紫隊演練計畫規劃與流程

計畫階段

• 紫隊演練的時間的設定(沒有強制規定)
  • 短期：幾個小時
    • 設定特定目標的演練
    • 測試單一/不複雜的系統安全性
    • 測試單一/不複雜的攻擊ㄈ法
  • 全面：數天
    • 較全面的演練
    • 多個系統
    • 多個攻擊技巧
  • 全面、深度：數周/數月
    • 較深度的演練
    • 模擬真實的攻擊情境
    • 涵蓋企業的 IT 基礎設施
    • 需要有充分時間調整策略
  • 其他
    • 資源可用性
    • 企業可承受的風險能力
    • 演練成本
    • 之前的經驗(之前過短/過長)也會影響
    • 外部因素(法規、合約、業務需求)
• 決定時間長短的因素，最終會決定計劃時間
  • 取決於主管、執行單位互相配合的時間
    • 來回溝通頻率
    • 計劃資訊透明度
    • 主管的決策速度
  • 基於目標和目的
    • 目標太模糊
    • 目標目的變更頻率太頻繁
  • 基於限制
    • 資源限制：人員、設備、預算
    • 時間限制：時程太趕
  • 基於模擬駭客(攻擊者)的策略技巧和流程(TTPs)
    • 複雜度越複雜準備度可能要更高
    • 經驗和知識，可能缺乏特定經驗，需要研究與培訓時間
  • 其他
    • 技術問題：軟體、體體不足
    • 外部因素：法規、企業策略調整
    • 團隊動力：合作與互動方式影響效率
• 企業如果已經有紫隊演練的經驗
  • 經驗累積：可以加速、更有效率規劃
  • 流程優化：調整改善後讓演練更順暢
  • 資源配比：知道哪邊需要投入更多資源、更有效率利用現成資源
  • 內部合作：更知道跨部門如何合作
  • 工具熟悉度：更加知道如何使用者些工具
  • 演練模組/模板化：縮短計畫與執行演練的時間

計劃會議(Planning Meeting)

1. 目的
   • 確保演練過程有充分考慮與策劃
   • 參與者討論與確定演練目標、範圍、需求跟時間表
   • 會議室為了減少意外與誤解，最終可以提高演練的價值和效果
2. 決定會議數量的影響因素
   • 會根據企業自己對於紫隊的熟悉程度
     • 不熟悉的話能會有更多的計畫會議
     • 如果之後熟悉，可能可以計畫會議的需求
   • 參與者組成
     • 如果有外部顧問，可以會需要事前規劃會議
       • 外部顧問需要熟系內部流程與文化
3. 會議舉辦的建議
   • 確保每次計劃會議都有明確的目的和議程，並事先通知所有參與者
   • 邀請所有相關的利益相關者參加計劃會議，包括紅隊、藍隊、IT部門、業務部門等
   • 在會議後，及時發送會議記錄和行動項目，確保所有參與者都清楚他們的責任和期限
4. 計畫會議的類型
   • 提案會議(Pitch)
   • 需求會議
   • 準備會議(行前會議)

提案會議

• 紫隊計劃和紫隊演練的初步提案，目標介紹和說明紫隊的重要性和效益
• 大綱
  • 向參與者介紹紫隊的概念
  • 分享其他產業/國際案例在進行紫隊演練時所採用的方法論
  • 若有紫隊演練經驗，分享前次演練的成果、收獲和改進措施
• 參與者
  • 主要是高層領導
  • 各資安團隊
  • 可能的贊助商

計劃會議1(需求會議)

• 獲得贊助商和利益相關者的批准後，詳細計劃和設定紫隊演練的各項要求和步驟
• 大綱
  • 討論和確定計劃和網路威脅情報階段的所有需求
  • 分配各種任務給相關的利益相關者
  • 演練協調員應確保每項任務都有明確的負責人和完成的時限
• 參與者
  • 主要涉及到演練的所有團隊和利益相關者

計劃會議2(準備會議/行前會議)

• 在紫隊演練開始之前，確認所有的準備工作都已完成，並解決可能的問題和疑慮。
• 大綱
  • 確認所有的計劃和網路威脅情報階段的項目都已完成
  • 確保演練所需的所有物理和技術要求都得到滿足
    • 物理位置是否符合所有要求，如電源、系統連接性（攻擊和防禦基礎設施）、空調等。
    • 確認沙盤推演的時間和方式
      • 演練前還是演練當天進行
    • 確認所有的參與者都已經收到演練的議程
  • 紅隊準備
    • 設置至少2個系統以了解攻擊行為
      • 有足夠的資源進行攻擊
    • 確保攻擊工具可正常使用
      • 攻擊工具、伺服器可以正常執行
    • 確保目標系統可存取
      • 可成功存取目標
    • 在指南或模擬計劃中記錄模擬TTPs所需的所有指令
      • 紅隊需要按照預先設定的策略寄型攻擊
    • 在與演練主機設定完全相同的不同主機上測試TTPs
      • 正式演練前在測試環境中驗證攻擊策略
  • 藍隊準備
    • 驗證目標系統的安全工具是否有正常監控內容
    • 確保已經透過代理/流量控制存取被攻擊的基礎設施
      • 網路流量都可以正常監控
    • 確保可看到被攻擊的基礎設施
      • TLS解密/攔截
      • 目的可以檢測淺在地攻擊
    • 驗證白名單並通知紅隊
      • 確保已知安全流量不會被誤報
    • 確保在非演練系統上測試 payload 和C2
    • 根據DFIR過程有演練範例與規則
      • 每件事情都有紀錄
      • 日後可以分析
    • 確保目標系統在整個演練過程中不被分隔或移除
      • 藍隊可以持續監控與防禦
    • 確保在目標系統上部署了正確的監控與 DFIR 工具
      • 可以快速蒐集證據
    • 安裝即時監控工具以提高紫隊演練的效率
      • 即時反應與回應攻擊
