Defense in depth
A fictional design strategy that combines coordinated preventive, detective, responsive, recovery, governance, and human controls so one failure does not expose the entire mission.
High School AdvancedModule A2Lesson 2 of 10Layered Defense
A2.2 Defense-in-Depth Design
Learn how advanced defenders build fictional control layers that prevent, detect, limit, respond, recover, and improve without all failing through the same platform, identity, administrator, data source, network path, supplier, or assumption.
Lesson Progress
Defense-in-Depth Design
High School Advanced • A2: Security Architecture • Lesson 2 of 10
20% complete
Readiness Check
Before You Start
0/6 ready
Professional Hook
Five Controls Can Still Equal One Failure
A fictional design lists identity checks, approval, privileged access, logging, and recovery as separate layers. All five depend on the same identity platform and administrator group. If that dependency becomes unavailable or untrustworthy, prevention, evidence, response, and recovery may fail together. Defense in depth requires meaningful independence, not a longer inventory.
False depth
Several fictional controls share the same platform, owner, identity, evidence source, network, and recovery path.
Defensible depth
Layers protect different stages, retain evidence, fail safely, recover independently, and have clear owners.
Objective 1
Explain defense in depth as coordinated fictional protection across prevention, detection, response, recovery, governance, and human decision-making rather than simply adding more tools.
Objective 2
Distinguish independent control layers from duplicated controls that share the same platform, identity, data source, administrator, network path, supplier, or failure mode.
Objective 3
Map fictional controls to mission outcomes, assets, trust boundaries, threats, evidence sources, owners, failure conditions, and validation methods.
Objective 4
Design a fictional layered-defense strategy that preserves privacy, service continuity, evidence integrity, least privilege, safe failure, and recovery.
Objective 5
Create a portfolio-ready defense-in-depth package using only invented organizations, systems, identities, evidence, decisions, dates, controls, and outcomes.
Why This Matters
Layered Protection Should Reduce Likelihood and Consequence
Fictional preventive controls lower the chance of unsafe action, but no control is perfect. Detection should reveal failed prevention. Response should limit scope while preserving service and evidence. Recovery should restore known safe outcomes. Governance and learning should prevent the same weakness from returning.
Reduce likelihood
Use fictional secure defaults, least privilege, segmentation, validation, and approved change.
Reduce impact
Limit fictional blast radius through narrow access, service boundaries, rate limits, and targeted response.
Restore trust
Preserve fictional evidence, recover known states, validate outcomes, communicate, and improve.
Core Model
Prevent → Detect → Limit → Recover → Learn
Prevent
Reduce fictional unsafe access, exposure, change, communication, and data use before harm occurs.
Detect
Produce trustworthy fictional evidence that a control, service, identity, path, or assumption may have failed.
Limit
Use fictional response, segmentation, approval, rate limits, and service context to contain impact.
Recover
Restore fictional identity, data, service, evidence, access, and trust from approved known states.
Learn
Use fictional tests, events, exceptions, and evidence to improve architecture and ownership.
Advanced Vocabulary
Language for Layered Defense
Control layer
A fictional safeguard or group of safeguards protecting a mission outcome, asset, identity, data flow, trust boundary, service, or recovery path.
Preventive control
A fictional safeguard intended to reduce the likelihood or scope of unsafe behavior before it succeeds.
Detective control
A fictional safeguard intended to produce trustworthy evidence that unusual, unauthorized, failed, or harmful activity may be occurring.
Responsive control
A fictional decision, workflow, communication, containment, or escalation used while an issue is being reviewed.
Recovery control
A fictional safeguard that restores identity, data, service, configuration, evidence, or operations to an approved known state.
Compensating control
A fictional alternative safeguard used when a preferred requirement cannot be implemented fully, with documented limits and owner approval.
Control dependency
A fictional platform, identity, source, network, administrator, supplier, service, clock, or process required for a control to work.
Correlated failure
A fictional event in which several controls fail together because they rely on the same dependency or assumption.
Control diversity
Using fictional safeguards with meaningfully different mechanisms, evidence, owners, or failure paths.
Blast radius
The fictional scope of systems, identities, users, data, services, or decisions affected when a failure occurs.
Safe default
A fictional state that limits access, exposure, or action when a control, input, owner, or dependency becomes unreliable.
Fail-open
A fictional behavior that allows access or service to continue when a control fails, preserving availability while increasing some security risk.
Fail-closed
A fictional behavior that blocks access or service when a control fails, reducing some exposure while increasing availability risk.
Effective-state validation
Evidence that a fictional control works in the actual design state rather than only appearing in documentation or intended configuration.
Residual exposure
The fictional risk remaining after layered controls are applied, including exceptions, shared dependencies, uncertainty, and operational limits.
Control Layers
Eight Connected Layers of a Defensible Fictional Architecture
Mission and governance
Keep fictional security decisions aligned with purpose, ownership, privacy, service continuity, and risk tolerance.
Examples
Requirements, approvals, exceptions, change control, review cadence, risk acceptance, and portfolio safety.
Failure mode
Technical controls operate without clear authority, purpose, or residual-risk ownership.
Independence question
Can governance still stop or correct the design if a technical platform or operator fails?
Evidence
Decision records, approvals, exceptions, review notes, and owner signoff.
Identity and privilege
Limit which fictional humans, services, devices, and workloads may act and under what conditions.
Examples
Authentication, authorization, least privilege, role separation, lifecycle, emergency access, review, and monitoring.
Failure mode
One mistaken or compromised identity reaches too many critical functions.
Independence question
Do critical actions require separate approval, context, or evidence beyond the same identity service?
Evidence
Role matrix, approvals, reviews, lifecycle records, and privileged-session evidence.
Workload and application protection
Reduce fictional exposure and validate requests, authorization, configuration, errors, services, and dependencies.
Examples
Secure baselines, least functionality, request validation, service identity, rate limits, error handling, and rollback.
Failure mode
A weak workload becomes a path to data, identity, or service control.
Independence question
Can identity, network, data, and visibility controls still limit impact if the workload layer fails?
Evidence
Baseline review, service map, authorization checks, error records, and approved tests.
Network and trust boundaries
Limit unnecessary fictional communication and require validation where trust, ownership, or sensitivity changes.
Examples
Zones, approved flows, gateways, segmentation, supplier paths, remote access, monitoring, and exceptions.
Failure mode
A single allowed path enables broad movement or bypasses intended service boundaries.
Independence question
Do identity, application, and data controls still work if one network path is misconfigured?
Evidence
Zone diagram, flow matrix, effective-path review, denied-path checks, and exception records.
Data protection and privacy
Limit fictional collection, access, exposure, alteration, sharing, retention, and loss.
Examples
Classification, minimum necessary, access control, encryption concepts, integrity, retention, deletion, backup, and audit.
Failure mode
A broad identity or service failure exposes more information than the mission requires.
Independence question
Does data remain limited and recoverable if application or identity controls fail?
Evidence
Data inventory, flow map, field allowlist, access evidence, retention, deletion, and restore checks.
Detection and visibility
Provide trustworthy fictional evidence about identity, system, network, application, data, change, and recovery behavior.
Examples
Logs, alerts, metrics, source health, time quality, integrity, retention, access, and case linkage.
Failure mode
The team cannot detect or reconstruct control failure, misuse, drift, or recovery errors.
Independence question
Do important events remain visible if one platform, source, clock, or administrator becomes unreliable?
Evidence
Coverage map, sample events, source-health records, time-quality checks, and access review.
Response and communication
Coordinate fictional triage, containment, approvals, owner decisions, user guidance, supplier contact, and status messages.
Examples
Playbooks, approval gates, case ownership, safe messages, escalation, corrections, and status cadence.
Failure mode
A technically correct action creates confusion, service harm, privacy exposure, or delayed decisions.
Independence question
Can authorized owners pause or alter an automated or technical response?
Evidence
Case notes, approvals, communication logs, acknowledgments, and corrections.
Resilience, recovery, and learning
Preserve critical functions, restore known states, validate outcomes, and strengthen the fictional architecture after failure.
Examples
Redundancy, backups, restoration, rollback, dependency order, exercises, after-action review, and improvement.
Failure mode
One outage removes service, evidence, identity, recovery, and future learning together.
Independence question
Are recovery and review separate enough from the systems and owners they must restore or challenge?
Evidence
Recovery exercises, restore records, health checks, lessons learned, corrective actions, and signoff.
Independence Tests
Six Tests for Real Depth versus Repeated Weakness
Different mechanism
Does the fictional secondary control protect the outcome in a different way?
Weak example
Two passwords protect the same administrator account.
Strong example
Least privilege, independent approval, session evidence, validation, and rollback protect different stages.
Validation
Map how each layer works and which failure it addresses.
Different dependency
Do several fictional controls rely on the same identity service, platform, network, supplier, source, clock, or administrator?
Weak example
Authentication, approval, logging, and recovery all depend on one unavailable platform.
Strong example
Critical evidence, approval, and recovery retain separate approved paths and owners.
Validation
Create a control-to-dependency matrix and review one-dependency loss.
Different owner
Can one fictional person disable, bypass, approve, and hide every layer?
Weak example
One support administrator owns identity, application, data, logs, and backups.
Strong example
Critical decisions use role separation, owner-specific approval, and independent validation.
Validation
Review authority, emergency access, approval, evidence ownership, and signoff.
Different evidence
Would one fictional source failure remove proof from every layer?
Weak example
All controls write only to the same logging platform.
Strong example
Important actions leave source, destination, owner, and recovery evidence with source-health checks.
Validation
Confirm key defender questions remain answerable when one source is unavailable.
Different failure state
Do fictional controls fail open or fail closed in ways that create the same harmful outcome?
Weak example
Every layer blocks access when one shared service fails, causing total outage.
Strong example
Critical approved functions use a limited safe degraded mode while risky actions remain blocked.
Validation
Document fail-open, fail-closed, degraded, manual, and recovery behavior.
Different recovery path
Can fictional recovery operate if the primary environment, identity service, or administrator is unavailable?
Weak example
Backups require the same failed identity platform and administrator.
Strong example
Recovery uses separate approved authority, evidence, restore states, and validation.
Validation
Review recovery access, integrity, dependency order, restoration, and post-recovery checks.
Correlated Failure Domains
What Happens When Shared Dependencies Fail
Identity-service failure
Affected layers
Authentication, authorization, approval, administration, attribution, and recovery access.
Main danger
Several fictional layers may fail together or block every service.
Design response
Use limited degraded service, separate emergency ownership, independent evidence, and recovery validation.
Stop condition
No owner can confirm who may act safely during the outage.
Logging-platform failure
Affected layers
Detection, investigation, change validation, identity evidence, supplier review, and recovery proof.
Main danger
The team may continue high-impact work without reliable evidence.
Design response
Use source-health alerts, independent records, action limits, manual review, and safe fallback.
Stop condition
Critical actions cannot be reconstructed or attributed.
Network-control failure
Affected layers
Segmentation, remote access, supplier paths, management traffic, and monitoring visibility.
Main danger
Broad reachability or unnecessary total service loss may occur.
Design response
Use identity and application validation, safe defaults, targeted isolation, approved fallback paths, and owner review.
Stop condition
Effective paths cannot be confirmed against the approved design.
Administrator misuse or error
Affected layers
Identity, configuration, data, logging, backup, recovery, and evidence integrity.
Main danger
One fictional identity may alter both systems and proof of the alteration.
Design response
Separate duties, require approval, limit sessions, preserve independent evidence, and review effective state.
Stop condition
The same identity can change controls and remove all evidence.
Bad automation or rule update
Affected layers
Detection, response, identity, communication, service availability, fairness, and audit.
Main danger
The same incorrect fictional action may scale rapidly.
Design response
Use narrow scope, approval gates, rate limits, versioning, rollback, monitoring, and manual fallback.
Stop condition
High-impact action occurs without approver, explanation, or rollback.
Recovery-path failure
Affected layers
Restoration, evidence, continuity, trust, identity, data consistency, and future resilience.
Main danger
The organization may restore unsafe, incomplete, or altered states.
Design response
Use separate ownership, protected restore states, integrity checks, exercises, and complete service validation.
Stop condition
Restore integrity or recovery authority cannot be confirmed.
Defense-in-Depth Workflow
Ten Steps from Mission Outcome to Governed Layers
1
Define the mission outcome
Which fictional function, user need, data, service, decision, or recovery outcome must remain protected?
Required output
Mission and critical-outcome statement.
Stop condition
Do not design layers without knowing which outcome they protect.
2
Identify assets, flows, and trust boundaries
Which fictional systems, identities, data, paths, suppliers, owners, and dependencies enable the outcome?
Required output
Context, trust-boundary, and dependency map.
Stop condition
Pause if important ownership or paths are unclear.
3
Write control objectives
What must the fictional design prevent, detect, limit, preserve, continue, restore, explain, and validate?
Required output
Measurable layered-control requirements.
Stop condition
Reject vague objectives that cannot be tested.
4
Select control layers
Which fictional identity, workload, network, application, data, visibility, response, recovery, and governance safeguards support each objective?
Required output
Layered control map.
Stop condition
Do not count repeated versions of the same control as independent depth.
5
Map dependencies and correlated failure
Which fictional platform, identity, administrator, supplier, source, network, clock, or process does each layer require?
Required output
Control-to-dependency and failure-domain matrix.
Stop condition
Pause if one failure removes prevention, evidence, response, and recovery together.
6
Design safe failure
Should each fictional control fail open, fail closed, degrade, pause, or require manual fallback?
Required output
Failure-state and fallback design.
Stop condition
Do not accept uncontrolled access or unnecessary total outage.
7
Assign ownership and approval
Who designs, operates, changes, monitors, approves, validates, recovers, communicates, and accepts residual exposure?
Required output
Control-owner and decision map.
Stop condition
Pause if one person can bypass all layers or hide the evidence.
8
Validate layers and the combined service
What fictional evidence proves individual controls and end-to-end outcomes work under normal, degraded, failed, and recovered states?
Required output
Layer and end-to-end validation plan.
Stop condition
Do not approve based only on intended configuration.
9
Measure residual exposure
What fictional risk remains from exceptions, shared dependencies, uncertainty, usability, privacy, service, suppliers, and recovery limits?
Required output
Residual-exposure register and owner decision.
Stop condition
Do not claim that defense in depth makes the system perfectly secure.
10
Govern change and improvement
How are fictional controls, dependencies, owners, exceptions, evidence, failures, suppliers, and recovery reviewed over time?
Required output
Defense-depth lifecycle and improvement plan.
Stop condition
Do not allow layers to drift, duplicate, or lose evidence silently.
Layer Ownership
Eight Owners for Design, Operation, Validation, and Risk
Mission owner
Responsibility
Defines the fictional critical outcome, acceptable disruption, user need, service priority, and business risk.
Primary decision
Whether the layered design protects the mission sufficiently.
Required evidence
Mission priorities, service expectations, options, and risk acceptance.
Security architect
Responsibility
Coordinates fictional control objectives, layers, dependencies, failure states, evidence, tradeoffs, and decisions.
Primary decision
Whether the layers are meaningful, independent enough, measurable, and governed.
Required evidence
Layer map, dependency matrix, requirements, failure analysis, and validation plan.
Identity owner
Responsibility
Owns fictional authentication, authorization, privilege, lifecycle, emergency access, approval, and identity evidence.
Primary decision
Which identities and access paths may support each layer.
Required evidence
Role matrix, approvals, lifecycle, privileged-session records, and reviews.
Network and platform owner
Responsibility
Owns fictional zones, paths, gateways, infrastructure, dependencies, configuration, availability, and monitoring.
Primary decision
Which communication paths and fallback modes are supportable.
Required evidence
Flow matrix, effective-state checks, health records, changes, and exceptions.
Service and data owners
Responsibility
Own fictional service behavior, dependencies, continuity, data purpose, fields, access, retention, deletion, and restore needs.
Primary decision
Whether controls preserve service and minimum-necessary data use.
Required evidence
Service map, data inventory, access review, health tests, retention, deletion, and rollback.
Evidence owner
Responsibility
Owns fictional logs, alerts, metrics, source health, time quality, integrity, access, retention, and coverage.
Primary decision
Whether layer failure and recovery can be detected and reconstructed.
Required evidence
Coverage map, source-health checks, sample events, and retention evidence.
Response and recovery owner
Responsibility
Owns fictional containment, communication, rollback, continuity, restoration, exercises, and recovery validation.
Primary decision
Whether the design can fail and recover safely.
Required evidence
Playbooks, approvals, restore records, health checks, and signoff.
Governance and risk owner
Responsibility
Owns fictional versions, exceptions, review cadence, control drift, residual exposure, and final acceptance.
Primary decision
Which layered design and remaining risk are acceptable.
Required evidence
Decision record, architecture diff, exceptions, corrective actions, and acceptance.
Design Patterns
Six Fictional Patterns for Meaningful Layered Protection
Identity plus context plus approval
Mission outcome
Protect fictional privileged changes without relying on one password or one identity decision.
Layers
Authentication, least privilege, separate approval, session evidence, change validation, and rollback.
Failure resistance
A stolen credential alone does not create complete authority.
Validation
Approved requests succeed; unapproved or context-mismatched requests are denied and recorded.
Segmented service path
Mission outcome
Limit fictional application-to-data communication to the required service path.
Layers
Trust zones, service identity, application authorization, narrow data role, path monitoring, and denied direct administration.
Failure resistance
One network or application mistake does not expose every data function.
Validation
Approved flow works; alternate path is denied; evidence identifies actor, service, target, and result.
Protected evidence chain
Mission outcome
Preserve fictional evidence when one logging component fails.
Layers
Source records, transport health, central analysis, independent administrative evidence, time-quality monitoring, and access control.
Failure resistance
One platform outage does not remove all visibility.
Validation
Important actions remain reconstructable during source or platform degradation.
Safe automated response
Mission outcome
Reduce fictional risk quickly without scaling an incorrect action.
Layers
Narrow detection, evidence enrichment, human approval, service context, rate limit, reversible action, audit, and rollback.
Failure resistance
One noisy rule cannot disable many critical identities.
Validation
Noisy input triggers pause or capped action rather than broad disruption.
Resilient recovery
Mission outcome
Restore fictional service, identity, data, logging, access, and communication from known states.
Layers
Protected recovery identity, separate evidence, data integrity, dependency order, service checks, user validation, and monitoring.
Failure resistance
Recovery does not depend completely on the failed production environment.
Validation
The complete service outcome is restored and independently signed off.
Governed supplier dependency
Mission outcome
Use a fictional external service without relying on invisible supplier assumptions.
Layers
Supplier requirements, owner, evidence, access limits, monitoring, communication, fallback, exit, and risk review.
Failure resistance
Supplier outage or change does not remove every mission function.
Validation
Fallback, evidence, communication, and owner decisions are reviewed and exercised conceptually.
Fake Dashboard
Fake Northbridge Defense-in-Depth Dashboard
Fictional control-layer, dependency, evidence, failure, and recovery review for training only.
Listed controls
12
Twelve controls appear in the fictional inventory.
Shared dependencies
5
Identity, administration, logging, approval, and recovery share one platform and owner group.
Depth status
Weak
The design has multiple controls but insufficient independence and recovery separation.
Fake SOC Alert
Layered Controls Share One Identity, Evidence, and Recovery Failure Domain
Source: Fake Northbridge Defense Architecture Console • Time: 3:18 PM
Five fictional controls depend on the same identity platform and administrator group. High-impact automation can disable critical accounts without service approval, and restoration requires the same failed access path.
Defensive recommendation: Pause approval, map dependencies, separate authority and evidence, add approval gates and rate limits, design safe degraded operation, create independent recovery access, validate end-to-end outcomes, and document residual exposure.
Fake Log Panel
Fake Layered-Defense Review Timeline
training-log-viewer.log
14:00 CONTROL identity-auth='enabled' 14:01 CONTROL privileged-approval='same-idp' 14:02 CONTROL admin-logging='same-platform' 14:03 CONTROL recovery-access='same-idp' 14:04 OWNER admin-group='shared' 14:15 DEPENDENCY correlated='confirmed' 14:30 AUTOMATION broad-disable='allowed' 14:31 APPROVAL service-owner='missing' 14:45 LOGGING backup-change='not-covered' 15:00 RECOVERY restore-access='primary-idp' 15:01 RECOVERY independence='failed' 15:05 FAIL-CLOSED support-service='blocked' 15:10 EXCEPTION count='3-unowned' 15:15 DECISION architecture='paused' 15:18 STATUS redesign='required'
Training note: this is fake data for defensive analysis practice only.
Fictional Evidence Matrix
Evidence before Approving the Layered Design
DID-01
Fictional control inventory
Observation
Five controls depend on the same identity service and administrator group.
Supports
The design has correlated identity and ownership dependencies.
Does not prove
Does not prove the controls are ineffective during normal operation.
Design use
Add independent approval, evidence, fallback, and recovery paths.
DID-02
Fictional network diagram
Observation
Public, application, data, management, logging, and backup zones exist.
Supports
The design intends several trust and service boundaries.
Does not prove
Does not prove effective paths, identity checks, or denied communication.
Design use
Validate flows and combine network boundaries with identity, application, data, and monitoring controls.
DID-03
Fictional visibility map
Observation
Application and identity events are recorded, but changes to logging and backup controls are not.
Supports
A privileged administrator may alter systems and reduce evidence.
Does not prove
Does not prove this occurred.
Design use
Add independent administrative evidence and source-health alerts.
DID-04
Fictional automation record
Observation
One High alert can trigger broad account disabling without service-owner approval.
Supports
The response layer may scale a false positive into service disruption.
Does not prove
Does not prove the alert is wrong.
Design use
Use enrichment, approval gates, rate limits, targeted reversible action, and audit.
DID-05
Fictional recovery exercise
Observation
Restoration requires the same identity service and administrator group that failed.
Supports
Recovery is not independent from the primary failure domain.
Does not prove
Does not prove all backup data is unusable.
Design use
Redesign recovery authority, evidence, and validation with separate approved paths.
DID-06
Fictional service-health review
Observation
Fail-closed identity behavior protects administration but blocks a critical support function.
Supports
One failure state creates availability harm.
Does not prove
Does not prove fail-open behavior is safer.
Design use
Define a limited safe degraded mode for critical approved functions.
DID-07
Fictional exception register
Observation
Three temporary network and privilege exceptions have no expiration, owner review, or monitoring.
Supports
Exceptions may silently weaken several layers.
Does not prove
Does not prove the exceptions are unnecessary.
Design use
Assign owner, purpose, expiration, evidence, validation, and removal criteria.
DID-08
Fictional after-action review
Observation
A previous event identified the same shared dependencies, but no architecture change was completed.
Supports
The learning and governance layer is ineffective.
Does not prove
Does not prove every recommendation was feasible.
Design use
Assign corrective owners, deadlines, evidence, and independent closure validation.
Analyze the Evidence
Does the Fictional Design Have Real Defense in Depth?
Five controls depend on the same identity platform and administrator group.
One High alert can trigger broad account disabling without service-owner approval.
Application and identity events are logged, but logging and backup changes are not.
Restoration requires the same identity platform that failed.
Fail-closed identity behavior blocks a critical support function.
Three temporary exceptions have no owner, expiration, or monitoring.
A previous review identified the same dependencies without corrective closure.
Does the current fictional Northbridge design provide meaningful independent defense in depth?
Common Layering Mistakes
What Advanced Defenders Must Avoid
Counting several fictional tools as defense in depth when they rely on the same identity, platform, administrator, source, network, supplier, or recovery path.
Adding layers without connecting them to a mission outcome, asset, trust boundary, owner, failure, evidence source, and validation method.
Focusing only on prevention while neglecting visibility, response, recovery, communication, and improvement.
Assuming a firewall, identity provider, or logging platform automatically creates independent protection.
Using broad fail-closed behavior that protects one boundary but causes unnecessary total outage.
Using fail-open behavior without limiting privilege, data, service, time, action, evidence, or owner review.
Allowing the same fictional administrator to change systems, approvals, logs, backups, and recovery evidence.
Treating backups as recovery without testing authority, integrity, dependency order, identity restoration, service health, and logging.
Automating high-impact action without human approval, service context, rate limits, audit, and rollback.
Leaving temporary exceptions without owner, purpose, expiration, monitoring, validation, and removal.
Assuming more controls always improve security even when complexity makes operation and recovery unreliable.
Validating each control separately but never testing the complete fictional service outcome.
Failing to update the architecture after incidents, tests, supplier changes, or control drift.
Using real internal control maps, diagrams, configurations, logs, identities, suppliers, or failure reports in a portfolio artifact.
Safe Practice Lab
Build a Fictional Defense-in-Depth Strategy
Fictional assignment
Redesign the Northbridge Layer Stack
Use only the invented evidence on this page. Do not upload, copy, quote, lightly modify, summarize, or reproduce real internal controls, diagrams, configurations, credentials, logs, network details, supplier information, or failure reports.
Required deliverables
- Mission outcome, assets, dependencies, and trust boundaries.
- Control objectives across prevention, detection, response, recovery, governance, and learning.
- Eight-layer fictional control map.
- Control-to-dependency and owner matrix.
- Correlated-failure and blast-radius analysis.
- Fail-open, fail-closed, degraded, manual, and recovery decisions.
- Evidence coverage and source-health plan.
- Layer and end-to-end validation matrix.
- Residual-exposure, exception, change, and improvement register.
- Reflection, revision history, and complete fictionalization statement.
This activity creates a fictional educational design only. It does not authorize access, testing, configuration, change, recovery, or investigation involving any real system.
Scenario Decision Lab
The Identity Platform Becomes Unavailable
The fictional identity platform provides authentication, approval, administrator access, evidence attribution, and recovery access. It becomes unavailable during an important support period.
Scenario Decision Lab
A High Alert Triggers Broad Automation
One fictional High alert can disable many service accounts automatically. The affected services are critical, evidence is incomplete, and no service owner approves the action.
Advanced Challenge
Protect the Mission after a Shared Platform Failure
Extend the fictional Northbridge design for a scenario in which one platform provides identity, approval, administrative access, logging, and recovery. The platform becomes unreliable while the service must continue in a limited safe mode. Design independent safeguards that preserve critical outcomes, block risky actions, retain evidence, assign authority, support recovery, and validate the complete service state.
Required architecture
Show fictional control objectives, alternate dependencies, owners, safe defaults, degraded service, evidence, fallback, recovery order, and validation.
Required defense
Explain why each added layer is meaningfully different and which correlated failure or blast radius it reduces.
Defender Habits
Defense-in-Depth Design Checklist
Check Your Understanding
A2.2 Mini Quiz: Defense-in-Depth Design
Choose your answers first. Explanations appear only after submission.
1. What best describes defense in depth?
2. Five fictional controls depend on the same identity service and administrator group. What is the main concern?
3. Which design provides the strongest independent depth for a privileged fictional change?
4. A fictional logging platform fails. What is the strongest response?
5. Why can fail-closed behavior be risky?
6. What is strongest evidence that layered controls work?
7. What makes an A2.2 portfolio artifact safe to share?
Portfolio Prompt
Portfolio Prompt
Create a fully fictional Defense-in-Depth Design Package for Northbridge. Include the mission outcome, assets, dependencies, trust boundaries, control objectives, layered map, independence tests, dependency matrix, correlated-failure analysis, blast-radius review, fail-open and fail-closed decisions, safe degraded mode, owner map, evidence coverage, automation controls, recovery separation, validation plan, exception register, residual exposure, improvement actions, reflection, revision history, and a statement that every organization, system, identity, control, dependency, failure, evidence item, decision, date, and outcome is invented.
Count a fictional layer only when it adds meaningful independent value.
Show which platform, identity, owner, source, network, supplier, or clock each control depends on.
Include at least one correlated failure and redesign the architecture around it.
Validate the complete fictional service under normal, degraded, failed, and recovered states.
Keep every control, architecture element, evidence item, decision, and outcome fully invented and safe to share.
Confidence / Readiness Reflection
Are You Ready to Map Trust Boundaries and Security Zones?
Before moving to A2.3, rate your readiness from 1 to 5 for each area: control objectives, layer diversity, dependency mapping, correlated failure, blast radius, failure-state decisions, ownership, evidence, recovery, and end-to-end validation.
I can explain why several fictional tools may still represent one failure domain.
I can map fictional preventive, detective, response, recovery, governance, and learning layers.
I can identify fictional shared dependencies and correlated failures.
I can design fictional safe degraded operation without uncontrolled access or unnecessary total outage.
I can validate fictional controls individually and as a complete service outcome.
I can keep the entire defense-in-depth portfolio fully invented and safe to share.
Record one fictional control layer you can defend confidently, one shared dependency you would challenge before approval, and one boundary question you will carry into A2.3.
Key Takeaways
What You Should Remember
1.Defense in depth is coordinated layered protection, not a count of products or controls.
2.Fictional layers should reduce likelihood, reveal failure, limit impact, support recovery, and improve future design.
3.Several controls may still represent one failure when they share a platform, identity, administrator, source, network, supplier, clock, or recovery path.
4.Meaningful depth requires different mechanisms, dependencies, owners, evidence, failure states, trust boundaries, or recovery paths.
5.Fail-open and fail-closed decisions should protect both security and mission outcomes through approved safe degraded modes.
6.High-impact fictional automation requires evidence, human approval, service context, rate limits, audit, rollback, and targeted action.
7.Recovery is a control layer only when authority, evidence, integrity, dependencies, restoration, and validation are protected.
8.Layered controls should be validated individually and as an end-to-end fictional service under normal, degraded, failed, and recovered conditions.
9.Exceptions and lessons learned need owners, deadlines, evidence, architecture updates, and independent closure.
10.Every CyberShield defense-in-depth artifact must remain fully fictional, defensive, non-operational, privacy-safe, and incapable of exposing real systems.
Navigation