一、 为什么我们要去建设 SOAR 能力

在谈到建设 SOAR 能力的时候，在和周围人聊天的时候都对 SOAR 有着不同的看法，有的人觉得 SOAR 这个东西就是一个独立的产品，有些人认为 SOAR 这东西需要和 SIEM 进行深度绑定，有些人觉得 SOAR 这个玩意儿可以接入所有的东西。但是从实际落地 SOAR 而言，我们需要去谈论一下做 SOAR 的收益，在我看来做 SOAR 的意义在于以下几点。

（1）信息安全运营已经处于规模化阶段

当你在谈论 SOAR 的时候，其实绝大多数人实际上对于 SOAR 能力一直会有一个误区，就是觉得别人要有的东西我也要有，不能在产品线上落后别人一步（这种想法在部分安全领域其实是正确的，但是遇到一些需要堆人效的工作可能就会变得不那么适用），所以我们就需要去建立 SOAR。但实际情况是，对于绝大多数企业而言，SOAR 能力建设实际上完全是一个赔本的买卖，简单说主要有以下几个问题：

• 企业内部真的需要有那么多的安全事件能够发展到需要进行止损么，规则优化到位了么？

• 企业内部相关联的系统具备自动化/半自动化的响应能力么？（点个按钮拉群的那种不算）

• 建设 SOAR 的成本大概回本的周期是业务可以接受的吗？

• 如果没有 SOAR 的话，纯人工运营对于现在的信息安全和风险真的比 SOAR 更低吗？

其实以上问题如果能回答的很明白的话，绝大多数人对于需要建设 SOAR 相关的能力的公司会有一个大概的画像：

• 安全团队有一定规模，且基础的安全产品已经铺设的差不多了（资产安全相关产品、终端安全相关产品、流量安全相关产品、研发流水线安全相关产品等），并且数据质量和规则模型质量已经优化的基本到位了（漏报率和误报率达到了可人工运营的水平）；
• 企业内部 IT/运维相关平台和能力已经完成了绝大多数标准化的建设（不管是开源产品还是商业产品，数据结构和 API 的统一化和标准化建设基本完成）；
• 安全需求多而繁杂，并且对应的安全运营相关指标已经出现了停摆或者说是达到了一定瓶颈（绝大多数是人效的问题或者说是 TCO 上不去）；
• 信息安全相关的预算比较充足且一段时间没有预算明显降低的风险。

所以如果要是不满足上述的条件的话，可能拉群会比建设一整套 SOAR 能力来的更有性价比一些。

（2）信息安全运营工作的标准化和流程化建设

如果满足了上述条件，但是从指标来看，在各种响应层面的指标仍旧处于不健康或者是落后于同行的情况下，这个事后其实不用我说，大家也都知道一定是运营质量上出现了很多问题。笔者在建设 SOAR 能力的时候也在经常考虑一个问题，如何将 SOAR 相关的产出和部门内 BU Goal 甚至是 BG Goal 结合起来说明建设 SOAR 的价值，但是从一段时间的实践来看，似乎这不是一件容易的事情。

如果说前面的基本功做好了，差不多在 1-2 年之内就会遇到上述情况，比如说漏报率、误报率不稳定的问题、事件响应时间长的问题，人员变更导致运营能力不能稳定输出等。

如果你遇到了这种问题，绝大多数情况下肯定是运营质量出现了一些情况，最直观的感受就是很多 core metrics 会变得不稳定且不可预测，这个时候安全运营工作的标准化建设和流程化建设实际上是下一阶段安全运营工作建设的重点。

但是这个和 SOAR 有什么关系呢，从对 SOAR 这种类型的概念来看，本质上 Playbook 就是标准化和流程化结果的最好体现。简单来说 SOAR 的 core metrics 除了要关心产品的稳定性等性能指标之外，还需要去关心 Playbook 的覆盖程度、运营成功率、运营自动化率等问题，除了 SOAR 本身的能力不断要建设之外，IT/基础设施也是需要通过 SOAR Playbook 的覆盖程度去 push 对应能力的建设。除此之外，专家经验也是可以通过 Playbook 进行沉淀。这样建设一轮下来，误报率漏报率等核心安全运营指标在一段时间之后从原来的不稳定且不可预测会改观许多。

（3）信息安全工作人效比太低，TCO 指标难看

