Rohit Sethi is a specialist in building security controls into the software development life cycle (SDLC). He has helped improve software security at some of the world's most security-sensitive organizations in financial services, software, ecommerce, healthcare, telecom and other industries. Rohit has built and taught SANS courses on Secure J2EE development. He has spoken and taught at FS-ISAC, RSA, OWASP, Secure Development Conference, Shmoocon, CSI National, Sec Tor, Infosecurity, CFI-CIRT, and many others. Mr. Sethi has written articles for InfoQ, Dr. Dobb's Journal, TechTarget, Security Focus and the Web Application Security Consortium (WASC), has appeared on Fox News Live, and has been quoted as an expert in application security for ITWorldCanada and Computer World. He also created the OWASP Design Patterns Security Analysis project.
1. Threat Modeling is supposed to be one of the most effective and fundamental practices in secure software development. But a lot of teams that are trying to do secure development find threat modeling too difficult and too expensive. Why is threat modeling so hard - or do people just think it is hard because they don't understand it?
I've recently started touring across North American OWASP chapters facilitating discussions with the topic "Is there an end to testing ourselves secure?". It's an open dialogue about the problems with successfully scaling early-phase secure SDLC activities, and one of the hottest topics is threat modeling. There are a handful of companies that have had success rolling out threat modeling with appropriate tool support. Unfortunately, most people at these OWASP chapters are saying they just do not have the organizational expertise, motivation, and available cycles to really institute proper threat modeling. Many software shops lack a single architecture diagram, let alone the capacity to build data flow diagrams. They've found it difficult to enumerate every use case, to identify interaction between processes, and to enumerate defenses against generalized classes of threats such as spoofing.
For threat modeling to scale, it's supposed to be something that a development team can do on its own without the support of information security. The reality is that unless you have a development force that's very well educated in security (i.e. generally places where senior executives see application security as a differentiator), developer interest is generally low and they often feel that they don't have the requisite expertise to effectively build a threat model.
2. What are the keys to building a good threat model? What tools should you use, what practices should you follow? How do you know when you have built a good threat model - when are you done?
At Security Compass and SD Elements we tend to advocate a more agile approach to threat modeling, ?Threat Modeling Express', which is just a name we gave for something that companies have been doing for years. In the absence of a solid investment in a threat modeling library, we think you need application security expertise to build useful threat models. The approach is basically a 2-4 hour collaborative review session between an app sec expert, a developer, and somebody who represents the business. You enumerate a few major uses cases, think about threats from a business process perspective (i.e. "I'm worried that somebody can view somebody else's shopping cart "), collectively rate the risk of these threats, excuse the business person and try to hash out the technical attack vectors that somebody might use to enable these threats.
Ideally you spend more time focusing on domain-specific (a.k.a. business logic) threats because the domain-agnostic threats won't very much between use cases. It's an informal approach, it's not very comprehensive, it'll almost certainly miss things, but it's much easier to get started with until you've built up a business case to do comprehensive threat modeling. Most importantly, it requires a relatively low time commitment, which is almost always the biggest blocker to doing threat modeling.
3. Where should you start with threat modeling? Where's your best pay-back, are there any quick wins?
The earlier you can start the better, and doing it right at application design is most cost effective. The reality is that in most cases you won't have any choice: you're brought in to do a threat model and development is either well under way or done. In these cases it's better to treat threat modeling as a precursor to a security assessment. For example, effective threat modeling should identify and prioritize domain-specific threats, which gives a penetration tester or a source code reviewer guidance on where to focus.
In terms of quick wins you'll find that domain-agnostic threats tend to become repetitive for classes of applications. For example, almost all web applications have to build controls for XSS and CSRF. These recurring security issues dovetail into a discussion on security requirements, which I recently wrote an article for InfoQ. If you can institute a solid library of reusable threats for particular application types, then you can focus threat modeling time on the all-important domain-specific issues.