应急响应流程及思路

应急响应流程及思路

一：前言

       对于还没有在项目中真正接触、参与过应急响应的同学来说，“应急响应”这四个字见的最多的就是建筑工地上的横幅 —— 人人懂应急，人人会响应。这里的应急响应和我们网络安全中的应急响应有着某种本质的相似，但却有些许操作的不同。

        网络安全中的应急响应，我个人的将其分为两种：一种是事前响应 —— 即未雨绸缪，做到防患于未然；将灾难性事件扼杀在萌芽之中；另一种就是事后响应 —— 即亡羊补牢；灾难性事件发生之后将损失降到最小。对于网络安全而言，我们所遇到的大部分应急响应的情况都是事后响应，导致这个情况主要是因为我国网络安全现状下企业安全投入与产出效果之间的矛盾以及网络安全事业起步晚、整体网络安全意识不高等。对于企业而言，对网络安全的投入基本是合规驱动（满足法律法规要求和监管要求）和事件驱动（安全事件），加之我国网络安全整体意识不强，不少企业基本就是实行出了问题再弥补的被动式防御措施。因此，本文着重讨论事后响应的流程及思路。

二：应急响应流程及思路

A：事前响应

       听到事前应急响应，不少同学肯定心里在想：事件没发生，何来应急？如何响应？笔者怕不是还没睡醒吧？如此不专业。在这里笔者保证：在和同学们分享此篇技术文章的时候是前一夜睡了一个好觉，还是自然醒。

        网络安全中的事前应急响应简单的概括为就是企业因某些安服服务驱动因素事前向安全公司购买相关蓝队安服服务或攻防演练服务，比如风险评估服务、人员安全意识培训服务、进行安全巡检服务、制定安全运营管理计划服务、举行应急演练服务、攻防演练服务、进行数据安全备份等，以此来提前对未发生的安全事件做出防范措施。

B：事后响应

      而对于事后应急响应，不少同学在不同的论坛、文章中也看见过。笔者将事后应急响应的流程归纳为：事件确认 ——>  事件抑制 ——> 事件处置 ——>  事件分析 ——> 编写报告 ——> 事后跟踪。

（一）事件确认：对已经发生的安全事件进行确认（是真实攻击还是设备误报等），定性分析处理事件所需要的资源支持。

1）确认安全事件的类型、评估事件的影响范围。

2）安服客户情绪，确定客户面对此次安全事件的真实需求和痛点。安全事件发生之后，客户可能存在焦急、紧张的情绪，作为技术人员需要用自己的专业性来安抚客户情绪，引导客户确认面对此次安全事件的真实需求，有利于技术人员快速、准确的处理安全事件。

3）根据经验定性判断处置此次安全事件所需要的资源支持（设备资源、人员资源、时间资源等等），并形成工单或报告提交给客户。（这个举措可以起到安抚客户情绪，并体现我们作为技术人员的专业性）

（二）事件抑制：确认为安全事件之后，为了防止攻击者将攻击面扩散，需要在一定程度上对事件进行攻击抑制。

       在事件处置之前，我们可以根据事件的严重性制定相应的应急措施，并根据客户的业务情况进行具体的事件抑制操作。

（1）可中断业务：即发生严重安全事件时，客户运行的业务系统可以暂时中断修复。

1）关闭在此次安全事件中被攻击失陷的业务系统，并告知客户可向用户发布系统暂时维护的通知，安抚用户。

2）断开被攻击系统的网络，或关闭被攻击利用的服务。

3）禁止登录或删除被攻击的系统账户。

（2）不同中断业务：即发生严重安全事件时，客户的业务系统不能中断运行。

1）修改被攻击的系统账户密码。

2）根据被攻击的具体情况，重新配置安全设备的安全策略。

3）设置源IP白名单。

4）对攻击感染的设备或系统进行隔离处置。

（三）事件处置：在对攻击系统进行隔离或对攻击进行抑制之后，需要对事件攻击进行具体的处置。

1）清除被攻击系统中的病毒、木马、恶意程序等。可以使用清理工具进行检测和清理：内存和进程检测工具：Process Hacker，启动项监控工具：Autoruns，文件、恶意代码检测工具：Pchunter，杀软，EDR等。

2）清理Web站点中存在的木马、暗链、挂马页面等。可以使用D盾、河马等进行木马、病毒检测和查杀。

3）恢复被攻击者篡改的系统、设备配置，删除攻击者创建的账户。

4）删除异常的系统服务，清理异常进程。

5）若业务中断，需要重启业务。

（四）原因分析：查找并分析此次安全事件的攻击链，利于预测、阻止和应对潜在的攻击。

1）进行威胁情报收集，确定攻击IP，了解攻击者的基本情况，利于后续的溯源工作。

2）对系统日志、Web日志、安全产品相关日志、网络流量日志等进行分析，理解攻击者的入侵手法，调查此次安全事件的原因。

3）根据客户需求，对攻击者进行溯源。

（五）编写报告：根据此次安全事件的具体情况编写《xx事件应急响应报告》

1）事件处置完成之后，根据此次安全事件的情况编写安全报告，描述安全事件的具体情况、处置过程、处置结果以及对事件的分析，并向客户提出整改建议、安全产品加固建议。【此处作为安全厂商的安全人员应该着重对待 —— 商机】

（六）事后跟踪：对此次安全事件进行跟踪，定时询问客户系统安全情况。

      一般的文章或论坛中对于应急响应的流程并没有这一步，作为技术侧人员认为在《xx安全事件报告》提交、通过之后此次事件就算结束。但笔者认为，事后跟踪却是另一个故事的开始。

       我国的安全服务现状是重产品轻服务，安全企业的收入主要还是依靠安全产品侧。虽然现在很多厂商想极力改变这种现状，但至少目前我国安全服务还是重产品轻服务。因此，在对于应急响应的流程中笔者加入了最后一环：事后跟踪。

       事后跟踪一方面可以复盘发现在安全事件应急响应中存在的不足和问题，利于安全企业进行改进提高；另一方面有助于事后监测客户系统安全情况，更重要的是给客户一种专业、负责的感觉。同时事后跟踪可以增强企业与客户的粘性，帮助客户明确企业在安全体系建设中的缺陷，利于帮助客户企业提高安全运营体系建设，降低、甚至杜绝此类安全事件再次发生的可能。