浅谈网络安全事件调查那些事（一）

1. 攻防的事件响应

    网络攻防对抗是事件调查响应主要的应用场景，这种高强度对抗产生的事件是需要组织内安全调查人员去调查分析，其调查响应工作量是那些通用的木马、病毒或者脚本小子的攻击事件所不能比的。

    通用的木马、病毒事件，其特征比较固定明显，且这些特征都是已经被安全厂商、安全研究机构研究通透了，那么这些恶意行为已经是清晰明了的，也就不需要安全人员再去调查一遍，只要发现特定的IOC特征，事件处置人员直接按照已有的调查报告处置风险就可以了，甚至一些安全防护工具已经自动完成拦截而无需人为介入处理。

    但在网络攻防对抗中，攻击者的攻击意图是不确定的，攻击者的所使用的技术手法一定也是针对组织做了免杀或者绕过，这些战术手法就需要防守方的安全调查人员有更专业的能力和工具来完成调查响应工作。

    为了说明攻防中的事件响应是如何运作的，我们可以先简要列出攻防对抗中有哪些阶段，以及防守方是如何应对的。

    从攻防视角上看，攻击过程会有以下几个阶段（为简化概念，就不用KillChain或者ATT&CK模型）：

    在整个过程中，“打点”是找到可以利用的突破口，一旦利用成功就实现了“驻留”，“驻留”是入侵的关键第一步，“驻留”的成功意味着攻击方已经突破防守方的安全边界进入内网。后续的“横向”是为了扩大战果，直到最终实现入侵攻击的目标。

    同时，在防守方在防御过程中也有几个关键的阶段：

    “检测”是对边界的安全检测，确保在攻击发生时能够及时发现异常，一旦发现高度可疑的异常，就需要快速进入“调查”阶段，梳理出攻击路径，并进行“抑制”止损；在完成“抑制”后才会进行更完整的、彻底的修复阶段。

    防守方防守阶段中的“调查”和“抑制”就是安全事件调查响应过程。而攻击中的“驻留”和“横向”是发生在终端主机上的，那么顺其自然，防守方的事件调查响应也应该就聚焦在终端主机上。

    “检测”和“调查”都需要有相应的检测发现规则，最大的不同在于，“检测”关注系统中某一瞬间的状态改变值来识别异常，而“调查”是基于这个异常状态点进一步还原状态变更的原因，更关注系统在发生异常前后一段时间的上下文状态，也就是把一个“异常点”还原成一个“事件线”，如果涉及多个终端主机就还原成一个“攻击面”。

    安全事件调查响应的工作，就是顺着这样的思路，通过历史状态记录找出攻击方的攻击手法和攻击路径，确定攻击者的意图，评估损失并及时有效制止恢复。

2. 事件调查响应生命周期

    安全事件调查响应在安全体系中从开始到结束有一个区间范围，暂可以认为是安全事件响应的生命周期。

    在一个组织内，日常需要处理大量的安全设备告警，按照告警响应人员以及告警类型分类，大致有以下三种：

• Level1：处理设备日常告警，排除误报，处理低风险告警，快速闭环；

• Level2:  处理Level1无法处理的告警，对安全事件更深入分析；

• Level3：对高级威胁事件分析(如APT攻击)，需要更专业的知识(如木马后门二进制分析、攻击者画像溯源等)

    通常情况下，Level1响应人员需要面对大量的设备告警，需要对每个告警进行判断分析，这需要耗费相当的人力资源。所以，Level1这部分工作现在越来越多由自动化工具来完成，例如，一部分告警是已经被拦截的自动化攻击告警，这些告警可能是一些“无差别”攻击行为，可以通过SOAR编排脚本直接拦截掉；另外一些告警可以通过多设备关联分析、AI机器学习、行为分析判断等策略方法进一步判别、过滤、聚合等手段以降低数量。

    设备告警经过一段事件运营、经过Level1的处理，只有最后一小部分告警，才会进入到事件调查响应人员(Level2)的处理流程中。类似有这样的一个处理逻辑：

    Alert是各类安全设备产生的原始告警，这些告警数量巨大；Event是经过Level2的“事件”，相比Alert数量会降低很多，比Alert更准确描述环境状态，具有更高的可信度，但此时的Event还不能算是一个真实的安全事件(Incident)，Incident是指确实发生有损失的事件，这需要安全运营人员进行“事件调查”后才能判断。

    当然，理想的状态是Level1之后就已经是可以明确的事件，或者说不需要人工介入就能够完全将所有告警自动判断是否是事件，但在安全运营实际情况下，这是很高的难度。主要有以下几个原因：

