Threat Modeling as a Program, Not a Workshop

TL;DR: Run threat modeling as a program by giving it an owner, defined triggers and a stored record, then measuring it. Answer the four questions at design time, update the model in small slices whenever data flows, dependencies, trust boundaries or releases change, keep diagrams and threat lists in the repository linked to tickets, and report coverage, freshness, verification and burn-down each quarter. The method chosen matters less than whether all four questions get answered.

What is threat modeling?

Threat modeling is, in the words of the Threat Modeling Manifesto, analyzing representations of a system to highlight concerns about security and privacy characteristics. Put plainly, a team draws the system, works out how it could fail, and decides what to change.

The method is short. The manifesto frames it as four key questions:

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 enough job?

Each question has a practical scope.

• The second finds threats. The method can be as simple as a brainstorm or a structured technique such as attack trees.
• The third is a decision. The team either builds a mitigation or applies the accept, transfer or eliminate approaches of risk management.
• The fourth checks the work. The test is whether the team did a good enough job for the system at hand.

What a threat model produces

The output is a set of working documents. The OWASP developer guide lists system models and diagrams, lists of threats among the deliverables. A typical model also records actions that can be taken to mitigate each threat and assumptions that can be checked or challenged in the future.

Two further outputs matter at the leadership level. The first is a prioritized list of security improvements to the concept, requirements, design or implementation. The second is an assurance argument that can be used to explain and defend the security of an application.

Why it shapes later decisions

The manifesto says the threats a model identifies inform decisions in subsequent design, development, testing, and post-deployment phases. In our reading, testing is the most direct case. OWASP lists security test cases and test scenarios among the results.

That only holds if the model stays current. The OWASP cheat sheet says a threat model should be maintained, updated and refined alongside the system. In our reading, this is the line between a program and a workshop. A workshop produces a diagram that ages. A program keeps the four questions attached to every material change.

For related terms, see the glossary.

What goes into a threat model

A threat model is a document, not a meeting. OWASP calls it a structured representation of all the information that affects the security of an application. That makes it something a reader can open, check and argue with months after the workshop ends.

The core parts

OWASP's community page lists what a threat model typically holds. It starts with a description of the subject to be modeled and ends with a way of validating the model and threats, and verification of success of actions taken. In between sit the threats, the mitigations and the assumptions covered in the previous section.

The validation step has a blunt first test. OWASP's process page asks: Are there records showing a diagram, a threats list and a control list. If those three records are missing, the work has not been done.

The scoping artifacts

Scoping is where most of the paper comes from. Expect to see these:

• Data flow diagrams (DFDs). A DFD is a high-level way to visualize data flows between the major components of a system. Trust boundaries are often illustrated in DFDs with dashed red lines.
• Entry points. The scoping step involves identifying entry points to see where a potential attacker could interact with the application. Exit points, where data leaves the system, belong next to them.
• Assets. An asset is something of value in a system that needs to be protected.
• Trust levels. These are trust levels that represent the access rights that the application will grant to external entities.
• External dependencies. Third-party services, libraries and platforms the system relies on but does not control.

Trust boundaries deserve the closest look. Calls that cross them often need to be authenticated and authorized, so a diagram with no boundaries drawn is a diagram that skipped the hard part.

Asset lists need a lighter hand. OWASP warns that often times those assets are out of scope for a project, and are a distraction. In our reading, a short list tied to the diagram is more useful than an inventory copied from elsewhere.

When reviewing a team's model, start with the diagram and the boundaries. Then ask whether each threat maps to something on that diagram.

How STRIDE works

STRIDE is a mnemonic for six threat types: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privilege. Microsoft, which uses it, says the model categorizes different types of threats and simplifies the overall security conversations. Each letter names a way an attacker breaks one specific promise the system makes.

Category, property, question

The third column is how we would phrase each category as a design-review prompt.

Microsoft's own examples are pointed. Its tool prompts questions such as "How can an attacker change the authentication data?" and "What happens if access is denied to the user profile database?" In our reading, a team that can answer those for every login path and every data store has done most of the STRIDE pass.

What the definitions add

