What is it and why should I care?
After the last post covering secure the concept of a secure SDLC, this week we’ll look at a specific activity recommended by the various secure SDLC models: threat modeling. From the view of the secure SDLC, this is an activity that takes place fairly early in the cycle.
Threat modeling is an exercise intended to improve the security of your application(s) by considering the attacks that a threat can perform against your specific application. That data is then used to inform the development of controls and tests to verify the prevention of those attack vectors.
There are various components in the above definition that will be discussed below. However, given the short post, I’d like to make a “further reading/watching” suggestion up front. If you’re interested in the topic, please go look at the resources. I even included an excellent video of jOHN Steven talking about threat modeling. It’s worth an hour as it’s a good overview. jOHN is an expert on threat modeling and has a wealth of experience in making it useful and practical – his wisdom has certainly heavily influenced my own views on the topic.
What should I do about it?
A few initial caveats:
- This is fairly thin coverage of threat modeling as it is a complex process. Many complete books have been written on the topic.
- There are various models of threat modeling. I am attempting to portray the basic process only. You should use the model that most closely aligns with your organizational needs and then further tailor it to your specific environment.
- Along with various models, there is a wide array of terminology used to describe various components in threat modeling. A good example I like is the work Cigital has done on producing a useful vocabulary.
With those initial points out of the way, what do you actually do when threat modeling? Here are a few steps:
1. Identify what you want to protect
This should already be understood in your organization, but I mention it as a predecessor because writing down what is important can be a useful activity. One stakeholder won’t often have all the information, and this process is really helpful to get everyone on the same page from the get-go. It also helps you determine what’s worth protecting. This process should involve assigning a specific (or at least relative) value to your assets in order to determine priority.
2. Consider your application
Look at what you want to build, are building, or have built (depending on where you are in the life of the application) and make a picture of that (pictures are pretty and easier to understand). Do NOT use a network architecture diagram (too generic) or a set of UML class diagrams (too specific). My personal rule of thumb (informed by work of others) is that your picture should have 2 basic criteria. It should be specific to this application (the diagram of 2 similar apps in your portfolio should still have different components and therefore look somewhat different), and it should all fit onto 1 page in reasonably readable form (helps keep complexity at the right level). This diagram is not the only one that will exist. You can layer additional data on top of it with different views or you can expand certain subsections for more data, but there should be a single-page overall view. This view should include application-specific information, such as the software components along with design patterns used, frameworks used, etc.
3. Add more views
In addition to the basic view of your system, you’ll want to start to annotate your view with additional information. You can add data like:
- entry points: Think about areas of your application that can be invoked externally. These are important in that they provide attack surface so should be carefully considered.
- trust boundaries: These are areas where you make a decision about levels of trust granted to a given component. See the jOHN Steven video for an example of how trust boundaries aren’t necessarily so cleancut.
- data flow: Consider how information flows through your system. Are there areas where data can flow in different paths depending on conditions such as role or other context? Think these through and map them out.
- critical functionality: The parts of the application that are most important deserve a look and some thinking about how they are different. Are there actually controls in place that make them different. Should there be?
4. Consider the attackers
We need to think about who is attempting to attack the application. Is a curious user the same as an insider in the types of attacks they can launch. What about an angry customer versus an angry employee or a customer that is not familiar with computers at all? They could all do things to attack the application, but they’ll come in different forms and may require different controls. In this phase, you can build a simple spreadsheet to keep track of the different users, or try attack graphs or even attack trees. These vary in complexity and usefulness. The idea here is to give sufficient thought to the types of attackers you could encounter, determine which of those you care about, and then think about how those specific attackers may attempt to attack your application (specific attack vectors).
5. Rate the issues
Given the specific components of the application (what) and the attackers (who) and their attack vectors (how), we should have a decent picture of our threat environment, assuming we did a good job on the previous activities. At this point, we need to decide which threat scenarios (who attacking what how) we care about and how much. This prioritization process will rank issues for the next step.
6. Resolve the issues
Now we need to do something with this data that we’ve worked so hard to produce. Once we know the specific issues we care about preventing and which ones are most important, we go through the process of resolving them. I find I go through a few simple steps naturally.
- reduce attack surface: Are there things that can be resolved by removing unnecessary functionality or architecture from the application? There are tradeoffs here, but simplicity is your friend in security, and I try to look for this ways to apply this solution relentlessly.
- design around them: Can you build your system in a different way that doesn’t require that specific technique. Are there alternative technologies or solutions that don’t suffer that weakness? There is again a tradeoff here, as you’ll need to reconsider your threat model in light of your given design alternative .
- find controls: If I can find quality reusable solutions, I use them. There are obvious benefits to reuse.
- build controls: If I can’t find something that already does the job, I go the route of building something to handle the issue. When I do that, I also try to make it reusable.
- build tests: The threat modeling process should be a drive for test cases, just as requirements would. An additional benefit to doing this task as part of the process is that you can use a traceability matrix to tie the threat/attack vector to a test case, and show that it’s covered.
Threat modeling is an activity that, if done, is usually done once at the beginning of the project and not again. This should not be the case. Practically, I don’t think you need to re-evaluate it for every development sprint, but you should re-evaluate it periodically. I generally recommend that you revisit the threat model in earnest when you hit a specific trigger (new attack, incident, operations data on attack scenarios, new assets, change in personnel) and on a periodic timed basis (3m, 6m, 1y).
The coverage I have given to threat modeling is admittedly basic, but should hit the high points well enough. This is an extremely useful security process that adds value, but is often not done because either 1) people don’t know how to do it or 2) people think it’s too heavyweight. Reason 1 is an education issue, and is easy enough to remedy for those who are interested. Reason 2 goes away in part with education, but also realize you should customize the process to your environment, which can save you time (certain threat actors may be of no concern to you, eg.) Also consider that we all generally build similar things for the most part (web, mobile, desktop) – our threat models often have similar or common components. We can build reuse across applications, internal groups, and even across organizations. There are publically available threat models (some better than others) for common application models that you can use as a starting point. From there, reuse what you can from app to app to save time.
In conclusion, threat modeling is a very useful exercise to evaluate and improve the security of your application. By considering your application and the threats against it, you can have a better understanding of how to effectively design the security of your system.
jOHN Steven’s threat modeling talk