1. 安全运营阶段可以使用各种手法(例如，关联分析、SOAR)去降噪、聚合，提高运营告警风险研判效率，但组织内的环境是动态变化的，即使再完美的策略，也需要根据业务状态而实时变化；而为了跟踪业务变化的过程，就需要人工介入去调查分析，输出新的检测策略去适配新的业务状态；

2. 面对APT类、攻防类等强目标性的攻击，攻击行为是“Case By Case”的，自动化的规则策略都有被绕过的可能，期望自动化就能解决所有问题是不切实际的。我们只能尽可能减少人工重复的事件调查，但不能完全避免人工的事件调查。

    所以，在一个成熟安全运营环境中，大部分的设备告警应该被自动化策略处理掉，仍存在一部分告警是必须人工通过事件调查才能完全闭环的。事件调查主要作用在Level2阶段，就是为了更好完成事件闭环。

    检测告警是事件“调查”起始，没有告警就不会有事件调查响应的动作，检测告警同时也是事件调查的基础。如果安全设备系统轻悄悄的，什么告警都没有，那就没有什么事件需要调查响应了。正是因为检测告警是事件调查响应的基础，而事件调查响应是检测告警的上层，所以当一个组织内还在疲于Level1阶段，是没有精力去考虑事件调查响应平台化建设。

    检测环节是整个安全体系的检测，可以是WAF、IPS等网络设备的检测，也可以是HIDS、EDR终端安全检测的告警。这个检测目标是保证安全边界安全，检测不安全的边界行为，能够快速发现异常行为，产生告警。这种告警虽然“快”和“准”，但未必都是确实发生了造成损失的安全事件。

    所以，Event是Alert在经过Level1处理后的结果，也是事件调查的起点；同时，如果组织内没有有效度过Level1告警风暴阶段，而进行事件调查平台化建设没有实际意义。

    如前面所说，Alert告警只能描述环境中某一个系统模块的在某一个时间的状态存在异常，不能描述这个异常状态发生的原因。因此Level2的事件调查就是从发生告警的这个“异常点”，去还原整个攻击事件的过程。

    例如一个主机的HIDS告警，只是描述在某个时间点当前这个主机发现了一个异常的行为点，事件调查就需要回溯出这个“异常点”发生的原因。首先要做的是，把这个主机状态变化梳理出一个事件的“时间线”，如果涉及到多个主机的，就需要在多个主机上列出状态变化，这样与这个告警的主机都有一个事件的“时间线”，这些不同的时间线最后就可以整合成这个告警的“面”，这个“面”才能回答为什么会出现这个告警、是否是真实的风险、是否已经造成损失、是否需要处置等等问题。

    因此，事件调查从本质上看，关键是能够掌握足够多的环境信息，对环境是否具备相当的“可见性”，才能完成事件调查工作。这有点类似警察在调查案件需要案发现场监控、取证、访问当事人一样，办案的过程就是通过这些”可见性“方式去获取足够证据来实现案件的侦察。(当然，真实情况中事件调查还包括人员访谈、恶意程序分析，这些都算是另外一个领域，能力有限，就不过多探讨。)

    系统环境的状态以及状态变化记录，就是”可见性“最直接的一种，这种状态或者记录就是“日志”。常见的调查过程就是获取这些日志的过程。例如，在终端主机做事件调查，就需要关注以下内容：

1. 进程网络日志

2. 用户账号记录

3. 用户访问记录

4. 计划任务

5. 用户登录日志

6. 服务创建日志

7. 应用日志

8. 命令执行日志

9. ......
   

    这些日志保存的越详细越具体，颗粒度越精细，越能够真实可靠还原整个事件过程，在实际调查响应中，可以参考ATT&CK框架中技术项的检测数据源来决定需要从哪些日志开始调查。

    在实际安全运营中，如果组织内有建设SIEM作为日志收集管理平台，那么SIEM就自然承担了一部分事件调查能力，因为SIEM目标是尽可能收集各类日志，只要SIEM收录了日志，就对组织内的某一部分环境具备一定的“可见性”。

    笔者曾参与过SIEM建设，在SIEM建设中就有一个灵魂拷问，就是收集的日志到底是以安全设备告警为主还是原始日志为主？例如，在主机检测方面，在部署了HIDS、EDR情况下是否还需要收集主机的原始数据(进程创建、网络等)？从检测角度看，HIDS、EDR产品在具备一定检测能力的情况下，是可以不再收集原始事件信息，但这些告警信息对调查响应是不够的。主要原因是这些告警信息缺少上下文信息，很难还原整个事件过程。同理，如果SIEM系统能够完全收录所有终端主机所有原始事件信息，SIEM就可以成为一个极佳的调查平台，在能力允许情况下甚至能够补充更多安全设备没有实现的检测项，但这样做的成本是庞大的。试想下在一个组织中有上万台服务器、上十万台PC终端，这些终端主机所有原始数据这么庞大，得需要多少的存储和计算成本，而在实际调查响应中，有1%的日志能够在事件调查用的上就已经很不错了，这种建设方式“投入产出比”实在是太低，是SIEM很难完全胜任事件调查平台的最重要的非技术因素。

    另外，事件调查不是固定的模式，是“Case by Case”的，SIEM上存储的日志未必能够满足所有事件调查响应所需要的信息，同时日志收集在SIEM是一项工程化事项，一项日志从收集到存储可能需要经历一定的时间，也不能满足紧急情况下的事件调查的需要。

    因此，理论上，SIEM可以完成事件调查，但在实际上，SIEM受限于一些技术、成本因素，SIEM只能提供给调查分析提供一部分便利，但不能提供完整的事件调查分析能力。

    “抑制”是响应过程中最后一个阶段，“抑制”的效果是强依赖于事件调查结果的。例如，一个钓鱼邮件攻击，除了简单拦截已经发现的恶意邮件，还需要分析出恶意后门的C2地址，再针对这个C2进行封禁。如果事件调查中没有找到这个C2地址，缺少C2的拦截，那么这个“抑制”动作的效果是不彻底而且存在风险的。

