Trust boundaries
Places where data, identities, systems, or management authority cross between zones with different trust assumptions.
Review question: Ask what control validates the transition, what evidence is logged, and who owns the boundary.
High School AdvancedA18.2Advanced Defensive Labs
Lesson A18.2
Network Defense Architecture Review
Defensive architecture review asks whether trust, access, monitoring, resilience, ownership, and failure behavior make sense together. A network can look neatly segmented on a diagram while still hiding stale ownership, fragile dependencies, or incomplete evidence.
This lesson uses a fictional architecture package only. No live network discovery, probing, scanning, or modification is involved.
Lesson Progress
Network Defense Architecture Review
High School Advanced • A18: Advanced Defensive Labs • Lesson 2 of 10
20% complete
Readiness Check
A18.2 Entry Readiness
0/4 ready
Professional Hook
Architecture Review Is Really Dependency Review
A diagram may show six zones and dozens of arrows, but the hardest question is usually simpler: what depends on what? If identity fails, which services stop? If monitoring loses one collector, what evidence disappears? If an owner record is stale, which routing or access decisions become unreliable?
Strong reviewers look beyond clean visual boundaries and ask how the design behaves under change, failure, missing evidence, and operational pressure.
A good architecture review explains where trust changes, where dependencies concentrate, what evidence exists, and how the system fails safely.
Learning Objectives
Five Capabilities for This Lab
1
Review a fictional network architecture using trust boundaries, segmentation, identity, management paths, logging, monitoring, resilience, and ownership rather than focusing on isolated devices.
2
Distinguish architecture design evidence from assumptions, missing documentation, stale diagrams, and unresolved dependencies so findings remain traceable and defensible.
3
Evaluate whether control placement, monitoring coverage, fallback paths, and administrative access support least privilege, containment, observability, and operational continuity.
4
Prioritize architecture findings using business criticality, affected scope, likelihood of control failure, detectability, reversibility, dependency concentration, and remediation effort.
5
Build a Network Defense Architecture Review with findings, evidence references, risk statements, priorities, owners, compensating controls, validation needs, and a leadership summary.
Architecture Principles
Eight Ideas That Shape a Defensive Review
Segmentation
Logical or physical separation that reduces unnecessary communication and limits the scope of faults or incidents.
Review question: Ask whether segments reflect real business and administrative needs rather than arbitrary network shape.
Least privilege
Access paths should support the minimum approved communication and management need.
Review question: Ask whether broad pathways exist simply for convenience or because ownership is unclear.
Management-plane separation
Administrative access should be distinct from normal user and application traffic where appropriate.
Review question: Ask how privileged management is identified, approved, monitored, and separated conceptually.
Observability
The design should produce enough evidence to understand important transitions, failures, and administrative changes.
Review question: Ask what is logged, where evidence goes, how complete it is, and whether health is monitored.
Resilience
Important services should not depend on one fragile control, path, or logging component when continuity matters.
Review question: Ask what happens if a dependency is unavailable and whether safe degraded operation exists.
Ownership
Every important service, segment, control, logging source, and administrative path needs a current owner.
Review question: Ask who maintains the design, approves change, and responds when health degrades.
Change governance
Architecture evidence should remain aligned with real approved design decisions over time.
Review question: Ask whether diagrams, inventories, review dates, and exceptions are current.
Fictional Zone Model
Six Zones in the Northbridge Architecture
User Access Zone
Purpose: Represents standard employee endpoints and approved user-facing access paths.
Expected controls: Identity-aware access, endpoint health concepts, monitored transitions, limited direct administrative reach.
Review concern: Should not become an unrestricted bridge into management or sensitive service zones.
Application Zone
Purpose: Contains fictional business application services that support normal workflows.
Expected controls: Defined service-to-service paths, logging, ownership, health monitoring, limited management access.
Review concern: Application dependencies should be documented so broad exceptions are not used as substitutes for architecture.
Data Services Zone
Purpose: Represents fictional storage and database services used by approved applications.
Expected controls: Narrow service access, identity validation, logging, backup, ownership, and recovery planning.
Review concern: Direct user access should be justified rather than assumed.
Management Zone
Purpose: Represents administrative systems, privileged management paths, and approved operational tooling.
Expected controls: Separate privileged identities, strong review, monitored administration, narrow scope, change evidence.
Review concern: Management should not share broad trust with normal user traffic.
Security Monitoring Zone
Purpose: Collects fictional logs, alert context, health, and review evidence.
Expected controls: Independent evidence paths, source attribution, health monitoring, retention, controlled access.
Review concern: Monitoring should not depend entirely on the same failure domain it is meant to observe.
External Services Boundary
Purpose: Represents approved connections to fictional third-party or externally managed services.
Expected controls: Documented purpose, ownership, identity, logging, availability expectations, and fallback.
Review concern: External dependency assumptions should be explicit and reviewed.
Architecture Case File
Northbridge Synthetic Architecture Evidence
ARC-1801User Access ZoneExpected
Evidence
Standard users reach APP-NB-10 through an approved application gateway path.
Concern
No direct management path is documented.
Interpretation
Supports separation between user access and administration.
ARC-1802Management ZoneExpected
Evidence
Administrative workflows use a separate fictional privileged access service.
Concern
The diagram does not show the backup administrative path.
Interpretation
Separation is strong, but resilience evidence is incomplete.
ARC-1803Security Monitoring ZoneExpected
Evidence
Application and identity logs are forwarded to MON-NB-4.
Concern
Network device health logs depend on the same collector as application logs.
Interpretation
Shared collector concentration may create an observability failure domain.
ARC-1804Application ZoneExpected
Evidence
APP-NB-10 communicates with DATA-NB-3 using a defined service path.
Concern
The architecture review package does not include the latest dependency owner.
Interpretation
Communication appears bounded, but ownership evidence needs refresh.
ARC-1805Data Services ZoneExpected
Evidence
DATA-NB-3 is reachable only from the approved application service and management zone in the fictional design.
Concern
A temporary exception is listed but its expiration field is blank.
Interpretation
Exception governance is incomplete and could create long-term drift.
ARC-1806External Services BoundaryExpected
Evidence
APP-NB-10 depends on EXT-NB-2 for a noncritical reference lookup.
Concern
Fallback behavior is not shown.
Interpretation
An optional dependency could become an unnecessary single point of failure.
ARC-1807Identity DependencyNeeds Review
Evidence
User and management access both depend on ID-NB-1 for fictional authentication decisions.
Concern
The architecture package does not show degraded-mode or recovery assumptions.
Interpretation
Central identity is expected, but resilience planning must be explicit.
ARC-1808Logging PathNeeds Review
Evidence
MON-NB-4 receives both operational and security-relevant telemetry.
Concern
The collector and dashboard service share the same fictional hosting dependency.
Interpretation
A shared dependency could reduce both collection and visibility at once.
ARC-1809Architecture DocumentationStale
Evidence
Diagram version 4.1 was last approved nine months ago.
Concern
Two current service owners differ from the diagram labels.
Interpretation
The model may no longer represent current approved ownership.
ARC-1810Change GovernanceNeeds Review
Evidence
Three architecture changes were approved after diagram version 4.1.
Concern
The changes are documented individually but not reflected in the consolidated diagram.
Interpretation
Change records exist, but architecture evidence is fragmented.
Dependency Thinking
Six Different Dependencies Can Shape One Architecture
Functional dependency
A service depends on another component to deliver business functionality.
Example: APP-NB-10 uses DATA-NB-3 for application data.
Identity dependency
Access depends on a shared identity or authorization service.
Example: User and management access depend on ID-NB-1.
Monitoring dependency
A control depends on a logging, telemetry, or dashboard service for visibility.
Example: Several sources forward evidence to MON-NB-4.
Administrative dependency
Operational management depends on a privileged access or change-control path.
Example: Management workflows use a separate administrative service.
External dependency
A service relies on a third party or externally managed component.
Example: APP-NB-10 uses EXT-NB-2 for a noncritical reference lookup.
Governance dependency
Safe operation depends on current ownership, approval, review, or exception records.
Example: A data-zone exception lacks an expiration date.
Fake Dashboard
Northbridge Network Defense Architecture Dashboard
Fictional architecture evidence, findings, priorities, and safety posture
Architecture records
10
Zones, identity, logging, dependencies, documentation, and governance evidence
Priority findings
6
Monitoring, identity resilience, stale documentation, exception, external fallback, and management recovery
P1 findings
4
Highest current remediation attention
Real network tests
0
All review work remains fictional and architecture-focused
Fake SOC Alert
Monitoring Dependency Concentration Requires Review
Source: Fictional Architecture Review Queue • Time: 10:16
Several security-relevant telemetry sources depend on one collector, while the collector and its dashboard share the same fictional hosting dependency. No current outage is shown, but the evidence suggests a concentrated observability failure domain.
Defensive recommendation: Document independent health visibility, resilient evidence handling, and a safe recovery path without assuming the current architecture is already failing.
Fake Log Panel
Northbridge Fictional Architecture Review Log
training-log-viewer.log
[08:10] ARC-1801 zone=USER_ACCESS state=EXPECTED direct_management_path=NONE_DOCUMENTED [08:28] ARC-1802 zone=MANAGEMENT separation=STRONG backup_path=NOT_DOCUMENTED [08:46] ARC-1803 zone=MONITORING shared_collector=YES concentration=REVIEW [09:04] ARC-1805 zone=DATA_SERVICES exception_expiration=MISSING action=GOVERNANCE_REVIEW [09:22] ARC-1807 dependency=IDENTITY recovery_assumption=NOT_DOCUMENTED [09:40] ARC-1808 logging_hosting_dependency=SHARED state=REVIEW [09:58] ARC-1809 diagram_version=4.1 age=9_MONTHS owner_labels=STALE [10:16] ARC-1810 approved_changes=3 reflected_in_diagram=NO
Training note: this is fake data for defensive analysis practice only.
Architecture Findings
Six Evidence-Backed Findings
FND-1801P1
Monitoring concentration creates an observability dependency
Evidence
ARC-1803, ARC-1808
Risk
A shared collector or hosting failure could reduce collection and visibility at the same time.
Impact
High
Likelihood
Moderate
Recommendation
Document independent health signals and a resilient evidence path for critical monitoring sources.
Owner
Security Monitoring Owner
Validation
Review synthetic failure scenario and confirm evidence remains available during collector degradation.
FND-1802P1
Identity resilience assumptions are not documented
Evidence
ARC-1807
Risk
A central identity dependency could interrupt both standard and administrative access if recovery or degraded-mode assumptions are unclear.
Impact
High
Likelihood
Low to Moderate
Recommendation
Document approved resilience, recovery ownership, and emergency administrative decision paths conceptually.
Owner
Identity Platform Owner
Validation
Tabletop the fictional identity dependency failure and record decision authority.
FND-1803P1
Architecture diagram is stale
Evidence
ARC-1809, ARC-1810
Risk
Reviewers may make decisions from ownership and dependency information that no longer represents the approved current state.
Impact
Moderate
Likelihood
High
Recommendation
Reconcile approved change records into a current architecture version with owner signoff.
Owner
Security Architecture Owner
Validation
Compare all approved post-4.1 changes with the refreshed diagram.
FND-1804P1
Data-zone exception has no expiration
Evidence
ARC-1805
Risk
A temporary architectural deviation may become permanent without deliberate review.
Impact
Moderate
Likelihood
Moderate
Recommendation
Assign scope, owner, compensating control, expiration, and closure evidence.
Owner
Risk / Governance Owner
Validation
Confirm the exception is either closed, renewed, or redesigned with current approval.
FND-1805P2
Optional external dependency lacks documented fallback
Evidence
ARC-1806
Risk
A noncritical external lookup could unnecessarily interrupt the application workflow.
Impact
Moderate
Likelihood
Moderate
Recommendation
Define visible degraded behavior so the core fictional workflow can continue without the optional reference.
Owner
Application Service Owner
Validation
Use a synthetic tabletop where EXT-NB-2 is unavailable and confirm safe degraded behavior.
FND-1806P2
Management separation is strong but backup-path evidence is missing
Evidence
ARC-1802
Risk
A primary management dependency could become an operational bottleneck if the approved fallback is unknown.
Impact
Moderate
Likelihood
Low
Recommendation
Document the approved recovery path and decision authority without broadening normal access.
Owner
Platform Operations Owner
Validation
Review the fictional recovery plan and ensure the fallback preserves least privilege.
Analyze the Evidence
Evidence Analysis: Monitoring Concentration
Application and identity telemetry depend on MON-NB-4.
Network-device health evidence also depends on MON-NB-4.
The collector and dashboard share one fictional hosting dependency.
No current outage is shown.
The review package does not show an independent monitoring-health path.
What is the strongest architecture finding supported by ARC-1803 and ARC-1808?
Finding Quality
Turn Vague Statements Into Defensible Architecture Findings
Weak
The network is insecure.
Stronger
Monitoring evidence from several critical sources depends on one collector and one shared hosting dependency, creating an observability concentration risk.
Why stronger: The strong version names the condition, affected function, and risk without exaggeration.
Weak
Identity is a single point of failure.
Stronger
User and management access depend on one identity service, while the review package does not document degraded-mode or recovery assumptions.
Why stronger: The strong version separates the observed dependency from the unproven outcome.
Weak
The diagram is wrong.
Stronger
Diagram version 4.1 is nine months old and does not reflect three approved changes or two current owner mappings.
Why stronger: The strong version points to specific stale evidence.
Weak
The external service is dangerous.
Stronger
The external reference lookup is noncritical, but fallback behavior is undocumented, so an optional dependency may have disproportionate availability impact.
Why stronger: The strong version focuses on resilience rather than dramatic language.
Prioritization
How to Decide Which Architecture Finding Matters First
Business criticality
How important is the affected service or control to normal defensive or business operations?
Blast radius
How many fictional systems, workflows, or users could be affected if the design fails?
Control dependency
Does one architecture element protect or observe many others?
Detectability
Would failure be immediately visible or could the design fail silently?
Reversibility
Can the problem be corrected safely without broad disruption?
Evidence confidence
Is the finding supported by current architecture evidence or mainly by stale or missing documentation?
Existing safeguards
Are compensating controls already reducing the practical risk?
Remediation dependency
Does the fix require several owners, a major redesign, or a simple documentation correction?
Review Artifact
What a Professional Architecture Review Contains
Finding ID
Stable reference for each architecture finding.
Example: FND-1801
Architecture scope
Names the zone, service, dependency, or trust boundary being reviewed.
Example: Security Monitoring Zone
Evidence references
Links the finding to specific fictional architecture records.
Example: ARC-1803, ARC-1808
Observed condition
States what the evidence actually shows.
Example: Multiple critical sources share one collector and hosting dependency
Risk statement
Explains what could happen and why it matters.
Example: Collector failure could reduce both telemetry collection and visibility
Impact
Rates the consequence if the condition produces a failure.
Example: High
Likelihood
Estimates how plausible the failure is within the fictional context.
Example: Moderate
Priority
Orders the finding for remediation and leadership attention.
Example: P1
Recommendation
Defines the defensive improvement without overprescribing implementation.
Example: Add resilient monitoring health and evidence path
Owner
Names the accountable fictional role.
Example: Security Monitoring Owner
Compensating control
Records an existing or temporary safeguard while the finding remains open.
Example: Manual health verification during collector degradation
Validation
Defines how reviewers will know the issue is actually resolved.
Example: Synthetic failure tabletop with evidence continuity confirmed
Scenario Decision Lab
Scenario Decision Lab 1 — Shared Monitoring Collector
A fictional architecture uses one collector for several important telemetry sources. The collector and dashboard also share one hosting dependency, but no outage has occurred.
Scenario Decision Lab
Scenario Decision Lab 2 — Management Resilience
The fictional architecture has strong management-plane separation, but the review package does not document what happens if the primary privileged-access path is unavailable.
Safe Fictional Lab
Build a Network Defense Architecture Review
Review a fictional network design as a set of trust relationships, operational dependencies, evidence paths, ownership decisions, and failure domains rather than as a collection of devices.
1
Create at least thirty-five fictional ARC records across user, application, data, management, monitoring, identity, and external-service areas.
2
Give every architecture record a stable ARC ID.
3
Document the purpose of each zone or service.
4
Document the owner of each important architecture element.
5
Document trust-boundary transitions.
6
Document management paths.
7
Document identity dependencies.
8
Document logging dependencies.
9
Document monitoring dependencies.
10
Document business-service dependencies.
11
Document optional external dependencies.
12
Record whether each dependency is essential or optional.
13
Record resilience or degraded-mode assumptions.
14
Record current architecture version.
15
Record last review date.
16
Record approved changes not yet reflected in diagrams.
17
Record temporary exceptions.
18
Record exception owners and expiration.
19
Create at least twelve findings.
20
Give each finding a stable FND ID.
21
Link every finding to ARC evidence.
22
Write an observed-condition statement.
23
Write a bounded risk statement.
24
Assign impact.
25
Assign likelihood.
26
Assign priority.
27
Identify compensating controls.
28
Assign a fictional remediation owner.
29
Define a validation method.
30
Identify at least three observability concentration risks.
31
Identify at least three identity or management dependency risks.
32
Identify at least three stale-documentation or ownership issues.
33
Identify at least three resilience or fallback gaps.
34
Write a one-page leadership summary.
35
Keep every review step conceptual, fictional, and non-disruptive.
Lab boundary
Use only fictional diagrams, ownership records, service dependencies, architecture versions, monitoring paths, and exception records. Do not scan, probe, enumerate, exploit, or change any real network. The lab is a conceptual defensive review.
Analyze the Evidence
Evidence Analysis: Stale Architecture Documentation
Diagram version 4.1 is nine months old.
Three approved architecture changes occurred after version 4.1.
The change records are individually documented.
Two owner labels in the diagram differ from current records.
The consolidated architecture view has not been refreshed.
What is the strongest response when a nine-month-old diagram does not reflect three approved changes?
Advanced Challenge
Create a Resilience and Observability Review
Take the fictional Northbridge architecture and write a short review focused only on failure domains and evidence continuity. Identify where one dependency could reduce both service availability and the team's ability to observe what happened.
1
Critical service dependency
2
Identity dependency
3
Monitoring dependency
4
Management dependency
5
External dependency
6
Governance dependency
7
Potential failure domain
8
Detectability concern
9
Existing safeguard
10
Safe degraded behavior
11
Recovery owner
12
Validation evidence
13
Highest-priority resilience gap
14
Leadership recommendation
Keep the challenge conceptual. You are reviewing architecture resilience, not testing a real system.
Defender Habits
A18.2 Defender Checklist
Skill Check
Seven Questions
Check Your Understanding
A18.2 Mini Quiz: Network Defense Architecture Review
Choose your answers first. Explanations appear only after submission.
1. What is a trust boundary?
2. Why is management-plane separation useful?
3. What is the strongest conclusion when one monitoring collector supports many critical sources?
4. What should happen when an architecture diagram is stale but approved change records exist?
5. What is strongest for a temporary architecture exception?
6. How should architecture findings be prioritized?
7. What is the purpose of the Network Defense Architecture Review artifact?
Portfolio Prompt
Portfolio Build — Network Defense Architecture Review
Create the second artifact for your A18 Advanced Defensive Casebook: a fictional Network Defense Architecture Review. Include architecture scope, zone purpose, trust boundaries, identity dependencies, management paths, logging and monitoring dependencies, resilience assumptions, architecture version, ownership, exceptions, at least twelve findings, evidence references, impact, likelihood, priority, compensating controls, remediation owner, validation method, and a one-page leadership summary.
Review relationships and dependencies, not just individual components.
Separate observed architecture evidence from assumptions.
Treat stale diagrams and ownership as real governance issues.
Do not call a dependency a failure unless evidence shows it failed.
Write bounded recommendations that preserve least privilege and resilience.
Keep every record fictional and non-disruptive.
Confidence / Readiness Reflection
Are You Ready for A18.3?
A18.3 moves into a fictional cloud security review. Before continuing, make sure you can explain how trust boundaries, identity, monitoring, resilience, ownership, and documentation quality shape the strength of a network architecture.
1
I can identify trust boundaries and explain why they matter.
2
I can distinguish segmentation from simple diagram separation.
3
I can identify dependency concentration without claiming a failure has already occurred.
4
I can write evidence-backed architecture findings and priorities.
5
I can recommend conceptual improvements without probing or modifying a real network.
Portfolio Build Guide
How to Make the Architecture Review Look Professional
Show the architecture scope
Define which zones, services, identity systems, monitoring paths, and dependencies the review covers.
Use evidence IDs
Every finding should trace back to specific architecture evidence.
Write bounded risk statements
Describe what could happen without claiming that the failure has already occurred.
Prioritize by consequence
Use business criticality, blast radius, detectability, and dependency concentration.
Separate design from governance
A technically strong design can still have stale ownership, expired exceptions, or outdated documentation.
Show validation
A recommendation is incomplete until you define how reviewers will know the issue is resolved.
Keep resilience compatible with least privilege
Fallback should not require collapsing trust boundaries or broadening access unnecessarily.
Connect forward
A18.3 applies the same architecture-review discipline to a fictional cloud environment.
Key Takeaways
What You Should Remember
1.Network architecture review is about relationships, boundaries, dependencies, resilience, and ownership—not just device inventory.
2.Trust boundaries need clear control, evidence, and accountability.
3.Management-plane separation supports least privilege and clearer administrative oversight.
4.Centralized services can still create concentration risks that deserve resilience planning.
5.Monitoring should remain observable even when part of the monitored environment is degraded.
6.Stale diagrams and ownership records are architecture risks because decisions depend on current models.
7.Temporary exceptions need governance, expiration, compensating controls, and closure evidence.
8.Optional dependencies should not become unnecessary single points of failure.
9.Strong findings describe observed conditions and bounded consequences without exaggerating certainty.
10.The Network Defense Architecture Review becomes the second artifact in the A18 Advanced Defensive Casebook.
Lesson Safety Boundary
A18.2 stays fictional, conceptual, defensive, and non-disruptive
Do not scan, probe, enumerate, fuzz, exploit, access, or modify real networks. Do not use real credentials, private records, or live security platforms. This lesson is about architecture reasoning, evidence, resilience, ownership, monitoring, governance, and defensible recommendations.
Lesson Complete
A18.2 Network Defense Architecture Review Complete
You now have a defensible approach to trust boundaries, segmentation, management paths, identity dependencies, monitoring concentration, resilience, architecture freshness, exceptions, and prioritization. Next, A18.3 applies those skills to a fictional cloud security review case.