It involves accurately mapping the component parts of the application or system, along with their roles and functions, and uncovering potential threats based on various factors such as protocols used, environment and data sensitivity.
One key aspect to threat modeling is that it is a process not a project. It’s easy to think of threat modeling as a project with a beginning, middle and end. Identify threats during the design phase, mitigate them and move on. But in a world where applications are continuously deployed in ever-changing cloud environments, threat modeling must become an ongoing process for it to be effective.
It’s natural to assume that threat modeling applies to applications residing in the cloud. And while that’s mostly true, threat modeling applies to many more systems, most of which do not reside in the cloud, but represent an even greater threat target.
Threat modeling is important because there are at-risk systems whose failure could be catastrophic. A sampling of those systems include the following:
Threat modeling is also important because it identifies more than just security threats. It can also be used to identify compliance threats. Threats, that if realized, could prove just as costly to an organization, in terms of fines, as a security breach.
In practice, the scope of threat modeling encompasses more than might be inferred from the definition above. That’s because threat modeling is not done in isolation. Rather it’s done by taking a holistic view of the organization.
In addition to application threats, threat modeling considers business threats, asset threats and infrastructure problems. And it does more than just address threats and problems.
Threat modeling includes defining security requirements and test cases; producing Center for Internet Security (CIS) benchmarks; conducting risk assessments; and analyzing regulatory compliance.
Thorough threat modeling also attempts to answer business questions like the following:
A threat is also referred to as a threat agent or adversary. It is either a person or code operating on behalf of a person. For it to be a threat, it must harbor ill will toward your organization, have the capability to execute on it and have the motivation to do so.
As alluded to previously, the purpose of threat modeling is more than just to model threats. As a way of simplifying, you can picture threat modeling as a Venn diagram of two overlapping circles: assets you care about and assets threat agents care about.
The purpose of threat modeling is to identify the overlap of those two circles. Then prioritize it and then protect it from threat agents. Of utmost urgency are those assets in the overlap area that represent the doomsday scenarios your business fears.
For threat modeling to be truly effective, it cannot be done as an afterthought, or in an ad hoc or unplanned manner. Threat modeling must bring a discipline to identifying and assessing application threats and vulnerabilities.
When done properly, threat modeling’s role is to provide a systematic and repeatable way to ensure you’re both thorough in modeling the attacks, as well as focusing on the attacks that matter most. In general, this level of analysis cannot be achieved by simply checking off items in a list. Instead, you must look to attain visibility into attack surface entry points, exploit chains and vulnerable assets. There are tools available today that make this exercise easier.
There is a fundamental paradigm of when to update a threat model: whenever anything changes. That includes both technologically and business-wise. So, unless your organization and applications are frozen, threat modeling is going to be more or less a continuous activity.
But continuous doesn’t mean periodic. With most development today predicated on agile methodologies, and multiple releases per day not uncommon, continuous threat modeling means exactly that. Real-time and near-real time updates to your threat models are not only required, they are essential.
Here are some examples of when to update a threat model:
You can threat model an organization. You can threat model a portfolio of applications. You can threat model a single application and you can even threat model a chunk of code. Effective threat modeling requires that you apply the same risk methodology, consistently, at any of those levels.
One of the benefits of a consistent threat modeling process is that it helps you decide where to spend your time in the organization modeling threats. More importantly, which applications to start with.
You already know you should be threat modeling continuously throughout the lifecycle. You should also be refining those threat models as you go as well. An accurate threat model from ten iterations back, probably is accurate any more.
As an application evolves, it is important for you to focus on the elements of the threat model that are impacted by that evolution. In other words, focus on the change.
How you define a threat agent depends a great deal on your organization, as the definition tends to be organization specific. The types of threat agents depend on their motivation and who is sponsoring them. As a simplification, there are four categories of threat agents:
Understanding the different threat agents is an important first step in adopting the perspective of a hacker.
More than just a tool, and even more than a process, threat modeling is discipline that can be developed throughout an organization. The discipline comprises several unique and specific skills. And one of the most important is learning to think like a malicious hacker.
As mentioned previously regarding the purpose of threat modeling, the overlap of the Venn diagram includes those assets malicious hackers care about. And what are assets hackers care about? It depends on the threat agent. For number one and two in the list above, it’s money and things that can be easily exchanged for money.
So, to adopt the perspective of a hacker, you must learn to ask empowering questions. Questions like, if I were organized crime, what assets does my organization possess that is money or can be exchanged for money easily?
For threat modeling to be successful, you must address impacts to the technology side as well as the business side. After all, not all threats are technical in nature (e.g., social engineering).
Analyzing the business risk of software architecture is an essential element in prioritizing mitigations. For example, suppose some system is vulnerable, but only makes publicly available information vulnerable. In that case, the technological risk may be high, but the business risk is small, so prioritize mitigations accordingly. Bottom line? All threats must be analyzed within the context of the business.
To fully understand the threats to a system, process or application, you must do threat modeling as early as possible in the software development lifecycle (SDLC) to ensure that threats are identified and mitigated appropriately. When you do threat modeling earlier in the life cycle, security issues are less expensive to resolve and less likely to delay a project.
Here is 10-step, high-level overview for developers to perform threat modeling:
Several advantages accrue when you develop a company-wide threat modeling discipline. One of the most important is that it standardizes security across all applications and systems in the enterprise. Furthermore, it reduces the burden and expense of having to make risk models from scratch and repeated calculations.
Threats are commonly due to design flaws In essence, it is the design flaw that allows the attack to occur. So, one byproduct of threat modeling is spotting some design flaws. Of course some threats are the result of a lack of attention to detail. Those types of threats don’t do much in the way of finding design flaws.
Threat modeling works best when a commitment to threat modeling permeates the entire team, not just the security folks. The idea is to create an inclusive security culture. One that exists on a collaborative platform that makes interacting seamless.
With this commitment, threat modeling happens in a repeatable process. It’s done on all applications and systems. It’s integrated right into the DevOps process and made part of all cloud transformation initiatives.
Threat modeling must be done at the portfolio level to define the scope and depth of analysis. You start by asking one question: How much security work is required? And the answer is, it depends on how capable your adversaries are and how valuable your assets are.
Those answers help you define the scope and depth of the analysis required. If your adversary is a lone wolf hacker, that requires a different scope and depth of analysis than if your adversary is a nation state. The end goal is knowing when you can stop threat modeling.
One of the real benefits of threat modeling is that it can produce a visual depiction of your system and the threats it faces. Threat diagrams make it easier to understand the threats as well as collaborate with team members.
It’s important when doing threat modeling to do more than just fill out a checklist. It’s a best practice to create a visual understanding of the system, and there are a few different ways to do that.
When gaining a visual understanding of the system, it’s a best practice to include modeling the attack possibilities. You don’t truly understand your adversaries until you can model all of the different ways they can attack your system.
An essential part of threat modeling is to create a threat traceability matrix. In the matrix, each row is a unique threat and the columns are as follows:
One of the important things to come out of creating the threat traceability matrix are the blank cells. Blanks cells represent unknowns in your threat model which need to be addressed.
The idea behind checklists is that you start with a roadmap when looking for threats. The goal is to be able to answer questions like the following:
Checklists are, by definition, incomplete because they fail to consider who and how, and also fail to prioritize assets.
One of the first of these checklists is STRIDE . STRIDE is a mnemonic for six threat categories, each of which if violated, represents a potential threat:
T ampering
R epudiation
I nformation disclosure
D enial of service
E levation of privileges
ASVS , or Application Verification Security Standard, is a project by OWASP (Open Worldwide Application Security Project) which provides a basis for testing web application technical security controls. The AVSV reference can be used as a metric, as guidance for developers and during procurement.
OWASP Top 10
According to their own website , The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications.
Essentially, the OWASP Top 10 is a checklist of the top 10 security categories which threaten web applications at any point in time. The list is continually updated as threats change. Since they are the most pervasive threats, the list represents a good starting point for checking off threats and mitigations in an application.
The non-checklist based approaches are all predicated on taking a different view of the threat landscape. There are attack centric approaches that consider the threat landscape from the attackers point of view.
There are asset centric approaches which start by looking at which assets are valuable and which are vulnerable. There are also software centric approaches which attempt to analyze the software in detail and look for vulnerabilities in the application design and in the code.
One non-checklist based approach which supports enterprise-wide scalability is VAST . VAST is a mnemonic that stands for Visual, Agile, Simple Threat modeling. The VAST methodology is unique because it is founded on the idea that threat modeling is only useful if it encircles the entire software development life cycle (SDLC), throughout the whole enterprise.
Which non-checklist approach is the right one? They can all be the right one, as long as they force you to think through all your security threats.
Synopsis is a leading provider of electronic design automation solutions and services. One of their services is to provide threat modeling. They have developed a three-step high-level approach to analyzing threats:
