Threat Modeling without Security Subject-Matter Expertise
With this release of the process and the accompanying tool, there were 4 high-level objectives we are trying to fulfill:
- Provide a consistent methodology for objectively identifying and evaluating threats to applications.
- Translate technical risk to business impact.
- Empower a business to do effective application risk management during the SDLC and beyond.
- Create awareness among teams of security dependencies and assumptions.
I wrote about the challenges that lead us to our first objective (at the end of the post) and will be writing about the other three later. What I wanted to talk about here was a theme central to our process. This being the ability to produce feature-rich threat models with a process that meets these objectives without requiring security subject-matter expertise.
We’ve been doing security consulting work (code assessment, training, design reviews, etc.) internally in Microsoft for almost half a decade now. Threat modeling is one of the more recent activities we pushed out in an effort to make application teams more pro-active about security. One of the key observations we’ve made (especially with v1 of threat modeling) is that application development teams do not want to be security subject-matter experts (SME) – it’s not their job! (before you gasp for air, allow me to finish… J).
One doesn’t have to be a security SME to write secure software.
The first thing to point out here is that there is a fundamental difference between becoming a security SME and being security aware. When building a house, you have various professionals involved in the process. Here, you wouldn’t expect the carpenter to be able to lay the bricks or the either of them to be able to do the plumbing. But you still expect everyone involved in the process to build a structurally sound house at the end without any of them being structural engineers. Structural soundness is just one attribute of the house along with energy efficient, appealing, etc.
When building a software application, the same kind of thing applies. Development teams have to worry about a lot of things such as scalability, usability, performance, accessibility, cost, etc. and they have various professionals involved (architects, developers, testers, etc.). Security is just another attribute they have to worry about. Granted that depending of the application being built, security may take greater or lesser (yes, believe it!) significance than other attributes. It’s our job, as security SMEs, to empower the development teams in their quest to build secure applications by making them more security aware.
With our threat modeling, we’re trying to empower the business to do effective application risk management. Threat modeling is essentially about creating specific instances of the following structure:
Now defining the threat is the job of the development teams (because it’s their application and their business) but they can’t define or know what kind of attacks are going to be used to realize those threats (or the vulnerabilities used to materialize these attacks or the countermeasures used to mitigate these vulnerabilities). There is a separation of duties here and what we needed to do (and did in V2) is acknowledge that. The development teams need to model their application and identify the threats inherent in it. After that, they utilize these known attacks, in the form of the Attack Library, that is created and verified only by security SMEs. This Attack Library is a very fundamental feature of our process and is meant to be extensible (more on this in a later post).
Threat Modeling can’t replace other security activities like code reviews, design reviews, training, etc. What it can and does do is to complement these activities. Our job, as security SMEs, is to ensure that the threat models are optimized and are complete and that appropriate up-to-date guidance (through Attack Libraries) is being followed. But at the end of the day, threat models need to be created by application development teams in order to define their threat profile that are not – and will never be because it’s not their job – security subject matter experts.
-Talhah Mir