Security architecture
The intentional fictional arrangement of systems, identities, data, networks, services, controls, trust relationships, visibility, resilience, ownership, and change so the mission can operate safely.
High School AdvancedModule A2Lesson 1 of 10Architecture Foundations
A2.1 What Security Architecture Means
Learn why security architecture is more than a diagram or product list. Build a fictional design foundation that connects mission, assets, identities, data, networks, services, trust, control layers, evidence, resilience, ownership, decisions, and change.
Lesson Progress
What Security Architecture Means
High School Advanced • A2: Security Architecture • Lesson 1 of 10
10% complete
Readiness Check
Before You Start
0/6 ready
Professional Hook
A Diagram Can Look Secure while the System Remains Fragile
A fictional architecture diagram shows a public application, identity provider, internal service, database, logging platform, backup service, and supplier. The diagram looks organized, but one support administrator controls several critical functions, database and backup administration are not logged, the application reaches an undocumented management interface, and recovery restores the application without identity synchronization. Architecture means understanding how those decisions interact—not merely drawing the boxes.
Tool-first thinking
Add more products, trust the approved diagram, and assume each team will manage its own gap.
Architecture thinking
Start with mission and dependencies, map trust and ownership, define measurable requirements, coordinate control layers, analyze failure, and validate effective outcomes.
Objective 1
Explain security architecture as the coordinated design of mission, assets, identities, data, networks, services, controls, trust, visibility, resilience, ownership, and change.
Objective 2
Distinguish architecture, engineering, configuration, operations, policy, governance, products, and individual security controls in a fictional environment.
Objective 3
Create a fictional system-context map showing users, services, identities, data, dependencies, trust boundaries, owners, assumptions, and critical outcomes.
Objective 4
Evaluate whether a fictional design supports prevention, detection, response, recovery, privacy, service continuity, and professional accountability together.
Objective 5
Produce a portfolio-ready architecture foundation using only invented organizations, systems, identities, records, diagrams, decisions, dates, and outcomes.
Why This Matters
Security Outcomes Depend on Relationships between Decisions
A strong fictional identity control may still fail if recovery cannot restore identity state. Segmentation may reduce spread but fail if exceptions are unmanaged. Logging may exist but remain unusable because timestamps, source health, ownership, or retention are missing. Security architecture connects these decisions so the mission remains preventable, visible, recoverable, supportable, and governed.
Mission aligned
The fictional design protects the outcomes users and owners actually depend on.
Failure aware
The fictional design expects controls, services, identities, suppliers, and evidence sources to fail.
Governed
The fictional design has owners, requirements, validation, exceptions, versions, and residual-risk decisions.
Core Model
Mission → Context → Trust → Requirements → Controls → Validation
Mission
Define fictional users, critical functions, success, acceptable disruption, and operating assumptions.
Context
Inventory fictional systems, identities, data, services, suppliers, networks, owners, and dependencies.
Trust
Identify where fictional authority, sensitivity, ownership, identity, network, and control assumptions change.
Requirements
Write measurable fictional prevention, detection, privacy, resilience, evidence, and governance outcomes.
Controls
Coordinate fictional identity, segmentation, hardening, visibility, response, recovery, and ownership layers.
Validation
Prove fictional effective behavior, service outcomes, evidence quality, recovery, and residual risk.
Advanced Vocabulary
Language for Architecture Decisions
Mission
The fictional purpose the organization or service must accomplish for its users and stakeholders.
System context
A high-level fictional view showing the system, users, external actors, connected services, data exchanges, owners, and boundaries.
Asset
A fictional system, identity, data set, service, device, process, supplier dependency, or capability that has value and requires protection.
Dependency
A fictional system, service, identity, data source, supplier, network, process, or person required for another function to operate.
Trust relationship
A fictional assumption that one identity, service, system, owner, or data source may rely on another under defined conditions.
Trust boundary
A point where fictional ownership, authority, sensitivity, identity, network, service, or control assumptions change.
Security requirement
A measurable fictional condition the architecture must satisfy, such as limiting access, preserving evidence, maintaining service, or restoring within an approved period.
Control objective
The fictional outcome a safeguard should achieve, such as prevent unauthorized access, detect unusual activity, preserve evidence, or restore service.
Control implementation
The fictional process, configuration, technology, role, or procedure used to achieve a control objective.
Architecture decision
A documented fictional choice among design options, including context, assumptions, tradeoffs, owner, rationale, consequences, and residual risk.
Constraint
A fictional limitation involving time, budget, law, privacy, supplier capability, performance, usability, staffing, legacy systems, or service continuity.
Assumption
A fictional condition treated as true for design purposes that should be documented and later validated.
Failure mode
A fictional way in which a system, control, identity, data source, service, dependency, or process may fail or become unreliable.
Resilience
The ability of a fictional service to continue safely, degrade predictably, recover from known states, and validate restored outcomes.
Observability
The fictional evidence and context needed to understand system state, actions, failures, changes, and control effectiveness.
Residual risk
The fictional risk remaining after approved architecture controls and decisions are applied.
Architecture governance
The fictional ownership, review, versioning, exception, validation, change, and retirement process that keeps architecture aligned over time.
Architecture Layers
Ten Connected Layers of a Defensible Design
Mission and users
What fictional outcome must the service provide, for whom, under which safety and availability expectations?
Includes
Business purpose, user groups, critical functions, success measures, operating hours, support, and acceptable disruption.
Failure if missing
The design protects technology without knowing which outcomes matter most.
Portfolio output
Mission and user-needs statement
Assets and dependencies
Which fictional systems, identities, data, services, networks, suppliers, locations, and processes enable the mission?
Includes
Asset inventory, ownership, criticality, dependency chains, single points of failure, and lifecycle state.
Failure if missing
Important services or hidden dependencies remain unprotected and unrecoverable.
Portfolio output
Asset and dependency inventory
Identity and authority
Which fictional humans, services, devices, and workloads may act, and who approves their permissions?
Includes
Authentication, authorization, roles, privilege, lifecycle, emergency access, review, and monitoring.
Failure if missing
The architecture cannot explain who may do what, why, or under whose authority.
Portfolio output
Identity and privilege map
Data and privacy
What fictional information exists, why is it used, where does it move, who owns it, and how long is it retained?
Includes
Classification, purpose, minimum necessary, flow, storage, access, sharing, retention, deletion, and evidence needs.
Failure if missing
Security controls may overcollect, expose, misroute, or retain information without ownership.
Portfolio output
Data inventory and flow diagram
Networks and trust boundaries
Where do fictional communication, ownership, sensitivity, and trust assumptions change?
Includes
Zones, approved paths, denied paths, gateways, remote access, supplier connections, monitoring, and exceptions.
Failure if missing
Connected systems may be treated as equally trusted and broad impact may spread.
Portfolio output
Trust-boundary and zone diagram
Applications and services
How do fictional components provide the mission, validate requests, protect data, handle errors, and communicate with dependencies?
Includes
Service responsibilities, interfaces, authentication, authorization, configuration, secrets, logging, error handling, and recovery.
Failure if missing
Security decisions remain disconnected from how the service actually functions.
Portfolio output
Service responsibility map
Prevention and hardening
Which fictional safeguards reduce the likelihood and scope of unsafe behavior?
Includes
Secure defaults, least privilege, least functionality, segmentation, access limits, baselines, change control, and exceptions.
Failure if missing
The architecture depends mainly on detecting problems after they occur.
Portfolio output
Preventive-control map
Detection and visibility
Which fictional evidence sources answer important defender and owner questions?
Includes
Logs, metrics, alerts, source health, time quality, context, access, retention, integrity, and case linkage.
Failure if missing
The team cannot distinguish expected behavior, control failure, service degradation, or risk.
Portfolio output
Visibility and evidence-coverage map
Response and recovery
How does the fictional architecture contain problems, preserve evidence, continue critical functions, restore service, and validate recovery?
Includes
Playbooks, owner coordination, rollback, backup, restoration, continuity, communication, and residual monitoring.
Failure if missing
The architecture may prevent some events but fail dangerously when disruption occurs.
Portfolio output
Response and recovery architecture
Governance and change
Who owns fictional decisions, exceptions, suppliers, versions, validation, review cadence, residual risk, and retirement?
Includes
Decision records, approvals, reviews, exceptions, metrics, evidence, change control, and lifecycle ownership.
Failure if missing
The architecture becomes an outdated diagram rather than a maintained control system.
Portfolio output
Architecture governance plan
Architecture and Related Work
Architecture Guides Other Disciplines without Replacing Them
Security architecture
Primary question
How should the fictional system be structured so mission, trust, controls, visibility, resilience, ownership, and change work together?
Typical output
Context diagrams, trust boundaries, control patterns, requirements, decisions, tradeoffs, and governance.
Not the same as
Installing one product or writing one configuration.
Relationship
Guides and constrains engineering, operations, policy, and technology choices.
Security engineering
Primary question
How should an approved fictional architecture be implemented, tested, integrated, and maintained?
Typical output
Detailed designs, implementation plans, test cases, interfaces, configurations, and technical validation.
Not the same as
Owning the entire business and risk decision.
Relationship
Turns architecture into working technical controls.
Security operations
Primary question
How should fictional systems be monitored, triaged, supported, changed, responded to, and restored day to day?
Typical output
Runbooks, alerts, tickets, investigations, response actions, metrics, and lessons learned.
Not the same as
Defining every long-term design principle.
Relationship
Provides operational evidence that architecture works or needs revision.
Governance, risk, and compliance
Primary question
Which fictional obligations, risk decisions, evidence, policies, controls, ownership, and exceptions must be governed?
Typical output
Policies, risk registers, control mappings, audit evidence, exceptions, and owner decisions.
Not the same as
Designing every technical component.
Relationship
Supplies requirements and receives evidence from architecture and operations.
Privacy engineering
Primary question
How should fictional personal and sensitive information be minimized, used, protected, retained, deleted, and explained?
Typical output
Data inventories, purpose maps, field allowlists, privacy requirements, assessments, and lifecycle controls.
Not the same as
A single encryption or access-control decision.
Relationship
Shapes architecture wherever data and user rights are involved.
Product or platform selection
Primary question
Which fictional product or service best meets approved requirements and constraints?
Typical output
Requirements comparison, evaluation, procurement decision, and supplier-risk review.
Not the same as
Architecture itself.
Relationship
Products should fit the architecture rather than define it by default.
Professional Workflow
Ten Steps from Mission to Architecture Governance
1
State the fictional mission
What outcome must exist, who depends on it, which functions are critical, and what does safe operation mean?
Required output
Mission, users, critical functions, success measures, and operating assumptions.
Stop condition
Do not design controls before the mission and critical outcomes are understood.
2
Define the system context
What is inside the fictional system, what is outside, and which users, services, suppliers, and environments interact with it?
Required output
System-context diagram and boundary statement.
Stop condition
Pause if ownership or system limits are unclear.
3
Inventory assets and dependencies
Which fictional systems, identities, data, networks, services, suppliers, processes, and people enable the mission?
Required output
Asset, owner, criticality, lifecycle, and dependency inventory.
Stop condition
Do not assume the most visible application is the only critical asset.
4
Map trust and data flows
Where do fictional authority, sensitivity, ownership, network, identity, and control assumptions change?
Required output
Trust-boundary, zone, and data-flow diagram.
Stop condition
Pause if any path lacks a purpose or owner.
5
Write measurable requirements
What must the fictional architecture prevent, detect, preserve, continue, recover, explain, and validate?
Required output
Security, privacy, resilience, visibility, and governance requirements.
Stop condition
Reject vague requirements such as be secure or use strong security.
6
Design coordinated control layers
Which fictional preventive, detective, response, recovery, identity, segmentation, logging, hardening, and governance controls work together?
Required output
Layered control architecture and responsibility map.
Stop condition
Pause if all controls depend on the same platform, identity, owner, or data source.
7
Analyze failures and tradeoffs
What happens when fictional controls, identities, networks, suppliers, data sources, services, or administrators fail?
Required output
Failure-mode, dependency, tradeoff, and residual-risk matrix.
Stop condition
Do not claim resilience without testing failure assumptions.
8
Assign owners and decisions
Who designs, approves, implements, operates, communicates, validates, accepts risk, and governs change?
Required output
Architecture RACI-style responsibility and decision map.
Stop condition
Pause if no authorized owner exists for a critical decision or exception.
9
Validate the architecture
Which fictional evidence, review, test cases, recovery exercises, source checks, and effective-state checks prove the design works?
Required output
Architecture validation plan and evidence register.
Stop condition
Do not treat a diagram or approved document as proof of effective behavior.
10
Govern lifecycle and change
How are fictional versions, exceptions, suppliers, owners, data flows, technologies, risks, and retirement reviewed over time?
Required output
Architecture governance, review, change, and retirement plan.
Stop condition
Do not let the approved design drift silently.
Architecture Ownership
Ten Owners with Different Decisions
Business or mission owner
Owns
Fictional mission, users, critical outcomes, acceptable disruption, value, and business residual risk.
Must decide
Whether the architecture supports the mission and whether remaining business risk is acceptable.
Required evidence
Mission statement, critical-function list, service priorities, and risk decision.
Security architect
Owns
Fictional security design principles, trust model, control patterns, architecture decisions, and integrated review.
Must decide
Whether the proposed design satisfies approved security requirements and documents limitations.
Required evidence
Architecture diagrams, requirements, decision records, and validation plan.
System or application owner
Owns
Fictional service function, component behavior, dependencies, configuration ownership, support, and lifecycle.
Must decide
Whether the system design and changes meet service needs.
Required evidence
Service map, component inventory, dependencies, and owner validation.
Identity owner
Owns
Fictional authentication, authorization, roles, privilege, lifecycle, emergency access, review, and identity evidence.
Must decide
Which identities and permissions are justified and how they are governed.
Required evidence
Identity map, access matrix, lifecycle, approvals, and review logs.
Data or privacy owner
Owns
Fictional data purpose, classification, fields, access, sharing, retention, deletion, and privacy requirements.
Must decide
Which data uses and flows are authorized and minimum necessary.
Required evidence
Data inventory, flow map, classification, owner approval, and lifecycle rules.
Network or platform owner
Owns
Fictional zones, communication paths, connectivity, platform services, availability, configuration, and monitoring.
Must decide
Which paths and platform capabilities are approved and supportable.
Required evidence
Zone map, flow allowlist, configuration baseline, and validation.
Logging and detection owner
Owns
Fictional evidence sources, context, source health, time quality, access, retention, integrity, coverage, and alert use.
Must decide
Whether defender and owner questions can be answered reliably.
Required evidence
Visibility map, source inventory, health checks, retention, and coverage review.
Service continuity and recovery owner
Owns
Fictional continuity, backup, restoration, dependency order, rollback, communication, exercises, and recovery validation.
Must decide
Whether the service can be restored to a known safe state within approved expectations.
Required evidence
Recovery sequence, backup records, exercises, health checks, and signoff.
Supplier or contract owner
Owns
Fictional external dependencies, service commitments, evidence, communication, change, support, exit, and supplier risk.
Must decide
Which supplier capabilities and risks are acceptable.
Required evidence
Supplier map, agreement requirements, review evidence, and contingency plan.
Risk owner or leadership
Owns
Fictional cross-functional tradeoffs, resources, exceptions, residual risk, and final acceptance.
Must decide
Which architecture option is approved and which remaining risks are accepted, reduced, transferred, avoided, or monitored.
Required evidence
Decision record, option comparison, exception, owner, deadline, and acceptance.
Measurable Requirements
Replace Vague Security Language with Testable Outcomes
Access
Weak requirement
Only authorized users may access the system.
Strong requirement
Each fictional human and service identity must use an approved role, least privilege, named owner, expiration or lifecycle state, review evidence, and monitored administrative activity.
Validation
Role-to-permission matrix, denied-path test, access review, and audit record.
Data
Weak requirement
Sensitive data must be protected.
Strong requirement
The fictional service must use only approved fields for the stated purpose, encrypt protected data in approved states, restrict access by role, retain it for the approved period, and validate deletion.
Validation
Data flow, field allowlist, access test, storage review, retention, and deletion evidence.
Segmentation
Weak requirement
The network should be segmented.
Strong requirement
Fictional public, application, data, management, logging, backup, and supplier zones may communicate only through documented owner-approved paths with monitoring and exception review.
Validation
Zone diagram, flow matrix, effective-path review, denied-path checks, and exception evidence.
Visibility
Weak requirement
Enable logging.
Strong requirement
Fictional identity, application, database, administrative, change, backup, and recovery events must include reliable time, actor, action, target, result, source health, owner, retention, and access controls.
Validation
Evidence coverage, sample records, time-quality test, source-health check, and access review.
Recovery
Weak requirement
The service must have backups.
Strong requirement
The fictional service must restore application, identity, data consistency, logging, dependencies, and user access from approved recovery states and validate each outcome before closure.
Validation
Recovery exercise, service checks, identity checks, data integrity, logging, owner signoff, and residual-risk record.
Change
Weak requirement
Changes must be approved.
Strong requirement
Fictional architecture-impacting changes must identify owner, purpose, affected assets, trust boundaries, data flows, dependencies, risk, rollback, validation, communication, and review deadline.
Validation
Change record, architecture diff, approval, implementation evidence, rollback test, and post-change review.
Architecture Principles
Eight Principles for a Defensible Design
Mission before technology
Fictional controls and products should support defined user, service, data, and recovery outcomes.
Failure pattern
The team purchases tools before understanding what must be protected.
Evidence
Mission, critical functions, user needs, and measurable requirements.
Explicit trust
Every fictional reliance between identities, systems, services, owners, data sources, and suppliers should be documented and validated.
Failure pattern
Internal or connected systems are trusted automatically.
Evidence
Trust-boundary map, flow matrix, owner, condition, and validation.
Layered protection
Fictional preventive, detective, response, and recovery controls should provide meaningful independent value.
Failure pattern
Several controls fail together because they share one platform or identity.
Evidence
Control-dependency and failure-mode review.
Least privilege and least functionality
Fictional identities, services, paths, data, and features receive only what the mission requires.
Failure pattern
Broad access and unnecessary services remain enabled for convenience.
Evidence
Access matrix, service inventory, exceptions, review, and effective-state checks.
Evidence by design
The fictional architecture should produce reliable evidence for security, service, privacy, recovery, and governance questions.
Failure pattern
Important administrative actions cannot be reconstructed.
Evidence
Logging coverage, source health, time quality, retention, integrity, and access.
Safe failure and recovery
Fictional systems should fail predictably, preserve critical functions, protect evidence, and restore from known states.
Failure pattern
A control outage removes both service and visibility.
Evidence
Failure tests, fallback, rollback, recovery sequence, and validation.
Clear ownership
Every fictional asset, identity, data set, path, control, exception, dependency, decision, and residual risk needs an authorized owner.
Failure pattern
Everyone assumes another team owns the gap.
Evidence
Responsibility map, approvals, actions, deadlines, and signoff.
Governed change
Fictional architecture evolves through visible, reviewed, tested, reversible, documented decisions.
Failure pattern
Suppliers, data flows, identities, and exceptions change without architecture review.
Evidence
Version history, architecture diff, change record, validation, and review cadence.
Fake Dashboard
Fake Northbridge Architecture Foundation Dashboard
Fictional mission, trust, identity, visibility, recovery, and governance review for training only.
Critical dependencies
7
Identity, database, logging, backup, supplier, support, and network services enable the mission.
Architecture gaps
4
Privilege concentration, undocumented flow, evidence coverage, and incomplete recovery require design changes.
Current status
Review
The architecture is not ready for approval until requirements and validation are complete.
Fake SOC Alert
Approved Diagram Does Not Match Effective Architecture
Source: Fake Northbridge Architecture Review Console • Time: 2:16 PM
The fictional application reaches an undocumented backup-management interface, one support identity controls several critical functions, database and backup administration lack evidence coverage, and recovery omits identity synchronization.
Defensive recommendation: Pause architecture approval, confirm mission and ownership, update the context and flow diagrams, review privilege, add evidence requirements, redesign recovery validation, and document tradeoffs and residual risk.
Fake Log Panel
Fake Architecture Review Timeline
training-log-viewer.log
13:00 MISSION service='overnight-support' 13:05 CONTEXT systems='app,idp,service,db,logs,backup,supplier' 13:12 IDENTITY support-admin='multi-domain-privilege' 13:18 FLOW app-to-backup-mgmt='observed' 13:19 DIAGRAM app-to-backup-mgmt='missing' 13:25 LOGGING database-admin='not-covered' 13:26 LOGGING backup-admin='not-covered' 13:35 RECOVERY application='restored' 13:36 RECOVERY identity-sync='incomplete' 13:37 RECOVERY security-logs='incomplete' 13:45 REQUIREMENT identity-recovery='missing' 13:50 OWNER backup-admin='unclear' 14:00 DECISION architecture-approval='paused' 14:05 ACTION trust-map='update' 14:10 ACTION requirements='rewrite' 14:16 STATUS validation='required'
Training note: this is fake data for defensive analysis practice only.
Fictional Evidence Matrix
Evidence before Architecture Approval
A2-01
Fictional mission statement
Observation
The service provides overnight support for three internal teams and must remain available during regional maintenance.
Supports
Availability, identity continuity, support, and recovery are important architecture requirements.
Does not prove
Does not define acceptable disruption or every dependency.
Architecture use
Ask the mission owner for measurable service and recovery expectations.
A2-02
Fictional system-context diagram
Observation
A public application connects to identity, internal service, database, logging, backup, and supplier systems.
Supports
Multiple trust, ownership, data, and dependency boundaries exist.
Does not prove
Does not prove actual communication paths or controls.
Architecture use
Create trust-boundary, data-flow, and owner maps.
A2-03
Fictional identity matrix
Observation
One support administrator can manage application, identity, database, and backup functions.
Supports
Privilege and role concentration may increase impact and weaken independent review.
Does not prove
Does not prove misuse or that every permission is unnecessary.
Architecture use
Review least privilege, role separation, emergency access, and monitoring.
A2-04
Fictional flow record
Observation
The application communicates directly with a backup-management interface not shown in the approved design.
Supports
Effective behavior may not match the architecture diagram.
Does not prove
Does not prove harmful traffic or intentional bypass.
Architecture use
Investigate ownership, purpose, path approval, monitoring, and correction.
A2-05
Fictional logging map
Observation
Application and identity activity are visible, but database administration and backup changes are not.
Supports
The architecture lacks evidence for important administrative questions.
Does not prove
Does not prove a security event occurred.
Architecture use
Expand evidence coverage with privacy, integrity, source-health, and retention controls.
A2-06
Fictional recovery exercise
Observation
The application returns, but identity synchronization and security logging remain incomplete.
Supports
Application availability alone does not equal full service recovery.
Does not prove
Does not prove the recovery design always fails.
Architecture use
Redesign the recovery sequence and validation gates.
A2-07
Fictional architecture decision record
Observation
A low-cost option combines identity, application, logging, and backup administration in one platform.
Supports
The option reduces complexity but increases correlated-failure and privilege-concentration risk.
Does not prove
Does not determine whether the option is unacceptable.
Architecture use
Compare cost, simplicity, resilience, ownership, recovery, and residual risk.
A2-08
Fictional change log
Observation
A supplier connection was added without updating the context diagram, data flow, trust boundaries, or evidence plan.
Supports
Architecture drift and governance failure occurred.
Does not prove
Does not prove the supplier connection is unsafe.
Architecture use
Require architecture review, owner validation, and updated documentation.
Analyze the Evidence
Should the Fictional Architecture Be Approved?
The mission depends on overnight availability and coordinated recovery.
One support administrator controls application, identity, database, and backup functions.
The application reaches an undocumented management interface.
Database and backup administrative actions are not logged.
Application recovery succeeds, but identity synchronization and logging remain incomplete.
Several asset and control owners are unclear.
The approved diagram does not match effective behavior.
Should the fictional Northbridge architecture be approved in its current state?
Common Architecture Mistakes
What Advanced Defenders Must Avoid
Starting with a fictional product name instead of the mission, users, data, dependencies, and requirements.
Treating one diagram as the architecture rather than a view of the architecture.
Listing controls without explaining which mission outcome, asset, boundary, or failure they address.
Assuming connected or internal fictional systems are automatically trusted.
Designing several controls that depend on the same platform, identity, administrator, or evidence source.
Ignoring service continuity, recovery order, identity restoration, logging, and communication.
Using vague requirements such as secure, strong, modern, or protected without measurable validation.
Failing to assign owners for identities, data, paths, logs, backups, suppliers, exceptions, and residual risk.
Treating an approved diagram as proof that effective configuration and behavior match the design.
Collecting more fictional data and logs than the purpose requires.
Focusing on prevention while neglecting detection, response, recovery, and improvement.
Allowing architecture changes and supplier connections to drift without versioned review.
Using real internal diagrams, configuration details, credentials, logs, or supplier architecture in a portfolio artifact.
Making the fictional architecture so complex that it becomes difficult to operate, validate, recover, and govern.
Safe Practice Lab
Build a Fictional Architecture Foundation
Fictional assignment
Rebuild the Northbridge Architecture Context
Use only the invented evidence on this page. Do not upload, copy, quote, lightly modify, summarize, or reproduce real internal architecture, diagrams, network details, configurations, credentials, logs, system names, supplier information, or private records.
Required deliverables
- Mission, users, critical functions, and success measures.
- System-context and boundary diagram.
- Asset, identity, data, service, supplier, and dependency inventory.
- Trust-boundary and data-flow map.
- Measurable security, privacy, visibility, resilience, and governance requirements.
- Layered control and control-dependency map.
- Owner, decision, exception, and residual-risk matrix.
- Failure-mode and tradeoff analysis.
- Architecture validation and evidence plan.
- Revision history, reflection, and complete fictionalization statement.
This activity produces a fictional educational design only. It does not authorize access, scanning, testing, configuration, change, investigation, or collection involving any real system.
Scenario Decision Lab
The Team Wants to Buy a Security Product First
A fictional project team wants to select a platform immediately, but the mission, critical functions, data, dependencies, trust boundaries, owners, recovery needs, and measurable requirements are incomplete.
Scenario Decision Lab
The Diagram Was Approved, but the Flow Is Undocumented
A fictional flow record shows the application reaching a backup-management interface not present in the approved architecture diagram.
Advanced Challenge
Design for a Failure That Removes Both Control and Evidence
Extend the fictional Northbridge design with one correlated-failure scenario. Assume the same platform provides identity, logging, and administration. Explain what happens when that platform becomes unavailable or unreliable. Your response must preserve service, prevent uncontrolled privilege, retain minimum evidence, support safe fallback, assign owners, and define recovery validation.
Required analysis
Identify affected mission functions, trust boundaries, identities, evidence, dependencies, owners, and decisions.
Required design
Propose fictional independent controls, fallback, communication, rollback, recovery order, validation, and residual-risk ownership.
Defender Habits
Security Architecture Foundation Checklist
Check Your Understanding
A2.1 Mini Quiz: What Security Architecture Means
Choose your answers first. Explanations appear only after submission.
1. What best describes security architecture?
2. Why should architecture begin with the fictional mission?
3. A fictional diagram shows a supplier connection. What does the diagram alone prove?
4. Which requirement is strongest?
5. What is a trust boundary?
6. A fictional recovery exercise restores the application but not identity synchronization or logging. What is strongest?
7. What makes an A2.1 architecture portfolio artifact safe to share?
Portfolio Prompt
Portfolio Prompt
Create a fully fictional Security Architecture Foundation Package for Northbridge. Include the mission, users, critical functions, context diagram, system boundary, asset inventory, identity map, data inventory, dependency map, trust boundaries, approved flows, measurable requirements, architecture layers, control dependencies, owner map, failure modes, tradeoffs, validation plan, architecture decision record, residual risk, governance, reflection, revision history, and a statement that every organization, system, identity, record, diagram, owner, decision, date, and outcome is invented.
Begin with fictional mission and critical outcomes rather than products.
Show both the approved design and one fictional effective-state mismatch.
Include at least one correlated control failure and explain how the design responds.
Make requirements measurable and connect each one to evidence and an owner.
Keep every architecture element completely invented, defensive, non-operational, and safe to share.
Confidence / Readiness Reflection
Are You Ready to Design Defense in Depth?
Before moving to A2.2, rate your readiness from 1 to 5 for each area: mission definition, context mapping, trust boundaries, measurable requirements, control relationships, ownership, failure analysis, validation, and architecture governance.
I can explain why security architecture is more than a product list or diagram.
I can create a fictional context map with mission, assets, identities, data, services, suppliers, owners, and dependencies.
I can identify fictional trust changes and write measurable requirements.
I can connect control layers to failure modes, evidence, recovery, and ownership.
I can explain what the fictional evidence does and does not prove.
I can keep the entire architecture portfolio fully invented and safe to share.
Record one architecture concept you can explain confidently, one assumption you would validate before approval, and one skill you will strengthen in A2.2.
Key Takeaways
What You Should Remember
1.Security architecture coordinates mission, assets, identities, data, networks, services, controls, trust, visibility, resilience, ownership, and change.
2.A product, configuration, policy, diagram, or individual control is only one part of the architecture.
3.Architecture begins with users, critical functions, dependencies, assumptions, and measurable outcomes.
4.Trust boundaries identify where authority, ownership, sensitivity, identity, network, service, or control assumptions change.
5.Strong fictional requirements are specific, measurable, owner-aware, and testable.
6.Control layers should provide independent value rather than failing together through shared dependencies.
7.Evidence, source health, time quality, privacy, retention, and ownership should be designed before incidents occur.
8.Recovery must validate identity, data, dependencies, service, logging, access, communication, and residual risk—not only application availability.
9.Architecture remains effective through owners, decisions, validation, exceptions, versioning, change control, and lifecycle governance.
10.Every CyberShield architecture artifact must remain fully fictional, defensive, non-operational, privacy-safe, and incapable of exposing real systems.
Navigation