大多数企业都搞错了事件响应的这两个阶段

事件响应不是个事情，而是个过程。

[[228524]]

事件响应是有基准的，SANS培训出来的安全人员都熟悉这6个阶段：准备、识别、限制、清除、恢复、总结经验教训。这6个阶段定义了公司企业以最少的修复时间将网络攻击破坏限制在最小范围的基本操作。

但是，这6个阶段中有些方面是公司企业老弄错了的。

观察最近一系列勒索软件攻击的受害者，不难看出事件响应是一个依所处情况不断修正的动态过程。

大多数公司要么提供SaaS平台供员工操作，要么依赖SaaS平台运营，而他们部署的很多事件响应计划并未真的适应了此类动态环境。

相反，大多数公司的事件响应计划的焦点，都集中在本世纪初甚至更早时期的静态环境上。虽说以前的静态环境和现在的动态环境还是有很多交集，但确实有些小的方面如果不注意的话，是可以让公司栽个大跟头，信誉与底线双双受损的。

于是，这其中有哪些方面是公司企业尚未投注足够的重视的呢?有哪些地方尚存有空白和漏洞呢?

最大的漏洞恐怕就是没认识到事件响应是个过程，而不是个事情。你做的不是事件响应，而是事件响应中的一个阶段。

另外，限制和清除这两个阶段之间的差异也少有人意识到。很多人都觉得直接跳到清除过程就好了啊，清除掉了不就限制了威胁的破坏了么?

然而，这种想法大错特错。

限制阶段的存在是有原因的。通过将威胁限制在某一范围，事件响应团队就有时间对事件进行恰当的排查。这又走回了识别阶段，有些公司就是在这里会有些迷惑与混乱。识别阶段不是入侵检测，而是确定公司所遭遇攻击已经严重到何种程度。

你得找出每一台被感染的设备，如若不然，攻击者就仍然会在公司网络中留下据点，即便事件响应的所有6个阶段都走完了。

换句话说，限制阶段基本上就是密集监视，对攻击者围追堵截，尽一切努力阻碍其达成最终目标。

这一阶段，响应团队依然在勾勒对手的轮廓，了解感染的范围和严重程度，但却又好像什么都没有干，因为你仅仅是在看着。而这就是大多数公司都很难进行的部分之一，毕竟，干看着对手而不动作的耐心不是每个人都有的。

如果有在司法部门工作的经历，倒是不难理解为什么会有“限制”这个阶段了。这一阶段可以让你确定自己已经完全摸清了状况，可以在真正的坏事即将发生时加以阻断。但如果没能做好这一步骤就马上切到了清除阶段，那基本上相当于做无用功，等于又重新回到了原点。

大多数事件响应计划中的第二大空白，集中在恢复和经验总结上。大多数公司企业在这方面做得糟透了。

他们总是太过关注自己是怎么被攻击的，或者发生的情况是有多么异常。

然而，事件的发生肯定不仅仅运气不好这个原因。这些公司却放弃了认识到同样的事件极有可能再次发生的机会。

他们没有花时间去追问可以做些什么来确保既从当前事件中恢复，又能检测并击败未来的类似事件。

而一旦公司防护脆弱的事流传出去，被攻击的风险就会成倍上升，因为别的黑客都排长队等着试手了，更别说曾经尝试过的那拨攻击者了。

攻击者第一次没能得手最终目标的话，他们卷土重来的概率几乎是100%。

想要公司企业承认自己防护失败，承认从长远看自己必须做得更好，是需要相当的自我意识的，这也正是为什么回复和经验总结阶段如此重要的原因所在。然而，想要达到这种级别的自我意识，公司文化就不得不做出一些改变。

事件发生后，大多数公司都集中在打补丁或增加额外的入侵检测防护层上，却忘了问题的根源。

但实际上，退回到最初的几个阶段来衡量某些东西才是真正应该做的。比如，威胁入侵了多长时间你才检测出来?也就是业内很多人说的，驻留时间有多长?

如果每次事件后都不能缩短驻留时间，那只是说明公司的入侵检测存在系统性问题。

但有趣的是，大多数公司企业都不讨论驻留时间。你几乎看不到有哪家公司谈论自己在哪个年份处理了多少事件，自己的响应速度有多快。

事件响应的底线就在于，这是一个循环，而你总是处在经验教训总结这个阶段。

所以，这个循环永远不会完结，你不过是又走回识别阶段，在想“别的事件将要发生，我们能找出来吗?”

事件响应成为大多数公司日常安全运营而不是有事时才想起来用用的原因正在于此。

事实上，安全行业中将事件响应作为日常任务采用的公司，也比那些求助于两三年前就弄好放那儿积灰的发展得好。