核心論點

資安演練的核心概念是「用受控情境驗證控制面與協作流程」。Abuse case 提供攻擊或濫用假設，game day 驗證團隊能否在訊號、角色與決策節奏上完成收斂。

讀者入口

本篇適合銜接 7.R11 流程濫用問題卡片、7.16 從公開事故到工程 Workflow 與 Game Day。它把資安案例庫轉成演練材料。

演練模型

演練模型的責任是把不同粒度的材料放在同一條路徑上：

這條路徑的關鍵是先用抽象層材料定義問題，再用現場演練驗證行為。如此可以讓同一張 problem card 在不同服務情境重用。

演練前置設計

演練前置設計的責任是讓每次演練都能回答同一組問題，並用固定欄位維持命名一致性。建議欄位如下：

1. Scenario：定義服務情境與風險邊界。
2. Trigger：定義演練起點訊號。
3. Roles：定義決策角色與操作角色。
4. Expected path：定義預期路由與完成條件。
5. Evidence：定義演練後要保留的證據。

Tabletop 演練

Tabletop 的責任是驗證決策與協作。重點是讓角色在時間壓力下仍能維持一致路由，並把升級流程與外部溝通節奏跑過一次。

Tabletop 推薦輸出：

1. Decision timeline：每個決策點何時產生、由誰承接。
2. Escalation record：何時升級、升級依據為何。
3. Gap list：本輪找到的流程缺口。

Game Day 演練

Game day 的責任是驗證系統與流程在真實操作下的穩定度。重點是把 control path、alert path、recovery path 串在同一輪場景。

Game day 推薦輸出：

1. Signal evidence：告警、log、metric、trace 片段。
2. Control evidence：release gate、rollback、token revocation 操作記錄。
3. Write-back task：對應回寫到章節與卡片的位置。

演練回寫流程

演練回寫的責任是讓演練成果進入知識網。建議回寫順序：

1. 先回寫 problem card 的失效樣式與補強點。
2. 再回寫 7.x 判讀訊號與風險邊界描述。
3. 最後回寫 incident workflow 的任務模板與檢查點。

兩種常見演練場景

1. 身份與會話場景：檢查 token 濫用、權限收斂與 session 失效節奏。
2. 供應鏈場景：檢查 artifact provenance、release freeze、tripwire 與放行條件。

判讀訊號與路由

判讀表格的重點是從訊號直接推到下一步行動。這種路由格式可以直接轉成演練 backlog。

必連章節

• 7.R7 事故案例庫
• 7.R8 控制面失效樣式
• 7.R11 流程濫用問題卡片
• 7.16 從公開事故到工程 Workflow

完稿判準

完稿時要讓讀者能用一張 problem card 建立一次資安演練。演練設計至少包含場景、角色、訊號、決策點、操作證據、關閉條件與回寫位置。

核心論點

Tabletop 與 game day 的核心概念是「用受控演練驗證角色、訊號、決策與操作證據」。Tabletop 驗證協作與決策，game day 驗證系統與流程能否實際承接。

讀者入口

本篇適合銜接 7.19 資安演練：從 Abuse Case 到 Game Day、7.B2 從偵測到回應的路由 與 Game Day。

演練設計欄位

演練設計欄位的重點是讓演練可重複。當 scenario、injects、expected actions 固定，團隊可以跨季度比較能力變化。

選題來源

選題來源的責任是讓演練對準實際風險。建議優先順序：

1. 已出現在 problem card 的高風險流程。
2. 近期發生變更的關鍵系統。
3. 近期公開事故對應的同類場景。

Tabletop 設計

Tabletop 設計的責任是驗證角色協作與決策節奏。這一層可在不動系統的前提下，先跑完整個判讀與升級路由。

Tabletop 推薦輸出：

1. Decision timeline。
2. Escalation transitions。
3. Communication script。
4. Write-back draft。

Game Day 設計

Game day 設計的責任是驗證實際操作能力。這一層會執行告警處理、控制面操作、放行或回復流程，並收集完整證據。

Game day 推薦輸出：

1. Signal evidence：告警、log、metric、trace。
2. Action evidence：runbook 操作、gate 決策、rollback 記錄。
3. Closure evidence：關閉條件驗證與回寫任務。

演練觀察與回寫

演練觀察的責任是把事後改進對齊到章節結構。建議每次演練至少回寫三個位置：

1. blue-team 路由與驗證章節。
2. red-team problem cards 失效樣式。
3. incident workflow 檢查點與 owner map。

演練節奏建議

演練節奏的責任是建立可持續運作 cadence。建議以「月度 tabletop + 季度 game day」組合，並把每輪成果寫入固定回寫模板。

判讀訊號與路由

判讀表格可以當作演練發起條件。當任一列被命中，團隊就有清楚起點啟動演練設計。

必連章節

