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.

Don’t they already have one of those?

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.

So what’s wrong with the current crop of TM tools?

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.

So where’s the cost?

The SDL TM tool itself was free, but it had a rather significant dependency.

Visio.

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.

What’s changed today?

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.

Is there anything else good about this new tool?

A quick bullet list of some of the features you’ll like, besides the lack of Visio requirement:

• Imports from the previous SDL Threat Modeling Tool (version 3), so you don’t have to re-work
• Multiple diagrams per model, for different levels of DFD
• Analysis is per-interaction, rather than per-object [scary, but functionally equivalent to per-object]
• The file format is XML, and is reasonably resilient to modification
• Objects and data flows can represent multiple types, defined in an XML KnowledgeBase
• These types can have customised data elements, also defined in XML
• The rules about what threats to generate are also defined in XML
• [These together mean an enterprise can create a library of threats for their commonly-used components]
• Trust boundaries can be lines, or boxes (demonstrating that trust boundaries surround regions of objects)
• Currently supported by a development team who are responsive to feature requests

Call to Action?

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.

I’ve written before on “Full Disclosure”:

• Full Disclosure – how full is full?
• "Full Disclosure" and the vendor.
• Dealing in Vulnerabilities – Denying the Vendor
• Sometimes ‘journalists’ make me spitting mad

Recent events have me thinking once again about “full disclosure”, its many meanings, and how it makes me feel when bugs are disclosed publicly without allowing for the vendor or developer to address the bug for themselves.

The post that reminded me to write on this topic was Tavis Ormandy’s revelation of the Help Control Protocol vulnerability, but it could be anyone that triggered me to write this.

How you disclose implies your motivation

Securing the users

If your motivation is to help secure users and their systems, then I think your disclosure pattern should roughly be:

1. Find the world-renowned experts in the code (usually including the software’s developers) where the vulnerability lies.
2. Discuss the extent of the flaw, and methods to fix and/or work around it.
3. Get consensus.
4. Test workarounds and fixes, so as to ensure that your fix is sufficient, as well as that it does not kill more important functionality.
5. Publicise only as much demonstration as is required to show that the problem exists, and that it is serious.
6. Release patches and workarounds, and work with affected users to assist them in deploying these.
7. After a reasonable amount of time, publicise the exploit in full detail, so as to encourage developers not to cause similar mistakes, and to ensure that slow users are given good reason to upgrade their systems.
8. Only if the vendor refuses to work with you at all do you publish without their involvement.

[Obviously, some of the timing moves up if and when the exploit appears in the wild, but the order is essentially the same.]

Disadvantages:

• The bad guys may already have the vulnerability.
• This only makes sense with relatively obvious vulnerabilities, and even then, working with the vendor allows you and the vendor to quantify its extent beyond what you know on your own, and beyond what the bad guys currently know, so that the bug can be fixed properly. Believe it or not, enterprises get really pissed when you release a “bug fix”, and then release another fix for the same bug, and then another fix for the same bug. For every time you revise the bug fix, you decrease the number of users applying the fix.
• Someone else may publish ahead of you.
• That’s okay, you’re smart and you’ll get the next one – besides, most vendors you’re working with will say in their bug report that you reported it to them, rather than the guy who publishes half-cocked.
• Your bug report, collaborating with the vendor/developer, will be correct, whereas the other guy’s report will be full of its own holes, which you and the vendor can happily poke holes in.

Personal publicity

It’s fairly clear that there are some people in the security research industry whose main goal is that of self-publicity. These are the show-offs, whether they are publicising their company or their services or just themselves.

For these people the disclosure pattern would be:

1. Demonstrate how clever I am by detailing the depth of the exploit with full examples.
2. Watch while everything else happens.
3. Occasionally interject that others don’t understand how important this vulnerability is.

Disadvantages:

• This really makes the vendor hate you – which is great if you don’t ever need their assistance.
• Occasionally, you’ll report something stupid – something that demonstrates that not only are you clueless about the software, but you’re loudly clueless.
• It’s obvious that you’re in this for the publicity, rather than to help the user community get secure; as a result, users don’t come to you as much for help in securing their systems. Which is a shame if that’s the job you’re trying to get publicity for.

Just for the money

When all you’re in it for is the money, the answer is clear – you shop around, describing your bugs to Tipping Point and the like, then selling your bug to the highest bidder.

Disadvantages:

• You may not necessarily get the publicity that brings future contracts and job interest.
• There’s a chance that the person / group buying your bug doesn’t share your motives.
• You get no further control over the progress of your bug.

Sometimes this isn’t so bad – you get the money, and many of the vulnerability buyers will work with vendors to address the bug – all the while, protecting their subset of users with their security tool.

To punish the vendor

What a noble goal – you’re trying to make it clear to users that they have chosen the wrong vendor.

Here, the disclosure pattern is simple:

1. Release full details of the vulnerability, with a wormable exploit that requires as little user interaction as possible.
2. Decry the security of a vendor that would be so stupid as to produce such an obvious bug and not find it before release.
3. Wait and watch as your posse takes up the call and similarly disses your chosen target.

Disadvantages:

• Again, you can look like an idiot if your research isn’t quite up to snuff.
• Actually, you can look like an idiot anyway with this approach, especially when you pick on vendors whose security has improved significantly.
• Vendors have their own posse:
• People who work at the vendor
• People who admire the vendor
• People who share the vendor’s position, and don’t want people like you being shitty to them either.
• You have to ask yourself – what am I looking for in a vendor before I determine that they are no longer subject to punishment?
• Or are all vendors equally complicit in evil?
• [Or only those who are fallible enough to let a bug slip through their testing?]

Here’s the lesson

You may agree or disagree with a lot of what I’ve written above – but if you’re going to publish vulnerability research, you have to deal with the prospect that people will be watching what you post, when you post it, how you post it – and they will infer from that (even if you think you haven’t implied anything of the sort) a motive and a personality. What are your posts and your published research going to say about your motives? Is that what you want them to say? Are you going to have to spend your time explaining that this is not really what you intended?

As Tavis is discovering, you can also find it difficult to separate your private vulnerability research from your employer – this is perhaps harder in Tavis’ case to draw the line, since he is apparently employed in the capacity of vulnerability. If your employer is understanding and you have an agreement as to what is personal work and what is work work, that’s not a big problem – but it can be a significant headache if that has not been addressed ahead of time.

The Rule: Performance optimizations are not worth making for anything less than 10% improvement in speed.

Corollary: Performance optimizations must be measured before and after, and changes reverted if they do not cause significant performance improvement.

Converse: If you are pushing back on implementing a feature “because it will make the app unbearably slow”, particularly if that feature is deemed a security requirement, you had better be able to demonstrate that loss in performance, and it had better be significant.

I come about this insight through years of work as a developer, in which I’ve seen far too many mistakes introduced through people either being “clever” or taking shortcuts – and the chief reason given for both of these behaviours is that the developer was “trying to make the program faster” (or leaner, or smaller).

I have also seen developers disable security features, or insist that they shouldn’t implement security measures (SSL is a common example) because they “will make the application slower”.

I have yet to see a project complete a proper implementation of SSL for security that significantly slowed the application. In many cases, the performance testing that was done to ensure that SSL had no significant effect demonstrated that the bottleneck was already somewhere else.