3.12 关于应急响应
很多人认为应急响应就是SSH连上被黑的机器去查rootkit，直到今天我也基本不漏读那些思路清晰的入侵分析的paper，只不过工程师关注的跟CSO关注的还是有些不一样。10年前，我是乙方工程师时去客户机器上查后门，虽然没有犯过明显的大错误，但有时候还是很怕把系统搞垮了，毕竟人家也没备份数据，所以总归心里不踏实。如果你在SRC接到白帽子报漏洞，打开一看人已经入侵到系统了，然后就突然心里一沉，慌慌张张就要了个root账号SSH连上去了，这种状态其实很不好，搞不好反添乱，一个不小心就发生了点小意外把什么东西搞挂了，然后莫名其名自己就变成罪魁祸首了。
图3-6 应急响应的PDCERF模型
应急响应有一个PDCERF模型（也可以参考NIST SP800-61），如图3-6所示。简单说来就是一连串步骤。P是指Preparation（准备），之前要做各种准备工具，具体一点的比如应急工具：静态编译的ls、ifconfig、ps等总归是要事前准备好。D是指Detection（诊断），初步诊断发生了什么类型的问题，以助于后续工作展开，同样是大规模流量，L4 DDoS，CC还是蠕虫爆发，对应的应急手段不一样。C是指Containment（抑制），这是被大多数人忽略的一步，首先应该是抑制受害范围，隔离使受害面不继续扩大，再追求根治，而不是一边任其蔓延，一边去查后门，到头来你查完这台机器，入侵者在这时间档里又搞到了另外两台，然后你就干瞪眼吧。这跟ITIL的思路是一样的，问题发生时首先是用事件管理以平息事件，恢复SLA为目标，至于到底是什么原因可以先放一放，等恢复服务了，再用问题管理来解决根因的事情。接下来就是大多数人最熟悉的那一步，E是指Eradication（根除），寻找根因，封堵攻击源。R是指Recovery（恢复），把业务恢复至正常水平。最后，F是指follow-up（跟踪），监控有无异常，报告，管理环节的自省和改进措施，现在俗称安全运营的持续改进环节。
ITSM的思路贯穿于企业安全建设的方方面面，了解攻防技术只是说你具备了参与企业安全建设的技术理论基础，但并不代表你具备了企业安全建设的正确方法。之前说到抑制的环节，首先要了解业务、数据流、各服务接口调用关系，这些都是日常的积累，否则随便一个隔离又把什么服务搞挂了。反过来倒推，如果安全团队平时连个数据流图都没有的，发现单点出现问题症状时大致的系统间影响和潜在的最大受害范围都估计不出来的，那安全建设即便是救火也肯定是一团糟啦。
