從黑客攻擊聊聊事件響應與事件管理

春節期間，德國石油儲存公司 Oiltanking 遭到黑客組織的持續網絡攻擊。由此，讓我們來討論一下如何區別對待事件響應與事件管理。

作者丨陳峻

策劃丨孫淑娟

不知您是否留意到，我們這邊正在舉國上下歡慶春節和冬奧會開幕之時，遠在歐洲大陸的德國卻傳來了，其主要石油儲存公司 Oiltanking，以及礦物油貿易公司 Mabanaft 的 IT 系統遭到黑客組織的持續網絡攻擊。由于他們的儲罐裝 / 卸載過程，完全依賴于已被攻擊下線的計算機系統，因此無法從自動化退回到手動操作模式。此次中斷預計會給整個供應鏈造成嚴重的影響。

遙想 2021 年 5 月，DarkSide 黑客集團也曾利用勒索軟件，攻擊了美國最大燃油管道公司 Colonial Pipeline，并引起了油氣管道的計量系統無法運行，進而中斷服務。面對這些屢禁不止的惡意安全事件，我不禁利用這個春節長假中，再次思考了事件響應與事件管理的相關問題。

事件響應與事件管理的區別?

面對突發的各種網絡安全事件，我們通常考慮的是如何在最短的時間內，去消除事件的影響，甚至會眉毛胡子一把抓、病急亂投醫。不過，實際上事件響應(Incident Response，IR)和事件管理(Incident Management，IM)是兩種截然不同的處置方式。理清它們之間的區別，將有助于我們從根本上更好的管控安全事件。

從定義上來看：

事件響應主要包括對事件進行檢測分類、深入分析、實施控制、減少影響、保護關鍵數據、資產與系統、以及采取技術恢復等具體的行動要素。
事件管理主要涉及到安全事件響應團隊在各個處置階段所采取的不同流程，而且不限于技術流程。它包含了各種通信交流、升級轉發、以及事態報告等。可以說，它起到了將整個響應的環節串聯起來，形成一個有機整體的作用。

從人員上來看：

事件響應是技術人員的主要職責。
事件管理則需要更廣泛的利益相關方(例如：法務部門、公關團隊、合規人員、以及后勤保障等)開展溝通與協作。

從目標上來看：

事件響應需要各個職能角色各司其職，通過快速檢測和修復損壞，來達到預定的技術要求。
事件管理則著眼于最小化安全事件對于整個業務的影響，最大程度地降低危害、防止組織因違規而招致的懲罰。

事件威脅建模?

眾所周知，事件響應離不開響應團隊成員和應手的工具。常言道：“知己知彼，百戰不殆。”一套清晰全面的威脅模型，可以被用來詳細定義不同類型的安全威脅，概述組織會采取哪些略有區別地響應措施，以及涉及到的角色和責任等。面對可以預見的網絡、系統和應用等維度的安全威脅，業界常用 STRIDE 威脅建模，來識別潛在的漏洞，并建立響應機制。該模型包含了六種不同的威脅類別：

