C — Context
Define the fictional asset, actor, action, object, flow, boundary, abuse case, state, and business purpose.
High School AdvancedModule A3Lesson 5 of 10Conceptual Classification
A3.5 Threat Categories Conceptually
Learn how professional defenders use conceptual categories to organize fictional threat questions about identity, authority, integrity, confidentiality, availability, accountability, privacy, safety, resilience, dependency, and governance. Categories support reasoning, but they do not prove that a threat exists, that a control failed, that an actor acted maliciously, or that a scenario is high risk.
Lesson Progress
Threat Categories Conceptually
High School Advanced • A3: Threat Modeling • Lesson 5 of 10
50% complete
Readiness Check
Before You Start
0/6 ready
Professional Hook
A Category Is a Lens, Not a Verdict
A fictional Northbridge reviewer sees that several notification changes lack a recorded reason and user-confirmation field. Calling this a “privacy threat” may be partly useful, but it does not explain the strongest supported issue. The available evidence first raises an accountability question: can the team connect actor, purpose, approval, action, target, result, and user confirmation? Secondary authorization, privacy, integrity, and governance questions may also matter. None of those labels proves misuse or malicious intent.
Weak category use
“This is an insider threat and a critical privacy breach.” The statement assumes actor intent, event, impact, category, and severity without evidence.
Strong category use
“The fictional ticket pattern creates a primary accountability question and secondary authorization, privacy, integrity, and governance questions; current evidence does not prove unauthorized action, harmful outcome, or intent.”
Categories should improve questions, traceability, ownership, control design, evidence review, and communication. If a label does not change any of those, it may not be useful.
Exactly Five Learning Objectives
What You Will Be Able to Do
Objective 1
Explain why conceptual threat categories help defenders organize questions without proving that a threat exists, that a control failed, or that an actor acted maliciously.
Objective 2
Classify fictional threat-model concerns across identity, integrity, confidentiality, availability, privilege, accountability, privacy, safety, dependency, recovery, and governance themes.
Objective 3
Use categories as prompts that connect fictional assets, actors, entry points, flows, trust boundaries, abuse cases, evidence, assumptions, controls, owners, and review triggers.
Objective 4
Recognize cross-category, uncategorized, overlapping, and context-specific concerns without forcing every scenario into one rigid label.
Objective 5
Create a portfolio-ready fictional threat-category worksheet that remains ethical, authorized, defensive, evidence-aware, privacy-safe, and completely invented.
Why This Matters
Categories Help Teams See Different Questions in the Same Scenario
One fictional event may create several legitimate review questions. A delayed supplier result can affect integrity because workflow state becomes stale, availability because the service is delayed, dependency because an external service is involved, accountability because health evidence is unclear, and resilience because recovery and reconciliation may be needed. The goal is not to collect labels. The goal is to identify distinct defensive decisions.
Category as prompt
Ask a structured question about a fictional asset, actor, flow, boundary, abuse case, control, evidence source, or owner decision.
Category as organizer
Group related concerns so reviewers can compare controls, owners, evidence gaps, assumptions, and review triggers.
Category as communication
Explain the kind of concern without overstating proof, severity, exploitability, or intent.
Core Framework
The C-L-E-A-R Category Method
L — Label
Choose a primary conceptual category and only meaningful secondary categories.
E — Evidence
Record what supports the category assignment, what does not, source health, confidence, and unknowns.
A — Action
Connect the category to controls, evidence needs, owners, decisions, recovery, and residual questions.
R — Review
Revisit the label when assets, actors, flows, suppliers, automation, recovery, evidence, ownership, or purpose changes.
Decision-ready category statement
This fictional scenario is categorized primarily as a named concern because the central affected asset and decision involve a specific harmful outcome. Secondary categories apply only where they introduce different owners, controls, evidence, or recovery requirements. The assignment is based on supplied evidence with documented limits and does not prove event, intent, severity, or exploitability.
Advanced Vocabulary
Terms for Precise Conceptual Classification
Threat category
A conceptual label used to organize defensive questions about possible harm, unsafe conditions, control gaps, or trust assumptions in a fictional system.
Category prompt
A structured question that helps defenders review a fictional design, workflow, role, flow, boundary, or abuse case from a particular security perspective.
Classification
The act of assigning one or more conceptual labels to a fictional concern so that related questions, owners, controls, and evidence can be compared.
Cross-category concern
A fictional scenario that affects more than one security property, such as identity, privacy, integrity, availability, accountability, and recovery at the same time.
Primary category
The conceptual label that best represents the main decision or harm being reviewed in a fictional scenario.
Secondary category
An additional conceptual label that captures another important effect, dependency, control, or owner decision.
Uncategorized concern
A fictional issue that does not fit the chosen category set clearly and therefore requires a custom question rather than forced labeling.
Category coverage
The degree to which a fictional threat model considers relevant security, privacy, safety, resilience, governance, and operational questions.
Category bias
The risk that a chosen framework causes reviewers to notice some concerns while overlooking context that does not match familiar labels.
Category inflation
Assigning too many labels to every scenario until categories no longer help distinguish decisions, owners, evidence, or mitigations.
Category collapse
Combining different concerns into one vague label that hides distinct assets, outcomes, controls, owners, or evidence requirements.
Category evidence
The fictional records, owner decisions, diagrams, events, role definitions, data inventories, tickets, reviews, and exercises that support or limit a category assignment.
Identity concern
A fictional question about who or what is acting, how identity is established, how trust is carried, and how lifecycle or recovery affects that identity.
Authorization concern
A fictional question about whether an actor or service may perform a specific action on a specific object under defined conditions.
Integrity concern
A fictional question about whether data, workflow state, configuration, evidence, decisions, or system behavior remain accurate, complete, consistent, and authorized.
Confidentiality concern
A fictional question about whether information is disclosed only to approved actors, services, audiences, and purposes.
Availability concern
A fictional question about whether a service, workflow, data set, dependency, or recovery capability is accessible and usable when needed.
Accountability concern
A fictional question about whether actions, approvals, decisions, failures, changes, and recoveries can be attributed and reviewed using trustworthy evidence.
Privacy concern
A fictional question about collection, purpose, minimization, audience, retention, inference, consent, expectation, deletion, and responsible use of data.
Safety concern
A fictional question about whether system behavior, communication, automation, or failure could create harm to people, operations, or essential services.
Resilience concern
A fictional question about whether the system can continue, degrade safely, recover correctly, reconcile state, and restore trust after disruption.
Dependency concern
A fictional question about shared services, suppliers, identities, networks, queues, data sources, people, and recovery steps on which other functions rely.
Governance concern
A fictional question about ownership, approval, policy, exception, evidence, review, risk acceptance, lifecycle, and decision rights.
Category traceability
The connection from a conceptual category to the exact fictional asset, scenario, evidence, owner, control, decision, and review trigger it supports.
Instructional Section 1
Use Eleven Conceptual Category Families
The categories below are not an exhaustive or mandatory framework. They are a defensive question set for the fictional Northbridge model. Reviewers may add, combine, split, or retire categories when context requires it.
Identity and authenticity
Central defender question
Who or what is acting, and what evidence supports that identity, relationship, device, service, session, or trust assertion?
Fictional examples
A stale service identity remains active; a supplier assertion lacks current ownership; a recovery identity is used outside the approved event window.
Affected assets
Accounts, roles, service identities, sessions, federation, user trust, approvals, recovery authority, and evidence.
Supporting evidence
Authentication results, assertion source, lifecycle records, role assignment, device context, approvals, access reviews, and recovery closure.
Control themes
Strong identity proof, lifecycle, role ownership, service-identity governance, session protection, conditional access, and recovery controls.
Category warning
An identity category does not prove impersonation, credential theft, compromise, or malicious intent.
Authorization and privilege
Central defender question
May this fictional actor perform this action on this object, for this purpose, under these conditions, at this time?
Fictional examples
A support role can reprocess records without case-state confirmation; a broad role grants access beyond active assignment; emergency authority outlives recovery.
Affected assets
Permissions, roles, case assignments, administrative functions, sensitive records, workflow state, and separation of duties.
Supporting evidence
Policy decisions, role maps, object checks, approval records, access reviews, administrative events, and reason capture.
Control themes
Least privilege, object-level authorization, separation, time limits, approval, reason capture, review, and denial evidence.
Category warning
A privileged role is not automatically unsafe, and broad authority does not by itself prove misuse.
Integrity and correctness
Central defender question
Can fictional data, workflow state, decisions, configuration, evidence, or derived output become incorrect, incomplete, duplicated, reordered, stale, or unauthorized?
Fictional examples
Delayed supplier results update the wrong workflow state; duplicate submissions create conflicting case status; recovery restores stale notification data.
Affected assets
Case state, data records, event order, approvals, configuration, evidence, reports, and user-facing status.
Supporting evidence
Validation results, event correlation, version records, reconciliation, change history, queue state, and business-state checks.
Control themes
Validation, freshness, duplicate and ordering handling, versioning, approvals, reconciliation, integrity checks, and safe rollback.
Category warning
Integrity concerns include business meaning and workflow state, not only file or database modification.
Confidentiality and exposure
Central defender question
Could fictional information be disclosed to an unapproved actor, service, audience, destination, environment, or purpose?
Fictional examples
Notification content includes unnecessary case detail; a supplier receives a free-text support note; support access reveals records outside assigned cases.
Affected assets
Personal data, case records, metadata, support notes, identities, derived reports, logs, backups, and trust.
Supporting evidence
Field inventories, classification, access records, sharing decisions, audience settings, retention, supplier fields, and privacy reviews.
Control themes
Access control, minimization, audience restriction, masking, encryption concepts, retention, deletion, review, and monitoring.
Category warning
Confidentiality is broader than secrecy; purpose, audience, derived information, and metadata also matter.
Availability and service continuity
Central defender question
Can fictional users, services, defenders, or recovery teams access the required capability, data, identity, dependency, or evidence when needed?
Fictional examples
Processing results are delayed; identity services are unavailable; a queue backlog creates hidden user impact; monitoring evidence stops arriving.
Affected assets
Portal access, identity, processing, notifications, evidence, support, recovery, supplier services, and communication.
Supporting evidence
Health signals, queue state, service objectives, support tickets, retry records, dependency maps, and recovery exercises.
Control themes
Redundancy, bounded retry, graceful degradation, health monitoring, capacity planning, alternate workflows, communication, and recovery.
Category warning
A service can be technically online while the business workflow is unusable or misleading.
Accountability and evidence
Central defender question
Can fictional teams explain who or what acted, what changed, why, when, on which object, with which result, and whether evidence sources were healthy?
Fictional examples
Notification changes lack reason and confirmation; dashboard status conflicts with delayed events; administrative actions cannot be linked to a ticket.
Affected assets
Logs, approvals, tickets, timestamps, event meaning, source health, decision history, and auditability.
Supporting evidence
Event schemas, source-health records, actor and target fields, approvals, tickets, correlation identifiers, retention, and review notes.
Control themes
Purposeful logging, event quality, integrity, time context, source health, correlation, access restrictions, retention, and review.
Category warning
More logging is not automatically better; evidence must be useful, trustworthy, privacy-aware, and owned.
Privacy and responsible data use
Central defender question
Is fictional data collected, used, combined, shared, retained, inferred, or deleted only for a clear and approved purpose?
Fictional examples
A future analytics process combines support and supplier events without approved fields; free text crosses a supplier boundary; data remains beyond its retention purpose.
Affected assets
Personal data, metadata, derived information, consent or notice, expectations, trust, retention, and deletion evidence.
Supporting evidence
Purpose records, field inventories, classification, privacy review, retention schedules, audience decisions, and deletion records.
Control themes
Purpose limitation, minimization, access restrictions, masking, retention, deletion, transparency, review, and governance.
Category warning
A security control can still create privacy risk if it collects excessive data or uses it beyond the approved purpose.
Safety and human impact
Central defender question
Could fictional system behavior, automation, communication, failure, or recovery create harm to people, fairness, essential service, or trusted decision-making?
Fictional examples
Incorrect case status changes a student decision; delayed communication causes duplicate action; low-confidence automation affects priority without review.
Affected assets
People, service access, fairness, accurate communication, trusted decisions, essential workflows, and recovery outcomes.
Supporting evidence
User journeys, support themes, decision records, error messages, automation outcomes, complaints, exercises, and owner review.
Control themes
Human review, safer defaults, clear communication, guardrails, appeal paths, accessibility, workload limits, and escalation.
Category warning
Safety is not limited to physical harm; service and decision consequences can matter.
Resilience and recovery
Central defender question
Can fictional services, data, identities, configurations, evidence, dependencies, and business state be restored safely after disruption?
Fictional examples
Application recovery occurs before queue validation; emergency access remains active; stale notifications are sent after restore.
Affected assets
Backups, recovery identities, configuration baselines, dependency order, communication, business state, and trust.
Supporting evidence
Restore tests, recovery triggers, approvals, source artifacts, validation, reconciliation, communication, and closure review.
Control themes
Trusted baselines, restore order, strong recovery identity, integrity checks, reconciliation, communication, revocation, and lessons learned.
Category warning
Backup presence does not prove correct, timely, complete, or usable recovery.
Dependency and concentration
Central defender question
Which fictional services, suppliers, identities, people, queues, data sources, or recovery steps create shared or concentrated dependence?
Fictional examples
One identity provider supports portal, administration, and supplier trust; one queue carries multiple business-critical event types; one supplier performs all document processing.
Affected assets
Shared services, supplier relationships, identity, network paths, queues, specialized staff, evidence sources, and recovery dependencies.
Supporting evidence
Dependency maps, service catalogs, supplier records, identity consumers, queue metrics, staffing plans, and recovery order.
Control themes
Redundancy, alternate providers, isolation, capacity, ownership, fallback, contract planning, recovery, and exit strategy.
Category warning
A small or low-volume dependency can still create broad impact when many functions rely on it.
Governance and ownership
Central defender question
Are fictional purpose, ownership, approval, policy, exception, evidence, lifecycle, risk acceptance, and review responsibilities clear?
Fictional examples
A temporary interface has no owner; a service identity review has expired; a future analytics flow lacks approved purpose and retention.
Affected assets
Decision rights, ownership records, policies, exceptions, risk decisions, change history, reviews, and accountability.
Supporting evidence
Owner registers, approvals, policies, review records, exception decisions, change tickets, risk acceptance, and retirement records.
Control themes
Named owners, review cadence, approval, expiration, exception governance, evidence standards, change management, and retirement.
Category warning
A governance gap does not automatically prove a technical weakness or harmful event, but it increases uncertainty and decision risk.
Instructional Section 2
Turn Categories into Defensive Prompts
1
Who or what is trusted?
Related categories
Identity, authorization, accountability, governance
Apply to
Actors, service identities, sessions, federation, roles, emergency access, approvals, and lifecycle.
Useful evidence
Identity source, role, policy result, assignment, approval, access review, event, and owner.
2
What value could become incorrect?
Related categories
Integrity, safety, accountability, recovery
Apply to
Data, workflow state, decisions, configuration, event order, notifications, reports, backups, and restored state.
Useful evidence
Validation, version, state, reconciliation, change record, exercise result, and business owner decision.
3
What could be disclosed or used too broadly?
Related categories
Confidentiality, privacy, governance
Apply to
Records, fields, metadata, support notes, logs, notifications, analytics, suppliers, backups, and derived information.
Useful evidence
Field inventory, classification, purpose, audience, access, sharing, retention, privacy review, and deletion.
4
What must remain available?
Related categories
Availability, dependency, resilience, safety
Apply to
Portal, identity, processing, notifications, monitoring, support, suppliers, queues, recovery, and communication.
Useful evidence
Service objective, health, queue state, support impact, dependency map, retry, fallback, and recovery exercise.
5
What must be explainable later?
Related categories
Accountability, governance, integrity, privacy
Apply to
Administrative actions, approvals, policy decisions, support changes, supplier results, recovery actions, and risk acceptance.
Useful evidence
Actor, action, target, reason, result, time, source health, ticket, approval, correlation, and review.
6
What if one dependency fails?
Related categories
Dependency, availability, resilience, safety
Apply to
Identity provider, supplier, queue, notification service, monitoring source, specialized staff, backup, and network path.
Useful evidence
Dependency map, failure test, alternate process, capacity, support impact, recovery order, and communication plan.
7
What changes during degraded or emergency operation?
Related categories
Resilience, authorization, identity, accountability, safety
Apply to
Emergency roles, alternate workflows, delayed processing, manual review, failover, restore, and reconciliation.
Useful evidence
Trigger, approval, authority, source artifact, actions, validation, communication, closure, and revocation.
8
Who owns the remaining uncertainty?
Related categories
Governance, accountability, risk, dependency
Apply to
Unowned interfaces, stale identities, unclear supplier fields, draft analytics, missing evidence, and unresolved recovery assumptions.
Useful evidence
Owner assignment, decision log, evidence request, review date, residual risk decision, and change trigger.
Instructional Section 3
Apply Ten Category-Assignment Rules
Start with the decision, not the label
Identify the fictional decision, affected asset, actor, flow, boundary, abuse case, and evidence before selecting categories.
If ignored
Beginning with a favorite category can distort the scenario and hide context that does not match the framework.
Choose one primary category when useful
Select the label that best represents the main harmful outcome or owner decision.
If ignored
Assigning every category as primary makes prioritization and ownership unclear.
Add secondary categories only when they change the decision
Use additional labels when they introduce a different asset, owner, control, evidence source, or recovery requirement.
If ignored
Decorative labels create category inflation without improving reasoning.
Preserve uncategorized concerns
Record a custom concern when the chosen category set does not fit the fictional context.
If ignored
Forced classification can erase safety, human, operational, supplier, or governance concerns.
Keep category and evidence separate
A label organizes a question; evidence supports or limits the underlying claim.
If ignored
Calling a scenario an integrity threat does not prove data was changed or a control failed.
Keep category and severity separate
A category describes the kind of concern, while later risk ranking evaluates impact, likelihood, exposure, control strength, uncertainty, and mission context.
If ignored
A confidentiality label is not automatically higher or lower risk than availability, privacy, or governance.
Keep category and actor intent separate
Categories describe possible effects and control questions, not whether a fictional actor acted deliberately.
If ignored
Identity or authorization concerns do not prove impersonation, insider misuse, or malicious behavior.
Review category coverage with multiple roles
Technical, privacy, data, operations, support, recovery, supplier, and mission owners notice different concerns.
If ignored
One reviewer may overemphasize familiar technical categories and miss human or business impact.
Trace categories to controls and owners
Every important category assignment should connect to specific mitigations, evidence, decision rights, and review triggers.
If ignored
A category worksheet that stops at labels does not improve the design.
Retire or revise labels when context changes
Update assignments when assets, flows, suppliers, identity, automation, recovery, evidence, or business purpose changes.
If ignored
Stale category labels can create false confidence and preserve outdated assumptions.
Instructional Section 4
Handle Cross-Category Scenarios without Losing Precision
Cross-category classification is useful when each label adds a distinct defensive decision. The examples below show how to select a primary category, identify meaningful secondary categories, and preserve what the evidence does not prove.
A fictional support analyst changes notification preferences without complete reason and user-confirmation evidence.
Primary category
Accountability
Secondary categories
Authorization, privacy, integrity, governance
Why this classification helps
The main supported gap is incomplete evidence, while permission scope, data use, correct preference state, and ownership also affect the decision.
What is not proven
The evidence does not prove unauthorized action, malicious intent, or user harm.
A fictional supplier result arrives late and updates a case after the workflow has moved to another state.
Primary category
Integrity
Secondary categories
Availability, dependency, accountability, resilience
Why this classification helps
The central concern is incorrect workflow state, while delay, supplier reliance, evidence, and recovery also matter.
What is not proven
The scenario does not prove tampering, compromise, or permanent data loss.
A fictional analytics proposal combines support, supplier, portal, and notification events without approved fields or retention.
Primary category
Privacy
Secondary categories
Confidentiality, governance, accountability, integrity
Why this classification helps
Purpose, minimization, audience, inference, and retention are central, while exposure, owner decisions, evidence quality, and interpretation also matter.
What is not proven
The proposal is future-state and does not prove collection or misuse has occurred.
A fictional identity provider outage causes teams to rely on broad emergency access for longer than planned.
Primary category
Availability
Secondary categories
Authorization, identity, accountability, safety, resilience
Why this classification helps
Loss of identity service drives the condition, but emergency authority, identity confidence, evidence, human impact, and recovery closure also change.
What is not proven
The scenario does not prove that emergency access is currently broad or improperly used.
A fictional recovery restores application service but sends stale notifications and repeats archival tasks.
Primary category
Resilience
Secondary categories
Integrity, accountability, availability, safety, trust
Why this classification helps
The central decision is correct recovery, while business state, evidence, service timing, user impact, and confidence are also affected.
What is not proven
One exercise does not prove future frequency or current production exposure.
A fictional temporary migration interface remains documented as enabled without a current owner or purpose.
Primary category
Governance
Secondary categories
Identity, authorization, accountability, dependency
Why this classification helps
Ownership and lifecycle are the supported gaps, while connected identity, accepted operations, evidence, and dependencies require validation.
What is not proven
The record does not prove reachability, use, unsafe configuration, or malicious activity.
Instructional Section 5
Separate Category, Evidence, Severity, and Intent
| Dimension | Question answered | Example | What it does not answer |
|---|---|---|---|
| Category | What kind of fictional security, privacy, safety, resilience, or governance question is this? | Primary integrity concern with secondary availability and dependency concerns. | Whether the event occurred, how severe it is, or who intended it. |
| Evidence | What supports or limits the fictional claim? | Queue delay, stale state, source-health report, support tickets, and recovery exercise. | Automatic proof of one cause or complete control state. |
| Severity | How important is the fictional risk after considering impact, likelihood, exposure, controls, uncertainty, and mission context? | To be evaluated in A3.6 using defined criteria. | The category name alone does not determine severity. |
| Intent | What is known about why a fictional actor or process behaved as observed? | Deliberate, accidental, process, supplier, automation, or unknown explanation. | Role, source, timing, denial, or error alone does not prove intent. |
| Control | Which safeguard should prevent, detect, limit, recover, govern, or communicate the scenario? | State validation, bounded retry, source health, reconciliation, and owner review. | A control label does not prove implementation or effectiveness. |
| Ownership | Who validates the assumption, chooses mitigation, accepts residual risk, and maintains the decision? | Workflow owner, supplier owner, operations owner, risk owner. | Shared responsibility does not eliminate named accountability. |
Category Quality
Move from a Label to a Decision-Ready Classification
Weak category statement
Statement
This is a confidentiality threat.
Remaining problem
The label does not identify the fictional asset, actor, flow, boundary, scenario, evidence, owner, or decision.
Improvement
Explain what information could be exposed, to whom, for which purpose, through which flow, under which condition, and with which evidence limits.
Developing category statement
Statement
The supplier flow may create a privacy concern because it includes free text.
Remaining problem
The statement does not identify field purpose, actual population, destination use, retention, owner, or whether the flow is current.
Improvement
Record the field, approved purpose, minimization question, supplier boundary, evidence, unknowns, owner, and review trigger.
Strong category statement
Statement
The fictional supplier request creates a primary privacy concern and secondary confidentiality and governance concerns because a free-text support note may cross an administrative boundary without confirmed necessity, retention, or owner approval.
Remaining problem
The statement still requires current-state evidence, controls, confidence, and residual decision.
Improvement
Add field-population evidence, access, retention, validation, minimization controls, owner actions, and uncertainty.
Decision-ready category statement
Statement
The fictional supplier request is categorized primarily as privacy because the free-text support note may exceed the minimum processing purpose; confidentiality and governance are secondary because external audience and owner approval also matter. Current evidence does not prove the field is populated or unapproved, so the data and supplier owners must validate purpose, fields, retention, access, and controls before risk ranking.
Remaining problem
The category assignment remains a model and must be reviewed when fields, purpose, supplier, interface, evidence, or ownership changes.
Improvement
Record version, review date, control evidence, residual uncertainty, and change triggers.
Fictional Category Map
Northbridge Threat-Question Coverage
The following conceptual map is completely invented. It shows how one fictional system can require several distinct category lenses without treating those labels as proof or severity.
Identity
Human and service identity, session, federation, lifecycle
Authorization
Role, object, action, purpose, conditions, approval
Integrity
Data, state, order, version, configuration, decisions
Confidentiality
Audience, access, disclosure, destination, exposure
Fictional Northbridge Scenarios
Support change
Reason, confirmation, scope, privacy
Supplier result
State, delay, source health, reconciliation
Analytics proposal
Purpose, fields, inference, retention
Service identity
Owner, lifecycle, authority, recovery
Duplicate submission
Integrity, usability, communication
Recovery sequence
State, identity, evidence, closure
Temporary interface
Purpose, ownership, retirement
Notification delay
Availability, safety, trust, support
Availability
Service, dependency, delay, evidence, capacity
Accountability
Actor, action, target, reason, result, health
Privacy and safety
Purpose, minimization, people, communication
Resilience and governance
Recovery, ownership, exception, review
Fake Dashboard
Fake Northbridge Threat-Category Dashboard
Fictional category coverage, overlap, evidence, and ownership status for training only.
Scenarios categorized
18 / 18
Every fictional abuse case has one primary category and a written rationale.
Scenarios with category inflation
4
Four cases currently use more secondary labels than distinct owner or control decisions justify.
Uncategorized concerns preserved
3
Usability, communication trust, and human-review quality remain custom concerns pending owner discussion.
Fake SOC Alert
Category Assignment Mistaken for Risk Severity
Source: Fake Northbridge Threat-Model Quality Console • Time: 1:22 PM
A fictional reviewer marked every confidentiality and identity scenario High while assigning Low to availability and governance scenarios. No impact, likelihood, exposure, control, uncertainty, mission, dependency, or recovery analysis was recorded.
Defensive recommendation: Separate category from severity. Preserve the conceptual labels, document evidence and affected assets, and defer final priority until the A3.6 risk-ranking criteria are applied.
Fake Log Panel
Fake Threat-Category Review Timeline
training-log-viewer.log
09:00 REVIEW scope='northbridge-abuse-library' scenarios='18' 09:08 CATEGORY support-change primary='accountability' 09:16 CATEGORY support-change secondary='authorization,privacy,integrity' 09:24 CATEGORY supplier-delay primary='integrity' 09:32 CATEGORY supplier-delay secondary='availability,dependency,resilience' 09:40 CATEGORY analytics-proposal primary='privacy' state='future' 09:48 CATEGORY archive-identity primary='governance' 09:56 CATEGORY recovery-sequence primary='resilience' 10:04 QUALITY category-inflation='4' 10:12 QUALITY uncategorized='3' 10:20 EVIDENCE category-proof='false' 10:28 EVIDENCE intent-proof='false' 10:36 RISK severity-assignment='premature' 10:44 OWNER privacy='assigned' supplier='assigned' recovery='assigned' 10:52 ACTION reduce-secondary-labels='required' 11:00 ACTION preserve-custom-concerns='required' 11:08 REVIEW technical='complete' privacy='pending' 11:16 REVIEW operations='pending' mission='pending' 11:24 CONFIDENCE category-map='medium' 13:22 ALERT issue='category-equals-severity'
Training note: this is fake data for defensive analysis practice only.
Fictional Evidence Matrix
What the Evidence Supports—and What It Does Not Prove
TC-01
Fictional support-role matrix
Observation
The support role can reset accounts, change notification settings, view case status, and initiate reprocessing.
Supports
Identity, authorization, integrity, privacy, accountability, and governance questions may apply to different support actions.
Does not prove
The matrix does not prove current effective permission, misuse, malicious intent, or inadequate controls.
Category use
Assign categories to exact action-object scenarios rather than labeling the entire role as dangerous.
TC-02
Fictional notification-ticket review
Observation
Several notification changes lack recorded reason and user-confirmation fields.
Supports
Accountability is a strong primary category, with possible authorization, privacy, integrity, and governance overlap.
Does not prove
Missing fields do not prove that the changes were unauthorized, incorrect, deliberate, or harmful.
Category use
Separate evidence quality from actor intent and connect category assignments to owner review.
TC-03
Fictional supplier-field inventory
Observation
A processing request may include a free-text support note in addition to case reference, category, and priority.
Supports
Privacy, confidentiality, governance, integrity, and supplier-dependency questions may apply.
Does not prove
The inventory does not prove the field is populated, unnecessary, retained, accessed, or unapproved.
Category use
Use privacy as a likely primary prompt while preserving field-purpose uncertainty.
TC-04
Fictional queue-health dashboard
Observation
Result events were delayed for twenty-two minutes while source health remained Green.
Supports
Availability, integrity, accountability, dependency, and resilience questions may overlap.
Does not prove
The dashboard does not prove data loss, tampering, malicious activity, or incorrect final state.
Category use
Create category prompts about delay, state, source health, reconciliation, and evidence meaning.
TC-05
Fictional support-ticket pattern
Observation
Users submitted duplicate documents after delayed status notifications.
Supports
Integrity, availability, safety, usability, accountability, and resilience concerns may be connected.
Does not prove
The tickets do not prove one technical cause or that every duplicate had the same explanation.
Category use
Avoid category collapse by separating user impact, workflow state, communication, and evidence.
TC-06
Fictional service-identity review
Observation
An archival service identity lacks a confirmed owner and has passed its review date.
Supports
Governance is a strong primary category, with identity, authorization, accountability, and recovery overlap.
Does not prove
The record does not prove compromise, misuse, excessive permission, or active processing.
Category use
Use categories to organize owner, lifecycle, authority, activity, and recovery questions.
TC-07
Fictional recovery exercise
Observation
Application service returned before notification and archival dependencies were validated, creating stale messages and repeated archival tasks.
Supports
Resilience, integrity, availability, accountability, safety, dependency, and trust concerns are connected.
Does not prove
One exercise does not prove current exposure, future frequency, or control failure outside the exercise.
Category use
Select a primary recovery category while preserving distinct secondary outcomes and owners.
TC-08
Fictional analytics proposal
Observation
A proposed analytics process may combine portal, support, supplier, and notification events, but fields, audience, purpose, retention, and ownership remain unresolved.
Supports
Privacy and governance prompts are central, with confidentiality, integrity, accountability, and safety questions possible.
Does not prove
The proposal is future-state and does not prove current collection, exposure, or misuse.
Category use
Label the scenario future-state and require owner decisions before final risk ranking.
Analyze the Evidence
Which Category Assignment Is Best Supported?
The fictional support role can change notification settings.
Several notification-change tickets lack a recorded reason and user-confirmation field.
The available evidence does not show whether each action was authorized, accurate, accidental, deliberate, or harmful.
Notification settings affect user communication, privacy expectations, workflow state, and trust.
The ticket pattern creates questions about actor, action, target, purpose, result, and review evidence.
No risk-ranking criteria have been applied yet.
The scenario has not been connected to one confirmed technical cause.
The fictional model remains draft with medium confidence.
Which conclusion most accurately classifies the fictional notification-change evidence?
Common Mistakes
Errors That Weaken Conceptual Threat Classification
Treating categories as proof
Why it fails
A label such as integrity or privacy organizes a question but does not prove a harmful condition, control failure, or event.
Strong correction
Link every category assignment to fictional evidence, assumptions, confidence, unknowns, and owner review.
Using categories as severity
Why it fails
Category describes the type of concern, while severity requires later impact, likelihood, exposure, control, uncertainty, and mission analysis.
Strong correction
Keep category assignment separate from A3.6 risk ranking.
Assigning every category to every scenario
Why it fails
Category inflation makes the worksheet unreadable and hides which decisions, owners, controls, and evidence actually differ.
Strong correction
Use one primary category and only meaningful secondary categories.
Forcing every concern into one framework
Why it fails
Human safety, usability, supplier responsibility, governance, recovery, or context-specific concerns may not fit a chosen label set.
Strong correction
Preserve uncategorized and custom concerns when needed.
Ignoring cross-category effects
Why it fails
One fictional scenario may affect integrity, privacy, availability, accountability, recovery, and trust in different ways.
Strong correction
Record primary and secondary categories when each changes assets, owners, controls, evidence, or recovery.
Categorizing a person instead of a scenario
Why it fails
Labels should describe concerns about a fictional interaction or condition, not mark a role, employee, supplier, or user as a threat.
Strong correction
Categorize the exact actor-action-object-flow scenario and preserve intent uncertainty.
Ignoring business and user context
Why it fails
A technical label can hide user harm, fairness, communication, mission, workflow, or service impact.
Strong correction
Include mission, privacy, safety, trust, usability, and operational perspectives.
Using labels without controls or owners
Why it fails
A category list that does not change a design, evidence, ownership, or risk decision has little value.
Strong correction
Trace each category to specific questions, controls, evidence, owners, and review triggers.
Mixing current and proposed concerns
Why it fails
A future analytics design may be mistaken for an existing privacy issue.
Strong correction
Label current, future, temporary, degraded, recovery, and retired states clearly.
Using real internal classifications
Why it fails
Real threat models, categories, diagrams, roles, suppliers, evidence, and recovery details may reveal sensitive organizational information.
Strong correction
Invent every organization, actor, system, flow, scenario, category assignment, record, date, control, decision, and outcome.
Safe Fictional Practice Lab
Build the Northbridge Threat-Category Worksheet
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, threat models, diagrams, roles, logs, interfaces, suppliers, configurations, incidents, recovery details, or private information.
1
Confirm scope and category purpose
State which fictional Northbridge threat-model decision the category worksheet supports and which abuse cases, assets, actors, flows, boundaries, suppliers, and recovery states are included.
Required output
Purpose, scope, exclusions, category set, stakeholders, version, and safety boundary.
Quality check
The worksheet explains why categories are being used and what they do not prove.
2
Select decision-relevant scenarios
Choose fictional abuse cases from A3.4 that affect different assets, owners, states, and dependencies.
Required output
A scenario list with identifiers, affected assets, evidence, uncertainty, and current or future-state label.
Quality check
Each scenario is specific enough to categorize without labeling a person or entire system.
3
Assign primary categories
Choose the category that best represents the central harmful outcome or owner decision for each fictional scenario.
Required output
One primary category with written rationale for every scenario.
Quality check
The rationale explains why the category helps the decision rather than merely repeating the label.
4
Add meaningful secondary categories
Add another category only when it introduces a distinct asset, owner, control, evidence source, or recovery requirement.
Required output
A limited set of secondary categories with decision impact.
Quality check
The worksheet avoids decorative or automatic multi-labeling.
5
Preserve uncategorized concerns
Record fictional safety, usability, supplier, governance, human, or context-specific questions that do not fit clearly.
Required output
A custom-concern register with rationale and owner.
Quality check
No important concern is removed simply because the framework lacks a perfect label.
6
Connect controls and evidence
For each category assignment, record controls, evidence, evidence limits, owners, current state, assumptions, unknowns, and review triggers.
Required output
A traceability matrix from scenario to category, control, evidence, owner, and decision.
Quality check
The worksheet remains evidence-aware and does not treat labels as proof.
7
Review coverage and bias
Ask technical, privacy, data, support, operations, supplier, recovery, and mission perspectives to identify missed or overused categories.
Required output
A category coverage review, overlap log, bias findings, and revisions.
Quality check
The review can explain both category gaps and category inflation.
8
Prepare for risk ranking
Summarize which fictional scenarios are ready for ranking and which still need evidence, owner decisions, scope clarification, or category revision.
Required output
A readiness summary for A3.6 with unresolved questions and next actions.
Quality check
Category labels remain separate from severity and do not predetermine risk scores.
Scenario Decision Lab
A Reviewer Labels Every Supplier Scenario High Risk
The fictional reviewer assigns High severity to every supplier-related scenario because external services are involved. No impact, likelihood, exposure, control strength, evidence, mission, or recovery criteria are recorded.
Scenario Decision Lab
A Scenario Does Not Fit the Existing Category List
A fictional student-support communication scenario raises concerns about confusing language, accessibility, user trust, and delayed help. The current worksheet has no clear usability or communication category.
Advanced Challenge
Resolve a Category Disagreement without Choosing Labels by Vote
The fictional privacy owner classifies the supplier free-text field as privacy. The security reviewer calls it confidentiality. The supplier manager calls it governance. The workflow owner calls it integrity because the field may influence processing. Build a classification that preserves all legitimate perspectives without assigning four primary categories.
Define the decision
State whether the team must approve the field, change the flow, add controls, request evidence, or accept residual risk.
Identify the central asset
Determine whether purpose and responsible use, exposure, ownership, or workflow correctness is the main decision.
Choose one primary category
Select the label that best organizes the central owner decision and explain the rationale.
Preserve secondary categories
Add only labels that introduce different evidence, owners, controls, or outcomes.
Document disagreement
Record each owner's reasoning, supporting evidence, assumptions, and unresolved questions.
Defer severity
Do not convert the category disagreement into a risk score before A3.6 criteria are applied.
Challenge output
Create a fictional category-decision record with one primary label, limited secondary labels, owner perspectives, evidence, evidence limits, controls, unresolved questions, confidence, and a statement explaining why category disagreement can improve the model when it is documented rather than hidden.
Defender Habits
Threat Categories Conceptually Checklist
Check Your Understanding
A3.5 Mini Quiz: Threat Categories Conceptually
Choose your answers first. Explanations appear only after submission.
1. What is the main purpose of a threat category?
2. A fictional supplier result arrives late and updates stale workflow state. Which category is the strongest likely primary label?
3. Why should a scenario sometimes have secondary categories?
4. What should a reviewer do when a concern does not fit the chosen category framework?
5. A fictional service identity has no confirmed owner and an expired review. What does a governance category prove?
6. Why must category and severity remain separate?
7. Which portfolio approach is safest?
Portfolio Prompt
Portfolio Prompt
Create a fully fictional Threat-Category Worksheet for the Northbridge Student-Support Portal. Include purpose, scope, exclusions, safety boundary, category definitions, at least eighteen fictional abuse cases, one primary category per case, limited secondary categories, category rationale, affected assets, actors, entry points, flows, trust boundaries, evidence, evidence limits, assumptions, unknowns, confidence, controls, owners, current-state or future-state label, cross-category analysis, uncategorized concerns, category-inflation review, coverage review, bias review, disagreement log, readiness statement for A3.6, leadership summary, technical appendix, reflection, and a statement that every organization, scenario, actor, asset, flow, category assignment, record, control, date, decision, and outcome is invented.
Begin with the fictional scenario and decision before choosing a label.
Use one primary category and add a secondary category only when it changes the owner, control, evidence, recovery, or affected asset.
Preserve custom or uncategorized concerns rather than forcing every scenario into one framework.
Keep category, evidence, severity, intent, control, and ownership as separate fields.
Keep the entire artifact completely fictional, defensive, evidence-aware, non-operational, privacy-safe, and suitable for a public learning portfolio.
Confidence / Readiness Reflection
Are You Ready to Rank Threat-Model Risks?
Before moving to A3.6, rate your readiness from 1 to 5 for category purpose, primary and secondary labels, cross-category reasoning, uncategorized concerns, evidence limits, intent separation, severity separation, control traceability, owner decisions, bias review, and complete fictionalization.
I can explain why a category organizes a question but does not prove an event or control failure.
I can choose a primary category based on the central affected asset and decision.
I can add secondary categories only when they create distinct owner, evidence, control, or recovery needs.
I can preserve uncategorized, human, usability, safety, supplier, and context-specific concerns.
I can separate category assignment from severity, intent, evidence, and exploitability.
I can identify category inflation, category collapse, and framework bias.
I can document category disagreement and use it to improve the model.
I can create a complete fictional worksheet without copying, modifying, or exposing real internal information.
Record one fictional scenario whose primary category changed after review, one useful secondary category, one concern you preserved outside the framework, one category-evidence limitation, and one question you will carry into A3.6 risk ranking.
Key Takeaways
What You Should Remember
1.Threat categories are conceptual prompts that organize defensive questions; they do not prove events, control failure, exploitability, severity, or intent.
2.The most useful categories connect directly to fictional assets, actors, flows, boundaries, abuse cases, controls, evidence, owners, and decisions.
3.Identity, authorization, integrity, confidentiality, availability, accountability, privacy, safety, resilience, dependency, and governance provide different review lenses.
4.One scenario may have a primary category and several meaningful secondary categories.
5.Secondary categories should be used only when they introduce different assets, owners, controls, evidence, recovery, or user outcomes.
6.Uncategorized and custom concerns should be preserved when the framework does not fit.
7.Category inflation and category collapse both reduce decision quality.
8.Category, evidence, severity, intent, control, and ownership answer different questions and should remain separate.
9.Category assignments should be versioned and reviewed when system purpose, assets, actors, flows, suppliers, automation, recovery, evidence, or ownership changes.
10.Every CyberShield category worksheet and artifact must remain fully fictional, authorized, defensive, non-operational, privacy-safe, and incapable of exposing real systems or people.
Navigation
Continue Module A3
Next, use fictional evidence and clearly defined criteria to rank threat-model risks without confusing category labels with impact, likelihood, exposure, control strength, uncertainty, or mission priority.