背景

作为一名安全应急人员，每天要处理安全系统的大量告警，据笔者了解有些公司的安全应急人员每天要处理几百甚至上千个告警，而大部分是无效告警，其中真正的安全事件是否遗漏、响应是否及时，没有人知道。

此外随着业务上云和使用云原生开发模式，告警的数量也随着容器的量级大幅增长，应急人员能否长期保持专注力？大量的无效告警显然已经影响到应急质量和应急人员的生活质量了（周末值班）。

安全系统提高告警质量可以解决这个问题，但在现实环境中，安全系统众多且策略研发同学一般需要一个较长的周期才能优化，有时候优化甚至赶不上告警波动变化。

基于这些问题我们尝试建设了基于 SOAR 的新一代应急运营方案，以提高安全响应效率，EDR 是对响应要求非常高的系统且误报也比较多，本文以腾讯自研的 EDR“洋葱” 系统的安全运营为例分享一些实践和思路，希望能对大家有所帮助，也请各位不吝赐教。

我们要实现的三个目标：

1. 策略逻辑和告警逻辑分离

应急人员不再被动接收告警，将策略和告警逻辑分开，应急人员可以根据告警组织自动化响应流程

2. 精细化运营

解决重复误报、规避告警风暴和业务特性误报，加强关联分析和划分响应优先级

3. 精准事件自动化响应

分析日志/数据、找人和止损操作尽量自动化，提高 MTTR

策略告警分离：SOAR 架构建设探索

2.1 选择 SOAR 的原因

我们使用 SOAR 架构实现了策略和告警的分离，为什么选择 SOAR 而不使用其他方案——比如让安全应急人员直接修改策略，主要有以下几个原因：

1. 策略研发的策略逻辑涉及比较复杂的算法，运营人员直接修改策略需要非常高的学习成本，效率低下，也容易出现问题

2. 很多实时策略基于 Flink 等流式平台实现，需要开发 JAVA，团队应急人员的技能栈主要是 Python/JavaScript

3. 我们的分析逻辑、应急逻辑针对不同场景可以复用，计算平台不支持

SOAR 正好和我们的几个需求完美契合。

我们先看一下 SOAR 的基础概念。SOAR 最早由 Gartner 公司在 2015 年提出，是一类从各种来源获取输入并应用工作流来拉通各种安全过程与规程，从而为安全运营人员提供机器协助的解决方案。这些过程和规程可以被编排（通过与其它技术的集成）并自动执行以达成预期结果，譬如分诊管理、事件响应、威胁情报、合规性管理和威胁猎捕。

SOAR 具备以下特征：

1. 支持多途径的源数据输入、支持自定义插件开发，基础平台功能上扩展性强。

2. 支持响应流程编排（剧本），可将安全运营相关团队工具和能力，以场景来进行组织编排，形成可复用的剧本

2.2 SOAR 架构设计

经过调研分析，目前的 SOAR 产品基本都包含三个核心模块：Dashboards、Cases、Playbooks，我们的 SOAR 也是基于这三大模块构建而成

Dashboards 除了兼顾以前 SOC 的 Dashboard 功能之外，还增加了特有的对 Playbooks 的展示，这个模块我们在实现上复用了自有的 SOC 系统。

Cases/Alerts 则类似工单，目前我们已经有现成的工单系统，所以会按照 SOAR cases 的特征对工单系统进行改造，不再重新建设这个模块。

Playbooks 是 SOAR 系统的最核心功能，包含 Playbooks 的编写、应用管理、插件的管理，但其核心是基于事件驱动的工作流系统，也是我们这次 SOAR 系统建设的重点方向，以下重点介绍：

2.2.1 框架选型

公司有百万级的集群和设备，每天处理的数据量非常大，引擎需要具备海量数据的处理能力，另外业务希望平台尽快落地且跟业界对标，基于此我们决定在开源事件驱动项目 FLOGO 上进行二次开发，快速满足业务需求的同时，定制我们自己的 SOAR 系统。

FLOGO 的优势：

1. 功能齐全，模块化架构，前端可视化编排、后端调度引擎、原生插件等一应俱全，方便快速二次开发；

2. 后端使用 Golang 编写，借助 Go 语言的高性能和并发优势，提高安全事件响应速率，在海量数据输入场景下提升尤为明显；

2.2.2 平台架构

主要有以下几个特点：

1. 云原生架构

通过对系统整体的无状态化和配置远程化改造实现前端控制台 Web 和后端 应用在腾讯云 TKE 集群上的部署和自动扩缩容，目前在日均百万级的数据处理场景下运行稳定；

2. 权限管控

增加控制台的员工认证和权限管控机制，提升系统的安全性；

3. 可视化编辑

