A Risk Register Is Not a Threat Model

“It is on the risk register, so we have threat-modeled it.”

Let me stop you before a spreadsheet gets promoted to security architecture.

A risk register is not a threat model.

A threat model discovers how a particular system can be abused.

It starts with assets, actors, entry points, data flows and trust boundaries.

It produces threat events, abuse cases, attack paths, and requirements somebody can actually build or test.

A risk register records what you decide to do about an exposure once you have one.

Likelihood.

Impact.

Risk level.

Treatment.

Owner.

Rationale.

Review status.

And the conditions that require the decision to be revisited.

Those systems meet at a handoff.

They aren’t interchangeable.

No one would say “we have a change ticket, so we have designed the feature.”

Yet people look at a row marked High and announce that the design has been threat-modelled.

Apparently a colour grid has become an architectural analysis tool.

Somewhere, an external entity is feeling very represented.

1. “But the Register Has Likelihood and Impact.”

Yes.

That is what a register is for.

NIST SP 800-30 assesses likelihood and impact after identification.

It asks for the threat source and threat event.

The vulnerabilities and predisposing conditions affecting adverse impact.

Your organization’s susceptibility.

Then a determination built from likelihood and impact.

The order matters, because a scale can rank only a thing that has been described.

“Likelihood: Medium.

Impact: High” is not a description of an attack path.

It does not say what asset is at stake.

Who interacts with it.

Where data crosses from one privilege level to another.

Which entry point the path begins at.

What condition lets it proceed.

It is an opinion about an unnamed noun.

Threat modelling supplies those nouns.

A data-flow diagram has four element types: external entity, process, data store, data flow.

It marks a trust boundary wherever privilege or authentication changes.

OWASP makes that boundary explicit.

Microsoft’s minimal example is equally blunt, a human user outside your system, a web-server process, a database data store, and a dashed line between user and server.

That isn’t diagram ceremony.

It is the difference between “customer data could be exposed” and “an external entity crosses this boundary, reaches this process, and causes this store to disclose data through this flow.”

The first fits in a register.

The second gives your team something to inspect.

NIST SP 800-30 calls your assessment output a risk determination.

Correct.

And a determination is not a discovery method, any more than a lab result is a microscope.

2. “But the Risk Owner Accepted It.”

Then the risk owner accepted something.

The question remains: what, exactly?

A working register records a named risk, a treatment decision, a named owner and stated rationale.

Its entries need a threat event and source, likelihood, impact, resulting risk level, treatment, owner, date last reviewed, and the trigger forcing an off-cycle update.

Appendix K to NIST SP 800-30 adds assessment date, purpose, scope, assumptions and constraints, risk-tolerance inputs, the risk model and analytic approach, rationale and uncertainty.

Useful accountability.

Keep it.

It doesn’t replace the missing model.

An owner can accept residual exposure after mitigation.

Or mitigate a risk and then accept what remains.

Or layer a transfer instrument over the remainder.

NIST SP 800-30 supports acceptance, avoidance, mitigation, sharing and transfer as investment decisions.

None of those verbs creates an abuse case.

“Accepted” means you have selected a course of action within your tolerance.

It does not mean somebody established how an attacker reaches the asset.

Which boundary they cross.

Which precondition your design leaves intact.

Whether the proposed control breaks that route.

A signature can’t add an entry point to a diagram.

It only makes the absence more accountable.

3. “But We Used the Same Risk Taxonomy Across the Company.”

Good.

A common taxonomy makes risks comparable across systems, teams and tiers.

It is doing a governance job.

It isn’t doing a discovery job.

Your enterprise register aggregates findings from a system or application threat model, an audit, a vendor review, an incident post-mortem, a business change.

NIST SP 800-30 describes identification as finding threat sources and the threat events they can initiate or cause.

ISO/IEC 27005 frames the same space through assets, threats, vulnerabilities and affected business processes.

Already a richer model than a shared label.

“Information disclosure” can mean a data store has an overbroad authorization decision.

Or a process emits a secret into a log.

Or a data flow crosses a boundary without the required protection.

Not the same engineering problem, merely because they share a taxonomy leaf.

STRIDE exists because your team has to walk the actual design element by element, boundary by boundary.

Six categories.

Spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege.

Microsoft describes both a goal-based pass.

Could an attacker spoof identity here, tamper with this data, deny service?, and a checklist pass across network, host and application layers.

A corporate taxonomy gives the resulting findings somewhere consistent to go.