• 參與者
  • 所有涉及到演練的團隊和利益相關者

後勤/後方勤務(Logistics)

• 目的
  • 確保參與者可以依據計畫參與演練
  • 選擇合適的時間與地點進行
• 作法
  • 選定參與者，開始進行準備計畫
    • 執行前可以先確認人員的請假狀況
    • 通知對方執行時間與預留會議時間
  • 決定演練地點
    • 框架建議
      • 在防禦者(藍隊的地方)
      • 專門的會議室/有足夠的空間
      • 可快速輸出(投影、HDMI)目前進度與內容的場地
        • 可以即時了解目前狀況、下一步該怎麼做
      • 如果需要跨縣市演練需要提早規劃
    • 若真的不行可以遠端
      • 遠端會議工具
  • 備案
    • 停電/網路中斷

議程(Agenda)

• 目的
  • 為了確保大家都知道每一個階段的任務與目標
  • 確保演練過程中的流暢與效益
  • 需要提前設定議程並且告知大家
• 作法
  • 設定議程
    • 根據演練的內容和時間長度，設定一個明確的時間表
    • 10:00-11:00 公開資訊情蒐
    • 11:00-11:15 休息
  • 通知大家議程內容
  • 休息時間
    • 也許會有零食、咖啡、茶點、小吃
  • 補充作法
    • 每個議程有明確目標與預期結果
    • 有主持人引導整個演練活動
    • 安排提問與討論時間
    • 發放對應的架構圖、補充資料
    • 設定回饋與檢討機制

指標 (Metrics)

• 目的
  • 確保演練過程中哪一些因素可以用來有效評估攻擊與防禦策略
  • 與傳統的脆弱性管理指標不太相似
    • 注重 TTPs 的表達與攻擊的行為
• 作法
  • Data Sources 資料來源
    • Logging events locally 本地端的日誌事件
      • 伺服器或工作站自己的安全日誌，記錄登入嘗試或軟體安裝
    • Logging events centrally 中央管理的日誌事件
      • 使用SIEM工具（如Splunk或ELK)收集和分析所有工作站和伺服器的日誌
  • Detection 檢測目標
    • Alerts 警報
      • 當系統上發生異常活動時，生成的通知
      • 台灣公司卻有一個來自一個非洲的地理位置的登入嘗試
    • Telemetry 遙測的資料
      • 系統的資料
        • CPU 使用率
        • 網路流量
    • Indicator of Compromise 妨礙指標
      • 惡意 IP 位址、網域名稱
    • General Behavior 一般行為
      • 使用者在正常上下班時間登入與登出
    • Specific Behavior 特定行為
      • 管理員在半夜登入到核心伺服器
  • Response
    • Time to Detect 檢測時間
      • 從異常活動開始到系統生成警報的時間
      • 不尋常的檔案存取可能在幾秒內觸發一個警報
    • Time to Investigate 調查時間
      • 從接收警報到確定其是否為真實威脅的時間
      • 資安團隊需要十分鐘來確認是否為「誤判」
    • Time to Remediate 修復時間
      • 從確定真實威脅到解決問題的時間
      • 如果警報是真實的，可能需要1小時來清除惡意軟體並修復受影響的系
  • 可見性與警報的關係
    • 確保可以看到網路上的所有行為
      • 部署端點檢測和響應（EDR）工具
    • 建立資料來源可見性的框架
      • DETT&CT
        • https://github.com/rabobank-cdc/DeTTECT
  • 高可靠性的警報機制
    • 機器檢測 ==> 人工檢測
    • 簡單告警機制 ==> 複雜
      • 單一技術
      • 單一指令
    • 複雜機制
      • 基於網路
      • 基於主機
      • 基於 C2 相關的流量
  • 選擇合適的技術與工具
    • 有哪些資產/資產對應的版本
    • 根據業務需求選擇不同版本的 sysmon 工具
  • 評估檢測、回應和恢復的能力
    • 除了技術，加入人和流程的考量
    • 資安團隊使用工具與流程的效率與速度
    • 透過紫隊演練，定期模擬真實攻擊，並評估安全團隊的反應速度和效率

資料來源

• https://github.com/scythe-io/purple-team-exercise-framework
• https://github.com/rabobank-cdc/DeTTECT