工业落地-滴滴安全《安全运营之自动编排SOAR的探索》

滴滴安全运营之自动编排 (SOAR) 的探索

DiDi:https://www.secrss.com/articles/25896

困难和挑战

• 海量异构的日志数据源
  • 覆盖广：通过各类sensor采集的数据，覆盖了办公网和客服网的终端，以及测试网生产网的服务器，还有公有云的虚拟机等等。
  • 来源多：HIDS，网络层的NTA，终端EDR，还有VPN的认证日志，DNS的解析记录，802.1x的认证，AD域控的日志，还有防火墙邮件服务器密罐的日志等等。
  • 量级大：每天用于安全审计的原始日志达到了10Tb及以上的量级。
  • 异构性：Hive、ElasticSearch、Kafka等等，而有些日志是设备通过Syslog和Webhook的方式打给我们的，这些日志都是异构的。
• 有效的告警会淹没在误报当中
  • 黑名单的规则来定义异常，无法感知未知；白名单规则，通过定义正常来发现异常；
  • 统计规则阈值的选取也和误报息息相关；
  • 在甲方日常的安全运营中，团队可能会受 KPI的影响
• 告警研判推理的挑战
  • 如果我们缺少有效的关联分析能力，就很难从各个孤立的告警中还原出攻击者的一次战术动作。
  • 告警研判过程中存在重复低效的二次取证的工作
  • 不完备的资产实体库
  • 研判过程中还缺乏知识的指引

如何针对事件检测响应去建构知识体系？

• 知识模型：STRIDE的模型、kill Chain杀链模型、ATT&CK模型
• 知识交换：指交换威胁情报和lOC识别的知识，目前业内比较通用的有像==STIX2.0==，还有TAXll协议。
• 知识运用：如何运用知识来指导我们做lOC规则的开发，如何做研判策略的设计，以及如何制定事件处置的SOP流程等等。
• 知识迭代：知识模型自身的迭代，比如说近期ATT&CK模型也推出了Sub-techniques，就是子技术的概念。另一方面就是日常运营的案件如何反馈到知识模型来做迭代。

如何建立科学的度量和评价体系？

我们在事件检测运营中有很多指标，比如围绕资产实体的，有HIDS部署的覆盖率，比如终端EDR的安装覆盖率，还有跨网络、跨安全域网络边界、南北向流量检测覆盖率等等。

还有围绕运营流程的，比如像比较核心的MTTD/MTTR指标。还有围绕能力矩阵的，比如ATT&CK矩阵的覆盖率。指标的选取，它关系到能否把控安全态势的全局以及能否做好牵引能力的建设，因此选取有效的度量和评价体系，也是存在挑战的。

MTTD = 故障与检测之间的总时间/事件数量

MTTA = 指从系统产生告警到人员开始注意并处理的平均时间。

安全编排自动化与响应SOAR，它能为安全事件检测与响应流程带来哪些改善?

SOAR分为安全编排自动化，安全事件响应平台，以及威胁情报平台三种技术工具的融合。

SOAR如何加速事件检测和响应

首先在IDR运营流程中，我们接收到一个异常的事件Event，我们如何通过SOAR的思想来处理这个事件，从而提升IDR流程的效率？

• 告警分诊:一个原始的告警里边可能只包含了少量的事件信息，我们需要在这个阶段使告警丰富化，也就是 Enrichment概念——将原始告警中的IP服务器，终端ID这样的字段，在我们内部的资产库当中查询出详细的信息，并且自动补充到告警信息中。
• 初步决策，比如有些字段命中了白名单库，或者威胁情报显示这是一个非恶意的良性的特征。将告警作为误报直接关闭，减少后面人工审计的运营负担。
• 调查取证：通过SOAR的自动调用能力，可以调用后台的数据，收集更多的IOC信息，我们也可以调用沙箱这个能力对可疑文件进行动态的检测，得到检测结果，从而实现证据的自动收集。
• 溯源关联分析：实现告警事件的上下文相关联事件的聚合。

比如说同一个告警事件，它发生在不同的资产实体上，或者说同一个资产实体，它在一定的时间段内，发生了多类的告警事件.

经过前期的告警分诊、误报关闭、调查取证的几个阶段，原始的事件event就转化为了一个需要人工验证的incident案件。在这个环节安全工程师会根据前面SOAR自动补充和取证的信息做出研判，进入到对这个事件的响应的流程。响应阶段也可以利用SOAR自动地执行安全处置的动作，包括邮件IM通知员工，或创建处置或漏洞工单，或是向防火墙/终端EDR下发安全策略（比如封禁）等等。这样我们就通过SOAR完成了一次告警事件的检测与响应的流程。

