Threat Modeling
Objectives: By the end of this topic, you will be able to…
- Decompose a system into a data flow diagram with its trust boundaries and entry points drawn
- Enumerate threats against each element with STRIDE, using the per-element mapping so that no category is silently skipped
- Prioritize threats with DREAD against anchors you wrote down before scoring, and defend the resulting order
- Propose a countermeasure for each threat and say whether it is a fix or a compensating control
What is threat modeling?
Threat modeling is the systematic process of identifying which assets need to be protected, determining who could attack them (threat actors), analyzing how they could do it (attack vectors), assessing vulnerabilities and their impact, and defining controls to mitigate those risks. Its purpose is to anticipate potential attacks, design more secure systems from the start, and prioritize security controls and resources.
Three of the words in that definition are used loosely in ordinary speech and precisely here. A threat is an unwanted outcome someone could bring about, stated in terms of what is lost. A vulnerability is the specific weakness that would let them bring it about. An attack vector is the route taken to reach that weakness, meaning the entry point plus the technique used against it. Keeping the three apart matters because a control attaches to exactly one of them: you can remove the vulnerability, block the vector, or accept that the threat exists and invest in detecting it instead. A finding that blurs them tends to produce a countermeasure that answers a different problem from the one identified.
Assets do not all deserve the same attention, and a model that treats them as equals spends most of its effort in the wrong place. Three questions rank them. The first is what the asset is worth to an attacker, which is not what it is worth to you: a table of password hashes has little operational value to the organization holding it and considerable value to someone who intends to reuse those credentials elsewhere. The second is how far the damage spreads when the asset is lost, which separates an asset whose compromise affects one account from one whose compromise affects every account at once. The third is which security property the loss breaks, in the sense of the confidentiality, integrity and availability that class 01 introduced: an asset that matters because it must stay secret needs a different control from one that matters because it must stay accurate. Rank the assets before enumerating threats against them, because the ranking is what decides where the analysis time goes.
Threat actors differ along two dimensions that change the model rather than just its wording. The first is capability, which covers skill, tooling and how much time and money the actor can spend. The second is where they already stand. An external attacker has to cross every boundary from the outside, while an insider, whether that is a disgruntled employee or an outsider operating a compromised employee account, begins inside one or more boundaries already, which makes any control that only inspects traffic at the perimeter irrelevant against them. Modeling only the outsider is a common way for a threat model to come out looking reassuring while leaving the more damaging scenarios unexamined.
Threat modeling belongs to the design phase of the software development lifecycle, before anything has been built. A finding at that point costs a change to a diagram, while the same finding after release costs a patch and a release cycle, plus whatever the vulnerability did in the meantime. It also forces security, development and product people to agree on what the system actually is, which is worth something on its own even when the threat list comes out short.
Threat modeling methodologies
STRIDE (Microsoft)
Each letter represents a threat category:
| Category | Property it negates | What it looks like concretely |
|---|---|---|
| Spoofing | Authentication | An attacker presents an identity that is not theirs: a captured session token replayed against an API, or a service impersonating a peer it is not. |
| Tampering | Integrity | Data or code is modified without authorization: a price or a role field edited in a request in transit, or a stored record rewritten after the fact. |
| Repudiation | Non-repudiation | A party performs an action and later denies it, and you hold no evidence strong enough to contradict them: a transfer with no log entry, or a log entry that same party could have deleted. |
| Information Disclosure | Confidentiality | Data reaches someone not authorized to see it: a verbose error returning a stack trace and a query, or an unauthenticated backup endpoint. |
| Denial of Service | Availability | Legitimate use is prevented: a request that exhausts memory or connections, or a lock held indefinitely on a shared resource. |
| Elevation of Privilege | Authorization | A party gains capabilities it should not have: an ordinary user reaching an administrative function, or a process escaping the privilege level it was meant to run at. |
The middle column is what makes the six categories memorable rather than arbitrary. Each STRIDE category is the negation of one security property, so naming a threat and naming the property it breaks are the same act. Three of those properties are the confidentiality, integrity and availability that class 01 introduced as the CIA triad; the other three, authentication, non-repudiation, meaning that a party cannot credibly deny an action you hold evidence for, and authorization, are what the triad on its own does not cover, which is why a model built only on the triad tends to under-report impersonation and privilege problems.
The pairing also runs in the other direction, and that is where it earns its place. Once you have classified a threat, the property tells you what kind of control answers it. Spoofing is answered by authentication controls, tampering by integrity controls such as signing, hashing and server-side validation, repudiation by logging the acting party cannot alter, information disclosure by encryption and access control, denial of service by quotas and rate limiting, and elevation of privilege by authorization checks enforced on the server rather than assumed by the client. You are not expected to memorize a catalogue of countermeasures; you are expected to derive the category of control from the property that was broken, and then name a specific instance of it.
Two boundaries cause most misclassification. Tampering and elevation of privilege both involve an attacker doing something they should not, but tampering changes data or code while elevation of privilege changes what the attacker is permitted to do. If the attacker’s rights are unchanged and only the data moved, it is tampering. Spoofing and elevation of privilege are close in a different way: replaying a captured session token is spoofing, because the attacker is asserting an identity that is not theirs, and it becomes elevation of privilege only if the identity they assume carries rights their own account did not have. Classify by what the attacker gained rather than by how they got in, because the control you propose follows from what was lost.
DREAD (threat prioritization)
Used to rank and prioritize threats based on risk:
| Criterion | Associated Question |
|---|---|
| Damage | How severe is the damage if it happens? |
| Reproducibility | How easily can the attack be repeated? |
| Exploitability | How easy is it to exploit the threat? |
| Affected Users | How many users are affected? |
| Discoverability | How easy is it to discover the threat? |
Each criterion is scored from 1 to 10, and the mean of the five is the threat’s risk score. Scoring is only useful if two people evaluating the same threat land near the same number, and an instruction to score from one to ten does not achieve that on its own, so fix the ends of the scale before you score anything. For Damage, a 1 is a cosmetic or purely informational effect, a 5 is the exposure or loss of one user’s non-critical data, and a 10 is full compromise of the system or irrecoverable loss of the data it holds. For Affected Users, a 1 is a single user under unusual conditions, a 5 is an identifiable subset such as one tenant or one role, and a 10 is the entire user base. For Exploitability, a 1 requires a rare precondition, physical access or a custom-built tool, and a 10 is reachable by anyone who can send a request, with no credentials and no tooling beyond a browser. Write your anchors down before you score, and use the same ones for every threat in the same analysis, because the numbers are comparable only within one anchoring. The anchors above are a convention adopted for consistency rather than a published rubric. The scale used here, one to ten per criterion averaged over the five, is one of several in circulation, and what none of them fixes is what the intermediate values mean, which is the source of the weakness discussed next.
DREAD is worth knowing and worth being skeptical of. Its criteria are not independent of each other, Reproducibility and Exploitability in particular overlap heavily, and two competent people scoring the same threat routinely produce different totals. Discoverability is the least defensible of the five, because a vulnerability nobody has noticed yet is not a safer vulnerability, and scoring it low rewards obscurity with a lower risk number. The unweighted mean is the second problem: dividing by five gives Discoverability exactly the same influence as Damage, and a criterion on which every threat in your set scores 8 to 10 raises every total while contributing nothing to the ordering. When you compare two threats, the criterion that decided the ranking is the one with the widest spread between them, not the one with the highest score. None of this makes the exercise pointless, and the discipline of scoring five named dimensions separately is most of the value; it makes the resulting number an argument you have to be able to defend rather than a measurement.
Class 03 already gave you the two questions a defensible severity rating has to answer, impact and exploitability, which are two of DREAD’s five criteria under other names, and it introduced the CVSS score published alongside most CVE entries. Hold the contrast: CVSS comes from a published formula and is comparable across findings written by people who have never met, while a DREAD score comes from your judgement and is comparable only inside one consistently anchored analysis. Use structured scoring to order threats in a system for which nobody has published anything, and cite the published score when one already exists.
PASTA (Process for Attack Simulation and Threat Analysis)
PASTA is a seven-stage, risk-centric methodology that starts from business objectives rather than from a diagram, decomposes the application into the same kind of data flow diagram described in the next section, and ends by expressing findings as business risk. Reach for a lightweight per-element method when you are modeling one system in a design review, and for a business-risk method when the output has to justify a budget or satisfy a regulator.
Data Flow Diagrams (DFDs)
A data flow diagram shows where information enters a system, moves through it and leaves it, and it is the artifact that lets you apply STRIDE element by element rather than reasoning about the system as an undifferentiated whole. Most of you will have met the notation in systems analysis already, so the table below is a reminder rather than new material.
| Element | Common Symbol | Example |
|---|---|---|
| External entity | Rectangle | User, external system |
| Process | Circle/Oval | Web service, business logic |
| Data store | Two lines | Database, files |
| Data flow | Arrow | Interaction between elements |
The element types are not interchangeable from a security point of view, and that is what turns a systems-analysis diagram into a threat model. Each element type is subject to a known subset of the STRIDE categories, and the subset follows from what the element is:
| DFD element | Categories that apply |
|---|---|
| External entity | Spoofing, Repudiation |
| Process | all six |
| Data store | Tampering, Repudiation, Information Disclosure, Denial of Service |
| Data flow | Tampering, Information Disclosure, Denial of Service |
Read the table as reasoning rather than as a rule to memorize. An external entity is outside your control, so the only things you can meaningfully doubt about it are the identity it claims and whether it will later deny what it did; you cannot tamper with something you do not run, and it has no privileges of yours to escalate. A process runs your code, holds your privileges and touches everything else on the diagram, so all six categories apply to it, which is why processes generate the longest threat lists. A data store has no identity to impersonate and no privilege level of its own, but its contents can be altered, read or made unavailable; repudiation applies to it specifically when the store is the log you would rely on as evidence, because a log that can be edited cannot settle a dispute. A data flow in transit can be modified, read or interrupted, and that is the whole of it.
This mapping produces candidates, not findings. It tells you where to look and guarantees you will not silently skip a category on an element that could suffer it; deciding whether a given candidate is real in a given design, and how much it matters, is still your judgement.
A trust boundary is a line on the diagram where the level of trust in the data, or in the party handling it, changes. Anything crossing it inbound was produced by something you do not control, so it has to be authenticated, validated and authorized on your side of the line, and nothing on the far side can be relied on to have done that for you. Client side validation is a common illustration: it improves the experience of an honest user and constrains nothing at all about what an attacker sends, because the attacker controls everything on their side of the boundary including the code you shipped them.
An entry point is a specific place where data or control crosses a trust boundary into the system: a form submission, an API endpoint, a file upload, a message consumed from a queue, or a link that returns a user into an authenticated session. An entry point is always a boundary crossing, which is what distinguishes it from an internal call.
The attack surface is the set of all entry points together with the data and functionality reachable through each one. Reducing attack surface means removing entry points or narrowing what each one reaches, which is why an administrative interface exposed to the public internet is a materially worse design than the same interface reachable only from an internal network, even when both are password protected. That reasoning is developed further in class 12.
Threats concentrate at boundary crossings. When you are asked which of several entry points carries the most risk, you are being asked to combine three things: how much trust the crossing gains (an anonymous request that ends up executing privileged logic gains more than one that returns a public page), what the data reaching it is worth, and which actors can realistically stand on the untrusted side of it.
Here is a minimal DFD for a login system, with the trust boundary drawn in:
untrusted (client) ┊ trusted (server side)
┊
[User] ┊ (Validate Credentials) =User DB=
│ ┊ │ │ │
│──── username + password ─────►│ │◄──── user record ─────────│
│◄─── session token ────────────│ │──── lookup query ────────►│
┊ │
┊ │──── write session ────► =Session Store=
Legend: [ ] external entity · ( ) process · = = data store · ───► data flow · ┊ trust boundary
Only two flows cross the boundary, and those two carry the concentration of threats. The credential submission crosses inward from a party you do not control, so it can be spoofed by anyone holding valid-looking credentials, read in transit if the channel is not encrypted, and used as a vehicle for injection into the lookup query that follows it. The session token crosses outward and must be unforgeable, unguessable and protected in transit, because possession of it is what the server will accept as proof of identity on every later request. Replaying a captured token is spoofing rather than elevation of privilege, since the attacker acquires exactly the rights of the account they impersonate and no more. Flows that stay on the trusted side are still subject to the per-element mapping, but reaching them requires an attacker who has already crossed the boundary or who started inside it.
Identifying threats, vectors, and mitigations
Example: User login web system
| Asset | Threat (STRIDE) | Vector | Control |
|---|---|---|---|
| User credentials, in use | Spoofing | Online password guessing or credential stuffing against the login endpoint | Rate limiting and lockout, multi-factor authentication, detection of anomalous login patterns |
| User credentials, at rest | Information Disclosure | Theft or leak of the credential store | Salted password hashing, covered in class 06 |
| Credentials in transit | Information Disclosure | Interception by a machine-in-the-middle (MITM) attacker, positioned to relay traffic between two parties who believe they are talking directly | TLS with certificate validation actually enforced by the client |
| Database contents | Tampering, Information Disclosure | SQL injection through input concatenated into a query | Parameterized queries as the fix; input validation and a WAF as defense in depth. See class 08 |
| System logs | Repudiation | Deletion or editing of entries by the party whose actions they record | Append-only storage, entries shipped to a system under separate control, per-entry hash chaining |
| Internal API | Elevation of Privilege | Calling an endpoint the caller’s role should not reach, or presenting a token whose claims are not verified | Authorization enforced server side on every endpoint, full validation of session tokens. Token and session security is developed in class 14 |
Two of those rows separate a fix from a compensating control, and telling them apart is most of what justifying a security decision amounts to. Parameterized queries remove the injection outright, because the input can no longer be parsed as part of the query whatever it contains. A WAF sits in front of the application and rejects requests that look like injection attempts, which leaves the flaw in the code and buys time until it is repaired. Both belong in a thorough answer, but proposing only the WAF is proposing not to fix the vulnerability. Hashing works the same way against credential theft: it does not prevent the disclosure, and it is not a control against online guessing at all, which is what rate limiting and multi-factor authentication answer. What it does is raise the cost of turning a stolen credential store into working logins.
The logs row deserves the same care, because “add auditing” is the reflex answer to repudiation and it is frequently not enough. A log establishes non-repudiation only if the party whose actions it records could not have written or altered it. A log file the application can rewrite, on a host its administrator controls, records what happened but proves very little about it, since the party who would deny the action is also the party who could have removed the entry. What closes the gap is tamper evidence: append-only or write-once storage, shipping each entry as it is written to a system under different control, or chaining every entry to a hash of the one before it so that a deletion leaves a detectable break in the chain.
When analyzing a system for threats, a useful mental checklist runs through five questions: who are the attackers that could realistically reach the system, what assets would be valuable to them, what vectors could they use to get there, what vulnerabilities exist at the entry and exit points they would traverse, and what controls would meaningfully reduce the risk of a successful attack.
Hands-on lab
Requirements: A diagramming tool. Draw.io and Lucidchart are general-purpose diagram editors; OWASP Threat Dragon is a threat-modeling tool that stores the diagram as a model and can generate a per-element STRIDE candidate list from it. If you use Threat Dragon, treat that generated list as the starting point for the reasoning Part 2 asks for, not as the completed table. One shared diagram file per pair. Base case: the Online Banking Web Application described in Part 0 below.
Part 0: Base case — Online Banking Web Application
Reference scenario for applying STRIDE, DREAD and data flow analysis.
Scenario
A mid-sized bank offers an online banking platform where customers can:
- Log in using a username, password, and optional 2FA code
- View account balances and recent transactions
- Transfer money between accounts or to other banks
- Receive email notifications for transfers or security alerts
System components
- Frontend Web App: A browser-based interface for customers
- Backend API Server: Handles authentication, account data, and transactions
- Database: Stores user profiles, credentials, and transaction history
- Email Service: Sends alerts and notifications
- Admin Portal: Allows bank staff to manage accounts and investigate suspicious activity
Key assumptions
- Customers access the platform via desktop and mobile browsers
- The platform uses HTTPS and JWT tokens for sessions
- There is an external payment processor for interbank transfers
- Logging and audit trails exist but are not tamper-proof
- Attackers may be external (hackers) or internal (disgruntled staff)
Identifiable assets
| Asset | Description |
|---|---|
| User credentials | Login username, hashed passwords, and 2FA secrets |
| Session tokens | JWT tokens used for authentication |
| Transaction records | Logs of all user transactions |
| Account balance information | Sensitive financial data |
| Customer personal details (PII) | Names, addresses, emails, phone numbers |
| Banking APIs | Endpoints for account management and transfers |
Actors
- Customer: End user accessing the system
- Bank Admin: Employee with privileged access to manage accounts
- External Payment Processor: Third-party API for interbank transfers
- Attacker: Could be an external hacker or malicious insider
Entry points
- Web login page
- API endpoints for transactions and account data
- Admin portal login page
- Email notifications (with embedded links)
Part 1: Case introduction and asset analysis
Roles. This lab is done in pairs, and the two of you analyze different regions of the same system. Decide now who takes which role and write it on the diagram.
- Customer-channel analyst. You own the Customer as an actor, the Frontend Web App, the customer-facing side of the Backend API Server, the session-token flow, and the email notifications as the customer receives them. Your entry points are the web login page, the API endpoints for transactions and account data, and the links embedded in email notifications.
- Back-office analyst. You own the Bank Admin as an actor, the Admin Portal, the Database, the Email Service as a sending system, and the External Payment Processor. Your entry points are the admin portal login page and the interface to the payment processor, and the malicious insider named in Part 0’s assumptions is your actor of record.
The Email Service sits in both regions and that is deliberate: the back-office analyst owns it as a process that sends, and the customer-channel analyst owns the link it delivers as an entry point. The Backend API Server is the same kind of case, owned by the customer-channel analyst and reached by flows the back-office analyst owns. Those overlaps are exactly the crossings step 4 makes you negotiate.
Who owns a flow that crosses between the regions. A data flow is an element in its own right and can be tampered with, disclosed or denied, so every crossing needs threats written against it by exactly one of you. The analyst who owns the destination end writes them, because the destination is what has to authenticate and validate whatever arrives; the analyst who owns the origin end reviews those rows in the Part 2 swap. Apply this rule to every row of the crossing table you agree in step 4.
-
Both of you read the base case in Part 0, then agree who takes which role.
-
Working separately, each analyst ranks the assets from Part 0 that are handled inside their own region, from most to least critical, and writes one sentence per asset justifying its place: what it is worth to an attacker, how far the damage spreads if it is lost, and which security property the loss breaks. Assets that appear in both regions are expected; note them, because they are the first crossings you will have to agree on.
-
Working separately, each analyst draws their own region as a partial data flow diagram: every component they own as a process or a data store, every actor they own as an external entity, every flow with its direction and the data it carries, and every trust boundary they can see inside their region.
-
Meet and agree, in writing, on the flows that cross between your regions. Complete one row per crossing before you merge anything:
Flow From (owner) To (owner) Data carried Trust level each side Crosses a trust boundary? List each crossing once per direction, because a data flow is directional and a request and its response are two flows with two different destinations. At minimum this table has a row for Backend API Server to Database and Database back to Backend API Server, Backend API Server to Email Service and Email Service on to the Customer, Backend API Server to External Payment Processor and the confirmation returning from it, and Admin Portal to Database. Neither of you can fill this table alone: each of you knows one end of every crossing, and the trust level on each side is a judgement you have to reach together.
-
Merge your two halves into one diagram using the agreed crossing table, and draw every trust boundary on it as a line the flows cross. Between the two halves the merged diagram must contain at least 4 processes, 2 data stores, 3 external entities, 10 directed data flows and 2 trust boundaries.
Question
Which entry point in your merged DFD represents the highest risk, and why? What combination of threat actors and attack vectors makes it the most attractive target? Answer this once, as a pair, and say whether the entry point you chose is in one analyst’s region or on a crossing between them.
Part 2: Applying STRIDE to the DFD
-
Working separately, each analyst applies STRIDE to the elements in their own region of the merged diagram, using the per-element mapping: an external entity can be spoofed and can repudiate, a process can suffer all six, a data store can be tampered with, disclosed, denied or repudiated when it is the log, and a data flow can be tampered with, disclosed or denied. Produce at least one threat per component you own. For the flows that cross between the two regions, the ownership rule from Part 1 decides who writes them: the analyst who owns the destination end of a crossing writes its rows, and the other analyst reviews them in step 3.
-
Complete your half of this table. The example rows below use the base case’s own component names:
Owner Element STRIDE Type Threat Description Proposed Countermeasure Fix or compensating Customer-channel Frontend Web App (login form) Spoofing An attacker submits credentials obtained from an unrelated breach and is accepted as the customer Multi-factor authentication on login; rate limiting and lockout per account and per source address MFA is a fix; rate limiting is compensating Back-office Database Tampering Transaction records altered after the fact by a party holding database access Append-only storage for the transaction log with per-entry hash chaining Fix Back-office Transaction log (data store) Repudiation A customer denies having ordered a transfer, and the audit trail could have been edited by the staff who administer it Each transfer event shipped as it is written to a log system under separate control Fix Back-office (owns the destination end) Backend API Server to Database flow Information Disclosure Account balances and personal details read in transit between the API server and the database Encrypted connections between the two, with the database refusing unencrypted ones Fix -
Swap tables. Each analyst reads the other’s half against the per-element mapping and flags any element that has no row for a category the mapping says can apply to it. Add the rows that survive that review, then merge both halves into one table.
Question
Looking at the merged STRIDE table, which category has the most threats in this system? What does this pattern reveal about its design weaknesses? Does the answer change if you look at each analyst’s half separately, and what does that tell you about the two regions?
Part 3: Risk analysis with DREAD
-
Before either of you scores anything, agree one anchor table and write it down. For each of the five criteria, state what a 1, a 5 and a 10 mean for this system. You will both use these anchors and nothing else; scores produced under different anchorings are not comparable. The theory anchors three of the criteria for you, Damage, Affected Users and Exploitability, so you only have to agree Reproducibility and Discoverability yourselves. Expect those two to be where your independent scores diverge most in step 4, and expect Discoverability to be the hardest to anchor, for the reason the theory gives.
Criterion 1 means 5 means 10 means -
Each analyst selects 2 to 3 threats from their own half of the merged STRIDE table and hands the other analyst the element and threat description only, with no scores attached.
-
Score the threats you received against the agreed anchors, without discussing them with the author first. The author scores the same threats independently.
-
Exchange scores. For every criterion where your two numbers differ by 3 or more, record which anchor the two of you read differently, then agree a single reconciled number and note what settled it.
-
Apply the DREAD formula to the reconciled scores and order all selected threats by result:
(D + R + E + A + D) / 5 = Total Risk -
Discuss which threats should be mitigated first, and say whether the order you would actually recommend matches the numeric order.
Question
Did the DREAD scores change how you would prioritize threats compared to your initial intuition? Which criterion had the greatest influence on the final ranking? Separately: on which criterion did your two independent scores diverge most, and was the cause a disagreement about the system or an anchor that could be read two ways?
Part 4: Documentation and export
- Export the merged DFD as
.pngor PDF, with both analysts’ names and the region each one owned marked on the diagram or in its caption. - The crossing table, the merged STRIDE table, the anchor table and the DREAD table go inside the report document rather than as separate files.
- Write one mini report between you, following the technical report structure from class 03: system description, DFD, merged threats table, the anchors you agreed, DREAD scores with the divergences you reconciled, and prioritized countermeasures. For every countermeasure in the priority list, say whether it is a fix or a compensating control, and where it is compensating, name the fix it is standing in for.
Submission
- Merged Data Flow Diagram (
.pngor.pdf), with trust boundaries drawn and both regions marked - The agreed boundary-crossing flow table
- Merged STRIDE table with at least 8 different threats, at least 3 contributed by each analyst, with the Owner and Fix-or-compensating columns filled
- The agreed DREAD anchor table
- DREAD table showing both independent scores, the reconciled score, and the resulting priority order
- Mini report with findings
Key concepts
| Term | Definition |
|---|---|
| STRIDE | Threat categorization model: Spoofing, Tampering, Repudiation, Information Disclosure, DoS, Elevation of Privilege |
| DREAD | Threat prioritization model based on five risk criteria |
| DFD | Data flow diagram that visualizes how information flows through a system |
| PASTA | Threat modeling methodology oriented toward enterprise risk management |