事件響應不是個事情，而是個過程。

[[228524]]

事件響應是有基準的，SANS培訓出來的安全人員都熟悉這6個階段：準備、識別、限制、清除、恢復、總結經驗教訓。這6個階段定義了公司企業以最少的修復時間將網絡攻擊破壞限制在最小范圍的基本操作。

但是，這6個階段中有些方面是公司企業老弄錯了的。

觀察最近一系列勒索軟件攻擊的受害者，不難看出事件響應是一個依所處情況不斷修正的動態過程。

大多數公司要么提供SaaS平臺供員工操作，要么依賴SaaS平臺運營，而他們部署的很多事件響應計劃并未真的適應了此類動態環境。

相反，大多數公司的事件響應計劃的焦點，都集中在本世紀初甚至更早時期的靜態環境上。雖說以前的靜態環境和現在的動態環境還是有很多交集，但確實有些小的方面如果不注意的話，是可以讓公司栽個大跟頭，信譽與底線雙雙受損的。

于是，這其中有哪些方面是公司企業尚未投注足夠的重視的呢?有哪些地方尚存有空白和漏洞呢?

最大的漏洞恐怕就是沒認識到事件響應是個過程，而不是個事情。你做的不是事件響應，而是事件響應中的一個階段。

另外，限制和清除這兩個階段之間的差異也少有人意識到。很多人都覺得直接跳到清除過程就好了啊，清除掉了不就限制了威脅的破壞了么?

然而，這種想法大錯特錯。

限制階段的存在是有原因的。通過將威脅限制在某一范圍，事件響應團隊就有時間對事件進行恰當的排查。這又走回了識別階段，有些公司就是在這里會有些迷惑與混亂。識別階段不是入侵檢測，而是確定公司所遭遇攻擊已經嚴重到何種程度。

你得找出每一臺被感染的設備，如若不然，攻擊者就仍然會在公司網絡中留下據點，即便事件響應的所有6個階段都走完了。

換句話說，限制階段基本上就是密集監視，對攻擊者圍追堵截，盡一切努力阻礙其達成最終目標。

這一階段，響應團隊依然在勾勒對手的輪廓，了解感染的范圍和嚴重程度，但卻又好像什么都沒有干，因為你僅僅是在看著。而這就是大多數公司都很難進行的部分之一，畢竟，干看著對手而不動作的耐心不是每個人都有的。

如果有在司法部門工作的經歷，倒是不難理解為什么會有“限制”這個階段了。這一階段可以讓你確定自己已經完全摸清了狀況，可以在真正的壞事即將發生時加以阻斷。但如果沒能做好這一步驟就馬上切到了清除階段，那基本上相當于做無用功，等于又重新回到了原點。

大多數事件響應計劃中的第二大空白，集中在恢復和經驗總結上。大多數公司企業在這方面做得糟透了。

他們總是太過關注自己是怎么被攻擊的，或者發生的情況是有多么異常。

然而，事件的發生肯定不僅僅運氣不好這個原因。這些公司卻放棄了認識到同樣的事件極有可能再次發生的機會。

他們沒有花時間去追問可以做些什么來確保既從當前事件中恢復，又能檢測并擊敗未來的類似事件。

而一旦公司防護脆弱的事流傳出去，被攻擊的風險就會成倍上升，因為別的黑客都排長隊等著試手了，更別說曾經嘗試過的那撥攻擊者了。

攻擊者第一次沒能得手最終目標的話，他們卷土重來的概率幾乎是100%。

想要公司企業承認自己防護失敗，承認從長遠看自己必須做得更好，是需要相當的自我意識的，這也正是為什么回復和經驗總結階段如此重要的原因所在。然而，想要達到這種級別的自我意識，公司文化就不得不做出一些改變。

事件發生后，大多數公司都集中在打補丁或增加額外的入侵檢測防護層上，卻忘了問題的根源。

但實際上，退回到最初的幾個階段來衡量某些東西才是真正應該做的。比如，威脅入侵了多長時間你才檢測出來?也就是業內很多人說的，駐留時間有多長?

如果每次事件后都不能縮短駐留時間，那只是說明公司的入侵檢測存在系統性問題。

但有趣的是，大多數公司企業都不討論駐留時間。你幾乎看不到有哪家公司談論自己在哪個年份處理了多少事件，自己的響應速度有多快。

事件響應的底線就在于，這是一個循環，而你總是處在經驗教訓總結這個階段。

所以，這個循環永遠不會完結，你不過是又走回識別階段，在想“別的事件將要發生，我們能找出來嗎?”

事件響應成為大多數公司日常安全運營而不是有事時才想起來用用的原因正在于此。

事實上，安全行業中將事件響應作為日常任務采用的公司，也比那些求助于兩三年前就弄好放那兒積灰的發展得好。