Threat Modeling Basics
What is Threat Modeling?
In many ways, software developers overlook threat modeling rendering it an unnecessary piece of the SDLC puzzle. Yes, organizations choose to wait until the application is finished to test their security. As experts, we know this type of response can become a costly mistake. Also, this cybersecurity exercise can be completed as deemed appropriate by the security team.
At Praetorian Secure, we like to create a standardized schedule for testing and modeling. The most important thing to remember with threat modeling is that it uses a systematic and structured approach.
A threat model gives a visual representation of the information that affects the security of your applications. We use it to capture, organize, and analyze all the information gathered including threats, weaknesses, and attack vectors. In essence, if you take a process flow diagram and view it through a security lens you get threat modeling. Also, it allows us to make a better decision about our application’s security risks. Typically, threat modeling is broken into two key factors:
- Business Assets – including organizational, employee, customer data, and human assets.
- Threat agents/actors – the person, actor, entity, or organization that is initiating the given scenario.
Praetorian Secure uses a combination of threat modeling techniques that allows our clients the ability to become better prepared against vulnerabilities early in the software development lifecycle (SDLC). Proper modeling can enable your organization to quickly identify threats, attacks, and vulnerabilities, and then implement countermeasures.
Being open-minded when creating your “threat scenarios” will lead to a rapid increase in overall security posture in a shorter timeframe while also accelerating your application’s success rate. You can use threat modeling to structure your application’s design from the ground up, meet security objectives, and reduce overall risk.
Objectives of Threat Modeling
The main objective of threat modeling is simple, prevent all threats from taking advantage of the system flaws in an application. Undoubtedly, users can accomplish this by performing modeling in the early stages of the development lifecycle. Having a standardized schedule is best.
During threat modeling, the objective is to provides clarity on the organization’s risk appetite and prioritization. This includes, which assets are more important than others? Which threat communities are more relevant than other threat communities?
Another key aspect of threat modeling is that the team can use similar tools and methods to “think” like an attacker. The threat model should be constructed by the security team in harmony with the other testing efforts. Testing should continue as frequently as needed.
Clearly documenting and defining a threat model is important. All technical findings will be addressed in the report and will reference the threat model to create a more accurate risk score that is specific to your organization.
Importance of Threat Modeling in SDLC
Threat modeling, similar to DevSecOps, is best applied continuously throughout the software development lifecycle. It is important to realize that you will end up finding new threats as you progress. This is not a bad thing, it is exactly what we want, to discover all threats in the software before it is released. For example, if you choose to code your application in C++ or Java you take on the vulnerabilities that come with it. To elaborate, the source code type you choose will inherently have its own risk. Especially, when a deprecated syntax is used and secure coding practices are not followed.
The threat modeling process is the same at various levels of the exercise. Ideally, a high-level model should be defined in the concept or planning phase, and then refined throughout the lifecycle. Keep in mind, the information will start simple and then becomes more granular throughout the lifecycle. Over time information and details are added to the system, new attack vectors are then created and discovered. Finally, countermeasures are implemented, and the process is repeated as needed. This ongoing threat modeling process is important for the SDLC and should examine, diagnose, and address your threats while reducing expenses of development in the long run. Software development is not a sprint, it is a marathon.
Threat Modeling General process
Following is the general process for threat modeling:
- Defining security requirements (scope).
- Create a process flow or data flow diagram of the application.
- Identify all threats and bad actors via attack tree.
- Review and rank threats – decide which are exploitable – high/medium/low risk.
- Mitigate the identified threats.
- Validate that all threats have been identified and mitigated correctly.
4 question framework to help understand threat modeling objectives:
- What are we working on?
- What can go wrong?
- How can we deal with it?
- Did we do a good job?
Various Types of Threat Models
- PASTA – Stands for Process for Attack Simulation and Threat Analysis. It is an application threat modeling methodology that uses a risk-based approach developed in 2012. PASTA is the most difficult to prepare but best documentation when completed.
- STRIDE – Developed in the late 90s by Microsoft. STRIDE Stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of privileges.
- CVSS – captures principal characteristics of a vulnerability and produces a numerical severity score. Also, CVSS was developed by NIST, and v3.1 was released in Jan. 2019.
- Attack Trees – one of the oldest and widely used techniques developed in the 90s. It allows threat modelers to see what events must come together for a threat to be successful.
- Trike – Trike is a framework accompanied by an open-source tool that runs from a defending viewpoint rather than trying to emulate the thought process of an attacker. Uses CRUD. This stands for: create, read, update, or delete.
- DREAD – Add-on to STRIDE. Allows you to rank vulnerabilities once identified. Stands for: Damage potential? Reproducibility? Exploitability? Affected users? Discoverability?
- OCTAVE – Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE®). An approach for managing information security risks. This threat modeling methodology focuses on organizational risks rather than technological risks. There are three phases:
- Construct threat profiles for all assets
- Identify vulnerabilities in current infrastructure
- Make your cybersecurity strategy and plan come to life
- NIST – The U.S. National Institute of Standards and Technology has its own data-centric threat modeling methodology, which consists of four steps:
- Identify and describe the system and data of interest
- Detect and select the attack vectors to be included in the model
- Characterize security controls for mitigating the attack vectors
- Analyze the threat model
Understanding the application
Everything begins with defining the scope. Identifying the use case, key assets, and external connections/devices are necessary when creating your assessment scope or rules of engagement (ROE). The ROE will define everything about the project such as timeframe, testing objectives, etc.
Identify the Trust Zones, Motivations, & Threat Agents
Identifying trust zones, motivations, and threat agents as quickly as possible is crucial. Any point in the data flow where the data must be validated before it can be used by the entity receiving it is considered a trust zone or trust boundary. These connection verification points are the main door to your organization’s network. Next comes motivations these are the reason why someone would target your organization. Finally, target all means, motives, and all angles of attack to reduced threat agents.
Define Exploitable Vulnerabilities & Prioritize Risks
Once you understand the security in the application, you can then analyze for new vulnerabilities. The search is on for vulnerabilities that connect these possible attacks to negative outcomes you have identified while searching for threats. Prioritization is everything in threat modeling, as there are always lots of risks that simply do not rate any attention. For each threat, you estimate several likelihood and impact factors to determine an overall risk or severity level.
Identify Countermeasures to Reduce Threats
The last step is to identify countermeasures to reduce the risk to acceptable levels. Rinse and repeat the process. But seriously, it is not that complex. Each time around will be a little bit different learning how to be more precise with time.
Benefits of Threat Modeling – When Done Correctly
The benefits of threat modeling are immense, but only when done correctly. This exercise can become a large waste of time and effort done incorrectly. To avoid this, you should always plan out your effort in advance before crashing in. Having a clear picture of the threat landscape makes it easier to defend against your adversaries. In other words, it offers a clear-cut “line of sight” across any project and validates spending and security efforts. A company can measure the security of an application using the threat modeling process and an assurance argument. An assurance argument starts with a few high-level claims and justifies them with either sub-claims or evidence.
- Starting at the wrong time – it is good to start early, but first, analyze your risk internally then consult with a professional.
- Forgetting to document during the process – always document from the very beginning.
- There is a right vs. wrong way to pick a threat model – this is false, there is just an effective and less effective way to use it.
- “Thinking like an attacker”– this is subjective, instead ask these questions in an objective, methodical way to identify real problems.
- Threat modeling is all about identifying threats – not entirely, it is also about implementing proper countermeasures before they can be exploited.
Fruhlinger, Josh. “Threat Modeling Explained: A Process for Anticipating Cyber Attacks.” CSO Online. CSO, 15 Apr. 2020.
N/A. “Getting Started – Microsoft Threat Modeling Tool – Azure.” Getting Started – Microsoft Threat Modeling Tool – Azure | Microsoft Docs.
N/A. “Threat Modeling Cheat Sheet.” OWASP Cheat Sheet Series.
N/A. “Threat Modeling.” OWASP. Web. 03 Mar. 2021.
Shevchenko, Nataliya. “Threat Modeling: 12 Available Methods.” Threat Modeling: 12 Available Methods. 03 Dec. 2018.
“Threat Modeling.” Pentest-Standard.org.