Diploma thesis regarding Threat Modeling

Question

Hi,

let me introduce myself. My name is David Elze and I'm a student of computer science at a german university. At the moment, I'm writing my diploma thesis regarding threat modeling as an efficient method to increase the security level of software projects at security code reviews.

After reading "Writing Secure Code" (Michael Howard/David LeBlanc), "Threat Modeling" (Frank Swiderski/Window Snyder), some additional books about secure programming and a lot of papers and stuff about threat modeling from the Microsoft perspective as well as other approaches (like TRIKE and PTA) I came to the conclusion, that the methodology by Swiderski/Snyder in combination with the ACE-Teams tam-methodology fits best for the company I do the thesis for.

Until now, only the old threat modeling tool from MS existed which did not match my requirements. Now the new tool is released and it seems to fit better for what I'm looking for, so thanks alot in the first place :-)

But I really want to know if you plan to integrate some better export filters and/or the possibility to draw attack trees in a visio-way like it is done for data flow diagrams!?

The first point (export) is very important. Imagine, you work for a security company that builds security profiles and threat models as a service. Now your client needs some nice document, that contains all the information of the threat model but also has some informative value, meaning more prose text than something completely generated.

My idea is to write some xml style sheet (or something similar) that "interprets" the data of a .tms-file and can include it into some template (word, rtf, you name it).

After I saw the old threat modeling tool, I planned to write some web app to do exactly what the new threat modeling tool does. Well, now that the new one exists, maybe I don't have to write stuff like described because you guys already have something in the pipeline!?

Greets, David

Answer 1

Hey David,

Let me take this to the guys who wrote the tool and see if I can get you an answer.

Dana Epp
Microsoft Security MVP

Answer 2

Hi David,

I'm the PM owner behind the tool.  I'm glad you're finding it a better fit.  We're not making any commitments to future versions just yet, but let me give you my feedback.

1) Reports are (mostly) generated via XSLT.  Have you investigated those as an avenue for changing the reports?

2) I doubt threat trees are in the near future.   My experience is that threat trees are a very expert-centric approach which stymie non-experts.  Since we're focusing on tools to help non-experts, I don't think we'll go in this direction.

Finally, since you mention you're a degree student, let me point you at the Proceedings of the Workshop on Modeling Security (MODSEC08) held as part of the 2008 International Conference on Model Driven Engineering Languages and Systems  http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-413/ , where I published a paper on Experiences Threat Modeling at Microsoft.  It discusses a lot of our approaches to threat modeling, and that has obvious impact on the tooling.

Adam

Answer 3

Hey Adam,

thanks a lot for your reply, I actually already read your paper but your hint to the xslt-files was very helpful. I'll take these to do some conversion stuff and if something practical comes out of it I'll be glad to share the results with you.

Your approach, to give non-security experts a tool for threat modeling, is very interesting. I, personally, think that threat modeling involves a lot of security-centric thinking and is likely to fail for non-experts. Lets take the old tool. Without any security knowledge, one could insert all "known stuff" (like assets, use cases etc.) if these details were known (which is often not the case, unfortunately). But the result, a nearly complete threat model, did not really help in reality, because it was too complex. With the new tool, you can shorten your threat model (removing DoS from a data flow for example) and thus eventually make it more comprehensive. Sure, you loose completeness, but that often needed to fit real-life use-cases that involve specific time frames and so on ;-)

So due to the fact that I'm aiming to create a usuable methodology/tool-support-environment for creating threat models in different complexity levels, done by security-experts for non-security experts, the new tool is a good starting point. Think of a conversion from the old approach ("brainstorm threats, value them and give mitigations") to a new, more methodic one ("find out as much as possible about the assets, roles and entry points, input them into a {tool|document template}, think of threats and connect assets/roles/entry points/threats to get the whole picture, describe vulnerabilities if known, give mitigations"). This new approach should drive security code reviews more efficientl, (i.e. the threat model should point a security reviewer to important points in the code which should increase efficiency (no more line-by-line searching) and effectiveness (threat modeling has the advantage of identifying context and thus could find security-related problems that line-by-line inspection can not).

Well, hopefully I can prove that the last sentence is really true :-)

Greetings, David