保安事故應變流程圖
保安事故應變流程的泳道圖：由偵測與分流，經嚴重程度分級、遏制、證據保全與清除，一直到資料外洩通報、事後檢討與結案。
甚麼是保安事故應變流程
保安事故應變流程，是一個機構由發現可疑跡象的那一刻起，直到事故記錄被結案為止所依循的次序。它被刻意設計成不同於 IT 服務事故流程。目標不只是復原服務，還要弄清楚攻擊者做了甚麼、阻止他們繼續做下去、保持證據完整，並判斷這次事故是否必須向監管機構報告。
多數公開發佈的流程共用同一副骨架。NIST SP 800-61r2 把它拆成準備，偵測與分析，遏制、清除與復原，以及事後活動。ISO/IEC 27035 用的則是規劃與準備，偵測與報告，評估與決策，應變，以及經驗總結。本圖沿用這個形態，並把在真實事故中最容易引發爭論的兩個決策畫了出來：這到底是不是一次保安事故，以及這次外洩是否須通報。
團隊在壓力之下弄錯的，通常是先後次序的規則。用關掉電源的方式遏制一台主機，會毀掉揮發性的記憶體證據。在範圍尚未分析清楚之前就重建伺服器，意味著你再也無法證明甚麼被拿走了。在系統尚未驗證乾淨之前就復原服務，會令整個環境再次受感染。提前約定好次序，並且每個角色一條泳道，是這些規則能夠捱過凌晨三點一通電話的方法。
本流程圖涵蓋的內容
本範本包含
- 五條角色泳道（報告人與偵測、保安團隊、事故總指揮、IT 營運、法律部門與傳訊）橫跨五個階段欄：偵測與報告、分流與分級、遏制、清除與復原，以及通報與檢討。
- 偵測與報告：可疑活動經由單一的事故通道上報，隨後由保安團隊登記，並展開事故時間線。
- 分流之後的「是否確認為保安事故？」決策，把誤報送往一份已結案的記錄，把已確認的事故送往嚴重程度與影響分級。
- 「是否為高嚴重程度事故？」決策，為高嚴重程度情況指派一位具名的事故總指揮，其餘一律直接進入遏制。
- 遏制被拆成短期（隔離受影響系統）與長期兩段，中間是證據保全與系統映像，之後是範圍分析、清除，以及一個在未通過時回到隔離的「系統是否驗證乾淨？」檢查。
- 由法律部門與傳訊負責的「是否屬須通報的外洩？」決策，通向在法定時限之內向監管機構和資料當事人通報，隨後是事後檢討、記錄經驗並結案。
何時使用本範本
- 你們正在編寫或更新一份事故應變計劃，需要用一頁紙說明誰在甚麼時候做甚麼。
- 你們正在準備一次 ISO 27001 審核或一次客戶保安評估，並被要求出示一份書面的應變流程（這張圖證明流程存在，它本身並不表示符合規定）。
- 你們正在進行桌面演練，希望把決策點、交接和通報時鐘攤開來作為檢驗對象。
- 你們正在帶新分析員入門，或者當值輪更中包含保安團隊以外的人。
- 你們希望保安、IT 營運和法律部門在事故發生之前而不是在事故當中就把交接談定。
運作方式
把泳道改成你們真實的角色
把這五條泳道換成你們真正擁有的角色：SOC 或 MSSP、服務台、保安主管、平台團隊、資料保障主任、外部鑑證機構或外洩事故法律顧問。如果某個角色並不存在，就刪掉那條泳道，而不是讓它空著無人承擔。
訂定你們的嚴重程度判定準則
打開「對嚴重程度與影響分級」方格，把說明換成你們自己的矩陣：甚麼樣的事故算作高嚴重程度、誰有權宣佈，以及每個等級各自承諾甚麼樣的應變時間。
確定通報時限與對應的監管機構
編輯「是否屬須通報的外洩？」決策，令它寫明適用於你們的制度：英國或歐盟 GDPR（72 小時之內通報監管機構）、NIS2、HIPAA、行業規則，以及合約訂明的客戶通知期限——後者往往比法定期限更短。
補上人們在凌晨三點需要的聯絡資料
把事故通道、當值電話、事故總指揮更表和證據存放位置寫進方格備註裡，這樣這張圖在事故當中也用得上，而不只是在檢討時才拿出來。
調整迴路並補上缺失的步驟
判斷「系統是否驗證乾淨？」回到隔離的這條分支是否符合你們的工作方式，並補上你們環境中特有的內容，例如啟用常設合約的鑑證供應商、網絡保險通報，或者一個客戶對外稿件的審批步驟。
分發簽署並保留版本
把這張圖交給保安主管、IT 營運和法律部門簽署確認，然後保留獲批版本。事故應變計劃是一份受控文件，你們演練的版本應當就是你們發佈的版本。
常見問題
事故應變流程分為哪些階段？
本圖使用五個階段：偵測與報告、分流與分級、遏制、清除與復原，以及通報與檢討。它與 NIST SP 800-61r2 高度對應，後者使用偵測與分析，遏制、清除與復原，以及事後活動。NIST 另有一個準備階段，但準備是持續性的工作（工具、更表、演練、常設服務合約），而不是你在事故當中執行的一個步驟，因此沒有畫在流程上。
保安事故應變與 IT 事故管理有甚麼分別？
一次 IT 服務事故在服務復原時就完結了。保安事故不是，因為存在一個對手。過早復原可能等於把攻擊者的存取權重新交回去，而且它還帶有 ITIL 事故流程並不承擔的責任：在重建之前保全證據、判定哪些資料受到影響、並在需要時通報監管機構和個人。這正是本圖把證據保全與映像放在清除之前，並在復原之後加上一條通報分支的原因。
誰應當擔任事故總指揮，甚麼時候指派？
事故總指揮應當是有權做決定的人（把一套生產系統下線、聘請外部法律顧問、聯絡客戶），而不一定是當下技術最強的人。他們負責協調，而不是負責調查。在本圖中，只有當「是否為高嚴重程度事故？」得到「是」時才指派總指揮；嚴重程度較低的事故仍留在保安團隊。在一次長時間的事故中，這個角色會在每次換更時明確交接。
72 小時的外洩通報時鐘由甚麼時候開始？
在英國和歐盟 GDPR 之下，這 72 小時由機構知悉發生了個人資料外洩時起計，而不是由攻擊開始時、也不是由調查結束時起計；如果尚未掌握完整情況，可以分階段通報。通知受影響的個人是另一項判定：當外洩很可能為他們帶來高風險時，須在不當延誤的情況下通知。其他制度運行的是不同的時鐘，因此請把適用於你們的那一個寫在決策方格上。