It cannot tell STRIDE which process exists.

Which data store holds the asset.

Where the trust boundary moved in the last deployment.

A filing system is very efficient once somebody has found the file.

4. “But Threat Modeling Takes Too Long for Every Change.”

Sometimes it does.

That is a scoping problem.

Not an excuse to call your register a threat model.

Your model has two dials.

Granularity sets whether one data-flow diagram spans the whole system or a particular component.

The UK NCSC says a whole-system view includes components, users, data flows, interconnectivity and trust boundaries.

It is the only view that can show a threat living at the seam between components.

It also becomes difficult to finish and maintain as your system grows.

A per-component model is more tractable, and can be kept current by the team that owns it.

It can also stop exactly where the relevant cross-component threat begins.

Neither failure turns a risk register into a substitute.

One is too broad to finish.

The other is too narrow to show the seam.

Different problems, different fixes.

Method selection is the second dial.

STRIDE is a developer-facing, six-category checklist from 1999, giving broad coverage across a diagram.

PASTA runs seven stages.

Define Objectives, Define Technical Scope, Application Decomposition, Threat Analysis, Vulnerability and Weakness Analysis, Attack Modeling, Risk and Impact Analysis, and brings business impact in before technical decomposition.

That does not mean every pull request convenes a PASTA workshop with a business stakeholder and a catered lunch.

It means you choose a scope and method proportional to the change, then model enough of the changed asset, boundary and path to make the risk decision intelligible.

“Too slow to do exhaustively” is not evidence that “not done at all” has become rigorous.

5. “But the Security Team Already Knows the Common Threats.”

Security teams do know common threats.

Which is why they should be particularly suspicious of a process relying on memory instead of a diagram.

STRIDE doesn’t ask your team to become surprised by spoofing or tampering.

It makes your team ask where, in this system, spoofing or tampering could apply.

That small word is the entire problem.

Generic knowledge isn’t a substitute for a system-specific path.

Microsoft’s threat template calls for a description, a target element, an attack technique and a countermeasure.

The risk rating stays blank until the list has been narrowed enough to justify the next analysis.

That sequence prevents the familiar move.

Putting Medium beside “unauthorized access,” calling it sober judgment, and never asking which authorization decision or entry point permits it.

Misuse cases and abuse cases offer another route when you begin with a harmful scenario rather than a diagram element.

Guttorm Sindre and Andreas Opdahl define a misuse case as the inverse of a use case: a completed sequence producing loss rather than value.

John McDermott and Chris Fox introduced abuse cases in December 1999 as harmful interactions between a system and one or more actors.

Not exotic alternatives designed to keep workshop facilitators employed.

They are ways to make the threat event concrete.

A security team that knows common threats should have no trouble saying which asset is harmed, which actor starts the interaction, and which system behaviour permits the loss.

If it can’t, “common” is doing suspiciously little work.

6. “But a Detailed Attack Tree Is Theoretical.”

An attack tree is theoretical in the same sense that a route map is theoretical before the truck misses the bridge.

Its purpose is to expose the path before your system depends on it.

Bruce Schneier’s December 1999 formulation places the attacker’s goal at the root.

OR nodes are alternatives, any one route succeeds.

AND nodes are required steps, every condition must succeed.

For a high-value threat, that decomposition exposes the preconditions a flat risk row politely leaves out.

The important design consequence is practical.

Breaking any one AND-linked node defeats that path.

So a countermeasure can target a specific precondition, instead of vaguely “reducing risk” in a quarterly slide deck.

Microsoft illustrates this with a credential-obtaining threat decomposed into cleartext credentials crossing your network and network monitoring, then further conditions beneath it.

No, you don’t build a detailed tree for every STRIDE finding.

Attack trees are reserved for the higher-value threats worth their construction cost.

An attack tree alone can be a legitimate deep dive when the goal is already known and the asset is high value.

It is poor first-pass coverage for an entire system, because nothing forces the tree builder to consider every entry point before choosing the root.

That is not theory.

That is triage.

And it is considerably more useful than accepting a score whose path nobody can draw.

7. No, This Does Not Mean Every Change Needs an Exhaustive Attack Tree.

It doesn’t.

It means a risk decision needs a sufficiently concrete model of the asset, trust boundary and abuse path it is accepting.

For a narrow, routine component change, a current component DFD, an explicit changed flow or boundary, and a STRIDE pass may be enough.