剧本编排的概念

以钓鱼邮件检测与响应的剧本为例。

• 检测钓鱼邮件时，首先是提取邮件的信息，包括发件人、收件人、正文里可点击的url链接列表、附件等等。
  • 从AD里查询出员工的相关信息，可以自动去邮件服务器的访问日志里面去查看员工近期有没有异常的登录行为，比如说异地登录，或者是使用非常设备登录等等。
  • URL链接，我们首先去威胁情报里查一下有没有命中情报样本。针对可疑的URL链接，我们可以结合像Whois信息，像域名的信息，对 URL进行评分。
  • 针对邮件的附件也可以做静态分析，看是否包含 office鱼叉。我们还可以利用Cuckoo这样的动态沙箱对邮件附件里的可执行文件做行为检测。我们还可以利用外部的比如Virus Total这样的样本分析平台，来看是否命中恶意样本。
• 经过信息的自动化收集和分析的动作，我们进入到最后的人工审计环节。这个时候安全工程师会结合前面自动收集的信息去做研判。一旦安全工程师识别出这是一个有效的钓鱼邮件，也会通过剧本的方式去执行后续的这些自动化的动作，包括向员工发送告警工单，要求他修改域账号的密码。我们还可以将发件人的邮箱加入邮件安全网关的发件人黑名单列表里，防止他再给其他员工继续发邮件。我们也可以将恶意的或可疑的钓鱼邮件链接的域名加入到我们DNS封禁列表里，来防止进一步的扩散。

结合滴滴的实践经验和探索，介绍贴合甲方实际场景的SOAR建设思路

需要明确SOAR在事件检测响应体系中的定位，也就是它与SIEM/SOC/安全事件响应平台SIRP之间的关系，还有它与TIP威胁情报平台之间的关系。SOAR可以理解为是事件响应平台或者是SOC的扩展能力。 当然SOAR也可以作为一个独立的平台，与SOC和TIP实现打通。

根据Gartner的定义，SOAR是一系列技术的合集，它能够帮助企业和组织收集安全运营团队监控到的各种信息，也包括各种安全系统产生的告警，并对这些信息进行告警分诊和事件分析。

SOAR在甲方如何落地，主要考虑三方面：

• 实现路径:
  • 可以采用商业化的产品，近期我们也看到很多国内外知名安全厂商陆续推出了SOAR这款产品。
  • 我们也可以基于开源工具做二次开发，比如说剧本编排引擎，它特别类似于一个Workflow的工作流引擎，我们可以基于开源的像Activity或者是Airflow这样的工作流引擎去做二次的开发。
  • 使用自研的方式。
• 技术选型：主要是考虑可视化剧本的编排引擎，还有剧本的执行引擎。
• 系统设计：SOAR虽然是一个扩展的能力，但是从系统设计的角度来说，一旦我们引入SOAR，就会将它串联到我们整个的 IDR流程当中。所以SOAR自身的稳定性，还有一些其他的技术指标，比如像EPS每秒处理的事件数，SLA，包括一些其他的benchmark等等，这些也是我们关注的重点。刚才也提到SOAR会串联到IDR流程里，所以它有可能会引入或导致一个单点问题，所以我们也会考虑分布式的部署。还有降级，一旦SOAR不可用的时候，我们的SOC或者事件响应平台能否降级到没有SOAR的状态。

如何评估SOAR的效果和收益？

• 对IDR核心运营指标MTTD和MTTR的提升，它能让我们技术运营投入更少的人力去做更多的事，提升人效。
• 他能否通过SOAR来识别攻击者完整的战术动作，也就是TTP。
• 通过将剧本的引入，将流程案件知识固化下来，牵引我们能力侧的建设。

结合滴滴的经验和探索，介绍一下SOAR的系统设计思想？

首先我们从各个sensor采集到的数据经过ETL存储在大数据的组件当中。我们的策略规则是作用在这些大数据的计算引擎上，像 Spark，Hadoop，还有Flink这样实时的引擎，也包括我们自研的异常检测的引擎，最终产生的异常告警事件会打到我们的event gateway通用事件网关上。这一阶段被我们称为异常检测阶段。

事件网关主要做两个事：一，做标准化，将这些异构的数据源产生的各种类型的告警里的字段格式和数据类型做标准化，以便后面我们在做SOAR编排的时候降低成本。二， 在这个环节我们会做 index，把原始的告警事件索引到数据库里，以便我们后面做关联分析，或者我们可以回溯的时候去实时地查询历史的告警事件数据。

