Shostack’s Four Question Framework for Threat Modeling

This framework, originally proposed by Adam Shostack in his book Threat Modeling: Designing for Security, was created to provide a process for systematizing threat modeling in organizations. This framework, as amended by Adam, is as follows: 

1. What are we working on? 

2. What can go wrong? 

3. What are we going to do about it?

4. Did we do a good job? 

The Framework is SIMPLE

Have you ever heard the statement, “If you cannot explain it simply, then you don’t understand it well enough”. I feel like the four questions embody this understanding with regard to threat modeling any given system. A point of contrast might point out that they are “too generic to offer any real value” but I feel that this fails to recognize them for what they are and are not. They are not meant to be a complete checklist for threat modeling. They are meant to be flexible such that other threat modeling practices and processes can fit inside of them. 

Rejecting this framework exclusively for its simplicity might represent an organization that values obscure obfuscated compliance over value added processes. 

The Framework is Proactive

The four questions focus on action statements. What are we working on? This statement is not “what are we building?” but is instead “What are we working on?”. Regardless of where an application or system is in its lifecycle, it can and should be threat modeled. What are we going to do about it? This was rephrased from “What can we do about it” to reflect a more proactive approach. Not only should all options be considered but the focus should also be on the options that can be implemented and will be implemented by our team. 

The Framework is NOT a silver bullet 

This framework will not solve content or knowledge problems but it will provide a structure to assess a threat modeling program against. For example, it might reveal that your team is especially skilled at designing systems but they get stuck on determining potential threats. By segmenting those items into separate phases, it allows the team to be “single-minded” and focus energies on one set of tasks at a time. 

The Four Questions

The below sections further detail out the four questions. 

What are we working on? 

Focused on the deconstruction of the current system or application into its component parts which will then be threat modeled individually, in parts, or as a whole. In this phase, scope must be defined to ensure that the borders are well defined for this threat model. Assigning something as “Out of Scope” does not mean that it will not or never be threat modeled. It just means that it will not be in this threat model. 

What can go wrong?

This phase focuses on the assessment of threats. In this phase other frameworks can be used to generate or categorize threats for this system or application. Frameworks such as STRIDE, TRIKE, OWASP, MITRE ATT&CK, MITRE CWE, OCTAVE, and PASTA can be used to determine the potential threats, weaknesses, or attack methods that might be used against the system we are threat modeling. The four question framework is easy to work with because it permits for the incorporation of additional threat modeling frameworks.

What can we do about it?

This phase focuses on proactive discussions around reducing or eliminating potential weaknesses or the likelihood of threat realization. This phase should follow an established prioritization process. Do we prioritize based on cost to implement or system classification or both? Internal policy and procedure should dictate how those are prioritized. 

Did we do a good job? 

This model includes an assessment step to determine how effective this process has been. Focus on iteration and improvement of the process. Does it need to include additional captured information from the architecture team or from security champions. Are we achieving the outcomes that have been communicated by senior management? This step should be the evaluation of your process against those success criteria. 

Conclusion

Shostack’s Four Question Framework for Threat Modeling is a flexible and simple framework that can be used in nearly any environment. Do you have a unique application or adaptation of this framework that you can share with the community? Leave a comment below with how you have used this or adapted it to your environment. 

Reference:

• Shostack, Adam. Threat Modeling: Designing For Security. John Wiley & Sons, 2014.