Update: 28-11-2008 - Microsoft have released an update - v3 of the SDL Threat Modelling Tool - which is DFD based as opposed to use case driven. Check it out at The Microsoft SDL Threat Modeling Tool v3
Original post....
In my first year on the MSc programme at RHUL ISG, I completed a course on security management, and while that hardly makes me an expert (since I'm still new to the world of information security), the course was excellent, and I learned a lot about the fundamentals of building an information security management system.
At its most basic level, information security management is about attempting to estimate the probability and impact of unwanted events; events that may effect the confidentiality, availability or integrity of information assets. Estimates about the risks associated with these events can then be used to make decisions about what measures (if any) an organisation will choose to implement as part of its overall information security management strategy.
The process of estimating and assessing risk should be guided by an information security policy that, among other things, will state the aims, values and objectives of an organization with regards to risk. The policy, when combined with legal, businesses and moral responsibilities will (or at least should) influence the choices that are made in managing risk within an organization (the ISO 27000 series of documents is the place to start if you'd like to know more about building an information security management system (ISMS)).
The process of producing risk estimates is called risk assessment, and while there are different techniques for performing a risk assessment, the common goal of each is to produce a metric that allows risks to be weighed. Weighting risks allows an organization to make appropriate decisions about how to prioritise and manage risk.
One formula that is often used to describe the calculation of risk is: risk = threat x vulnerability x impact, which translates to: What is the level of an identified threat (how common is it, how relevant is it to the industry or asset in question), how vulnerable is the asset or system to the threat, and what is the impact if the vulnerability to a specific threat for a specific asset is realized. If any of the factors are zero - then risk is is also zero.
Acceptable choices in managing risk include: 1) accept the risk, 2) mitigate the risk, 3) transfer the risk or 4) avoid the risk.
The first task then is to work out what the threats are, creating an applicable threat model (well actually the first task is to work out what your assets are - how much they're worth to you, and what a total loss of that asset would cost you in both tangible and intangible terms - but let's assume we're at the threat identification stage).
So how are threats identified? Well I think for the most part they come from a body of knowledge and experience that exists for a given industry and its assets. For example - a jewellery shop is likely to consider the threat of theft to be relevant since it has stuff of value, and jewellers have learned, through experience, that a small percentage of the population will attempt to steal things of value, ergo.. theft is a threat. How vulnerable the jewellery shop is to theft depends on where it's located, how valuable the jewels are, and whether or not the shop has implemented any measures designed to prevent theft- like locks on cabinets, security cameras, security cards etc.
Threats against computer systems and networks also require a body of knowledge in terms of historical and current threats. One approach in helping to identify threats as part of risk assessment is to use a threat library, or database of known threats. There are a few systems out there that take this approach - like a software tool called CRAMM Expert (based on the the CRAMM methodology) which includes a database of threats that you can use to create a threat model for your organisation.
This evening, during another one of those serendipitous link journeys, combined with some reading I've been doing on application lifecycle and security, led me to discover a link to the Threat Modeling Tool tool from Microsoft. While other methodologies in risk assessment cover a wide range of threats and security management issues, Microsoft's tool is geared specifically towards managing risk in software (not surprisingly) and is part of Microsoft's Security Development Lifecycle (SDL) methodology.
I think this tool (and the methodology) is pretty interesting. For starters it's free, which shows how committed Microsoft is to not only producing secure software, but to helping the community at large incorporate secure software development practices into their overall software development process.
In fact it was this post by Adam Shostack, Experiences in Threat Modeling At Microsoft (an excellent article) which led me to the SDL portal, and it was a reference in Bruce Schneier's - Crypto-Gram monthly newsletter that led me to Adam Shostack's post.
I can't claim to be an expert in using this tool after just 30 minutes of experimenting... but I was impressed. Using the the "New with wizard" option - I was able to create a rudimentary threat model in just a few minutes.
The process involved defining user roles (UR), components, service roles (SR) and data. The tool and the process is 'data centric' and as Adam Shostack points out in his article,
"... a great many software attacks involve the flow of data through the system in some way...."
Components used in service roles are also assigned relevancies (or features) like whether the component utilizes HTTP, or builds SQL queries.
Access control rules are created for the defined data entities - both for users and components.
Application Use Cases are then created which in turn are composed of application calls. The caller for each call in a use case can be a user role (UR) or a service (SR).
Threats can then be automatically generated and the tool will attempt to match a list of attacks in the attack library with the calls in a use case, creating a threat list for the given use case. The terminology here is slightly different from what I was taught - since I would have classified the threats that were produced as vulnerabilities, and the attack library as a threat library or database.
Here's an example call graph from a simple use case.
And here's a full screen-shot of the application with an automatically generated threat (vulnerability) that was created for the "Create User" use case. I'm about to choose 'Reduce' as my Risk Response (remember I can choose to avoid, reduce, transfer or accept a risk). I've also chosen three counter-measures as the mechanisms I will use to reduce risk (click on the image for a larger version).
There is a lot in here, including being able to specify authentication mechanisms for roles (which I'm assuming is used to weight and select attacks) as well as analytics including data access matrix, component access matrix and subject object matrix reports as well as visualizations for call, data and trust flows. Other reports are divided into risk owner reports, design team reports, development team reports and test team reports. Development team reports even include code examples on how to implement selected countermeasures.
To be honest I'm not sure entirely where the Threat Analysis and Modelling tool fits into the data flow diagram (DFD) and "STRIDE per element" approach described in Adam Shostack's paper. The tool appears to be use case driven as opposed to data flow diagram driven.
Also wondering how this application might be integrated with other application design components, like logical or physical design models. There are options for importing Visual Studio Team System Deployment reports as well as exporting Team System Work Items.
I guess the ultimate test in value will be in how much effort is required to build and maintain a threat model using this application when compared to other methods. Large models in particular might be difficult to maintain, although I guess there is no reason why you couldn't use this application to create several smaller threat models with only the user/service roles, data and use cases that are specific to a given feature or iteration of development.
I think it's also worth pointing out that the Threat Analysis and Modelling tool is just one (albeit important) part of a larger process designed to create secure software. It is not a replacement for functional, performance, vulnerability (penetration) and regression testing, nor does it appear to have any risk modelling functions for assessing application deployment, configuration and change management risks.
My limited experience with both this application and a formal software security development process means that I'm not able to say how successful this application might be at helping to 'connect' the security process with application development. But it is a very interesting product, feature rich and easy to use - with zero financial risk to boot.
Managing the risks associated with software, whether developed in-house or acquired is a core component any information security management process and so any tool that helps to increase awareness and manage risk in this respect is a good thing.