docs/TO_GUIDE.md

The Threat Orchestrator's Guide

Version: 2.2 - Playtest Edition Audience: anyone about to run Incident Zero — teacher, trainer, or the friend who volunteered.

1. The Role

The Threat Orchestrator (TO) is Incident Zero's dungeon master. You wear three hats, usually in the same minute:

• The Adversary — you built the hidden attack chain; you know what the Blue Team doesn't. You want them challenged, not beaten.
• The Narrator — you turn card text into a story. "You failed the roll" is a rules outcome; "the log archive was rotated last night — whatever was there is gone" is a game.
• The Teacher — you award the justification bonuses, ask "why?", and run the debrief. Every roll is a chance to make someone articulate real security reasoning.

If you've ever run a tabletop RPG, you already have 80% of this. The remaining 20% is the adjudication rubric in §4 — it's the part that makes this game educational rather than just thematic.

A good TO makes the game. The same scenario is flat or unforgettable depending on how you deliver clues and how honestly you judge reasoning. That's why this guide exists.

2. Golden Rules

1. Be fair, not nice. Never fudge dice — in either direction. The rules already give you legitimate difficulty dials (§5); use those, not your thumb on the d20.
2. Never block on ignorance. If players are stuck, sell them a hint through the fiction ("your SOC junior suggests looking at outbound traffic...") rather than letting three turns die in silence.
3. Announce costs before actions. "That's 15 Budget — confirm?" prevents every argument you'd otherwise have.
4. Explain outcomes. Success or failure, say why in security terms. The explanation is the lesson; the roll is just pacing.
5. Keep the clock. 2-3 minutes of planning per turn, firmly. Deliberation past that point is quarterbacking, not strategy.
6. Let them be wrong. A confidently wrong plan that fails teaches more than a corrected plan that succeeds. Save the correction for the debrief.

3. Session Prep (15 minutes)

• [ ] Pick the module; skim its rules doc and its v2.2 Playtest Edition Changes section
• [ ] Build your scenario (IR: choose the chain; Hardening: threat profile; DR: pick scenario + place scheduled events on the timeline; Forensics: pick tier; Audit: pick sample org; NB: shuffle REQ/EVT decks)
• [ ] Print/lay out: tracker sheets, the module's cards, one d20 (d4/d6 where the module calls for them)
• [ ] Rehearse your first clue out loud once. Seriously — the first clue sets the session's tone.
• [ ] Decide your difficulty posture (§5) based on who's at the table
• [ ] First time running anything? Use the fully scripted opening in How to Play §4

4. Judging Justifications (the heart of the job)

The +2/+1 modifiers are the game's teaching engine. Your consistency is what makes them meaningful.

+2 — Strong technical justification. The player explains methodology: what they'll look at, and why that would reveal or stop this specific thing. - ✅ "We pull the mail gateway logs and compare the return-path against the display-name domain — spoofed senders won't match." (mechanism stated) - ✅ "Deploy EDR because living-off-the-land attacks won't trip signature AV — we need behavioral detection." (threat-to-control logic) - ❌ "We investigate the email server thoroughly." (a location is not a method)

