Lesson A20.3
The capstone briefing told us what evidence exists. Architecture tells us how the fictional environment fits together. Threat modeling then asks which plausible conditions could affect important assets and which defensive controls, evidence, resilience, and ownership decisions matter.
This phase does not hunt for real vulnerabilities or prove an attacker exists. It builds a safe, evidence-aware decision model for the later detection, incident-response, cloud, identity, risk, privacy, and executive phases.
Lesson Progress
High School Advanced • A20: Advanced Capstone • Lesson 3 of 10
Readiness Check
0/4 ready
Professional Hook
A list of technologies is not an architecture review. A professional reviewer needs to understand which services support the mission, which identities can act, which data moves where, which trust assumptions change, which dependencies are concentrated, and what happens when important controls or services degrade.
Threat modeling adds a second question: under what plausible conditions could those relationships produce a meaningful security, privacy, reliability, or recovery concern? The answer should lead to defensive controls and evidence needs—not exploitation procedures.
Learning Objectives
Translate the A20 case charter into a security architecture view that identifies critical assets, identities, data flows, trust boundaries, dependencies, control locations, and recovery paths.
Write bounded threat statements that connect plausible conditions to affected assets and defensive consequences without claiming unsupported vulnerabilities, intent, or exploitation.
Distinguish architecture facts, design assumptions, expected control behavior, implementation evidence, and unresolved validation needs.
Evaluate concentration, dependency, degraded-mode, and recovery risks so the capstone architecture remains resilient rather than focusing only on prevention.
Create an Architecture and Threat Model Decision Pack that later detection, incident-response, cloud, identity, risk, privacy, and executive phases can reference consistently.
Architecture Review
The architecture review should become more specific as it moves from mission to assets, identities, flows, trust, controls, dependencies, and recovery. Each layer should answer a different professional question.
Review question: Which fictional service outcomes matter most, and what would materially affect users or business operations?
Northbridge: Northbridge Learning Portal availability, trustworthy administrative actions, protected student-service data, reliable reporting, and recoverable service operations.
Evidence: Case charter, service inventory, business-impact notes, ownership records.
Review question: Which applications, identities, services, data stores, queues, configuration states, logs, and recovery assets deserve protection?
Northbridge: Portal application, identity platform, worker service, protected data store, reporting queue, monitoring pipeline, configuration records, and backup/recovery artifacts.
Evidence: Architecture inventory, data-classification notes, service records, recovery inventory.
Review question: Which human and workload identities can act, what resources can they reach, and where does privilege change?
Northbridge: Student users, staff users, privileged administrators, portal workload identity, worker workload identity, monitoring service identity, and recovery operator role.
Evidence: Role inventory, approval records, identity design, access-review notes.
Review question: What information or requests move between components, and what security expectations apply at each step?
Northbridge: User requests reach the portal, the portal requests identity and data services, worker jobs use queue and storage dependencies, and monitoring sources export evidence to the collector.
Evidence: Architecture diagram, application-flow notes, service dependency map.
Review question: Where does control, identity, administrative authority, data sensitivity, environment, or organizational responsibility change?
Northbridge: User-to-portal, portal-to-data, administrator-to-management plane, workload-to-cloud service, provider/customer boundary, and monitoring-source-to-collector relationships.
Evidence: Architecture diagram, role definitions, cloud responsibility notes, policy requirements.
Review question: Which prevention, detection, response, recovery, privacy, and governance controls should exist at important boundaries?
Northbridge: Strong identity, least privilege, scoped service access, audit evidence, source-health monitoring, change governance, recovery validation, and privacy-aware telemetry.
Evidence: Policy, standards, threat model, detection plan, recovery requirements.
Review question: Which shared services could affect several security or availability outcomes at once?
Northbridge: Identity, monitoring, worker queue, protected storage, configuration, and recovery services create shared dependency relationships.
Evidence: Dependency inventory, service-health records, architecture review.
Review question: How should the environment behave when identity, monitoring, queue, or recovery dependencies are partially unavailable?
Northbridge: Critical functions should have bounded degraded behavior, clear ownership, recovery priorities, source-health awareness, and validation before normal confidence returns.
Evidence: Recovery objectives, degraded-mode notes, service-owner decisions, validation records.
Trust Boundaries
A trust boundary is not simply a line between two boxes. It marks a place where identity, privilege, data sensitivity, environment, administrative authority, or operational responsibility changes.
Untrusted or partially trusted user requests enter an application that must authenticate, authorize, validate, and protect data.
The application workload crosses into a more sensitive data plane where resource-level authorization and workload identity matter.
Human administrative authority increases and can change identity policy, application configuration, or service state.
A workload identity processes queued jobs and reaches protected storage on behalf of application workflows.
Security and service evidence crosses from producing systems into the monitoring plane, creating a dependency on collection health and timing.
Operational responsibility is split between managed platform capabilities and customer-controlled identity, configuration, data, monitoring, and governance choices.
Fake Dashboard
Synthetic architecture, dependency, and trust-boundary snapshot
Critical architecture layers
8
Mission through recovery and degraded operation
Named trust boundaries
6
User, data, administration, workload, monitoring, cloud responsibility
Concentration dependencies
6
Identity, monitoring, queue, data, change/configuration, recovery
Open architecture findings
5
Each has evidence, implication, and fictional owner
Fake SOC Alert
Source: Synthetic Northbridge Architecture Quality Check • Time: A20.3 architecture review
Fake Log Panel
[ARCH] portal depends on identity, worker, protected data, monitoring, and recovery services [TRUST] privileged administration crosses a high-authority boundary [IDENTITY] worker workload identity reaches queue and protected data relationships [MONITOR] collector delay affects multiple downstream evidence decisions [QUEUE] latency increased before portal errors; causation remains unresolved [CHANGE] approved maintenance establishes context but not event-level proof [RECOVERY] backup status current; complete restoration evidence older than preferred review window [PRIVACY] monitoring purpose and minimization remain later review questions [SAFETY] all architecture and threat-model records are fictional and non-operational
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Dependency Analysis
A dependency deserves special attention when many services, controls, or decisions rely on it. Concentration does not mean the dependency is bad. It means architecture should understand how failure, delay, compromise, or uncertainty would affect multiple outcomes.
Threat Modeling
Threat modeling should make architecture more useful, not more sensational. A strong threat statement describes a plausible condition, the asset or security outcome that could be affected, the consequence that matters, the controls that reduce the concern, and the confidence supported by the current case.
Condition: If privileged administrative actions occur outside the approved maintenance scope or cannot be traced to an accountable owner
Affected asset/outcome: identity policy, configuration integrity, and service trust
Consequence: defenders may be unable to distinguish expected administration from an unauthorized or process-failure condition
Defensive controls: bounded privileged access, explicit change-task scope, session evidence, approval, revocation, and retrospective review
Current confidence: Medium — the 09:11 event is confirmed, but whether it matched the approved task remains unresolved.
Condition: If monitoring-source health degrades without being represented separately from event content
Affected asset/outcome: detection confidence and incident chronology
Consequence: missing or late events may lead reviewers to make unsupported negative-evidence conclusions
Defensive controls: source-health monitoring, backlog visibility, timestamp normalization, degraded-state indicators, and recovery validation
Current confidence: High — the briefing already confirms collector delay during the case window.
Condition: If a workload identity has broader access than its worker-service purpose requires
Affected asset/outcome: protected data and job integrity
Consequence: a service error or identity misuse could affect more resources than the business workflow requires
Defensive controls: scoped workload authorization, narrow destinations, role ownership, access review, audit evidence, and revocation
Current confidence: Low to Medium — the architecture shows the relationship, but current role scope has not yet been reviewed.
Condition: If queue health, application health, and maintenance timing are reviewed independently
Affected asset/outcome: availability reasoning and incident-scope accuracy
Consequence: a dependency problem may be misclassified as a direct application or security cause
Defensive controls: dependency mapping, normalized timing, service-health correlation, owner context, and multiple competing hypotheses
Current confidence: High that the reasoning risk exists; the case does not yet establish which dependency caused the interruption.
Condition: If backup availability is treated as proof of complete recovery readiness
Affected asset/outcome: service continuity and trustworthy restoration
Consequence: leaders may believe the environment can recover when restoration procedures, identities, dependencies, or evidence are stale
Defensive controls: current restoration exercises, dependency validation, recovery-role review, RTO/RPO evidence, and residual-risk ownership
Current confidence: High — the case briefing identifies current backups but older full restoration evidence.
Condition: If technical telemetry collects more data than the defensive purpose requires
Affected asset/outcome: privacy, trust, and governance quality
Consequence: monitoring may create unnecessary access, retention, or data-exposure risk
Defensive controls: purpose limitation, minimization, role-based access, retention rules, review, and privacy-aware logging
Current confidence: Conceptual — A20.7 will evaluate actual synthetic data-purpose and minimization evidence.
Evidence Discipline
The supplied diagram shows the portal depends on identity, worker, data, monitoring, and recovery services.
Use: Can support dependency and trust-boundary reasoning.
The architecture inventory is assumed current unless later evidence contradicts it.
Use: Allows modeling to proceed while keeping freshness uncertainty visible.
Privileged maintenance should use approved, accountable, bounded administrative access.
Use: Defines what the defensive design expects.
A synthetic identity record confirms that a privileged event occurred under a named administrative role.
Use: Supports a statement about observed behavior, not automatically about purpose or correctness.
A post-change record confirms that expected service behavior and access restrictions were checked after maintenance.
Use: Supports whether a control or change achieved its intended outcome.
The current evidence does not confirm whether the 09:11 privileged event was included in the approved task.
Use: Blocks stronger claims until additional case evidence resolves or governs the uncertainty.
Analyze the Evidence
Architecture Findings
Finding: Identity and monitoring are high-concentration dependencies for both operations and defensive interpretation.
Evidence: Architecture inventory plus case briefing shows several access and investigation decisions depend on both services.
Carry forward: Degraded-state design and independent health evidence should be treated as architecture requirements.
Finding: The privileged administrative path crosses a strong trust boundary and requires better task-level traceability.
Evidence: 09:11 privileged event is confirmed, but the summarized approved change record does not explicitly map that exact action.
Carry forward: A20 should preserve this as a validation need instead of classifying the event as expected or unauthorized.
Finding: The worker queue is an important availability and analysis dependency.
Evidence: Queue latency increased before portal errors, but causation remains unconfirmed.
Carry forward: Later detection and incident phases should include queue health and normalized timing in the evidence model.
Finding: Recovery architecture has a freshness gap between current backup status and older restoration validation.
Evidence: Recovery inventory confirms current backup status while the latest full restoration exercise is older than the preferred review window.
Carry forward: Recovery confidence should remain bounded until restoration and dependency evidence is refreshed or residual risk is accepted.
Finding: Workload identity scope is a material architecture question that should be carried into A20.6.
Evidence: Worker service accesses queue and protected data, but the current briefing does not contain complete authorization-scope evidence.
Carry forward: Do not label the access weak or excessive yet; create a targeted identity-review question.
Common Architecture Mistakes
A diagram can document intended structure without proving every deployed control, current permission, or operational behavior.
Threat models can identify plausible conditions and validation needs without claiming a confirmed weakness.
Service and workload identities can hold meaningful access and need purpose, ownership, scope, review, and lifecycle governance.
Architecture should explain how decisions change when identity, monitoring, queue, or recovery services are partially unhealthy.
An earlier queue or administrative event may be relevant without being the proven cause of a later service symptom.
Recovery also depends on restoration evidence, dependencies, identities, ownership, timing, and validation.
Safe Fictional Lab
Use only the synthetic Northbridge evidence supplied in A20.2 and this lesson. The goal is to create a defensible model for later phases, not to test or attack anything.
List the portal mission, protected data, critical services, human identities, workload identities, evidence systems, and recovery assets.
Create a fictional diagram showing portal, identity, worker, queue, data, monitoring, recovery, and important administrative relationships.
Label at least five places where identity, privilege, data sensitivity, environment, or responsibility changes.
Identify at least four concentration dependencies and describe degraded behavior, evidence needs, and recovery ownership.
Write at least five bounded threat statements using condition, affected asset/outcome, consequence, controls, and current confidence.
Create architecture findings for A20.4–A20.7 that identify what monitoring, identity, recovery, risk, or privacy evidence should be reviewed later.
Scenario Decision Lab
The worker service clearly needs queue and protected-data access, but the supplied case does not contain complete evidence showing the exact current workload permissions.
Scenario Decision Lab
Northbridge has current backup status, but the latest full restoration exercise is older than the preferred review window.
Advanced Challenge
Choose the monitoring collector as the example concentration dependency. Explain the same architecture decision from four professional perspectives while preserving one consistent set of facts.
Explain why one collection path serving many sources creates concentration and degraded-mode requirements.
Explain why source health and backlog state must be visible separately from alert content.
Explain why missing events during a delay should not be treated as strong negative evidence.
Explain the business effect of reduced visibility, the residual risk, the owner, and the improvement decision.
Defender Habits
Assessment
Check Your Understanding
Choose your answers first. Explanations appear only after submission.
Portfolio Prompt
Create a fictional Northbridge Architecture and Threat Model Decision Pack. Include mission, critical services, assets, protected data, human identities, workload identities, service flows, administrative flows, monitoring flows, at least five trust boundaries, at least four concentration dependencies, degraded-mode considerations, recovery paths, control expectations, evidence sources, architecture assumptions, implementation-evidence gaps, at least five bounded threat statements, current confidence, defensive controls, architecture findings, fictional owners, validation needs, unresolved questions, and a short summary explaining which findings should be carried into detection, incident response, cloud, identity, risk, privacy, and recovery review.
Confidence / Readiness Reflection
A20.4 moves into Detection and Monitoring Phase. Before continuing, make sure the architecture model identifies what defenders need to observe and why those sources matter.
I can identify which architecture relationships should influence monitoring priorities.
I can explain why source health is itself an important defensive signal.
I can identify identity, queue, application, data, configuration, and recovery relationships that deserve observable evidence.
I can distinguish a threat-model concern from a confirmed incident.
I can carry architecture findings into A20.4 without turning them into unsupported alert conclusions.
Portfolio Build Guide
Trust boundaries, findings, dependencies, threats, and validation needs should be easy to reference from later artifacts.
If later evidence proves or disproves an assumption, record the change instead of silently rewriting the model.
Every important architecture conclusion should identify the source or assumption supporting it.
Workload identity, monitoring delay, recovery freshness, and maintenance-scope questions belong in later A20 phases.
Let diagrams show relationships while written notes explain evidence, confidence, limitations, and decisions.
Identity, monitoring, queue, data, and recovery services should have expected behavior when partially unavailable.
Architecture owners should align with later detection, response, cloud, identity, risk, and recovery decisions.
Keep all names, systems, addresses, diagrams, roles, evidence, and control details fictional and non-operational.
Key Takeaways
Lesson Safety Boundary
Use only the fictional Northbridge architecture and synthetic records supplied by CyberShield Academy. Do not scan, probe, enumerate, test credentials, exploit, bypass, evade monitoring, access cloud accounts, inspect private systems, collect real logs, recreate confidential production architecture, or validate threats against real targets. The purpose is to reason about defensive design, evidence, governance, resilience, and safe validation needs.
Lesson Complete
The capstone now has a shared architecture, trust-boundary model, dependency review, bounded threat statements, and architecture findings. Next, A20.4 turns those findings into defensive monitoring questions, telemetry requirements, source-health decisions, and detection-quality review.