The Open Web Application Security Project (OWASP) describes threat modeling as a structured approach for identifying, quantifying and addressing the security risks associated with an application. It essentially involves thinking strategically about threats when building or deploying a system so proper controls for preventing or mitigating threats can be implemented earlier in the application lifecycle.
Threat modeling as a concept certainly isn't new, but few organizations have implemented it in a meaningful way. Best practices for threat models are still emerging says Archie Agarwal, founder and CEO of ThreatModeler Software. "The biggest problem is a lack of understanding of what threat modeling is all about," he says. There are multiple ways to do threat modeling and companies often can run into trouble figuring out how to look at it as a process and how to scale it. "There is still a lack of clarity around the whole thing."
Here, according to Agarwal and others, are seven mistakes you are likely making when doing threat modeling:
1. Being too application centric
One of the most common mistakes that organizations make when building a threat model is to focus only on the application itself, Agarwal says. With threat modeling you should try to understand the overall landscape and not just a single application in isolation, he says.
Consider the infrastructure, the database, shared components, third-party interactions and the deployment environment. Threats can vary based on whether an application is on-premises or is running in the cloud or can be accessed by mobile devices and other computing endpoints.
If you are moving to the cloud, you need a threat model for the cloud. Will your applications and data run on a dedicated infrastructure or shared servers and databases? It's critical to remember that when threat modeling, you need to look not just at the application but everything that touches it, Agarwal says. Developers need to think about some fixes when building an application and the operations they need to handle when the application is deployed.
2. Focusing on the vulnerabilities and not the threats
One mistake organizations can make is to focus too much on the vulnerabilities and not enough on threats, says Pete Lindstrom, an analyst with IDC. It's certainly important to look at your data flow and control flow and know what vulnerabilities might exist in your apps. In addition, you need to look at threats more explicitly and identify inputs and output where you might be at risk. You need to think about all the opportunities for an attacker to thwart your controls to affect the confidentiality, integrity, availability, productivity, and the proprietary nature of your data.
"Right now we are talking about Meltdown and Spectre being attacks against confidentiality," Lindstrom says. "But what about integrity or availability? Are there ways for attackers to manipulate those memory tables or insert data?" Just because you have controls against a specific exploit doesn't mean an attacker won't find new ways of taking advantage of a flaw.
3. Focusing too much on the threat of the day
Don't rush after the latest threats or pay too much attention to specific threat actors or types of actors when building threat models, says John Pescatore, director of emerging security trends at the SANS Institute. Ransomware and cryptomining software might present the biggest current threats to your security. Rather than modeling specifically against these threats, focus instead on controls for mitigating any threat to the confidentiality, integrity and availability of your systems.
Similarly, it doesn't really matter if the threats against you are coming from Chinese, Russian, or Serbian actors, Pescatore says. The focus on attribution and state-sponsored hackers and criminal gangs is less important that knowing how to protect against the threats they represent. "Being told that Chinese actors are coming after you is less important than knowing what to do about it."
Your focus should be on building repeatable processes so every time something changes you are prepared for it. The key is having a standard process or methodology that is done the same way each way time, regardless of the newness of a threat. You need to know what it is you are trying to protect and begin from there, Pescatore says.
4. Mistaking threat mapping for threat modeling
If your idea of building a threat model is working off a list of threats and seeing if your app has any of them, all you are doing is threat mapping, Agarwal says. "Let's say you have an online banking application and you ask a set of questions like 'are you using Flash?' or 'are you using Java?' or 'are you doing authentication?'," Agarwal says. What you are doing here is not threat modeling because you really have no context around the threats. You don't know how you are using Flash or where you are using it.
Similarly, just because you have a database doesn't automatically mean you have to worry about SQL injection as an attack vector. SQL injection becomes a potential concern only if you also have a web app that accepts input from an external source. This kind of nuance is easy to miss when you take a checklist approach to assessing threats, Agarwal says.
To build a proper threat model, an architecture diagram is critical. It should show you the database, the web server, the operating system layer, and the infrastructure on which the app will be running and through which it is accessed. It should show where all the data and the communication are flowing, where the entry points are, and what sort of input is coming from those entry points. An architecture diagram shows you the big picture and also the edge cases, Agarwal says.
5. Not bringing the user into the threat model
There's such a thing as focusing too much on how an adversary might attack your code and not enough on other ways they can get at your applications and data. "It's a really good idea to threat model how bad guys attack code," Pescatore says. "But protection against a phishing attack is not something you can build into the application."
You need to bring the user into the threat model and consider the different ways that user actions can impact security. You need to look at things like privilege management and roles based access. You need to consider potential threats when users access the application in the cloud or via a mobile app that might be part of a bigger e-commerce scheme, Pescatore said.
6. Taking a once and done approach to threat modeling
A threat model cannot be static. You can't take a critical application, do a threat model on it once, and assume you are done, Agarwal cautions. If your organization is like most, continuous development activity is going on. As your application changes, its threat profile does as well. That means your current threat model will be obsolete in three months. "Your threat model should be a living document," Agarwal says. "You cannot just build a threat model and forget about it. Your applications are alive."
7. Not taking into account how your systems impact others
When building a threat model it's a good idea to consider how digitally trustworthy you are. Once you have accounted for all the threats you face and figured out controls or mitigations for them, look at how your organization's systems might potentially impact others that come in touch with them.
You need to pay attention to how your outputs might affect the security posture of others, Lindstrom says. "You could, for example, be housing a black market site or someone could be squatting on your domains or bouncing DDoS packets off your IoT systems." You might not accept ad blockers, but what happens if a malicious ad on your site infects customer systems? As you put stuff online, it's your responsibility for keeping them clean so downstream uses don't get impacted from using your systems. Such diligence needs to be part of your threat modeling, both from a digital trustworthiness and liability standpoint, Lindstrom says.
As part of the threat modeling exercise, make sure you understand the risks associated with open source software and third-party components, not just to your organization but downstream users of your services as well. If you are offering mashups for instance, you need to be thinking about how your data or services might impact some one else's outputs. "If someone else is relying on GPS data coming from you, you need to be thinking about the integrity and reliability of that data," Lindstrom notes.