Threat modeling is an important piece of the security puzzle that may be missing in many IT organizations. Building a comprehensive model of the threats to your applications, systems, and organization will focus your security efforts where they matter most.
When you drive your car, do you fasten your seat belt? Then, you understand the concept of threat modeling. And if you don’t use your seatbelt, you are still conducting some sort of threat modeling by accepting the risk of injury or death from an accident.
Threat modeling approaches are as varied and numerous as the practitioners who implement them. As Adam Shostack points pointed out in ‘Threat Modeling: Designing for Security’, threat modeling is essentially a process of answering these four questions:
The framework you use isn’t as important as answering those questions, and depending on your goals, different frameworks will make more sense. STRIDE, for example, was created by a software company for the modeling of their applications during the development process, so it naturally applies to software development.
Denial of Service
Elevation of Privilege
This mnemonic was developed at Microsoft in 1999 as an approach to organizing their mindset around classes of threats to their applications. You may have also heard of other frameworks or methodologies such as VAST, DREAD, or OCTAVE.
Think beyond application or product development, though. Does your network engineering team model threats to the network? Does your directory engineering team model threats to their directory implementation? What about operations teams, like desktop or facilities? While these groups are constantly thinking about and reacting to perceived threats, it is more of an informal process that relies on tribal knowledge and rarely produces any documentation. These teams would benefit from a formalized process of threat modeling that documents the identified threats and mitigation responses to help security efforts. Those documents may include a threat heat map, security design document, and often backlog items or work tickets to implement mitigation strategies.
There are three benefits to modeling threats at every organizational level. Scope network models as well as application models and roll those into an overarching system threat model for a more complete and actionable view.
By identifying threats, you will better understand your system’s security requirements. For example, you may model a threat of information disclosure through email. By identifying this threat, you understand the security requirement for encrypting sensitive data transferred via email.
Defining security requirements in this way will lead to targeted defense strategies. A security requirement of “Encrypt sensitive data” is not as specific or defined as “Sensitive data must be encrypted in the database and may only be transmitted through email using Public Key Encryption.”
The process of threat modeling will help you identify and respond to threats before a costly incident brings them to your attention. Too often, vulnerabilities are only found after they have been exploited. And by then, the real damage has been done.
Taking an attacker’s perspective will help you identify entire classes of threats that technical teams may have unintentionally overlooked. It is human nature to consider things from the perspective of one’s experience; thinking like an attacker doesn’t come naturally to most people. However, attackers have their own perspective, so it is important to try to understand their motivations, which will uncover their objectives and reveal more threats.
In threat modeling, we call this process threat actor profiling. Ask yourself, what would a financially motivated outsider try to do to your organization? They will be looking for ways to monetize the attack. Stealing PII or financial data is probably high on their list of priorities.
Now think about a morally motivated activist. What would they be willing to do to stop what they believe to be unjust or evil? Denial of service or public embarrassment are probably high on their list.
The below is a simple framework to help you start threat modeling immediately.
Understanding the intended operation of your application or system is a necessary first step. Include the following:
Balance the level of detail with enough information to clearly understand a system’s operation without going too deep into specifics of port numbers or variable names. In some cases, you may need more detail to fully understand a threat.
There are a number of ways to search for threats. Here are some key activities:
There are four things you can do with identified threats:
In most cases, you cannot completely eliminate threats without also eliminating functionality or feature set. This is where developing mitigation strategies becomes important. From our earlier example, if the threat is information disclosure of sensitive data sent through email, eliminating the threat would mean never emailing any sensitive data ever. Depending on your organization and workflow, that may not be possible. Therefore, a mitigation strategy is to encrypt emails that contain sensitive data.
Threat modeling needs to be a cross-functional team effort. Design and engineering teams have the knowledge of how the system is built and should function. Operations and support teams offer insight into daily operational challenges. Security teams tend to think like an attacker. All three perspectives are necessary for a solid threat model. As a group, ask yourself:
By incorporating threat modeling into your organization, you will better understand your IT security requirements, be they design considerations or compensation controls. And from this point forward, you have a greater likelihood of mitigating threats before they manifest into worst case situations. You can circumvent threats before exploitation occurs and identify classes of threats you may have never previously considered. And ultimately, this will save you time, money, and anguish.
 Wiley press, 2014 – pg 4