欺騙身份(Spoofing identity)，主要針對的是系統的身份認證機制。攻擊者偽造的身份既可以是合法用戶本身，又可以是合法的技術調用或進程。例如，典型的中間人攻擊(MIM)、網站木馬、郵件偽造等都屬于此類威脅。一旦獲得了易受攻擊系統的訪問權限，攻擊者便可以截取敏感信息，進而執行深層次的攻擊。
篡改數據(Tampering with data)，主要針對的是數據的完整性。攻擊者通過未經授權的數據篡改，可以更改系統或應用的配置文件，以獲得控制權、插入惡意代碼、甚至刪除日志。例如，數據包傳輸過程中的注入攻擊，以及由于執行了錯誤的代碼，而導致完整數據被損壞等都屬于此類威脅。對此，我們可以通過文件完整性監控(File Integrity Monitoring，FIM)，根據已創建的基線，去判斷和識別關鍵日志、配置與存儲文件是否被篡改。
否認(Repudiation), 主要體現在攻擊者在執行了非法操作后，隱匿其行蹤，以達到抵賴的效果。對此，我們可以通過審計用戶的登錄與執行，采取簽名和哈希等手段，來增強追蹤惡意活動的識別能力。
信息泄露(Information disclosure)，主要體現在應用或網站向未經授權的用戶泄露敏感數據。例如，在有漏洞的系統進行調用，可能會遭遇緩沖區溢出攻擊。同時，中間人對于傳輸數據的截獲也屬于此類威脅。值得注意的是，它與前面提到的“欺騙身份”威脅不同，攻擊者是直接獲取到不該泄露的信息，而不需要通過假扮或欺騙合法用戶來得到。
拒絕服務(Denial of Service，DoS)，主要體現在攻擊者迫使目標系統的資源(如：處理或存儲能力等方面)不可被訪問與使用、或完全無法受理正常服務請求。例如，各種 SYN 泛洪攻擊、TCP 復位攻擊、緩沖區溢出等都屬于此類威脅。對此，我們可以通過采用安全協議，完善配置，增加檢查等方式，來予以防范。
特權提升(Elevation of Privilege)，主要體現在攻擊者在系統管理員不知情的狀態下，通過普通用戶獲得特殊訪問權，進而破壞目標系統。例如，用戶代碼超越緩沖區，以更高權限執行敏感操作。或是由于訪問檢查的缺失或不當，導致攻擊者未經授權地運行了可執行文件等。

盡管 STRIDE 是目前最為流行且有效的威脅建模與安全設計框架，不過如果您覺得它有些陳舊的話，則可以參考最新的零信任網絡(zero trust networks，ZTN)安全模型。它秉承的是“從不信任，始終驗證”的概念，即：在任何用戶、資源或資產都是不可信的前提下，通過消除隱含的信任關系，并不斷驗證每個階段的交互過程，來保護目標組織和應用系統。

無論是被部署在云端，還是在本地，零信任網絡作為一種持續評估和驗證的關鍵性流程組件，可以在檢測過程中，為響應團隊提供有關的可疑訪問請求、以及事件本身的詳細信息。我們可以通過如下方面對各類網絡攻擊，做出及時響應，并最大限度地減少損害。

假設違規。由于凡事都不可信，因此我們能夠從網絡中已存在著攻擊者的角度出發，更加專注于阻止各種違規行為。
完整的可見性。我們能夠通過管理各種憑證、訪問、操作、端點環境、以及基礎設施，來監控用戶請求所對應的身份、設備、應用和數據，這四種元素的詳細信息。而在驗證過程中，一旦發現任何異常的訪問嘗試，響應團隊都能準確地關聯到特定的實體、應用和數據上。
自動化響應。由于處于零信任狀態，因此有待檢查的節點會更多。我們往往需要實施自動化的檢測與緩解手段，并通過事件關聯來剔除誤報，并自動更改網絡訪問規則，進而構建比手動響應更為有效的反應機制。

當然，沒有一種完全模型能夠完美到“團滅”所有的威脅、或“包治百病”。我們應當根據實際情況，選用、調整或自定義某一種、或混用各種安全模型的用例，通過縮小信任區域范圍，制定出更快、更有效的響應計劃。

事件嚴重級別?

光有定性的識別模型顯然是不夠的，我們在實踐中還需要有定量的指標等級，以便濾除“噪聲”，界定和分析事件。

從表面上看，嚴重性高的事件通常需要快速的響應，但是實際情況并非一成不變。由于在事件響應的過程中，我們往往推崇的是“快速生效”。因此，對于某些低嚴重性事件而言，如果它們需要調用的資源較少，能夠立竿見影，起到迅速遏制事件在范圍與程度的效果，那么我們就可以將其視為高優先級的處置目標，予以快速修復。可見，事件的嚴重程度并不能完全決定了事件的優先級，我們需要從業務的角度，多方面綜合考慮。

