Hopefully, you’ll all know by now what Heartbleed is about. It’s not a virus, it’s a bug in a new feature that was added to a version of OpenSSL, wasn’t very well checked before making it part of the standard build, and which has for the last couple of years meant that any vulnerable system can have its running memory leached by an attacker who can connect to it. I have a number of approaches to make to this, which I haven’t seen elsewhere:
You know me, I’m all about the “defence against the dark arts” side of information security – it’s fun to attack systems, but it’s more interesting to be able to find ways to defend.
Here are some of my suggestions about programming practices that would help:
There’s just a few ideas off the top of my head. It’s true that this was a HARD bug to find in automated code review, or even with manual code review (though item 2 above tells you that I think the code looked perverse enough for a reviewer to demand better, cleaner code that could at least be read).
Clearly, from the number of sites (in all countries) affected negatively by this flaw, from the massive hysteria that has resulted, as well as the significant thefts disclosed to date, this bug was a National Security issue.
So, how does the US government respond to the allegations going around that they had knowledge of this bug for a long time?
By denying the allegations? By asserting they have a mandate to protect?
No, by reminding us that they’ll protect US (and world) industries UNLESS there’s a benefit to spying in withholding and exploiting the bug.
There was even a quote in the New York Times saying:
“You are not going to see the Chinese give up on ‘zero days’ just because we do.”
No, you’re going to see “the Chinese” [we always have to have an identifiable bogeyman] give up on zero days when our response to finding them is to PATCH THEM, not hold them in reserve to exploit at our leisure.
Specifically, if we patch zero days when we find them, those weapons disappear from our adversaries’ arsenals.
If we hold on to zero days when we find them, those weapons are a part of our adversaries’ arsenals (because the bad guys share better than the good guys).
National Security officials should recognise that in cyberwar – which consists essentially of people sending postcards saying “please hit yourself” to one another, and then expressing satisfaction when the recipient does so – you win by defending far more than by attacking.
It’s often been stated that “many eyeballs” review open source code, and as a result, the reviews are of implicitly better quality than closed source code.
Clearly, OpenSSL is an important and widely used piece of security software, and yet this change was, by all accounts, reviewed by three people before being published and widely deployed. Only one of those people works full time for OpenSSL, and another was the author of the feature in question.
There are not “many” eyeballs working on this review. Closed source will often substitute paid eyeballs for quantity of eyeballs, and as a result will often achieve better reviews.
Remember, it’s the quality of the review that counts, and not whether the source is closed or open.
Closed source that is thoroughly reviewed by experts is better than open source that’s barely reviewed at all.
But here’s the one I use to describe it to family members.
Imagine you’re manning a reception desk.
Calls come in, you write down messages, and you send them off.
At some point, you realise that this is a waste of paper, so you start writing your messages on a whiteboard.
Wiping the whole whiteboard for each message is a waste of effort, so you only wipe out enough space to write each incoming message.
Some messages are long, some are short.
One day, you are asked to read a message back to the person who leaves it, just after you wrote it.
And to make it easy, they tell you how long their message is.
If someone gave you a six letter message, and asked you to read all six hundred letters of it back to them, you’d be upset, because that’s not how many letters they gave you.
Computers aren’t so smart, they are just really fast idiots.
The computer doesn’t get surprised that you sent six characters and ask for six hundred back, so it reads off the entire whiteboard, containing bits and pieces of every message you’ve had sent through you.
And because most messages are small, and only some are large, there’s almost an entire message in each response.
Amid almost no fanfare whatsoever, Microsoft yesterday released a tool I’ve been begging them for over the last five or six years.
[This is not unusual for me to be so persistently demanding, as I’ve found it’s often the only way to get what I want.]
As you’ve guessed from the title, this tool is the “SDL Threat Modeling Tool 2014”. Sexy name, indeed.
Well, yeah, kind of. There’s the TAM Threat Analysis & Modeling Tool, which is looking quite creaky with age now, and which I never found to be particularly usable (though some people have had success with it, so I’m not completely dismissive of it). Then there’s the previous versions of the SDL Threat Modeling Tool.
These have had their uses – and certainly it’s noticeable that when I work with a team of developers, one of whom has worked at Microsoft, it’s encouraging to ask “show me your threat model” and have them turn around with something useful to dissect.
In a word, Cost.
Threat modeling tools from other than Microsoft are pretty pricey. If you’re a government or military contractor, they’re probably great and wonderful. Otherwise, you’ll probably draw your DFDs in PowerPoint (yes, that’s one of the easier DFD tools available to most of you!), and write your threat models in Word.
Unless, of course, you download and use the Microsoft SDL Threat Modeling Tool, which has always been free.
The SDL TM tool itself was free, but it had a rather significant dependency.
Visio is not cheap.
As a result, those of us who championed threat modeling at all in our enterprises found it remarkably difficult to get approval to use a free tool that depended on an expensive tool that nobody was going to use.
With the release of Microsoft SDL Threat Modeling Tool 2014, Microsoft has finally delivered a tool that allows for the creation of moderately complex DFDs (you don’t want more complex DFDs than that, anyway!), and a threat library-based analysis of those DFDs, without making it depend on anything more expensive or niche than Windows and .NET. [So, essentially, just Windows.]
Yes, that means no Visio required.
A quick bullet list of some of the features you’ll like, besides the lack of Visio requirement:
Yes, every good blog post has to have one of these, doesn’t it? What am I asking you to do with this information?
Download the tool. Try it out on a relatively simple project, and see how easy it is to generate a few threats.
Once you’re familiar with the tool, visit the KnowledgeBase directory in the tool’s installation folder, and read the XML files that were used to create your threats.
Add an object type.
Add a data flow type.
Add custom properties that describe your custom types.
Use those custom properties in a rule you create to generate one of the common threats in your environment.
Work with others in your security and development teams to generate a good threat library, and embody it in XML rules that you can distribute to other users of the threat modeling tool in your enterprise.
Document and mitigate threats. Measure how successful you are, at predicting threats, at reducing risk, and at impacting security earlier in your development cycle.
Then do a better job on each project.