Post navigation

There’s been a lot said in security circles about a talk on Tor being pulled from Blackhat. (Tor’s comments are also worth noting.) While that story is interesting, I think the bigger story is the lack of infrastructure for disclosure coordination.

Coordinating information about vulnerabilities is a socially important function. Coordination makes it possible for software creators to create patches and distribute them so that those with the software can most easily protect themselves.

In fact, the function is so important that it was part of why CERT was founded to: “coordinate response to internet security incidents.” Now, incidents has always been more than just vulnerabilities, but vulnerability coordination was a big part of what CERT did.

The trouble is, it’s not a big part anymore. [See below for a clarification added August 21.] Now “The CERT Division works closely with the Department of Homeland Security (DHS) to meet mutually set goals in areas such as data collection and mining, statistics and trend analysis, computer and network security, incident management, insider threat, software assurance, and more.” (Same “about” link as before.)

This isn’t the first time that I’ve heard about an issue where CERT wasn’t able to coordinate disclosure. I want to be clear, I’m not critiquing CERT or their funders here. They’ve set priorities and strategies in a way that makes sense to them, and as far as I know, there’s been precious little pressure to have a vuln coordination function.

It’s time we as a security community talk about the infrastructure, not as a flamewar over coordination/responsibility/don’t blow your 0day, but rather, for those who would like to coordinate, how should they do so?

Heartbleed is an example of what can happen with an interesting vulnerability and incomplete coordination. (Thanks to David Mortman for pointing that out in reviewing a draft.) Systems administrators woke up Monday morning to incomplete information, a marketing campaign, and a slew of packages that hadn’t been updated.

Disclosure coordination is hard to do. There’s a lot of project management and cross-organizational collaboration. Doing that work requires a special mix of patience and urgency, along with an unusual mix of technical skill with diplomatic communication. Those requirements mean that the people who do the work are rare and expensive. What’s more, it’s helpful to have these people seated at a relatively neutral party. (In the age of governments flooding money into cyberwar, it’s not clear if there are any truly neutral parties available. Some disclosure coordination is managed by big companies with a stake in the issue, which is helpful, but it’s hard for researchers to predict and depend apon.) These issues are magnified because those who are great at vulnerability research rarely spend time to develop those skills, and so an intermediary is even more valuable.

Even setting that aside, is there anyone who’s stepping up to the plate to help researchers effectively coordinate and manage disclosure?

