Threat Modeling & SDL-IT

A common challenge for folks looking at threat modeling as a control to potentially help them secure their software is setting the correct expectations. So what exactly can threat modeling do for you? In order to answer this question, I think it’s important to first set the context.

 

Within our team, ACE, everything pretty much revolves around an application risk management process we’ve established known as Security Development Lifecycle for IT or SDL-IT for short. SDL-IT basically looks like the following:

 

 

 

The best way to think of SDL-IT is as a process that defines control points into a typical software development lifecycle (BTW: the picture maybe a little misleading as SDL-IT does work on more agile or iterative development processes as well but that’s a different discussion). So any typical lifecycle will have an envisioning, design, development, etc. phase. What SDL-IT does is mandate certain tasks (through risk management controls) alongside these development controls in order to inject risk management into the process.

 

Now you can also view SDL-IT as a control management framework. At the very first stage, envision, we’re trying to catalog all of our application that make up our enterprise portfolio and then to classify each application in that portfolio against a risk classification. This is important: Microsoft has one application internally that manages our non-disclosed financial information and we have another application that displays the menu items for cafeterias across the campus. Both of these applications may be built using IIS6, .NET 2.0 and SQL Server 2.5 so they have the same technical composition and yet their business risk is completely different. It’s the business risk that we use to classify the application which in turn defines the level of ‘security scrutiny’ the application is given throughout the rest of the process.

 

After this stage, we move onto threat modeling in which we articulate the risk in the application contextualized against the business requirements, define the acceptable assurance level of the application and align that with the kinds of security controls (e.g., Encryption, Encoding, Input Validation, Password Policies, etc.) that we would need to implement in order to achieve that assurance level. Moving on, during development, we implement the identified control, during test we verify the implementation of those controls and finally in production/release, we monitor the controls for compliance throughout the lifetime of the application.

 

This is the quick 30,000 foot overview of SDL-IT on a foggy day… J

 

So what threat modeling does is provide a framework on top of which to consistently articulate and understand the business risk and align that to an acceptable assurance level which we realize in the form of a security strategy implemented in the software we are about to build. In other words, it’s a structure way of helping application development teams to think about security in the course of designing and developing their system. And unless you can start thinking about security _early_ in the development lifecycle, you’re not going to be very successful in maintaining a secure posture of your system in a cost effective manner (as by now this fact has become general knowledge: addressing security early in the lifecycle is more effective than later).

 

In short: threat modeling, on its own, is a great way to start thinking about security in the systems you develop. To take it a step further, make threat modeling a fundamental part of the development lifecycle and your benefits will only increase.

 

As always, let us know if you have any questions or comments (click 'Email').

 

Thanks.

 

-Talhah Mir

Comments

• Anonymous
  October 04, 2007
  Many times when we’re speaking with a customer or reviewing material from security vendors, the inclination