I feel that it is important to lay the foundation of a topic before digging into the details. With that in mind, I’ve chosen to introduce threat modeling at the first part of this series. Threat modeling is still a skill I am mastering, so I’m sure new and inexperienced developers likely don’t really know what it is unless they have some security background. That is why it’s important to understand how to use it to increase your application’s security posture.
What is threat modeling?
According to Wikipedia, threat modeling is “the process by which potential threats can be identified, enumerated, and prioritized – all from a hypothetical attacker’s point of view.” Threat modeling is an important piece of a secure development lifecycle. It should be done at the beginning of the project when the overall architecture is being designed as well as when there are any major changes or additions to the architecture by enhancements to the product. It provides a solid baseline from which to plan and prioritize how you will mitigate the threats and possible vulnerabilities that we will be discussing in more detail later in this series.
Enough definitions though. Let’s move on to how to do it.
Identify Security Objectives
The first step in the threat modeling process is to identify security objectives. These can come from legal requirements, regulatory requirements, or existing standards and security standards of your company. What is relevant here will change depending on the nature of the application you are building.
Another important piece of this is to make sure that there is a justification for the data being stored by the business and what its purpose is. The development team alone may not have all of this information, so bring in help from outside the team when necessary. Ultimately, you want a list of security objectives that will provide a security “vision” for the application based on any known legal and security requirements by which this application must abide per your company.
With the objectives in hand, the decomposition process begins by creating a design and requirements based on the objectives that were identified in step one. This can be done in many ways. UML is one way, but I won’t drag you through that nightmare here. Instead, I’ll introduce you to the data flow diagram (DFD).
The DFD, as you can probably tell from the name, documents the flow of data through the application. This allows you to understand all of the processes, data stores, and data flows between elements. We all know that enterprise systems (and even “small”) systems can have many parts. I am currently wrapping up a project that is considered small by most standards but still has data moving between four different technologies on different machines. Large systems can easily have complex data flows. In large systems, breaking up the DFD into smaller chunks using use cases can help.
Let’s look at an example DFD for a car dealership’s inventory system. I ask that you remember that this is for illustration purposes, and I may be off on the details of what a real system such as this would be like, so bear with me. Take a look at the DFD for our example system. It covers a customer placing an online order as well as a sales executive entering a sale into the system at the dealership.
I think you get the idea. This follows the flow of data around the system during its normal operation.This could even be split up into use cases and you could follow the data from one end of the use case to the other.
Why is this important? Most of the time, data is main thing a hacker is looking for when compromising an application. You need to understand what data is stored, where it is stored, and how it is stored in order to protect it properly.
The next step, once you understand how data flows through your application, is to identify the specific threats that your application may face. There are several different types of threat modeling frameworks in use. Covering them all in detail is out of scope for an introduction such as this, but I will introduce one that is in wide use for illustration purposes, called STRIDE.
STRIDE was actually developed within Microsoft. It stands for Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Escalation of privilege. This handy little acronym will allow you analyze your application and think of threats against which you need to defend. In combination with your DFD and architecture diagram, you can step through a process and see what threats of these varieties may come into play. If you are unfamiliar with the terms used in STRIDE, such as Spoofing, you can use the below table to map the STRIDE term with security property that you may be more familiar with:
|Denial of Service||Availability|
|Elevation of Privilege||Authorization|
(Source: CSSLP All-in-One Exam Guide)
Let’s use our car dealership example from above. Let’s say that the main architecture is a standard MVC based, n-tier web application. For the purposes of this exercise, the specific technology used doesn’t really matter. Let’s say it looks like this:
Using this we can follow a request through each piece of the application and use STRIDE to identify possible threats. Let’s examine the first step in an order of a car by a customer and see where threats may lay in waiting.
This is just one piece of the scenario: a user entering login credentials (or maybe registering for access). This gives you an idea of how to apply the STRIDE acronym to your application. Here we see both spoofing and information disclosure threats appearing in the form of CSRF and SQL injection. As you walk through the various pieces of the application, you can continue to do this analysis to build up a good set of threats that you can defend against from the start of your project.
Remember, these are only threats to your application, not vulnerabilities in your code, and not all threats will be applicable to all systems. Also, it is impossible to know every threat to a system. While it is preferable to do this process before code it written, it is possible to do this after the fact. In that case, you can prioritize the most serious threats for immediate remediation and work the others into your backlog.
Next, a tool called an attack tree can be used to break down a threat from the attacker’s perspective. Let’s look at an attack tree for the SQL injection threat identified above:
This is a nice way to visualize in more detail what specific conditions need to be present in order for an attack to succeed. This will directly influence what security controls need to be put into place in order to protect against the threat. My next post in this series will detail SQL injection and what controls will help prevent it. However, you likely have a good idea of what is needed to protect against it from this attack tree, namely that you need to validate input and not concatenate said input to create SQL statements.
These pieces can all be combined to create the threat model. The threat model is a living document that will change throughout the length of the project. You should update it when new functionality is created to identify any new threats that may be introduced by that new functionality. It should also be reviewed by many eyes to help ensure as many threats are identified as possible.
Developers of all levels of experience need to take security seriously. With these tools in hand, building security into an application can become much simpler for all developers. Make good use of these tools to help protect your company and your customers!