W — Write the charter
Define fictional decision, scope, roles, evidence, outputs, criteria, and safety.
High School AdvancedModule A3Lesson 10 of 10Capstone Workshop Lab
A3.10 Threat Modeling Workshop Lab
Combine the full A3 workflow in one completely fictional, professional workshop. Build system context, asset and actor registers, flow and trust-boundary maps, abuse cases, categories, risk rankings, mitigation packages, assumptions, limitations, peer-review findings, sign-off decisions, and a maintainable public portfolio package.
Lesson Progress
Threat Modeling Workshop Lab
High School Advanced • A3: Threat Modeling • Lesson 10 of 10
100% complete
Readiness Check
Before You Start
0/6 ready
Professional Hook
The Workshop Must Produce Decisions, Not Just Diagrams
A fictional Northbridge team enters a workshop with an architecture diagram, a queue-delay dashboard, several support tickets, a supplier-field inventory, a service-identity review, and one recovery exercise. The evidence is useful but incomplete. The team must decide which risks are ready to rank, which controls are justified, which assumptions block decisions, and what must be reviewed before sign-off.
Weak workshop outcome
A polished diagram, a list of “critical threats,” and generic recommendations with no evidence, owners, uncertainty, recovery, completion criteria, or review triggers.
Strong workshop outcome
A traceable fictional package that identifies decision-ready, conditional, and blocked areas and assigns evidence, mitigations, owners, closure criteria, residual risk, and maintenance triggers.
The workshop succeeds when authorized fictional owners can explain what the model supports, what it does not prove, what must change, and when the model must be reviewed again.
Exactly Five Learning Objectives
What You Will Be Able to Do
Objective 1
Integrate the complete fictional threat-modeling lifecycle from scope and system context through assets, actors, entry points, flows, trust boundaries, abuse cases, categories, risk ranking, mitigation, assumptions, review, and maintenance.
Objective 2
Produce decision-ready fictional artifacts that preserve evidence, uncertainty, ownership, privacy, safety, recovery, and current-versus-future-state distinctions.
Objective 3
Facilitate a multidisciplinary fictional workshop that captures disagreement, evidence gaps, blocked decisions, review findings, completion criteria, and residual risk without blaming people or assuming intent.
Objective 4
Evaluate fictional threat-model quality through traceability, consistency, coverage, evidence provenance, control maturity, recovery readiness, assumption maintenance, and safe-publication review.
Objective 5
Assemble a portfolio-ready fictional threat-model package that is ethical, defensive, authorized, non-operational, privacy-safe, evidence-aware, maintainable, and completely invented.
Why This Matters
Integration Reveals Gaps That Individual Worksheets Can Hide
A fictional asset register may look strong while a related data flow is missing. A High risk may appear justified until reviewers notice that control evidence is only planned. A mitigation may look complete until recovery and privacy owners identify new dependencies. The workshop connects these pieces and exposes where decisions do not yet align.
Integration
Connect fictional mission, architecture, evidence, scenarios, risk, mitigation, assumptions, review, and maintenance.
Decision quality
Distinguish what is ready, conditional, blocked, accepted, provisional, or reopened.
Portfolio value
Demonstrate professional defensive reasoning without exposing or testing any real system.
Core Framework
The W-O-R-K-S-H-O-P Method
O — Outline the system
Map mission, assets, actors, interfaces, flows, boundaries, dependencies, states, and exclusions.
R — Reason through misuse
Create safe fictional abuse cases, categories, alternatives, and intent uncertainty.
K — Know the risk
Assess impact, likelihood, exposure, controls, uncertainty, confidence, priority, urgency, and recovery.
S — Select mitigations
Choose layered design, prevention, detection, response, recovery, privacy, governance, communication, and evidence controls.
H — Highlight assumptions
Record fictional beliefs, unknowns, evidence limits, confidence, consequences, owners, expiration, and triggers.
O — Obtain peer challenge
Review traceability, consistency, evidence, categories, risk, controls, recovery, ownership, safety, and maintenance.
P — Package and preserve
Deliver leadership and technical outputs with versions, closure evidence, residual risk, dates, owners, and review triggers.
Advanced Vocabulary
Terms for the Full Workshop
Workshop charter
A fictional agreement defining the decision, scope, participants, roles, evidence, timeline, outputs, methods, and safety boundary.
System context
A fictional high-level view of mission, users, services, data, identities, suppliers, environments, dependencies, and external relationships.
Asset register
A fictional inventory of mission, data, identity, service, privacy, evidence, safety, trust, and recovery values that require protection.
Actor register
A fictional inventory of human, service, supplier, automated, administrative, support, emergency, and recovery actors defined by relationship and authority.
Entry-point inventory
A fictional list of interfaces through which users, services, suppliers, files, messages, support actions, administrators, monitors, and recovery processes interact.
Flow register
A fictional record of source, destination, purpose, data, identity, validation, timing, state, trust, evidence, failure, and recovery for each important movement.
Trust-boundary decision
A fictional explanation of what changes in authority, ownership, identity, validation, data, evidence, or responsibility when a flow crosses a boundary.
Abuse case
A safe fictional description of how a legitimate capability, workflow, identity, interface, or process could produce an unsafe outcome without operational harmful instructions.
Threat category
A conceptual fictional label that organizes defensive questions without proving event, intent, control failure, exploitability, or severity.
Risk rationale
A fictional explanation connecting scenario, impact, likelihood, exposure, controls, uncertainty, mission context, recovery, confidence, and priority.
Mitigation package
A fictional set of complementary design, preventive, detective, response, recovery, privacy, governance, communication, and evidence controls.
Assumption register
A fictional record of precise, testable beliefs with evidence, confidence, owner, consequence, expiration, validation, and review triggers.
Limitations register
A fictional record of scope, evidence, time, method, supplier, control, human, prediction, recovery, and publication limits.
Review finding
A fictional quality observation with criterion, decision impact, evidence, limits, owner, completion criterion, status, and trigger.
Traceability chain
The fictional connection from mission and assets through actors, interfaces, flows, boundaries, scenarios, categories, risks, controls, assumptions, owners, and review.
Decision-ready
A fictional state in which enough scope, evidence, ownership, uncertainty, rationale, and authority exist to support a responsible choice.
Conditional decision
A fictional choice that may proceed only while named assumptions, controls, evidence actions, deadlines, owners, and review conditions remain satisfied.
Blocked decision
A fictional choice that cannot proceed responsibly because scope, evidence, ownership, control state, or uncertainty is insufficient.
Residual risk
The fictional risk remaining after supported mitigation effects, limitations, dependencies, uncertainty, recovery, and owner decisions are considered.
Closure evidence
Fictional evidence showing that a review action or mitigation completion criterion has been met.
Change trigger
A fictional event that requires a model or decision to be revisited, such as an architecture, identity, supplier, data, control, recovery, ownership, or mission change.
Workshop retrospective
A fictional reflection on what the team learned, missed, debated, improved, deferred, and must change in the next review.
Safe publication review
A fictional quality check confirming that a public artifact is completely invented, non-operational, privacy-safe, and free of real targets or sensitive details.
Threat-model package
The complete fictional collection of workshop outputs, decisions, evidence, registers, findings, leadership summary, technical appendix, and maintenance plan.
Workshop Phase Map
Ten Phases from Charter to Maintenance
1. Charter and safety
Define the fictional decision, scope, participants, roles, evidence package, deliverables, review criteria, timeline, and non-operational safety boundary.
Core questions
What decision must this workshop support? What is included, excluded, current, future, temporary, degraded, and recovery state?
Outputs
Workshop charter, safety statement, participant roles, evidence index, schedule, and decision-rights map.
Quality check
The workshop never claims to certify perfect security or authorize activity on real systems.
2. Mission and assets
Identify fictional mission, user, data, identity, service, privacy, evidence, safety, trust, supplier, and recovery values.
Core questions
What must remain correct, available, private, attributable, recoverable, understandable, and trusted?
Outputs
Asset register, value statements, owners, classification, dependencies, and impact dimensions.
Quality check
Assets include human and business outcomes rather than only technical components.
3. Actors and authority
Map fictional human, service, supplier, automated, support, administrative, emergency, and recovery actors.
Core questions
Who or what acts, under which identity, role, object scope, conditions, lifecycle, approval, and evidence?
Outputs
Actor register, authority map, service-identity list, ownership gaps, and lifecycle assumptions.
Quality check
Actors are described by relationship and authority, not labeled as malicious.
4. Entry points, flows, and trust
Map fictional interfaces, data movement, administrative relationships, and trust changes.
Core questions
Where does information or authority enter, leave, change owners, cross environments, or depend on another service?
Outputs
Entry-point inventory, flow register, trust-boundary map, data-purpose table, source-health notes, and recovery flows.
Quality check
Each flow explains purpose, data, identity, state, validation, evidence, failure, and recovery—not only arrows.
5. Abuse cases and categories
Create safe fictional scenarios across deliberate, accidental, process, supplier, automation, usability, degraded, and recovery conditions.
Core questions
How could legitimate capabilities produce unsafe outcomes? Which conceptual categories organize the decision?
Outputs
Abuse-case register, category rationale, uncategorized concerns, and intent-uncertainty notes.
Quality check
Scenarios remain outcome-focused, defensive, fictional, and non-operational.
6. Risk ranking
Compare fictional impact, likelihood, exposure, control strength, uncertainty, recovery, confidence, priority, and urgency.
Core questions
Which scenarios require attention first, what evidence supports the ranking, and what remains uncertain?
Outputs
Inherent and residual risk register, criteria guide, disagreement log, confidence statements, and blocked decisions.
Quality check
Category, impact, likelihood, intent, control state, uncertainty, priority, and urgency remain separate.
7. Mitigation selection
Choose layered fictional design, prevention, detection, response, recovery, privacy, governance, communication, and evidence controls.
Core questions
Which root conditions can be removed, what tradeoffs appear, how can controls fail, and what risk remains?
Outputs
Mitigation decision matrix, selected packages, owners, dependencies, validation plans, and residual-risk decisions.
Quality check
Controls are not treated as effective without design, operating, failure, and recovery evidence.
8. Assumptions and limits
Make fictional observations, interpretations, beliefs, unknowns, exclusions, constraints, confidence, expiration, and consequences visible.
Core questions
Which conclusions depend on incomplete evidence, and what must change if an assumption is false?
Outputs
Assumption register, limitations register, evidence-gap queue, confidence map, and review triggers.
Quality check
Decision-blocking uncertainty is not forced into unsupported scores or conclusions.
9. Peer review and correction
Challenge the fictional model for scope, evidence, traceability, consistency, categories, risk, controls, recovery, assumptions, safety, and maintenance.
Core questions
What would need to be true for a conclusion to be wrong? Which decisions are ready, conditional, blocked, accepted, or reopened?
Outputs
Review findings, action register, completion criteria, closure plan, sign-off matrix, and revision history.
Quality check
Review challenges the model rather than blaming people.
10. Delivery and maintenance
Package the fictional model for leadership, technical readers, portfolio use, and future review.
Core questions
What is the decision, what is blocked, who owns the next action, and what changes trigger review?
Outputs
Leadership summary, technical appendix, portfolio artifact, maintenance calendar, trigger list, and retrospective.
Quality check
Public delivery remains completely invented and clearly states scope, limits, confidence, and safety.
Fictional System Brief
Northbridge Student-Support Cooperative
Organization
Northbridge Student-Support Cooperative, a completely fictional organization created for defensive learning.
Mission
Provide a fictional web portal for support requests, document references, case updates, and authorized communication.
Services
Web portal, identity, support console, document-processing supplier, result queue, notification, monitoring, archive, and recovery.
Actors
Fictional students, support staff, supervisors, administrators, supplier services, service identities, recovery coordinators, privacy owners, and system owners.
Data
Fictional account details, contact preferences, support categories, document references, case state, supplier results, notification state, event evidence, and retention metadata.
Constraints
The fictional supplier cannot be replaced this quarter; the mobile client is outside scope; all exercises use invented data; no real systems may be accessed or tested.
Asset Workshop
Prioritize What the Fictional System Must Protect
Student-support mission outcome
Value
Students receive accurate, timely, understandable, and fair support decisions.
Owner
Fictional student-services owner
Potential harm
Delay, confusion, incorrect status, inaccessible support, duplicate action, or loss of trust.
Evidence
Service objectives, user journeys, support themes, message reviews, and recovery exercises.
Case-state integrity
Value
Case status, required actions, document state, and processing results remain correct and current.
Owner
Fictional workflow owner
Potential harm
Stale, duplicated, reordered, missing, conflicting, or incorrect business state.
Evidence
State transitions, version records, correlation, reconciliation, and support tickets.
Student privacy
Value
Fictional personal and support information is collected, shared, used, retained, and deleted only for approved purposes.
Owner
Fictional privacy and data owner
Potential harm
Unnecessary collection, broad audience, unsupported inference, supplier over-sharing, or excessive retention.
Evidence
Field inventory, purpose records, access, retention, sharing, deletion, and privacy review.
Identity and authority
Value
Human and service actors act under correct, current, bounded, attributable, and recoverable authority.
Owner
Fictional identity owner
Potential harm
Stale roles, unowned service identity, broad support action, weak emergency access, or unclear attribution.
Evidence
Role maps, policy results, access reviews, lifecycle records, approvals, and administrative events.
Service availability and continuity
Value
Portal, identity, processing, notification, evidence, support, and recovery capabilities remain usable when needed.
Owner
Fictional operations owner
Potential harm
Outage, hidden backlog, degraded service, misleading status, or unavailable recovery evidence.
Evidence
Health, queue age, service objectives, support impact, dependency maps, and exercises.
Evidence and accountability
Value
Actions, decisions, approvals, failures, changes, and recoveries can be explained using trustworthy, privacy-aware evidence.
Owner
Fictional evidence owner
Potential harm
Inability to attribute action, validate state, assess controls, recover, or support governance decisions.
Evidence
Event schemas, source health, correlation, tickets, approvals, timestamps, and review history.
Recovery correctness
Value
Technical and business state, identity, notifications, evidence, communication, and trust are restored in a safe order.
Owner
Fictional continuity owner
Potential harm
Service returns with stale state, repeated tasks, broad emergency authority, missing evidence, or incorrect user communication.
Evidence
Recovery plan, restore tests, dependency order, reconciliation, communication, and closure.
Supplier relationship and shared responsibility
Value
External processing has defined purpose, fields, identity, evidence, responsibility, change review, recovery, and exit planning.
Owner
Fictional supplier owner
Potential harm
Unknown processing, excessive data, ambiguous identity, delayed results, weak evidence, or concentrated dependency.
Evidence
Interface records, field inventories, owner statements, change history, service evidence, and recovery terms.
Actor Workshop
Map Relationship, Authority, Evidence, and Lifecycle
Student portal user
Relationship
Fictional person requesting support through the portal.
Authority
Create and view own support cases, upload invented documents, and manage approved communication preferences.
Evidence
Identity event, session context, object ownership, case event, and confirmation.
Open question
How is account recovery separated from routine preference change?
Support analyst
Relationship
Fictional employee assisting assigned student cases.
Authority
View assigned case status, request clarification, update bounded fields, and initiate approved reprocessing.
Evidence
Role, case assignment, support ticket, reason, action, target, result, and user confirmation.
Open question
Which actions require supervisor review or object-level policy?
Support supervisor
Relationship
Fictional owner of higher-impact support decisions and quality review.
Authority
Approve defined exceptions, review sensitive changes, and supervise quality.
Evidence
Approval, independent role, case context, reason, result, and review record.
Open question
How are emergency exceptions expired and reviewed?
Supplier processing service
Relationship
Fictional external service that processes approved document references and returns results.
Authority
Receive minimized request fields and submit results through one documented interface.
Evidence
Service identity, request schema, result schema, correlation, source health, and supplier owner review.
Open question
Is authority delegated to any downstream identity?
Workflow service
Relationship
Fictional internal service that maintains case state.
Authority
Validate and apply approved state transitions.
Evidence
Service identity, state version, policy result, transition event, correlation, and reconciliation.
Open question
How are stale, duplicate, or misordered results handled?
Notification service
Relationship
Fictional service that communicates case status and user actions.
Authority
Send approved messages to approved destinations using minimized content.
Evidence
Template, destination, audience, event, delivery status, preference state, and source health.
Open question
How are stale notifications prevented after recovery?
Archival service identity
Relationship
Fictional non-human identity supporting retention and recovery.
Authority
Perform bounded archival actions on approved records.
Evidence
Owner, purpose, role, schedule, destination, activity, review, and recovery dependency.
Open question
Who currently owns the identity and whether its review is current?
Recovery coordinator
Relationship
Fictional authorized role managing continuity events.
Authority
Invoke approved recovery workflows, coordinate owners, validate state, and close emergency access.
Evidence
Event trigger, approval, action, source artifact, validation, reconciliation, communication, and closure.
Open question
Which actions require independent approval during degraded operation?
Flow and Boundary Workshop
Trace Purpose, Identity, State, Evidence, Failure, and Recovery
FL-01
Student portal user → Web portal
Purpose
Create a fictional support request.
Data
Account reference, support category, minimized description, document reference, and contact preference.
Controls
Identity, object ownership, required fields, input validation, duplicate handling, confirmation, and evidence.
Failure
Invalid, duplicate, incomplete, or confusing request state.
Recovery
Correct request state, preserve user intent, explain status, and reconcile duplicates.
FL-02
Web portal → Supplier processing service
Purpose
Request fictional document processing.
Data
Case reference, approved processing category, document reference, priority, and only approved optional fields.
Controls
Service identity, minimized schema, destination restriction, correlation, purpose, access, retention, and supplier review.
Failure
Excessive field, wrong destination, delayed request, or unclear supplier state.
Recovery
Pause unsafe field, correct request, reconcile result, and review supplier handling.
FL-03
Supplier processing service → Result queue
Purpose
Return a fictional processing result.
Data
Case reference, result category, result state, confidence, timestamp, version, and correlation.
Controls
Source identity, schema, freshness, ordering, duplicate detection, queue health, and evidence.
Failure
Delayed, stale, duplicate, misordered, malformed, or uncorrelated result.
Recovery
Quarantine uncertain result, review, reconcile state, correct notifications, and close evidence.
FL-04
Result queue → Workflow service
Purpose
Apply an approved fictional state transition.
Data
Validated result, current state version, target transition, correlation, and reason.
Controls
State compatibility, object check, version, idempotence, policy, event, and reconciliation.
Failure
Incorrect state update, duplicate action, or hidden backlog.
Recovery
Restore correct state, remove duplicate effects, notify owners, and document resolution.
FL-05
Workflow service → Notification service
Purpose
Create a fictional user-facing case update.
Data
Approved message type, minimized status, required action, destination reference, and preference state.
Controls
Template approval, audience restriction, state freshness, preference check, accessibility, delivery evidence, and correction.
Failure
Stale, excessive, inaccessible, delayed, or misdirected communication.
Recovery
Suppress stale message, send correction, restore preference, and update support guidance.
FL-06
Support console → Workflow and notification services
Purpose
Perform an approved fictional support change.
Data
Actor, assigned case, reason, action, old state, new state, confirmation, approval, and result.
Controls
Role, object assignment, verification, required reason, approval, confirmation, evidence, and quality review.
Failure
Unsupported change, missing evidence, incorrect state, or user communication error.
Recovery
Review action, restore correct state, confirm with user, and record outcome.
FL-07
Portal and connected services → Monitoring service
Purpose
Provide minimized fictional defensive evidence.
Data
Actor type, action type, target reference, result, state, timing, source health, correlation, and control outcome.
Controls
Purpose limitation, field minimization, access, retention, source health, event quality, correlation, and review.
Failure
Noise, missing context, unhealthy evidence, over-collection, or false confidence.
Recovery
Restore evidence pipeline, mark blind period, use alternate evidence, and review affected decisions.
FL-08
Recovery service → Connected services
Purpose
Restore fictional service and business state.
Data
Recovery trigger, source artifact, configuration baseline, state record, identity, dependency status, validation, and closure.
Controls
Strong recovery identity, approval, trusted baseline, order, integrity, reconciliation, communication, emergency-access revocation, and review.
Failure
Technical service returns with stale business state, repeated tasks, broad authority, or missing evidence.
Recovery
Re-enter degraded mode, correct sequence, reconcile, communicate, and document lessons.
Abuse-Case Workshop
Create Safe Fictional Misuse Scenarios
AB-01
Stale supplier result changes current case state
Actor context
Fictional supplier service, result queue, and workflow service.
Preconditions
Result delay, changed case state, incomplete freshness or state-version validation.
Potential outcome
Incorrect case status, duplicate action, misleading communication, support burden, or trust loss.
Categories
Primary integrity; secondary availability, dependency, accountability, resilience.
Evidence
Queue delay, support pattern, state records, source-health dashboard, and recovery exercise.
Unknowns
Current ordering, reconciliation, duplicate handling, and production frequency.
AB-02
Free-text support note crosses supplier boundary
Actor context
Fictional support workflow, portal service, and processing supplier.
Preconditions
Field exists, may be populated, and purpose or minimization is unresolved.
Potential outcome
Unnecessary data sharing, broad audience, unsupported retention, or privacy expectation harm.
Categories
Primary privacy; secondary confidentiality, governance, supplier dependency.
Evidence
Supplier-field inventory and proposed request schema.
Unknowns
Current use, purpose, access, retention, and downstream processing.
AB-03
Unowned archival service identity remains active
Actor context
Fictional archival service identity and recovery workflow.
Preconditions
Missing owner, expired review, unclear current purpose or scope.
Potential outcome
Unreviewed authority, weak attribution, retention error, or recovery dependency uncertainty.
Categories
Primary governance; secondary identity, authorization, accountability, recovery.
Evidence
Service-identity record, service catalog, and recovery reference.
Unknowns
Current owner, authority, activity, delegation, and retirement need.
AB-04
Support notification change lacks verification and confirmation evidence
Actor context
Fictional support analyst, student user, and notification service.
Preconditions
Action permitted by role, but reason or user-confirmation fields are incomplete.
Potential outcome
Incorrect preference, missed message, privacy expectation change, or support dispute.
Categories
Primary accountability; secondary authorization, privacy, integrity, governance.
Evidence
Support ticket review and role matrix.
Unknowns
Actual authorization, correctness, user impact, and actor intent.
AB-05
Recovery returns application before dependencies are ready
Actor context
Fictional recovery coordinator and connected services.
Preconditions
Restore sequence emphasizes application availability before queue, notification, archive, and evidence validation.
Potential outcome
Stale messages, repeated archival tasks, inconsistent case state, or broad emergency authority.
Categories
Primary resilience; secondary integrity, availability, accountability, safety, trust.
Evidence
Fictional recovery exercise.
Unknowns
Current corrective controls, future frequency, and owner closure.
AB-06
Temporary migration import remains enabled without current purpose
Actor context
Fictional migration service identity and import interface.
Preconditions
Temporary path exists in inventory, ownership and activity are unresolved.
Potential outcome
Unexpected data path, weak validation, stale authority, or hidden dependency.
Categories
Primary governance; secondary identity, authorization, integrity, accountability.
Evidence
Temporary-interface inventory.
Unknowns
Reachability, activity, accepted data, owner, and retirement status.
AB-07
Monitoring source appears healthy while business evidence is delayed
Actor context
Fictional monitoring service and result queue.
Preconditions
Health status measures connectivity but may not represent freshness or business completion.
Potential outcome
Delayed detection, false confidence, incorrect triage, or stale risk decisions.
Categories
Primary accountability; secondary availability, integrity, governance.
Evidence
Green health indicator during a twenty-two-minute delay.
Unknowns
Dashboard semantics, source-health checks, alert thresholds, and alternate evidence.
AB-08
Future analytics design combines event sources without approved purpose
Actor context
Fictional analytics service, data owners, and event sources.
Preconditions
Proposed design lacks approved fields, purpose, audience, retention, ownership, and safeguards.
Potential outcome
Over-collection, unsupported inference, broad access, misleading analysis, or long-lived data use.
Categories
Primary privacy; secondary governance, confidentiality, integrity, accountability.
Evidence
Fictional analytics proposal.
Unknowns
Final design, fields, controls, current deployment, and owner decisions.
Risk Workshop
Rank Fictional Scenarios without False Precision
RSK-01
Stale supplier result changes current case state.
Impact
High—case integrity, user decisions, communication, support load, evidence, and recovery.
Likelihood
Moderate—one fictional delay and exercise support plausibility, but current frequency and controls remain incomplete.
Control evidence
Schema validation designed; source health operating; reconciliation, ordering, duplicate handling, and recovery evidence partial.
Uncertainty
Moderate to High.
Residual risk
High provisional.
Priority
Immediate workflow, supplier, evidence, and recovery owner review.
RSK-02
Free-text support note may cross supplier boundary.
Impact
Moderate to High—depends on content, purpose, access, retention, and user expectation.
Likelihood
Unknown—field exists in inventory, but current population is not established.
Control evidence
Minimization expected; approved purpose, schema enforcement, retention, and owner evidence incomplete.
Uncertainty
Decision-blocking for final residual ranking.
Residual risk
Not final.
Priority
Assign data owner and validate current-state field use before approval.
RSK-03
Unowned archival service identity remains active.
Impact
High potential—identity, archival state, retention, evidence, and recovery could be affected.
Likelihood
Moderate—active status and expired review are supported; misuse and excessive authority are not proven.
Control evidence
Identity exists and may be logged; owner, scope, review, and recovery dependencies incomplete.
Uncertainty
High.
Residual risk
High provisional.
Priority
Validate purpose, owner, authority, activity, lifecycle, and recovery before change.
RSK-04
Notification change lacks verification and confirmation evidence.
Impact
Moderate—communication, privacy expectations, workflow state, and trust.
Likelihood
Moderate—multiple fictional tickets show the evidence gap.
Control evidence
Role and ticketing exist; reason, verification, correlation, confirmation, and review incomplete.
Uncertainty
Moderate.
Residual risk
Moderate.
Priority
Improve support workflow and evidence quality.
RSK-05
Recovery returns application before dependencies are ready.
Impact
High—stale business state, repeated actions, incorrect communication, and weak closure.
Likelihood
Moderate—supported by one fictional exercise.
Control evidence
Recovery plan and backups exist; dependency gates, reconciliation, communication, and emergency-access closure incomplete.
Uncertainty
Moderate.
Residual risk
High.
Priority
Prioritize recovery sequencing, evidence, and re-test.
RSK-06
Temporary migration import remains enabled without current purpose.
Impact
Moderate to High depending on authority, data, validation, and environment.
Likelihood
Unknown because current activity and reachability are not established.
Control evidence
Inventory record exists; ownership, lifecycle, activity, monitoring, and retirement evidence incomplete.
Uncertainty
High.
Residual risk
Provisional.
Priority
Validate before retain, restrict, or retire decision.
Mitigation Workshop
Choose Layered Fictional Control Packages
RSK-01 — Stale supplier result
Design
Make current workflow state and result version explicit.
Prevent
Require state compatibility, source identity, correlation, duplicate and ordering checks.
Detect
Monitor queue age, freshness, state mismatch, source health, and reconciliation failure.
Respond
Pause uncertain automatic updates and route affected records to controlled fictional review.
Recover
Reconcile case, notification, archive, support, and evidence state.
Govern
Assign supplier, workflow, queue, evidence, recovery, and residual-risk owners.
Residual risk
Supplier delay and manual review workload remain.
RSK-02 — Free-text supplier field
Design
Remove the field or replace it with a limited approved category unless a necessary purpose is approved.
Prevent
Enforce a minimized supplier schema and approved purpose.
Detect
Monitor field presence and schema deviation without broadly storing sensitive content.
Respond
Pause unapproved field use and notify fictional data and supplier owners.
Recover
Correct requests and review downstream retention where authorized.
Govern
Define purpose, fields, access, retention, deletion, owner, and exception expiration.
Residual risk
Supplier processing and metadata exposure may remain.
RSK-03 — Unowned archival identity
Design
Separate archival authority from unrelated processing and define one narrow purpose.
Prevent
Limit actions, objects, destinations, environments, schedules, and recovery use.
Detect
Monitor owner status, review expiration, activity, denied actions, and schedule.
Respond
Validate purpose, assign owner, restrict unsupported authority, and preserve evidence.
Recover
Verify archival and recovery workflows before rotation, replacement, suspension, or retirement.
Govern
Require lifecycle, review, exception, recovery, and retirement ownership.
Residual risk
Recovery dependency and specialized operational knowledge remain.
RSK-04 — Support notification change
Design
Make verification, reason, target, approval, and user confirmation structured workflow fields.
Prevent
Require correct role, case assignment, allowed action, object, and approved change type.
Detect
Correlate ticket, actor, target, old state, new state, reason, result, and confirmation.
Respond
Review incomplete changes and correct unsafe state through approved fictional process.
Recover
Restore preference, correct missed communication, and document outcome.
Govern
Assign support, identity, privacy, notification, evidence, and risk owners.
Residual risk
Human error and review workload remain.
RSK-05 — Recovery sequencing
Design
Create recovery gates for identity, queue, workflow, notification, archive, evidence, and business-state readiness.
Prevent
Do not declare full service before required validation and approval.
Detect
Monitor stale state, repeated tasks, delayed notifications, invalid identity references, and reconciliation gaps.
Respond
Declare degraded mode, limit unsafe actions, preserve evidence, and communicate status.
Recover
Restore in order, reconcile state, validate user outcomes, revoke emergency access, and close the event.
Govern
Approve recovery order, roles, evidence, exceptions, exercises, and review cadence.
Residual risk
Complex dependencies and recovery time remain.
Assumption Workshop
Make Beliefs, Limits, and Consequences Visible
ASM-01
The fictional result queue preserves ordering for one case reference.
Confidence
Moderate
Evidence
Queue design summary and interface sequence notes.
Evidence limits
No complete delay, retry, failover, or recovery evidence.
Consequence if false
If false, stale-state, duplicate, mitigation, and recovery decisions must be revised.
Owner
Fictional workflow integration owner
Review and expiration
Expires after queue, supplier, retry, or recovery change.
ASM-02
The fictional supplier free-text field may be used in current requests.
Confidence
Low
Evidence
Field appears in the documented schema.
Evidence limits
No current usage, purpose, access, retention, or payload evidence.
Consequence if false
If unused, current risk may decrease; if broadly used, mitigation urgency may increase.
Owner
Fictional data owner—currently unassigned
Review and expiration
Decision-blocking until validated.
ASM-03
The fictional archival identity remains necessary for approved retention and recovery.
Confidence
Moderate
Evidence
Service catalog and recovery references.
Evidence limits
Owner, scope, activity, and current review are incomplete.
Consequence if false
If purpose ended or changed, authority and lifecycle decisions must be revised.
Owner
Fictional records and recovery owner
Review and expiration
Review before any lifecycle decision and after recovery change.
ASM-04
The fictional Green source-health status measures connectivity rather than complete event freshness.
Confidence
Moderate
Evidence
Green status remained during a twenty-two-minute result delay.
Evidence limits
Dashboard semantics and implementation are not fully documented.
Consequence if false
Monitoring design and risk confidence may change after validation.
Owner
Fictional monitoring owner
Review and expiration
Review after telemetry or dashboard changes.
ASM-05
The fictional recovery exercise is relevant to current recovery design but does not establish production frequency.
Confidence
High for exercise observation; Moderate for current-state inference
Evidence
Exercise output showing stale messages and repeated archival tasks.
Evidence limits
One exercise and incomplete corrective-action evidence.
Consequence if false
Residual risk may increase or decrease after current control validation.
Owner
Fictional continuity owner
Review and expiration
Review after corrective action and the next exercise.
Peer-Review Workshop
Convert Model Defects into Measurable Actions
REV-01
Every High residual risk must link to current control-operating and failure evidence.
Observation
Three fictional High risks cite designed controls but incomplete operating evidence.
Decision impact
Residual-risk reduction may be overstated.
Review severity
High review severity
Corrective action
Attach fictional operating, source-health, failure, and recovery evidence or revise residual rankings.
Owner
Fictional control assurance owner
Completion criterion
Each affected risk shows evidence, limitations, revised rationale, approval, and review trigger.
Status
Open—blocks final residual-risk acceptance.
REV-02
Every important assumption must have an owner and valid review state.
Observation
The archival identity assumption expired after a recovery-design change.
Decision impact
Identity, governance, archival, and recovery conclusions may be stale.
Review severity
High review severity
Corrective action
Validate purpose, owner, authority, activity, lifecycle, and recovery dependency.
Owner
Fictional identity and continuity owners
Completion criterion
Updated assumption and dependent decisions are approved with current evidence.
Status
Blocked.
REV-03
Threat categories must improve decision ownership and control selection.
Observation
Four fictional scenarios use more secondary categories than distinct decisions justify.
Decision impact
Category inflation reduces clarity and comparison.
Review severity
Moderate review severity
Corrective action
Keep one primary category and only secondary labels that change assets, controls, evidence, owners, or recovery.
Owner
Fictional threat-model facilitator
Completion criterion
Updated worksheet contains rationale and preserved uncategorized concerns.
Status
Open.
REV-04
Current and future-state scenarios must be distinguished.
Observation
The future analytics proposal is clearly labeled, but one summary paragraph implies current exposure.
Decision impact
Leadership may misunderstand deployment state and urgency.
Review severity
Moderate review severity
Corrective action
Revise summary language and preserve future-state design requirements.
Owner
Fictional model editor
Completion criterion
All references align with future-state status and no incident claim remains.
Status
In Review.
REV-05
Public artifacts must remain fictional, privacy-safe, and non-operational.
Observation
The package uses invented names, records, dates, systems, identities, and evidence and contains no real targets.
Decision impact
Safe-publication quality is currently strong.
Review severity
Informational strength
Corrective action
Retain final safe-publication check before delivery.
Owner
Fictional publication reviewer
Completion criterion
Final package passes the safety checklist.
Status
Ready.
Traceability Matrix
Follow One Fictional Concern across the Entire Workshop
| Layer | Fictional record | Decision contribution | Maintenance trigger |
|---|---|---|---|
| Mission | Accurate and timely student-support decisions. | Defines impact and urgency. | Service objective or user population changes. |
| Asset | Case-state integrity and user communication. | Defines what must remain correct and trusted. | Data model or workflow state changes. |
| Actors | Supplier service, queue, workflow service, support reviewer. | Defines authority, responsibility, and evidence. | Identity, delegation, role, or ownership changes. |
| Entry point | Supplier result interface. | Defines exposure and accepted operations. | Interface, schema, destination, or lifecycle changes. |
| Flow | Supplier result → queue → workflow. | Defines purpose, state, validation, and recovery. | Queue, retry, ordering, or recovery changes. |
| Boundary | Supplier-to-Northbridge administrative boundary. | Defines trust, identity, schema, evidence, and responsibility. | Supplier, contract, identity, or control changes. |
| Abuse case | Stale result changes current case state. | Defines unsafe outcome and control questions. | New ticket, exercise, event, or workflow change. |
| Category | Primary integrity; secondary availability, dependency, accountability, resilience. | Organizes owners and control perspectives. | Scenario meaning or affected outcome changes. |
| Risk | High provisional residual risk. | Sets priority and evidence needs. | Impact, likelihood, control, uncertainty, or mission changes. |
| Mitigation | State version, correlation, freshness evidence, review, reconciliation, communication. | Defines expected risk reduction. | Control design, operation, failure, or recovery changes. |
| Assumption | Queue preserves ordering for one case. | Limits confidence and selected control design. | Supplier, queue, retry, failover, or evidence changes. |
| Review finding | Operating reconciliation evidence incomplete. | Blocks final residual-risk acceptance. | Closure evidence or new contradiction. |
Fake Dashboard
Fake Northbridge Workshop Dashboard
Fictional workshop progress, traceability, blocked decisions, ownership, and review status for training only.
Traceable high-priority risks
4 / 4
Each high-priority fictional risk links to assets, actors, flows, scenarios, evidence, controls, assumptions, owners, and triggers.
Decision-blocking gaps
3
Supplier field use, archival identity ownership, and control-operating evidence still block final decisions.
Review actions with completion criteria
11 / 13
Two fictional actions still use vague wording and require measurable closure evidence.
Fake SOC Alert
Workshop Sign-Off Attempts to Close a Blocked Privacy Decision
Source: Fake Northbridge Workshop Governance Console • Time: 6:04 PM
The fictional workshop summary marks all privacy decisions Complete even though current use, purpose, access, retention, and ownership of the supplier free-text field remain unresolved.
Defensive recommendation: Reclassify the affected privacy decision as Blocked, assign a fictional data owner, preserve evidence limits, define validation and completion criteria, and update risk, mitigation, sign-off, and review triggers.
Fake Log Panel
Fake Threat-Modeling Workshop Timeline
training-log-viewer.log
09:00 CHARTER decision='support-portal-review' scope='web+services' 09:08 SAFETY fictional='true' real-testing='prohibited' 09:16 ASSET count='8' mission-owner='assigned' 09:24 ACTOR count='8' service-identity-gap='archive' 09:32 ENTRYPOINT count='8' temporary='migration-import' 09:40 FLOW count='8' recovery-flow='included' 09:48 BOUNDARY supplier='administrative' identity='required' 09:56 ABUSECASE count='8' intent-proof='none' 10:04 CATEGORY inflation='review-needed' 10:12 RISK high='4' blocked='2' provisional='3' 10:20 MITIGATION layered='5-packages' 10:28 ASSUMPTION open='5' unowned='1' expired='1' 10:36 REVIEW finding='5' blocking='3' 10:44 TRACE high-risk='complete' 10:52 SIGNOFF architecture='conditional' privacy='blocked' 11:00 SIGNOFF recovery='conditional' publication='ready' 11:08 ACTION owners='assigned-11-of-13' 11:16 MAINTENANCE triggers='defined' 11:24 CONFIDENCE package='moderate' 18:04 ALERT issue='privacy-signoff-overreach'
Training note: this is fake data for defensive analysis practice only.
Fictional Evidence Matrix
What the Workshop Evidence Supports—and What It Does Not Prove
EV-01
Fictional architecture context
Observation
The web portal, identity, supplier, queue, workflow, notification, monitoring, archive, and recovery relationships are documented.
Supports
The workshop can model those relationships and their trust changes.
Does not prove
The record does not prove every current path, identity, field, control, temporary interface, or failure state.
Workshop decision
Use the context as a starting point and preserve current-state validation actions.
EV-02
Fictional queue-health dashboard
Observation
Result events were delayed twenty-two minutes while source health remained Green.
Supports
Availability, integrity, evidence semantics, dependency, and recovery questions are justified.
Does not prove
The dashboard does not prove data loss, malicious activity, one cause, or future frequency.
Workshop decision
Create a stale-result scenario and monitoring-semantic assumption.
EV-03
Fictional support-ticket pattern
Observation
Users submitted duplicate documents after delayed notifications.
Supports
User, workflow, service, communication, support, and integrity impact may be meaningful.
Does not prove
The pattern does not prove the delay was the only cause.
Workshop decision
Use bounded impact evidence and preserve alternative explanations.
EV-04
Fictional supplier-field inventory
Observation
A free-text support-note field appears in the request schema.
Supports
Privacy, confidentiality, governance, supplier, and minimization questions are valid.
Does not prove
Current use, purpose, access, retention, and downstream handling are unresolved.
Workshop decision
Block final privacy ranking until a fictional data owner validates use.
EV-05
Fictional service-identity review
Observation
The archival service identity lacks a confirmed owner and is past review.
Supports
Identity, governance, authority, evidence, retention, and recovery uncertainty are elevated.
Does not prove
The record does not prove compromise, misuse, broad permission, or harmful activity.
Workshop decision
Create an owner-validation action without destructive or accusatory response.
EV-06
Fictional support-ticket review
Observation
Several notification changes lack reason and user-confirmation fields.
Supports
Accountability and workflow evidence are incomplete.
Does not prove
The evidence does not prove unauthorized action, incorrect preferences, harmful outcome, or intent.
Workshop decision
Choose proportionate workflow and evidence mitigations.
EV-07
Fictional recovery exercise
Observation
Application service returned before notification and archival dependencies were validated.
Supports
Recovery sequencing, reconciliation, communication, identity, evidence, and closure concerns are credible.
Does not prove
One exercise does not establish current frequency or all control effectiveness.
Workshop decision
Prioritize recovery gates and re-test with fictional evidence.
EV-08
Fictional mitigation register
Observation
Several controls are designed or planned but lack operating, failure, or recovery evidence.
Supports
Residual-risk reduction should remain provisional.
Does not prove
The register does not prove the controls are absent or ineffective.
Workshop decision
Assign validation actions and avoid unsupported closure.
Analyze the Evidence
Which Final Workshop Decision Is Best Supported?
The fictional model has clear scope, mission, asset, actor, flow, boundary, abuse-case, category, risk, mitigation, assumption, and review artifacts.
Four high-priority risks are traceable across the model.
The supplier free-text field remains decision-blocking because current use, purpose, access, retention, and ownership are unresolved.
The archival service identity lacks current ownership and review evidence.
Several controls are designed but lack complete operating, failure, or recovery evidence.
Recovery sequencing concerns are supported by one fictional exercise.
Safe-publication review found no real targets, credentials, routes, logs, or operational harmful instructions.
The package has Moderate overall confidence.
Which conclusion most responsibly summarizes the fictional Northbridge workshop?
Common Mistakes
Errors That Weaken the Workshop
Starting with threats before defining the decision
Why it fails
The fictional workshop may produce a large list that does not support any architecture, risk, mitigation, or ownership choice.
Strong correction
Begin with a charter, decision, audience, scope, exclusions, and success criteria.
Letting one participant dominate
Why it fails
Technical or author perspectives may hide privacy, user, support, supplier, recovery, accessibility, and mission concerns.
Strong correction
Use independent pre-work, structured rounds, role-based questions, and a facilitator.
Treating workshop discussion as evidence
Why it fails
A fictional participant statement may be useful context but does not automatically prove current state or control operation.
Strong correction
Record the statement, source, limits, confidence, owner, validation, and affected decisions.
Creating disconnected registers
Why it fails
Assets, scenarios, risks, controls, assumptions, and findings may not explain one another.
Strong correction
Use stable identifiers and complete traceability chains.
Ranking too early
Why it fails
Impact, likelihood, control state, and uncertainty may be guessed before flows and scenarios are clear.
Strong correction
Complete context, evidence, abuse cases, and category rationale before final ranking.
Choosing tools instead of control objectives
Why it fails
The fictional team may select familiar controls that do not reduce the root condition.
Strong correction
Define the exact risk dimension and scenario condition that must improve.
Ignoring failure and recovery
Why it fails
A mitigation may work during normal operation but fail during delay, retry, degraded mode, emergency, or restore.
Strong correction
Model safe failure, alternate evidence, response, reconciliation, communication, and closure.
Hiding unresolved disagreement
Why it fails
Different owner perspectives can reveal important assumptions and tradeoffs.
Strong correction
Record disagreement, evidence, rationale, uncertainty, and decision authority.
Ending without owners and maintenance
Why it fails
The fictional model may become stale immediately after the workshop.
Strong correction
Assign owners, dates, triggers, versions, closure evidence, and reopened-finding rules.
Using real internal material
Why it fails
Real systems, identities, logs, suppliers, controls, gaps, recovery details, and priorities may be sensitive or unsafe.
Strong correction
Invent every organization, system, identity, scenario, record, control, owner, date, decision, and outcome.
Safe Fictional Practice Lab
Complete the Northbridge Threat-Modeling Workshop
Use only the supplied fictional information on this page. Do not access, scan, test, configure, investigate, monitor, recover, or change any real system. Do not use real identities, logs, routes, suppliers, diagrams, controls, incidents, recovery details, credentials, internal records, or organizational priorities.
1
Create the fictional workshop charter
Define the Northbridge decision, scope, exclusions, participants, roles, evidence package, criteria, outputs, schedule, and safety boundary.
Required output
Charter, role map, agenda, decision-rights map, and safe-use statement.
Quality check
The workshop is clearly limited to invented, defensive, non-operational analysis.
2
Build system context
Map the fictional mission, services, users, identities, data, environments, suppliers, dependencies, current state, future state, degraded state, and recovery state.
Required output
System context, scope map, dependency list, and exclusions.
Quality check
A reader can explain the mission and boundary without real-world knowledge.
3
Create asset and actor registers
Document fictional values, owners, harm, evidence, human roles, service identities, authority, lifecycle, and open questions.
Required output
Asset register, actor register, authority map, and owner-gap list.
Quality check
The model includes mission, privacy, evidence, safety, trust, and recovery assets.
4
Map entry points, flows, and boundaries
For each important fictional relationship, record purpose, data, identity, state, validation, trust change, evidence, failure, recovery, and owner.
Required output
Entry-point inventory, flow register, and trust-boundary map.
Quality check
No flow is represented only by an arrow or vague label.
5
Write and categorize abuse cases
Create safe fictional scenarios across deliberate, accidental, process, supplier, automation, usability, degraded, and recovery families.
Required output
At least sixteen abuse cases, category rationale, uncategorized concerns, and intent-uncertainty notes.
Quality check
Scenarios describe outcomes and controls without procedural harmful detail.
6
Rank risks
Use defined fictional impact, likelihood, exposure, control, uncertainty, confidence, recovery, priority, and urgency criteria.
Required output
Inherent and residual risk register, disagreement log, blocked decisions, and owner actions.
Quality check
Every rating has rationale and evidence limits.
7
Choose layered mitigations
Generate fictional design, prevention, detection, response, recovery, privacy, governance, communication, and evidence controls.
Required output
Mitigation decision matrix, selected packages, tradeoffs, owners, validation, and residual risk.
Quality check
Controls address the scenario and root conditions rather than only adding monitoring.
8
Document assumptions and limits
Record fictional observations, interpretations, assumptions, unknowns, exclusions, constraints, confidence, consequences, owners, expiration, and triggers.
Required output
Assumption register, limitations register, evidence-gap queue, and confidence map.
Quality check
Decision-blocking gaps remain visible and are not forced into final conclusions.
9
Conduct peer review
Use published criteria to review scope, evidence, traceability, consistency, category quality, risk rationale, control evidence, recovery, assumptions, ownership, maintenance, and safety.
Required output
Finding register, action plan, completion criteria, sign-off matrix, and revised model version.
Quality check
Findings challenge the artifact, not the people.
10
Deliver and maintain
Prepare fictional leadership, technical, portfolio, and maintenance outputs with versions, dates, owners, triggers, closure evidence, and retrospective.
Required output
Complete threat-model package, leadership brief, technical appendix, maintenance plan, and reflection.
Quality check
The package is useful, honest, maintainable, and safe for public learning.
Scenario Decision Lab
The Workshop Is Running Out of Time
The fictional team has completed scope, assets, actors, flows, and abuse cases, but risk rankings, assumptions, and peer review remain incomplete. A participant proposes assigning quick scores and signing off.
Scenario Decision Lab
A Reviewer Finds a Real-Looking Detail in the Portfolio Draft
The fictional portfolio draft contains a realistic internal-style route and a copied log pattern that may resemble a real environment, even though the organization name is invented.
Advanced Challenge
Defend a Conditional Sign-Off before Fictional Leadership
Fictional leadership wants one answer: “Is the portal safe?” The workshop shows that architecture coverage is strong, supplier-result risk is High provisional, privacy is blocked on field-use evidence, recovery controls are conditional, and public publication is ready. Prepare an accurate decision without saying simply yes or no.
State the decision scope
Explain which fictional design, risk, mitigation, and publication decisions were reviewed.
Separate readiness states
Identify Ready, Conditional, Blocked, Accepted, Provisional, and Reopened areas.
Explain evidence and confidence
Summarize strongest evidence, important limits, and Moderate overall confidence.
Name blocked decisions
State why supplier-field use, archival identity ownership, and control operation require evidence.
Assign next actions
Give each fictional action an owner, completion criterion, due condition, and trigger.
Avoid guarantees
Explain that the model supports decisions but does not certify perfect security or predict every event.
Challenge output
Produce a fictional five-minute leadership briefing, sign-off matrix, blocked-decision list, owner action table, residual-risk summary, confidence statement, safe-publication statement, maintenance schedule, and response to “Is it safe?” without overpromising.
Defender Habits
Threat Modeling Workshop Lab Checklist
Check Your Understanding
A3.10 Mini Quiz: Threat Modeling Workshop Lab
Choose your answers first. Explanations appear only after submission.
1. What should happen first in a professional threat-modeling workshop?
2. Why are stable identifiers useful across workshop artifacts?
3. A future analytics design lacks approved purpose and fields. What is the most responsible workshop decision?
4. What is the strongest reason to include recovery in threat modeling?
5. Which workshop output makes uncertainty most maintainable?
6. What should a workshop do with a finding that blocks residual-risk acceptance?
7. Which portfolio approach is safest?
Portfolio Prompt
Portfolio Prompt
Create a complete, fully fictional Threat-Modeling Workshop Package for the Northbridge Student-Support Portal. Include a workshop charter, decision statement, scope, exclusions, safety boundary, agenda, role assignments, evidence index, system context, dependency map, at least twelve assets, at least twelve actors, at least twelve entry points, at least fifteen flows, trust-boundary decisions, at least twenty abuse cases, primary and secondary category rationale, uncategorized concerns, a published risk-ranking method, at least fifteen risk records, layered mitigation packages, tradeoff analysis, validation plans, at least fifteen assumptions, at least ten limitations, evidence provenance, blocked decisions, confidence statements, multidisciplinary review findings, completion criteria, sign-off matrix, leadership summary, technical appendix, maintenance schedule, review triggers, closure evidence, retrospective, reflection, and a statement that every organization, asset, actor, identity, system, interface, flow, scenario, record, control, owner, date, decision, and outcome is invented.
Use stable fictional identifiers so every important decision can be traced across the entire package.
Distinguish current, future, temporary, degraded, recovery, conditional, blocked, accepted, provisional, and reopened states.
Preserve evidence limits and confidence instead of forcing unsupported certainty.
Show how selected controls will be validated during normal, failure, degraded, emergency, and recovery conditions using only invented data.
Keep the entire package defensive, non-operational, privacy-safe, evidence-aware, maintainable, and suitable for a public learning portfolio.
Confidence / Readiness Reflection
Are You Ready for the A3 Module Test?
Rate your readiness from 1 to 5 for chartering, scope, assets, actors, entry points, flows, trust boundaries, abuse cases, categories, risk ranking, mitigation, assumptions, peer review, leadership communication, maintenance, safe publication, and complete fictionalization.
I can explain the complete fictional threat-modeling lifecycle from purpose to maintenance.
I can produce traceable artifacts instead of disconnected lists and diagrams.
I can separate evidence, interpretation, assumption, unknown, category, severity, intent, control state, and residual risk.
I can identify what is Ready, Conditional, Blocked, Accepted, Provisional, or Reopened.
I can explain why recovery, privacy, usability, accessibility, evidence, and ownership belong in threat modeling.
I can defend a conditional sign-off without overpromising or hiding uncertainty.
I can build a public portfolio package without real targets, logs, routes, identities, credentials, configurations, or operational harmful detail.
I can proceed to the module test with a clear list of concepts that still need review.
Record one fictional decision that became conditional, one that remained blocked, one mitigation that changed after peer review, one assumption that affected a risk ranking, one safety correction, and three topics you will review before the A3 Module Test.
Key Takeaways
What You Should Remember
1.A professional fictional workshop begins with a decision, scope, roles, evidence, outputs, criteria, and safety boundary.
2.Threat modeling is a connected lifecycle, not a collection of independent diagrams, labels, scores, or controls.
3.Mission, privacy, user, evidence, safety, trust, supplier, and recovery assets belong beside technical assets.
4.Actors should be modeled by relationship, authority, lifecycle, and evidence rather than assumed intent.
5.Flows and trust boundaries must explain purpose, data, identity, state, validation, evidence, failure, and recovery.
6.Abuse cases should remain fictional, defensive, outcome-focused, and non-operational.
7.Risk rankings require defined impact, likelihood, exposure, control, uncertainty, confidence, recovery, priority, and urgency criteria.
8.Mitigations should be layered, failure-aware, privacy-aware, maintainable, testable, and honest about residual risk.
9.Assumptions, limits, blocked decisions, disagreement, findings, closure evidence, and review triggers make the model trustworthy.
10.Every CyberShield workshop package must remain fully fictional, authorized, defensive, non-operational, privacy-safe, maintainable, and incapable of exposing real systems or people.
Navigation
Complete Module A3
You have completed the full fictional threat-modeling workflow. Continue to the A3 Module Test to evaluate scope, assets, actors, flows, trust boundaries, abuse cases, categories, risk ranking, mitigation, assumptions, review, ethics, safety, and maintenance.