Threat Modeling
Program: Security Foundations, Governance and Risk Module: Introduction to Risk Management Submodule: Threat Modeling
The previous submodules covered how to assess risk and how to respond to it with controls. Both, however, assume you already know what could go wrong. Threat modeling is the disciplined, whiteboard-driven practice that produces that list — and it does so before the attacker gets a chance to.
This submodule answers three questions:
- What is threat modeling and where does it fit in the risk-management cycle?
- How do you identify and categorize threats — which approach, which framework?
- How do you turn a threat list into an action list — decomposition, prioritization, response?
1. What Threat Modeling Is (and Why)
Threat modeling is a structured, visual exercise in which security, engineering and business stakeholders sit around a whiteboard and enumerate all the plausible ways an asset — an application, a server, a user, a building — could be attacked.
The output is not a single verdict; it's:
- a list of possible threats against the asset,
- a priority ranking so the most dangerous ones are handled first, and
- an analysis of controls that could eliminate or reduce each one.
1.1 Why it matters
- Early identification. Finding an issue on a whiteboard costs a meeting; finding it in production costs an incident.
- Efficiency. Instead of trying to secure everything equally, controls are directed where they matter most.
- Shared understanding. Everyone in the room leaves with the same mental model of how prone the organization actually is to attack.
- Realistic red-team scenarios. Defensive teams get an inventory of risks; offensive teams get a menu of realistic campaigns to run (e.g. hurricane knocks out the data center, USB drops in the parking lot, nation-state actor hunts for cancer research).
1.2 Proactive vs reactive threat modeling
Threat modeling is not a one-time exercise done at project kickoff.
| When | Called | What it produces |
|---|---|---|
| Before the asset exists / is deployed | Proactive threat modeling | Design decisions, chosen controls, safer software from day one |
| While the asset is already in use | Reactive threat modeling | New threats discovered mid-life, ways to reduce known ones, iterative improvements |
Mature organizations run both — proactively at design, then reactively throughout the entire lifecycle of the asset. Data centers in tornado-prone areas, for example, use proactive threat modeling to choose location and construction, then reactive threat modeling to refine building management as conditions change.
1.3 The three stages of any threat model
Whichever approach you use, the exercise itself always has the same three phases:
Concretely: weak passwords are a vulnerability; a criminal organization is the threat actor; the possibility of them exploiting the weak passwords is the risk; deciding to enable MFA is the response — and that whole loop is one threat-modeling pass.
2. Three Approaches to Identifying Threats
Before you can categorize a threat, you have to find it. There are three well-established approaches, and each is suited to a different job.
| Approach | Start from… | Best for | Trade-off |
|---|---|---|---|
| Asset-based | A list of the assets you deem valuable, then the threats to each | Business-level risk assessments; feeds directly off a business impact analysis | Not granular — poor fit for deep technical work |
| Attacker-based | The threat actors, their motives, means and opportunity, then the threats they'd pose | Vulnerability assessments and pen tests | Highly engaging (everybody wants to play the spy) — but can miss risks no attacker has "personified" yet |
| Software-based | A diagram of the software — users, databases, privileges — then the threats to each component | Helping developers understand their own applications (web, email, in-house software) | Requires the design to already exist and be well understood |
In practice you often combine them: an asset-based pass to decide what is worth defending, a software-based pass to decompose how it works, and an attacker-based pass to stress-test who would come after it.
3. Categorizing Threats with STRIDE
Once threats are on the board, they need to be classified so they can be reasoned about consistently. STRIDE, built by Microsoft to identify threats against applications and operating systems, is the most widely used categorization framework.
Each letter is one category the modeler must consider.
| Letter | Category | Attacker capability | Real-world illustration |
|---|---|---|---|
| S | Spoofing | Use a falsified identity | Phishing email claiming to be "latest salary data from HR"; spoofed MAC/IP address inside the network |
| T | Tampering | Make unauthorized changes to systems or data | Modifying data in transit or at rest due to weak/absent encryption — an integrity attack |
| R | Repudiation | Deny having performed an action | Attacker makes activity look like it came from a third party; trust in audit logs collapses |
| I | Information disclosure | Expose confidential data | Adobe (2013) — 453 M usernames & encrypted passwords leaked; Equifax (2017) — 147 M records; NSA tools leaked by Shadow Brokers (2017), later reused against hospitals; also over-verbose error messages that leak backend detail |
| D | Denial of Service | Exhaust the system so legitimate users can't use it | Memory-buffer overflow, request flooding; can be temporary, but also destructive to data or usable for ransomware leverage |
| E | Elevation of privilege | Escalate from low to higher privilege | Red-teaming a visitor check-in terminal that was wired into the internal network — pretend to check in, escalate to local admin, then roam |
3.1 STRIDE in the bigger picture
STRIDE is a checklist for the imagination. Applied to every component you've drawn on the whiteboard, it forces the group to ask "could a spoofing attack happen here? a tampering one? …" instead of relying on the team's spontaneous creativity.
After categorizing, always push the analysis further:
- How far can the attacker go? Can they reach a production database? Global admin in your cloud tenant? Spin up new environments?
- What is the attacker's end goal? A payday, reputational damage, or something specific — in one tabletop with a financial firm, the end goal was publicly leaking financial data about celebrities. Marketing, legal and sales belonged in that room precisely because the end goal was a PR event, not a technical one.
4. A Worked Example — Whiteboarding a Public Website
A canonical worked example: your publicly available website, accessed by normal users and admins over the internet, backed by an authentication server and a database that are also reachable from the internal network for management and development.
Working component by component, the group asks "how could this be exploited?" — and the STRIDE categories start filling themselves in almost automatically.
4.1 User & admin access to the website
- Could a malicious user flood the site into halting? (DoS)
- Could they guess credentials? (Spoofing)
4.2 The authentication system
- How does it distinguish an admin from a low-privilege user?
- Anti-pattern: websites that store the privilege identifier in the user's browser — the authorization code lives client-side, so any user can modify it and promote themselves to admin. (Elevation of privilege via tampering.)
4.3 Database access
- Who can create, modify or delete records? Can one user delete another user's records? (Tampering, elevation of privilege)
- What if a user sends database commands instead of search keywords? Does the site forward them raw and does the database execute them? If so, can the attacker dump or delete every record? (Information disclosure and tampering — classic injection.)
4.4 Post-compromise: reach into the internal network
- If the whole website is compromised, how far can the attacker pivot? Where in the internal network are "the keys to the kingdom"?
The whole point of this stage is to break the system into small components and identify threats to each of them, producing a list that is both actionable for defenders and realistic for pen testers / red teamers to validate.
5. Decomposition — Looking for Controls and Reduction
Once the threat list exists, the next pass is a reduction analysis: dive deep into every subroutine and module and look for boundaries where trust changes and inputs that need scrutiny. Concretely, the modeler asks:
- Trust boundaries. Where does the trust or security level change? Do we accept traffic from anywhere, or only certain hosts? Can all partners access our systems, or do we require extra verification? Can they access each other's data?
- Data flow. Where is data coming from and where is it going? Does it cross untrusted boundaries — and if so, is it protected in transit?
- Input handling. Where and how do we take input? Only usernames and passwords, or also search fields and other forms? Can users upload files, and if so, of what type and size?
- Privileged functions. Which activities require elevated rights, and how are they protected? How does the app ensure only authorized users can invoke them?
- Security assumptions. Which assumptions are we quietly making? Do we trust every user? Every input? Every file type? Is there a maximum accepted file size?
Anecdote — file uploads and DoS
One pen-test target allowed users to upload any file, of any size. The testers uploaded terabytes of video until the application's storage was exhausted — a denial-of-service attack triggered purely by a missing input constraint. Fix: allow only trusted file types, enforce size caps, and validate everything at the trust boundary.
Decomposition turns each vague threat ("someone could abuse uploads") into a concrete control opportunity ("restrict to specific MIME types under N MB, scan and quarantine").
6. Prioritizing and Responding to Threats
You won't fix everything at once, so prioritize. Three common techniques of increasing sophistication:
6.1 Probability × damage
The simplest quantitative approach: combine how probable the threat is with how much damage it would do. The output is a 1–10 rating, with 10 being the highest priority.
$$ \text{priority} ;=; \text{probability} ;\times; \text{damage} $$
6.2 High / Medium / Low ranking
Cruder but often "good enough". Subjective, fast to apply, and communicates cleanly to non-technical stakeholders. Example: a website hosting sensitive patient data without authentication is clearly high; an insider walking away with encrypted backups is low.
6.3 DREAD
DREAD is a more granular framework. Score each threat on five axes (often 1–10) and sum or average them:
| Letter | Question |
|---|---|
| D — Damage potential | How severe would the damage be? Whole site down, or just a portion? |
| R — Reproducibility | How easily can the attacker reproduce the exploit? Trivial, or complicated scenario? |
| E — Exploitability | How hard is it to actually carry out? Guessable passwords are easy; needing custom exploit code filters out low-skilled attackers. |
| A — Affected users | What percentage of users are affected? Just the compromised account, or can the attacker pivot laterally and hit others? |
| D — Discoverability | Is the weakness exposed to the whole world or just insiders? Does the attacker need to be authenticated first? |
Higher DREAD scores go to the top of the response queue.
6.4 Choosing controls after prioritization
Prioritization tells you which threats to respond to first; submodule 02 tells you how — the four responses (mitigate, transfer, accept, or don't-ignore) and the control categories/types. When shopping for tooling to implement those controls, weigh cost against effectiveness and beware the modern security-product landscape:
Before purchasing an application or suite that mitigates a specific threat, ensure your security and risk teams can actually implement and monitor it. A tool that isn't operated is not a control.
6.5 Threat modeling is continuous
Both attackers and defenders keep evolving. Threat modeling therefore has to be re-run regularly, often in near real time, so that new threats and risks are accounted for — the same message as the Monitoring stage of the NIST RMF in submodule 02 §5.
7. Putting It All Together
Threat modeling is the loop that keeps risk assessment honest and gives risk management something concrete to act on.
8. Key Takeaways
- Threat modeling is a whiteboard-driven, collaborative exercise that enumerates plausible attacks against an asset before they happen — and iterates on that list forever.
- Every pass has three stages: list threats → prioritize → analyze & respond.
- Choose an identification approach that fits the goal: asset-based for risk assessments, attacker-based for pen tests and vuln assessments, software-based for developers.
- STRIDE — Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege — is the default categorization checklist.
- Decomposition exposes trust boundaries, data flows, inputs and privileged functions where controls can actually be inserted; the "unlimited file uploads → terabyte DoS" anecdote is the canonical reminder to validate inputs.
- Prioritize with probability × damage, High/Medium/Low, or the more granular DREAD (Damage, Reproducibility, Exploitability, Affected users, Discoverability).
- Threat modeling is done both proactively (before deployment) and reactively (throughout the asset's life) — never once and done.
9. Glossary (this submodule)
- Threat modeling — structured exercise that enumerates, categorizes and prioritizes plausible attacks against an asset, then identifies controls to eliminate or reduce them.
- Proactive threat modeling — threat modeling performed before the asset is deployed, feeding design and control decisions.
- Reactive threat modeling — threat modeling performed during the operational life of the asset, catching new threats and refining existing controls.
- Threat actor — the person, group or force capable of exploiting a vulnerability (criminal organization, insider, nation-state, natural disaster).
- Asset-based approach — threat identification that starts from the valuable assets and lists threats to each.
- Attacker-based approach — threat identification that starts from the threat actors' motives, means and opportunity.
- Software-based approach — threat identification driven by a diagram of the software's users, data stores and privileges.
- STRIDE — Microsoft's threat categorization framework: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege.
- Spoofing — using a falsified identity (phished email, spoofed MAC/IP) to impersonate a trusted party.
- Tampering — unauthorized modification of systems or data, at rest or in transit; violates integrity.
- Repudiation — an actor's ability to deny performing an action; attackers exploit weak logging to shift blame.
- Information disclosure — exposure of confidential data, whether through breach, leak, or over-verbose error messages.
- Denial of Service (DoS) — attack that exhausts system resources so legitimate users cannot use the service.
- Elevation of privilege — attacker moves from a low-privilege context to a higher one (e.g. local admin, domain admin).
- Trust boundary — location in the system where the trust or security level changes; a natural place to insert a control.
- Decomposition — breaking the target into subroutines and data flows to find trust boundaries, inputs and privileged functions to protect.
- DREAD — quantitative threat-prioritization scheme scoring Damage, Reproducibility, Exploitability, Affected users and Discoverability.
- Probability × damage — the simplest quantitative prioritization: probability of the threat times the damage it would cause, rated 1–10.
- Tabletop exercise — discussion-based walkthrough of a scenario with cross-functional stakeholders (security, legal, marketing, sales) to test response plans.
10. What's Next
The next submodule — Business Continuity Planning — takes the worst-case threats that survive prioritization and asks how the organization keeps operating when one of them actually happens: which processes must survive, how quickly they must recover, and where the backups, alternate sites and playbooks live.