这部分其实从 2018 年之后对于很多公司的信息安全团队都有一个比较明显的感受，企业内部对于信息安全的预算一降再降，这部分原因除了宏观背景之外，很大一部分原因是因为这个时候企业对于安全建设的 ROI 会发现不成正比。尽管任何企业被入侵这个事儿从概率的角度上讲几乎是一个必然事件，但是信息安全工作从来不在于完全抵御所有的网络攻击，而是尽可能提高攻击成本，甚至更进一步，在有限的资源内尽可能高的提升攻击成本。所以基础建设相关的团队都会把 TCO 指标当做自己核心指标的一部分。Google 在 2021 年披露他们的 Autonomic Security Operations 相关的 blog 的时候，实际上已经这么干了。

而对于 SOAR 而言，提升 TCO 这一部分其实是顺手的事儿，SOAR 建设的终极目标其实就是将企业内部的风险全都自动化处理掉（当然绝大多数的时候这是不可能的），所以对于 TCO 提升而言，SOAR 的建设程度越高，TCO 也就越高（其实 TCO 指标和 SOAR 成熟度可以互为反向指标）。

（4）信息安全建设工作需要进一步内生化和集成化

外挂式安全不可持续这件事儿其实一直是最近一段时间业内的共识（也有上限低的情况），原生安全能力的建设其实一直是未来信息安全建设的重点。SOAR 能力其实本质上来讲也是一种外挂式能力，但是 SOAR 的外挂能力和扫描器等外挂式安全能力不同的地方在于 SOAR 更像是原生安全和外挂安全的耦合剂，也就是在处理风险的时候，SOAR 可以更高效的调用原生的安全能力来解决实际的安全问题。

二、在企业内部如何去建立 SOAR 能力

SOAR 的核心能力实际上对下是要把安全风险和安全能力进行耦合，对上要对各种安全领域出现的安全风险提供底层能力的 Playbook 级别的调用，达到自动化响应风险的目的。

（1）SOAR 能力在整个 SOC 能力中的定位

首先对于 SOC 而言，SOAR 的能力更像是是一个底座级别的能力，而非是和 SIEM 进行捆绑操作，本质上来讲 SOAR 在整个 SOC 架构里面应该是下面这种情况。

一张不完整的 SOC 架构图

SOAR 的核心能力实际上对下是要把安全风险和安全能力进行耦合，对上要对各种安全领域出现的安全风险提供底层能力的 Playbook 级别的调用，达到自动化响应风险的目的。

（2）建立 SOAR 的 metrics 和对应的 measure plan

讲道理的话，但凡有点工作常识都知道应该从服务可用性和运营指标两个维度分别构建正反向指标用来描述 SOAR 能力在安全运营工作里面的价值。但是实际上 SOAR 的价值核心在于提效，然而效率指标这个事儿实际上是一件比较扯皮的事儿，因为很多时候风险运营的指标（比如说响应时间）很有可能仅仅是因为当天的值班人员在告警列表中多看了一眼，然后就发现这个运营指标嗖的一下就上去了，但是到开会的时候如果要是向上如实汇报的话，在管理层眼中这个原因是不可接受的，原因其实上面已经提到了——这个指标不具备稳定性和持续性。

简单来说在构建整个 SOAR 的评价体系的时候，需要在能力原有的指标稳定可控的前提下排除其他原因对于指标的干扰。简单来说其实可以浓缩成一张表（举个例子）：

从构建体系来讲，一般是要遵循三个 M，即指标化（Metrics）、体系化（Matrix）和可观测（Measure），尽量去贴近用户体感和实际运营指标。

（3）SOAR 应用技术性问题的发现和解决

在建设 SOAR 的过程中，实际上来讲其实技术上的坑还是有很多的，从最近一段时间来看，其实 SOAR 的调用量比我们当初设计的时候要大很多，并且我们设计的指标体系有的时候并不一定符合用户的体感。 我举几个例子：

a. Playbook 的高踩踏率优化

