上两篇文章提到了对情报的简单梳理与实际工作中应用的简单场景，不过也仅仅只是简单的抛砖引玉。本身计算机安全是一个很大的范畴，每个小方向与大方向如果需要深入研究与实践都是可以特别深入的，作为安全人员选择好自己决心从事的方向并付出行动尊重客观规律与技术，这样就有可能看到不一样的风景。接下来就回到事件响应这个方向，理解相关的方法论与情报结合的经典实践。

事件响应是一种抽象的表达，有可能仅仅只是操作系统故障导致需要重新安装系统，也可能相关应用软件故障需要IT支持人员进行故障修复保证办公正常。甚至于也可能是遭遇网络入侵或攻击，需要阻断或者排查受损范围等场景，总体来说是一个遇到问题需要及时解决问题的方向。事件响应的参与双方为攻击者和防御者，由于客观原因无法得知攻击者的在事件响应过程中的所有行动，所以目前整体上上以防御者的角度来思考事件响应。

模型

模型在之前的文章中提及过，这里就简单列举下，事件响应周期如下：

预备阶段我们需要在安全建设完成的情况下做好监测与加固工作，对于整体安全架构的设计与实现，这个确实是最底层的核心要素。如果安全架构存在一点点问题一旦遇到相关安全风险确实会对后续的事件响应阶段造成困扰与影响，例如内部网络防御架构设计时只部署了旁路流量检测设备并未有全流量设备做好流量审计与纪录，导致后续排查风险时相关节点流量缺失影响排查效果甚至会遗漏风险资产，内部网络架构时存在NAT模式或存在私接路由器场景下无法定位到所需机器的发起请求的资产地址，因此针对这类需要内部排查的场景时往往会存在阻碍，所以对资产梳理是一个非常重要的防御准备工作，上述是在监测场景下经常遇到的问题。除了监测方向外，加固也是非常重要的一环，对于权限类的加固一定要确保权限最小原则以及分地区划分权限原则，避免被攻击者找到弱点直接入侵进而影响不同区域，遇到最多的场景就是总部入侵分部或者分部入侵到总部，由于总部或分部存在行政等级的不同，因此给排查风险带来很大的阻碍，如何正确的配置好安全设备做好内部网络设备各种安全配置也是一个需要投入精力认真实践的事情。

做好流程化与文档整理，虽然这个环节与技术范围关系不大，但这是可以提升效率与更快定位风险的一种方法。比如一旦出现安全问题响应人员匆忙去处理很可能导致前期没有做好与相关人员的沟通而导致浪费了大量时间却效果不好，前期的有效沟通可以一定程度避免走错方向。流程与文档化整理往往是在吃过亏以后才会逐步完善并得到补充，这也是经验积累的一环。实践是检验真理的唯一标准，对于事件响应也是如此，演练阶段也是非常重要的一环，最好的事件响应团队是那些一起经历过事件的团队，最好的办法就是演练，演练可以发现很多难以注意到的风险与问题。目前大家比较常用的是渗透测试（模拟黑客的入侵手段借此发现防御的薄弱环节）、针对大多数场景下的钓鱼攻击演练来以此提高员工的安全风险意识，毕竟安全意识培训再多也难以抵得上一次被钓鱼演练攻击后的真实感受。

识别阶段表明已经意识到可能所负责的网络或者单位已经有入侵痕迹了，于是需要将攻击痕迹给找出来。在将其揪出来的过程中存在快或慢以及彻底或者残留的结果，这里与情报结合的一点是在直接需要响应之前如果能识别出更多关于攻击或者攻击者的信息将会对接下来的响应提供更大的帮助，威胁情报的关键目标之一就是增强识别阶段，提高早期识别攻击者的方法的准确性与数量。例如不少的公开威胁分析报告表明某个黑客组织经常使用某种攻击方法或者技巧，因此在发现疑似该黑客组织的攻击入侵痕迹后，可以在内部重点搜寻是否有相同的入侵痕迹，这样子能更快地定位风险。

这个阶段比较好理解，需要减缓或者消除攻击者入侵所带来的影响，常见的方法有断网，阻断恶意域名或IP的通信，锁定受影响的账号等，这些属于简单的临时措施，所以攻击者就有可能存在二级后门或者跳板，这块在遭遇过的一些针对性攻击事件响应中确实存在，在发现被防御者阻断后再次利用后门或跳板获得控制权。

消除阶段是一个比较长的过程，主要是要尽量彻底地将攻击者所带来的影响给消除，因此涉及到数字调查与取证（DFIR）还原入侵痕迹与受影响的资产范围以及恶意代码与流量分析等相关环节，响应人员无法同时掌握这么多的技能，因此需要团队协作共同应对。在处理针对性攻击事件时，如若要彻底消除影响还需要事件响应团队的协作才能更快地完成这个阶段，针对已经发现的受控资产完成响应后，最好的建议是直接重装系统，如果发现存在更底层的后门等风险则还需要直接清除相关硬件与芯片数据等（例如UEFI后门等bootkit风险）。不过这种场景由于其特殊性会非常罕见，因此大部分情况下要想彻底清除风险，条件允许的情况下重装系统是非常好的方法。

IT支持人员或者运营人员相比于应急响应人员会更熟悉相关的资产属性以及服务类别，因此恢复阶段除了应急响应人员还需要与其他部门人员协作，保证受控的资产在恢复后能正常使用，恢复相关的服务，笔者遇到的一个真实案例，在完成Linux环境rootkit的响应后需要对所有受控服务器进行查杀清除风险恢复正常，但是在编写完shell脚本后并未对相关兼容性进行验证（其实也没法像上线环境一样严格验证），不过也能理解毕竟响应人员是没有系统运维人员更有专业性的，所以结束响应后提交查杀与清除脚本让用户批量运行后，过了有一段时间朋友从其他渠道反馈其中一台服务器就无法进入系统了。因此涉及影响系统的操作（例如内核层面的风险）需做好充足验证并提前说明风险，最好是响应人员提供相关做法参考，不要参与该阶段。这个根据具体入侵事件会有不同的做法，这里不再叙述。

反思阶段是一个比较尴尬的阶段，安全事件的出现有时候也算是一个比较尴尬的事情，相安无事没有发现任何安全事件的时候大家会渐渐忘记了做好防御与日常运营的重要性，一旦发现了安全事件又会表明犯错了，也许之前的部署以及防御可能存在问题。不过作为一种理想的模型，反思阶段是必要的，没有反思就不会有改进与提升，只有反思才能让事件响应团队快速成长。一般反思的时候反问自己的基础问题如下：

1、发生了什么事？

2、我们在哪方面做得好？

3、我们在哪方面可以做得更好？

4、下一次我们要做什么不同的事？

5、哪些设备或者策略可以识别出本次整个入侵过程中的痕迹呢？

6、我们可以提取什么特征或者情报来识别其余的受害者呢？

7、有没有比较好的措施尽量全面地发现并清除内部所有攻击者的痕迹呢？

以上的一些问题笔者在亲身参与的响应过程中也有体会，总的来说反思的内容挺多的，业界其实大家都有比较普遍的反思方法与做法，但是想与实际去做好其实是不对等的，反思最终是要能做出改变并影响下一次安全事件响应的效果甚至于提高防御能力，这样子反思阶段才能算是取得了进步或者效果，其实也是变相地向攻击者“学习”。

由于一本书的内容很多，这里就摘了一小部分想法加上自己的理解与实践整理成文属于第三部分内容，后续将会有时间继续纪录整理笔记一一输出。