Z — Zero in on mission
Define fictional users, critical services, data, identity, evidence, support, supplier, and recovery outcomes.
High School AdvancedModule A4Lesson 1 of 10Mission-Driven Network Design
A4.1 Defensive Network Architecture
Learn how professional defenders design fictional networks around mission, identity, services, data, zones, trust relationships, administrative separation, supplier dependencies, visibility, safe failure, recovery, evidence, ownership, and lifecycle—not merely around devices or one perimeter.
Lesson Progress
Defensive Network Architecture
High School Advanced • A4: Advanced Networking Defense • Lesson 1 of 10
10% complete
Readiness Check
Before You Start
0/6 ready
Professional Hook
A Clean Diagram Can Still Hide a Dangerous Architecture
A fictional Northbridge diagram shows a public portal, application services, data services, a supplier connection, monitoring, and a recovery network. Everything is separated into neat boxes. During review, the team learns that the same identity and DNS services support every zone, administrators and supplier support share one gateway, two temporary paths lack owners, internal visibility is incomplete, and recovery can reach sensitive services through poorly documented emergency permissions.
Weak architecture statement
“The internal network is trusted, the supplier is behind a firewall, and a backup link provides resilience.”
Strong architecture statement
“Each fictional path requires a documented purpose, identity, destination, service, state, control point, evidence source, owner, failure mode, recovery decision, exception, and review trigger.”
Architecture quality is not measured by how many boxes appear. It is measured by whether the design explains and limits trust, supports mission needs, produces trustworthy evidence, fails safely, and recovers correctly.
Exactly Five Learning Objectives
What You Will Be Able to Do
Objective 1
Explain defensive network architecture as a mission-driven design discipline connecting users, services, identities, data, zones, dependencies, visibility, safe failure, recovery, evidence, and ownership.
Objective 2
Model fictional network zones, communication paths, administrative relationships, supplier boundaries, wireless classes, remote-access paths, monitoring locations, and recovery connections without using real infrastructure details.
Objective 3
Evaluate fictional north-south, east-west, administrative, supplier, wireless, DNS, management, monitoring, and recovery traffic based on documented purpose, identity, service need, trust, evidence, and lifecycle.
Objective 4
Identify fictional architectural weaknesses such as flat trust, hidden dependencies, shared control points, weak administrative separation, blind spots, unsafe fallback, stale exceptions, and recovery paths that bypass normal controls.
Objective 5
Create a portfolio-ready fictional defensive network architecture brief with zones, critical services, path requirements, control objectives, evidence needs, owners, assumptions, residual risks, and review triggers.
Why This Matters
Architecture Determines What Can Reach, Trust, Observe, Fail, and Recover
Network architecture shapes the blast radius of error, misuse, control failure, supplier delay, stale identity, DNS problems, management mistakes, wireless access, monitoring gaps, and recovery actions. A strong fictional architecture does not assume an “inside” is safe. It assigns purpose and control to every important relationship.
Mission protection
Network paths should support only approved fictional user, service, data, administrative, supplier, evidence, and recovery outcomes.
Trust reduction
Zones and control points reduce unnecessary reachability and make identity, validation, evidence, and ownership explicit.
Resilient operation
Failure and recovery design preserve safe degraded service, evidence, communication, reconciliation, and closure.
Core Framework
The Z-O-N-E-D Method
O — Organize zones and owners
Group fictional services by purpose, trust, sensitivity, administration, visibility, recovery, and accountable ownership.
N — Name every necessary path
Document source, destination, identity, service, purpose, data, state, evidence, owner, exception, and expiration.
E — Establish controls and evidence
Choose fictional identity, authorization, validation, segmentation, policy, visibility, source-health, and review points.
D — Design for disruption
Plan fictional safe failure, degraded modes, alternate evidence, dependency validation, recovery order, reconciliation, and closure.
D — Document lifecycle decisions
Maintain versions, assumptions, findings, owners, exceptions, residual risk, review dates, and change triggers.
Decision-ready architecture statement
This fictional architecture supports a defined mission through owned zones and narrowly justified communication paths. Each important path has identity, authorization, validation, evidence, failure, recovery, exception, and review requirements. Shared dependencies and residual risks remain visible.
Advanced Vocabulary
Terms for Defensive Network Architecture
Defensive network architecture
A fictional mission-driven design showing how users, devices, services, identities, data, zones, dependencies, controls, evidence, administration, and recovery interact safely.
Network zone
A fictional grouping of systems, services, users, or devices with similar mission purpose, trust requirements, data sensitivity, administrative ownership, or control expectations.
Security boundary
A fictional point where trust, identity, authority, data handling, ownership, visibility, policy, or responsibility changes.
North-south traffic
Fictional communication entering or leaving a defined environment, such as user-to-portal or internal-service-to-supplier traffic.
East-west traffic
Fictional communication between internal zones, services, workloads, or dependencies.
Administrative path
A fictional communication path used for privileged management, support, configuration, maintenance, monitoring, emergency access, or recovery.
Control point
A fictional location where identity, authorization, segmentation, validation, inspection, logging, rate handling, approval, or recovery requirements are enforced.
Choke point
A fictional place where many important paths depend on one component or control, creating both strong governance opportunities and concentrated failure risk.
Shared dependency
A fictional service such as identity, DNS, time, networking, monitoring, management, supplier connectivity, or recovery that supports several zones or mission functions.
Management plane
The fictional services, identities, interfaces, and evidence used to administer network and infrastructure components.
Data plane
The fictional paths that carry normal user, application, service, file, message, and business communication.
Control plane
The fictional decisions and protocols that determine how communication is routed, permitted, denied, prioritized, or changed.
Out-of-band management
A fictional separately governed management path intended to remain available when normal operational paths are degraded.
Blast radius
The fictional scope of assets, services, users, identities, data, or recovery functions that could be affected by one unsafe condition or control failure.
Least connectivity
A fictional design principle allowing only the communication required for an approved mission purpose under defined identity, service, destination, time, state, and ownership conditions.
Service dependency
A fictional identity, naming, queue, data, management, supplier, monitoring, storage, notification, or recovery capability needed for another service to operate.
Failure domain
A fictional grouping of components that may fail together because they share power, management, routing, identity, DNS, supplier, policy, capacity, or administrative ownership.
Trust relationship
A fictional decision describing why one actor, zone, service, or dependency is allowed to rely on another and what evidence or controls justify that reliance.
Reachability
Whether a fictional source can communicate with a destination under defined conditions; reachability alone does not prove authorization or safe business action.
Policy enforcement point
A fictional place where approved network, identity, application, device, data, or administrative policy is evaluated.
Visibility point
A fictional source of network evidence such as connection metadata, control results, source health, flow records, service events, DNS events, or approved inspection.
Architectural invariant
A fictional design statement that must remain true, such as administrative access never sharing the same trust path as guest access.
Safe failure
A fictional condition where control or dependency failure limits exposure, preserves evidence, communicates degradation, and supports controlled recovery.
Architecture review trigger
A fictional event that requires the design to be reconsidered, such as a new supplier, zone, identity source, remote-access path, wireless class, DNS dependency, recovery method, or mission change.
Instructional Section 1
Apply Ten Architecture Principles
Begin with mission, not devices
A fictional architecture should first explain which users, services, data, identities, evidence, support, suppliers, and recovery outcomes matter.
Strong practice
Define the student-support mission, critical workflows, owners, and recovery needs before choosing zones or control points.
If ignored
A diagram may contain many devices without showing which communication or controls actually protect the mission.
Make trust explicit
Every fictional relationship should state what one zone or service trusts another to do, which identity acts, and which evidence supports that decision.
Strong practice
The workflow service accepts supplier results only after source identity, schema, correlation, freshness, state compatibility, and evidence checks.
If ignored
A line between boxes can hide assumptions about identity, authorization, validation, and responsibility.
Separate user, service, and administrative paths
Fictional normal use, service communication, privileged management, monitoring, support, emergency access, and recovery should have distinct purposes and controls.
Strong practice
Administrative access uses a separately governed path with stronger identity, approval, destination, evidence, and lifecycle requirements.
If ignored
One shared path can expand blast radius and make normal traffic indistinguishable from privileged action.
Design least connectivity
Allow only fictional communication required by a documented mission purpose, source, destination, identity, service, data need, state, owner, and review.
Strong practice
A notification service receives only approved message requests from the workflow service and does not require broad data-zone access.
If ignored
Broad reachability can outlive its purpose and become difficult to review safely.
Model shared dependencies
Identity, DNS, time, routing, management, monitoring, supplier, storage, and recovery services may support many fictional zones.
Strong practice
Show which critical services rely on the same identity and naming systems and how those dependencies fail or recover.
If ignored
Apparently separated services may still share one failure domain.
Place visibility with purpose
Fictional evidence collection should answer defined defender questions while preserving privacy, source health, retention, and access limits.
Strong practice
Collect connection, policy, source-health, and service-correlation evidence where trust changes occur.
If ignored
More visibility can create noise, privacy exposure, cost, and false confidence without improving decisions.
Assume controls can fail
Fictional policy enforcement, identity, DNS, routing, monitoring, remote access, wireless, supplier, and recovery controls may be unavailable or unhealthy.
Strong practice
Define safe defaults, degraded modes, alternate evidence, owner escalation, and recovery gates.
If ignored
A strong control can become a concentrated single point of failure.
Design for recovery correctness
Restoring fictional connectivity is not enough if identity, DNS, routing, business state, monitoring, notifications, and administrative access remain incorrect.
Strong practice
Use recovery order, dependency validation, reconciliation, communication, and closure evidence.
If ignored
Technical availability can return while the service remains unsafe or misleading.
Assign ownership and lifecycle
Every fictional zone, path, control, dependency, visibility source, exception, and recovery relationship needs an accountable owner and review trigger.
Strong practice
Temporary supplier connectivity expires unless the fictional owner revalidates purpose, scope, evidence, and residual risk.
If ignored
Unowned paths and exceptions can become permanent architecture.
Keep the public artifact fictional
A learning architecture must demonstrate reasoning without exposing real addresses, routes, rules, devices, suppliers, logs, credentials, or internal diagrams.
Strong practice
Invent every zone, path, identity, policy, record, date, owner, finding, and outcome.
If ignored
Removing a company name does not make real internal network detail safe to publish.
Instructional Section 2
Define Eight Fictional Architecture Zones
Zones should represent meaningful differences in mission, trust, identity, data, administration, visibility, and recovery. They should not be treated as automatically trusted simply because they are internal.
Public access zone
Purpose
Hosts the fictional student-facing portal and only the functions required to receive approved user requests.
Typical fictional actors
Student portal users and approved public-facing service identities.
Allowed relationships
User-to-portal communication and narrowly defined portal-to-application communication.
Control objectives
Strong identity transition, input validation, session protection, object authorization, rate handling, minimal service reachability, and evidence.
Evidence
Authentication result, session context, request validation, policy decision, destination, result, source health, and user confirmation.
Failure questions
What happens when identity, application, DNS, rate handling, or monitoring is unavailable?
Application services zone
Purpose
Runs fictional workflow, case, and service logic that coordinates business processes.
Typical fictional actors
Portal service, workflow service, approved service identities, and controlled support workflows.
Allowed relationships
Approved communication with public access, data, supplier integration, notification, evidence, and recovery services.
Control objectives
Service identity, least connectivity, object and state validation, dependency separation, change control, and resilient evidence.
Evidence
Service identity, request purpose, object, state, destination, control result, correlation, change version, and health.
Failure questions
Could degraded service bypass validation, create stale state, or hide dependency failure?
Sensitive data zone
Purpose
Stores fictional case, account, preference, retention, and workflow state requiring stronger confidentiality and integrity controls.
Typical fictional actors
Approved data services, workflow service identities, recovery identities, and limited administrative roles.
Allowed relationships
Narrow application-to-data and recovery-to-data relationships with explicit identity and purpose.
Control objectives
Strong identity, object authorization, purpose limitation, encryption, integrity, auditability, retention, backup, and recovery validation.
Evidence
Actor, service identity, data object, operation, purpose, result, approval, source health, retention, and recovery state.
Failure questions
How is access limited during support, maintenance, degraded operation, and recovery?
Supplier integration zone
Purpose
Separates fictional external processing communication from core internal services.
Typical fictional actors
Supplier service identities, integration services, queue services, and supplier owners.
Allowed relationships
Approved minimized requests to the supplier and validated results returning through controlled interfaces.
Control objectives
Identity, destination restriction, schema validation, data minimization, correlation, freshness, duplicate handling, evidence, and safe failure.
Evidence
Service identity, supplier destination, request fields, result fields, correlation, queue age, source health, validation, and owner review.
Failure questions
What if the supplier is delayed, unavailable, returns stale data, changes fields, or loses evidence continuity?
Administrative management zone
Purpose
Provides fictional privileged management, configuration, maintenance, and support capabilities through separately governed paths.
Typical fictional actors
Authorized administrators, support supervisors, service-management identities, and emergency-access roles.
Allowed relationships
Purpose-bound, time-bound, destination-bound administrative access to approved management interfaces.
Control objectives
Strong identity, device context, approval, least privilege, session evidence, separation of duties, change tracking, and revocation.
Evidence
Actor, device, role, approval, destination, action, old state, new state, result, session, and review.
Failure questions
How are emergency access, remote administration, failed identity, and recovery authority controlled?
Monitoring and evidence zone
Purpose
Collects fictional minimized evidence about network, identity, service, policy, DNS, queue, wireless, control, and recovery behavior.
Typical fictional actors
Evidence collection services, analysts, source-health monitors, and review owners.
Allowed relationships
Approved event delivery from defined sources and controlled analyst access to necessary evidence.
Control objectives
Purpose limitation, source health, event meaning, correlation, privacy, access, retention, availability, integrity, and alternate evidence.
Evidence
Source, event schema, health, timestamp, transformation, collector status, access, retention, alert, analyst action, and closure.
Failure questions
How are blind periods, unhealthy sources, noisy alerts, and over-collection identified and handled?
Wireless access zone
Purpose
Separates fictional managed devices, employee access, guest access, service devices, and administrative wireless needs.
Typical fictional actors
Managed endpoints, approved users, guest users, service devices, support roles, and wireless-management identities.
Allowed relationships
Identity- and device-aware communication to approved services; guest access remains separated from internal service paths.
Control objectives
Onboarding, identity, device context, network class separation, management security, monitoring, support, lifecycle, and safe alternatives.
Evidence
User identity, device identity, network class, authorization result, session, destination class, policy outcome, source health, and revocation.
Failure questions
What happens when identity, device posture, wireless management, or onboarding services are unavailable?
Recovery and continuity zone
Purpose
Supports fictional backup, restore, emergency coordination, alternate access, validation, reconciliation, and closure.
Typical fictional actors
Recovery coordinators, recovery service identities, approved administrators, evidence owners, and continuity owners.
Allowed relationships
Separately approved recovery communication with identity, DNS, application, data, notification, archive, and monitoring services.
Control objectives
Trusted recovery identity, artifact integrity, order, dependency validation, emergency-access governance, evidence continuity, reconciliation, and revocation.
Evidence
Recovery trigger, approver, actor, source artifact, destination, action, result, validation, communication, reconciliation, and closure.
Failure questions
Could recovery restore connectivity while leaving identity, DNS, business state, monitoring, or communication incorrect?
Instructional Section 3
Review Eight Important Path Types
User access path
Fictional example
Fictional student device → public portal → application service.
Required context
User identity, session, device or client context, request purpose, object ownership, validation, destination, result, and evidence.
Control point
Public access boundary and application authorization layer.
Failure
Identity outage, stale session, invalid input, duplicate request, or misleading response.
Recovery
Safe retry, preserved user intent, clear status, correction, and evidence.
Application-to-data path
Fictional example
Fictional workflow service → sensitive data service.
Required context
Service identity, approved operation, data object, business state, purpose, authorization, result, and audit evidence.
Control point
Application policy and data authorization boundary.
Failure
Broad service authority, wrong object, stale state, unavailable data, or incomplete evidence.
Recovery
Restore correct service identity, data state, authorization, reconciliation, and monitoring.
Supplier request path
Fictional example
Fictional application service → supplier integration → processing supplier.
Required context
Service identity, supplier destination, approved fields, purpose, schema, correlation, retention, and owner.
Control point
Supplier administrative boundary.
Failure
Excessive data, wrong destination, schema drift, supplier delay, or unclear ownership.
Recovery
Pause unsafe processing, correct request, validate supplier state, and reconcile.
Supplier result path
Fictional example
Fictional supplier → result queue → workflow service.
Required context
Source identity, correlation, freshness, ordering, duplicate handling, state version, validation, and source health.
Control point
Result validation and workflow-state boundary.
Failure
Stale, delayed, duplicated, misordered, malformed, or incorrectly trusted result.
Recovery
Controlled review, state reconciliation, corrected notification, and closure evidence.
Administrative path
Fictional example
Fictional administrator → remote-access service → management zone → approved target.
Required context
Strong identity, managed device, role, purpose, destination, time, approval, session evidence, action, and revocation.
Control point
Remote-access and management authorization layers.
Failure
Broad destination access, stale role, weak device context, incomplete session evidence, or emergency-access persistence.
Recovery
Revoke unsafe authority, validate configuration state, restore access safely, and review evidence.
Monitoring path
Fictional example
Fictional network and service sources → evidence collection → analyst review.
Required context
Source, schema, health, purpose, transformation, timestamp, privacy limit, correlation, retention, and owner.
Control point
Evidence collection and access boundary.
Failure
Blind period, unhealthy source, over-collection, noise, missing context, or false confidence.
Recovery
Restore collection, mark evidence gaps, use alternate evidence, and reassess affected decisions.
Wireless path
Fictional example
Fictional managed device → managed wireless class → approved application service.
Required context
User identity, device identity, network class, authorization, destination, session, policy, evidence, and lifecycle.
Control point
Wireless onboarding and network authorization boundary.
Failure
Wrong network class, stale device, unavailable identity, weak guest separation, or missing visibility.
Recovery
Move to safe limited access, restore identity and policy, revoke stale access, and validate evidence.
Recovery path
Fictional example
Fictional recovery coordinator → recovery zone → identity, DNS, application, data, notification, archive, and monitoring services.
Required context
Trigger, approval, recovery identity, artifact, destination, order, validation, evidence, communication, and closure.
Control point
Recovery governance and dependency gates.
Failure
Incorrect restore order, broad emergency authority, stale naming, unavailable evidence, or unreconciled business state.
Recovery
Return to controlled degraded mode, correct sequence, reconcile state, revoke emergency access, and close.
Instructional Section 4
Ask Ten Architecture Review Questions
Mission
Review question
Which fictional user and service outcomes must remain correct, available, private, attributable, understandable, and recoverable?
Supporting fictional evidence
Service objectives, user journeys, critical workflows, owner decisions, support themes, and recovery expectations.
Identity
Review question
Which human and service identities act across each path, and how are role, object, device, time, purpose, lifecycle, and approval evaluated?
Supporting fictional evidence
Identity source, role map, service-identity register, access review, approval, session, and lifecycle records.
Reachability
Review question
Which fictional source truly needs to reach which destination for which purpose and under which state?
Supporting fictional evidence
Communication register, service dependency, owner approval, policy result, usage evidence, exception, and expiration.
Trust
Review question
What must be validated before a fictional zone accepts identity, data, commands, results, or evidence from another zone?
Supporting fictional evidence
Identity, schema, authorization, state, freshness, correlation, source health, policy, and owner review.
Administration
Review question
Are privileged management, support, emergency, and recovery paths separated from normal user and service communication?
Supporting fictional evidence
Management architecture, remote-access decision, destination list, session evidence, approval, change record, and revocation.
Visibility
Review question
Which defender questions must be answered at each fictional boundary and which source-health or privacy limits apply?
Supporting fictional evidence
Visibility map, event schema, connection metadata, policy result, source health, retention, access, and alert review.
Failure
Review question
What happens when fictional identity, DNS, routing, policy, supplier, monitoring, wireless, remote access, or management becomes unavailable?
Supporting fictional evidence
Failure-mode review, degraded-mode decision, alternate path, alert, communication, and exercise results.
Recovery
Review question
How does the fictional architecture restore correct connectivity, identity, DNS, service, evidence, business state, and communication?
Supporting fictional evidence
Recovery order, source artifact, validation, reconciliation, emergency-access revocation, communication, and closure.
Ownership
Review question
Who owns each fictional zone, path, dependency, policy, visibility source, exception, control, and residual risk?
Supporting fictional evidence
Owner register, decision rights, approval, review date, exception record, acceptance, and retirement.
Maintenance
Review question
Which fictional changes require architecture review and which temporary paths or assumptions must expire?
Supporting fictional evidence
Change history, architecture version, review trigger, expiration, reopened finding, and lifecycle plan.
Instructional Section 5
Separate Reachability, Authorization, Validation, and Business Action
| Decision layer | Question answered | Fictional evidence | What it does not prove |
|---|---|---|---|
| Reachability | Can the fictional source communicate with the destination under current policy and state? | Connection result, path, policy outcome, destination, time, and source health. | That the actor or service is authorized for every operation. |
| Identity | Which fictional human, device, or service is acting? | Authentication, service identity, device identity, session, certificate concept, and source. | That the identity may access the object or perform the action. |
| Authorization | May the fictional identity perform this action on this destination or object under these conditions? | Role, object, assignment, purpose, approval, policy result, and denial evidence. | That the supplied data or state is correct. |
| Validation | Does the fictional request, message, result, or state meet expected format, meaning, freshness, correlation, and version? | Schema result, state check, freshness, correlation, ordering, duplicate check, and reason. | That the resulting business action is safe in the current workflow. |
| Business action | Should the fictional system change case, preference, workflow, notification, archive, or recovery state? | Current state, transition rule, owner decision, user impact, result, and reconciliation. | That every dependency or future state is correct. |
| Evidence | Can defenders explain the fictional actor, path, decision, state, result, failure, and recovery? | Events, source health, correlation, ticket, approval, change, alert, recovery, and closure. | That the model has complete visibility or certainty. |
Instructional Section 6
Model Shared Dependencies and Failure Domains
Identity services
Ask which fictional zones depend on the same authentication, authorization, device, service-identity, and emergency-access systems.
Why it matters
Failure may affect user access, administration, service communication, monitoring attribution, and recovery.
DNS and naming
Ask which fictional services share naming, change, validation, evidence, and failover dependencies.
Why it matters
A second path may remain unusable when naming is stale or unavailable.
Management services
Ask whether fictional network, wireless, firewall, remote-access, monitoring, and recovery administration share one path or identity.
Why it matters
A management failure may prevent containment, evidence collection, and recovery.
Monitoring and time
Ask whether fictional evidence sources share collectors, time synchronization, storage, access, or dashboards.
Why it matters
A common failure can make multiple controls appear healthy while evidence is incomplete.
Supplier connectivity
Ask which fictional workflows, identities, data, queues, support processes, and recovery decisions rely on one supplier relationship.
Why it matters
Delay or change may affect multiple mission outcomes simultaneously.
Wireless and remote access
Ask whether fictional onboarding, identity, policy, management, DNS, and monitoring dependencies are shared.
Why it matters
A failure may force unsafe fallback or block legitimate support.
Power, capacity, and location
Ask whether fictional primary and backup paths share capacity, provider, physical location, or operational ownership.
Why it matters
Redundant diagrams may hide one real failure domain.
Recovery services
Ask whether fictional backup, restore, emergency access, DNS, identity, evidence, and communication can fail together.
Why it matters
Recovery may not be independently usable during the event it is intended to address.
Fictional Architecture View
Northbridge Defensive Network Architecture
This conceptual diagram is fully invented and intentionally non-operational. It shows mission relationships and control questions rather than real addresses, routes, devices, vendors, ports, firewall rules, wireless identifiers, or DNS records.
Public users
Student access through approved portal functions
Remote users
Support, administrators, suppliers, and recovery roles
Wireless users
Managed, employee, guest, and service-device classes
External supplier
Minimized request and validated result relationships
Fictional Northbridge Network
Public access zone
Portal and user-facing boundary
Application zone
Workflow and service logic
Data zone
Sensitive state and retention
Supplier zone
External request and result control
Management zone
Privileged administration
Evidence zone
Monitoring and source health
Wireless zone
Managed, guest, and service classes
Recovery zone
Restore, validation, and reconciliation
Identity
Human, device, service, emergency, and recovery authority
DNS
Naming, ownership, change, evidence, and failover
Policy
Segmentation, firewall, authorization, and exceptions
Recovery
Safe failure, order, evidence, communication, and closure
Fake Dashboard
Fake Northbridge Network Architecture Dashboard
Fictional zone, path, ownership, dependency, evidence, and recovery status for training only.
Approved communication paths
26 / 31
Five fictional paths remain temporary, unowned, expired, or insufficiently evidenced.
Shared critical dependencies
6
Identity, DNS, management, monitoring, supplier connectivity, and recovery support several zones.
Architecture findings blocking approval
3
Recovery access scope, temporary path ownership, and control-source independence require validation.
Fake SOC Alert
Recovery Path Bypasses Normal Administrative Evidence
Source: Fake Northbridge Architecture Assurance Console • Time: 1:42 PM
The fictional recovery zone has emergency reachability to the sensitive data and management zones, but destination scope, session evidence, approval independence, expiration, and revocation are only partially documented.
Defensive recommendation: Treat recovery access as conditional. Define fictional identity, destination, purpose, approval, evidence, time limit, validation, revocation, reconciliation, owner, and review trigger before final approval.
Fake Log Panel
Fake Defensive Architecture Review Timeline
training-log-viewer.log
09:00 SCOPE mission='student-support' state='current+future' 09:08 ZONE public-access owner='portal-team' 09:16 ZONE application owner='workflow-team' 09:24 ZONE data owner='data-team' 09:32 ZONE supplier owner='integration-team' 09:40 ZONE management owner='infrastructure-team' 09:48 ZONE evidence owner='monitoring-team' 09:56 ZONE wireless owner='network-team' 10:04 ZONE recovery owner='continuity-team' 10:12 PATH approved='26' total='31' 10:20 PATH temporary-unowned='2' 10:28 DEPENDENCY identity shared='true' 10:36 DEPENDENCY dns shared='true' 10:44 VISIBILITY east-west='partial' 10:52 VISIBILITY recovery='partial' 11:00 RESILIENCE backup-path='connectivity-only' 11:08 FINDING recovery-evidence='incomplete' 11:16 FINDING temporary-owner='missing' 11:24 CONFIDENCE architecture='moderate' 13:42 ALERT issue='recovery-access-evidence'
Training note: this is fake data for defensive analysis practice only.
Fictional Evidence Matrix
What the Architecture Evidence Supports—and What It Does Not Prove
AR-01
Fictional system-context brief
Observation
A public portal, application service, sensitive data service, processing supplier, notification service, monitoring service, archive, and recovery service support one student-help mission.
Supports
The architecture needs distinct user, service, supplier, administrative, evidence, data, and recovery trust decisions.
Does not prove
The brief does not prove actual communication, current policies, control effectiveness, or complete dependencies.
Architecture use
Define initial zones, mission dependencies, owners, flows, and review questions.
AR-02
Fictional communication register
Observation
Two temporary zone-to-zone paths have no current owner, expiration, or documented business purpose.
Supports
Lifecycle, least-connectivity, firewall-governance, exception, and ownership review are justified.
Does not prove
The register does not prove the paths are active, reachable, unsafe, or misused.
Architecture use
Mark the paths unvalidated and assign evidence owners before retain, restrict, or retire decisions.
AR-03
Fictional management-path summary
Observation
Support administration and infrastructure administration currently share one remote-access gateway but use different roles and destinations.
Supports
Administrative paths require separate purpose, authorization, device, destination, evidence, and failure analysis.
Does not prove
A shared gateway does not prove broad authority or unsafe sessions.
Architecture use
Model distinct access profiles and determine whether stronger separation or evidence is needed.
AR-04
Fictional visibility map
Observation
Public-boundary metadata is strong, while east-west application, supplier-result, DNS, wireless, management, and recovery evidence is uneven.
Supports
Network visibility should be designed across internal and dependency paths rather than only at the perimeter.
Does not prove
Uneven coverage does not prove compromise, complete blindness, or control failure.
Architecture use
Prioritize defender questions, source health, correlation, privacy, and alternate evidence.
AR-05
Fictional DNS dependency record
Observation
Portal, identity, supplier, notification, monitoring, and recovery services rely on two naming services managed through one shared change process.
Supports
DNS is a shared architecture and recovery dependency that needs ownership, change, evidence, failure, and resilience review.
Does not prove
The record does not prove incorrect resolution, outage, tampering, or insufficient redundancy.
Architecture use
Map shared failure points and define validation and recovery assumptions.
AR-06
Fictional wireless inventory
Observation
Managed employee devices, guest users, service devices, and one administrative use case are represented, but two service devices have unclear owners and lifecycle.
Supports
Wireless classes, device identity, onboarding, segmentation, ownership, monitoring, and retirement require design attention.
Does not prove
The inventory does not prove those devices are active, unsafe, or broadly reachable.
Architecture use
Create ownership and authorization actions before changing fictional access.
AR-07
Fictional resilience exercise
Observation
A backup path restored connectivity, but DNS updates lagged, remote support failed, and monitoring evidence was incomplete during transition.
Supports
Connectivity redundancy alone does not establish full mission, support, naming, evidence, or recovery resilience.
Does not prove
One exercise does not establish production frequency or every current control condition.
Architecture use
Define dependency gates, evidence continuity, degraded-mode communication, and retest criteria.
AR-08
Fictional recovery architecture
Observation
The recovery zone can reach several critical services under emergency approval, but destination scope, evidence, and revocation are only partially documented.
Supports
Recovery paths need identity, destination, order, evidence, approval, revocation, and residual-risk governance.
Does not prove
The diagram does not prove current reachability, misuse, or excessive authority.
Architecture use
Mark recovery access conditional and assign validation before final approval.
Analyze the Evidence
Which Architecture Decision Is Best Supported?
The fictional recovery zone can reach sensitive data and management services under emergency approval.
Destination scope and session evidence are only partially documented.
The recovery design references strong identity but does not show approval independence.
Emergency-access expiration and revocation are incomplete.
One resilience exercise restored connectivity while DNS, remote support, and monitoring remained degraded.
The evidence does not prove misuse or current excessive authority.
The recovery path affects identity, data, management, evidence, DNS, communication, and closure.
Overall architecture confidence is Moderate.
Which conclusion most responsibly addresses the fictional recovery-path evidence?
Architecture Defects
Ten Problems That Weaken Defensive Network Design
Flat trust model
Fictional observation
Many fictional services are treated as equally trusted because they are inside one environment.
Decision impact
Compromise, error, stale authority, or dependency failure may have a larger blast radius.
Strong correction
Define zones and trust decisions by mission, identity, data, service purpose, administration, evidence, and recovery.
Hidden administrative path
Fictional observation
A fictional support or maintenance interface is omitted from the main architecture.
Decision impact
Privileged reachability, evidence, lifecycle, and recovery decisions may be incomplete.
Strong correction
Add management and support paths with identity, device, destination, approval, session evidence, and revocation.
Unowned temporary connectivity
Fictional observation
A fictional path remains after a migration or exception without current owner, purpose, expiration, or evidence.
Decision impact
Temporary reachability may become permanent and escape review.
Strong correction
Assign owner, validate activity and dependencies, set expiration, and document retain, restrict, or retire decision.
Perimeter-only visibility
Fictional observation
Fictional defenders can see public traffic but not east-west, supplier, DNS, wireless, management, or recovery paths.
Decision impact
Important state changes and dependency failures may be difficult to explain.
Strong correction
Design visibility around trust changes, defender questions, source health, privacy, and alternate evidence.
Shared control failure domain
Fictional observation
Identity, DNS, policy, monitoring, and management depend on one fictional service or administrative process.
Decision impact
One failure can disable enforcement, evidence, administration, and recovery simultaneously.
Strong correction
Map shared dependencies, define safe degraded states, alternate evidence, recovery order, and residual risk.
Recovery bypass
Fictional observation
A fictional recovery path can reach sensitive services without the same identity, destination, evidence, or revocation requirements.
Decision impact
Emergency authority may remain broad or invisible after restoration.
Strong correction
Define recovery-specific controls, independent approval, time limits, session evidence, validation, revocation, and closure.
Zone by technology only
Fictional observation
Fictional zones group systems by product type without considering mission, data, identity, administration, ownership, or recovery.
Decision impact
Communication policy may not reflect actual trust or business risk.
Strong correction
Use mission and trust characteristics alongside technical architecture.
Redundancy without independence
Fictional observation
A fictional backup network path shares DNS, identity, management, power, monitoring, and supplier dependencies with the primary path.
Decision impact
The second path may fail during the same event and create false resilience confidence.
Strong correction
Map shared failure domains and validate end-to-end mission recovery, not only connectivity.
Architecture without lifecycle
Fictional observation
Fictional diagrams show current paths but no owners, versions, review dates, exceptions, assumptions, or retirement rules.
Decision impact
The design quickly becomes stale and cannot support later decisions.
Strong correction
Add ownership, evidence, versioning, expiration, triggers, findings, and maintenance.
Unsafe publication detail
Fictional observation
A fictional portfolio draft includes real-looking addresses, routes, device names, policy details, DNS records, or copied logs.
Decision impact
The artifact may expose sensitive information or become operationally unsafe.
Strong correction
Replace all details with clearly invented, non-operational, outcome-focused content.
Safe Fictional Practice Lab
Build the Northbridge Defensive Network Architecture Brief
Use only the supplied fictional information on this page. Do not access, scan, map, capture, intercept, test, configure, reroute, block, investigate, monitor, recover, or change any real network, device, wireless system, account, DNS service, gateway, firewall, sensor, or organizational infrastructure.
1
Write the architecture decision
Define the fictional student-support mission, the network architecture decision, stakeholders, current state, future state, exclusions, and public-learning safety boundary.
Required output
Architecture purpose and decision statement.
Quality check
The decision is narrower and more useful than “design a secure network.”
2
Inventory mission dependencies
List fictional users, critical services, identities, data, suppliers, DNS, wireless, remote access, management, monitoring, support, archive, and recovery needs.
Required output
Mission and dependency register.
Quality check
Each dependency has a purpose, owner, importance, failure effect, and evidence source.
3
Define zones
Group fictional services and actors by mission purpose, trust requirements, data sensitivity, administration, visibility, ownership, and recovery.
Required output
Zone register with inclusion and exclusion criteria.
Quality check
Zones are not based only on product type or convenience.
4
Map paths and trust changes
Document fictional user, service, supplier, administrative, monitoring, wireless, DNS, and recovery communication with purpose, identity, data, state, evidence, failure, and recovery.
Required output
Path and trust-decision register.
Quality check
Every path has one approved mission purpose and accountable owner.
5
Identify control and visibility points
Choose fictional locations for identity, authorization, segmentation, validation, firewall policy, monitoring, source health, alerting, and recovery gates.
Required output
Control-point and visibility map.
Quality check
Each control point answers a defined defender question and includes failure behavior.
6
Review shared failure domains
Trace fictional identity, DNS, management, routing, monitoring, supplier, wireless, remote-access, power, capacity, and recovery dependencies across zones.
Required output
Shared-dependency and failure-domain matrix.
Quality check
Redundancy claims include independence and end-to-end mission validation.
7
Design safe failure and recovery
Define fictional degraded modes, blocked actions, alternate evidence, communication, recovery order, validation, reconciliation, emergency access, revocation, and closure.
Required output
Failure and recovery architecture.
Quality check
Recovery restores correct mission and business state, not only connectivity.
8
Assign owners and maintenance
Give each fictional zone, path, control, dependency, evidence source, exception, assumption, risk, and trigger an accountable owner.
Required output
Ownership and maintenance register.
Quality check
Temporary paths and assumptions have expiration and review conditions.
9
Conduct peer review
Review fictional scope, trust, reachability, administration, visibility, dependencies, failure, recovery, evidence, privacy, lifecycle, and publication safety.
Required output
Architecture findings and action log.
Quality check
Findings challenge the design and evidence without blaming people or assuming intent.
10
Prepare the portfolio brief
Create a fictional leadership summary, technical architecture, risk priorities, assumptions, residual risks, decisions, review triggers, and reflection.
Required output
Complete defensive network architecture brief.
Quality check
Every name, path, identity, control, record, date, owner, and outcome is invented.
Scenario Decision Lab
A Temporary Path Has No Owner
The fictional communication register shows a temporary application-to-management path created during migration. The migration is complete, but current activity, purpose, owner, dependencies, and expiration are unknown.
Scenario Decision Lab
A Backup Path Restores Connectivity but Not the Mission
During a fictional resilience exercise, the secondary path becomes active. Basic connectivity returns, but DNS updates lag, remote support cannot connect, and monitoring evidence is incomplete.
Advanced Challenge
Defend a Network Architecture under Conflicting Requirements
The fictional mission owner wants fast supplier processing, the privacy owner wants fewer fields and narrower paths, the support owner needs reliable remote access, the network owner wants simpler policy, and the recovery owner needs emergency reachability. Build an architecture decision that protects the mission without turning every zone into one trust space.
Define mission-critical paths
Identify only the fictional communication required for student access, workflow, supplier processing, notification, support, evidence, and recovery.
Separate administrative use
Create distinct fictional support, infrastructure, supplier, and recovery access profiles with destination and evidence limits.
Minimize supplier trust
Use a controlled integration zone, minimized data, validated results, queue evidence, and safe degraded operation.
Preserve support usability
Define approved remote destinations, strong identity, managed devices, session evidence, support alternatives, and revocation.
Design recovery conditions
Use emergency approval, limited destinations, evidence, time limits, dependency gates, reconciliation, and closure.
Explain residual risk
Document shared identity, DNS, supplier, monitoring, management, capacity, and operational dependencies that remain.
Challenge output
Produce a fictional zone architecture, communication register, administrative-path design, supplier-boundary decision, visibility map, shared-dependency matrix, failure and recovery plan, owner map, assumptions, residual risks, and leadership explanation of the tradeoffs.
Defender Habits
Defensive Network Architecture Checklist
Check Your Understanding
A4.1 Mini Quiz: Defensive Network Architecture
Choose your answers first. Explanations appear only after submission.
1. Which statement best describes defensive network architecture?
2. Why should administrative paths be separated from normal user and service paths?
3. A fictional service can reach a destination. What does that prove?
4. What is the strongest reason to map shared dependencies?
5. Which visibility strategy is strongest?
6. Why does a second fictional network path not automatically prove resilience?
7. Which portfolio approach is safest?
Portfolio Prompt
Portfolio Prompt
Create a fully fictional Defensive Network Architecture Brief for the Northbridge Student-Support Cooperative. Include purpose, mission, decision, scope, stakeholders, exclusions, safety boundary, current state, future state, at least eight zones, at least twenty communication paths, human and service identities, north-south paths, east-west paths, administrative paths, supplier paths, wireless classes, DNS dependencies, visibility points, control points, shared failure domains, least-connectivity requirements, evidence fields, source-health requirements, safe-failure decisions, degraded modes, recovery order, reconciliation, emergency-access controls, owners, exceptions, expirations, assumptions, residual risks, review findings, completion criteria, architecture triggers, leadership summary, technical appendix, reflection, and a statement that every organization, zone, identity, path, service, record, control, owner, date, decision, and outcome is invented.
Start with fictional mission and service outcomes before drawing zones or control points.
Give every important communication path a documented purpose, identity, destination, owner, evidence source, failure mode, recovery need, and review trigger.
Show shared dependencies and failure domains rather than assuming segmentation or redundancy is automatically effective.
Separate normal user, service, supplier, administrative, monitoring, wireless, and recovery communication.
Keep the entire artifact completely fictional, defensive, non-operational, privacy-safe, evidence-aware, maintainable, and suitable for a public learning portfolio.
Confidence / Readiness Reflection
Are You Ready for Segmentation and Microsegmentation?
Before moving to A4.2, rate your readiness from 1 to 5 for mission context, zones, trust relationships, path purpose, identity, authorization, visibility, shared dependencies, administration, safe failure, recovery, ownership, maintenance, and complete fictionalization.
I can explain why an internal network should not be treated as one trusted space.
I can distinguish a clean-looking diagram from a decision-ready architecture.
I can separate reachability from authorization and safe business action.
I can identify where trust, ownership, identity, validation, evidence, or responsibility changes.
I can model shared identity, DNS, management, monitoring, supplier, and recovery dependencies.
I can explain why a backup path may not restore the mission.
I can create owned, reviewable, failure-aware administrative and recovery paths.
I can produce a safe fictional architecture without copying, modifying, or exposing real network information.
Record one fictional zone you changed after reviewing mission purpose, one hidden dependency, one administrative-path control, one recovery weakness, one residual risk, and one question you will carry into A4.2.
Key Takeaways
What You Should Remember
1.Defensive network architecture begins with fictional mission, users, services, identity, data, evidence, administration, failure, and recovery—not devices alone.
2.Zones should represent meaningful differences in purpose, trust, sensitivity, ownership, administration, visibility, and recovery.
3.Reachability does not prove identity, authorization, validation, safe business action, or control effectiveness.
4.Every important path should have a purpose, source, destination, identity, service, data need, owner, evidence, failure mode, recovery decision, exception, and review trigger.
5.Administrative, supplier, wireless, monitoring, DNS, and recovery paths require explicit architecture treatment.
6.Shared identity, DNS, management, monitoring, supplier, capacity, and recovery dependencies can invalidate segmentation and resilience assumptions.
7.Visibility should answer defined defender questions and include source health, privacy, retention, access, correlation, and alternate evidence.
8.Connectivity redundancy is not the same as end-to-end mission resilience.
9.Architecture is a living decision artifact with owners, versions, assumptions, residual risks, findings, expiration, and change triggers.
10.Every CyberShield network architecture artifact must remain fully fictional, authorized, defensive, non-operational, privacy-safe, and incapable of exposing real systems or people.
Navigation
Continue Module A4
Next, turn the fictional architecture into segmentation and microsegmentation decisions based on mission purpose, identity, service communication, asset value, trust, policy, evidence, operations, and recovery.