網絡釣魚事故應變流程圖（舉報電郵）
網絡釣魚事故應變流程圖範本：用戶舉報、SOC 分流定性、全租戶搜尋副本、清除並封鎖指標、重設密碼並撤銷工作階段、帳戶被入侵時升級與保安意識跟進。
甚麼是網絡釣魚事故應變流程圖（舉報電郵）流程
網絡釣魚事故應變，是一個人轉發一封電郵之後所發生的事。觸發點是一次舉報，而不是一個示警：有人按下電郵客戶端裡的舉報按鈕，或者就一封看起來不妥當的電郵致電服務台。從那一刻起，工作就是一個簡短、可重複的循環。把樣本分流至定性結論，找出所有已到達機構的其他副本，移除該些副本並封鎖它們所指向的目標，撤銷收件人已經做過的操作，並告知相關人員發生了甚麼事。下面這張圖跟隨一次舉報由頭到尾走完六個階段：由受理，經分流、確定範圍、遏制和復原，一直到決定下個月你們會收到多少舉報的指標與保安意識工作。
這裡說的只是經電郵傳播的這一種情況，而且僅限於此。它不是保安營運中心從一條偵測示警出發所運行的那種通用網絡安全事故應變生命週期：那個流程由遙測資料而不是由一個人開始，而本圖在「是否有帳戶被入侵的跡象？」這一步把個案移交給它，前提是某個郵箱被發現已落入他人控制。它也不是保安事故升級流程裡的那道嚴重程度階梯，也不是一次常規的密碼重設，因為這裡的重設是針對攻擊者已經掌握的憑證所做的遏制，並且必然伴隨工作階段撤銷。它同樣不是資料外洩通報：如果個人資料已經落入攻擊者手中，評估、法定時限以及與監管機構的溝通，屬於法律部門和資料保障主任的工作範圍，與本圖並行進行，而不是包含在其中。請把這張圖當作一個教學起點，再按照你們自己的事故應變程序、適用的法規，以及保安主管的審核去調整它。
四個判斷撐起整個流程。「被舉報的電郵是否惡意？」是把一次滋擾和一宗事故區分開來的定性結論，它由 SOC 分析員而不是服務台來做，因為一個仿冒網域和一次失敗的寄件人身分驗證檢查，都不是前線人員能下的判斷。「有沒有人點擊或回覆？」把一項電郵衞生工作變成一項身分工作，圖上一切代價高昂的環節都掛在它下面。「受影響使用者做了甚麼？」被畫成一個三分支判斷，而不是一串是非題，因為輸入憑證、執行了一個附件，以及一次險失事件，需要不同的團隊按不同的時鐘去處理。「是否需要全體員工預警？」被刻意放在保安管理層泳道：向每一位員工發一則訊息，是一項有成本的溝通決定，不應該只由發現這場攻擊活動的那位分析員一個人來做。
本流程圖涵蓋的內容
本範本包含
- 五條泳道——員工／舉報人、服務台、SOC 分析員、IT／身分團隊與保安管理層——橫跨六個階段：舉報與受理、分流與定性、確定攻擊範圍、遏制與清除、復原與溝通，以及結案與改進
- 兩條受理路徑匯入同一個隊列：按下舉報按鈕，樣本會直接送到保安團隊手上；而選擇致電的人則由服務台開一張工單，並附上原始電郵而不是靠描述記錄
- 一個定性判斷「被舉報的電郵是否惡意？」，其無害分支會回覆舉報人、調校電郵過濾規則，並以非惡意結案，而不是靜靜把它擱在一邊，因為正是這條回覆令大家願意繼續舉報
- 先確定範圍再刪除：「在租戶內搜尋其他副本」與「有沒有人點擊或回覆？」，隨後是一輪遏制清掃，清除每一份副本、封鎖寄件人、連結與檔案雜湊值，並在攻擊活動仍在持續送達時於「是否仍有新的副本送到？」上循環
- 一個三分支的「受影響使用者做了甚麼？」判斷：輸入了憑證會走向身分泳道裡的「重設密碼並撤銷工作階段」，打開了附件會走向隔離主機與全面掃描，而「有沒有帳戶被入侵的跡象？」則是升級而不是結案
- 溝通與收尾：「是否需要全體員工預警？」在保安管理層泳道獲批，收件人會被告知需要留意甚麼，而這宗舉報只有在記錄了失陷指標、時間線、舉報率與點擊率，以及一次保安意識跟進之後才會結案
何時使用本範本
- 你們在 Outlook 或 Gmail 裡有舉報按鈕，但背後沒有一份大家認可的處置手冊，於是一封被舉報的電郵會遇到甚麼，取決於恰好接手的是哪位分析員
- 用戶們把可疑電郵轉寄到一個沒人真正負責的共用收件箱，你們需要把受理、定性和給舉報人的回覆畫成一條完整路徑
- 一場憑證釣魚攻擊活動剛剛送達，你們想在下一波到達之前，把清除、重設、工作階段撤銷和郵箱規則檢查排好次序
- 你們正在撰寫事故應變計劃裡的釣魚電郵章節，需要它能乾淨地移交給更大範圍的保安事故流程，而不是與之重複
- 審核員問起員工如何舉報懷疑保安事件、之後又會發生甚麼，而這正是 ISO/IEC 27001:2022 附錄 A 控制項 6.8 所要求的舉報機制
運作方式
把泳道改成你們的角色
把員工／舉報人、服務台、SOC 分析員、IT／身分團隊和保安管理層，換成你們機構實際擁有的角色。不少機構根本沒有服務台這條泳道，因為舉報按鈕直接通向保安團隊；也有不少機構把身分相關工作放在 SOC 內部完成。與其讓一條泳道空置，不如把它刪除；如果某條泳道有一部分由外判服務供應商負責，就把它拆分。
列明每一條受理渠道
列出一封釣魚舉報可能抵達的每一種途徑：舉報按鈕、共用郵箱、服務台電話、代人轉寄的主管、告知你們發票收款方遭更改的客戶。然後標示哪些會自動進入分流隊列，哪些則取決於有沒有人記得轉寄——那個缺口，正是舉報靜靜流失的地方。
定下分流定性的判斷標準
打開「被舉報的電郵是否惡意？」，寫下分析員實際會進行的檢查：寄件人身分驗證是否一致、仿冒或新登記的網域、連結引爆、附件沙盒檢測，以及電郵是否索取憑證、付款或製造緊迫感。也要說明一封令人厭煩但無害的電郵會如何處理，令垃圾電郵的判定成為一個決定，而不是一個聳肩。
在清除之前先做好範圍搜尋
清除的效果取決於它前面那次搜尋的質素。記錄下你們搜尋時依據甚麼——應該包括寄件人地址、顯示名稱、主旨、連結和附件雜湊值——以及你們的工具能追溯到多久之前，通常只是雲端郵箱上一段較短的回溯視窗。再另行說明你們如何在本地部署郵箱、封存檔案以及任何已轉寄到外部的內容中找到副本。
商定身分應變內容及下令的人
決定「重設密碼並撤銷工作階段」這一步會令你們承諾做甚麼，以及凌晨三點誰有權下令執行。單單重設密碼，會令被盜取的工作階段權杖繼續可用，所以撤銷動作要與檢查 MFA 方式、郵箱規則和已授權應用放在同一步驟裡完成。同時說明新憑證會經一條攻擊者無法控制的渠道送達使用者。
決定由誰批准全體員工預警
在「是否需要全體員工預警？」旁邊寫上一個具體的名字，再定下一條門檻：涉及多少收件人、被冒用的是哪些品牌或高層、是否已經有人付款或輸入了憑證。提前擬好這份通知，因為在壓力之下臨時寫成的版本，往往只會提醒員工留意攻擊者一小時前已經更改的那個電郵主旨。
拿一封真實的舉報電郵對照走一遍
選取兩宗近期的舉報，一宗最終證實是垃圾電郵，另一宗演變成真實事故，與當時處理它們的人一同，將兩者都沿著這張圖走一遍。那些沒有人能說清由誰負責的步驟，以及那些明明發生過卻沒有畫出來的步驟，就是值得在發佈並演練這份處置手冊之前修正的發現。
常見問題
網絡釣魚事故應變流程包含哪些步驟？
員工發現一封可疑電郵並舉報，方式是使用電郵客戶端裡的按鈕，或者向服務台開一張附有原始電郵的工單。分析員檢查郵件標頭、連結和附件，得出一個定性結論。一封令人厭煩但無害的電郵會得到給舉報人的回覆、一次過濾規則調整和一份已結案的記錄。一封惡意電郵則會被確定範圍：在租戶內搜尋其他副本，並確認是否有人點擊或回覆過。隨後遏制階段會清除每一份副本，封鎖寄件人、連結與檔案雜湊值，並在副本持續送達期間反覆進行。受影響使用者做了甚麼，決定了後續走向。輸入了憑證意味著重設密碼並撤銷工作階段，同時檢查 MFA 方式、郵箱規則與已授權應用；打開了附件意味著隔離主機並進行掃描；帳戶被入侵的跡象則會升級至事故應變。否則，團隊會權衡是否需要全體員工預警，告知收件人需要留意甚麼，記錄失陷指標與各項指標，並與舉報人一同結案。
釣魚電郵應變與網絡安全事故應變有甚麼分別？
範圍和觸發方式不同。釣魚電郵應變是一個高頻率、在很大程度上可重複的流程，起點是一個人舉報了一封電郵，而且大多數個案最終都不會被正式宣告為一宗事故：電郵被清除、指標被封鎖、舉報人得到回覆，就此了結。網絡安全事故應變流程則由一次偵測或一次已確認的入侵開始，依次走過宣告、定級、指派事故總指揮、鑑證、清除與復原。兩者只在這張圖上的一個點相遇：當身分檢查顯示某個郵箱已經不再由其擁有人掌控時，釣魚電郵應變就完成了自己的任務，把個案移交出去。將兩者分開在兩個方向上都很重要：把每一封被舉報的電郵都推入完整的事故生命週期會拖垮團隊，而將一宗正在發生的帳戶接管當成一次郵箱清理，則會放跑攻擊者。
有人在釣魚頁面上輸入了憑證之後，重設密碼就足夠嗎？
通常不足夠。現代的憑證釣魚工具套件會以中間人的方式運作：偽造頁面代理了真實的登入過程，密碼和多重因素驗證提示都會被轉發給真正的服務，而攻擊者會截取隨之返回的工作階段權杖與更新權杖。這些權杖在密碼更改之後仍然有效，這正是本圖將重設與工作階段撤銷放在同一步驟裡的原因，並緊接著檢查已登記的 MFA 方式、郵箱轉寄規則和已授權的 OAuth 應用程式——攻擊者通常留後路的三個地方。長遠而言，能夠消除這類攻擊而不是事後清理的控制措施，是抗釣魚身分驗證。CISA 的指引將 FIDO/WebAuthn 驗證器以及智能卡等以 PKI 為基礎的方式列為抗釣魚形式，因為它們將登入過程綁定到真實網域上，在代理面前會失敗。
電郵送達之後，能否將一封釣魚電郵從所有郵箱裡清除？
只能部分做到，而且值得在你們作出承諾之前先了解清楚這個限度。雲端電郵平台為那些送達之後才被證實是惡意的電郵提供追溯清除功能。以微軟的 zero-hour auto purge 為例，它作用於雲端郵箱中已經送達的電郵，其搜尋範圍覆蓋最近 48 小時內送達的電郵，而且在受 Microsoft 365 保護的本地部署郵箱中並不生效。由分析員在保安入口網站發起的搜尋與清除，能撒出更大的網，但依然只覆蓋那個平台所掌管的郵箱。任何清除都無法觸及的，是收件人已經轉寄到外部的副本、被下載到本地封存檔案的電郵，或者聊天記錄裡的一張截圖。這正是本圖在「是否仍有新的副本送到？」上循環、而不是將清除當作一次性事件的原因，亦是告知收件人需要留意甚麼始終留在關鍵路徑上的原因。
一宗釣魚事故是否一定要上報監管機構？
這取決於攻擊者拿到了甚麼，而且不應該由分析員一個人來決定。根據英國和歐盟的 GDPR，資料控制者必須在意識到個人資料外洩後毫不遲延地通知其監管機構，條件許可時最遲不超過 72 小時，除非該外洩不太可能對個人的權利和自由造成風險；遲交的通報還必須說明延遲的原因。行業規定、合約和網絡保險保單還會在此之上設定各自的時限。實際的做法是，一旦這張圖走到帳戶被入侵的跡象這一步，法律部門和資料保障主任就會同步介入，技術工作則繼續進行。另外，亦有多個國家的機構會直接接收樣本本身：在英國，NCSC 的可疑電郵舉報服務（Suspicious Email Reporting Service）會接收轉寄至 report@phishing.gov.uk 的電郵。