當然，最為穩妥的方法應該是：以事件對于業務的影響程度，來界定嚴重性級別。無論是服務級別目標(Service Level Object，SLO)也好，還是服務級別約定(Service Level Agreement，SLA)也罷，它們都直接影響著我們去確定安全事件的嚴重性與優先級，并且會影響到如何配置人員與資源，以及是否按需升級響應等級。在此，我以一個 App 的頁面平均加載時間為例，向您展示嚴重性與響應的關系：

嚴重程度	狀況	客戶影響	涉及到利益相關方
1	頁面無法加載	客戶無法使用應用服務違反SLA	響應團隊執行應急方案，各部門展開排查，告知管理層
2	頁面加載速度慢200%	服務響應極慢，客戶失去使用意愿	應急響應團隊協同運維團隊排查，并向客戶發出警告
3	頁面加載速度慢50%	服務響應緩慢，客戶產生抱怨	運維團隊排查
4	頁面加載速度慢1%-10%	大部分客戶未注意到	將事件錄入事件管理系統，但無需立即升級或發出警告

通常，我們應當事先制定好一個包含了事件影響范圍和程度的等級關系矩陣。運維人員和應急響應人員可以將收集到的指標參數，對應到事先明確定義好的取值范圍中，進而通過客觀且公式化結合方式(或是相乘、或是相加)，來確定其嚴重性。

事件管理團隊?

如前文所述，事件管理比事件響應更加“高屋建瓴”，是一整套實踐流程和解決方案。它不但需要組織能夠管理好安全事件的發展走勢，而且可以滿足所處環境中日益嚴苛的數據合規要求。此外，它還能夠讓各個利益相關方通過規范化的流程，避免同類事件的復發。

常言道：“凡事預則立，不預則廢。”事件管理切忌臨時抱佛腳。我們應當事先構建好一個“召之即來，來之能戰”的團隊。在實踐中，一些組織會片面地認為安全事件處理只和那些諳熟日常運維的技術大咖有關。但其實，若要真正管理好事件，少不了安全、基礎架構與運營(I&O)、以及管理層的調兵遣將與有效溝通。

事件管理指標?

如今已是大數據時代，我們擔心的不再是得不到必要的數據指標，而是向我們涌來的數據是否有用、是否能夠協助我們實施事件管理。以下便是一些常見的指標類別，它們有助于隨著事件響應的逐步推進，各方更好地把控安全事件的全局：

各類警告數量：我們可以通過衡量事件警告的不同類型、級別和數量，從宏觀上直接了解當前的任務積壓。
平均檢測時間(Mean time to detect，MTTD)：我們可以用來了解監控工具的事件觸發效率，以及運維人員對于事件威脅的敏感程度。
平均確認時間(Mean time to acknowledge，MTTA)：我們既可以用來判定對于事件分類的合理性，又能夠獲悉響應團隊剔除誤報的專業程度。
平均解決時間(Mean time to resolve，MTTR)：指從事件響應開始，到業務服務完全恢復所需要的平均時間。它是組織在事件管理能力方面的直接體現。
預算消耗比例。這反映了團隊在事先制定響應計劃，并申請資源配置方面的規劃能力。為了避免出現“時間未半，卻已花光預算”的情況，團隊應當實時根據該指標，靈活地調整事件處置的策略。

事件管理工具?

俗話說：“工欲善其事，必先利其器。”優秀的工具往往能夠協助我們進行事件的跟蹤、記錄、處置、以及最終的績效考評。在管理事件時，我們通常會用到如下兩類工具：

即時通訊工具。在實踐中，許多組織都會通過此類工具，方便團隊實時地以協同和會診的方式，去分析事件。各種圖文并茂的交流記錄，不但為事件的響應和決策過程提供了豐富的第一手資料，而且方便了響應過程的后期復盤。
事件管理工具。除了團隊之間的人員溝通，我們也離不開事件從生成時的捕獲，到原始信息的轉存，以及任務的分派等自動化流轉的過程。在實踐中，我們常用到的此類工具包括：ServiceNow 和 OnPage 等。響應團隊不但可以在 PC 端上使用它們，還能夠通過智能手持設備接收到其推送的通知，并通過友好的界面，隨時隨地參與事件的協同處理。