Learn why professional defenders use threat modeling before and during design, change, integration, detection, recovery, and risk review. Build a fictional foundation that makes system context, assumptions, misuse possibilities, uncertainty, mitigations, evidence, ownership, and review decisions visible without teaching operational attack steps.
Lesson Progress
High School Advanced • A3: Threat Modeling • Lesson 1 of 10
Readiness Check
0/6 ready
Professional Hook
A fictional Northbridge team is nearly ready to launch a student-support portal. The architecture diagram looks complete, but no one has formally asked which data and service outcomes matter most, how account reset and document reprocessing could be misused, what happens when notifications and identity recovery fail together, which supplier assumptions are unverified, or who owns residual risk. Threat modeling exists so those questions become visible while teams can still change the design, requirements, controls, evidence, workflow, and ownership.
Late reactive thinking
Build the fictional system, assume familiar patterns are safe, add tools, and wait for an incident, audit, privacy concern, or failed recovery to reveal hidden design questions.
Threat-model thinking
Define the decision, understand the fictional system, challenge assumptions, describe safe misuse outcomes, rank concerns, choose mitigations, assign owners, and maintain the model as the system changes.
Objective 1
Explain threat modeling as a structured defensive decision process that helps teams understand a fictional system before choosing controls.
Objective 2
Distinguish a threat model from an attack plan, vulnerability scan, risk register, architecture diagram, compliance checklist, and security guarantee.
Objective 3
Define a safe fictional modeling purpose, scope, stakeholders, assumptions, exclusions, evidence needs, and review triggers.
Objective 4
Connect threat modeling to design, change review, privacy, resilience, detection, response, recovery, governance, and risk ownership.
Objective 5
Create a portfolio-ready fictional Threat-Model Charter using only invented organizations, systems, identities, data, diagrams, evidence, decisions, dates, and outcomes.
Why This Matters
Teams often use the same words while imagining different systems. One person thinks the portal is only a website. Another includes the identity provider, notification service, document processor, supplier, backup, logging, support workflow, and archival process. Threat modeling creates a structured shared view and then asks how valuable outcomes, trust, authority, data, dependencies, failures, and controls interact. The result is not certainty. The result is a better documented decision.
Change fictional requirements, roles, interfaces, data fields, trust boundaries, and dependencies before they become expensive.
Show which concerns, assumptions, mitigations, evidence needs, tradeoffs, and residual risks require owner decisions.
Update the fictional model when architecture, suppliers, data, controls, incidents, recovery exercises, or user needs change.
Core Concept
A useful fictional threat model connects a defined decision to system context, assets, actors, entry points, data flows, trust boundaries, safe abuse cases, assumptions, evidence, risk ranking, mitigations, owners, validation, residual risk, and review triggers. A long list of threats without those connections may look detailed while remaining difficult to act on.
Describe the fictional mission, system, users, assets, actors, workflows, data, dependencies, and trust.
Ask safe outcome-focused questions about misuse, failure, error, privilege, privacy, suppliers, evidence, and recovery.
Rank concerns and compare fictional design, prevention, detection, response, recovery, governance, and communication options.
Track owners, assumptions, validation, residual risk, revisions, disagreements, triggers, and retirement.
Threat-Model Purposes
Professional question
What fictional mission, users, assets, components, identities, data, workflows, dependencies, and boundaries exist?
Decision value
Teams can discuss the same system instead of protecting different mental pictures.
Failure if missing
Controls are chosen for an incomplete or incorrect understanding of the system.
Fictional artifact
System context and scope statement
Professional question
Which fictional identities, suppliers, interfaces, workflows, locations, defaults, and recovery paths are being trusted without enough evidence?
Decision value
Uncertainty becomes visible and reviewable rather than silently becoming architecture.
Failure if missing
Unverified assumptions are treated as facts until a change or failure reveals them.
Fictional artifact
Assumption and unknown register
Professional question
Which fictional decisions should be reconsidered before implementation, deployment, integration, or approval?
Decision value
The team can change a diagram, requirement, role, interface, or workflow before changes become expensive.
Failure if missing
Risk is discovered only after deployment, audit, incident, or failed recovery.
Fictional artifact
Design question and decision log
Professional question
Which fictional scenarios matter most when mission impact, likelihood, exposure, control strength, uncertainty, and recoverability are considered together?
Decision value
Resources are directed toward the most decision-relevant concerns rather than the longest list.
Failure if missing
Every concern appears equally urgent or dramatic language controls priority.
Fictional artifact
Threat-risk ranking rationale
Professional question
Which fictional preventive, detective, response, recovery, privacy, governance, and communication controls address each concern?
Decision value
Mitigations become traceable and gaps between layers are easier to identify.
Failure if missing
Teams list products or policies without knowing which modeled problem they address.
Fictional artifact
Threat-to-mitigation map
Professional question
What fictional events, failures, denied actions, state changes, source-health records, and business outcomes must be observable?
Decision value
Visibility is designed around defender questions before an incident occurs.
Failure if missing
The system may block or fail without enough evidence to understand what happened.
Fictional artifact
Evidence and detection requirements
Advanced Vocabulary
A structured fictional process for understanding what matters, how a system works, what could go wrong, which safeguards exist, what remains uncertain, and which defensive decisions deserve priority.
The exact fictional decision, design, change, review, or risk question that the threat model is expected to support.
The fictional systems, environments, users, data, interfaces, suppliers, workflows, locations, and time period included in the model.
A fictional component, environment, question, data set, or responsibility deliberately left outside the current model and documented for later review.
A fictional data set, identity, service, capability, device, process, relationship, reputation, safety outcome, or recovery function that has value and requires protection.
A fictional human, service, device, workload, supplier, administrator, automation, or unknown party that interacts with the system.
An approved fictional interface through which data, requests, identities, files, messages, commands, or administrative actions enter a system.
A fictional movement of information or requests between actors, processes, services, stores, zones, and external dependencies.
A fictional point where identity, authority, ownership, sensitivity, technology, location, administration, or control assumptions change.
A safe, outcome-focused fictional description of how a legitimate feature, permission, workflow, dependency, or assumption could produce harm or policy failure.
A defensive question used to test an assumption, boundary, asset, workflow, or control without providing operational instructions for causing harm.
A fictional design, prevention, detection, response, recovery, governance, privacy, communication, or process safeguard chosen to reduce a modeled concern.
The fictional risk that remains after selected mitigations are applied and validated.
A fictional condition treated as true for the model even though it may require evidence, an owner, an expiration date, or later validation.
A fictional question that cannot yet be answered with the supplied evidence and must remain visible rather than being guessed.
A documented fictional estimate of how reliable the model is based on scope, evidence, stakeholder participation, assumptions, freshness, and review quality.
Professional Lifecycle
The workflow is iterative rather than perfectly linear. New fictional evidence may change scope, context, assumptions, ranking, mitigations, ownership, or confidence. The important professional habit is to make each change visible and traceable.
Which fictional design, feature, integration, service, workflow, policy, or change must the model help someone decide?
Output
Decision statement, audience, owner, deadline, and success criteria.
Evidence
Project brief, approved change record, architecture objective, policy requirement, or risk question.
Stop condition
Pause if the team cannot explain what decision the model will support.
Which fictional systems, environments, users, data, suppliers, interfaces, workflows, and time periods are included or excluded?
Output
Scope map, exclusions, authorization boundary, safety statement, and privacy limits.
Evidence
Fictional ownership records, design documents, data-purpose notes, and stakeholder approval.
Stop condition
Do not let scope expand silently during the workshop.
What must the fictional service accomplish, who depends on it, and what outcomes must remain confidential, accurate, available, private, safe, and recoverable?
Output
Mission, critical outcomes, user groups, context diagram, and operating assumptions.
Evidence
Fictional service catalog, user journeys, continuity requirements, owner interviews, and privacy purpose.
Stop condition
Do not begin with a generic threat checklist before understanding the system.
What fictional value requires protection, who or what interacts with it, and through which approved interfaces?
Output
Asset, actor, entry-point, owner, and dependency register.
Evidence
Fictional inventories, role maps, interface lists, service diagrams, and workflow records.
Stop condition
Avoid treating only servers and databases as assets.
How do fictional data and requests move, and where do identity, authority, sensitivity, ownership, technology, or administration assumptions change?
Output
Data-flow diagram, stores, processes, transfer paths, trust boundaries, and validation points.
Evidence
Fictional architecture views, API descriptions, workflow maps, data inventories, and supplier interfaces.
Stop condition
Do not assume a diagram proves actual behavior or complete coverage.
How could a fictional feature, permission, dependency, workflow, default, failure, or assumption produce an unsafe outcome?
Output
Outcome-focused abuse cases and defensive threat questions without operational harmful detail.
Evidence
Fictional failure history, design reviews, support issues, policy exceptions, and stakeholder concerns.
Stop condition
Do not write step-by-step instructions for causing harm.
Which fictional concerns matter most based on impact, likelihood, exposure, control strength, uncertainty, mission importance, privacy, safety, and recoverability?
Output
Prioritized threat-risk register with rationale, confidence, and owner review.
Evidence
Fictional control evidence, dependency data, incident lessons, business impact, recovery exercises, and assumptions.
Stop condition
Do not present an unsupported score as objective truth.
Stakeholder Model
Contribution
Explains fictional critical outcomes, users, value, acceptable disruption, priority, and business consequences.
Questions
Which functions must continue? Which harms matter most? Which residual risks require leadership decisions?
Decision ownership
Accepts or rejects business tradeoffs and residual risk.
Contribution
Structures the fictional workshop, maps relationships, challenges assumptions, documents decisions, and protects scope and safety.
Questions
Does the model connect mission, assets, actors, flows, boundaries, threats, controls, evidence, and owners?
Decision ownership
Recommends whether the model is ready for review and where deeper work is required.
Contribution
Explains fictional components, interfaces, dependencies, states, errors, maintenance, deployment, support, and recovery behavior.
Questions
What does the service actually do? Which paths and dependencies are required? Which assumptions are outdated?
Decision ownership
Confirms technical context and owns system changes.
Contribution
Explains fictional human, service, device, workload, supplier, emergency, and recovery identities.
Questions
Who may do what, to which resource, for what purpose, under which conditions, for how long, and with which evidence?
Decision ownership
Approves identity and privilege requirements.
Contribution
Explains fictional data purpose, fields, classification, users, sharing, retention, deletion, and privacy consequences.
Questions
Is each data element necessary? Who owns it? Which flows and uses are authorized?
Decision ownership
Approves data purpose and privacy safeguards.
Contribution
Explains fictional zones, connectivity, platform services, administrative paths, supplier connections, availability, and monitoring.
Questions
Which paths are required, denied, temporary, privileged, monitored, resilient, and recoverable?
Decision ownership
Owns platform and connectivity controls.
Quality Principles
Strong practice
The fictional model begins with a clear decision, owner, audience, deadline, and success criteria.
Weak practice
The team creates a large threat list with no clear use.
Evidence
Charter, decision statement, review agenda, and approved deliverables.
Strong practice
Mission, users, workflows, assets, actors, data, dependencies, and trust are understood before categories or controls are applied.
Weak practice
Generic threat labels are copied onto an unfamiliar system.
Evidence
System context, user journeys, inventories, data-flow diagram, and owner review.
Strong practice
Included and excluded fictional systems, environments, data, suppliers, workflows, and time periods are visible.
Weak practice
The workshop silently expands until no conclusion is reliable.
Evidence
Scope statement, exclusion register, authorization boundary, and change log.
Strong practice
Safe fictional abuse cases describe affected assets, conditions, outcomes, evidence, and controls without operational harmful detail.
Weak practice
The model becomes a procedure for causing harm.
Evidence
Abuse-case template, facilitator review, safety statement, and revised wording.
Strong practice
Facts, interpretations, assumptions, hypotheses, unknowns, source health, and confidence remain separate.
Weak practice
A diagram, alert, score, or stakeholder opinion is treated as proof.
Evidence
Evidence matrix, source notes, limitation fields, and confidence rationale.
Strong practice
Fictional assets connect to flows, boundaries, concerns, mitigations, owners, validation, and residual risk.
Weak practice
Controls cannot be connected to the modeled concern they supposedly address.
Evidence
Traceability map, identifiers, decision records, and validation plan.
Fictional System Context
The following visual is an invented training model. It shows enough context to ask defensive questions, but it does not prove real configuration, authorization, effective permissions, control behavior, supplier commitments, or complete data flows.
Students and families
Submit fictional documents, review status, receive messages, and request help.
Counselors
Review fictional submissions and communicate decisions.
Support staff
Assist with accounts, status, notifications, and approved reprocessing.
Fictional service boundary
Identity provider
Authenticates fictional human and service identities.
Processing supplier
Returns fictional document-processing results.
Notification service
Delivers fictional status messages through approved channels.
Archive and backup
Preserves fictional records and supports restoration.
Fake Dashboard
Fictional scope, stakeholder, evidence, assumption, and review status for training only.
Context completeness
62%
Core services are listed, but support workflows, supplier failure, archival deletion, and recovery communication remain incomplete.
Open assumptions
9
Field necessity, privilege need, retry behavior, supplier retention, source health, and recovery dependencies require owners.
Model status
Draft
The fictional model is useful for questions but not ready for final ranking or design approval.
Fake SOC Alert
Source: Fake Northbridge Design Governance Console • Time: 11:24 AM
Fake Log Panel
09:00 PROJECT portal='student-support' phase='pre-release' 09:08 DECISION launch-approval='requested' model='not-complete' 09:16 CONTEXT systems='portal,idp,processor,notify,storage,logs,backup' 09:24 WORKFLOW account-reset='documented' reprocessing='partial' 09:31 DATA supplier-fields='status,reference,result' owner-approval='missing' 09:38 IDENTITY support-role='broad' exact-need='unconfirmed' 09:44 LOGGING notification-change='actor-context-missing' 09:51 RECOVERY portal='restored' notifications='delayed' duplicates='observed' 09:58 PRIVACY archival-deletion='not-modeled' 10:05 SUPPLIER retention='unknown' failure-mode='unknown' 10:12 ASSUMPTIONS open='9' expired='2' 10:20 STAKEHOLDER privacy-owner='missing' recovery-owner='assigned' 10:28 REVIEW model-confidence='medium-low' 10:36 ACTION charter='required' scope='required' 10:44 ACTION launch-approval='paused' 11:00 WORKSHOP date='scheduled' participants='cross-functional' 11:24 STATUS threat-model='draft' final-ranking='not-ready'
Training note: this is fake data for defensive analysis practice only.
Fictional Evidence Matrix
Observation
Northbridge plans a student-support portal for document submission, counselor review, notifications, and archival status.
Supports
A threat model can help decide how identity, privacy, workflow, availability, integrity, support, and recovery should be designed.
Does not prove
The brief does not define every component, flow, role, interface, data field, supplier, or control.
Threat-model use
Create the decision statement, initial scope, stakeholders, mission outcomes, and evidence requests.
Observation
The portal connects to identity, document processing, notification, storage, logging, backup, and a supplier service.
Supports
Multiple fictional systems and external dependencies belong in the context discussion.
Does not prove
The diagram does not prove actual communication paths, effective permissions, data fields, monitoring, or failure behavior.
Threat-model use
Identify assets, actors, entry points, data flows, boundaries, assumptions, and owners that require confirmation.
Observation
A support role can reset accounts, view submission status, modify notification settings, and initiate document reprocessing.
Supports
Privilege concentration, approval, evidence, separation-of-duty, lifecycle, and recovery questions deserve review.
Does not prove
The summary does not prove misuse, effective permissions, or whether all actions are necessary.
Threat-model use
Create identity and workflow threat questions while requesting exact role and business-purpose evidence.
Observation
The proposed supplier receives document status, student reference code, and processing result, but field necessity is not approved.
Supports
Data minimization, purpose, supplier trust, retention, access, evidence, and exit require decisions.
Does not prove
The note does not prove which fields will be implemented or whether alternative designs exist.
Threat-model use
Open assumptions and require the data owner to approve a minimum field set before final ranking.
Observation
A rejected document can be resubmitted, reprocessed, reviewed, notified, and archived through several state changes.
Supports
Integrity, authorization, duplicate action, stale state, error handling, evidence, and user communication are connected.
Does not prove
The workflow map does not prove every exception, race condition, retry, or recovery path.
Threat-model use
Develop outcome-focused abuse cases and state-transition questions without operational harmful detail.
Analyze the Evidence
Common Mistakes
Safe Practice Lab
Fictional assignment
Use only the invented Northbridge records on this page. Your charter should tell every participant what decision the model supports, what is included, what is excluded, what evidence is available, what remains uncertain, which safety rules apply, and how the model will be reviewed and maintained.
Required deliverables
Scenario Decision Lab
A fictional project team has not agreed on the portal decision, scope, users, data, workflows, suppliers, dependencies, or owners, but it wants to copy a large category checklist into a spreadsheet and begin scoring.
Scenario Decision Lab
A fictional student portfolio reviewer says the threat-model charter will look more authentic if the learner includes a real school network diagram and lightly changes the names.
Advanced Challenge
Create a fictional confidence method for the Northbridge threat model. Your method must consider scope completeness, stakeholder participation, evidence quality, source health, assumptions, unknowns, change freshness, review depth, disagreement, mitigation traceability, and unresolved owner decisions. Do not collapse all of those factors into one unexplained number.
Required analysis
Rate each confidence factor separately, explain the evidence and limitations, and identify which missing input could change the model most.
Required decision
State whether the fictional model is suitable for questions, preliminary prioritization, mitigation planning, design approval, or only further discovery.
Required trigger
Define which evidence, stakeholder review, architecture change, incident lesson, supplier update, or expired assumption requires reassessment.
Required communication
Write one leadership statement that explains confidence without exaggerating certainty or hiding important unknowns.
Defender Habits
Check Your Understanding
Choose your answers first. Explanations appear only after submission.
Portfolio Prompt
Create a fully fictional Threat-Model Charter for the Northbridge Student-Support Portal. Include the decision, audience, owner, deadline, mission, critical outcomes, scope, exclusions, safety boundary, users, systems, data, workflows, suppliers, stakeholders, evidence sources, evidence limitations, assumptions, hypotheses, unknowns, confidence method, planned modeling steps, safe abuse-case rule, expected outputs, review process, disagreement process, approval path, version history, maintenance triggers, retirement criteria, reflection, and a statement that every organization, system, identity, asset, actor, interface, diagram, evidence source, owner, decision, date, and outcome is invented.
Confidence / Readiness Reflection
Before moving to A3.2, rate your readiness from 1 to 5 for each area: modeling purpose, decision statement, scope, exclusions, stakeholder participation, evidence quality, assumptions, safe misuse wording, confidence, maintenance, and complete fictionalization.
Key Takeaways
Navigation
Next, identify the fictional assets that require protection, the human and non-human actors that interact with them, and the approved entry points through which data, requests, identity, files, and administrative actions enter the system.