“抑制”主要有以下几个方式：

• 清理：清理是最有效的抑制手段，能够以最小损失还原系统的状态；

• 封禁：封禁是简单而且粗暴的做法，但也可能会影响业务；

• 停止：停止是停止服务，这个服务可以是线上的服务停止，也有可能是完全隔离一台终端或者主机让其用户不能正常使用。不管是什么情况的停止，都是最无奈的选择。导致这种情况的，有可能是0day尚未有好的手段来减缓攻击，也或者是因为各种原因导致调查响应的失败，无法实施清理或者封禁。

    抑制是需要执行一定动作的，这个动作可以在终端主机上，也可以将动作应用在网关设备上。

    在事件调查清晰的情况下，“抑制”操作相比事件“调查”的来说，是简单很多的。

3. 事件调查响应方式

    如上述所说，事件调查响应在Level2阶段，在这个阶段每个组织都有不同的落地实践方法。常见的有”人工手动调查响应“、”工具脚本响应“和”平台响应“。

    人工手动调查响应，是指当发生安全事件需要调查时，由安全分析人员直接登录到目标终端主机上进行调查分析的动作。人工手动调查响应的特点就是有点”费人“，哪里有疑似失陷，分析人员就往哪里上：登录机器、上传工具，捞日志、过滤日志、匹配IOC，再一顿命令操作......

    人工手动调查响应在小规模的环境中是非常适用的，不需要维护复杂的环境或者工具，但在大的组织里面，人工手动调查响应很快就会遇到瓶颈，主要原因可能有如下几点。

    首先，每个调查响应人员都有自己的调查分析方法、工具，方法和工具不能做到统一，就有可能出现同一个安全事件经不同人调查会有不同的调查结果，或者也存在不同的终端主机环境下受限于系统环境的限制出现调查异常的情况。

    例如，调查常用的日志解析过程，就有可能出现各种坑，可能是终端主机环境不能执行常用的日志解析工具，也可能是终端主机内存太小导致日志文件无法正常打开，更别说还有日志的快速检索过滤处理了。

    其次，人工手动调查最大的问题是无法应对批量调查响应问题。试想着上百个中了钓鱼邮件的终端用户，调查人员是无法逐个去上机排查的。

    从攻防实战中，这种钓鱼攻击的响应场景是经常发生的。在没有好的工具事件调查工具平台的情况下，调查人员通常通过询问用户的方式来判断钓鱼邮件的后门是否已经在终端上执行，但这种依靠用户来确认的攻击是否成功的方式是不可靠的。用户会因为一些不能明说的原因故意隐瞒真实情况。比如，钓鱼邮件有可能是为伪造招聘跳槽类的邮件，收到这些邮件的用户会隐瞒自己有”跳槽“的动机，谎称没有收到邮件或者没有运行邮件中的附件。这种对”人性的攻击“是对安全调查最大的难度。所以，用户的”证词“只能作为参考，而非判断事件的真实依据。

    总的来说，人工手动调查响应还是有很多的局限性，是非常依赖调查人员的能力水平和调查经验、实际调查环境的。

3.2 工具脚本调查响应

    为了解决”人工手动调查响应“各种局限和问题，应运而生了各种应急响应的工具或者脚本。

    工具脚本调查响应是指将工具或者脚本拷贝到目标终端主机上，在本地批量收集日志、信息，以加快事件调查进展，就是将人工手动调查过程自动化的一个方式。

    适用调查响应的工具脚本通常可以分两种：