For a high-value asset, or a threat with several plausible routes, use an attack tree to expose the alternatives and required conditions.

For a decision needing business-impact prioritization at the outset, PASTA’s seven stages may fit better.

The choice is not between exhaustive theatre and a single red cell.

It is between a model proportionate to the decision, and no model at all.

DREAD makes the same point about scoring.

Five dimensions.

Damage potential, Reproducibility, Exploitability, Affected users, Discoverability, at High (3), Medium (2) or Low (1), producing a composite from 5 to 15.

Microsoft also documents a simpler Probability × Damage Potential scale, inputs from 1 to 10, composite from 1 to 100.

Those are ordering mechanisms.

They can help decide which known threat deserves an attack tree or immediate treatment.

They do not discover a threat.

A calculator is allowed to rank the routes after somebody has drawn the map.

It does not get to draw the map by being nearby.

8. What You Should Actually Do

Start with the current system, not the existing risk sheet. Define the scope: system boundary, assets worth protecting, explicit exclusions.

Draw the data-flow diagram with external entities, processes, data stores, data flows, and every trust boundary where privilege or authentication changes.

Apply STRIDE to every diagram element and boundary. Use a goal-based pass and a checklist pass.

Record each credible threat with its description, target element, attack technique and countermeasure.

Start a misuse or abuse case when a harmful scenario makes the path clearer than the diagram walk alone.

For the high-value findings, build attack trees. Make OR routes and AND preconditions visible.

Derive controls that break a precondition or constrain a path.

Then turn the result into a tracked security requirement, with a bug-tracker identifier and status.

The Threat Modeling Manifesto puts finding and fixing design issues ahead of checkbox compliance, because a threat document without a work item changes nothing.

Only then open or update the risk register. Record the threat event and source, likelihood, impact, level, treatment, named owner, rationale, date last reviewed, and off-cycle trigger.

Evaluate acceptance, avoidance, mitigation, sharing or transfer against risk tolerance.

Mitigate first and accept the residual where that is the actual decision.

Pretending the options are mutually exclusive is another way to make paperwork sound cleaner than reality.

Monitor the assumptions. NIST SP 800-39 separates frame, assess, respond and monitor.

NIST SP 800-30 separates prepare, conduct, communicate and maintain, and its Appendix L assigns ongoing monitoring of risk factors and updating from those results.

An incident, a materially altered control, a new system, a new obligation or a newly discovered vulnerability class can require a targeted assessment rather than waiting for the calendar.

9. “But We Audit the Register, So We Know It Is Working.”

Audit it.

Just do not ask that audit a question it cannot answer.

A completeness audit checks whether your record contains its required content.

A currency audit checks whether material changes, a retired control, a confirmed incident, a new system, a regulatory obligation, caused the required update.

A fully populated entry can still be stale.

A current entry can still be sparse.

Different failures.

FAIR adds a dollar-denominated Value at Risk output, from loss-event-frequency and loss-magnitude ranges with stated sources and confidence intervals.

Useful when you need a quantitative comparison with a treatment’s cost.

Translating that result back into red, yellow or green preserves your dashboard and throws away the comparison.

C2M2 organizes more than 350 practices across ten domains and scores objectives at MIL1 Initiated, MIL2 Performed and MIL3 Managed.

NIST CSF uses four Tiers.

Partial, Risk Informed, Repeatable, Adaptive, and CSF 2.0 adds a Govern function for establishing, communicating and monitoring risk-management strategy, expectations and policy.

All valuable.

None of it verifies that the underlying threat event was discovered correctly.

A programme can be current, complete, quantitatively decorated and highly institutionalized while its likelihood estimate describes the wrong attack path.

A pristine filing cabinet remains a poor substitute for knowing what is in the file.

10. The Actual Model Is Not Complicated.

Threat modelling asks: what assets exist, who interacts with them, where does data flow, where does trust change, and how can this system be abused?

Risk management asks: given that exposure, what are its likelihood and impact, which treatment do we select, who owns it, what is the rationale, and when must the decision be revisited?

The first produces the thing the second evaluates.

Risk treatment cannot be sounder than the model of the threat it treats.

Use DFDs.

Use STRIDE.

Use attack trees where their extra detail earns its cost.

Convert credible threats into requirements.

Then use the register for what it is good at.

Accountable treatment, residual acceptance, continuous review.

But do not point at a likelihood-and-impact label and call it a threat model.

That is not architecture.

That is a confidence interval wearing a hard hat.