• 7.R11 流程濫用問題卡片
• 7.16 從公開事故到工程 Workflow
• 7.19 資安演練：從 Abuse Case 到 Game Day
• 7.B3 資安控制驗證

完稿判準

完稿時要讓讀者能設計一次 tabletop 或 game day。演練設計至少包含 scenario、participants、injects、expected actions、evidence、exit condition 與 write-back target。

核心論點

Scenario library 的核心概念是把防守知識轉成可重播情境。可重播情境讓控制驗證從一次性討論變成可累積資產。

讀者入口

本篇適合銜接 7.B4 Tabletop 與 Game Day 設計、7.BM3 藍隊推演情境素材 與 7.B7 Threat-Informed Validation。

情境卡模板

初始情境組合

初始情境組合的責任是聚焦高價值風險。可先固定四組：

1. Identity Support Token Tabletop：支援流程、session token 與客戶通報。
2. Edge Session Hijack Game Day：入口曝險、修補後 hunting 與 session invalidation。
3. Supply Chain Artifact Drill：artifact provenance、release freeze 與 rollback。
4. Low-frequency Exfiltration Tabletop：資料範圍判讀、通報與證據保存。

Source-first 情境規則

情境庫的責任是把真實案例轉成可重播演練。每張情境卡都要能回查到 field case 或 professional source，並把事件細節轉譯成通用服務壓力。

Source-first 讓情境保留真實防守壓力，同時避免把單一公司事件寫成讀者必須照抄的流程。情境卡負責抽出 trigger、hypothesis、control surface、response route、evidence target 與 write-back target。

演練節奏

演練節奏的責任是讓情境能持續更新。每輪演練後同步更新觸發條件、分級基準、證據欄位與 runbook，並記錄下一輪要驗證的假設。

指標設計

指標設計的責任是評估情境品質。建議追蹤命中率、triage 時間、升級一致性、證據完整度與回寫完成率。

判讀訊號與路由

必連章節

• 7.B4 Tabletop 與 Game Day 設計
• 7.B6 Incident Triage Loop
• 7.B7 Threat-Informed Validation
• 7.BM3 藍隊推演情境素材
• 7.BM2 藍隊現場案例素材

完稿判準

完稿時要讓讀者能把一個風險轉成可演練情境。輸出至少包含 trigger、hypothesis、control surface、response route、evidence target 與 write-back target。

情境模板

初始情境方向

推演情境先從四類高價值服務壓力開始：身份濫用、入口曝險、供應鏈 artifact 偏移與低頻資料外送。這四類能直接承接 7.2、7.3、7.12 與 7.13。

Source-first 規則

推演情境卡的責任是把真實案例轉成中性服務演練。每張情境卡都要標示來源案例，並把情境改寫成通用服務語言。

情境可以合成多個來源的壓力點，但每個主要壓力都要能回查到 field case 或 professional source。這個規則讓 tabletop 與 Game Day 保持可討論性，也避免情境只停留在想像中的攻防故事。

下一輪情境大綱

情境卡的完成條件是能直接產生演練腳本。每張卡至少包含 scenario trigger、initial hypothesis、response route、evidence target 與 write-back target。

Scenario Trigger

支援系統出現大量附件下載，同一時間有客戶回報管理員 session 異常。SOC 在 identity provider log 中看到高權限 session 從不常見位置延續使用。

Initial Hypothesis

Control Surface

控制面包含 support workflow、session management、token revocation、customer communication 與 ownership。

Response Route

1. Triage：確認支援附件是否含敏感 session 資料。
2. Severity：依受影響 tenant、權限等級與 token 可用性分級。
3. Owner：identity owner 主責，support owner 與 incident commander 協作。
4. Containment：撤銷 session、鎖定附件下載、通知受影響客戶。
5. Write-back：更新支援附件處理、HAR sanitizer、customer notification 與 runbook。

Evidence Target

Write-back Target

• 7.2 身分與授權邊界
• 7.B6 Incident Triage Loop
• Control owner pattern
• Exercise write-back pattern

Scenario Trigger

外部 advisory 指出受管檔案傳輸系統存在已被利用漏洞。內部稽核發現 MFT 上有異常 web shell indicator 與多筆低頻大量下載。

Initial Hypothesis

Control Surface

控制面包含 data classification、MFT ownership、audit trail、incident communication、forensic preserve 與 retention。

Response Route

1. Contain：隔離 MFT、保留 forensic image、暫停高風險傳輸。
2. Scope：建立資料集、客戶、時間窗與存取主體映射。
3. Notify：讓 legal、customer success 與 incident commander 對齊通報節奏。
4. Recover：修補 MFT、輪替 credential、驗證 log coverage。
5. Write-back：更新資料出口控制、retention 與 low-frequency exfiltration detection。

Evidence Target

Write-back Target

• 7.4 資料保護與遮罩治理
• 7.24 資安事故如何回寫產品與架構
• Evidence chain pattern
• Exercise write-back pattern