事件應變為何不能再照固定流程走？SANS從勒索、雲端與OT拆解實務難題

傳統事件應變雖已有一套成熟流程，但面對今日攻擊型態，線性方法逐漸顯得不足。SANS Institute於9月15日發布一份720頁的技術資源《Dynamic Incident Response: A Framework for Security Teams》，提出動態事件應變框架，打破應變流程缺乏彈性的限制，改以可隨新證據反覆調整的方式處理事件。至於為何需要做出這項改變，SANS在一場線上直播發表會中邀集本書多名作者，從勒索軟體、雲端，以及OT／ICS等不同環境的第一線經驗，說明現代資安事件為何愈來愈難以沿用傳統流程處理，以及事件應變如今面臨的實務挑戰與關注重點。

身為主作者的Joshua Wright表示，約1年6個多月前，SANS首席AI長暨研究長Rob T. Lee提議應重新思考事件應變流程，而這也呼應他長期在教學與實務中觀察到的問題：現有方法雖已有成熟管理流程，卻仍缺乏一套能銜接管理與技術實務，並讓應變團隊隨新證據持續調整調查範圍與處置方式的公開框架。

他進一步指出，實際事件並不會按照準備、識別、圍堵、清除到復原的順序一路推進，應變人員在處理過程中，往往會因出現新的入侵指標或受害系統，重新回到前面的調查與範圍界定工作。

勒索軟體攻擊型態的變化，也顯示事件應變需要面對更複雜的攻擊範圍。負責撰寫勒索軟體與網路恐嚇章節的Ryan Chapman指出，近年的攻擊模式已明顯改變，攻擊者不再只著眼於加密Windows網域中的系統或檔案伺服器，也愈來愈常從企業身分、帳號及第三方存取憑證下手。自2022年以來，許多攻擊團體大量運用語音網路釣魚（Vishing）等社交工程，一旦取得SSO帳號的控制權，就可能進一步存取GitHub、GitLab、Atlassian甚至薪資系統並竊取資料。

當攻擊活動延伸到身分與多個SaaS平臺後，事件應變的另一個難題就是可見性不足。Chapman表示，攻擊者取得SSO權限後，可能利用TruffleHog等工具大量搜尋GitHub程式碼庫中的密碼、API金鑰與其他機密資訊，但不少企業並未集中蒐集相關平臺日誌，甚至事件發生後，仍得由應變人員逐一登入系統、動匯出CSV檔案並進行分析。

類似問題也出現在雲端環境。負責雲端事件應變章節的Megan Roddie-Fonseca指出，雲端平臺預設多半只記錄高階管理事件，至於敏感資料實際由誰存取、是否遭下載等資料層面（Data Plane）的活動，則未必預設留下紀錄；一旦事件發生，企業甚至可能連最基本的「資料是否外洩」都無法回答。這也意味著，若企業平時沒有依資料風險開啟足夠的雲端存取日誌，即使事故發生後知道帳號或設定曾遭異動，也可能無法進一步確認敏感資料是否遭存取或外洩。

到了OT與ICS環境，事件應變更不能直接套用IT經驗。負責相關章節的Dean Parsons指出，約80%的OT資產並非一般Windows或Linux系統，傳統端點鑑識工具只能涵蓋部分環境；同時，OT處置還必須將實體安全放在首位。Parsons建議，企業應優先掌握HMI、工程工作站、Data Historian與PLC等關鍵資產紀錄，並透過能解析Modbus TCP、EtherNet/IP及CIP等工控協定的網路分析工具補足可見性。對OT應變團隊而言，調查與處置因此必須同時考量設備特性、工控協定與實體安全風險。

此外，這幾位作者也分享各自推薦閱讀的章節。Joshua Wright與Megan Roddie-Fonseca都提到可先從介紹事件應變演進與動態框架的內容讀起；Dean Parsons則推薦Ryan Chapman撰寫的勒索軟體與網路恐嚇相關章節，作為OT團隊進行兵棋推演與技能對齊的參考；Ryan Chapman則推薦「Prepare」相關內容，強調事前準備是事件應變中經常被忽略的重要環節。