前言

随着网络环境变得更加复杂，界限变得模糊，安全事件频发，有的企业在安全建设初期或者没有合适的应急响应体系及流程，很多企业安全人员都变成了“救火队长”，陷入了出现问题，急忙解决事件的点对点恶性循环中，有时候甚至还要被领导误解，着实让人精疲力尽，心力交瘁，有苦说不出，头痛不已，那么，面对这样的情况，如何建立应急响应体系与流程呢？

一、目标

规范应急响应的流程，提升应急响应能力，减少“救火队长”的情况出现

二、威胁情报

说到应急响应，势必都会想到威胁情报，也可以说是情报驱动应急响应。那什么是威胁情报呢？旨在为面临威胁的资产主体提供全面的、准确的、与其相关的、并且能够执行和决策的知识和信息。那怎么样开展威胁情报工作呢？可以从OODA模型、情报获取、情报分析、情报决策、情报处置这五个方面说起。

2.1 OODA模型

在实际的我们采用的是OODA循环（又叫博伊德环）模型，它是由Observation观察、Orientation判断、Decision决策、Action执行四个步骤，将行动前的动作，进行了一步步分解。这些步骤，可以让我们的行动，有据可依，通过这个循环，则可以让我们的行动更加系统化、理性化。

2.2 情报获取

我们在做威胁情报收集之时，获取的途径一般都是互联网上预警的漏洞，主要包括Twitter，BM X-Force Exchange，CNVD,以及360cert等各种厂商公众号，情报共享群等，当然肯定还需要注意监管机构预警的漏洞情报。

注意，一般甲方企业都会与很多厂商有项目合作，在情报收集这一块，可以跟各家安全厂商沟通，希望能免费帮忙提供威胁情报支持，当然在资金充足的情况下，也可以采用付费订阅的方式每周或每天发送至工作邮箱。

2.3 情报分析

收集完成情报之后，因为非常多的情报，我们需要进行初步的筛选，可以根据漏洞利用的难易程度，受影响范围，还有网上是否已经有POC来进行区分，也就是优先级，一般我们都会选择远程代码执行，任意代码执行，exp，poc的漏洞优先进行分析，这样可以尽量快速的处理，毕竟每个企业的安全人员都是非常少的。

2.4 情报决策

对筛选的漏洞进行分析后，一般我们都会将写个情报分析报告，其中会包括情报来源，情报类型，可利用情况，修复方式，受影响的资产（需特别注意对互联网可访问资产），是否已有poc，等，从而得出一个风险级别，发送给领导决策，审阅，一般高危以上的情报，且单位也有受影响的资产，这时都会直接找领导现场沟通，待同意后再进行下一步操作，切记，邮件一定要领导审阅。

2.5 情报处置

针对已筛选出的情报，领导也审阅完成，这时就根据内部的规范流程，准备好应急处置的方案，受影响的资产，反馈表等，提交流程给开发团队，对漏洞进行修复处置，这时我们也需要跟进验证漏洞的修复情况，直至修复完成。这一步的反馈表是为了防止有资产更新的情况未发现，需开发反馈的，如已有实时同步的资产管理平台，反馈表也可忽略。

三、应急响应

3.1 准备工作

对于威胁情报驱动的应急响应工作，可以使用前面的应急处置方案，但对于不定时发生的应急处置工作，可以从几个方面做准备工作：

1、找到问题点，并在短时间内判断此次事件是否与安全有关。在发现故障后快速定位问题点考验的是运维团队和安全团队的综合协调能力。

2、快速恢复业务。这个阶段重点是准确，应急预案的选择和执行是否有效是关键。

3、进行全面排查，消除隐患。入侵者一般都会给自己留条后路，一个入侵点被封堵后不至于毫无办法。需要应急团队能够找出共性的特征（如：后门文件、反连域名等），然后进行细致筛查，没有应急团队的可以要求厂商协助处置。

3.2 应急类型

应急响应的类型一般包括病毒感染、系统漏洞、应用漏洞、入侵攻击、组件漏洞、中间件漏洞、信息泄露、仿冒欺诈等，可以根据不同类型先准备对应的应急响应方案模板，也可以在工单系统中将这些选项添加，以便及时处置。

3.3 应急级别

我们应急的级别分为严重、高危、中危、低危，针对严重与高危，都会事先与领导现场沟通的，会申请走签报或者EOA阅件处理单，需要各部门领导支持处置，对于中危及以下，可以根据情况自行处置，以下图仅供参考。

3.4 应急处置流程

在进行应急处置流程时，其实非常重要的是下图中的流程，不过，建议先指定是急响应的制度，这样在进行详细的应急处置之时，才有制度可依，会有很大的助力，不然只依靠口头的，会有很多不知名的因素，阻碍我们去处置。

应急响应的操作步骤，主要为识别、遏制、消除、恢复、反思五个。

四、跟进与处理

将情报告知给开发部门后，很多小伙伴可能会觉得，此项事情已经完成了，以为是开发部门的事情，然后就撒手不管了，其实这样是为自己挖了坑，因为开发的同事不一定有安全的知识，所以需要协助，处理好漏洞，直至验证修复，在这里我们是内部建设的工单系统，是将应急响应这种情况包含在内的，在上面创建一个应急响应的任务之时，会要求上传应急处置的方案，关联受影响的人员，这一部分跟漏洞管理类似，有兴趣的可以参考《企业安全建设之漏洞管理与运营》中的内容。

五、总结与改进

一般来说，我们每周都会对这些应急事项做个统计，分析，复盘，发现其中的不足之处，例如是情报来源不准确？情报分析不彻底？未按制度跟提交流程？哪些问题目前为止还未修复，有无缓解措施等？其实，不断的复盘与改进，才能在这方面做得更好，这也是我们团队一直重复做的事情，目前来说效果还是很不错的。有关于应急响应详细操作内容，感兴趣的小伙伴可以私聊我获取。