This article "What to Threat Model -- Each Software Release Cycle" is part of the What to Threat Model series. This article targets Software Security Group (SSG) Owners and the Security Champions/Architects working within that group.
Author: John Steven
Even after an organization has decided what applications and infrastructure to threat model, questions remain for an SSG. "Does each delivery team wait for a particular phase of its lifecycle to conduct the threat model? -- Does threat modeling have to occur during design?" "Do we block on threat modeling before proceeding with the rest of delivery?" "What if the team doesn't have a diagram? -- what artifacts are necessary to begin threat modeling?"
Having Enough to start Threat Modeling
Having decided a particular application or piece of infrastructure is worth threat modeling at the organizational level, the work on that threat model begins in earnest. The team assigned begins to collect inputs: system diagrams and answers to key design tradeoffs being considered. Questions about what is necessary to begin the threat model quickly turn to when the necessary information will be available.
It's almost universally true that some material necessary to conduct threat modeling (a diagram, clear direction as to approach and key design decisions) will not be available. Engineering teams may use this to defer threat modeling to a later time -- only to then claim, "It's too late, we've made all the pertinent decisions."
Absolutely threat model systems even when there's no diagram or when key decisions remain open. Use any missing threat modeling inputs as an opportunity to place security practitioners on the critical path to delivery. If diagrams don't exist, interview engineers and develop them. Providing functional infrastructure and process-flow diagrams will accelerate delivery. If key design decision challenges remain unanswered, explore their tradeoffs and answer them as part of threat modeling -- holistically, not just from a security perspective. Engineering teams need additional hands and threat models can and should address design tradeoffs, documenting intended security controls and residual risks.
What/When to Threat Model?
There is no one best time to conduct threat modeling. Threat modeling is best thought of as a continual exercise, conducted incrementally and throughout software and infrastructure delivery lifecycles, rather than as a point-in-time activity conducted during a specific lifecycle phase. Align threat modeling with application or infrastructure release schedule, preferring major release milestones. A security champion/architect should plan to deliver a threat model along the same cadence as the underlying application or infrastructure release being modeled. This implies that during each functional aspect of the lifecycle a commensurate threat model activity occurs. For instance:
| Functional Area: | Threat Modeling Activity |
| User Stories Elicitation | Identify adversaries, elicit misuse/abuse cases |
| Diagramming | Identify attack surfaces, diagram process-flows, annotate controls |
| Architecture/Design | Threat enumeration, flaw identification, secure design |
| Defect Discovery | Flaw-hypothesis testing, Security-test planning |
In a continuous and incremental model, what/when to threat model becomes significantly less stressful: mirror delivery activities, following the same cadence. A threat model isn't 'finished' until all its activities are -- again, similar to a release. However, each threat modeling activity generating insight and value as input to the next lifecycle phase.
There are plenty of good reasons threat modeling occurs as a point-in-time activity, rather than a continuous and incremental pursuit, aligned with delivery. Two common scenarios include evaluating 3rd party packages considered for use or due-diligence on acquisitions. Other motivations involve re-capitulation of existing threat models due to changes in asset classification, emergence of new threats, or changing compliance regimes. These point-in-time threat modeling catalysts fall into two operating modes: proactive and reactive. Neither is 'right' or 'wrong', both have their intended purpose.
Reactive Threat Modeling
Reactive point-in-time threat modeling is perhaps the most comfortable for security practitioners because it mimics the approach of defect discovery (code review, penetration testing) activities with which they're most familiar. This type of threat model, like assessment, is designed to produce a snapshot of system security posture.
Output outlines both the effective use of security controls as well as the design flaws inherent in a system. Activity and deliverable align to support decision-making, gauging 'good enough' to release, incorporate, acquire, and so forth. Reactive threat models should always include at least one diagram encompassing the whole scope of the model. That diagram should include both the structure and relationship of infrastructure and software, as well as process-/data-flow among depicted system components. Reactive threat models will also deliver a ‘burn down’ list of design flaws, prioritized by risk, and accompany each flaw with a mitigation strategy or combination of compensating controls and explanation of residual risk.
The scope of what’s threat modeled is that which is necessary to support confident decision making for each iteration. Within an organization’s own delivery a model will likely be scoped to functionality planned for release. Whereas modeling 3rd party systems or potential acquisitions will a broader scope of interest — perhaps a whole product or system.
Proactive Threat Modeling
Proactive point-in-time threat modeling is most commonly what organizations growing a threat model practice list as their aspiration. While this style of threat modeling leverages many of the same activities as the reactive model, its intended outputs are considerably different. Proactive threat modeling intends to evaluate design before it’s finalized, and certainly before implementation is available for review or testing. In this threat modeling modality producing an assessment-style deliverable would be failure. Proactive threat modeling is a means to accomplish secure design.
Much of the output of proactive threat modeling is incorporated into a system’s documented design — a design which now reflects the desired security properties. Accompanying standard design artifacts is a Threat Traceability Matrix: essentially a spreadsheet that “Shows the secure design work” for posterity and reuse:
| Who | Where | What | How | So What? | Now What? |
| Adversary | Attack Surface | Attack Objective | Exploit graph | Impact | Mitigation/Control Strategy |
Practice tremendous flexibility with the scope of what a proactive mode threat models. The technique, applied this way, can answer extremely tactical design tradeoffs (e.g. “Can we allow this container to run as root?”) and stretch to analyze a green-field architecture in the large (e.g. “What do we fear as we move to the cloud?”). If practicing proactive threat modeling within a software or infrastructure delivery lifecycle, scope the model to that lifecycle iteration, aligning it with the planned work.
Aligning Threat Modeling with a Lifecycle
Whether proactive or reactive, what is threat modeled should align with the acquisition or delivery lifecycle. Whether it’s a product being acquired, a framework or service being selected, or roadmap milestone being released. Again, in the proactive case, what’s being modeled could be a single tactical decision.
What to Focus On
What’s changing? - From the perspective of an application owner or business information security officer, the question about what to threat model is less about particulars of the technical solution and more about the use cases being developed. What sensitive business processes or assets are planned for new delivery or change? This is the ‘what’ to threat model.
Align threat modeling with the delivery lifecycle itself and model a sprint’s or roadmap’s key milestones.
- Identify new assets being digitized (e.g. a rewards or points system for customers)
- Discover what legacy assets are newly visible in developing services or externally
- Re-evaluate compliance and security requirements for those assets based on changing data sensitivity classification or regulation.
- Is new functionality being offered conveying digital privilege unavailable prior (e.g. funds transfer)? And
- Have customers’ expectations for privacy or due care changed?
When threat modeling aligns with the critical path delivery priorities of a lifecycle there’s a natural consequence: modeling will focus on change. This is ok. Focusing on change is a great way to control the scope of what’s modeled and assures that modeling aligns with current business priorities.
Summarizing…
What do you threat model within the scope of a chosen application or infrastructure? The answer is: mirror the delivery goal.
- Acquiring a product, incorporating a SaaS or selecting a dev framework? threat model your organization’s solution architecture and use cases for that product
- Planning a major release? Threat model the planned roadmap items.
- Minor release? Focus on active development and what that development relies on.
By controlling the scope of what’s modeled, organizations can avoid perhaps both of the biggest twin problems causing failure: not knowing where to start because there’s too many targets within a green-field holistic threat model and a lack of clarity around what good enough looks like so that threat modeling exercises can transition to downstream consumers of that information, like secure design or manual security testing.