[Update: I had a good conversation with some people at CERT/CC, in which I learned that they still do coordination work, especially in cases where the vendor is dealing with an issue for the first time, the issue is multi-vendor, or where there’s a conflict between vendor and researcher. The best way to do that is via their vulnerability reporting form, but if things don’t work, you can also email cert@cert.org or call their hotline (the number is on their contact us page.]

[Update 2, Dec 2014: Allen Householder has a really interesting model of “Vulnerability Coordination and Concurrency Modeling” on the CERT/CC blog, which shows some of the complexity involved, and touches on topics above. Oh, and some really neat Petri-dish state models.]

There are people who can write eloquently about events of such significance. I am not one of them. I hope that doesn’t stand in the way of folks remembering the amazing accomplishment that the Apollo program was.

I’m getting ready to announce an East coast book tour. In planning my Silicon Valley tour, I learned that between scheduling, getting the details needed out, making sure I knew where I was sleeping, there was a large amount of administrative work involved. So I’d like to hire someone to take care of all that for me next time.

I think the tasks will include:

Engage with companies/venues interested in having me speak to work through scheduling & logistics, including ordering books

Scheduling (including travel time, setup, speaking, signing)

Travel coordination including hotels & trains

Do you have recommendations for a virtual assistant service that you’ve used for something at this level of complexity?

Alternately, convince me that I want a specialized book tour operator? My experience in Silicon Valley was that most venues were companies, and many were good enough to buy the books for their employees. So I don’t think I need someone specialized.

Via Poynter, we learn that the word “massive” has been banned on Gawker.

We want to sound like regular adult human beings, not Buzzfeed writers or Reddit commenters,” new Gawker Editor Max Read says in a memo to the publication’s writers. Words like “epic,” “pwn” and “derp” are no longer welcome on the site. Read also says the word “massive” is “never to appear on the website Gawker dot com.”

The desire to sound like regular human beings is admirable, and Mr. Read is correct when he says that jokes made using strikethrough are generally not worth saving.

However, he seems to fall into a trap of believing that there is an hierarchy of language goodness which is removed from our social hierarchies. We’re not the French, with L’Acadamie française to define correct language, and to be ignored by Le Frenchmen dans on le weekends.

The observable reality is that language evolves as a result of a variety of pressures or opportunities. That is, language is emergent, not decreed. There is no authority who gets to declare what words a community uses (outside of NewSpeak, and even in Orwell’s world, normal people don’t use NewSpeak daily, because the words decreed by Big Brother didn’t serve their needs. Real language is inevitably chaotic and messy.

One of the most effective ways to improve your software is to use it early and often. This used to be called eating your own dogfood, which is far more evocative than the alternatives. The key is that you use the software you’re building. If it doesn’t taste good to you, it’s probably not customer-ready. And so this week at RSA, I think more people should be eating the security community’s cryptographic dogfood.

As I evangelize the use of crypto to meet up at RSA, I’ve encountered many problems, such as choice of tool, availability of tool across a set of mobile platforms, cost of entry, etc. Each of these is predictable, but with dogfooding — forcing myself to ask everyone why they want to use an easily wiretapped protocol — the issues stand out, and the companies that will be successful will start thinking about ways to overcome them.

So this week, as you prep for RSA, spend a few minutes to get some encrypted communications tool. The worst that can happen is you’re no more secure than you were before you read this post.

I am super-excited to announce that my new book, Threat Modeling: Designing for Security (Wiley, 2014) is now available wherever fine books are sold!

The official description:

If you’re a software developer, systems manager, or security professional, this book will show you how to use threat modeling in the security development lifecycle and the overall software and systems design processes. Author and security expert Adam Shostack puts his considerable expertise to work in this book that, unlike any other, details the process of building improved security into the design of software, computer services, and systems — from the very beginning.

Find and fix security issues before they hurt you or your customers

Learn to use practical and actionable tools, techniques, and approaches for software developers, IT professionals, and security enthusiasts

Explore the nuances of software-centric threat modeling and discover its application to software and systems during the build phase and beyond

Use specific, actionable advice regardless of software type, operating system, or program approaches and techniques validated and proven to be effective at Microsoft and other top IT companies

Threat Modeling: Designing for Security is full of actionable, tested advice for software developers, systems architects and managers, and security professionals. From the very first chapter, it teaches the reader how to threat model. That is, how to use models to predict and prevent problems, even before you’ve started coding.

Threat Modeling: Designing for Security is jargon-free, accessible, and provides proven frameworks that are designed to integrate into real projects that need to ship on tight schedules.

Availability

Amazon has Kindle edition, and is saying that the paperback will ship in “9-11 days.” I believe that’s startup issues in getting the books to and through the warehousing system, but don’t know details. I will be having a book signing at RSA, Wednesday at 11 AM in Moscone South. (iCal reminder.)

Future blogging

In light of me celebrating the joyous chaos of what to put on which blog, but more importantly, not wanting readers to have to subscribe to three blogs, I’ll be blogging about threat modeling over on the New School blog.

I fell victim to an interesting attack, which I am recounting here so that others may avoid it.

In a nutshell, I fell victim to a trojan, which the malefactor was able to place in a trusted location in my search path. A wrapper obscured the malicious payload. Additionally, a second line of defense did not catch the substitution. I believe the attackers were not out to harm me, but that this trojan was put in place partially for lulz, and partially to allow a more-important attack on the systems RBAC mechanisms to succeed.

Attack Details

I was attempting to purchase a six pack of New Belgium Rampant IPA, shown immediately below.

I obtained the six pack from the canonical location in the system – a reach-in refrigerator in the supermarket’s liquor aisle. I proceeded to the cashier, who rang up my purchase, bagged it, and accepted payment.

I realized upon arrival home, that this was a trojan six pack, as seen below:

Clearly, the attacker to care to make his payload look legitimate. What I noticed later, was the subtle difference I zoom in on below

:

Yes, the attacker had substituted root beer for real beer.

Needless to say, this was a devious denial of service, which the perpetrators undoubtedly laughed about. However, this was likely not just “for the lulz”. I think this was the work of juvenile attackers, whose motives were to defeat the RBAC (real beer access control) system. Knowing that a purchase of real beer would be scrutinized closely, I believe they exfiltrated the target beer by hiding it in a root beer package.

Mitigations put in place by the system did not catch this error – the cashier/reference monitor allowed the purchase (and likely, the offsetting real beer as root beer purchase).

Possible Countermeasures

The keys to this attack were that the trojan was in the right place in the search path, and that it appeared legitimate. Obviously, this location must be readable by all, since items need to be fetched from it. However, allowing items to be placed in it by untrusted users is a definite risk. Technical constraints make the obvious countermeasure — allowing only privileged stocking, while permitting “world” fetching — presents serious usability concerns, and increases system cost, since the privileged stocker must be paid.

Nonetheless, such countermeasures are in place for certain other items, notably where the cost to the system — as opposed to the user — of an illicit item substitution is quite high.

Lessons learned

Ultimately, system usability and cost tradeoffs put the onus on the end-user. Before taking a non-idempotent step, inspect the objects closely!

For those of you who don’t know Adam, he created Hashcash, which is at the core of Bitcoin proof of work.

Two elements I’d like to call attention to in particular are:
First, there’s an interesting contrast between Adam’s opinions and Glenn Flieshman’s opinions in “On the Matter of Why Bitcoin Matters.” In particular, Glenn seems to think that transaction dispute should be in the protocol, and Adam thinks it should be layered on in some way. (Near as I can tell, Glenn is a very smart journalist, but he’s not a protocol designer.)

Secondly, Adam discusses the ways in which a really smart fellow, deeply steeped in the underlying technologies, can fail to see how all the elements of Bitcoin happened to combine into a real ecash system. Like Adam, I was focused on properties other systems have and Bitcoin does not, and so was unexcited by it. There’s an interesting lesson in humility there for me.