建置事件應變劇本
使用時機
- 從無到有建立或成熟化事件應變計劃
- 在經歷新型攻擊後，為新的事件類型撰寫標準作業程序
- 在 SOAR 平台（Cortex XSOAR、Splunk SOAR）中自動化應變工作流程
- 準備需要書面 IR 程序的合規稽核（SOC 2、PCI-DSS、HIPAA）
- 針對特定威脅情境，對現有 IR 能力進行差距分析
請勿使用於一次性臨時調查；劇本為可重複使用的程序文件，非針對個案之報告。
先決條件
- 組織風險評估，需識別出依發生機率與衝擊程度排列的優先事件情境
- 採用 NIST SP 800-61r3 或 SANS PICERL 框架作為組織的 IR 標準
- 資產清單，需包含業務關鍵性評級與資料分類
- RACI 圖表，定義角色：事件指揮官、SOC 分析師、系統管理員、法務、公關
- 現有偵測能力清單（SIEM 規則、EDR 偵測、IDS 特徵碼）
- 若建置自動化劇本，則需具備 SOAR 平台存取權
工作流程
步驟 1：選擇並界定事件類型
定義劇本將處理的具體情境：
- 根據組織風險評估與歷史資料，識別首要事件類型
- 為求清晰，每個劇本應專注於單一事件類型（請勿合併不相關的情境）
- 定義觸發劇本的條件
常見劇本類型：
優先劇本（優先建置）：
1. 勒索軟體事件應變
2. 釣魚／憑證遭竊
3. 商業電子郵件詐騙
4. 惡意軟體感染
5. 資料外洩／竊取
6. DDoS 攻擊
7. 內部威脅
8. 帳號遭盜用
9. Web 應用程式入侵
10. 雲端基礎架構入侵
步驟 2：定義劇本結構
每個劇本應遵循一致的結構：
劇本範本
━━━━━━━━━━━━━━━━
1. 劇本中繼資料
- 名稱、版本、負責人、最後審閱日期
- 觸發條件
- 嚴重性標準
2. RACI 矩陣
- 每個步驟的負責人（Responsible）、當責人（Accountable）、諮詢者（Consulted）、被告知者（Informed）
3. 偵測與分類
- 如何偵測到事件
- 初步分類檢查清單
- 嚴重性分類標準
4. 遏制
- 短期遏制措施
- 長期遏制措施
- 證據保存要求
5. 根除
- 根本原因識別
- 惡意軟體／威脅移除步驟
- 驗證程序
6. 復原
- 系統還原步驟
- 驗證標準
- 復原後監控要求
7. 事後檢討
- 觸發 Lessons Learned 會議的條件
- 報告範本
- 偵測改善措施
8. 溝通
- 內部通報矩陣
- 外部通報要求（監管機構、客戶、執法單位）
- 狀態更新頻率
9. 附錄
- 特定工具程序
- 聯絡人清單
- 證據蒐集檢查清單
步驟 3：撰寫決策樹與升級標準
定義具有二元結果的明確決策點：
收到偵測警示
├── 此警示是否為真陽性？
│ ├── 是 → 分類嚴重性
│ │ ├── P1（嚴重） → 呼叫事件指揮官，立即開始遏制
│ │ ├── P2（高） → 通知 IR 負責人，30 分鐘內開始調查
│ │ ├── P3（中） → 排入佇列，4 小時內調查
│ │ └── P4（低） → 記錄並於 24 小時內調查
│ └── 否 → 記錄為誤報，調整偵測規則
└── 無法判斷 → 升級至 Tier 2 進行深入分析
升級觸發條件：
- 任何 P1 事件：立即升級至 IR 負責人及 CISO
- 確認資料外洩：通知法務顧問與隱私長
- 涉及客戶資料：啟動客戶通知程序
- 涉及第三方：聯繫廠商安全聯絡窗口
- 需要聯繫執法單位：由總法律顧問授權後方可接觸
步驟 4：定義具體技術程序
為每個步驟撰寫特定工具的操作說明（非通用指導）：
遏制 - 透過 CrowdStrike 進行主機隔離：
1. 開啟 Falcon Console > Hosts > 搜尋受影響主機名稱
2. 點擊主機 > Host Details
3. 點擊右上角「Contain Host」按鈕
4. 確認隔離（主機僅能與 CrowdStrike 雲端通訊）
5. 在事件單中記錄遏制動作與時間戳記
6. 驗證隔離：主機應顯示「Contained」狀態徽章
遏制 - 在 DNS 層級封鎖 C2 網域：
1. SSH 至 DNS 伺服器：ssh [email protected]
2. 加入封鎖區域：echo "zone evil.com { type master; file /etc/bind/db.sinkhole; };" >> /etc/bind/named.conf.local
3. 重新載入 DNS：rndc reload
4. 驗證：dig @dns-primary evil.com（應解析至 sinkhole IP 10.0.0.99）
5. 在事件單中記錄被封鎖的網域
步驟 5：與 SOAR 平台整合
將手動劇本步驟轉換為自動化工作流程：
- 將每個劇本步驟對應到一個 SOAR 動作（API 呼叫、腳本、人工決策點）
- 定義自動化邊界（哪些自動執行，哪些需要分析師核准）
- 為分類階段建置情資擴充自動化
- 為高衝擊動作建立帶有核准關卡的遏制自動化
- 設定用於利害關係人溝通的通報自動化
步驟 6：測試與維護劇本
透過演練驗證劇本並保持其時效性：
- 與 IR 團隊進行桌上演練，逐步執行劇本
- 在測試環境中進行模擬該事件類型的實彈演練
- 每次實際使用劇本處理真實事件後，進行審閱與更新
- 每季安排審閱，確保聯絡人清單、工具程序及升級路徑的準確性
- 追蹤劇本指標：平均遏制時間、平均解決時間、誤報率
關鍵概念
| 術語 | 定義 |
|---|---|
| Playbook（劇本） | 針對特定事件類型所建立之文件化、可重複使用的應變程序集 |
| Runbook（操作手冊） | 較劇本更為精細；針對劇本中特定任務的逐步技術操作說明 |
| RACI Matrix（RACI 矩陣） | 定義每個活動的負責人（Responsible）、當責人（Accountable）、諮詢者（Consulted）及被告知者（Informed）之職責分配表 |
| Decision Tree（決策樹） | 基於流程圖的邏輯，根據每個決策點的二元條件定義應變路徑 |
| Escalation Criteria（升級標準） | 預先定義的條件，觸發通知更高層級人員或外部相關方 |
| SOAR Playbook（SOAR 劇本） | 在安全協調、自動化與回應平台中執行劇本步驟的自動化工作流程 |
工具與系統
- Cortex XSOAR：SOAR 平台，具備視覺化劇本編輯器、700 多個整合功能及協作 War Room
- Splunk SOAR：SOAR 平台，與 Splunk ES 整合，提供拖放式劇本建構器，內含 2,800 多個自動化動作
- TheHive：開源事件應變平台，提供可作為劇本框架的案例範本
- Confluence / GitLab Wiki：用於維護可閱讀劇本文件並具備版本控制功能的文件平台
- Tines：無程式碼安全自動化平台，用於建置劇本工作流程
常見情境
情境：從零建立釣魚郵件應變劇本
背景：一個擁有 5 人 SOC 的組織沒有文件化的釣魚郵件應變程序。分析師處理釣魚郵件通報的方式不一致。
方法：
- 訪談 SOC 分析師，記錄他們當前的臨時處理流程
- 定義觸發條件：使用者透過 abuse@ 信箱或釣魚郵件按鈕通報釣魚郵件
- 撰寫分類步驟：擷取郵件標頭、檢查寄件者信譽、在沙箱中分析 URL／附件
- 定義遏制：從所有信箱隔離郵件、封鎖寄件者網域、若已輸入憑證則重設密碼
- 建置 SOAR 自動化：從通報郵件中自動擷取入侵指標（IOC）、透過 VirusTotal 進行情資擴充、在 TheHive 中建立案件
- 使用模擬釣魚郵件進行測試，並衡量回應時間改善
陷阱：
- 編寫過於通用的程序，未參考特定工具介面或指令
- 未納入通知收到釣魚郵件使用者的溝通計畫
- 忘記定義釣魚郵件通報何時應升級為完整事件調查的標準
- 未對劇本進行版本控制，亦未安排定期審閱週期
輸出格式
事件應變劇本
============================
劇本名稱： 釣魚郵件事件應變
版本： 2.1
負責人： SOC 經理
最後審閱日期： 2025-11-01
下次審閱日期： 2026-02-01
觸發條件： 使用者透過 [email protected] 或釣魚郵件按鈕通報釣魚郵件
RACI 矩陣
活動 | SOC L1 | SOC L2 | IR 負責人 | 法務 | 公關
初步分類 | R | C | I | |
郵件分析 | R | A | I | |
遏制 | | R | A | I |
憑證重設 | | R | A | |
使用者通知 | | C | A | | R
法規通報 | | | C | R | A
事後檢討 | C | C | R | I | I
程序步驟
[包含特定工具操作說明的詳細步驟]
決策樹
[流程圖邏輯]
升級矩陣
[條件與聯絡人]
指標
目標平均分類時間（MTTA）：15 分鐘
目標平均遏制時間（MTTC）：1 小時
目標平均解決時間（MTTR）：4 小時