【告警分诊】经过事件网关以后，我们紧接着做两个事情，一个是做Enrichment丰富化，第二个是做威胁情报。我们在丰富化这个阶段会补齐像服务器地址、员工信息、终端信息和调研我们内部的核心的资产库，将告警信息做丰富化。 第二就是我们会初步匹配告警字段里边比如像域名，像文件哈希，去我们本地的威胁情报库里面做匹配。

【调查取证】接下来就进入到我们的核心检测阶段SOAR编排环节，在这个环节我们将各种检测能力抽象成为各种检测引擎，比如像攻击检测引擎、误报检测引擎、调查取证引擎和关联分析引擎等等。

• 【黑名单】攻击检测引擎是做什么？主要是根据告警事件里的一些字段去我们本地的黑名单库列表里做匹配，一旦确认命中我们的黑名单，就可以不需要做后面一些列复杂的调查取证和关联分析工作，可以直接交给人工来做研判，甚至对它可以绕过人工来做自动化响应。

• 【白名单】误报检测是根据字段里边的一些特征，以及我们之前配置的白名单规则，命中了白名单，这个事件我们可以把它自动关闭掉，以减少后面调查取证的负担。

• 调查取证我们是将一些通用的外部接口和能力封装成一些函数或者脚本，来做自动化的调用。而这些封装的能力之间，我们也是以一个子剧本的方式来进行编排，它可以根据剧本流程的配置来做自动化的执行和调用。

• 关联分析引擎也是基于我们配置好的一些关联分析的规则，来针对这一个告警事件的上下文，或者一段时间内它同资产的一些其他告警事件来做关联和聚合，上报给人工去做研判。

这些不同的检测引擎之间，我们也是通过剧本的方式把它进行一个整体的编排。有些我们可以先经过攻击检测引擎，误报检测引擎，再做调查取证和关联分析；而有一些告警类型，我们通过剧本的编排，它就不需要去做攻击检测了，比如他通过误报检测就可以直接到调查取证检测。这些其实都是通过剧本来实现一个动态编排。

【人工验证】经过这个阶段的检测，原始事件就形成了一个具体的需要人工验证的案件，也就是incident。从原始的事件到案件，这个阶段我们称它为是检测阶段的SOAR编排。【自动处置】这阶段经过人工的验证，如果是一个有效的案件需要经过处置的话，它就会进入到后续的自动处置的流程里面。而这一阶段我们也是通过剧本的方式，将各种处置能力封装来自动编排上。这里边包括像通过邮件和IM消息的方式来通知用户，也包括我们调用工单系统，还有就是我们调用 EDR/IPS/防火墙的一些封禁策略等等，把它封装成自动的脚本，通过剧本的方式做编排，做自动的调用。

在做SOAR系统设计的时候，是如何把知识体系来融合到系统设计里的呢？

在上文提到的情报交互里有一个STIX2.0协议，STIX2.0有很多个构件，其中有几个构件其实是可以指导我们去做异常检测规则的开发，以及SOAR编排里的关联分析和处置动作的。

• indicator，就可以指导我们去做异常检测阶段的IOC规则开发；

• Attack Pattern，描述的其实就是TTP，可以指导我们在SOAR检测阶段去做关联分析规则；

• course of action构件，它是指导我们在做响应处置阶段的SOP的流程。

我们前面也提到了ATT&CK模型，其实ATT&CK模型和STIX2.0之间是有映射关系的，我们可以将我们的异常检测规则映射到ATT&CK模型上，主要是做两个事，第一个就是我们根据现有的检测点，可以总体来看我们对ATT&CK的覆盖率，这样它能牵引我们去做能力侧的建设，也就是检测策略建设。当我们发现缺少哪一部分的检测能力，我们就可以去部署新的sensor，开发新的IOC规则。

我们也可以结合ATT&CK模型去和我们的真实的日常运营中的案件做结合，去查看我们ATT&CK热力图，去从整体安全态势上看我们哪些场景是经常会被攻击的。我们也可以结合资产的重要性、等级和实际发生的案件，通过一个公式来计算出我们整体的风险值。

【异常检测评估指标】整个SOAR流程和指标体系也是紧密结合的，包括我们在异常检测阶段有能力矩阵的覆盖率这样的指标。还有我们在检测阶段的SOAR编排决定了我们的MTTD（平均检测时间）的指标，以及在响应阶段SOAR关联了我们的MTTR（平均响应时间）指标。

这样我们就围绕着SOAR的系统设计，将IDR事件检测与响应流程、SOAR的自动编排、知识体系和指标体系，都融合在了我们整个的SOAR的系统设计思想里。