Your Worst Case Scenario: An Introduction to Threat Modeling

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.

What is Threat Modeling?

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’[1], threat modeling is essentially a process of answering these four questions:

1. What are you building?
2. What can go wrong?
3. What should you do about what can go wrong?
4. Did you do a decent job of analysis?

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.

Spoofing

Tampering

Repudiation

Information Disclosure

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.

Why Perform Threat Modeling

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.

Understand Security Requirements

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.”

Mitigate Threats Before A Breach

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.

Identify Threats That May Not Have Been Considered

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.

Threat Modeling in 4 Steps

The below is a simple framework to help you start threat modeling immediately.

Start With A Diagram

Understanding the intended operation of your application or system is a necessary first step. Include the following:

• Data flows
• Specified internal and external processes
• Identified trust boundaries

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.

Search For Threats

There are a number of ways to search for threats. Here are some key activities:

• Identifying threat actors
• Building attack trees
• Creating attack scenarios
• Playing “Elevation of Privilege” – a card game that can make finding threats (somewhat) enjoyable
• Most importantly, be creative! (Threat actors certainly are)

Build Defenses

There are four things you can do with identified threats:

• Eliminate the threat
• Mitigate the threat
• Transfer the threat
• And if you can’t do any of the above, accept the risk

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.

Evaluate the Model

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:

• What threats did we miss?
• Are the responses valid?
• Did we file a bug/ticket/backlog/action item for each mitigation?
• What is our highest priority?

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.

[1] Wiley press, 2014 – pg 4