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.
Televangelism in
IT - does this work?
My
IBM SpaceSaver II arrived today. Not sure what to say. The keyboard layout is perfect;
compact but not too small. Everything is in the right place. No number pad which is
important for me (as I mentioned in the first post) and helps to keep the keyboard
square with the screen.