The CMS definition of repudiation notes that a denial can be honest or false. In our reading, logging is therefore about settling disputes, not only catching attackers. Microsoft gives a plain non-repudiation example: a signed delivery receipt the vendor can then use as evidence that the user did receive the package.

Tampering covers more than databases. It includes the alteration of data as it flows between two computers over an open network, such as the Internet.

Microsoft describes elevation of privilege as the case where an attacker has effectively penetrated all system defenses and become part of the trusted system itself. In our reading, that description is why many reviews leave this category until last: it often depends on a spoofing or tampering step succeeding first.

To apply STRIDE, walk it across the diagram. Drata's guide lists the elements as processes, data stores, data flows, and the external entity, and reminds teams that threats tend to follow the data flow. We think asking all six questions of each flow catches more than asking them of the system as a whole.

The CMS example

The CMS Threat Modeling Handbook promotes early and ongoing threat modeling in the system life cycle using the STRIDE framework. A team starting out can take two reusable pieces from it: the property table above, and the pairing of STRIDE with Adam Shostack's Four-Question Frame for Threat Modeling. CMS says it chose these because they utilize industry-standard language. In our reading, that is a practical point for a program, because engineers, system owners and assessors can then share one vocabulary across reviews.

How STRIDE, PASTA and DREAD compare

The three methods do different jobs, which is why teams often run two of them together. STRIDE sorts threats into categories, DREAD (Damage, Reproducibility, Exploitability, Affected users, Discoverability) puts numbers on them, and PASTA (Process for Attack Simulation and Threat Analysis) frames the work around business risk in stages.

The table below sets them side by side. The staffing and effort columns are our reading, not a published standard.

What each one leaves to the others

STRIDE's output is a structured list of potential threats organized by category, which teams use to design countermeasures before implementation. The same analysis notes that STRIDE does not quantify or prioritize what it finds. Left without a scoring step, reviewers make those calls by hand, which can lead to inconsistent decisions across reviewers or teams.

DREAD fills that gap. It is typically used in combination with another framework, most often STRIDE, to score threats that have already been identified. Each of the five dimensions is scored, typically on a scale of 1 to 10, and the scores are averaged into one rating.

In our reading, the averaging is where DREAD needs care. Two reviewers can score the same threat differently, so a program that uses it should write down what a high score on each dimension means for its own systems.

Who the methods suit

STRIDE is often pitched at teams at earlier stages of security maturity, where a clear taxonomy gives guidance without deep expertise. We think PASTA fits better where business owners will sit in the room, because its stages ask for business context that a design review alone does not supply.

The method matters less than the questions

The Threat Modeling Manifesto describes itself as methodology-agnostic. It values people and collaboration over processes, methodologies, and tools. Its test is whether a team answers four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job.

For a security leader, that gives a simple check on any method in use. If the records answer all four questions for each system, the choice of method is a detail. If one question has no answer, switching frameworks will not supply it.

When in the lifecycle should you threat model?

Start at design. The software development lifecycle (SDLC) has a point where a change is a redrawn box on a diagram rather than a rewritten service, and that is where the first model belongs. The OWASP cheat sheet says threat modeling is ideally performed early in the SDLC, such as during the design phase.

The reason is cost. Microsoft describes its Threat Modeling Tool as a way to find and fix issues early, when they are relatively easy and cost-effective to resolve. OWASP makes the same point from the other side: building security in is far more efficient than having to identify and resolve security flaws after a system is in production.

Late is still better than never. The CMS handbook notes that threat modeling can be done at any time, with design as the ideal start.

Why one model is not enough

A model describes the system as it was on the day someone drew it. Systems drift. OWASP says a threat model should be maintained, updated and refined alongside the system.

The Threat Modeling Manifesto ties the cadence to how teams already ship. Its principle is that modeling must follow design changes in iterations that are each scoped to manageable portions of the system. In our reading, that rules out the annual offsite as the main vehicle. A program updates the slice of the model that changed, when it changed.

Triggers for a revisit

