Security is usually a highly pragmatic area of concern. You make a specific technical error; you get hacked. You use a specific risk list, like OWASP Top 10, to prevent a specific security vulnerability. That sort of thing.
However, threat modeling is more subtle. Security personnel need to work with hypotheticals and deal well with nuance to understand what the real assets of your system are, and what are the most likely threats to those assets. Often, you’ll need to do this before any part of your system has been designed, let alone programmed.
By exploring nuances, you can get beyond hypotheticals and take a journey of discovery inside your own system until you arrive at the best specific technical solutions to your most important security concerns.
At Ad Hoc, we use a modified version of MITRE’s ATT&CK framework in several of our engagements. We combine this with a strategy for assigning priorities, based on the likelihood and impact of specific attacks chosen from ATT&CK, to help determine the order for prioritizing our security work.
Threat modeling at Ad Hoc often starts early in the process of designing a system, and can involve product managers as much as it does any of the engineering staff.
Backstory
On a blissfully cold July in Baltimore, Maryland some number of years ago, I performed my first threat model for one of Ad Hoc’s customers. It was a new experience and a new adventure for us, as we were going into uncharted territory; an SDLC Magellan in search of a land of threat scenarios, brandishing “best practices” and mitigation strategies.
It didn’t go well.
I didn’t have objectives identified for the modeling session. I failed to account for the target audience and their expertise and left the entire topic open to their interpretation, without specifically pinpointing what the objective of the threat model was. Addressing those mistakes became the foundation of our current methodology. We took the errors that we made during that first attempt, and focused on where we went wrong. We researched how to establish the threat model not so much as a checkbox security session, but by approaching it as a conversation with the team.
The main reason why the session wasn’t fully successful was that we were too vague about what the threat model was specifically going to cover. We produced a general overview of “what type of security risks concern our customer.” In some organizations, or with sufficient context, this type of modeling can be beneficial. However, in a modern, agile environment, specifically those who adhere to the “shift left” mentality and DevSecOps, this type of open-conversation methodology can actually decrease security. Far too often, you’ll find yourself in a continuous rabbit hole of scenarios, rather than addressing any specific threat.
Industry frameworks
In order to improve our threat modeling, we’ve looked at leading industry testing frameworks and broken them down to identify exactly what works for us and what works for the programs that we support.
Two industry-standard frameworks are Microsoft’s STRIDE, which focuses on six specific categories of threats, and MITRE’s ATT&CK, which is more comprehensive but also more complicated.
STRIDE
At first, we looked at attempting to incorporate the STRIDE model into our security processes. It made sense, from an application perspective, since so much of the STRIDE model also overlapped with the OWASP top 10 (looking at you, data exposure and information disclosure). When you have a process that builds upon the CIA Triad and focuses more on applying it’s methodology to an application, it works wonders. Except when it doesn’t.
Some of our issues fall outside the domains that STRIDE lists, and not all the programs that we support have applications that can fall within this model. One of the issues with the STRIDE model was its limitations around how to mitigate involuntary sensitive information being disclosed without authorization. For example, if sensitive information was received from a 3rd party application. It wasn’t leaked from our customer. Instead, the information was transferred to our client.
STRIDE doesn’t have anything that covers this example, as it’s information disclosure is focused more on the obtained information from a red team standpoint vs an ingestion point of view.
ATT&CK
At a later point, we tried to incorporate the MITRE ATT&CK framework into our work.
ATT&CK categorizes specific attacker techniques across a broader set of tactics. Tactics are things like “privilege escalation” or “defense evasion,” while techniques are more specific within the tactics, allowing you to link the tactic and the technique in a single sentence. For example, “privilege escalation by means of access token manipulation.”
While the ATT&CK method of doing assessments is excellent for certain applications, it didn’t work well for our scenarios. Due to the nature of our infrastructure, having an enterprise style threat assessment was not optimal for what we needed.
Going back to the example of receiving PII from a 3rd party without being authorized for its use, how would we model this with the framework provided? Unfortunately, there’s nothing included in the ATT&CK methodology that addresses these types of concerns.
Ad Hoc’s pragmatic model
Since neither the STRIDE nor ATT&CK model fit our needs perfectly, we’ve continued to evolve our process over time. We’ve had greater success applying our own “ad hoc” methodology to threat modeling, which allows us to focus not only on security vulnerabilities, but also on improved mitigation strategies and the chance to review the strategies we have in place rather than just one specific scenario.
The main idea of the “ad hoc” threat model is that instead of focusing on the exploitation from a 50,000ft view of the target, we have a more focused attack mentality. With a target selected, we can apply scenario-based discussions against the target to discover what mitigation strategies we have in place. So, what does this process look like for an “ad hoc” threat model?
1. Define the critical assets of your system
What information does your system maintain, and how valuable is that information? What are some of the possible consequences if something were to happen and this information was made publicly available? What defensive capabilities does the system have in place currently, across the board and individually?
2. Define the objective
What is it that you ultimately want to accomplish? What is the takeaway from this threat model? Do you want to spend the next 6 weeks in a sprint cycle attempting to implement the changes, or are there other topics that would provide a better scope?
Approaching the process with a clear definition of the scope of the engagement would allow for teams to have a more focused approach in responding to threats and providing mitigations. It allows for people to have a baseline idea of what to expect, to understand the general direction that the conversation should proceed, and more importantly, it triages possible rabbit hole scenarios from occurring. This is where the focused attack mentality comes into play.
3. Understand goals
Having pre-established goals for what you want to achieve for the threat model is critical for establishing a baseline. However, defining a pre-set goal can also hamper the ability to be more thoughtful and creative in your threat landscaping. Individuals who attack systems try to undermine application and organizational defenses in unique and unexpected ways, so it’s best to be open to what could potentially be considered a threat to your program or application. It’s important to take into consideration how someone would approach this:
“How would I bypass a VPN connection?”
“Can I substitute a Man in The Middle attack in lieu of brute forcing the authentication?”
“Is it easier to take the XKCD approach to cracking the RSA encryption or to limit exposure?”
These are examples of the types of tactics that the team can consider when addressing possible threat scenarios. Once you have those tactics identified, you can establish your goals, such as this example for a threat model focused on adopting Splunk:
| Primary goal | Secondary goal |
|---|---|
| Understand the risks of introducing Splunk into our application ecosystem | Identify any migration strategies we have in place for the aforementioned threats |
Ultimately, these should be the key focus point of a useful threat model. You should approach the scenario with a specific objective in mind, based on concerns for an implementation of a new device, practice, or even reviewing other mechanisms within your systems network diagram. You describe what specifically your primary goal is, to ensure that the threat model approaches topics and scenarios relevant to that goal. The secondary goal is often overlooked by the review of the primary, however, having a secondary goal can benefit product owners and project leads by allowing them to combine multiple threat model objectives within a simple engagement
4. Identify threats
The threat identification is our “ad hoc” way of performing an impromptu, but specific, risk assessment and mitigation strategy on a scenario. Identification is further branched out into 5 different categories, with 3 rating subcategories for assigning a risk rating.
- Scenario
- Mitigation
- Capabilities
- Ratings (Likelihood / Impact / Risk)
- Action items
In this case, the scenario is the vulnerability, weakness, or given situation that would cause concern for the program or application within a set framework. The mitigation tactics are what preventive measures we have to ensure that the scenario does not become a reality, and we follow with identification of what preventive measures we would need to have in place to confront this scenario. Capabilities describe the ability and the capacity of the team to ensure that the possible mitigation tactics can be implemented if they are not already in place.
The ratings part is done via a value assessment given to both the impact and risk, then multiplied together. We use 1-4 as a standard range, however, you can use a different scale, depending on how specific you want to be in defining your priorities.
From here, we can prioritize the ranking and severity of the issues by the values we’ve attributed to them, and thus prioritize our work, starting with the highest-ranked issues. Oftentimes, there are further associations to be included within the parameters of impacts not associated with the application, such as risks to business continuity or reputational risks to business development and product management.
And finally, there are the associated action items related to the identified threat. The associated action items vary in size. Some can be as simple as a document update, and others can be as massive as an infrastructure rebuild. However, the key takeaway is something has come out of the identification and mitigation of the specific threat. The mitigation techniques applied to the model have given rise to a follow-up, which will decrease the threat surface of the scenario.
A closer look at identifying threats
Threats will be modeled using the fields indicated below. We identify a scenario, discuss mitigation tactics, evaluate our system’s capabilities to execute those mitigation tactics, and weight the likelihood and impact of those scenarios.
| Scenarios | Mitigation tactics | Capability status | Likelihood rating | Impact rating | Risk rating | Action items |
|---|---|---|---|---|---|---|
| A description of the possible vulnerability, issue, or problem | How might we mitigate the risk associated with the scenario described? | Is our system currently capable of supporting the suggested mitigation tactic? | Rate from 1 to 4 | Rate from 1 to 4 | Calculate using formula Likelihood * Impact = Risk rating | If the system is not currently capable of performing the mitigation tactics, document steps to enable those capabilities. |
| Supply chain attack from 3rd party IT vendor pushing operating system updates | Incorporate 3rd party auditing and Endpoint Protection. Testing any updates in a test environment prior to production deployment | We currently have Endpoint Protection enabled | 3 | 4 | 12 | Establish 3rd party auditing, set up testing environment |
Likelihood rating
How likely is it that this scenario will occur? Estimate on a scale of 1 to 4.
1 = Extremely unlikely that this could happen
2 = Somewhat unlikely that this could happen
3 = Somewhat likely that this could happen
4 = Extremely likely that this could happen
Impact rating
If mitigation tactics fail, what is the impact to the system? Depending on the scenario, what damage could this cause to the product, users, or system overall? Estimate on a scale of 1 to 4.
1 = Zero impact
2 = Minimal impact
3 = Significant impact
4 = Catastrophic impact
Risk rating
Measured by using the formula Likelihood * Impact = Risk rating
• If the likelihood has a lower rating (e.g. 1), it will negate the impact rating to automatically equal 1.
• A risk rating of 6 is a threat worthy of scrutiny.
• A risk rating above 8 is a threat that must be addressed.
Securing government services
Ultimately, Ad Hoc’s threat modeling process is a mix of the STRIDE framework with the inclusion of some of the exploitation techniques from the ATT&CK framework. This mix comes from our idea of what constitutes an active security mindset. Threat modeling is not end-all-be-all tooling, but merely one of the many security tooling resources available to people within your organization. The acknowledgment of what risks are posed to the system in question is not only a good security practice, but it’s one of the subsets of the Risk Management family within NIST 800-37, ensuring that our processes meet security best practices and set a pace for further improvement.
Threat modeling provides an insight into how your applications can operate and respond to malicious threats. For our customers within the federal government, that means ensuring the protection of sensitive information and ensuring that government services are available for use when the public needs them.
