網絡安全事故應變流程圖（SOC）
SOC 或 CSIRT 運行的技術性網絡安全事故應變生命週期泳道圖：由警報分流到清除、復原與偵測規則調校。
甚麼是網絡安全事故應變流程圖（soc）流程
網絡安全事故應變流程，是保安營運中心或 CSIRT 在一條偵測警報觸發之後所遵循的實際工作生命週期。分流並豐富警報、判斷它是否真實警報、宣佈事故並訂定嚴重等級、指派一名總指揮、找出攻擊者接觸過的每一項資產和每一個帳戶、在不破壞證據的前提下遏制、清除威脅、證明它確實已經消失，然後才復原。本範本把這條序列畫在五條泳道上：偵測／SOC、事故應變人員、事故總指揮、IT 營運和管理層。
有必要說清楚這個流程不是甚麼，因為經常有兩個相鄰流程被併進來，而兩者都因此變弱。它不是 IT 事故管理——後者以恢復被中斷的服務為量度標準，用戶能重新工作就算完結；而一次保安事故並不會因為服務恢復就完結，因為過早復原可能等於把存取權重新交回給攻擊者。它亦不是資料外洩通報。判斷個人資料是否受到影響、是否必須告知監管機構或客戶、以及按甚麼時限告知，屬於法律部門、資料保障主任和傳訊部門的工作，它按法定期限而不是技術節奏運行，歸屬於範圍更廣的保安事故應變流程。本圖與那部分工作並行，而不是把它吸收進來。
本圖的形態依循大多數公開指引共有的次序。SANS 的六步模型——準備、識別、遏制、清除、復原、經驗總結——可以直接對應；NIST SP 800-61 Revision 2 把同樣的工作分組為偵測與分析，遏制、清除與復原，以及事後活動。Revision 3 改為圍繞 Cybersecurity Framework 2.0 的各項功能來組織指引，而不再使用固定的階段清單，但應變人員實際的工作次序並沒有改變。準備沒有被畫成一個方格，因為它是持續性的工作——工具、更表、常設服務合約、演練——而不是事故發生期間執行的一個步驟。這張圖真正要保護的，是那個次序：先證據後清除，先驗證後復原，以及有一位具名的人能夠批准把一套生產系統下線。
本流程圖涵蓋的內容
本範本包含
- 五條角色泳道——偵測／SOC、事故應變人員、事故總指揮、IT 營運和管理層——橫跨六個階段欄：偵測與分流、宣佈、定範圍與遏制、清除、復原，以及經驗總結。
- SOC 泳道中的分流：「分流並豐富警報」通向「是否為真實警報？」的決策，其「否」分支走「關閉警報並調校偵測規則」，令一次誤報去改變偵測規則，而不是被隨手略過。
- 交接與指揮：「宣佈事故並訂定嚴重等級」把工作由 SOC 移交給事故應變人員，而「指派事故總指揮」指名了在此後整宗事故中對決策負責的那個人。
- 由事故總指揮負責的「遏制是否會中斷服務？」決策，其「是」分支先經過管理層泳道的「批准會中斷服務的遏制措施」，然後由 IT 營運執行「隔離受影響的主機與帳戶」。
- 先證據後清理：「保全鑑證證據與映像」位於遏制與清除階段之間；清除階段涵蓋搜尋攻擊者的其他駐留點、移除惡意程式與持久化手段，以及重設憑證並修補被利用的漏洞。
- 「威脅是否已徹底清除？」這項驗證決策在未通過時回到「識別受影響的資產與帳戶」，通過後則進行由乾淨備份重建、在 SOC 泳道中受監察地復原、事後檢討，以及在結案前「更新偵測規則與應變手冊」。
何時使用本範本
- 你們正在運行或正在籌建一個 SOC 或 CSIRT，希望把技術生命週期放在一頁紙上，由警報隊列一直到下一次會觸發的偵測規則。
- 你們正在編寫事故應變計劃中偏操作手冊的那一半，需要在事故發生之前就把遏制、證據和清除的先後次序談定，而不是在事故當中爭論。
- 你們正在準備一次桌面演練或紫隊測試，希望把決策點、迴路和交接攤開來作為檢驗對象。
- 你們需要保安、IT 營運和管理層提前就「誰有權把一套生產系統下線」達成一致，並約定這個人正在睡覺時該怎麼辦。
- 你們正在帶新分析員入門，希望把由分流到應變人員再到事故總指揮的升級路徑明確畫出來，而不是靠耳濡目染學會。
運作方式
把泳道改成你們真實的組織架構
把偵測／SOC、事故應變人員、事故總指揮、IT 營運和管理層換成你們實際擁有的：一家外判的 MSSP、拆成兩條泳道的一級和二級、以平台或雲端團隊代替 IT 營運、一家常設合作的鑑證供應商。與其留下一條沒有人手的泳道，不如刪掉它；如果確實由一個人同時承擔，就把總指揮併入應變人員泳道。
把你們的嚴重等級矩陣放在宣佈步驟上
打開「宣佈事故並訂定嚴重等級」，把說明換成你們自己的準則：甚麼樣的事故算作嚴重、誰有權宣佈，以及每個等級在應變時間、人手投入和非辦公時間召集上分別意味著甚麼承諾。嚴重等級驅動本圖下游的每一個決策，因此值得寫得具體。
訂定遏制的授權規則
「遏制是否會中斷服務？」這條分支只有在凌晨三點也有人可以回答時才有用。寫下哪些系統可以由應變人員自行授權隔離、哪些需要一次業務決定、這個決定由誰掌握，以及在約定時間之內聯絡不上他時該怎麼辦。
在遏制之前先訂好證據規則
把你們的採集次序記錄在「保全鑑證證據與映像」上：先記憶體與即時網絡狀態，再磁碟，最後封存日誌，依循 RFC 3227 提出的揮發性次序原則。註明主機是在網絡層被隔離，而不是被關掉電源，並寫明映像存放在哪裡、由誰簽收。
界定「威脅已徹底清除」是甚麼意思
把退出條件寫在「威脅是否已徹底清除？」決策旁邊：沒有觀察到攻擊者活動的觀察窗口、每一項入侵指標已在整個環境範圍內查找、每一個被攻陷的憑證已更換、被利用的漏洞已修補。同時決定失敗分支是像本圖這樣回到定範圍，還是回到遏制。
把它與前後兩側的流程連起來，並做好版本管理
補上通向資料外洩通報路徑的明確連結、通向面向永久修正的問題管理或變更管理的連結，以及在適用時通向網絡保險或供應商通報的連結。然後把這張圖交給保安主管、IT 營運和管理層簽署確認，並保留獲批版本，因為你們演練的計劃應該就是你們發佈的計劃。
常見問題
網絡安全事故應變流程分為哪些階段？
本圖使用六個階段欄：偵測與分流、宣佈、定範圍與遏制、清除、復原，以及經驗總結。它對應 SANS 的六步模型——準備、識別、遏制、清除、復原、經驗總結——亦對應 NIST SP 800-61 Revision 2，後者把這些工作分組為偵測與分析，遏制、清除與復原，以及事後活動。Revision 3 改為圍繞 Cybersecurity Framework 2.0 的各項功能來組織指引，而不再使用固定的階段清單。準備沒有被畫成一個步驟，因為它是持續性的工作——偵測工程、更表、常設服務合約、演練——在任何警報之前進行，而不是在警報發生期間進行。
這與 IT 事故管理、以及與資料外洩通報有甚麼分別？
IT 事故管理恢復被中斷的服務，並在用戶能重新工作時結案。保安事故裡有一個對手，因此恢復服務並不是終點線：如果威脅仍然駐留，那恰恰是風險最高的一刻——這正是本圖把一個驗證決策放在復原之前的原因。資料外洩通報是另一個相鄰流程。判斷個人資料是否受到影響、是否必須告知監管機構或客戶、以及在甚麼法定時限之內告知，是按法律時鐘運行的法律與傳訊工作，它與技術應變並行，而不是包含在技術應變之內。
為甚麼證據保全要排在清除之前？
因為最常見的遏制動作會破壞你之後需要的證據。把主機關掉電源會失去只駐留在記憶體中的惡意程式、即時網絡連線、已解密的內容和被注入的處理程序。在範圍尚未弄清之前就重建一台伺服器，會抹走那些顯示攻擊者如何進入、又觸及了甚麼的痕跡。RFC 3227 描述的揮發性次序原則給出了可操作的規則：先採集記憶體與即時狀態，再採集磁碟，最後採集封存日誌。在本圖中，證據步驟位於隔離之後、任何清除工作之前，而主機是在網絡層被隔離，因此保持運行。
怎樣判斷威脅已經徹底清除？
用事故發生之前就寫好的準則，而不是當場判斷。通常包括：在約定的觀察窗口之內，整個環境範圍沒有觀察到攻擊者活動；調查中得到的每一項入侵指標都已在所有主機上查找，而不只是在曾經發出警報的主機上；每一個可能已被竊取的憑證都已更換，包括服務帳戶和機器帳戶；以及導致初次入侵的漏洞或錯誤設定已被封堵。當答案是否時，通常意味著範圍判斷錯了，而不是清理做得馬虎——這也是本圖的失敗分支回到「識別受影響的資產與帳戶」而不是回到隔離的原因。
把生產服務下線的遏制措施由誰批准？
由有權承擔業務影響的人批准，而這個人很少是發現問題的那位應變人員。本圖把這類情況引向管理層泳道，但重點不在泳道名稱，而在於這個決定、這個具名角色，以及聯絡不上他時的後備安排都是提前約定好的。許多團隊會針對一份明確的系統清單和嚴重等級預先授權隔離，令常見情況永遠不必等一通電話，而把升級審批保留給涉及收入或安全的服務。沒有這一點，爭論就會在攻擊者仍然在活動的時候發生。