在 SOAR 刚上线的时候，因为我们对于用户的排查场景其实了解的并不透彻，所以在功能上线的之前的测试当中，我们做的测试用例其实并不能完整覆盖用户实际的入参情况（这个在测试行业也是个大问题，这就是为什么模糊测试会兴起）。所以在上线初期，Playbook 编排成功率可能只有个位数（当时还没有做这一部分的数据埋点）。虽然在上线之初考虑到了这种情况，但是没想到这个指标居然会这么难看。当时我们就发明了一个新词——Playbook 踩踏（这个是当初开玩笑的时候起的，但是大家都还觉得很贴切），所谓 Playbook 踩踏是指有些 Playbook 的插件还没有执行完或者是执行出错了，但是调度没有停下来会执行其他的，结果出现了一连串的执行错误，有点类似于熙熙攘攘的人群中有一个人摔倒了，后面的人一个接一个的摔倒，发生了踩踏事件，所以起名叫踩踏。后面仔细复盘了下这个问题，首先我们发现在编排的过程中当时没有考虑空参和执行超时等问题，调度引擎又没有超时重试和扩展运行的能力，所以出现了 Playbook 执行失败率奇高的问题。后续我们针对这一部分设计了对应的校验机制和重试机制，才算是解决了问题，将踩踏率控制在了合理的范围内。

b. Playbook 编排成功率和插件执行成功率的平衡

除了上面的踩踏率的问题，我们在后来对于指标的构建当中又发现了另外的一个情况，在对插件执行的埋点中，我们发现插件执行的成功率是达标的，但是编排执行的成功率却很难看。我们通过分析之后发现，在一些取证场景和自动化处置场景里面，很多时候 Playbook 在超时一次之后就卡住不会执行了，同时埋点的时候发现 Playbook 的成功率部分的卖点不科学，比如说超时这一部分没有纳入执行失败，而是单独的状态。但是从用户体感来看，用户觉得成功率还是低了，这个问题可能是链路抖动导致丢包了，或者是第三方系统出现了各种问题，再或者是在 SIEM 查询过程中耗时较长导致的。后面我们尝试引导用户使用【重排】按钮重新执行一下 Playbook，用户表示不能接受这种操作，所以这一部分后面我们在功能优化的过程中尝试不再以插件执行为优化重点，而是以 Playbook 执行成功率作为优化点做整体的建设。

c. Playbook 的配置成本

坦率的讲，这个问题目前其实没有一个比较好的解决方案，不管是使用云函数，还是使用卡片式拖拽，都不能很好的去解决 Playbook 配置成本的问题。这个问题比较核心的矛盾点实际上是在于配置 Playbook 的同学是否有真正的专家经验和内部系统是否足够标准化，因为我看到很多商业的 SOAR 产品都有一个插件商店或者是叫做 marketplace 的功能，这一部分实际上就是基于社区或者是厂商的安全运营能力做的一个类似于 App Store 的开箱即用的功能，但是从实际落地的角度来看，marketplace 这种机制在外企反而可以落地，但是在国内成功落地的几率实际上是非常的低的，主要有两个原因，第一个原因是因为国内安全建设实际上几乎是没有标准的，都是以业务为导向去建设对应的安全能力（不管是打补丁式的纯外挂安全，还是业务集成度很高的原生安全），第二个是因为 marketplace 里面的 Playbook 真的不一定就能够完成跑下来，这一点可以通过执行成功率去看一下。

短期之内，Playbook 配置的成本一定不会很低，但是长期来看，由于类似于 ChatGPT 之类的 Copilot 产品的引入，说不定会能降低一些。

d. Playbook 的应用场景

就目前而言，SOAR 的很多能力甚至包括带有 marketplace 的 SOAR 产品核心关注点还是在 DFIR 领域，也就是能力全都放在告警的运营和处置上面。但是从企业安全建设的角度来看，安全相关的工作必须要围绕业务来进行，也就是说业务的安全需求很可能并不是仅仅局限在 DFIR 领域，比如说合规领域、内容安全领域、数据安全领域等，这些领域的安全运营动作也是可以依托于 Playbook 提升运营效率的，所以在 SOAR 的建设层面，需要立足于业务本身的安全需求，建设一些通用的能力而避免过于 focus 某一个人或者某几个人身上，要正确筛选出大众需求和小众需求。

三、总结

若你的基础设施标准化程度高，而且需要关注的信息安全比较多而且比较杂，并且安全相关的运营指标长期没有一个质变，这个时候可以考虑建设一些 SOAR 能力（标准化做得好的甚至可以使用商业产品），用来提升人效和运营效率，让运营相关指标有一个质变。

但是如果你的基础设施定制化程度很高，而且企业内部有充足的研发资源用来支持运营平台的研发，同时有足够基数的安全专家来提供专家经验，这一部分的话可以考虑自行建设 SOAR 能力来降低整个安全运营工作的 TCO，也会收到不错的效果。