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