Threat Modeling 101

Threat Modeling Basics 101

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

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.

 

Common Mistakes

---

 

1. Starting at the wrong time – it is good to start early, but first, analyze your risk internally then consult with a professional.
2. Forgetting to document during the process – always document from the very beginning.
3. 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.
4. “Thinking like an attacker”– this is subjective, instead ask these questions in an objective, methodical way to identify real problems.
5. Threat modeling is all about identifying threats – not entirely, it is also about implementing proper countermeasures before they can be exploited.