1. “Case by Case”检测脚本工具：例如”log4j漏洞利用“的脚本、”永恒之蓝“的调查工具脚本；

2. 通用的信息采集脚本工具：适配通用的大多数调查场景，目标是尽可能收集事件调查关注的日志。

    "Case By Case"的工具脚本有最好的效果，但只是针对某个具体安全事件，这种往往只能做一种类型检测。这种比较适合在处理日常常见的病毒、木马攻击。

    通用的信息采集脚本工具能够适配常见的调查场景，但针对性不强，在某些情况是需要调查人员辅助于上级的人工手动调查动作，才能完全完成事件调查。

    工具脚本最大的好处就是能够按照既定的流程快速完成检测，其缺点也是”只能按照既定流程“完成检测或信息收集，在真实对抗或演练中，未必每个事件都是能够按照预置好的流程完成的，一旦工具脚本无法满足事件调查时，就会又进入“人工手动调查响应阶段”。

    其次，工具和脚本需要不断维护更新，随着需要面对的场景不断增加，工具和脚本也会不断臃肿，维护这些工具脚本也会成为新的挑战。

    工具脚本响应是人工手动响应的进阶，但随着调查场景不断增加，调查事件复杂不断提升，如果想要进一步提升调查响应的质量和效率，仅仅靠工具脚本就很难满足实际的事件调查需要了。在这种情况下，要进一步提升事件调查效率需要解决两个问题：工具的持续迭代开发维护和事件调查经验的有效沉淀，这就需要将事件调查能力提升到“平台级”，以系统化、工程化的思路来建设调查响应能力。

    要实现平台化的调查响应，首先想到的是终端主机的集中管控平台来实现平台化。如前面提到的，调查响应的”战场“主要在终端主机上，在终端主机Agent上实现调查响应能力应该是最简单的事情，例如常见部署在主机的HIDS和部署在终端的EDR两种Agent，都是调查响应最好的载体，例如可以利用这些HIDS或者EDR系统推送一些执行脚本，来代替某些需要上机调查的动作。

    但目前所大规模使用的HIDS和EDR的核心能力在威胁检测，响应能力只是作为产品的附加值存在，并不能算是完整的”调查响应平台化“的东西；即使有”调查响应“的能力，其功能还是受限的，只能完成一些初级的调查响应动作。

    因此，基于现有HIDS和EDR产品的作为调查响应平台，只能说”能用“，但离”好用“还有一段距离。

    在大的组织内部，只有建立一套专用的调查响应平台，才能更好应对日益复杂的事件调查需要。比如，如何应对大批量的终端主机调查取证，如何在某个特定范围内针对某个IOC狩猎，如何实现调查响应工作分工协助等。  笔者认为这样新的高阶调查方式应该是一个集合调查分析取证多种能力的综合“平台”。

这个平台应该具备以下特点：

• 适用范围广，具备非标环境、离线环境等其他各种"恶劣"环境下进行事件调查的能力；

• 灵活扩展能力，具备用户可定制扩展事件调查方式方法的能力；

• 可在线交互调查能力，满足不同事件调查场景不同调查方式不同的能力；

• 快速分析能力，能够确定失陷状态，是被植入后门还是被作为跳板；

• 调查取证能力，能够有效抓取解析日志，以更直观方式展示；

• 二次分析能力，能够结构化本地日志，离线导入分析，供二次深入调查分析；

• 团队协作能力，具备让多人同时调查，各司其职，加快响应处置进度；

• 持续监控能力，具备更细颗粒度监控，动态发现更隐蔽的恶意行为；

    简而言之，系统化、工程化的事件调查响应平台，既要满足人工手动调查的灵活自主，也要具备工具脚本的自动化能力，这种“半自动化”交互能力，才能最好提高事件调查能力，实现1+1>2的效果。

4 小结

    每个组织防守方都有各自应急响应的方式方法，如何去提高应急响应能力是每个防守方队员应该思考的问题，笔者也只是简单列出一些例子以及个人看法。或许也有人会觉得工具脚本也挺好用的，为啥还要去折腾平台建设呢？当然，在不同组织环境下，就会有不同的需求，没有说一种方式方法绝对”一定合适“或者“一定不合适”。

    作为经历了在对抗中各种坑的苦逼事件响应人员来说，建立平台化的响应能力，才是提升事件调查分析能力的最优方式。这也就是为什么有“Velociraptor(迅猛龙)”的原因。(Velociraptor是一款开源的、运行在终端主机的、监控、取证、响应平台，能够有效进行广泛的数字调查取证和网络安全事件调查。) 后面我们也将会介绍“Velocirapotor”作为一个事件响应平台的要素要点，讲讲顺丰基于Velociraptor建设DFIR平台的一些实践。