用户通过在剧本画布上对插件进行编排即可实现个性化的运营需求

4. 自定义插件

平台默认会提供一些通用安全组件，也支持业务自定义开发

（1）ChatOps

我们将企业微信客服号和群聊机器人的 API 封装成单独插件，安全运营人员通过简单、个性化配置即可实现拉群、推送消息、回调处理等等功能，再通过后续插件动作，实现 ChatOps。

（2）基础数据关联

SOAR 在接收到源数据后，经常需要对数据的上下文进行补充，为此我们将 SOC 数据接口封装为插件和函数两种形式，让运营人员可以在其他插件配置中通过函数快速整合上下文信息，实现灵活度更高、复杂度更低的剧本编排。

（3）工单联动

我们对工单系统的所有原子化功能进行整合和封装，如：创建工单（同时按需推送企业微信、电话、短信等等各种消息）、处理工单（支持灵活配置、ChatOps 和回调处理）、结束工单（事件分级、打标、消息推送）等等，在此基础上作为不同插件提供出来，让工单的生命周期在安全运营工作流中得到完整的体现。

除了以上这些通用插件，还有其他一些安全运营所需的插件，支持 Python/JavaScript，程序引擎中约定了插件的接口格式，开发插件时实现对应接口即可。

插件接口：

插件示例：

精细化运营

在旧式的运营中我们最痛的两个点：

1. 告警风暴处理

重复告警或者业务特性引起的大量告警，反馈优化周期长

2. 响应优先级

安全系统的告警大多数仅针对告警场景做的危害程度分级。在运营需要有自己的响应优先级分级指标和能力。

我们把策略告警数据接入 SOAR 平台，增加了两个插件来解决以上两个问题。

3.1 告警压制插件

针对告警压制的处置方案有：规则过滤、基于 IP/文件等属性做聚合归并、业务历史基线对比等方法，我们开发的这个插件核心是将这些功能改成配置化放到配置中心，通过把规则和流程分开管理，规则可以很快迭代的同时，也不影响现有系统的运行，一次优化流程 10 分钟就可以上线。

3.2 响应优先级分级插件

不同的告警划分响应优先级的方案有所不同，木马类告警我们使用了文件二次分析方案，进程网络类异常告警我们使用了上下文关联分析，我们将不同的分析方案都封装成插件供不同的事件类型过滤调用，从而根据二次分析的结果做进一步的分级和打标签。

1. 自动化响应 安全事件随时都可能发生，尤其是夜间的告警处理是个头疼的问题，7×24 小时值班机制对人力是个巨大的消耗，即便投入了人力 7×24 小时值班，如果凌晨 4 点电话业务起来排查告警、最终是个误报会产生 “狼来了” 的问题，都积累到白天处理响应延时又会很大。

我们通过 SOAR 系统对告警做响应优先级分级，对高响应级别事件接入自动化响应流程提高处理效率，还基于企业微信 API 接口开发了包括自动拉群知会业务、自动电话、自动查询基础信息、自动拉取日志/文件，其中部分业务团队开发了配置安全组、断网的功能接口，这里也有在做一些联动。

附 EDR 的 WebShell 告警的 SOAR 剧本示意图：

实测 SOAR 的效果不错，以某类安全事件为例，发出告警的响应时间从过去的平均 30 分钟降低到 2 分钟，效率大大提升，极大地方便了运营人员。

思考与展望

安全是在不断发展和变化的，安全运营仅仅是做被动响应很难跟上时代的变化，通过 SOAR 平台，安全运营提高了效率，也更好的发挥了自己的作用。除了洋葱 EDR 我们也在将在 Web 漏洞扫描器（“洞犀”）、WAF（“门神”）、NIDS/DDoS 防护（“宙斯盾”）等安全系统也将会接入 SOAR 平台，未来在系统联动、剧本建设上会持续迭代。

与业界先行者（如 Siemplify、Palo Alto XSOAR、Rapid7 InsghtConnect、雾帜 HoneyGuide、碳泽千乘）相比，我们数据面板、剧本等平台功能方面仍有一些差距，未来也会持续建设。

最后，感谢运营团队、研发团队对我们 SOAR 平台建设运营的帮助与支持。对腾讯的 SOAR 商业化产品感兴趣的同志可以看看腾讯云的 SOC 产品。

参考文章

1. 梳理：近三年 Gartner 对 SOAR 定义的不断变化 - 安全内参 决策者的网络安全知识库

2. Definition of Security Orchestration, Automation and Response (SOAR) - IT Glossary Gartner

3. GitHub - TIBCOSoftware/flogo: Project Flogo is an open source ecosystem of opinionated event-driven capabilities to simplify building efficient & modern serverless functions, microservices & edge apps.