+1 — Real tool or technique named. Wireshark, Splunk queries, Mimikatz, a MITRE technique ID, an actual CVE. - ✅ "Check LSASS access events — that's Mimikatz behavior, T1003." - ❌ "We use our security tools." (no it isn't)

Rulings that keep it fair: - Judge the reasoning, not the vocabulary. A beginner saying "check if the email really came from who it says" in plain words has the mechanism — award the +2. A buzzword salad without a mechanism gets +0. - Consistency beats generosity. Whatever bar you set on turn 1 is the bar all game. - Escalate the bar as the group learns — by session three, "we check the SIEM" that earned +1 in session one should need a specific query. Announce the escalation openly ("you're professionals now — I want specifics"). - Expert groups ("Expert Mode"): award +2 only for named artifacts, ATT&CK technique IDs, or detection logic. This is the challenge ceiling for practitioner tables — the card math never has to change. - One player monologuing every justification? Ask a different player to give it each turn ("Sam, you're on comms — why does this matter to the regulator?").

5. Difficulty Dials (live, legitimate)

Signs it's too easy: no failed rolls; goal in sight with 40+ Budget spare; players bored. Signs it's too hard: no progress for 3+ turns; consecutive failures; frustration replacing discussion.

Never adjust by fudging a roll or changing a printed number mid-game — players smell it, and it teaches that outcomes are arbitrary.

6. Failure Modes (yours, not theirs)

7. Module Panels (your screen, one per module)

🔎 Incident Response — you are the hidden attacker

• Setup: secret chain in kill-chain order (3-5 cards) · turns = (chain × 2) + 1 → 7/9/11 · Budget 100 · team draws 5 Defense cards
• Start of every turn, announce: -5 Active Breach (any card hidden) · -5 per uncontained revealed threat · then current Budget
• Actions: Investigate 5 (1st success on a link = clue, 2nd = reveal) · Deploy 10/15/25 (vector+step match = reveal; partial = stays, +2 later vs its vector) · Emergency Response 15 (contain, no roll)
• Always target the earliest unrevealed card. On reveal: +1 uncontained, previous auto-contains, team picks reward (2 cards / +10 Budget / next Investigate 5+)
• Your craft: progressive clues — first success is a symptom, second-to-last is nearly a name. Announce "your deployed defenses are helping here" when the +2 persistence applies — it's a clue in itself.

🛡️ Hardening — you become the pentester mid-game

• Setup: threat profile via 1d6 across all 6 vectors · 7 turns · Budget 150 (or IR carryover)
• Actions (one/turn): Deploy defense 10/15/25 (two BASIC may be one action) · Upgrade 5 (+2 on that defense) · Playbook 10 (+3, max 2 per game) · Test & Drill (roll)
• Pentester Challenge (turns 3-4): draw PT cards. Resolution: d20 + printed bonus of the ONE chosen defense + its upgrades + relevant playbook ≥ the card's DC. No stacking across defenses. Multi-vector tactics = separate rolls, one defense each.
• Victory gate: score ≥60 AND ≥4 defenses deployed AND majority of tactics defended. Score = defenses×5 + upgrades×2 + playbooks×10 + tactics defended×5 + (Budget left/150)×10.
• Your craft: narrate the pentester as a person with a plan; read the card's teaching point after each resolution, win or lose.

🏗️ Network Building — you are the demanding business

• Setup: Budget 60/50/40 (easier→harder) · 5 turns = design-review phases · REQ deck (1/turn) + EVT events between turns
• Turn rule: place ANY number of affordable components. Required: Email, Web, Database, Identity (DC), Backup. Overload = +1 Budget per extra service over capacity.
• Scoring: max 40 · tiers 32-40 / 22-31 / 12-21 / <12 · smart utilization beats hoarding (5-15 left is the sweet spot)
• Your craft: play the CFO and the auditor — every REQ card is a stakeholder with a voice. "Legal called: we're in PCI scope now."

🚨 Disaster Recovery — you are the crisis itself

• Setup: 8 turns (~72h) · Budget 50 · 3 tracks (Investigation/Remediation/Communication) + 5 stakeholder trust meters at start values · place scheduled events: EVENT-01 T2, 04 T3, 03+09 T5, 02 T6, 12 T7; triggered events fire on conditions
• Turn: one ACTION card (0-20 Budget; Holding Statement is free). Advances are deterministic — dice only for: optional Justification bonus (strong reasoning → d20, 11+ = +5% on that advance) and ACTION-13's pay-the-ransom reliability roll (1-5 = keys fail)
• Deadlines: customers by T5 · regulator penalties from T6, hard GDPR line T8 · Loss: any trust meter hits 0% · final Reputation computed at game end (tiers 85/70/55/40)
• Your craft: you are the ringing phone. Open every turn in-fiction: "The journalist calls again. The board wants a number. What do you do?"

🔬 Forensics — you are the evidence

• Setup: tier sets turns (TIER 2 ≈ 8-10, TIER 3 = 11-13, +d4 variation) · Budget 75 · 4 meters at 0%
• Actions: Investigation card (printed cost/DC; Duration N = results arrive N turns later, one in flight) · Analyze evidence 5 (DC 10, once per card, only two meters) · Follow lead 5
• Key rulings: evidence card's printed impacts replace the investigation's advance line (no double counting) · +5% Chain of Custody each time evidence is discovered AND the team states preservation (hash/image/export) · partial success band = DC-2 to DC-1 · haste -2
• Victory (checked first, at game end): V1 Attribution≥90+Timeline≥80 · V2 Timeline≥80+Chain≥80+CoC≥70 · V3 any two ≥70. Budget-out is NOT a loss.
• Your craft: describe evidence sensorily ("the timestamp is three hours before the alert"). Ask "how are you preserving that?" every single time — that question IS the chain-of-custody lesson.

📋 Audit & Compliance — you are the organization under review

• Setup: pick sample org (or the debate Variation C) · no budget during assessment (100 only for optional remediation cards)
• Scoring: 6 domains, PASS/FAIL against printed criteria (stars: 1-2★=FAIL, 3★+=PASS, PARTIAL=FAIL) → X/6 · gap penalties for later modules capped at -30 total
• Ruling discipline: the printed criteria decide, not vibes — untested backups FAIL even if the team likes the org. Disagreement about a borderline call is not a problem; it's the lesson. Let them argue, then apply the criterion.
• Your craft: in Variation C you're the judge panel — score arguments on risk reasoning, not rhetoric.

8. Running the Debrief (10 minutes, non-negotiable)

Three rounds, in order: What happened? (players narrate, you correct only facts) → Why did it work that way? (connect two or three key moments to real-world security — this is where you finally get to lecture, briefly) → What would you do differently? (go around the table; everyone answers). Losses debrief better than wins: read any unrevealed cards' "Why This Works" text aloud — it's the payoff for losing.

9. First Session? Do This

1. Run beginner Incident Response with the scripted opening in How to Play §4 — your first two turns are literally written out
2. Keep the tracker sheet visible to everyone; public state builds trust in your fairness
3. Log frictions on the session notes form — your confusion is playtest data too
4. Forgive yourself one rules mistake per session; announce it, fix it forward, don't replay

docs/rules/core-rules.md

Incident Zero: Core Rules & Mechanics

Version: 2.2 - Playtest Edition Last Updated: October 2025

Core Concept 🎯

Incident Zero is a modular cybersecurity board game for 2+ players designed for educational environments. One player acts as the Threat Orchestrator (TO) (the facilitator), while all other players form Blue Teams (the Defenders).

How It Works

Players choose which module(s) to play based on learning objectives:

1. Network Building Module - Design and secure infrastructure (30-45 min)
2. Hardening Module - Build defense-in-depth (30-45 min)
3. Incident Response Module - Detect and investigate hidden attack chains (30-45 min)
4. Disaster Recovery Module - Manage breach crisis (30-45 min)
5. Forensics Module - Investigate and attribute attacks (30-45 min) NEW in v2.1
6. Audit & Compliance Module - Conduct security assessments (30-45 min)

Modules can be played solo or combined in any sequence using the modifier generation procedures documented in FRAMEWORK.md and Module Combinations.

Game Components (Universal)

Card Types

Threat Cards

Represent attacker actions. Each card includes: - Title: e.g., "Phishing Campaign" - Attack Chain Step: INITIAL COMPROMISE, PIVOT & ESCALATE, PERSISTENCE, or C2 & EXFIL - Attack Vector: SOCIAL ENGINEERING, WEB EXPLOIT, CREDENTIAL ABUSE, MALWARE, NETWORK, or DATA EXFIL - Clue: Descriptive text for the Threat Orchestrator - Why This Works: Educational explanation (revealed after discovery)

Deck Composition: - 12 Base Threat Cards (see cards/incident-response/core-deck/threat-defense-cards.md) - 8 Expansion Threat Cards (see cards/incident-response/expansion-deck/advanced-threats.md)

Defense Cards

Represent security controls. Each card includes: - Title: e.g., "Multi-Factor Authentication" - Countermeasure Vector: One of the six attack vectors - Tier: BASIC (10 Budget), ADVANCED (15 Budget), or ELITE (25 Budget) - Description: What the defense does and when it applies

Deck Composition: - 24 Base Defense Cards (see cards/incident-response/core-deck/threat-defense-cards.md) - 19 Expansion Defenses (see cards/incident-response/expansion-deck/advanced-defenses.md)

Examples: - BASIC: Email Authentication Setup, User Security Training, Firewall Rules (10 Budget) - ADVANCED: Multi-Factor Authentication, EDR, Network Segmentation (15 Budget) - ELITE: Threat Hunting, Memory Forensics, Deception Technology (25 Budget)

Pentester Tactic Cards

Represent sophisticated attack techniques used in Hardening module (and potentially others).

8 Core Tactics (PT-01 to PT-08): 1. PT-01: Social Engineering - Pretexting Attack 2. PT-02: Malware Evasion - Living-off-the-Land Technique 3. PT-03: Credential Dumping - Mimikatz Attack 4. PT-04: Lateral Movement - Network Traversal 5. PT-05: Privilege Escalation - Unpatched Kernel Exploit 6. PT-06: Data Exfiltration - Unmonitored Channel 7. PT-07: Supply Chain Compromise - Trusted Software Update 8. PT-08: Insider Threat - Malicious Administrator

See cards/hardening/core-deck/pentester-tactic-cards.md for full card text, plus 8 expansion tactics (PT-09 to PT-16) in advanced-tactics.md.

Asset Cards

Simple cards providing scenario context. Examples: - Email Server - Customer Database - Domain Controller - Web Application - Backup System - Developer Workstation

Game Materials Required

Physical Components: - One 20-sided die (d20) - Turn Tracker (paper or board, counts 1-12+) - Budget Tracker (shows 0-150+) - Reputation/Security Score Tracker (shows 0-100) - Uncontained Threats Tracker (shows 0-5) - Tokens or counters (for tracking upgrades, penalties)

Optional: - Score sheets (printable or paper) - Playbook tracking sheet - Stakeholder communication log (for Disaster Recovery)

Universal Game Mechanics

1. The d20 Roll System

When Used: Investigation, Defense Deployment, Negotiation, and similar actions that have uncertain outcomes.

How It Works: 1. Player announces action and parameters 2. Player rolls 1d20 (one 20-sided die) 3. Compare result to target number (usually 11+) plus modifiers 4. Success if: roll + modifiers ≥ target number

Example:

Action: Investigate email headers
Target: 11+
Roll: 7
Modifiers: +2 (technical justification) +1 (referenced Splunk)
Calculation: 7 + 2 + 1 = 10
Result: FAIL (10 < 11)

2. Budget System (Universal)

What is Budget? Abstract resource representing time, money, personnel, and tools. Spent to take actions, buy defenses, or conduct investigations.

Budget Allocation by Module: - Network Building: Start at 40-60 (by difficulty; see module rules) - Hardening: Start at 150 (or carry over from IR) - Incident Response: Start at 100 - Disaster Recovery: Start at 50 (emergency fund) - Forensics: Start at 75 - Audit & Compliance: Start at 100 (used only for optional remediation cards)

Budget Spending: - Investigate action: 5 Budget - Deploy Defense: 10/15/25 Budget (by tier) - Emergency Response (IR): 15 Budget (v2.2; was 25) - Active Breach Cost (IR, v2.2): -5 Budget at start of each turn while any chain card remains unrevealed - Harden Upgrade (Hardening): 5 Budget - Create Playbook (Hardening): 10 Budget - Crisis Action cards (DR): 5-20 Budget per card (ACTION-01 to ACTION-12; the free "Holding Statement" costs 0) - Ransom Decision (DR, ACTION-13): Pay 20 / Negotiate 5 / Refuse 0

Budget = 0: Team loses (cannot take further actions)

Exception (Disaster Recovery, v2.2): Budget floor is 0 and the free Holding Statement action remains available — DR is never lost by running out of Budget; DR's loss condition is any stakeholder trust reaching 0%.

3. Turn System (Universal)

Turns represent: Time passing in the game world (6 hours, 30 minutes, or abstract unit depending on module)

Turn Sequence: 1. Start of Turn: Penalties applied, trackers announced 2. Planning Phase: Team discusses strategy (2-3 min) 3. Action Phase: Execute chosen action, resolve rolls 4. End of Turn: Advance tracker, draw card, check events

3a. Variable Game Length System (v2.1 - New!)

Philosophy: In real incident response, some attacks move fast (hours), some take months. Fixed turn lengths feel unrealistic. This system adds realism without requiring complex calculations.

For Beginners & Quick Play: Default Formula

Default Formula: (Attack Chain Cards × 2) + 1

This gives attackers enough time to progress realistically while keeping games manageable:

How to Use Default Formula: 1. Choose number of threat cards in attack chain (3, 4, 5, or 6) 2. Apply formula: (Cards × 2) + 1 = Turn Count 3. Announce turn count to Blue Team 4. Play game normally with that turn limit

Example Setup:

"I've created a 4-card attack chain. That's (4 × 2) + 1 = 9 turns. You have 9 turns to detect all four threats. Go!"

For Advanced Players: Complexity Tiers (v2.1)

Advanced Threat Orchestrators can use a Tier + d4 system for more control and variability:

Step 1: Select Attack Complexity Tier

Step 2: Add Randomness (Optional)

Roll 1d4 for variation: - Roll 1: -1 turn (tight timeline) - Roll 2 or 3: ±0 turns (no change) - Roll 4: +1 turn (extended dwell time)

Final Turn Count = Tier Base + d4 Result

Example Advanced Setup:

"This is a TIER 2 attack (organized cybercriminals). Base is 8-10 turns. I'll roll d4 for variation... [rolls 4, +1 turn]. Final turn count: 9-11 turns."

Critical Game Integrity Rules (v2.1)

These rules protect game balance and prevent metagaming:

Rule 1: Accept Any Roll (Even If It Feels Wrong)

The Rule: Threat Orchestrators MUST accept the random result, even if it feels impossibly tight or loose.

Why: Real incident response is unpredictable. Sometimes attacks happen faster or slower than expected.

Example Scenarios: - TIER 3 attack (11-13 base) + d4 roll of 1 = 10-12 turns (tighter than expected, but realistic) - TIER 1 attack (5-7 base) + d4 roll of 4 = 6-8 turns (easier conditions, but acceptable)

When Chaos Feels Realistic: - Tight timeline: "The attacker worked faster than expected—they had prior knowledge" - Loose timeline: "The attacker was cautious, spending weeks in reconnaissance before striking"

Implementation: Lean into the randomness as realistic incident variability.

Rule 2: Players Cannot Question Tier Based on Turn Count

The Rule: Blue Team CANNOT deduce the attack tier from the announced turn count. They cannot ask "Is this TIER 2?" or "Is this TIER 4?" based on how many turns they have.

Why: Real incident response doesn't come with difficulty labels. Attackers don't advertise sophistication. Players should discover complexity through gameplay (attack chain complexity, defender evasion, tool sophistication, etc.).

What Players CAN Ask: - "What are the suspicious network events?" (leads to understanding threats) - "Can we analyze the malware?" (reveals attacker sophistication through findings) - "Why did this attack succeed?" (post-game discussion)

What Players CANNOT Ask: - "Is this a TIER 2 attack?" (deriving tier from turn count) - "This looks like a TIER 1 because we have 7 turns" (meta-gaming difficulty)

Implementation: Respond to difficulty questions by saying "Investigate and find out!" Players discover sophistication through evidence, not from turn counts.

Rule 3: TO Modifier Authority (Rare & Optional)

The Rule: ONLY after rolling d4, the Threat Orchestrator may apply an optional ±1 turn adjustment IF the rolled result feels genuinely unreasonable for the scenario.

When to Use (Rare): - Scenario setup is unusually complex (multiple attack vectors, coordination across systems) - Player group is new and needs slightly easier conditions - Real-world incident being taught had specific timeline constraints

When NOT to Use (Prefer Random): - "The roll feels unlucky" (accept the chaos) - "I want this exactly 10 turns" (let dice decide) - "The attack chain is long so it should take longer" (that's what TIER system handles)

Implementation: 1. Roll d4 normally 2. Announce rolled result 3. ONLY IF genuinely unreasonable, apply ±1 modifier and explain why 4. Document the override for consistency in future scenarios

Example Valid Use:

"TIER 2 base 8-10, rolled -1 = 7-9 turns. That's tight given we have 5-card attack chain, so I'm adding +1 modifier (explaining the discovery is methodical). Final: 8-10 turns."

Example Invalid Use:

"I rolled 8-10 but I want 10-12, so I'm adding +2." (NO - use the roll as-is)

Implementation Checklist

For Beginners (Use Default Formula): - [ ] Choose attack chain length (3, 4, 5, or 6 cards) - [ ] Calculate: (Cards × 2) + 1 - [ ] Announce turn count - [ ] Play

For Advanced (Use Tier + d4): - [ ] Select TIER (1, 2, 3, or 4) - [ ] Announce TIER basis (not the number, just why it's that complexity) - [ ] Roll d4 for variation (hidden or public, your choice) - [ ] Calculate final turn count - [ ] Apply Rule 3 modifier if genuinely needed (rare) - [ ] Announce final turn count WITHOUT revealing tier

Quick Reference Card

Default Formula: Turn Count = (Attack Cards × 2) + 1

Tier System: - TIER 1: 5-7 turns (simple) - TIER 2: 8-10 turns (standard) - TIER 3: 11-13 turns (advanced) - TIER 4: 14-16 turns (expert) - Add d4 roll: -1, 0, 0, or +1

Golden Rules: 1. Accept any roll (embrace chaos) 2. Never reveal tier to players 3. Modifier authority only when truly needed (rare)

4. Roll Modifiers (Universal)

All modules use the same modifier system for consistency:

+2 Bonus: Strong Technical Justification

Awarded when a player provides clear, specific reasoning for their action using real security concepts.

Examples: - "We're analyzing email headers in the mail gateway logs to identify the true sender IP and check it against threat intelligence feeds" - "We're deploying EDR on all endpoints because it can detect living-off-the-land techniques" - "We're querying our SIEM for scheduled task creation events because attackers use them for persistence"

Criteria: - References specific tools (Splunk, EDR, SIEM, etc.) - Explains methodology (why this approach works) - Shows understanding of the threat being addressed

+1 Bonus: Real Tools or Techniques Referenced

Awarded when player references actual security tools or real attack/defense techniques.

Examples: - "We'll use Wireshark to analyze the network traffic" - "We're checking for Mimikatz usage in memory" - "We're reviewing EDR telemetry" - "We're looking for this specific CVE exploitation pattern"

Criteria: - References real tools (Wireshark, EDR, Splunk, etc.) - References real techniques (MITRE ATT&CK, specific CVEs) - Shows awareness of how things actually work

5. Uncontained Threats Penalty (Incident Response Module)

When Applied: Incident Response module only, applied at START of each turn

How It Works: 1. When a threat card is revealed, add 1 to Uncontained Threats Tracker 2. At START of each turn, deduct 5 Budget per uncontained threat 3. When next card in chain is revealed, previous threat is auto-mitigated (-1 from tracker) 4. When Emergency Response action is used (15 Budget), remove a revealed threat (-1 from tracker)

Companion rule — Active Breach Cost (v2.2): while at least one chain card remains unrevealed, deduct an additional flat -5 Budget at the start of each turn. Hidden attackers cost money too.

Purpose: Creates urgency - dwell time costs money, whether you've found the attacker yet or not. Teaches real-world incident response costs.

Example (uncontained penalty only; Active Breach Cost also applies while cards remain hidden):

Turn 1: Phishing revealed → Uncontained Threats = 1
Turn 2: START → Deduct 5 Budget (95 remaining from 100)
Turn 3: Lateral Movement revealed → Phishing auto-mitigated (Uncontained = 1)
Turn 3: START → Deduct 5 Budget
Turn 4: Emergency Response on Lateral Movement (15 Budget) → Uncontained Threats = 0

Common Roles & Responsibilities

Threat Orchestrator (Facilitator)

Responsibilities: - Manage game state and track turns/budget - Describe scenarios and outcomes - Roll dice when action outcomes are uncertain - Guide the narrative

During Incident Response: - Create and manage hidden attack chain - Provide clues based on successful investigations - Control Uncontained Threats penalties - Be fair but challenging

During Other Modules: - Describe threat context and defenses - Draw Pentester Tactic cards (Hardening) - Manage timeline and deadlines (Disaster Recovery) - Guide debrief questions

Universal Tips: - Explain why actions succeed or fail - Ask clarifying questions about player strategy - Balance challenge with learning - Provide constructive feedback

Blue Team (Defenders)

Responsibilities: - Discuss strategy as a team - Choose one action per turn - Justify your decisions (gain +2 modifier) - Manage budget carefully - Learn from success and failure

Modifier Stacking Rules

Key Rule: Modifiers are additive and can stack.

Example (Hardening Module, canonical formula — v2.2):

Pentester Tactic: PT-02 Living-off-the-Land (DC 13)

Defense roll = d20
  + printed bonus for the ONE defense chosen (D-08 EDR vs PT-02: +3)
  + hardening upgrades on that defense (+2 each; one upgrade: +2)
  + relevant playbook (+3)

Team rolls 8:
8 + 3 (EDR) + 2 (upgrade) + 3 (playbook) = 16 ≥ 13 = SUCCESS

Only the single chosen defense's printed bonus applies — deployed defenses do not stack with each other against one tactic.

Difficulty & Scaling

By Attack Chain Length

By Starting Budget

By Turn Limit

Note (v2.2): Incident Response derives its turn limit from the Variable Game Length formula — (Attack Chain Cards × 2) + 1 → 7/9/11 turns (see §3a). The table above is for modules with educator-set limits.

Educational Objectives

By Module

By Game Mechanic

Cooperative vs. Competitive Play

Cooperative Mode

• Single Blue Team vs. challenges
• Team wins or loses together
• Encourages discussion and consensus
• Better for learning
• Better for mixed experience levels

Competitive Mode

• Multiple Blue Teams solving same challenge
• First to achieve objective wins
• Creates urgency and engagement
• Better for tournaments
• Better for same-level players

Implementation: - Same setup for all teams - Teams cannot share information (Incident Response) - Score comparison determines winner (Hardening) - Reputation comparison (Disaster Recovery)

Debrief & Reflection (Universal)

Every module should include a 5-15 minute debrief with three sections:

Part 1: What Happened?

• Summarize the scenario and outcome
• Highlight key decisions
• Acknowledge successes and failures

Part 2: Why Did That Happen?

• Discuss the mechanisms (why the rule works that way)
• Connect to real-world security
• Explain attacker/defender motivation

Part 3: What Would You Do Differently?

• Reflect on strategy
• Discuss trade-offs
• Plan for next playthrough

Tips for Threat Orchestrators (Universal)

Before the Game

1. Read the module rules completely - Know what's coming
2. Prepare your scenario - Pre-build attack chain or threat context
3. Organize materials - Sort cards, prepare trackers
4. Know your balancing points - Be ready to adjust difficulty if needed
5. Practice reading clues - Deliver them dramatically!

During Gameplay

1. Be clear about costs - Announce Budget before action
2. Resolve rolls immediately - Announce target, let player roll, resolve
3. Ask clarifying questions - "Why are you investigating email headers?"
4. Be fair but challenging - Give honest difficulty, don't fudge rolls
5. Narrate outcomes - Describe what happens, not just success/failure
6. Manage pacing - Keep turns moving (2-3 min discussion max)
7. Track penalties accurately - Keep budget, turn, and threat trackers visible

Balancing Difficulty

Too Easy Signs: - Team reveals all cards/achieves goal with 40+ budget remaining - No failed rolls - No meaningful decisions required - Team is bored

Too Hard Signs: - Team is stuck/making no progress after 5 turns - Multiple consecutive failed rolls - Team frustrated rather than challenged - No learning happening

Adjustment Options: - Easier: Provide better clues, more starting budget, fewer tactics - Harder: Less specific clues, lower budget, more tactics - Faster: Shorter turn limits, simpler scenarios - Slower: More turns, more complex scenarios

Card Reference

For complete card descriptions, see: - Base Threat & Defense Cards cards/incident-response/core-deck/threat-defense-cards.md - Expansion Threats cards/incident-response/expansion-deck/advanced-threats.md - Expansion Defenses cards/incident-response/expansion-deck/advanced-defenses.md - All decks indexed cards/CARD_REFERENCE.md

Module-Specific Rules

For complete rules on each module:

• Network Building Module: module-network-building.md
• Hardening Module: module-hardening.md
• Incident Response Module: module-incident-response.md
• Disaster Recovery Module: module-disaster-recovery.md
• Forensics Module: module-forensics.md
• Audit & Compliance Module: module-audit-compliance.md

Quick Reference: Universal Mechanics

d20 Roll System

• Base target: 11+ (varies by action)
• +2 modifier: Strong technical justification
• +1 modifier: Real tools/techniques referenced
• Modifiers stack: All bonuses add together

Budget System

• Spent on: Actions, defenses, investigations
• Cannot go below: 0 (team loses)
• Tracked per turn: Budget available announced at start of turn

Turn System

• Sequence: Start → Planning → Action → End
• Planning: 2-3 minutes discussion
• End of turn: Advance tracker, draw card, apply effects

Penalties & Bonuses

• Uncontained Threats: -5 Budget per revealed-uncontained threat per turn (IR only)
• Active Breach Cost (v2.2): -5 Budget per turn while any chain card is unrevealed (IR only)
• Pentester Tactics: Add difficulty/modify actions (Hardening)
• Reputation: Track 0-100, affects outcome (DR)

Continuing to Next Steps

For your first game: 1. Choose a module from Module Combinations 2. Read the module-specific rules 3. Read the standalone setup guide 4. Prepare your scenario 5. Play!

For multiple modules: 1. Refer to Module Combinations for recommended sequences 2. Refer to FRAMEWORK.md for modifier generation procedures 3. Play first module, generate modifiers for next 4. Continue as desired

Need Help?

• Want to combine modules? See Module Combinations
• Understanding module flexibility? See FRAMEWORK.md
• Specific module rules? See module-*.md files
• How to play solo? See standalone guide for your chosen module

Incident Zero: Core Rules & Mechanics v2.1 - Balanced & Refined Edition Universal rules for all modules

docs/rules/module-network-building.md

Network Building Module: Rules & Mechanics

Version: 2.2 - Playtest Edition Last Updated: July 2026

Module Overview

The Network Building Module teaches players how to design IT infrastructure under budget constraints, business requirements, and trade-off decisions. This is a pre-game module designed to create the network context for other modules (particularly Incident Response, Hardening, and Disaster Recovery).

Key Concept: Architecture decisions create vulnerabilities that are discovered during investigations and audits. Bad decisions made here cost more money later.

Module Teaches: - Primary: Network architecture, infrastructure design, security trade-offs - Secondary: Budget prioritization, business vs. security balance, intentional/accidental vulnerabilities

Integration Point: - Network Building can be played standalone OR as setup for Incident Response/Hardening/Disaster Recovery modules - When combined with other modules, the network design created here becomes the context for those modules (see module-combinations.md)

Module Setup (15-20 minutes)

1. Choose Difficulty Level

Budget represents: Time, money, and resources for infrastructure design

(v2.2) More budget = easier. Beginner gets the most budget; Advanced gets the least.

2. Starting Scenario

Narrative Framing:

"Your organization is building or rebuilding its IT infrastructure. You have limited budget and must support 500 employees with core business functions. Every decision will affect your security posture when this network is tested. Make smart trade-offs."

Key Point: Teams don't know yet which decisions will matter most. Some budget is "wasted" on nice-to-haves, some on security that (hopefully) won't be needed.

3. Available Network Components

Components fall into 5 categories:

Category 1: Server Types

Capacity Rules: - Each server can host a certain number of services (shown in Capacity column) - Services = business functions (email, web, database, identity, file storage, etc.) - Can OVERLOAD a server (put more services than capacity allows) to save budget, but creates risk

Category 2: Security Devices

Category 3: Network Architecture Decisions

How servers are logically organized and connected:

Architecture decisions are NON-NEGOTIABLE - teams must pick one to organize their network.

Category 4: Business Requirements (v2.2)

Teams MUST satisfy every Required item by end of game. Recommended items are not mandatory, but skipping one is recorded as a gap (and costs points at scoring).

Key Rule: Required items are fixed. Teams must find places to host them, even if it means cloud-hosting or overloading servers.

Affordability Check (v2.2) — the Required list fits every difficulty:

• Dedicated servers for every Required item: Email 8 + Web 7 + Database 10 + Domain Controller 12 + Backup 9 = 46 → affordable at Standard (50, leaves 4) and Beginner (60, leaves 14)
• Advanced (40): cloud-host Email + Web on one Cloud Workload (4): 4 + 10 + 12 + 9 = 35 (leaves 5). Hosting the Database on a second Cloud Workload drops it to 29 (leaves 11) — cheap, but every substitution is a recorded gap
• File Storage can ride the Domain Controller's spare capacity slot (free) or overload any server (+1 Budget)

Category 5: Hosting Model

Physical location of infrastructure:

Gameplay Loop (15-20 minutes)

Turn Structure (v2.2)

Teams take 5 "Build Turns" (~3-4 minutes each to discuss and decide).

Each turn is a design-review phase (v2.2): the team may take any number of actions — place as many components as they can afford — before ending the turn. Turns are not a one-purchase limit; they are checkpoints where the design gets stress-tested.

Between turns, the Threat Orchestrator reveals a development: draw one Operational Event or Business Requirement card from the standalone decks (cards/network-building/standalone/), or narrate one (a stakeholder demand, a vendor issue, a budget change). This gives teams a reason to revisit the design each turn.

Available actions:

Action 1: Place a Server

Cost: Server cost (3-12 Budget) Effect: Add server to infrastructure

How It Works: 1. Choose a server card 2. Decide which business services it will host 3. Pay the cost 4. Track remaining budget

Example: "We're placing a Domain Controller on-premises (12 Budget). It will host user identity, with a spare capacity slot for file storage. Remaining budget: 38."

Constraints: - Duplicates allowed (v2.2): you may deploy more than one server of the same type; each copy costs full price - Can't host a required service on a server that doesn't exist - Can OVERLOAD servers (see Overload Mechanic below)

Action 2: Add Security Device

Cost: Device cost (6-15 Budget) Effect: Add network defense or monitoring

How It Works: 1. Choose a security device card 2. Describe which servers/zones it protects 3. Pay the cost 4. Track placement on network diagram

Example Turn: "We're deploying a Firewall between our DMZ and Internal network (12 Budget). This blocks unauthorized traffic between zones. Remaining budget: 26."

Action 3: Implement Network Architecture

Cost: Architecture cost (0-12 Budget) Effect: Determine how servers logically connect

How It Works: 1. Choose one architecture type (only ONE per game) 2. Describe zone organization 3. Pay the cost 4. Document on network diagram

Example Turn: "We're implementing a Segmented Network with 3 zones (5 Budget): - DMZ: Email and Web servers (internet-facing) - Internal: File servers and user workstations - Sensitive: Database and Domain Controller Remaining budget: 21."

Action 4: Choose Hosting Model

Cost: Usually 0 (some cloud strategies cost money) Effect: Determines where infrastructure physically lives

How It Works: 1. Decide on hosting strategy 2. Apply to appropriate servers 3. Document on infrastructure card 4. Pay if cloud-specific (usually free)

Example Turn: "We're hosting our email and web servers on AWS (0 cost). Domain Controller stays on-premises. This reduces on-prem complexity but adds cloud management responsibility."

Action 5: End Turn / Pass

Cost: 0 Effect: Take no further actions this turn; preserve budget

Use When: Satisfied with current design or holding budget in reserve for surprises

The Overload Mechanic

Strategic Tradeoff: Cost vs. Risk

Problem: Limited budget + mandatory services = imperfect solutions

Solution: Overload servers (put more services on one server than intended)

How It Works (v2.2): - If a server has capacity for 2 services, you can put 3+ on it - Cost: +1 Budget per extra service beyond capacity (paid when the service is added) - Benefit: Still far cheaper than buying another server - Risk: Overloaded server is harder to isolate; compromise affects multiple services

Example Scenario: "Budget remaining: 5. Still need to host Development Services.

Option A: Buy Dev Server for 5 (leaves 0 budget) Option B: Put Dev on our File Server, which already hosts File Storage and Email Backup (2/2). Overload by 1: pay 1 Budget (leaves 4)

We choose B: File Server becomes (File Storage, Email Backup, Dev Services — OVERLOADED 3/2)"

Consequences (Discovered Later): - Overloaded servers are easier to pivot from (when other modules investigate) - If one service is compromised, ALL services on that server are at risk - Recovery is harder (can't isolate just the compromised service)

Vulnerability Gaps (Intentional and Accidental)

How Budget Constraints Create Gaps

Teams inevitably leave security gaps:

Key Insight: These gaps are discovered when other modules test the network (Audit, Incident Response, Disaster Recovery).

Final Infrastructure Summary

After Building Complete

Teams create an Infrastructure Summary Card:

YOUR NETWORK ARCHITECTURE (Standard, 50 Budget)

SERVERS DEPLOYED:
- Cloud Workload (AWS) - Hosts: Email + Web (2/2, cloud-hosted)
- Database Server (On-Prem) - Hosts: Customer Database
- Domain Controller (On-Prem) - Hosts: Identity, File Storage,
  Dev Services (OVERLOADED 3/2, +1 Budget paid)
- Backup Server (On-Prem, isolated) - Hosts: Backups / DR

ARCHITECTURE: Segmented (3 zones)
- DMZ: (cloud workload fronts the internet)
- Internal: Users
- Sensitive: Database, Domain Controller, Backup Server

SECURITY DEVICES:
- Email Gateway (incoming mail)
- NO Firewall, NO IDS/SIEM, NO VPN Gateway, NO Honeypot

HOSTING: Hybrid (cloud front end, on-prem crown jewels)

BUDGET SPENT: 47/50 (3 remaining)
- Cloud Workload 4 + Database 10 + Domain Controller 12 + Backup 9
  + Segmented Architecture 5 + Email Gateway 6 + Overload 1 = 47

IDENTIFIED GAPS (for other modules):
- Overloaded Domain Controller (identity + files + dev on one box)
- No IDS/SIEM (attacks undetected; investigations harder)
- No VPN Gateway (remote workers use risky workarounds)
- Email and Web share one cloud workload (single point of failure)

Scoring & Network Assessment

Infrastructure Quality Score (v2.2)

After building, teams receive a score reflecting their design choices:

Maximum: 40 points. The reserve bonus rewards smart utilization — meet the requirements and keep a small cushion; hoarding budget scores nothing.

Example Scoring (the sample network above, Standard 50): - All 5 Required items satisfied: +10 - Segmentation implemented: +10 - No IDS/IPS/SIEM: 0 - Backup Server deployed: +5 - No redundancy: 0 - 3 Budget remaining: +2 - Total: 27 points — Good design

Interpretation Tiers (v2.2): - 32-40 points: Enterprise-grade design; comprehensive protection - 22-31 points: Good design; most critical gaps covered - 12-21 points: Adequate design; some gaps remain - Below 12 points: High risk; many gaps; future modules will be challenging

Reachability check: at Beginner (60), a team can score the full 40 — e.g., Cloud Workload 4 (Email+Web) + Database 10 + Domain Controller 12 (Identity + File) + Backup 9 + Segmented 5 + IDS 10 + second Cloud Workload 4 (redundant web) = 54 spent, 6 remaining → 10+10+5+5+5+5 = 40.

Gap Registry

For use in Incident Response and Audit modules: - List all identified gaps - Note severity (CRITICAL, HIGH, MEDIUM, LOW) - These gaps become modifiers when other modules test the network

Integration with Other Modules

Using Network Building as Context

When Network Building leads to other modules:

→ Incident Response Module: - Network design determines which attacks are possible - Overloaded servers make lateral movement easier - Missing IDS/SIEM makes investigation harder

→ Hardening Module: - Teams can see which network gaps they should fix - Fixing a gap they identified = +2 bonus to that defense

→ Disaster Recovery Module: - Network gaps increase crisis budget costs - Overloaded servers = more data compromised - No backup = no recovery option

→ Audit & Compliance Module: - Pre-built network is audited against NIST/CIS - Audit findings highlight network gaps - Findings become modifiers in Incident Response

Tips for Threat Orchestrators

Before the Game

1. Clarify business requirements - Teams must provide email, web, database, identity, and backup (file storage, dev, and VPN are recommended)
2. Show budget constraints - 50 Budget is tight; teams will make difficult choices
3. Emphasize consequences - Choices made here affect all future modules
4. Prepare Infrastructure Card template - For documenting final network

During Gameplay

1. Ask clarifying questions - "Why are you putting those two services together?"
2. Point out overloads - Track when servers exceed capacity
3. Keep budget visible - Announce remaining budget after each action
4. Suggest trade-offs - Help teams think through cost-benefit decisions

After Building Complete

1. Document gaps - List all identified vulnerabilities
2. Score the network - Tell them how good/risky their design is
3. Prepare for next module - If continuing to Audit or IR, this network is the context
4. Celebrate trade-offs - "You saved budget on IPS, but web exploits will be riskier"

Sample Scenarios

Scenario 1: "Startup Network" (Advanced, 40 Budget)

Constraint: Very limited budget; must make hard choices

Starting Narrative: "You're a startup with limited funding. You need to build infrastructure but can't afford everything. Choose wisely."

Likely Outcome: - Flat network (save 5) - Few security devices - Multiple overloaded servers - High vulnerability; good learning about consequences

Scenario 2: "Mid-Market Expansion" (Standard, 50 Budget)

Constraint: Moderate budget; can afford some security

Starting Narrative: "Your organization is growing. You have some budget for infrastructure but not unlimited. Balance growth with security."

Likely Outcome: - Segmented network - Basic security devices (firewall, email gateway, IDS or SIEM) - Some overloading but manageable - Moderate vulnerability; balanced design

Scenario 3: "Enterprise Hardening" (Beginner, 60 Budget)

Constraint: Good budget; comprehensive design possible

Starting Narrative: "You're rebuilding infrastructure with sufficient budget. Design for security AND resilience."

Likely Outcome: - Segmented or isolated network - Multiple security devices - Minimal overloading - Good security posture; few gaps

Extensions & Variations

Variation 1: Regulatory Compliance

Add compliance requirements: - NIST CSF, CIS Controls, PCI-DSS, HIPAA - Teams must choose devices that satisfy compliance - Some devices count toward multiple requirements

Variation 2: Business Department Negotiation

Assign roles: - Finance wants cheap solutions - Operations wants reliability - Security wants defense-in-depth - Teams must negotiate trade-offs

Variation 3: Network Redesign

After Incident Response or Disaster Recovery: - Teams rebuild network based on lessons learned - Compare new design to original - Measure improvement

Quick Reference: Component Costs

Need Help?

• Questions about universal rules? See Core Rules
• Want to combine modules? See Module Combinations
• How does this integrate with Incident Response? See module-incident-response.md
• How does this integrate with Audit & Compliance? See module-audit-compliance.md
• Standalone play guide? See Standalone Play Guide

v2.2 Playtest Edition Changes

Summary of rule changes for playtesters (all labelled "(v2.2)" in the text above):

1. Difficulty direction fixed: more budget = easier. Beginner 60 / Standard 50 / Advanced 40 (previously Beginner had the least budget).
2. Action economy fixed: each Build Turn, teams may place any number of components they can afford. Turns are design-review checkpoints; between turns the TO reveals an Operational Event or Business Requirement (see the standalone decks in cards/network-building/standalone/). Previously 5 turns × 1 action made the mandatory requirements physically impossible to place.
3. Requirement list rebalanced: Required = Email, Web, Database, Identity, Disaster Recovery (Backup). Recommended = File Storage, Development, Remote Work VPN. Backup is now Required (missing backup = automatic FAIL on that requirement, not an instant game loss). Development is Recommended and may be hosted by overloading. Email/Web/Database may be cloud-hosted on Cloud Workloads, which keeps the Required list affordable even at Advanced (40): dedicated build = 46; cloud-assisted builds = 35 or 29.
4. Overload now costs +1 Budget per extra service beyond capacity (was free). Matches the standalone game.
5. Duplication rule: multiple servers of the same type are allowed; each costs full price (replaces the old vacuous "unless you have the budget for both" wording).
6. Scoring rescaled: new Requirements metric (+2 each, max 10), Contingency Reserve bonus (+5 for finishing with 5-15 Budget — smart utilization, not hoarding), and tiers rescaled to reachable bands (32-40 / 22-31 / 12-21 / <12). Max score 40 is verified reachable at Beginner.
7. Terminology unified: "VPN Gateway" (was VPN Concentrator) and "Backup Server" (was Backup System) everywhere.
8. Examples corrected: the sample Infrastructure Summary and all in-text budget arithmetic now add up.

Network Building Module - Rules & Mechanics Part of Incident Zero, a modular cybersecurity board game v2.2 - Playtest Edition

docs/standalone-games/network-building.md

Incident Zero: Network Building Standalone Mini-Game

Infrastructure Design Competition

Version: 2.2 - Playtest Edition Last Updated: July 2026

Overview

Network Building Standalone is a 30-45 minute competitive resource management game where teams design IT infrastructure under budget constraints with random business requirements and operational challenges.

Core Concept: - Budget: Limited funding (40-60 Network Budget tokens by difficulty; 50 standard) - Requirements: Random business needs forcing tough trade-offs - Randomness: Equipment failures, budget surprises, requirement changes - Scoring: Multi-dimensional (security, budget efficiency, capability, resilience) - Winner: Team with highest final score

Best For: - Teaching infrastructure trade-offs - Understanding security budget constraints - Decision-making under uncertainty - Standalone 30-45 minute session - Competitive team play (2-4 teams)

Win Condition & Game Length

Turns & Time

Game Duration: 5-7 turns (by difficulty) × 4-5 minutes per turn = 20-30 minutes gameplay - Setup: 5 minutes (explain rules, distribute materials) - Gameplay: 20-30 minutes - Scoring & Debrief: 5-10 minutes - Total: 30-45 minutes

Each turn represents ~1 quarter of the fiscal year: - Reveal a Business Requirement (what does the business need this quarter?) - Reveal an Operational Event (failure, budget change, attack, opportunity) - Team deploys components, handles the event, or passes

Game Components

Network Budget Tokens

• Starting Budget: 50 Network Budget (Standard; see Difficulty Levels)
• Costs: Servers (3-12), Security Devices (6-15), Architecture (0-12)
• Tokens: Physical tokens, spreadsheet, or tracking sheet

Component Cards

SERVER CARDS (print from cards/network-building/core-deck/server-cards.md)

Each has: Type, Cost, Capacity, Security Profile

┌──────────────────────┐
│ EMAIL SERVER         │
│ Cost: 8              │
│ Capacity: 1 service  │
│ Security: Low        │
│ (Phishing target)    │
└──────────────────────┘

Server Types Available: - Email Server (8 Budget, 1 capacity, Low security) - Web Server (7 Budget, 1 capacity, Low security) - Database Server (10 Budget, 1 capacity, Medium security) - File Server (6 Budget, 2 capacity, Low security) - Domain Controller (12 Budget, 2 capacity, Medium security) - Development Server (5 Budget, 3 capacity, Low security) - Backup Server (9 Budget, 1 capacity, High security) - Cloud Workload (4 Budget, 2 capacity, Medium security) - Legacy System (3 Budget, 1 capacity, Very Low security) - Honeypot Decoy (7 Budget, 1 capacity, Medium security)

Overload rule: a server may host more services than its capacity for +1 Budget per extra service — but overloaded servers are a recorded risk (see Variations, now a standard rule).

SECURITY DEVICE CARDS (print from cards/network-building/core-deck/security-device-cards.md)

Each has: Type, Cost, Benefit

┌──────────────────────┐
│ FIREWALL             │
│ Cost: 12             │
│ Blocks traffic       │
│ between network      │
│ zones (segmentation) │
└──────────────────────┘

Security Device Types Available (v2.2 — benefits stated in plain language; the Scoring section says what each counts as): - Firewall (12 Budget) — blocks traffic between network zones; counts as Firewall and toward segmentation - IDS (10 Budget) — spots attacks in progress; counts as detection - IPS (14 Budget) — blocks known exploits in real time; counts as detection - Email Gateway (6 Budget) — filters phishing and email malware - WAF (11 Budget) — protects web applications from injection/XSS attacks - SIEM (15 Budget) — central logging and alerting; counts as detection, helps audits - Network Segmentation Switch (10 Budget) — isolates network zones; counts as segmentation - VPN Gateway (9 Budget) — secure remote access for staff - Load Balancer (8 Budget) — spreads load across duplicated services; counts as redundancy - Honeypot Network (8 Budget) — decoy segment that exposes intruders; counts as detection

BUSINESS REQUIREMENT CARDS (print from cards/network-building/standalone/business-requirement-cards.md)

20 cards (REQ-01 to REQ-20) of random quarterly business needs. Each names the requirement, what satisfies it, and the score impact.

┌──────────────────────┐
│ BUSINESS REQUIREMENT │
├──────────────────────┤
│ REQ-01: "New Product │
│ Launch Website"      │
│                      │
│ Satisfied by: Web    │
│ Server or cloud web  │
│                      │
│ Missed: -5 points    │
└──────────────────────┘

OPERATIONAL EVENT CARDS (print from cards/network-building/standalone/operational-event-cards.md)

16 cards (EVT-01 to EVT-16) of random incidents, opportunities, and challenges. Each states its effect and which designs mitigate it.

┌──────────────────────┐
│ OPERATIONAL EVENT    │
├──────────────────────┤
│ EVT-01: "Email       │
│ Server Failure"      │
│                      │
│ Pay 5 Budget to fix  │
│ OR -10 points        │
│                      │
│ Mitigated by:        │
│ redundant/cloud email│
└──────────────────────┘

Game Setup (5 minutes)

1. Explain Scoring System

Final Score = Security Score + Budget Score + Capability Score + Resilience Score − Requirement/Event penalties (+ bonuses)

Teams win by maximizing total score, not just saving budget.

2. Distribute Starting Materials

Each Team Receives: - Starting Budget: 50 Network Budget tokens (Standard difficulty) - Infrastructure Summary Sheet (to track what they've built) - Score Tracking Sheet - Network Diagram Worksheet (optional, for visualization)

3. Create Card Decks

Shuffle and place face-down: - Business Requirement deck (all 20 cards; 1 drawn per turn) - Operational Event deck (all 16 cards; 1 drawn per turn)

4. Brief Teams

**"You're a CIO designing your organization's IT infrastructure for the next 18 months. You have limited budget ($50K, represented as 50 tokens). Each quarter brings new business requirements and operational challenges. You must balance: - Getting the work done (business requirements) - Keeping things secure (security devices) - Managing money (budget efficiency) - Surviving incidents (resilience features)

After 6 quarters (turns), we'll score your infrastructure. Highest score wins."**

Turn Structure (4-5 minutes per turn)

Each Turn Has 4 Phases

Phase 1: Reveal Business Requirement (1 minute)

Threat Orchestrator flips top Business Requirement Card:

"It's Q2. The executive team wants to acquire a customer database company. You need to integrate their 2 million customer records into your infrastructure. You MUST have a functioning Database Server by end of Q2 or you lose 10 points (deal falls through)."

Team Notes: - What service is needed? - When is the deadline? (end of this turn unless the card says otherwise) - What's the penalty if you skip? (points deduction)

Teams Discuss: Do we have it? If not, how do we get it?

Phase 2: Reveal Operational Event (1 minute)

Threat Orchestrator flips top Operational Event Card:

"OPERATIONAL EVENT: Your Email Server just failed. It's been down for 2 hours. You can: - Option A: Pay 5 budget for emergency repair (get email back online) - Option B: Skip repair (email stays down all quarter) - lose 10 points (users upset, productivity down) - Option C: Use this as an excuse to upgrade (replace with new server, normal cost)"

Teams Decide: How to handle the incident?

Phase 3: Team Actions (2-3 minutes) (v2.2)

Teams may take ANY NUMBER of the following actions, in any order, limited only by budget (previously one action per turn):

Action A: Deploy a Server

• Select a Server Card from available servers
• Pay the Cost (from budget)
• Mark Capacity on infrastructure sheet (overloading costs +1 Budget per extra service)
• Consequence: Servers stay deployed (can't remove them)
• Duplicates allowed: each copy costs full price

Example: "We're deploying a Database Server on-premises. Cost: 10 budget. Remaining: 40 budget. This satisfies the Q2 acquisition requirement. No penalty!"

Action B: Deploy a Security Device

• Select a Security Device Card
• Pay the Cost
• Note the Benefit (what it protects and what it counts as for scoring)
• Can be deployed multiple times (multiple firewalls, IDS on different segments, etc.)

Example: "We're deploying an IDS on our internal network. Cost: 10 budget. Remaining: 30 budget. That gives us detection — if a ransomware or insider event comes up, we're covered."

Action C: Handle Operational Event

• Select the event option (fix it, skip it, upgrade it)
• Deduct cost from budget
• Update score (penalties if skipped)

Example: "Email Server failed. We're paying 5 budget for emergency repair. That lets us avoid the -10 penalty. Remaining: 25 budget."

Action D: Pass

• Cost: 0
• Effect: End the turn without (further) deployments
• Use When: Budget is low OR you're satisfied with current design OR you're holding a reserve for surprises
• Note: You still suffer any requirement penalties or event consequences

Phase 4: End of Turn Accounting (30 seconds)

Update Trackers: - Subtract budget spent - Mark servers/devices deployed - Apply any penalties from unmet requirements - Prepare for next turn

Next Turn Begins

Scoring System

Scoring Dimensions

Final Score = Security + Budget + Capability + Resilience − requirement/event penalties (+ bonuses)

Requirement and event penalties/bonuses (from the cards) are tracked as they happen and applied to the final total. Dimension scores can go negative.

1. SECURITY SCORE (0-30 points)

Measures defensive capability against attacks

Maximum Security Score: 30 points (5+5+4+4+3+3+3+3 = 30)

Examples: - Only Email Gateway: 3 points (basic phishing defense, weak) - IDS + SIEM + Email Gateway: 13 points (good detection) - Full suite (IDS + SIEM + Firewall + Backup + Email Gateway + WAF + Honeypot + Segmentation): 30 points (enterprise-grade, but expensive)

2. BUDGET SCORE (0-20 points) (v2.2)

Rewards smart utilization: meeting the business's needs within budget while keeping a small contingency reserve. Hoarding budget is NOT rewarded — an unspent token did no work.

Budget Remaining at Game End → Points:

Anti-hoarding check: if the team missed 2 or more Business Requirements during the game, halve their Budget Score (round down). Saving money by failing the business is not efficiency.

Examples: - Spent 42, left 8: 20 points (met needs, kept a reserve) - Spent 46, left 4: 15 points (all-in; one bad event from trouble) - Spent 20, left 30: 5 points (a pile of tokens and a network full of gaps)

3. CAPABILITY SCORE (0-25 points)

Does infrastructure meet business needs?

Maximum Capability Score: 25 points (3+3+4+2+3+2+3+2+2+1 = 25)

Penalties for Missing Key Services: - No Email service: -5 (business can't communicate) - No Database service: -10 (core data has no home) - No Domain Controller: -3 (no central identity) - No VPN Gateway (only if a remote-work requirement card was drawn): -3

(Ransomware consequences for missing backups come from the event cards themselves — see EVT-11.)

Examples: - Email, Web, Database, File, Domain Controller, Backup: 3+3+4+2+3+3 = 18 points (good) - The same plus VPN Gateway and a Honeypot: 18+2+1 = 21 points (excellent) - Email, Web, File, Domain, Backup but NO Database: 3+3+2+3+3 = 14, minus 10 = 4 points (the penalty bites)

4. RESILIENCE SCORE (0-25 points)

Ability to survive and recover from failures

Resilience Factors:

Maximum Resilience Score: 25 points (8+7+5+3+2 = 25)

Penalties for Vulnerabilities (v2.2): - No Backup Server: -10 (one disaster from catastrophe) - Single point of failure (all critical services on one server): -5 - No detection capability: -3 - Flat network (no segmentation): -2

Examples: - Backup + Detection + Segmentation + Redundancy: 8+7+3+5, +2 recovery plan = 25 points (maximum; very resilient) - Backup + Detection, flat network, no redundancy: 8+7+2−2 = 15 points (adequate) - No backup, no detection, flat network: −10−3−2 = −15 points (high risk; yes, scores go negative)

Final Scoring Example

Team A's Infrastructure (resilience-first)

Built (total 46 of 50; 4 remaining): - Email Server (8): handles email - Web Server (7): public website - Database Server (10): customer data - File Server (6): internal files - Backup Server (9): disaster recovery - Email Gateway (6): phishing defense

Check: 8+7+10+6+9+6 = 46 ✓. No Domain Controller (too expensive; skipped for budget). Flat network.

Scoring Team A:

Security Score: - Email Gateway: +3 - Backup Server: +4 - No IDS/IPS/SIEM/Firewall/WAF/Honeypot/Segmentation: 0 - Total: 7 points

Budget Score: - 4 budget remaining → 1-4 band - Total: 15 points

Capability Score: - Email +3, Web +3, Database +4, File +2, Backup +3 = 15 - No Domain Controller: −3 - Total: 12 points

Resilience Score: - Backup Server: +8 - No detection: −3 - Flat network: −2 - Total: 3 points

Team A Final Score: 7 + 15 + 12 + 3 = 37 points

Team B's Infrastructure (security-first, no backup)

Built (total 47 of 50; 3 remaining): - Email Server (8) - Web Server (7) - Database Server (10) - Domain Controller (12) - IDS (10)

Check: 8+7+10+12+10 = 47 ✓. No Backup Server (sacrificed for detection). Flat network.

Scoring Team B:

Security Score: - IDS: +5 - Total: 5 points

Budget Score: - 3 left → 1-4 band - Total: 15 points

Capability Score: - Email +3, Web +3, Database +4, Domain Controller +3 = 13 - Total: 13 points

Resilience Score: - Detection: +7 - No Backup Server: −10 - Flat network: −2 - Total: −5 points (negative!)

Team B Final Score: 5 + 15 + 13 − 5 = 28 points

RESULT: Team A (37) beats Team B (28)

Lesson: Having Backup is critical for resilience, even if it means fewer security devices.

Competitive Play (2-4 Teams)

Setup for Multiple Teams

Each team: - Separate budget (50 tokens each at Standard) - Separate infrastructure tracking sheet - Separate score tracker

Simultaneous Play: - All teams reveal the same requirement and event at the same time - Teams take turns choosing actions (round-robin) OR all teams act simultaneously - Simultaneous is faster; rotating turns allows player agency

Scoreboard

Track all teams' scores throughout game (illustrative):

Winner: Team with highest total score after the final turn

Tie-Breaking

If two teams tie: 1. First tiebreaker: Security Score (defense is critical) 2. Second tiebreaker: Resilience Score (ability to survive matters) 3. Third tiebreaker: Capability Score (business requirement fulfillment)

Random Elements & Replayability

Requirement & Event Card Variability

Each game is different because:

1. Card Order Randomized: Shuffle both decks each game — a 5-7 turn game uses only 5-7 of the 20 requirements and 16 events
2. Card Selection: The Threat Orchestrator may curate the decks (see difficulty options on the card files)
3. Consequence Ordering: Early disasters force different choices than late surprises

Example Game Flow Variations:

Game 1 (Tough Start): - Turn 1: Ransomware wave (REQ-12) → Must buy Backup + Detection early - Turn 2: Budget cut (EVT-05) → Can't afford nice devices - Turn 3: M&A integration (REQ-08) → Need more capacity - Result: Teams forced into defensive posture

Game 2 (Growth-Focused): - Turn 1: Product launch (REQ-01) → Need Web Server - Turn 2: Data acquisition (REQ-02) → Need Database - Turn 3: Emergency funds (EVT-06) → +10 budget! - Result: Teams build bigger, more capable infrastructure

Difficulty Levels (v2.2 — more budget = easier)

Beginner Mode (Generous): - Starting Budget: 60 - Kind decks (remove EVT-11 and REQ-12 before shuffling) - Turn Limit: 7 (extra time)

Standard Mode: - Starting Budget: 50 - Random card draws - Turn Limit: 6

Advanced Mode (Challenging): - Starting Budget: 40 (tight budget) - Harsh decks (remove EVT-06, EVT-07, EVT-16 — fewer breaks) - Requirement penalties doubled - Turn Limit: 5

Example Full Game Walkthrough (6 Turns, Standard 50)

TURN 1

Phase 1: Business Requirement TO flips card: "New Product Launch Website — need modern web server capability. If missing by end of Q1: -5 points."

Phase 2: Operational Event TO flips card: "Emergency Funds! A surprise rebate arrives. +10 Budget (one time)."

Budget update: 50 + 10 = 60

Phase 3: Team Actions "We're deploying a Web Server to meet the launch requirement. Cost: 7 budget. Remaining: 53. We know we'll need a backup server eventually — holding the rest for now."

Phase 4: End of Turn - Infrastructure: Web Server - Budget: 53

TURN 2

Phase 1: Business Requirement "Customer Data Acquisition — must have a functioning Database by end of Q2 or lose 10 points."

Phase 2: Operational Event "Email Server Failure — pay 5 budget for emergency repair OR skip and lose 10 points."

The team has no email server, so the TO rules the event inert — there's nothing to break. (TO tip: when an event targets a component the team doesn't own, it fizzles — but it's a great moment to point at the capability gap.)

Phase 3: Team Actions "We're deploying a Database Server (10 budget) to handle the acquisition — that's critical. The failure event doesn't apply to us, so no repair cost. Total this turn: 10. Remaining: 43."

Infrastructure: Web Server, Database Server Budget: 43

TURN 3

Phase 1: Business Requirement "Ransomware Wave in Sector — you need Backup AND Detection capability OR lose 20 points."

Phase 2: Operational Event "Vendor Promotion — next security device this turn costs 2 less."

Phase 3: Team Actions "Critical quarter. We're deploying: - Backup Server (9 budget) - IDS at the promo discount (10 − 2 = 8 budget) That satisfies the ransomware requirement. We'll also grab a Cloud Workload (4) for future flexibility. Total: 21 budget. Remaining: 22."

Infrastructure: Web, Database, Backup, IDS, Cloud Workload Budget: 22

TURN 4

Phase 1: Business Requirement "Work-From-Home Program — need remote access capability. Missing: -3 points."

Phase 2: Operational Event "IT Staff Burnout — you may deploy at most ONE component this turn."

Phase 3: Team Actions "We need remote access, and burnout limits us to one deployment. VPN Gateway it is (9 budget). Remaining: 13."

Infrastructure: Web, Database, Backup, IDS, Cloud, VPN Gateway Budget: 13

TURN 5

Phase 1: Business Requirement "Cyber-Insurance Renewal — Backup + Email Gateway + detection: +5 points if all present, -5 if not."

Phase 2: Operational Event "Hardware Recall — pick an on-prem server: pay 3 budget or it's offline this quarter."

Phase 3: Team Actions "We deploy an Email Gateway (6 budget) — with our Backup and IDS that completes the insurance checklist: +5 points. For the recall we pay 3 to keep the Database Server online (it's load-bearing). Total: 9. Remaining: 4."

Infrastructure: Web, Database, Backup, IDS, Cloud, VPN Gateway, Email Gateway Budget: 4

TURN 6 (Final Turn)

Phase 1: Business Requirement "Single Sign-On Rollout — must have a Domain Controller OR lose 5 points."

Phase 2: Operational Event "Quiet Quarter — no incident."

Phase 3: Team Actions "A Domain Controller costs 12; we have 4. We can't buy it. We pass and take the -5 penalty."

Final Infrastructure & Budget Check: - Web Server (7) - Database Server (10) - Backup Server (9) - IDS (10, paid 8 with promo) - Cloud Workload (4) - VPN Gateway (9) - Email Gateway (6) - Recall fee (3) - Total spent: 7+10+9+8+4+9+6+3 = 56 of 60 available (50 start + 10 windfall) - Final Budget: 4 remaining ✓

FINAL SCORING (Walkthrough Team)

Security Score: - IDS: +5 - Email Gateway: +3 - Backup Server: +4 - Total: 12 points

Budget Score: - 4 remaining → 1-4 band - Missed only 1 requirement (no halving) - Total: 15 points

Capability Score: - Web +3, Database +4, Backup +3, VPN +2, Cloud +2 = 14 - No Email service: −5 (an Email Gateway is a security device — it filters mail, it doesn't host mailboxes; they never deployed an Email Server or cloud email) - No Domain Controller: −3 - Total: 6 points

Resilience Score: - Backup Server: +8 - Detection (IDS): +7 - Recovery Plan (backup + detection): +2 - Flat network: −2 - Total: 15 points

Requirement/Event adjustments: - Turn 5 insurance bonus: +5 - Turn 6 missed SSO requirement: −5

FINAL SCORE: 12 + 15 + 6 + 15 + 5 − 5 = 48 points

Lesson: This team survived the ransomware quarter and kept every event in check — but never bought email or identity. Detection and backups scored well; missing core business services bled capability points all game.

Variations & House Rules

Overload Servers (v2.2 — now a STANDARD rule, not a variation)

Servers may exceed capacity at +1 Budget per extra service. This is the same rule as the Network Building module. - Example: 3 services on a 2-capacity server costs +1 budget - Trade-off: cheaper than a new server now, but overloaded servers are recorded risks (single point of failure; events and later modules punish them)

Variation 1: "Upgrade Existing"

Optional Rule: Allow teams to upgrade servers already deployed (swap for a better one, pay the difference). - Example: Replace File Server (6) with Domain Controller (12) — pay 6, keep the hosted services - Creates flexibility but adds complexity

Variation 2: "Disaster Strikes Mid-Game"

Optional Rule (High Difficulty): If EVT-11 (Ransomware Strikes) is drawn and the team has NO Backup Server, they take the -20 immediately AND must deploy a Backup Server by the end of the next turn (mandatory). - Creates an urgent decision point - Teaches that failures have compounding consequences

Variation 3: "Tech Debt"

Optional Rule: Each Legacy System deployed costs 1 extra budget per turn to maintain (not paid upfront). - Teaches that cheap solutions have hidden costs - Creates long-term vs. short-term thinking

Debrief Questions (5-10 minutes)

Strategy Discussion

1. "What was your infrastructure strategy? Why did you prioritize certain systems?"
2. "Which trade-off was hardest? (Security vs. Capability vs. Budget)"
3. "If you could replay, what would you change?"

Learning Connections

1. "How does this relate to real IT budgeting?"
2. "What did you learn about balancing security with other concerns?"
3. "If this network gets attacked (Incident Response module), which vulnerabilities do you see?"

Competitive Reflection

1. "Why did Team X score higher? What did they do differently?"
2. "What was the winning strategy?"

Quick Reference Sheets

Scoring Summary (1 page)

NETWORK BUILDING STANDALONE SCORING (v2.2)

SECURITY SCORE (max 30):
  IDS or IPS: +5 | SIEM: +5 | Firewall: +4 | Backup: +4
  Email Gateway: +3 | WAF: +3 | Honeypot: +3 | Segmentation: +3

BUDGET SCORE (max 20) — smart utilization, not hoarding:
  5-15 left: 20 | 1-4 left: 15 | 0 left: 10 | 16-25 left: 10 | 26+ left: 5
  Missed 2+ requirements? Halve it (round down).

CAPABILITY SCORE (max 25):
  Email: +3 | Web: +3 | Database: +4 | File: +2 | Domain: +3
  Dev: +2 | Backup: +3 | VPN: +2 | Cloud: +2 | Honeypot: +1
  Penalties: no Email -5 | no Database -10 | no DC -3
             no VPN (if remote-work card drawn) -3

RESILIENCE SCORE (max 25):
  Backup: +8 | Detection: +7 | Redundancy: +5 | Segmentation: +3
  Recovery Plan (Backup AND Detection): +2
  Penalties: no Backup -10 | single point of failure -5
             no Detection -3 | flat network -2

FINAL = Security + Budget + Capability + Resilience
        − requirement/event penalties (+ bonuses)

Component Quick Reference

SERVERS (Cost / Capacity / Security Profile):
  Email (8/1/Low) | Web (7/1/Low) | Database (10/1/Med)
  File (6/2/Low) | Domain (12/2/Med) | Dev (5/3/Low)
  Backup (9/1/High) | Cloud (4/2/Med) | Legacy (3/1/VLow) | Honeypot (7/1/Med)
  Overload: +1 Budget per service beyond capacity

SECURITY DEVICES (Cost — benefit):
  Firewall (12 — zone control) | IDS (10 — detection) | IPS (14 — detection+blocking)
  Email Gateway (6 — anti-phishing) | WAF (11 — web app defense)
  SIEM (15 — detection+logging) | Segmentation Switch (10 — isolation)
  VPN Gateway (9 — remote access) | Load Balancer (8 — redundancy)
  Honeypot Network (8 — detection/deception)

Ready for Play!

This is a complete, standalone 30-45 minute competitive mini-game.

To run a session: 1. Print server and device cards (cards/network-building/core-deck/) 2. Print the requirement and event decks (cards/network-building/standalone/) 3. Give each team a budget tracker 4. Run 5-7 turns (4-5 min each, per difficulty) 5. Calculate final scores 6. Declare winner 7. 10-minute debrief

v2.2 Playtest Edition Changes

Summary of changes for playtesters:

1. Difficulty labels unified with the module: Beginner 60 / Standard 50 / Advanced 40 (was "Hard"). More budget = easier.
2. Any-number actions (v2.2): Phase 3 now allows any number of deployments per turn, matching the module rules; the old "one action" wording contradicted the game's own walkthrough.
3. Real card decks: Business Requirements (20 cards, REQ-01..REQ-20) and Operational Events (16 cards, EVT-01..EVT-16) now exist as printable files in cards/network-building/standalone/; inline example lists replaced by references to them.
4. Budget Score redefined around smart utilization: the table now rewards finishing with a 5-15 token contingency reserve and no longer rewards hoarding (the old table gave 20 points for 40+ unspent, while the examples assumed the opposite). Anti-hoarding check added.
5. Scoring tables recomputed: Security items now sum to the stated max 30; Capability items sum to 25 (Honeypot +1 added — it was in an example but missing from the table); Resilience factors sum to 25 and penalties were rebalanced (no Backup −10). All worked examples now add up.
6. Worked examples rebuilt: Team A (37) and Team B (28) are clean, verified builds; the 6-turn walkthrough's budget ledger reconciles (56 spent of 60 available, 4 left, score 48). All AI drafting scratch-work removed.
7. Overload is standard: +1 Budget per extra service beyond capacity — same rule as the module.
8. Terminology: "VPN Gateway" (was VPN Concentrator), "Backup Server" (was Backup System); device "+1 stat" effects replaced with plain-language benefits tied to the scoring categories.
9. Component costs verified against the module rules (the canonical source): servers 3-12, devices 6-15.

Incident Zero: Network Building Standalone Mini-Game Infrastructure design competition with multi-dimensional scoring v2.2 - Playtest Edition

cards/network-building/core-deck/server-cards.md

Network Building Module: Server Cards

Version: 2.2 - Playtest Edition Last Updated: July 2026

Overview

Server Cards represent the core computational systems that run your business. Each server has cost (Budget), capacity (how many services it can host), complexity, and security properties that affect network design.

• Total Cards: 10 (SRV-01 to SRV-10)
• Used In: Network Building module
• Cost Range: 3-12 Budget depending on type and criticality
• Capacity: Number of services the server can host before the Overload rule applies (+1 Budget per extra service)
• Complexity Range: 1-4 (affects maintenance overhead, represented narratively)

Server Cards

SRV-01: Email Server

Type: Business Critical Cost: 8 Budget Capacity: 1 service Complexity: 2/4 Availability Requirement: 99.9% (almost always needed)

Description: Central email system (Exchange, Postfix, or cloud-based like Office 365). Handles all organizational communication. Commonly targeted by phishing and credential attacks. Must support spam filtering, encryption, and audit logging.

Key Concerns: - Email spoofing and phishing vectors - Credential compromise (email = access to password resets) - Data exfiltration via email attachments and forwarding - High user impact if unavailable

Defense Considerations: - Requires Email Authentication (DMARC/SPF/DKIM) - Benefits from DLP for sensitive email attachments - Gateway filtering for phishing and malware - MFA required for administrative access

Network Placement: DMZ or protected segment (external access required)

Interactions: - Used with Asset Card "Email" - References in Incident Response scenarios (T-01 Phishing, T-11 Browser Extension) - Part of Disaster Recovery "critical services" list

SRV-02: Web Server

Type: Business Critical Cost: 7 Budget Capacity: 1 service Complexity: 2/4 Availability Requirement: 99.5% (critical during business hours)

Description: Public-facing web application server (Apache, Nginx, IIS). Hosts corporate website, customer portal, or SaaS application. Primary attack surface for web exploits (SQL injection, XSS, remote code execution).

Key Concerns: - Web application vulnerabilities (OWASP Top 10) - Unpatched framework or library exploits - DDoS attacks targeting availability - Code injection and remote execution - Data exposure via web interface

Defense Considerations: - Requires WAF (Web Application Firewall) for SQL injection/XSS prevention - IPS for exploit signature detection - Regular patching and vulnerability scanning - Load balancer for availability - TLS/SSL for data in transit

Network Placement: DMZ (external access required, isolated from internal systems)

Interactions: - Used with Asset Card "Web" - References in Incident Response scenarios (T-02 Watering Hole, T-05 Kernel Exploit) - Load balancer reduces single point of failure

SRV-03: Database Server

Type: Business Critical Cost: 10 Budget Capacity: 1 service Complexity: 3/4 Availability Requirement: 99.9% (critical for business operations)

Description: Relational or NoSQL database (SQL Server, PostgreSQL, MongoDB, Oracle). Stores customer data, financial records, operational data. Highest value target after compromise—contains the "crown jewels."

Key Concerns: - SQL injection attacks - Credential abuse (weak database admin passwords) - Lateral movement target (pivot point) - Unencrypted data at rest - Unencrypted data in transit - Unauthorized data access and exfiltration

Defense Considerations: - Requires Network Segmentation to limit access - Credential Guard and strong authentication - Database activity monitoring (DAM) - TLS for all connections - Data encryption at rest - Regular backups with immutability - Connection string in vault (not hardcoded)

Network Placement: Restricted segment (only authorized systems can connect)

Interactions: - Used with Asset Card "Database" - References in Incident Response scenarios (T-04 Lateral Movement, T-10 SQL Exfiltration, T-11 Browser Extension) - Critical for Disaster Recovery backup and recovery

SRV-04: File Server

Type: Business Critical Cost: 6 Budget Capacity: 2 services Complexity: 2/4 Availability Requirement: 99% (needed during business hours)

Description: File storage and sharing system (SMB/CIFS, NFS, or cloud file sharing). Stores shared documents, project files, compliance records. Often contains both sensitive and non-sensitive data mixed together.

Key Concerns: - SMB lateral movement attacks - Excessive file permissions (everyone can read everything) - Ransomware encryption of shares - Unauthorized file access and data theft - Compliance violations (PII, PHI, PCI data stored unencrypted) - Uncontrolled data growth and backup challenges

Defense Considerations: - Network Segmentation to limit SMB access - File permissions auditing and hardening - DLP for sensitive file detection - Immutable snapshots for ransomware recovery - Encryption at rest - Access logging and monitoring

Network Placement: Protected segment (limited internal access only)

Interactions: - Used with Asset Card "File Storage" - Target of T-04 Lateral Movement in Incident Response - Critical dependency for Disaster Recovery

SRV-05: Domain Controller

Type: Business Critical Cost: 12 Budget Capacity: 2 services Complexity: 3/4 Availability Requirement: 99.5% (core infrastructure dependency)

Description: Active Directory or LDAP domain controller. Master repository of all user identities, credentials, and group memberships. Most powerful target in the organization—compromise of DC gives attacker control of entire directory.

Key Concerns: - Credential dumping (Mimikatz targets LSASS on DC) - Pass-the-hash attacks - Unauthorized privilege escalation - DC compromise = organization is fundamentally compromised - Backup DC synchronization complications - Can be both on-premises and cloud (Azure AD)

Defense Considerations: - Credential Guard to protect LSASS - Privileged Access Workstation (PAW) for DC admin access - Strong authentication (MFA) for all DC access - Network Segmentation (DC in restricted tier) - Backup DC in geographically separate location - Regular backup and recovery testing

Network Placement: Restricted segment (admin-only access)

Interactions: - Used with Asset Card "Identity" - Central to Incident Response investigation (T-06 Mimikatz, T-04 Lateral Movement) - DC compromise immediately loses the game (organizational control lost) - Critical for Disaster Recovery restore procedures

SRV-06: Development Server

Type: Business Important Cost: 5 Budget Capacity: 3 services Complexity: 2/4 Availability Requirement: 80% (nice to have, can work around)

Description: Development and testing environment for software development. Lower security requirements than production but often contains production-like data (for testing). Developers need broad access for testing purposes.

Key Concerns: - Overly permissive developer access - Production data in dev (compliance violations) - Outdated/unpatched tools (focus on development, not security) - Lateral movement springboard to production - Code repository contains source code (intellectual property) - Test credentials and API keys hardcoded

Defense Considerations: - Separate dev database from production database (never use prod data) - Firewall rules to prevent dev→prod lateral movement - Code repository security (secrets scanning, access control) - Regular cleanup of test data - MFA for dev server access - Audit logging of developer activities

Network Placement: Development segment (isolated from production)

Interactions: - Used with Asset Card "Development" - Often overlooked security risk (compliance gap in Audit module) - Lateral movement target (attacker compromise dev to move to prod)

SRV-07: Backup Server

Type: Business Critical (Different Tier) Cost: 9 Budget Capacity: 1 service Complexity: 2/4 Availability Requirement: 95% (needed for recovery scenarios)

Description: Backup and archival storage system (dedicated appliance, NAS, or cloud backup like Veeam, Commvault, or Backblaze). Stores point-in-time copies of all critical systems. The ultimate recovery mechanism for ransomware, disasters, and destructive attacks.

Key Concerns: - Backup corruption or compromise (renders backups useless) - Ransomware targeting backup systems - Backup media not separated from primary systems - Backups not regularly tested (recovery fails when needed) - Immutability not enforced (backups can be modified) - Access control: who can restore? Who can delete?

Defense Considerations: - CRITICAL: 3-2-1 backup strategy: 3 copies, 2 media types, 1 offsite - Immutable backups (WORM - Write Once Read Many) - Encryption at rest and in transit - Backup testing schedule (quarterly minimum) - Separate backup credentials (not domain-linked) - Offsite backup location (geographically separated) - Backup media inventory and audit log

Network Placement: Restricted segment + offsite (separate from primary network)

Interactions: - Used with Asset Card "Disaster Recovery" - Critical for Disaster Recovery module (backup resilience determines recovery speed) - If backup is missing or compromised, the team automatically FAILS the Disaster Recovery requirement (v2.2) — a CRITICAL gap carried into other modules - Incident Response mentions backup verification in defenses

SRV-08: Cloud Workload

Type: Increasingly Business Critical Cost: 4 Budget Capacity: 2 services Complexity: 2/4 (but different concerns than on-premises) Availability Requirement: 99% (vendor manages SLA)

Description: Cloud-hosted application or service (AWS EC2, Azure VM, GCP Compute Engine, or fully managed service like Lambda, Cloud Run). Shifts some infrastructure management to cloud provider but introduces new security concerns.

Key Concerns: - Misconfigured security groups/network ACLs (open to internet) - Cloud credentials compromise (AWS IAM keys stolen) - Instance metadata service attacks (AWS IMDS exploitation) - Cross-account or cross-tenant access (shared infrastructure) - Cloud-specific vulnerabilities (API, permissions models) - Data residency and compliance (where is data stored?)

Defense Considerations: - Cloud-native security tools (AWS Security Hub, Azure Security Center) - Proper IAM configuration (least privilege for cloud roles) - Network security groups with default-deny - Cloud workload protection (container runtime security) - VPC and subnet isolation - Encryption of cloud data

Network Placement: Cloud provider network (separate from on-premises, connected via VPN)

Interactions: - Used with Asset Card (varies—Email in cloud, Web in cloud, etc.) - Network design must include cloud connectivity (VPN or Direct Connect) - Audit module assesses cloud security posture - Cloud-specific Incident Response and Hardening challenges

SRV-09: Legacy System

Type: Business Important (Legacy) Cost: 3 Budget Capacity: 1 service Complexity: 3/4 (difficult to maintain, patch, or secure) Availability Requirement: 90% (supported but aging)

Description: Aging system running outdated OS (Windows XP, older Linux, proprietary systems) or custom applications. Cannot be easily patched due to compatibility issues, vendor no longer supporting, or critical business process depends on it.

Key Concerns: - Cannot patch due to vendor EOL (End of Life) - Incompatible with modern security tools (EDR won't run) - No TLS support (unencrypted traffic) - Known, publicly disclosed vulnerabilities with no fix - Business relies on it despite security risk - Migration cost exceeds security benefit (economically trapped)

Defense Considerations: - CRITICAL: Network Segmentation isolates legacy system - Firewall rules restrict legacy system traffic - Assume compromise and defend the segmented network (not the legacy system itself) - Monitor legacy system for suspicious activity (can't detect on system, detect on network) - Immutable backups to restore if compromised - Plan legacy system retirement

Network Placement: Isolated segment (strict firewall rules, minimal connectivity)

Interactions: - Used if organization has legacy infrastructure - Audit module finds legacy systems as critical findings - Network design: "assume legacy is compromised, defend around it" - Expansion deck explores legacy system challenges

SRV-10: Honeypot Decoy

Type: Security Tool (Non-Business) Cost: 7 Budget Capacity: 1 service (decoy only — hosts no real business service) Complexity: 1/4 (purposefully simple and unmonitored-looking) Availability Requirement: N/A (false resource)

Description: Deliberately exposed fake server or user account designed to detect compromise and lateral movement. Appears to be a real business resource but is actually a trap. Any access to honeypot indicates active attacker activity (zero false positives).

Key Concerns: - Placement visibility (attacker must discover it to trigger it) - Believability (must look like real system worth attacking) - Monitoring (honeypot access must be logged securely) - Honeypot maintenance (must not appear unmaintained) - Response procedures (what do we do when honeypot is triggered?)

Defense Considerations: - Canary tokens (watermarked documents, fake credentials) - Fake administrative account (admin account that isn't really admin) - Fake file server with sensitive-looking shares - Fake VIP email addresses on mailing lists - Alerting on any access to honeypot (immediate incident response)

Network Placement: Among legitimate resources (cannot appear isolated)

Interactions: - Used with Deception Technology defense card in Hardening - Network design: "place honeypots where attackers will likely look" - Zero false positives: any honeypot access = real attack - Expansion deck discusses advanced honeypot strategies

Server Card Summary

Gameplay Notes

Budget Considerations

• Cheapest: Legacy System (3), Cloud Workload (4), Development (5)
• Mid-range: File Server (6), Web Server (7), Honeypot (7), Email Server (8), Backup Server (9)
• Most Expensive: Database Server (10), Domain Controller (12)
• Total cost of all 10 servers: 71 Budget (teams must prioritize)

Capacity & Overload (v2.2)

• Capacity = how many services a server can host at its printed cost
• Extra services beyond capacity cost +1 Budget each and mark the server OVERLOADED (a recorded gap for later modules)

Complexity Considerations

• High complexity servers (DC, Database, Legacy) require more operational overhead
• Teams with strong Ops team can handle complexity better
• Low complexity servers (Web, Email) are easier to manage

Business Requirement Mapping

Each server fulfills one or more Asset Card requirements: - SRV-01 → Asset "Email" - SRV-02 → Asset "Web" - SRV-03 → Asset "Database" - SRV-04 → Asset "File Storage" - SRV-05 → Asset "Identity" - SRV-06 → Asset "Development" - SRV-07 → Asset "Disaster Recovery" - SRV-08 → Asset (varies—could be Email, Web, Database in cloud) - SRV-09 → Asset (legacy system supporting specific business function) - SRV-10 → Security monitoring (not a business requirement)

Print Instructions

1. Print on cardstock (250 gsm minimum)
2. Color-code by business criticality:
3. Red: SRV-03, SRV-05, SRV-07 (Business Critical - cannot lose)
4. Yellow: SRV-01, SRV-02, SRV-04 (Important - high impact if down)
5. Blue: SRV-06, SRV-08, SRV-09 (Business Important - can work around)
6. Green: SRV-10 (Security Tool - special purpose)
7. Cut along dotted lines
8. Consider creating a separate "Server Reference Card" with costs, capacity, and complexity for quick lookup

Network Building Module: Server Cards Part of Incident Zero, a modular cybersecurity board game v2.2 - Playtest Edition

cards/network-building/core-deck/security-device-cards.md

Network Building Module: Security Device Cards

Version: 2.2 - Playtest Edition Last Updated: July 2026

Overview

Security Device Cards represent network security appliances and tools that control traffic, detect threats, and enforce policies between network segments.

• Total Cards: 10 (SEC-01 to SEC-10)
• Used In: Network Building module
• Cost Range: 6-15 Budget depending on capability and throughput
• Placement: Between network segments or at network perimeter

Security Device Cards

SEC-01: Firewall (Perimeter)

Type: Perimeter Control Cost: 12 Budget Placement: Network edge (between internet and internal network) Primary Function: Block unauthorized inbound/outbound traffic

Description: Traditional stateful firewall (Cisco ASA, Palo Alto Networks, Fortinet FortiGate) at network perimeter. Enforces allow/deny rules based on source IP, destination IP, protocol, and port. First line of defense against external attacks.

What It Protects Against: - Unauthorized inbound access attempts - Unauthorized outbound connections (C2 beaconing, data exfiltration) - Network reconnaissance from internet - DDoS attacks (basic flood protection)

What It Doesn't Protect Against: - Application-layer attacks (SQL injection, XSS) - Lateral movement within network (operates at L3/L4 only) - Encrypted traffic inspection (needs deep packet inspection) - Insider threats or authorized-but-malicious access

Network Interactions: - Required for: Most organizations (perimeter protection is baseline) - Works with: Web Server (must allow inbound HTTP/HTTPS), Email Server (SMTP/POP3/IMAP) - Supports: Database (prevents inbound database connections from internet)

Ruleset Complexity: Medium (5-10 rules for basic setup, 50+ for mature organization)

Performance Impact: Minimal for small networks, can become bottleneck at scale

SEC-02: Intrusion Detection System (IDS)

Type: Threat Detection Cost: 10 Budget Placement: Internal network (behind firewall, in front of critical systems) Primary Function: Detect suspicious network traffic patterns

Description: Network-based IDS (Snort, Zeek, Suricata) that inspects all traffic and alerts on suspicious patterns. Uses signature matching and/or behavioral analysis to identify known attacks and anomalous traffic.

What It Protects Against: - Known attack patterns (exploits, vulnerability scans) - Port scanning and reconnaissance - Lateral movement (SMB, RDP abuse) - Data exfiltration patterns (unusual volume, unusual destination) - Command & Control (C2) communication

What It Doesn't Protect Against: - Zero-day exploits (no signature exists) - Encryption inspection (needs decryption) - Insider threats (authorized users on authorized systems) - Application-layer attacks (SQL injection, XSS still pass through)

Network Interactions: - Works with: SIEM (IDS alerts feed into SIEM for correlation) - Supports: Detection of T-04 (Lateral Movement), T-09 (C2 Beaconing) in Incident Response - Complements: IPS (IDS detects, IPS blocks; often paired)

Signature Maintenance: High (requires weekly/daily signature updates from threat intelligence)

Performance Impact: Medium (packet inspection adds latency, can slow network)

SEC-03: Intrusion Prevention System (IPS)

Type: Threat Prevention Cost: 14 Budget Placement: Internal network (actively blocks malicious traffic) Primary Function: Block suspicious traffic in real-time

Description: Network-based IPS (actively protective version of IDS). Can block traffic in addition to alerting. Inline placement allows real-time threat blocking.

What It Protects Against: - Everything IDS protects against (detection + blocking) - Exploit attempts against known vulnerabilities - Worm propagation - Policy violations

What It Doesn't Protect Against: - Same limitations as IDS, plus: - False positive blocking (can block legitimate traffic) - Encrypted traffic inspection limitations - Zero-day exploits

Network Interactions: - Works with: WAF on web traffic (IPS for network, WAF for applications) - Works with: Firewall (layered network defense) - Supports: Defense against T-02 (Watering Hole), T-05 (Kernel Exploit) in Incident Response

Tuning Complexity: High (false positives require tuning; too aggressive = blocks legitimate traffic)

Performance Impact: Medium-High (real-time inspection + blocking adds latency)

Risk: Misconfigured IPS can block critical business traffic

SEC-04: Load Balancer

Type: Availability & Performance Cost: 8 Budget Placement: In front of multiple web servers Primary Function: Distribute traffic across multiple servers

Description: Load balancer (F5, Citrix NetScaler, nginx, HAProxy) distributes incoming traffic across multiple backend servers. Increases availability and performance.

What It Protects Against: - Single server failure (if one web server fails, traffic routes to others) - DDoS attacks (distributes attack traffic across multiple servers) - Overload attacks (can queue excess requests)

What It Doesn't Protect Against: - Application vulnerabilities - Malicious traffic targeting multiple backends - Session hijacking - Backend compromise (load balancer can't protect compromised backend)

Network Interactions: - Requires: Web Server (needs multiple instances for load balancing to make sense) - Works with: Web Server redundancy (2+ web servers behind load balancer) - Supports: Web application availability in Incident Response scenarios

Health Check Mechanism: Monitors backend servers; removes unhealthy servers automatically

Cost-Benefit: Low cost (8 Budget) but high value if you have multiple web servers

SEC-05: VPN Gateway

Type: Remote Access Control Cost: 9 Budget Placement: Network perimeter (between internet and internal network) Primary Function: Secure remote access for employees/contractors

Description: VPN concentrator (Cisco AnyConnect, Palo Alto Prisma Access, F5 BIG-IP) that creates encrypted tunnels for remote users. Allows employees to securely access internal resources from outside network.

What It Protects Against: - Man-in-the-middle attacks on remote user traffic - Credential interception (traffic encrypted) - Unauthorized access to internal resources (authentication required) - IP spoofing (tunnel validates source)

What It Doesn't Protect Against: - Weak VPN credentials (still vulnerable to brute force) - Compromised endpoint connecting via VPN (malware on home computer) - Insider threats (authorized user with legitimate credentials) - Application vulnerabilities accessed through VPN

Network Interactions: - Works with: Domain Controller (VPN user auth) - Works with: MFA (VPN should require MFA) - Supports: Remote work scenarios (necessary for distributed teams)

Authentication Complexity: Requires MFA for security (otherwise easy brute force)

Cost-Benefit: Necessary for remote work, but alone insufficient (needs MFA)

SEC-06: Email Gateway

Type: Email Security Cost: 6 Budget Placement: Network perimeter (filters incoming/outgoing email) Primary Function: Filter spam, phishing, and malware in email

Description: Email security appliance (Proofpoint, Mimecast, Cisco Email Security) that filters all incoming/outgoing email. Scans for phishing, malware, data exfiltration attempts.

What It Protects Against: - Phishing emails (signature and behavior-based detection) - Email-based malware (attachments, links) - Spam (reduces alert fatigue) - Data exfiltration via email (DLP for email) - Email spoofing (validates SPF/DKIM/DMARC)

What It Doesn't Protect Against: - User clicks on phishing links (user training needed) - Advanced phishing with legitimate credentials - Compromised internal email account sending from inside - Zero-day malware in attachments

Network Interactions: - Works with: Email Server (filters before reaching server) - Works with: User Security Training (filters + training = defense-in-depth) - Supports: Defense against T-01 (Phishing) in Incident Response

Signature Maintenance: Very high (email threats change daily)

User Experience Impact: Email delays (milliseconds) are imperceptible; false positives = missed emails

SEC-07: Web Application Firewall (WAF)

Type: Application-Layer Protection Cost: 11 Budget Placement: In front of web server Primary Function: Block application-layer attacks (SQL injection, XSS, etc.)

Description: Web Application Firewall (ModSecurity, Cloudflare WAF, AWS WAF) that inspects HTTP traffic and blocks malicious payloads. Understands web application protocols unlike traditional firewall.

What It Protects Against: - SQL injection attacks - Cross-site scripting (XSS) - Cross-site request forgery (CSRF) - Remote code execution (RCE) - Malicious file uploads - Buffer overflows in web apps

What It Doesn't Protect Against: - Logic flaws in application (WAF can't fix broken business logic) - Authenticated attacks (user is authorized) - Distributed attacks across many IPs (WAF can't distinguish) - Zero-day application vulnerabilities (no rule exists)

Network Interactions: - Requires: Web Server (only protects web traffic) - Works with: IPS (network-level and application-level defense) - Supports: Defense against T-02 (Watering Hole) in Incident Response

Rule Maintenance: Medium (OWASP rules are standardized, vendor maintains them)

False Positive Rate: Medium (needs tuning for specific web application)

Performance Impact: Medium (application inspection adds latency)

SEC-08: Network Segmentation Switch

Type: Network Architecture Control Cost: 10 Budget Placement: Internal network (between segmented network zones) Primary Function: Enforce network segmentation via VLANs and ACLs

Description: Layer 3 switch or router configured for network segmentation. Implements VLANs (virtual LANs) and layer 3 filtering to separate network into zones (DMZ, User segment, Server segment, Admin segment).

What It Protects Against: - Lateral movement via SMB and other internal protocols - Credential dumping spread (isolated networks can't reach DCs) - Compromised user system accessing servers directly - Insider threats (restrictions on data access) - Data exfiltration to external media (if USB segment is isolated)

What It Doesn't Protect Against: - Attacks within same segment (switch can't prevent user↔user attacks) - Routing around segmentation (if misconfigured) - Physical network attacks (layer 1 problems) - Encrypted tunneling out of segment (if firewall rule allows)

Network Interactions: - Works with: Firewall (firewall rules enforce segmentation policies) - Works with: Database Server (database in isolated segment) - Works with: Zero Trust (segmentation is prerequisite for zero trust) - Supports: Defense against T-04 (Lateral Movement) in Incident Response

Configuration Complexity: High (requires planning of segment boundaries and rules)

Cost-Benefit: Very high ROI (prevents lateral movement for 10 Budget)

SEC-09: SIEM (Security Information & Event Management)

Type: Threat Monitoring & Investigation Cost: 15 Budget Placement: Central monitoring (logs from all devices) Primary Function: Aggregate logs and detect threats via correlation

Description: Enterprise SIEM (Splunk, Elastic, QRadar, ArcSight) that collects logs from all systems, correlates events, and alerts on suspicious patterns. Foundation of mature incident response program.

What It Protects Against: - Multi-step attack patterns (correlation finds chains) - Persistence mechanisms (scheduled tasks, registry changes logged) - Credential abuse (failed login spikes) - Insider threats (excessive file access, off-hours activity) - Data exfiltration (unusual volume to unusual destination)

What It Doesn't Protect Against: - Attacks happening faster than SIEM ingests logs - False negatives (misconfigured rules miss attacks) - Encrypted traffic inspection (needs decryption) - Malware on endpoint (needs EDR, not SIEM)

Network Interactions: - Requires: Log Centralization deployment (needs logs to analyze) - Works with: IDS/IPS alerts (SIEM correlates with network alerts) - Supports: Incident Response investigation (SIEM data essential for forensics) - Critical for: Hardening module detection (SIEM detects Pentester Tactics)

Data Requirements: Massive (can be 10+ GB/day for large organizations)

Maintenance: Very high (tuning rules, managing data retention, responding to false positives)

Value: Essential for organizations that need incident detection

SEC-10: Honeypot Network

Type: Deception & Detection Cost: 8 Budget Placement: Isolated segment (mimics legitimate infrastructure) Primary Function: Detect lateral movement and reconnaissance

Description: Network of decoy systems (not SRV-10 honeypot server, but entire segment) designed to attract attackers. Any access to honeypot network indicates active attacker.

What It Protects Against: - Lateral movement (attacker triggers honeypot while exploring) - Network reconnaissance (if honeypot is discovered) - Ransomware spread (if honeypot is in ransomware path) - Insider reconnaissance (any access to honeypot = red flag)

What It Doesn't Protect Against: - Attacks that don't trigger honeypot (if attacker follows direct path) - Honeypot visibility (attacker must find it to trigger it) - False positives (must be designed to avoid accidental triggers)

Network Interactions: - Works with: Network Segmentation (honeypot in isolated but accessible segment) - Works with: SIEM (honeypot triggers feed into SIEM) - Supports: Detection in Hardening module (Deception Technology defense)

Maintenance: Medium (must keep honeypot looking alive and attractive)

Cost-Benefit: Low cost (8 Budget) with high detection value (zero false positives)

Security Device Summary

Cost-Benefit Analysis

Tier 1 (Essential for Any Organization)

• SEC-01 (Firewall): 12 Budget - baseline perimeter control
• SEC-09 (SIEM): 15 Budget - essential for detection
• Subtotal: 27 Budget (minimum viable security monitoring)

Tier 2 (Advanced Organizations)

• SEC-02 (IDS): 10 Budget
• SEC-03 (IPS): 14 Budget - or choose IDS+IPS combo for redundancy
• SEC-08 (Segmentation): 10 Budget - critical for limiting lateral movement
• Subtotal: 34 Budget (adds detection + prevention + segmentation)

Tier 3 (Specialized Protections)

• SEC-06 (Email Gateway): 6 Budget - for email-heavy organizations
• SEC-07 (WAF): 11 Budget - if you have public web application
• SEC-05 (VPN Gateway): 9 Budget - if you have remote workers
• SEC-04 (Load Balancer): 8 Budget - if you need web app redundancy
• SEC-10 (Honeypot): 8 Budget - advanced detection tool
• Subtotal: 42 Budget (specialized for specific scenarios)

Gameplay Strategy Notes (v2.2)

Budgets are 40-60 by difficulty (Beginner 60 / Standard 50 / Advanced 40), and the Required servers eat most of it — plan security spending around what's left.

Beginner (Budget: 60)

• Dedicated servers for every Required item cost 46, leaving ~14 for security
• Good picks: Email Gateway (6) + Honeypot Network (8) = 14, or Segmentation Switch (10) + a small reserve

Standard (Budget: 50)

• Cloud-hosting Email + Web on a Cloud Workload trims the Required servers to ~35, leaving ~15
• Good picks: Segmentation Switch (10) or IDS (10) plus a 5-Budget contingency reserve, or Email Gateway (6) + Honeypot Network (8)

Advanced (Budget: 40)

• Every device is a sacrifice; expect to record big detection gaps
• Email Gateway (6) is the best value per Budget; a lone Segmentation Switch (10) pays off in every later module
• Firewall (12) and SIEM (15) are usually out of reach — note the gap and move on

Print Instructions

1. Print on cardstock (250 gsm minimum)
2. Color-code by OSI layer:
3. Red (Layer 3-4, Network): SEC-01, SEC-02, SEC-03, SEC-08, SEC-10
4. Orange (Layer 7, Application): SEC-07
5. Yellow (Specialized): SEC-04, SEC-05, SEC-06
6. Blue (Central): SEC-09
7. Cut along dotted lines
8. Create a "Device Reference Card" with costs, network placement, and primary protections for quick lookup during gameplay

Network Building Module: Security Device Cards Part of Incident Zero, a modular cybersecurity board game v2.2 - Playtest Edition

cards/network-building/core-deck/architecture-cards.md

Network Building Module: Architecture Cards

Version: 2.2 - Playtest Edition Last Updated: July 2026

Overview

Architecture Cards represent different network topology and design patterns. Each organization selects ONE architecture that determines how network segments are organized and how traffic flows between them.

• Total Cards: 5 (ARCH-01 to ARCH-05)
• Usage: Each team selects exactly ONE architecture for their network design
• Impact: Architecture choice affects cost, complexity, and security implications
• Trade-offs: Each architecture balances cost, security, complexity, and performance

Architecture Options

ARCH-01: Flat Network (Traditional)

Cost: 0 Budget Complexity: 1/5 (very simple) Security Posture: Low Performance: High (no routing/switching overhead)

Description: All systems connected to same network segment (same subnet, same broadcast domain). No network segmentation—everything can talk to everything. Traditional small office network.

Network Design:

Internet → Firewall → Switch
                      ├─ Email Server
                      ├─ Web Server
                      ├─ Database Server
                      ├─ File Server
                      ├─ Domain Controller
                      └─ User Workstations

Characteristics: - All systems on same IP subnet (e.g., 192.168.1.0/24) - Single broadcast domain - No layer 3 routing between segments - Firewall only at perimeter, not internal

What This Means for Security: - Advantages: Simple to set up and manage, low cost - Disadvantages: Lateral movement is trivial (attacker on user system can reach database server directly) - Implication: If any system is compromised, entire network is at risk

Who Uses This: - Small offices with <50 people - Non-security-sensitive organizations - Organizations where ease of use matters more than security

Defenses Required: - Stronger endpoint protection (must protect each individual system) - User security training (social engineering becomes primary attack vector) - Cannot rely on network-level controls

Against Incident Response Threats: - T-04 (Lateral Movement): Trivially successful (same network) - T-06 (Mimikatz): Once DC is compromised, entire network is accessible - T-11 (Data Exfil): No segmentation to stop data movement

ARCH-02: Segmented 3-Zone (DMZ Model)

Cost: 5 Budget Complexity: 2/5 (simple but requires planning) Security Posture: Medium Performance: Medium (slight routing overhead)

Description: Network divided into three logical zones with firewall rules between them. This is the most common network architecture for medium-sized organizations.

Network Design:

Internet → Firewall → [DMZ Zone] → Firewall → [Internal Zone] → Firewall → [Admin Zone]
             (Perimeter)    ↓                       ↓                      ↓
                        Web Server            File Server            Domain Controller
                        Email Server          User Workstations      Admin Workstations
                                             Database Server         Backup Server

Three Zones:

1. DMZ (Demilitarized Zone) - Internet-facing systems
2. Email Server, Web Server
3. Direct internet access controlled via firewall

4. If compromised, firewall prevents spread to internal zone

5. Internal Zone - Business systems

6. File Server, Database Server, User Workstations
7. Can reach DMZ for legitimate purposes

8. Cannot reach Admin Zone

9. Admin Zone - Administrative access and privileged systems

10. Domain Controller, Backup Server
11. Only reachable from specific admin workstations
12. Contains most sensitive access

Firewall Rules: - Internet → DMZ: Allowed (limited ports) - DMZ → Internal: Blocked (one-way dependency if needed) - Internal → Admin: Blocked (strict isolation) - Admin → Internal: Allowed (admin management of internal systems) - Admin → DMZ: Allowed (admin management of DMZ)

What This Means for Security: - Advantages: Limits lateral movement (attacker on web server can't reach database server directly) - Disadvantages: More complex to design and manage

Who Uses This: - Most medium-sized organizations (50-500 employees) - Organizations with some web/email presence - Organizations that want segmentation without extreme complexity

Against Incident Response Threats: - T-04 (Lateral Movement): Firewall rules block direct SMB access between zones; attacker must find alternate path - T-06 (Mimikatz): DC is in Admin Zone, isolated from compromised internal system - T-11 (Data Exfil): Must exit through firewall, can be monitored

ARCH-03: Fully Isolated (Zero Trust Model)

Cost: 12 Budget Complexity: 4/5 (complex, requires careful design) Security Posture: Very High Performance: Lower (strict controls add latency)

Description: Network divided into many small segments, each with strict firewall rules. No implicit trust based on network location—every connection is verified. Approximates zero-trust architecture.

Network Design:

Internet → Firewall → [DMZ Segment] → Firewall → [Each Server has own segment]
                                                   + User segment
                                                   + Admin segment
                                                   + Development segment
                                                   + Backup segment
                                                   + Legacy segment

Each connection between segments requires explicit allow rule.

Segment Isolation: - Every major system or group gets its own segment - Database server isolated from file server - Email server isolated from web server - User workstations isolated from each other (per-user or small group segments) - Development isolated from production - Admin segment for domain controllers only - Legacy systems isolated from modern systems

Firewall Rules: - Default deny: Any traffic not explicitly allowed is blocked - Explicit allows: Every needed connection has a specific rule - Unidirectional: Rules are directional (client→server, not server→client) - Port specific: Rules specify exact port, not ranges

What This Means for Security: - Advantages: Lateral movement is nearly impossible—even if one system is compromised, firewall blocks reach to others - Disadvantages: Very complex to design, expensive to implement, difficult to troubleshoot when legitimate traffic is blocked

Who Uses This: - Large enterprises with security teams - Organizations with strict compliance requirements (finance, healthcare, government) - Organizations that assume breach and plan accordingly

Against Incident Response Threats: - T-04 (Lateral Movement): Firewall blocks attempt immediately; attacker cannot move - T-06 (Mimikatz): Even with DC credentials, accessing other systems requires approval - T-11 (Data Exfil): Exfil traffic blocked by firewall rules

Governance: Requires change management process for any new firewall rules

ARCH-04: Cloud Hybrid (Mixed On-Premises & Cloud)

Cost: 8 Budget Complexity: 3/5 (cloud adds complexity) Security Posture: Medium-High (cloud provider handles some security) Performance: Medium (internet latency for cloud communication)

Description: Organization has both on-premises infrastructure AND cloud resources. Some applications run on-premises, others run in cloud (AWS, Azure, GCP).

Network Design:

Internet → Firewall → On-Premises Segment
                          ├─ Email Server (on-prem)
                          ├─ File Server (on-prem)
                          ├─ Database Server (on-prem)
                          └─ VPN/Direct Connect → Cloud

                                                 ├─ Web Server (cloud)
                                                 ├─ App Server (cloud)
                                                 ├─ Cloud Storage
                                                 └─ Cloud Database

Connectivity Methods: 1. VPN: Encrypted tunnel over internet (slower, cheaper) 2. Direct Connect: Dedicated network connection (faster, more expensive)

What This Means for Security: - Advantages: Flexibility (use right tool for each workload), scalability - Disadvantages: New attack surface (cloud APIs, IAM), credential management across platforms

Cloud-Specific Risks: - Misconfigured S3 buckets (public read access) - Cloud IAM overly permissive (too much access) - Cloud API keys in source code - Data residency in unexpected regions

Who Uses This: - Organizations transitioning to cloud (lift-and-shift) - Organizations with variable load (burst to cloud) - Organizations with development in cloud, production on-prem

Against Incident Response Threats: - T-04 (Lateral Movement): Can pivot from on-prem to cloud via cloud APIs - T-08 (Cloud breach): New threat class specific to cloud - T-13 (Misconfiguration): Cloud-specific attack not in traditional scenarios

ARCH-05: Cloud First (Cloud-Only Infrastructure)

Cost: 6 Budget Complexity: 2/5 (cloud provider manages complexity) Security Posture: Medium (cloud provider security + customer configuration) Performance: Excellent (cloud provider optimization)

Description: All infrastructure is cloud-based. No on-premises data center. Applications, data, and users all in cloud (AWS, Azure, GCP, or SaaS).

Network Design:

Internet → Cloud Edge
            ├─ Web Services (cloud)
            ├─ Application Services (cloud)
            ├─ Database (cloud)
            ├─ Storage (cloud)
            └─ All managed by cloud provider

Deployment Models: 1. IaaS (Infrastructure as a Service): You manage VMs, they manage infrastructure 2. PaaS (Platform as a Service): You manage app, they manage platform 3. SaaS (Software as a Service): Vendor manages everything (Microsoft 365, Salesforce, Slack)

Cloud Provider Responsibilities: - Physical security of data centers - Network infrastructure - Hardware maintenance - Some security controls (network, storage)

Customer Responsibilities: - IAM configuration (who can access what) - Network configuration (security groups, VPCs) - Encryption keys (customer-managed or provider-managed) - Application security

What This Means for Security: - Advantages: Offload infrastructure security to cloud provider, auto-scaling, built-in redundancy - Disadvantages: New threat landscape (cloud-specific attacks, misconfiguration)

Cloud-Specific Risks: - IAM overly permissive (everyone can do everything) - Public buckets/storage (data visible to internet) - Unused resources (exposed services) - Cross-account/cross-tenant misconfiguration - Cloud API abuse (stolen credentials)

Who Uses This: - Startups (no on-prem infrastructure needed) - SaaS vendors (cloud is core offering) - Organizations with distributed teams (no office) - Modern organizations building on cloud-native architecture

Against Incident Response Threats: - T-08 (Cloud-specific): Entirely new threat surface - T-13 (Misconfiguration): Most common cloud vulnerability - T-07 (API abuse): Cloud APIs are attack surface

Architecture Comparison Table

Selection Guidance for Teams

Choose Flat Network (ARCH-01) if:

• ✓ You're building a very small network (<20 people)
• ✓ You don't have sensitive data
• ✓ Your budget is extremely limited
• ✓ You want simplicity over security
• ✗ Not recommended for any organization with sensitive data or security requirements

Choose 3-Zone (ARCH-02) if:

• ✓ You're a medium-sized organization (50-500 people)
• ✓ You have web/email presence exposed to internet
• ✓ You have balance security and simplicity
• ✓ You want to limit lateral movement
• ✓ Most organizations should choose this

Choose Fully Isolated (ARCH-03) if:

• ✓ You're a large organization with security team
• ✓ You have strict compliance requirements (PCI-DSS, HIPAA, government)
• ✓ You assume breach and plan for containment
• ✓ You have budget for complexity
• ✓ You can maintain complex rule sets

Choose Cloud Hybrid (ARCH-04) if:

• ✓ You're transitioning to cloud
• ✓ You have variable workloads
• ✓ You want to try cloud without full commitment
• ✓ You have both on-premises and cloud operations

Choose Cloud First (ARCH-05) if:

• ✓ You're a new organization (no on-premises legacy)
• ✓ You want to avoid on-premises infrastructure cost
• ✓ You have a distributed, remote-first workforce
• ✓ You're building on cloud-native architecture

Architecture Impact on Other Modules

Incident Response

• Flat Network: Incident Response is very difficult (attacker spreads easily)
• 3-Zone: Normal difficulty (firewall blocks some lateral movement)
• Fully Isolated: Incident Response is harder (firewall rules block investigation traffic)
• Cloud Hybrid: New threat types (cloud-specific attacks)
• Cloud First: Cloud-specific investigation tools needed

Hardening

• Flat Network: Cannot implement segmentation defense
• 3-Zone: Can implement segmentation defense
• Fully Isolated: Segmentation is core architecture
• Cloud Hybrid: Cloud-specific hardening needed
• Cloud First: Cloud-native hardening strategies needed

Disaster Recovery

• Flat Network: Backup in same network, at risk
• 3-Zone: Backup in isolated segment (safer)
• Fully Isolated: Backup fully isolated (safest)
• Cloud Hybrid: Cloud backup provides geographically separate copy
• Cloud First: Cloud provider manages redundancy and backup

Gameplay Notes

Budget Impact

Choosing architecture affects remaining budget for servers and security devices: - ARCH-01 (Flat): 0 Budget cost, frees up budget for servers - ARCH-02 (3-Zone): 5 Budget cost, medium budget remaining - ARCH-03 (Fully Isolated): 12 Budget cost, significant budget consumed - ARCH-04 (Cloud Hybrid): 8 Budget cost, cloud connectivity cost - ARCH-05 (Cloud First): 6 Budget cost, low cost (cloud provider manages infrastructure)

Firewall Rule Complexity

Higher security architectures require more firewall rules: - ARCH-01: 0 rules needed (flat network) - ARCH-02: 10-20 rules (3-zone model) - ARCH-03: 50-100+ rules (fully isolated, per-system rules) - ARCH-04: 20-30 rules (cloud connectivity + on-prem) - ARCH-05: 10-15 rules (cloud provider manages most)

Print Instructions

1. Print on cardstock (250 gsm minimum)
2. Use distinct coloring by security level:
3. Red (Low Security): ARCH-01
4. Yellow (Medium Security): ARCH-02
5. Green (High Security): ARCH-03
6. Blue (Cloud Hybrid): ARCH-04
7. Purple (Cloud First): ARCH-05
8. Include a visual diagram on each card showing network layout
9. Cut along dotted lines
10. Create a decision tree reference card to help teams choose architecture

Decision Tree for Architecture Selection

Does your organization use cloud?
├─ No → Do you have >100 people?
│   ├─ No → Choose ARCH-01 (Flat) or ARCH-02 (3-Zone)
│   └─ Yes → Do you have compliance requirements?
│       ├─ No → Choose ARCH-02 (3-Zone)
│       └─ Yes → Choose ARCH-03 (Fully Isolated)
│
├─ Partially (hybrid) → Choose ARCH-04 (Cloud Hybrid)
│
└─ Yes, entirely cloud → Choose ARCH-05 (Cloud First)

Network Building Module: Architecture Cards Part of Incident Zero, a modular cybersecurity board game v2.2 - Playtest Edition

cards/network-building/core-deck/asset-cards.md

Network Building Module: Asset Cards

Version: 2.2 - Playtest Edition Last Updated: July 2026

Overview

Asset Cards represent business requirements or critical functions that the network must support. Each asset card describes a business need, and teams must ensure their network design includes appropriate servers/services to satisfy each requirement.

• Total Cards: 8 (ASSET-01 to ASSET-08)
• Used In: Network Building (to validate network design meets requirements)
• Also Used In: Incident Response (scenario context), Disaster Recovery (impact assessment)
• Purpose: Ensures network design addresses real business needs, not just security checkbox items

Asset Cards

ASSET-01: Email

Business Function: Internal and external email communication Criticality: High (nearly universal requirement) Impact if Down: Significant (communication stops, customer requests missed) Compliance Requirements: Email retention (SOX, GDPR), encryption (HIPAA, PCI-DSS)

Description: Organization needs reliable email system for internal communication and external customer contact. Email is both critical infrastructure and significant security risk (phishing, credential attacks, data exfiltration).

Network Requirements: - Server: Email Server (SRV-01) - Protection: Email Gateway (SEC-06) for phishing/malware filtering - Optional: Load Balancer if email server needs redundancy

Security Considerations: - Email is primary phishing attack vector (T-01 in Incident Response) - Email contains sensitive information (must be encrypted and access-controlled) - Email forwarding rules can be abused for data exfiltration - Email archive must be protected and retained per compliance requirements

Dependencies: - Requires Domain Controller for user authentication - Requires backup for email archive recovery - Integrates with SIEM for email security event logging

Team Design Validation: ✓ Must Include: Email Server or equivalent email service (cloud-based OK) ✓ Should Include: Email Gateway for threat filtering ✗ Failure Condition: No email capability = cannot satisfy Asset requirement

ASSET-02: Web

Business Function: Public-facing web application or website Criticality: Medium (business depends on it but alternatives exist) Impact if Down: Moderate (customers cannot access services, lost sales/engagement) Compliance Requirements: PCI-DSS (if payments), WCAG accessibility

Description: Organization has public web presence—either corporate website, e-commerce site, or customer portal. Web server is exposed to internet and primary target for web exploits (SQL injection, RCE, DDoS).

Network Requirements: - Server: Web Server (SRV-02) in DMZ - Protection: WAF (SEC-07) for application-layer attack prevention - Optional: Load Balancer (SEC-04) for redundancy and DDoS protection

Security Considerations: - Web servers have highest internet attack surface - Vulnerable to web exploits (T-02 Watering Hole, T-05 Kernel Exploit in Incident Response) - DDoS attacks can take down web server - Code injection can compromise entire application - Requires patching and web application security testing

Dependencies: - Often connects to Database (for dynamic content) - May require load balancer for redundancy - Requires SIEM monitoring for web security events

Team Design Validation: ✓ Must Include: Web Server (SRV-02) or cloud-hosted web service ✓ Should Include: WAF for attack protection ✓ Should Include: Load Balancer if redundancy needed ✗ Failure Condition: No web server = Asset unsatisfied

ASSET-03: Database

Business Function: Data storage and retrieval for critical business data Criticality: Very High (most sensitive business data) Impact if Down: Severe (business cannot operate, financial/customer impact) Compliance Requirements: PCI-DSS, HIPAA, GDPR, SOX (depending on data type)

Description: Centralized database for customer data, financial records, operational data. Database is most valuable attack target—contains the "crown jewels." Database compromise often defines loss condition in Incident Response.

Network Requirements: - Server: Database Server (SRV-03) in restricted/admin segment - Protection: Network Segmentation (SEC-08) to limit access - Optional: Backup Server (SRV-07) for recovery capability

Security Considerations: - Database is primary exfiltration target (T-10, T-11 in Incident Response) - SQL injection attacks compromise database - Credential abuse allows unauthorized access to sensitive data - Data exfiltration is often attack goal (customer PII, financial data) - Database compromise may be game-loss condition - Must have immutable backups for recovery from ransomware

Dependencies: - Requires strong authentication (MFA, password vault) - Requires Data Loss Prevention (DLP) to prevent exfiltration - Requires encryption at rest and in transit - Requires database activity monitoring (DAM) for audit

Team Design Validation: ✓ Must Include: Database Server or equivalent data store (Cloud Workload hosting is allowed but is a recorded risk) ✓ Should Include: Network Segmentation to isolate database access ✓ Should Include: Backup Server for disaster recovery ✗ Failure Condition: No database = Asset unsatisfied OR unsecured database access = audit finding

ASSET-04: File Storage

Business Function: Shared file storage for documents, projects, compliance records Criticality: High (business relies on shared documents) Impact if Down: Moderate-High (work stops, cannot access needed files) Compliance Requirements: Data retention (GDPR), data classification (HIPAA, PCI-DSS)

Description: Shared network file storage for collaborative work. File servers often contain mixed-sensitivity data (company policy next to customer PII next to trade secrets). Poorly secured file storage is source of data exfiltration and lateral movement.

Network Requirements: - Server: File Server (SRV-04) in protected segment - Protection: Network Segmentation (SEC-08) to limit file access - Optional: DLP (in Hardening module) to prevent sensitive file exfiltration

Security Considerations: - File servers are lateral movement target (T-04 in Incident Response) - SMB protocol allows attacker to enumerate shares and attempt access - Over-permissive file permissions = data exfiltration vector - Ransomware frequently targets file servers (T-11 in Incident Response) - File permissions audit is critical for compliance

Dependencies: - Requires Domain Controller for user authentication - Requires Network Segmentation to limit SMB access - Requires backup strategy (especially for ransomware recovery) - Requires file permission auditing

Team Design Validation: ✓ Must Include: File Server or cloud file storage (OneDrive, SharePoint, Google Drive) ✓ Should Include: Network Segmentation to restrict access ✓ Should Include: Backup for ransomware recovery ✗ Failure Condition: No file storage = Asset unsatisfied

ASSET-05: Identity

Business Function: User identity and access management Criticality: Very High (foundational to all access control) Impact if Down: Severe (cannot authenticate users, cannot operate) Compliance Requirements: MFA (various standards), audit logging (GDPR, SOX)

Description: Centralized identity system (Active Directory, Azure AD, Okta) that authenticates users and grants access to resources. Identity compromise is game-over scenario—attacker with access to identity system can impersonate any user.

Network Requirements: - Server: Domain Controller (SRV-05) in admin segment - Protection: Network Segmentation Switch (SEC-08) — keep the DC in an isolated admin zone - Optional: Second Domain Controller for redundancy (full price)

Security Considerations: - Domain Controller is most sensitive system (compromise = total infrastructure access) - Credential dumping attacks target DC (T-06 Mimikatz in Incident Response) - Compromised DC allows attacker to create backdoor accounts - Pass-the-hash attacks replay credentials from DC compromise - DC must be in isolated segment with strict access control

Dependencies: - Requires strong authentication (MFA for all DC access) - Requires privileged access workstation (PAW) for admin access - Requires immutable backup DC in separate location - Requires audit logging of all DC changes

Team Design Validation: ✓ Must Include: Domain Controller (on-premises or Azure AD) ✓ Should Include: Network Segmentation (isolated admin zone) ✓ Should Include: Second Domain Controller for redundancy (optional, full price) ✗ Failure Condition: No identity system = the Identity requirement is unsatisfied (design incomplete)

ASSET-06: Development

Business Function: Software development and testing environment Criticality: Medium (important but not production-critical) Requirement Strength: Recommended (v2.2) — may be satisfied by overloading another server (+1 Budget per extra service) Impact if Down: Low-Medium (development delays, but not immediate business impact) Compliance Requirements: Secrets management (API keys not hardcoded), code scanning

Description: Development and testing infrastructure where software developers build and test applications. Development environment is often overlooked security risk because developers prioritize speed over security.

Network Requirements: - Server: Development Server (SRV-06) in isolated development segment - Protection: Firewall rules prevent dev→prod lateral movement - Optional: Code repository (Git, GitHub) for version control

Security Considerations: - Development servers often contain production-like data (compliance violation) - Developers have broad access (weak access controls) - Test credentials and API keys in source code - Outdated/unpatched tools (developer tools not security tools) - Development system as lateral movement springboard to production - Source code repository is high-value target (intellectual property)

Dependencies: - Requires separate database from production (never use production data in dev) - Requires code review and secrets scanning - Requires firewall rules isolating dev from production - Requires MFA for code repository access

Team Design Validation: ✓ Should Include: Development Server, OR dev services overloaded onto another server (allowed, +1 Budget) ✓ Should Isolate: Dev network from production network ✓ Should Scan: Code for hardcoded secrets ✗ Failure Condition: Using production database in dev = data exposure/compliance violation

ASSET-07: Disaster Recovery

Business Function: Recovery capability for business continuity Criticality: Very High (determines if business survives major attack/disaster) Requirement Strength: Required (v2.2) Impact if Down: Catastrophic (cannot recover from major incident) Compliance Requirements: Backup retention, recovery SLA (RTO/RPO)

Description: Backup and disaster recovery capability. Organization needs ability to recover from data loss, ransomware, or disaster. Backup/recovery capability is often neglected until it's needed.

Network Requirements: - Server: Backup Server (SRV-07) with off-site backups - Protection: Immutable backups (WORM storage) - 3-2-1 Strategy: 3 copies, 2 media types, 1 off-site

Security Considerations: - Ransomware attacks target backup systems (T-11 in Incident Response) - Backup must be immutable (attacker cannot modify backups) - Backup must be off-site (local backup lost if data center destroyed) - Backup testing must be regular (quarterly minimum) - Backup credentials must be separate from domain (attacker cannot delete backups)

Dependencies: - Requires off-site backup location (geographically separated) - Requires immutable storage (WORM or cloud versioning) - Requires regular backup restore testing - Requires separate backup credentials

Team Design Validation: ✓ Must Include: Backup Server with off-site capability ✓ Must Test: Recovery procedures (quarterly) ✓ Must Implement: 3-2-1 strategy ✗ Failure Condition (v2.2): No Backup Server = automatic FAIL on the Disaster Recovery requirement, recorded as a CRITICAL gap (not an instant game loss — but ransomware in later modules becomes unrecoverable)

ASSET-08: VPN/Remote Access

Business Function: Secure remote access for employees and contractors Criticality: Medium (became High during COVID pandemic) Impact if Down: Moderate (remote workers cannot work) Compliance Requirements: MFA (various standards), encryption, audit logging

Description: VPN or similar remote access solution for employees working from home, traveling, or off-site. Remote access expands attack surface but is necessary for modern workforce.

Network Requirements: - Device: VPN Gateway (SEC-05) at network perimeter - Protection: MFA required for all VPN access - Optional: Conditional access policies (restrict access by device/location)

Security Considerations: - VPN is attractive attack target (Credential Abuse) - Weak VPN credentials easily brute-forced (must use MFA) - Compromised home computer connecting via VPN = internal network at risk - VPN traffic must be encrypted - VPN access must be logged and audited

Dependencies: - Requires Domain Controller for user authentication - Requires MFA (cannot rely on password alone) - Requires endpoint security on remote devices - Requires SIEM monitoring of VPN access

Team Design Validation: ✓ Should Include: VPN Gateway for remote access ✓ Must Implement: MFA for VPN access ✓ Should Monitor: VPN access logs in SIEM ✗ Failure Condition: Weak VPN security (no MFA) = credential attack vector

Asset Card Summary

Gameplay Integration

Network Building Module

Asset Cards drive network design decisions: 1. Display all 8 Asset Cards face-up on the table 2. Team designs network to satisfy each Asset 3. For each Asset, team must include appropriate Server and Defenses 4. Team validates: "Does our network design satisfy this Asset?"

Incident Response Module

Asset Cards provide scenario context: - Threat Orchestrator refers to Assets when describing scenarios - "Customer database is being exfiltrated" = reference ASSET-03 - "Email is compromised" = reference ASSET-01 - Assets help Blue Team understand what they're protecting

Disaster Recovery Module

Asset Cards determine impact assessment: - "How many critical systems are down?" = count "Very High" Assets affected - Recovery priority = order by Asset criticality - RTO (Recovery Time Objective) depends on which Assets must recover first

Expansion Notes

Asset Card Variants (for specific industries)

Financial Services Assets: - Trading System (real-time market data) - Payment Processing (external integrations) - Audit Trail (regulatory requirement)

Healthcare Assets: - Electronic Health Records (HIPAA-critical) - Prescription Management (pharmacy integration) - Patient Portal (external access)

Manufacturing Assets: - Industrial Control Systems (safety-critical) - Supply Chain Integration (vendor systems) - Engineering Data (intellectual property)

Retail Assets: - Point of Sale (transaction processing) - Inventory Management (supplier integration) - Customer Loyalty (marketing data)

Print Instructions

1. Print on cardstock (250 gsm minimum)
2. Color-code by criticality:
3. Red (Very High): ASSET-03, ASSET-05, ASSET-07
4. Orange (High): ASSET-01, ASSET-04
5. Yellow (Medium): ASSET-02, ASSET-06, ASSET-08
6. Include icons representing each asset:
7. Email: Envelope icon
8. Web: Globe icon
9. Database: Cylinder/drum icon
10. File: Folder icon
11. Identity: ID card / Shield icon
12. Development: Code brackets icon
13. Disaster Recovery: Backup/Archive icon
14. VPN: Lock/tunnel icon
15. Cut along dotted lines
16. Create a "Business Requirement Validation Card" that teams use to check off satisfied requirements

Team Validation Checklist (v2.2)

After team completes network design, verify each Asset is satisfied. The checklist only names components that can actually be purchased from the Network Building decks; items in parentheses are recommended, not mandatory.

• [ ] ASSET-01 (Email) - Email Server or Cloud Workload hosting email (+ Email Gateway recommended)
• [ ] ASSET-02 (Web) - Web Server or Cloud Workload hosting web (+ WAF and/or Load Balancer recommended)
• [ ] ASSET-03 (Database) - Database Server or Cloud Workload hosting the database (+ Network Segmentation recommended)
• [ ] ASSET-04 (File Storage) - File Server, or file storage on another server's spare capacity/overload (+ Network Segmentation recommended) — Recommended requirement
• [ ] ASSET-05 (Identity) - Domain Controller (+ Network Segmentation for an admin zone recommended)
• [ ] ASSET-06 (Development) - Development Server, or dev services via overload — Recommended requirement
• [ ] ASSET-07 (Disaster Recovery) - Backup Server — Required; no backup = automatic FAIL on this requirement
• [ ] ASSET-08 (VPN) - VPN Gateway — Recommended requirement

If any Asset is unsatisfied or under-defended: - Network design is incomplete - That Asset becomes a vulnerability in Incident Response - That Asset affects recovery time in Disaster Recovery

Network Building Module: Asset Cards Part of Incident Zero, a modular cybersecurity board game v2.2 - Playtest Edition

cards/network-building/standalone/business-requirement-cards.md

Network Building Standalone: Business Requirement Cards

Version: 2.2 - Playtest Edition Last Updated: July 2026

Overview

Business Requirement Cards drive the Network Building standalone game. One card is revealed at the start of each turn (Phase 1) and represents what the business demands this quarter. Teams must satisfy the requirement by end of the stated deadline or take the score penalty.

• Total Cards: 20 (REQ-01 to REQ-20)
• Used In: Network Building standalone game (one drawn per turn; 5-7 turns per game)
• Deadline: End of the current turn unless the card says otherwise
• Score Impact: Penalties and bonuses are applied to the team's final total score (tracked on the score sheet as they occur)
• Already satisfied counts: If the team's existing infrastructure already meets the requirement, it is satisfied at no extra cost

Business Requirement Cards

REQ-01: New Product Launch Website

Type: Growth Requirement: Marketing is launching a flagship product this quarter and needs a modern public website. Satisfied By: Web Server (7), OR web service hosted on a Cloud Workload (4) Score Impact: Missed: -5 points (launch flops; lost sales)

REQ-02: Customer Data Acquisition

Type: Growth / M&A Requirement: The executive team is acquiring a customer-data company. Two million customer records must land somewhere safe by end of quarter. Satisfied By: Database Server (10), OR database service hosted on a Cloud Workload (4) — cloud-hosting the crown jewels is a recorded risk Score Impact: Missed: -10 points (deal falls through)

REQ-03: Work-From-Home Program

Type: Workforce Requirement: HR is rolling out flexible work. Staff need secure remote access to internal systems. Satisfied By: VPN Gateway (9) Score Impact: Missed: -3 points (staff use risky workarounds; morale dips)

REQ-04: Remote Workforce Mandate

Type: Workforce Requirement: The board mandates support for a fully remote workforce: secure access AND central identity for every remote login. Satisfied By: VPN Gateway (9) AND Domain Controller (12) Score Impact: Missed: -5 points (shadow IT spreads across home offices)

REQ-05: HIPAA Compliance Mandate

Type: Compliance Requirement: A new healthcare client puts you in HIPAA scope. Regulators expect recoverable data and isolated sensitive systems. Satisfied By: Backup Server (9) AND network segmentation (Network Segmentation Switch (10), or Segmented/Fully Isolated architecture) Score Impact: Missed: -10 points (client walks; compliance exposure)

REQ-06: PCI Scope: Cardholder Data

Type: Compliance Requirement: You now process card payments. Cardholder data must live on a database that is walled off from the rest of the network. Satisfied By: Database Server (10) or cloud-hosted database, AND a Firewall (12) or Network Segmentation Switch (10) protecting it Score Impact: Missed: -10 points (acquirer threatens to pull card processing)

REQ-07: 99.9% Uptime SLA

Type: Operations Requirement: Your biggest customer signs a contract with a 99.9% uptime SLA on your public services. A single box is no longer good enough. Satisfied By: Load Balancer (8), OR a second server duplicating any business-critical service (full price) Score Impact: Missed: -5 points (SLA credits eat the margin)

REQ-08: M&A: Integrate Acquired Network

Type: Growth / M&A Requirement: The company you just bought needs its two core services absorbed into your infrastructure this quarter. Satisfied By: Two free capacity slots across your existing servers, OR deploy any new server this turn to host them (overloading is allowed at +1 Budget per extra service) Score Impact: Missed: -10 points (integration stalls; synergies evaporate)

REQ-09: Scale Email System

Type: Operations Requirement: Headcount doubled and the email system is groaning. Add headroom. Satisfied By: Second Email Server (8), Load Balancer (8), OR email hosted on a Cloud Workload (4) Score Impact: Missed: -5 points (mail delays; missed customer requests)

REQ-10: Security Audit Ordered

Type: Compliance Requirement: The audit committee orders an independent security audit. Auditors expect centralized visibility of security events. Satisfied By: SIEM (15), OR both IDS (10) and Email Gateway (6) Score Impact: Missed: -5 points (qualified audit opinion)

REQ-11: Board Demands IR Readiness

Type: Security Requirement: A competitor's breach is front-page news. The board demands demonstrable incident-detection capability. Satisfied By: IDS (10), IPS (14), OR SIEM (15) Score Impact: Missed: -10 points (board censure; CISO on thin ice)

REQ-12: Ransomware Wave in Sector

Type: Security Requirement: A ransomware variant is tearing through your industry. You need recoverable backups AND a way to spot the attack. Satisfied By: Backup Server (9) AND at least one of IDS (10) / IPS (14) / SIEM (15) Score Impact: Missed: -20 points (you are one bad click from catastrophe)

REQ-13: New Subsidiary Office

Type: Growth Requirement: A new regional office opens with no local infrastructure. Staff there must reach head-office systems securely. Satisfied By: VPN Gateway (9) Score Impact: Missed: -5 points (office runs on personal email and USB sticks)

REQ-14: E-Commerce Expansion

Type: Growth Requirement: Sales moves online. You need a public web presence AND protection against the web attacks that come with taking payments. Satisfied By: Web Server (7) or cloud-hosted web, AND WAF (11) Score Impact: Missed: -5 points (checkout is either absent or a breach waiting to happen)

REQ-15: Developer Hiring Spree

Type: Workforce Requirement: Engineering triples in size. Developers need somewhere to build and test that is not production. Satisfied By: Development Server (5), OR dev services overloaded onto an existing server (+1 Budget per extra service — allowed) Score Impact: Missed: -3 points (developers test in production; incidents follow)

REQ-16: Records-Retention Regulation

Type: Compliance Requirement: New regulation requires seven-year retention of business records: durable shared storage plus a recoverable copy. Satisfied By: File storage (File Server (6), or hosted on another server's capacity/overload) AND Backup Server (9) Score Impact: Missed: -5 points (regulator issues a compliance notice)

REQ-17: Single Sign-On Rollout

Type: Operations Requirement: Password chaos across a dozen apps. Leadership wants one identity for everything. Satisfied By: Domain Controller (12) Score Impact: Missed: -5 points (password reuse everywhere; helpdesk drowning)

REQ-18: Cyber-Insurance Renewal

Type: Security Requirement: Your insurer's renewal questionnaire wants proof of backups, phishing defense, and detection. Satisfied By: Backup Server (9) AND Email Gateway (6) AND at least one of IDS/IPS/SIEM Score Impact: Met: +5 points (premium drops). Missed: -5 points (premium spikes)

REQ-19: Threat-Intel Pilot

Type: Security (Opportunity) Requirement: Your ISAC offers to feature any member running deception technology in its quarterly report. Satisfied By: Honeypot Decoy (7) or Honeypot Network (8) Score Impact: Met: +5 points (industry kudos). Missed: 0 points (opportunity passes; no penalty)

REQ-20: Data-Center Consolidation

Type: Operations (Opportunity) Requirement: Finance wants the server-room footprint shrunk. Show that at least one business service runs in the cloud. Satisfied By: Any service hosted on a Cloud Workload (4) Score Impact: Met: +3 points (opex savings). Missed: -3 points (facilities costs balloon)

Requirement Card Summary

Gameplay Notes

Draw Rules

• Shuffle all 20 cards at setup; draw one per turn face-up in Phase 1
• A 5-7 turn game uses 5-7 of the 20 cards — every game sees a different mix
• For a gentler Beginner game, the Threat Orchestrator may pre-seed the deck (remove REQ-12 and one other -10 card)

Design Tension

Requirements are deliberately lumpy: some are satisfied by things every sane design already has (web, database), others punish narrow builds (detection, deception, redundancy). Teams that spend everything in turn 1 have no reserve when REQ-12 lands.

Print Instructions

1. Print on cardstock (250 gsm minimum)
2. Color-code by type:
3. Green (Growth/M&A): REQ-01, REQ-02, REQ-08, REQ-13, REQ-14
4. Blue (Workforce/Operations): REQ-03, REQ-04, REQ-07, REQ-09, REQ-15, REQ-17, REQ-20
5. Orange (Compliance): REQ-05, REQ-06, REQ-10, REQ-16
6. Red (Security): REQ-11, REQ-12, REQ-18, REQ-19
7. Cut along dotted lines
8. Shuffle into a single face-down deck for play

Network Building Standalone: Business Requirement Cards Part of Incident Zero, a modular cybersecurity board game v2.2 - Playtest Edition

cards/network-building/standalone/operational-event-cards.md

Network Building Standalone: Operational Event Cards

Version: 2.2 - Playtest Edition Last Updated: July 2026

Overview

Operational Event Cards are the random incidents, windfalls, and headaches of running infrastructure. One card is revealed each turn (Phase 2) of the Network Building standalone game, right after the Business Requirement.

• Total Cards: 16 (EVT-01 to EVT-16)
• Used In: Network Building standalone game (one drawn per turn; 5-7 turns per game)
• Effect Timing: Resolve immediately unless the card says otherwise
• Score Impact: Point penalties/bonuses apply to the team's final total score; Budget changes apply to the budget tracker immediately (Budget can never go below 0)
• Mitigation: Each card lists which designs shrug it off — good architecture turns bad events into non-events

Operational Event Cards

EVT-01: Email Server Failure

Type: Outage Effect: Your email server dies mid-quarter. Choose one: - Repair: Pay 5 Budget (emergency callout) - Ignore: -10 points (email down all quarter; users furious) Mitigated By: A second Email Server, or email hosted on a Cloud Workload — the redundant/cloud service carries the load: no cost, no penalty No email service at all? Nothing to break — but you already have bigger problems (see Capability scoring)

EVT-02: Traffic Spike

Type: Load Effect: Your product goes viral overnight. Public services are hammered. - Prepared (Load Balancer, CDN, or a duplicated web service): +5 points (you rode the wave; sales boom) - Unprepared: -5 points (site down during your biggest day) Mitigated By: Load Balancer (8), CDN (expansion CLOUD-04), or redundant web hosting

EVT-03: Phishing Wave

Type: Attack Effect: A targeted phishing campaign hits every inbox in the company. - Email Gateway deployed: +5 points (campaign filtered; nice catch) - No Email Gateway: -10 points (three credential sets stolen) Mitigated By: Email Gateway (6)

EVT-04: Cloud Vendor Outage

Type: Outage Effect: Your cloud provider has a region-wide outage this quarter. - If any required business service runs only in the cloud: -5 points (service dark; SLA breached) - Cloud services with an on-prem twin, or no cloud usage: no effect Mitigated By: On-prem redundancy for cloud-hosted services, or an all-on-prem design Lesson: Cloud is cheap, but concentration risk is real

EVT-05: Budget Cut

Type: Finance Effect: Fiscal crisis. Lose 5 Budget immediately (to a minimum of 0). Mitigated By: Nothing — but teams holding a contingency reserve absorb it without changing plans

EVT-06: Emergency Funds

Type: Finance Effect: A surprise rebate lands. Gain +10 Budget (one time). Mitigated By: N/A (enjoy it)

EVT-07: Security Grant

Type: Finance Effect: A government cyber-resilience grant is available to organizations with recoverable backups. - Backup Server deployed: Gain +5 Budget - No Backup Server: Nothing (you don't qualify) Mitigated By: N/A — this one rewards good hygiene

EVT-08: File Server Filling Up

Type: Capacity Effect: Shared storage hits 98% full. Choose one this turn: - Add capacity: Deploy any server to host file storage, or overload an existing server (+1 Budget per extra service) - Ignore: -5 points (service degradation; work grinds) Mitigated By: Spare capacity anywhere in your design (assign file storage to it at no cost) No file storage service at all? No effect — and no file-storage capability either

EVT-09: Honeypot Triggers

Type: Attack (Detected?) Effect: Someone has been quietly probing your network. - Honeypot Decoy or Honeypot Network deployed: +5 points (intruder caught red-handed in the decoy; access cut) - No honeypot: Nothing visible happens. Nothing visible ever happens. (No penalty — this time) Mitigated By: N/A — this is deception's payday

EVT-10: Insider Snooping

Type: Attack Effect: An employee is browsing systems far outside their role. - SIEM deployed OR network segmentation in place: +5 points (caught early / blocked at the zone boundary) - Neither: -5 points (months of quiet data access before anyone notices) Mitigated By: SIEM (15) or Network Segmentation Switch (10) / segmented architecture

EVT-11: Ransomware Strikes

Type: Attack (Severe) Effect: Ransomware detonates on an internal system. - Backup Server deployed: Pay 3 Budget for restore effort; if you also have detection (IDS/IPS/SIEM), you contained it fast: +5 points - No Backup Server: -20 points (pay the ransom or lose the data — either way it's ugly) Mitigated By: Backup Server (9); detection reduces blast radius

EVT-12: IT Staff Burnout

Type: Operations Effect: The ops team is running on fumes. This turn you may deploy at most ONE component. (Handling the turn's Business Requirement with an already-deployed component is fine.) Mitigated By: Designs that are already complete — teams who front-loaded their build barely notice

EVT-13: Vendor Promotion

Type: Opportunity Effect: A security vendor is clearing stock. The next security device you deploy this turn costs 2 less (minimum cost 1). Mitigated By: N/A — pure opportunity; skip it if nothing on the list fits your design

EVT-14: New Hire Needs Remote Access

Type: Workforce Effect: A key new hire works from another city and starts Monday. - VPN Gateway deployed: No effect (onboarding is routine) - No VPN Gateway: -3 points (they quit in week two, or worse: they improvise) Mitigated By: VPN Gateway (9)

EVT-15: Hardware Recall

Type: Outage Effect: A vendor recalls a faulty component. Pick one of your on-prem servers (Threat Orchestrator picks if you won't): - Pay 3 Budget for expedited replacement, OR - That server is offline this quarter — any requirement it alone satisfies counts as unmet this turn Mitigated By: Redundant servers or cloud-hosted twins (the twin covers the outage: no cost, no penalty). All-cloud designs are unaffected

EVT-16: Quiet Quarter

Type: Respite Effect: Nothing breaks. Nobody attacks. Finance leaves you alone. Use the breathing room to review your gaps. Mitigated By: N/A

Event Card Summary

Gameplay Notes

Draw Rules

• Shuffle all 16 cards at setup; draw one per turn face-up in Phase 2
• A 5-7 turn game uses 5-7 of the 16 cards
• Advanced difficulty option: remove EVT-06, EVT-07, and EVT-16 before shuffling (fewer breaks; matches the "disasters more frequent" rule)
• Beginner difficulty option: remove EVT-11 before shuffling

Design Tension

Events reward the same things the scoring rewards — redundancy, detection, backups, and a contingency reserve — so mitigation is never wasted spend. The nastiest cards (EVT-11) are exactly why hoarding zero-reserve builds and backup-free builds both hurt.

Print Instructions

1. Print on cardstock (250 gsm minimum)
2. Color-code by type:
3. Red (Attack): EVT-03, EVT-09, EVT-10, EVT-11
4. Orange (Outage/Capacity): EVT-01, EVT-04, EVT-08, EVT-15
5. Blue (Finance/Operations): EVT-05, EVT-06, EVT-07, EVT-12
6. Green (Opportunity/Respite): EVT-02, EVT-13, EVT-14, EVT-16
7. Cut along dotted lines
8. Shuffle into a single face-down deck for play

Network Building Standalone: Operational Event Cards Part of Incident Zero, a modular cybersecurity board game v2.2 - Playtest Edition

cards/network-building/expansion-deck/legacy-systems.md

Network Building Module: Legacy Systems (Expansion)

Version: 2.1 - Balanced & Refined Edition Last Updated: October 2025

Overview

Legacy System Cards extend the Network Building module with specialized systems that many organizations still operate but cannot easily patch or upgrade.

• Total Cards: 4 (LEGACY-01 to LEGACY-04)
• Used In: Network Building expansion (adds complexity and challenge)
• Assumption: Legacy systems cannot be patched or upgraded due to vendor EOL (End of Life) or critical business dependency
• Design Philosophy: Cannot defend legacy system itself; must isolate and defend around it

Legacy System Cards

LEGACY-01: Mainframe System

Type: Legacy Business-Critical Infrastructure Cost: 15 Budget (expensive to operate) Complexity: 4/4 (extremely complex, specialized expertise required) Availability Requirement: 99.95% (financial/mission-critical) Supported Operating System: Mainframe OS (z/OS, VSE, VM), Not patchable

Description: Large centralized mainframe computer running business-critical applications. Banks, insurance companies, government agencies, and utilities often depend on mainframes for core operations. Mainframes are designed for availability and stability, but security model is outdated (predates internet security concerns).

Key Characteristics: - Age: Often 20-30+ years old - Software: Custom applications written in COBOL or other legacy languages - Security: Perimeter security model (assume all internal traffic is trusted) - Expertise: Few experts remain (knowledge leaving the industry) - Vendor Support: Vendor may no longer exist; in-house expertise critical - Cost of Replacement: $5M-100M+ (impossible to replace)

Key Concerns: - No regular security patches available (vendor EOL) - Known CVEs published but cannot be patched - Legacy protocols (unencrypted connections, weak authentication) - Access control systems predate modern security standards - Directly connected to corporate network (not isolated) - Often contains entire organization's critical data - Business process depends on it (replacement would take years)

Defense Strategy (Cannot Fix, Must Isolate): - Network Isolation: Mainframe in restricted segment, minimal connectivity - Firewall Rules: Only authorized systems can connect to specific ports - Monitoring: SIEM must monitor all mainframe connections (detect anomalies) - Assumption of Breach: Assume mainframe will be compromised; defend everything else - No Direct User Access: Users should not directly access mainframe (access via secure application tier) - Log Aggregation: All mainframe activities logged centrally (immutable audit trail)

Network Interactions: - Requires: Firewall rules isolating mainframe - Requires: Network Segmentation to restrict access - Requires: SIEM monitoring for anomaly detection - Incompatible with: Direct internet access (perimeter firewall only) - Incompatible with: Cloud integration (data residency and connectivity issues)

Incident Response Impact: - If mainframe is compromised, entire organization may be compromised - Mainframe compromise may be immediate game-loss in Incident Response - Legacy authentication means attacker can move freely once inside - Mainframe contains sufficient data to be primary exfiltration target

Team Design Validation: - ✓ If including mainframe: must include Network Segmentation + Firewall - ✓ Must include SIEM for monitoring - ✗ Failure: Direct user access to mainframe increases risk - ✗ Failure: Cloud connectivity to mainframe violates security boundary

LEGACY-02: Custom Business Application

Type: Legacy Business-Critical Software Cost: 8 Budget (application licensing/support) Complexity: 3/4 (difficult to update or replace) Availability Requirement: 99% (business depends on it) Operating System: Windows Server 2008/2012, or older Linux, or proprietary OS

Description: Specialized business application written by external vendor or in-house team that is no longer maintained. Application may be: - Accounting system (custom financial software) - Manufacturing control system (production scheduling) - Insurance claims system - Legal case management system - ERP (Enterprise Resource Planning) system

The application is mission-critical but: - Vendor no longer provides updates (company went out of business, or stopped supporting) - Cost to replace: $500K-$5M+ (economically infeasible) - Business process deeply embedded in application (replacement would require major restructuring) - Knowledge of application is scarce (original developers left, documentation poor)

Key Characteristics: - Age: Often 10-20 years old - Language: Written in outdated languages (Visual Basic 6, old Java, COBOL) - Vendor: Vendor may no longer exist; purchased "as-is" - Customization: Heavily customized for organization (not standard product) - Expertise: Few people understand the code - Database: Proprietary or very old database (SQL Server 2005, Oracle 10g, etc.) - Integration: Deeply integrated into business workflow

Key Concerns: - Application may contain hardcoded credentials - Application may store passwords in plaintext - Application may use unencrypted connections to database - Application may have SQL injection vulnerabilities (pre-2005 development) - Application may lack audit logging - Upgrading operating system may break application - Patches to operating system may be incompatible with application - Security testing tools may break application

Defense Strategy (Isolate and Monitor): - Application Server Isolation: Application in restricted segment - Database Isolation: Application database encrypted and access-controlled - Network Firewall: Only users/systems needing application can access it - No Direct Internet Access: Application never exposed to internet - SIEM Monitoring: All application access logged and monitored - Assumption: Assume application has SQL injection or similar vulnerabilities; defend database - Access Control: Limit who can use application (risk vs. benefit analysis)

Network Interactions: - Requires: Application Server (SRV-06 or custom server) - Requires: Database Server isolated from other systems - Requires: Firewall rules limiting access - Requires: SIEM monitoring application access - Incompatible with: Cloud hosting (licensing, data residency issues)

Incident Response Impact: - Custom application vulnerability could be exploited for lateral movement - Application database compromise exposes sensitive business data - Application logs may be missing or inaccessible - Attacker may extract application source code

Team Design Validation: - ✓ If including custom application: must isolate application + database - ✓ Must limit user access (principle of least privilege) - ✓ Must monitor application access in SIEM - ✗ Failure: Direct internet access to application increases attack surface - ✗ Failure: Weak access controls allow unauthorized application access

LEGACY-03: Industrial Control System (ICS)

Type: Operational Technology (OT) / Safety-Critical Cost: 12 Budget (specialized equipment) Complexity: 4/4 (extremely specialized, safety implications) Availability Requirement: 99.9%+ (safety-critical, cannot fail) Operating System: Proprietary Industrial OS, real-time OS, or very old Linux

Description: Specialized system that controls physical machinery, manufacturing processes, power generation, utilities, or other critical infrastructure. Examples: - Manufacturing: Assembly line control, robotic systems - Utilities: Power distribution, water treatment, smart grid - Building Systems: HVAC, access control, fire systems - Transportation: Traffic signals, rail systems

Industrial Control Systems (ICS) are purpose-built for reliability and real-time control, not information security. They predate cybersecurity concerns.

Key Characteristics: - Purpose: Controls physical machinery or critical infrastructure - Real-time: Must respond in milliseconds (cannot tolerate latency) - Reliability: Designed for 99.99%+ availability - Security: Predates modern security (no authentication, no encryption) - Isolation: Historically air-gapped (not connected to corporate network) - Expertise: Requires specialized engineering expertise (electrical, mechanical, control systems) - Cost of Downtime: $10K-$1M+ per minute of downtime - Lifecycle: 10-30 year lifespan (different than IT systems)

Key Concerns (from IT Perspective): - Cannot be patched (real-time systems cannot tolerate OS updates) - Cannot tolerate intrusion detection (latency would affect operations) - Cannot install EDR/antivirus (would slow down real-time responses) - Cannot use modern encryption (adds latency) - Uses legacy protocols (Modbus, Profibus, DNP3 - no security built-in) - Often air-gapped; now being connected to corporate network (exposes vulnerability) - If compromised, physical safety implications (machinery malfunction, power outage, etc.)

Key Concerns (from ICS Perspective): - Availability is paramount (security is secondary) - Adding security controls might affect uptime - ICS engineers don't understand IT security - IT security tools and practices may break ICS - ICS changes must be tested extensively (downtime is unacceptable)

Defense Strategy (Strict Isolation): - Never Connect to Corporate Network: ICS should remain air-gapped - If Connection Required: Use unidirectional gateway (ICS can send data out, nothing comes in) - Network Segmentation: ICS in completely isolated segment from corporate systems - No User Internet Access from ICS: ICS workstations cannot browse internet - Physical Security: ICS room locked, access restricted to authorized engineers - Monitoring: Use ICS-specific monitoring tools (not traditional SIEM) - Assumption: Assume ICS network will be compromised; focus on preventing spread to corporate

Network Interactions: - Isolation: Complete separation from corporate network (air-gapped preferred) - If Bridge Required: Unidirectional gateway (one-way data flow) - Incompatible with: Corporate firewall (ICS cannot tolerate intrusion detection latency) - Incompatible with: EDR/Antivirus (would slow down real-time control) - Incompatible with: Cloud integration (real-time latency requirements)

Incident Response Impact: - ICS compromise may cause physical safety issues (priority = physical safety over data) - ICS compromise may cause production shutdown (significant financial impact) - ICS security investigation requires specialized expertise (not standard IT) - ICS forensics may disrupt operations (cannot preserve evidence if it affects safety)

Team Design Validation: - ✓ If including ICS: must isolate ICS from corporate network - ✓ Must use unidirectional gateway if connectivity required - ✓ Must NOT install traditional IT security tools on ICS - ✗ Failure: Corporate network connected to ICS without isolation - ✗ Failure: ICS exposed to internet or untrusted networks - ✗ Failure: IT security tools degrading ICS real-time performance

LEGACY-04: Obsolete Operating System

Type: Legacy Infrastructure Running Unsupported OS Cost: 5 Budget (cheap hardware, but difficult to support) Complexity: 3/4 (difficult to manage with modern security tools) Availability Requirement: 80-95% (business can tolerate occasional downtime) Operating System Examples: Windows XP, Windows Server 2003, old Linux kernels, custom UNIX variants

Description: Systems running operating systems that are no longer supported by vendor or open-source community. Vendor has stopped releasing security patches. Public exploit code for known vulnerabilities exists and is freely available.

Examples: - Windows XP (support ended 2014) - Windows Server 2003 (support ended 2015) - Linux 2.4/2.6 kernels (EOL for 10+ years) - Solaris 8/9 (Sun Microsystems EOL) - Other commercial UNIX variants EOL decades ago

Key Characteristics: - Support: No security patches from vendor - Exploits: All known vulnerabilities are published (no zero-days) - Tools: Modern security tools often don't run on EOL OS - Compatibility: Cannot run modern applications - Patching OS: OS upgrade would break dependent applications - Cost of Replacement: Application replacement cost makes OS upgrade prohibitive

Key Concerns: - All known vulnerabilities can be exploited (no patches) - Public exploits readily available (trivial for attacker) - Modern malware often targets these systems (profitable attacks) - Ransomware frequently targets EOL systems (known vulnerabilities) - System cannot run modern antivirus/EDR (not compatible) - System cannot use modern encryption protocols - System is prone to exploitation for lateral movement into modern systems

Defense Strategy (Assume Compromise, Isolate): - Assumption: Assume EOL system will be compromised (all vulnerabilities are public) - Network Isolation: EOL system in restricted segment, minimal connectivity - Firewall Rules: Only necessary traffic to/from EOL system - No Lateral Movement: Firewall rules prevent movement from EOL system to others - No Sensitive Data: Do not store sensitive data on EOL system - Monitoring: SIEM monitors EOL system closely (detect compromise signs) - Replacement Planning: Have timeline to replace/upgrade EOL system - Physical Security: Restrict physical access to EOL system

Network Interactions: - Isolation: EOL system in isolated segment - Firewall: Strict firewall rules (default deny) - Monitoring: SIEM alerts on any unusual EOL system activity - No Cloud Access: EOL system does not connect to cloud systems - Air-gapped Preferred: If possible, keep EOL system air-gapped

Incident Response Impact: - EOL system compromise may be inevitable (all vulnerabilities public) - Attacker will target EOL system as entry point (easier than hardened systems) - EOL system may be used as staging point for attacks on hardened systems - Forensics on EOL system may be difficult (no modern forensics tools support it)

Team Design Validation: - ✓ If including EOL system: must isolate completely - ✓ Must have replacement timeline - ✓ Must NOT store sensitive data on EOL system - ✗ Failure: No network isolation for EOL system - ✗ Failure: Sensitive data on EOL system - ✗ Failure: EOL system has same network privileges as modern systems

Legacy Systems Card Summary

Design Philosophy

Key Principle: Cannot Fix, Must Isolate

Legacy systems cannot be fixed through normal security controls: - Cannot patch (vendor no longer supports) - Cannot upgrade OS (breaks dependent applications) - Cannot install modern security tools (incompatible) - Cannot redesign (cost prohibitive)

Instead, organizations must: 1. Isolate the legacy system: Separate network segment, strict firewall rules 2. Monitor closely: SIEM alerts on any anomalous activity 3. Assume compromise: Design defenses assuming legacy system will be compromised 4. Plan replacement: Have timeline to eventually replace legacy system 5. Limit exposure: Do not connect sensitive systems to legacy system network

Gameplay Impact

Network Design Complexity

Including legacy systems significantly increases network design complexity: - Must add firewall rules for each legacy system - Must add network segmentation - Must add SIEM monitoring - Budget is constrained (legacy systems are expensive to operate)

Incident Response Complications

If Incident Response follows Network Building: - Legacy systems are easier attack targets (known vulnerabilities) - Attacker will likely compromise legacy system first - Legacy system compromise may lead to lateral movement - Legacy system may lack proper logging (forensics is difficult)

Strategic Trade-off

Teams face strategic decision: Include legacy systems or avoid them? - Include Legacy Systems: Realistic, mirrors real organizations, adds challenge - Avoid Legacy Systems: Simpler network design, but unrealistic - Team Decision: Should reflect organization's actual legacy system situation

When to Use Legacy System Cards

Use in Network Building Expansion if:

• Playing with experienced teams
• Want realistic organizational network design
• Want to teach legacy system security challenges
• Want to increase network design complexity

Skip Legacy System Cards if:

• Playing with beginners (too much complexity)
• Want to focus on modern security practices
• Want shorter, simpler network design phase
• Limited play time (legacy systems add design time)

Print Instructions

1. Print on cardstock (250 gsm minimum)
2. Use color scheme indicating "difficult/expensive":
3. Dark Red/Brown (Difficult): LEGACY-01, LEGACY-03
4. Orange (Moderate): LEGACY-02, LEGACY-04
5. Include warning icons (exclamation mark, caution symbol) on cards
6. Cut along dotted lines
7. Create a "Legacy System Reference Card" with isolation requirements and key facts

Possible Future Expansions

Additional Legacy System Cards: - LEGACY-05: Mainframe Tape Backup System (disaster recovery, retention archiving) - LEGACY-06: Proprietary Database System (custom data storage, vendor extinct) - LEGACY-07: Dedicated PBX Telephony System (VoIP not yet viable) - LEGACY-08: Custom SCADA System (industrial automation, not standard ICS)

Network Building Module: Legacy Systems (Expansion) Part of Incident Zero, a modular cybersecurity board game v2.1 - Balanced & Refined Edition

cards/network-building/expansion-deck/cloud-variants.md

Network Building Module: Cloud Variants (Expansion)

Version: 2.1 - Balanced & Refined Edition Last Updated: October 2025

Overview

Cloud Variant Cards extend the Network Building module with advanced cloud deployment options and cloud-native technologies beyond the basic Cloud Workload card in the core deck.

• Total Cards: 4 (CLOUD-01 to CLOUD-04)
• Used In: Network Building expansion (for cloud-first and advanced deployments)
• Prerequisite: Understand ARCH-04 (Cloud Hybrid) or ARCH-05 (Cloud First)
• Design Philosophy: Cloud variants offer different trade-offs: cost, complexity, security, scalability

Cloud Variant Cards

CLOUD-01: Containerized Microservices

Type: Cloud-Native Architecture Cost: 6 Budget (container orchestration platform) Complexity: 3/4 (requires Kubernetes expertise) Supported Platforms: AWS ECS, Azure Container Instances, Google Cloud Run, Kubernetes Application Type: Modern cloud-native applications built as multiple small services

Description: Applications broken into microservices running in containers (Docker). Each service is a separate container that can scale independently. Containers are orchestrated by a platform (Kubernetes, Docker Swarm, ECS).

Key Characteristics: - Services: Application broken into small, focused services - Containers: Each service runs in a container (isolated environment) - Orchestration: Platform automatically manages container deployment, scaling, and recovery - Scalability: Each service can scale independently based on demand - DevOps: Infrastructure and code are tightly integrated (Infrastructure as Code) - Cloud-Native: Built for cloud (ephemeral resources, auto-scaling, auto-healing)

Key Advantages: - Scalability: Auto-scale individual services based on load - Resilience: Container failure doesn't affect entire application - Efficiency: Containers share OS kernel (more efficient than VMs) - Velocity: Deploy microservices independently (faster development) - Cost: Pay only for resources used (serverless principles)

Key Concerns (Security Perspective): - Complexity: Many moving parts, many potential attack surfaces - Container Escape: Attacker in one container might escape to host - Supply Chain: Container images come from registries (may be compromised) - Secrets Management: Container needs credentials/API keys (risk of exposure) - Lateral Movement: Multiple containers in same cluster, network policies must isolate - Compliance: Tracing data across microservices complicated - Logging: Distributed across many containers (aggregation required)

Defense Strategy: - Container Runtime Security: Monitor and restrict container behavior (Falco, Sysdig) - Image Scanning: Scan images for vulnerabilities before deployment - Network Policies: Kubernetes network policies restrict inter-service communication - Pod Security Policies: Restrict what containers can do (no privileged escalation) - Registry Security: Scan images in registry, require signing - Secrets Vault: Use HashiCorp Vault or cloud native secrets (not environment variables) - SIEM Integration: Aggregate logs from all containers

Network Interactions: - Works with: Cloud-native architecture (ARCH-05) - Requires: Container orchestration platform (Kubernetes) - Requires: Container registry (Docker Hub, ECR, ACR, GCR) - Requires: Secrets management (HashiCorp Vault, AWS Secrets Manager) - Integrates with: Microservices architecture (multiple services)

Incident Response Impact: - Container compromise may be isolated (if network policies work) - Container escape would give attacker access to host - Supply chain attack on container images affects all deployments - Distributed nature makes forensics complex - Log aggregation essential for investigation

Team Design Validation: - ✓ If including microservices: must include container runtime security - ✓ Must include image scanning + signing - ✓ Must include network policies - ✓ Must include secrets management - ✗ Failure: Hardcoded secrets in containers - ✗ Failure: No image signing/scanning - ✗ Failure: No container network policies

CLOUD-02: Serverless/Function-as-a-Service

Type: Cloud-Native Compute (Abstracted Infrastructure) Cost: 3 Budget (minimal infrastructure management) Complexity: 2/4 (simple from ops perspective, but different security model) Supported Platforms: AWS Lambda, Azure Functions, Google Cloud Functions, IBM Cloud Functions Use Cases: Event-driven processing, API backends, scheduled jobs, data transformation

Description: Functions deployed to serverless platform. You write code, platform handles scaling, infrastructure, and execution. You pay only for actual execution time (milliseconds).

Key Characteristics: - No Infrastructure: You don't manage servers/containers/VMs - Event-Driven: Functions triggered by events (API call, message queue, schedule, etc.) - Auto-Scaling: Automatically scales from zero to thousands of concurrent executions - Stateless: Functions should not maintain state (state in database/message queue) - Time-Limited: Function has timeout (usually 15 minutes max) - Cost Model: Pay per execution millisecond (very cheap if infrequently called)

Key Advantages: - Simplicity: Write code, deploy, done (no servers to manage) - Cost: Pay only for execution time (not for idle servers) - Scalability: Automatic scaling without configuration - Velocity: Rapid deployment cycle (seconds) - Reduced Attack Surface: No server to compromise (provider manages infrastructure)

Key Concerns (Security Perspective): - Dependency Management: Function depends on libraries (vulnerable packages) - Secrets in Environment Variables: Function needs credentials (hardcoded or env vars) - Supply Chain: Libraries may be compromised (dependency attack) - Monitoring Blind Spot: Functions are ephemeral (logs must be aggregated) - Cold Start Attacks: Function startup time can leak information - Privilege Escalation: Function may have overly broad IAM permissions - Denial of Service: Function can be invoked repeatedly (cost/resource attack) - Compliance: Difficult to audit function execution (multi-tenant platform)

Defense Strategy: - Dependency Scanning: Scan dependencies for vulnerabilities - Secrets Management: Use cloud secrets manager (not environment variables) - IAM Least Privilege: Function has minimum required permissions - CloudTrail Logging: Log all function invocations - VPC Integration: Function connects to VPC if accessing private resources - Rate Limiting: Prevent function invocation DoS - Input Validation: Strict validation of all inputs (injection attacks) - Library Pinning: Pin exact library versions (prevent supply chain attacks)

Network Interactions: - Works with: Cloud-first architecture (ARCH-05) - Integrates with: API Gateway (exposes function as HTTP endpoint) - Integrates with: Message Queues (event-driven triggers) - Requires: Secrets Manager (for credentials) - Optional: VPC integration for private resource access

Incident Response Impact: - Function compromise is possible (code vulnerability or dependency) - Function invocation logs are critical (only audit trail) - Multi-tenant platform may complicate forensics - Dependency vulnerability affects all functions using vulnerable library - Distributed nature makes understanding attack chain difficult

Team Design Validation: - ✓ If including serverless: must include secrets management - ✓ Must include dependency scanning - ✓ Must include IAM least privilege configuration - ✗ Failure: Secrets in environment variables - ✗ Failure: Overly broad function permissions - ✗ Failure: No input validation

CLOUD-03: Database-as-a-Service (Managed Database)

Type: Cloud-Managed Data Layer Cost: 5 Budget (pay per GB + IO operations) Complexity: 1/4 (cloud provider manages infrastructure) Supported Platforms: AWS RDS, Azure SQL Database, Google Cloud SQL, MongoDB Atlas, DynamoDB Database Types: Relational (SQL Server, PostgreSQL, MySQL, Oracle), NoSQL (MongoDB, DynamoDB, Cassandra)

Description: Database managed entirely by cloud provider. You provision database capacity, cloud provider handles: backups, patching, failover, replication, encryption, monitoring.

Key Characteristics: - Managed: Cloud provider manages infrastructure (patches, backups, upgrades) - Automated Backup: Point-in-time recovery (no manual backup configuration) - Replication: Automatic geo-replication for disaster recovery - Encryption: Encryption at rest and in transit (built-in) - Scaling: Can scale storage and compute without downtime - Monitoring: Built-in monitoring and alerting - Compliance: Provider maintains compliance certifications (SOC 2, HIPAA, PCI-DSS)

Key Advantages: - Reliability: Provider manages availability (99.99% SLA typical) - Security: Provider manages patching and security updates - Compliance: Provider handles compliance certifications - Cost: No ops team needed to maintain database - Disaster Recovery: Automated backups and geo-replication - Scalability: Transparent scaling without downtime

Key Concerns (Security Perspective): - IAM Configuration: Database access via IAM roles (misconfiguration exposes data) - Network Exposure: Database may be internet-accessible (must restrict) - Encryption Keys: Cloud provider manages keys (limited control) - Audit Logging: Must enable audit logging (not always on by default) - Data Residency: Where is data stored geographically? - Backup Security: Backups must be encrypted and access-controlled - Supply Chain: Vendor is now part of attack surface - Multi-Tenant: Data may share hardware with other customers (trust model)

Defense Strategy: - Network Isolation: Database accessible only from application (not internet) - IAM Least Privilege: Only application has access (not human users) - Encryption Keys: Use customer-managed keys (not provider-managed) - Audit Logging: Enable all audit logging (schema changes, access, queries) - Monitoring: Set up alerting on suspicious queries (large exports, drops, etc.) - Backup Encryption: Verify backups are encrypted - Access Control: Disable public IP, use private endpoints only - Secrets Management: Database credentials in secrets vault (not hardcoded)

Network Interactions: - Works with: Cloud-first architecture (ARCH-05) or Cloud Hybrid (ARCH-04) - Integrates with: Application tier (via private endpoint) - Requires: Secrets management (for credentials) - Incompatible with: On-premises applications (latency/connectivity issues)

Incident Response Impact: - Database compromise likely primary attack goal (most valuable data) - Cloud provider manages baseline security (shifts responsibility model) - Audit logs are critical evidence (may be only forensics available) - Backup verification essential (can you restore to pre-attack state?) - Multi-tenant concerns for sensitive investigations

Team Design Validation: - ✓ If including managed database: must use private endpoints (not public) - ✓ Must enable audit logging - ✓ Must use customer-managed encryption keys - ✓ Must restrict database IAM permissions - ✗ Failure: Database public IP exposed to internet - ✗ Failure: Overly broad IAM permissions (anyone can access) - ✗ Failure: Audit logging disabled

CLOUD-04: Content Delivery Network (CDN)

Type: Edge Computing / Performance Enhancement Cost: 4 Budget (pay per GB transferred + requests) Complexity: 2/4 (configuration required, but well-documented) Supported Platforms: CloudFlare, AWS CloudFront, Azure CDN, Google Cloud CDN, Akamai Use Cases: Static assets (images, JS, CSS), web application acceleration, DDoS mitigation

Description: CDN caches content across globally distributed edge servers. When users request content, they get it from nearest edge server (fast). Reduces load on origin server and improves user experience.

Key Characteristics: - Distributed Caching: Content cached at 100+ edge locations worldwide - Fast Delivery: Users get content from nearest edge (milliseconds) - Origin Protection: Origin server behind CDN (hides IP, reduces load) - DDoS Protection: CDN absorbs DDoS attacks before reaching origin - SSL/TLS Termination: CDN handles encryption (origin can use HTTP) - Rate Limiting: Can rate-limit requests per IP - Security Headers: Can inject security headers (HSTS, CSP, etc.)

Key Advantages: - Performance: Content delivery 100x faster globally - DDoS Protection: Built-in DDoS mitigation - Security: Origin IP hidden, security scanning at edge - Cost Efficiency: Reduces origin server bandwidth costs - Geo-Location: Can route users to different content based on location

Key Concerns (Security Perspective): - Cache Poisoning: Attacker poisons CDN cache with malicious content - Origin Bypass: Attacker finds origin IP, bypasses CDN security - SSL Stripping: CDN can decrypt traffic (must trust CDN provider) - Cookie Security: Sensitive cookies may be cached (GDPR/privacy issue) - Personalization: Cached content loses personalization (may expose user data) - Configuration Mistakes: Wrong cache settings may cache sensitive content - Origin Protection: Still need to protect origin server (CDN is not complete solution) - Bot Attack: Attackers can still target origin through CDN

Defense Strategy: - Cache Settings: Do not cache sensitive content (set cache headers) - Origin Protection: Implement Web Application Firewall (WAF) on origin - Rate Limiting: Configure CDN rate limiting rules - DDoS Settings: Enable DDoS protection features - SSL Validation: Verify SSL certificates (prevent MITM) - Geoblocking: Block traffic from unwanted regions (geo-restrictions) - Security Headers: Implement security headers (HSTS, CSP, X-Frame-Options) - Origin IP Hiding: Use origin concealment (hide real IP) - Monitoring: Monitor for suspicious CDN patterns

Network Interactions: - Works with: Web application (static assets + dynamic content) - Works with: Cloud Hybrid (ARCH-04) or Cloud First (ARCH-05) - Complements: Web Application Firewall (WAF) - Optional with: Infrastructure (performance enhancement, not required)

Incident Response Impact: - CDN compromise could distribute malware to all users (supply chain attack) - Cache poisoning affects entire user base - Origin IP exposure could enable direct attacks on origin server - CDN logs are evidence (attacker activity visible in CDN analytics) - DDoS attack visibility (CDN shows attack patterns)

Team Design Validation: - ✓ If including CDN: must configure cache headers correctly - ✓ Must enable security features (DDoS, WAF, rate limiting) - ✓ Should hide origin IP - ✗ Failure: Caching sensitive/personalized content - ✗ Failure: Disabled security features - ✗ Failure: Origin IP exposed

Cloud Variants Card Summary

Design Philosophy

Key Principle: Different Cloud Services, Different Security Models

Each cloud variant represents different architectural choices: - Microservices: Scalability + complexity (many attack surfaces) - Serverless: Simplicity + different threat model (function-level security) - Managed Database: Reliability + shared responsibility (provider + customer) - CDN: Performance + edge computing (distributed security)

Organizations use combinations of these services: - Serverless functions backed by managed database (simple, scalable, reliable) - Microservices deployed globally via CDN (scalable, fast, available) - Mix of serverless and containers (different workloads, different approaches)

Gameplay Impact

Network Design Flexibility

Cloud variants add flexibility to network design: - Can build entirely on serverless (very simple, minimal infrastructure) - Can mix serverless + containers (different workloads) - Can add CDN for global distribution - Can use managed database for all data needs

Cost Considerations

Cloud variants have different cost models: - Serverless: Cheap if used occasionally, expensive if always running - Microservices: Scale-to-zero not available (always running cost) - Managed Database: Scale with usage (can get expensive) - CDN: Cheap for low traffic, expensive for high traffic

Complexity Trade-offs

Cloud variants trade operational complexity for different concerns: - Serverless: No ops burden, but security mindset different - Microservices: Ops burden (Kubernetes), but powerful scalability - Managed Database: No ops burden, but IAM misconfiguration risk - CDN: Config once, then mostly set-and-forget

When to Use Cloud Variants

Use in Network Building Expansion if:

• Playing with experienced teams
• Want to explore cloud-native architectures
• Want to teach different cloud service trade-offs
• Have time for complex cloud design discussions

Skip Cloud Variants if:

• Playing with beginners (too much cloud complexity)
• Want simpler network design
• Not focused on cloud (still on-premises focused)
• Limited play time

Print Instructions

1. Print on cardstock (250 gsm minimum)
2. Color-code by deployment type:
3. Blue (Containers): CLOUD-01
4. Green (Serverless): CLOUD-02
5. Purple (Data): CLOUD-03
6. Orange (Delivery): CLOUD-04
7. Include cloud provider logos if desired (AWS, Azure, GCP)
8. Cut along dotted lines
9. Create a "Cloud Architecture Reference Card" comparing services

Integration with Core Cloud Cards

Cloud Core Deck (from core-deck/architecture-cards.md)

• ARCH-04 (Cloud Hybrid): Can use any of these cloud variants
• ARCH-05 (Cloud First): Typically uses combination of these variants
• SRV-08 (Cloud Workload): Can be powered by any of these variants

Recommended Combinations

• Serverless + Managed DB + CDN: Ideal for web applications (cheap, scalable, fast)
• Microservices + Managed DB + CDN: Ideal for complex apps (powerful, scales well)
• Managed DB only: Simplest cloud setup (just move database to cloud)
• All four: Bleeding-edge cloud-native (most complex, most powerful)

Possible Future Expansions

Additional Cloud Variant Cards: - CLOUD-05: Machine Learning Platform (ML training/inference) - CLOUD-06: Event Streaming (Kafka, pub/sub architectures) - CLOUD-07: Search & Analytics (Elasticsearch, BigQuery) - CLOUD-08: API Gateway (API management and rate limiting) - CLOUD-09: Message Queue (async processing, event-driven) - CLOUD-10: Infrastructure as Code Platform (automated deployment)

Network Building Module: Cloud Variants (Expansion) Part of Incident Zero, a modular cybersecurity board game v2.1 - Balanced & Refined Edition

cards/print-templates/tracker-sheets.md

Tracker Sheets (Print & Play)

Version: 2.2 - Playtest Edition

Print on plain A4. One Universal Sheet per table, plus the module sheet for the module you're playing. Tip: laminate and use a dry-erase marker, or move a coin/token along the tracks.

Universal Tracker Sheet (all modules)

Turn Track

Cross off as each turn ends. Circle your turn limit before starting.

 1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16
[ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ]  [ ]  [ ]  [ ]  [ ]  [ ]  [ ]  [ ]

Budget Track

Start at your module's budget (Network Building 40-60 · Disaster Recovery 50 · Forensics 75 · IR 100 · Audit 100 · Hardening 150). Tick down in 5s.

150 145 140 135 130 125 120 115 110 105 100  95  90  85  80  75
 70  65  60  55  50  45  40  35  30  25  20  15  10   5   0

Reputation / Score Track (0-100)

100  95  90  85  80  75  70  65  60  55  50  45  40  35  30  25  20  15  10  5  0

Uncontained Threats (Incident Response)

 0   1   2   3   4   5
[ ] [ ] [ ] [ ] [ ] [ ]      Penalty at start of turn: -5 Budget each

Forensics Module Sheet — Progress Meters

Advance each meter per card effects. Victory thresholds marked ▲.

ATTRIBUTION      0   10   20   30   40   50   60   70   80   90▲  100
TIMELINE         0   10   20   30   40   50   60   70   80▲  90   100
ATTACK CHAIN     0   10   20   30   40   50   60   70   80▲  90   100
CHAIN OF CUSTODY 0   10   20   30   40   50   60   70▲  80   90   100

Victory check (end of game): - V1 Full Attribution: Attribution ≥90 AND Timeline ≥80 - V2 Solid Case: Timeline ≥80 AND Attack Chain ≥80 AND Chain of Custody ≥70 - V3 Partial Findings: any two meters ≥70

Investigation in flight: ____ (results arrive Turn _) Evidence collected (✓ = Analyzed, one Analyze per card):

Disaster Recovery Module Sheet

Crisis Progress Tracks

INVESTIGATION   0   10   20   30   40   50   60   70   80   90   100
REMEDIATION     0   10   20   30   40   50   60   70   80   90   100
COMMUNICATION   0   10   20   30   40   50   60   70   80   90   100

Stakeholder Trust (0-100%; any stakeholder at 0% = company collapses)

Deadline Timeline (mark scheduled events at setup)

Multi-turn action in flight: ____ (completes Turn _)

Audit & Compliance Module Sheet — Scoring Worksheet

Result: ___ / 6 PASS — Gap penalties for follow-on modules: see module rules (total capped at -30).

Network Building Module Sheet — Score Sheet

Components placed:

Budget remaining: ___ / starting ___