What is a threat model? Simply put, this is a process designed to elevate an organization’s security posture by cataloguing all assets within a given system that need to be protected, identifying by whom and what directions they might be attacked, and how exactly they can be safeguarded. The industry often associates these exercises with the early stages of the software development lifecycle, but it also applies to firmware and hardware as well. If you’re new to the concept, it’s important to start with an understanding of each step involved. Let’s take a look at the five main stages of building a threat model:
1. Take inventory of your assets
The first phase in developing a threat model is identifying what you care about. Before you can protect your systems, you first need a comprehensive understanding of what assets matter most and where they’re operating and stored at all times. Generally speaking, building an asset catalogue is a manual process, which might encompass things like cryptographic keys, encrypted data, private keys, System Management RAM, access to critical security features, and more.
2. Identify security objectives and non-objectives
Next, map out what you’re protecting each asset from, and prioritize your security objectives. To do this, security teams typically conduct a comprehensive audit of their assets against the “CIA triad.” This is a model for assessing three of the most important aspects of security; confidentiality (who has access to the asset), integrity (can the asset be modified), and availability (is the asset protected against denial of service and other attacks). Every organization’s security objectives and non-objectives are unique, and those priorities are set based on a variety of factors including the level of risk, the likelihood of an adversary successfully exploiting certain attack vectors and the amount of resources required (on both the organization and the attackers’ part).
3. Lay out an adversary model
One of the most important questions you need to ask during any threat modeling exercise is, who are my adversaries? Is it someone that has network access to a machine, someone that has physical access, or someone that has software access? Based on the security objectives you establish in Step 2, your adversary model is essentially a list of attacker personas you need to defend against. It will outline who they are, what their skillsets might be, what level of privilege they have and their attack method of choice. Understanding if you’re worried about script kiddies, attackers with a deep understanding of software programming, or someone capable of reverse-engineering hardware (or all the above) is crucial for being able to proactively develop mitigations for potential threats.
4. Pinpoint all relevant threat vectors and attacks
Now it’s time to begin examining potential attack vectors. This is the most time-intensive stage — one that involves staying up to date with both known (legacy) attacks, as well as the cutting edge threats. In this stage, you must understand the data flows of your assets. Where are they stored at rest? Are they encrypted? What about in transition? Your team must step into the adversary’s shoes and identify every possible attack vector. Should you be concerned about escalations of privilege in firmware, preventing unauthorized access for turning security features on or off, enabling or disabling debug and flash locks, or downgrading to older, legitimate software versions that are vulnerable to certain attacks? You need to understand if these are risks to your organization to protect against them. This section of the threat model will include a matrix of all threat vectors and every potential attack for each. One industry resource often used in this process is the CVSS calculator, which enables security teams to align assets with objectives, adversary models, attack vectors, and associated severity level.
5. Develop the necessary mitigations
From there, you’ll need to write a mitigation for each of those potential attacks. For instance, you might develop a mitigation that prevents attacks from modifying your firmware by forcing the system to prevent boot if any changes are made that don’t match approved policies. Or, a mitigation might prevent a bad actor from running a malicious driver by blacklisting it. This section of your threat model is essentially a matrix that includes at least one mitigation for each possible attack against every asset you’re trying to defend.
Tips for effective threat modeling
Now that you’ve gone through these five steps, you should have the ingredients needed for an effective threat model. As with any major security process or procedure, there are various best practices you can and should implement to avoid major pitfalls and increase the probability that your threat model will successfully improve your organization’s security posture over the long term. One critical best practice is to share the document broadly within your organization. Without wide circulation among those involved in every stage of product development (architects, developers, validation teams, and security researchers), the document isn’t of much use. When all teams are operating based on the same threat model — with the same objectives, threats and mitigations in mind — we increase the odds of delivering a cohesive, secure product consistent with its assumptions. This minimizes the likelihood of costly security oversights or mistakes. Whenever possible, consider sharing threat models with the broader industry as well, which can help other organizations improve their products and elevate our collective security. Additionally, you must approach threat models as “living documents.” The final and most important step in the threat modeling process is never truly “complete.” Commit to re-examining and refining your threat models regularly. As the threat landscape evolves (which it does rapidly and endlessly), your threat model must be adapted to account for new threats, attack techniques, etc. Failing to do so will result in missed vulnerabilities, unpatched exploits, ignorance about relevant security research, and other security blind spots. Furthermore, take advantage of existing specifications and technologies that can expedite and enhance the threat modeling process. For example, today, most platforms leverage the Unified Extensible Firmware Interface (UEFI) specification that was developed by Intel, AMD, Microsoft, and other PC manufacturers to overcome many of the performance shortcomings of BIOS firmware. It’s also important to note that following NIST standards (like NIST 800-193) is another way to help ensure that your platforms, software, and products are aligned with a robust threat model. Organizations can also use security validation tools like the open source CHIPSEC project to analyze the platform-level security of hardware, devices, and system firmware configurations. CHIPSEC in particular offers cumulative tests that can be applied across different platform generations, helping organizations catch potential regressions and streamlining testing for threat model assumptions. Advanced, automated analysis tools like this and others (some focused on negative testing, symbolic execution, fuzzing, etc.) allow for massive improvements in firmware security specifically, and are extremely helpful in enabling organizations to more easily identify vulnerabilities in their systems and validate mitigations during the threat modeling process.
Building living threat models
Done properly, threat modeling can profoundly improve your organization’s security posture. It’s a blueprint of every asset you care about, how you need to protect them, who you’re protecting against, what ways they could be accessed, what attacks might be possible, and the mitigations available for each. Use the above best practices to ensure that the threat models you develop are effective and that they’re seen across your organization as powerful, essential, and iterative frameworks for better security.