CMS sets a floor: a model should be revisited with each new feature or release. OWASP points to where change matters most. Trust boundaries, data flows, data stores, processes and external entities often represent possible attack points. When any of those move, the model is out of date.

Threats tend to follow data, as the STRIDE section noted, so in our reading the first trigger deserves the closest watch.

Making it stick

We think the practical move is to wire these triggers into existing gates. Add a model-update checkbox to the design review template. Flag pull requests that touch network policy or add an outbound integration. Treat a stale diagram as a defect, the same way a failing test is.

How to run threat modeling as a program instead of a one-off workshop

A workshop produces a document. A program produces a habit with an owner, a trigger and a record. The steps below describe how we think a sitting leader gets from the first to the second.

Anchor the work to a maturity model

The OWASP Developer Guide places threat modeling in the Threat Assessment practice of the Design business function, within the OWASP Software Assurance Maturity Model (SAMM) (OWASP Developer Guide). That gives you a shared vocabulary for reporting progress. In our reading, it also turns threat modeling from a favor engineers do for security into a practice you can score, fund and report to a committee, as covered in our board oversight report.

Run the four-step loop on a cadence

It adds that each step is frequently documented as it is carried out (OWASP).

The assess step has a plain first test: whether records exist showing a diagram, a threats list and a control list (OWASP). Two more rules keep the loop honest. When a team accepts a risk, document who chose to accept it. When it ranks fixes, the frequently included factors are likelihood of attack, damage from an attack, and complexity or cost of fix (OWASP).

Set intake rules

Almost anything can be modeled. So write intake rules that send scarce reviewer time to the systems with the most exposure.

In our reading, a workable set of triggers looks like this:

• A new internet-facing service or public API.
• A new external integration or third-party data flow.
• A change that adds or moves a trust boundary.
• A move to cloud services. OWASP says traditional techniques often need adaptation for cloud architectures (OWASP Cheat Sheet).

For teams that ship small changes often, one alternative is to model at the story level. That approach has been described as work that developers, operations or site reliability engineering (SRE) staff would do (OWASP).

Store models where engineers already work

The OWASP cheat sheet advises saving diagrams in a form the team can update (OWASP Cheat Sheet). We think that means the repository, next to the code, with each threat linked to a ticket in the tracker engineers already use. In our reading, a model kept in a security team's shared drive tends to go stale.

The stored record also does work beyond the engineering team. OWASP says the process produces an assurance argument you can use to explain the security of an application (OWASP Developer Guide). That is the artifact to bring to auditors and the board.

How to tell whether the program is working

The fourth question, did we do a good enough job, helps a leader only once it becomes something countable.

Four checks turn that question into a quarterly report.

Coverage and freshness

Coverage starts with an inventory. A model count means little without the list of systems the program claims to cover. In our reading, the most useful version breaks coverage down by team, because a program where one person writes every model is fragile. The Manifesto names this anti-pattern: threat modeling "does not depend on one's innate ability or unique mindset; everyone can and should do it."

Freshness needs defined triggers. OWASP lists events after which updating is advisable: a new feature is released, a security incident occurs, or there are architectural or infrastructure changes. Pull those events from release records, the incident log and change tickets. Then check each one against the model's revision history.

Verification and burn-down

A threat model is meant to carry its own proof. OWASP says a model typically includes a way of validating the model and threats, and verification of success of actions taken. The OWASP Developer Guide also lists identification of security test cases and test scenarios among the benefits. We think the cleanest rule is that a mitigation counts as done when a test or a review record shows it working, not when a ticket is closed.

Burn-down tracks the list itself. OWASP notes that typical efforts produce a prioritized list of security improvements alongside the model. If that list only grows, the program is finding problems faster than teams fix them. Report its age profile, not just its length.

Keeping the numbers honest

Tooling helps here. The Manifesto asks for tools that "enable repeatability and provide measurability." In our reading, the risk is teams writing models to move a coverage figure. Pair every coverage number with the verification and burn-down numbers, so a rising count with a stalled list shows up on the same page.

For how these figures fit a board pack, see our report on board committee oversight.

What this guide does not cover

This guide does not walk through attack trees or other techniques for finding threats in detail.