Four Questions to Ask When Building a Threat Model
In recent years, the increasing adoption of the continuous integration and continuous delivery (CI/CD) model in software development has made cloud resources a more suitable solution – bringing enhanced availability and scalability. However, despite the increased spending on security tooling, one of the most serious threats in cloud security remains unaddressed: cloud misconfiguration.
Many users assume the cloud is an inherently secure environment, but the shared responsibility model of the cloud details that, while cloud service providers (CSPs) are responsible for securing the cloud itself (i.e. data centers and infrastructure), customers are responsible for securing their workloads and data in the cloud. Security controls and configurations are often disabled by default for ease of use, creating a challenge for users to securely configure these services without impacting velocity.
Threat modeling provides a systemic approach for enumerating potential threats to workloads, devising mitigations, and prioritizing them for maximum impact on the overall security posture of the workload. Over the years, I have built threat modeling programs from the ground up for both commercial enterprises and federal government agencies and while the organizations vary dramatically, the approach to securing their workloads and data is largely the same.
In this post, I’m going to discuss the four key questions that I always ask when developing a threat model – as documented in the Threat Modeling Manifesto that I co-created in 2020 with a group of industry thought leaders.
1. What are we working on?
This first question helps to identify the scope of the project being analyzed with regards to security threats. Many times, a system will be described in terms of its goals and expected operations, and an architectural or network diagram is often created, to help visualize how the system works. Typically, in threat modeling, a data flow diagram (DFD) would be used. (I share examples of these diagrams in this whitepaper.)
2. What can go wrong?
This next question helps to identify threats, and there are several ways in which it can be done. One of the most common tools to use in identifying threats is to apply STRIDE, a mnemonic that represents Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege.
STRIDE is by no means the only way to identify threats, but it is a good place to start when thinking about application-focused threats.
3. What are we going to do about it?
This third question helps to determine mitigations. Each of the STRIDE threats has a property violated. A mitigation, or a combination of mitigations for defense in depth, can help make sure the property is secure. For example, if there is a Spoofing threat, a mitigation can be constructed that will ensure proper identity. Typically, this is done through authentication controls (e.g. checking username / password, preventing brute force attacks through limiting how many attempts to try a username / password, requiring two-factor or multi-factor authentication options beyond just a password, etc.).
4. Did we do a good enough job?
The final question helps to review the threat model and determine if there are more threats to uncover or additional mitigations to add, refining the model by leading to new security requirements, improvements to be made to existing mitigations, or mitigations that are no longer necessary. This step also highlights the need to continue to update the threat model when there are new features to add.
I provide more detail regarding each of these questions in our whitepaper, “Enhancing Amazon Web Services (AWS) Workload Security Through Threat Modeling.” While the focus is, in part, on AWS, the same threat modeling principles and best practices apply regardless of your platform.
The practice of implementing a threat model process can have challenges when it comes to how to initiate, nurture, and scale a program in an organization. It can be easy to start a program when an organization is new, but the reality is that many organizations are looking to adopt and develop a practice with their existing product constraints.
If you’re looking for guidance on how you can get started, give us a shout at Aquia. There are several methodologies that can be adopted, often in parallel, to drive toward the goal of a self-sustaining threat modeling culture. We’d be happy to help.
