Knowing Risks and Mitigations

Welcome back to the series of articles on how to be a better Threat Modeler.

As discussed in the previous article, a good Threat Modeler must have the following three capabilities:

• Good knowledge of common security risks and mitigations
• The ability to recognize threats to both the Infrastructure and Applications, and a good understanding of the various approaches to mitigate them by applying the best of both worlds (in other words, the application of a holistic approach)
• A critical mindset, never assuming

Nobody is born with the innate knowledge of those capabilities. You can learn them.

This article is meant to jumpstart you in your path to improve your Threat Modeling skills, by providing specific recommendations.

Let’s start with the knowledge of Security risks and Mitigations.

There are various good references you can get out there. The first recommendation is to start with a good book, providing a very structured introduction to Threat Modeling: “Securing Systems” by Brook S.E. Schoenfield. I’ve already introduced this book in those pages because it is by far the best one on Threat Modeling you can get now. It is invaluable to understand the inner working of the process and to get a solid foundation to build on. While it is not necessarily a book to introduce the various Threats and Mitigations, it should still be considered a required read. Another good book is Adam Shostack’s “Threat Modeling: Designing for Security”. That one is also a good book and expands over the previous one by covering recent studies and showing how Threat Modeling can be applied to other scenarios than assessing software. All in all, those books should be considered complementary, with the first representing a more important book than the latter.

Now that you have built a solid foundation, using those two books, what should you do to learn about Security Risks and Mitigations?

There are various sources out there you can use.

I am sure you have already heard about the OWASP Top 10 list. While it is a good starting point, this is not what you should focus on:

• First of all, being a Top 10 list, it cannot represent a complete representation of the risks, but merely identifies common issues in the Industry and applies mostly to Web Applications. Your organization may face different issues, or you may be a target of more skilled attackers, who would not be limited to those attacks.
• Secondarily, it mixes various types of issues, targeting Design, Development and Operation, or a combination of those, and as a result, it may not be that clear as a reference.

I like this list, but I hate it when it is referred to as the primary security requirement.

So, what could you get to go beyond the OWASP Top 10? Without searching far from it, you can find OWASP’s Application Security Verification Standard (ASVS). This document collects a good list of Mitigations, providing some background about them. The problem with ASVS is that it does not do a good job of linking Threats with Mitigations, because its goal is to provide a solid foundation for security tests or to define security requirements for your solution. Still, it’s a good reference to know.

The best material I can refer you to, for understanding possible Threats and Mitigations, is represented by the excellent CAPEC, CWE and ATT&CK projects by MITRE.

CAPEC, or the Common Attack Pattern Enumeration and Classification, is probably the best database to understand possible Threats and to enumerate them. It provides a searchable hierarchy of attack types, and for each of them, it gives information like the typical severity, the related weaknesses, and what mitigations you should consider. CAPEC contains references to other databases, like CWE, which allows us to contextualize the provided information better.

CWE, or Common Weaknesses Enumeration, is another useful database from MITRE. It collects information about the possible vulnerabilities present in our solution by enumerating the common failings. It may be helpful to highlight here that the concept of Threats is related to the potential attacks, which is what is covered by CAPEC; CWE instead covers the types of bugs or issues we may have in our software, also known as weaknesses. Understanding the Weaknesses may be essential to identify the potential attacks because there is a relationship between the two. Therefore, CAPEC and CWE link to each other, so that you can jump from a weakness to the related weaknesses and vice versa.

CWE is also associated with another famous Mitre database, CVE, which contains most vulnerabilities found in commercial and non-commercial products. You may have already seen examples of such vulnerabilities, for example related to patches to Windows OSs or famous applications. In other words, while CVE provides a list of the various known security issues in software, CWE categorizes them, and CAPEC lists common attacks linking them to the related weaknesses.

Not all Threat Modeling methodologies consider the weaknesses as a central part of the process: for example, Microsoft’s disregard weaknesses and focuses on Threats and Mitigations. The reason is simple: even if considering weaknesses is important, and everyone agrees on that, what is essential is to identify the right Mitigations and to prioritize them based on the actual risk. Weaknesses are indeed the root cause of security risks, but their impact is indirect and is materialized through the execution of attacks, that is the Threats. As a result, we may save us some effort and focus directly on Threats and Mitigations.

The last database, ATT&CK, is a database built upon a different approach. Instead of focusing on Threats as isolated activities, it recognizes that most typically attacks are part of sophisticated campaigns, where they represent only a single step, along with many others. For each possible attack, it provides the associated Threat in CAPEC, the potential mitigations, and many other details, including examples of known attacks based on those. Having examples of known attacks is really useful because it allows you to make the attack much more credible, by listing situations where it has been executed.

All in all, those three databases represent a very valid tool to understand the potential security risks, how they may occur and what you could do to control them. Indeed, they represent an essential tool to know Security Risks and Mitigations.

Of course, there are a lot of other tools you may use to get more proficient with Threat Modeling and to understand Threats and Mitigations, including lessons on Pluralsight, Cybrary, and other platforms.

We are at the end of our article. Next time the goal will be to discuss the importance of the holistic approach and how you can train yourself to be a better Threat Modeler by applying it.

For now, stay safe and happy Threat Modeling!