写在前面

书接上回

遏制、根除、恢复

限制策略

选择限制策略——根据不同安全事件类型制定不同限制策略

1、端点资产的潜在破坏和失窃（勒索、脱库等等）

2、利于证据保存（如果策略太过粗暴虽然可以快速阻断或停止损失，但也失去反侦查和记录详细信息的机会无法积累经验）

3、尽量保障服务的可用性（对于服务器来说此项更为重要）

4、执行策略所需的资源和时间（资源占用过多、执行复杂和时间过长基本不会被客户采用）

5、策略执行的有效性（部分限制、完全限制）

6、持续时间（比如限制扫描或暴力破解IP的时间等）

证据收集、处理

1、识别信息（编号、序列号、IP、主机名，如果还有别的唯一标识内容也应加进来）

2、参与取证、处理人员信息

3、取证、处理时间

4、证据保存（存放位置）

确定攻击者

1、确定攻击IP（包括跳板机）

2、对攻击者进行扫描、搜索（确定对手）

3、利用威胁情报

4、监测可能的通信信道可能的话（如IRC）

消除、恢复

1、清除恶意代码

2、禁用违规账号

3、干净的备份

4、重建系统

5、干净的替换版本

6、打补丁

7、更换口令

8、系统加固

9、采用更高级的监测、检测手段

事后工作

汲取经验

无论是客户、用户还是厂商都应该共享在端点事件响应中获取到的信息，刻意隐瞒这些内容不利于各方以后的工作开展。

1、到底发生了什么事，在什么时间发生的？

2、处理过程各参与人员表现如何？是否按预计的流程执行？执行是否充分？

3、事件响应过程中哪些信息是最重要的？

4、哪些工作对恢复有影响不管是好的还是坏的？

5、再次处理同类事件时需要哪些改进？

6、如何防止同类事件发生？

7、是否需要采用第三方工具响应事件？

使用收集到的数据

通过端点事件响应的积累所处理的安全事件数量增多，按事件分类的各项统计在整理、使用中将更为有效。

1、每个事件消耗的总时间

2、人员总劳动量

3、从事件发生到处理完毕的时间

4、从响应到提交报告的时间

5、客观评估——是否有完整记录文档；前兆和迹象内容；事件发现前是否已经产生损失；事件起因是否已经明确；损失多少；此事件是否有明确预防措施

6、主观评估——客户是否认为事件已得到有效处理，结果是否令人满意

7、从响应数据中是否能够提取新的IoC

事件响应审计

审计内容可以包括：流程、策略、工具、资源、组织模式结构、人员教育培训、文档报告等能够度量端点事件响应成功与否的内容。

保存

证据的保存；文档、数据的归档。

其他

建立端点安全事件响应策略和流程

端点事件响应不是端点安全产品厂商或用户某一方的独立工作，所有系统的利益相关者需共同努力，明确彼此在事件响应中的角色和责任，相互沟通协作的程度决定响应程度，依赖某一方通过技术手段搞定现在看是不大可能的。信息共享和外部信息联系可以包括cncert、ISP、软件厂商、公安等等。

EIR的好处

做的好是有好处，做不好就处处是坏处，好事不出门坏事传千里是肯定的，但凡出了岔子很容易失去客户信任在行业里迅速失去市场都是很快的。

情报为主

如果说端点安全产品在事件响应中占主导那工作开展会比较辛苦，情报为主则是难上手但一通百通随着情报网的扩大技术和经验的积累增多，队伍的扩大和传承会让优势放大毕竟产品就是载体。

演练

如果组织有能力进行演练应当经常操作下，比如护网或者重保。作为厂商围绕自家产品的演练更为重要更多的了解自己能力范围在真正事件响应时好知道派什么人去干什么活。

应该关注

团队

端点事件响应是需要一个团队，良好的沟通和共享会让自己和客户都有足够的自信。

灵活性

无论何时何地端点事件都有可能发生，端点事件响应应当具有足够的灵活性来满足所有的覆盖范围。

一体化

端点事件响应不是一个添加的插件不是一个孤立的活动，如果想发挥作用比如形成闭环什么之类，就要与其他流程和设施相集成。