在谈到建设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的核心能力实际上对下是要把安全风险和安全能力进行耦合，对上要对各种安全领域出现的安全风险提供底层能力的Playbook级别的调用，达到自动化响应风险的目的。 （1）SOAR能力在整个SOC能力中的定位 首先对于SOC而言，SOAR的能力更像是是一个底座级别的能力，而非是和SIEM进行捆绑操作，本质上来讲SOAR在整个SOC架构里面应该是下面这种情况。
SOAR的核心能力实际上对下是要把安全风险和安全能力进行耦合，对上要对各种安全领域出现的安全风险提供底层能力的Playbook级别的调用，达到自动化响应风险的目的 。 （2）建立SOAR的metrics和对应的measure plan
讲道理的话，但凡有点工作常识都知道应该从服务可用性和运营指标两个维度分别构建正反向指标用来描述SOAR能力在安全运营工作里面的价值。但是实际上SOAR的价值核心在于提效，然而效率指标这个事儿实际上是一件比较扯皮的事儿，因为很多时候风险运营的指标（比如说响应时间）很有可能仅仅是因为当天的值班人员在告警列表中多看了一眼，然后就发现这个运营指标嗖的一下就上去了，但是到开会的时候如果要是向上如实汇报的话，在管理层眼中这个原因是不可接受的，原因其实上面已经提到了——这个指标不具备稳定性和持续性。 简单来说在构建整个SOAR的评价体系的时候，需要在能力原有的指标稳定可控的前提下排除其他原因对于指标的干扰。简单来说其实可以浓缩成一张表（举个例子）： 从构建体系来讲，一般是要遵循三个M，即指标化（Metrics）、体系化（Matrix）和可观测（Measure） ，尽量去贴近用户体感和实际运营指标 。
（3）SOAR应用技术性问题的发现和解决 在建设SOAR的过程中，实际上来讲其实技术上的坑还是有很多的，从最近一段时间来看，其实SOAR的调用量比我们当初设计的时候要大很多，并且我们设计的指标体系有的时候并不一定符合用户的体感。 在SOAR刚上线的时候，因为我们对于用户的排查场景其实了解的并不透彻，所以在功能上线的之前的测试当中，我们做的测试用例其实并不能完整覆盖用户实际的入参情况（这个在测试行业也是个大问题，这就是为什么模糊测试会兴起）。所以在上线初期，Playbook编排成功率可能只有个位数（当时还没有做这一部分的数据埋点）。虽然在上线之初考虑到了这种情况，但是没想到这个指标居然会这么难看。当时我们就发明了一个新词——Playbook踩踏（这个是当初开玩笑的时候起的，但是大家都还觉得很贴切），所谓Playbook踩踏是指有些Playbook的插件还没有执行完或者是执行出错了，但是调度没有停下来会执行其他的，结果出现了一连串的执行错误，有点类似于熙熙攘攘的人群中有一个人摔倒了，后面的人一个接一个的摔倒，发生了踩踏事件，所以起名叫踩踏。后面仔细复盘了下这个问题，首先我们发现在编排的过程中当时没有考虑空参和执行超时等问题，调度引擎又没有超时重试和扩展运行的能力，所以出现了Playbook执行失败率奇高的问题。后续我们针对这一部分设计了对应的校验机制和重试机制，才算是解决了问题，将踩踏率控制在了合理的范围内。 b. Playbook编排成功率和插件执行成功率的平衡 除了上面的踩踏率的问题，我们在后来对于指标的构建当中又发现了另外的一个情况，在对插件执行的埋点中，我们发现插件执行的成功率是达标的，但是编排执行的成功率却很难看。我们通过分析之后发现，在一些取证场景和自动化处置场景里面，很多时候Playbook在超时一次之后就卡住不会执行了，同时埋点的时候发现Playbook的成功率部分的卖点不科学，比如说超时这一部分没有纳入执行失败，而是单独的状态。但是从用户体感来看，用户觉得成功率还是低了，这个问题可能是链路抖动导致丢包了，或者是第三方系统出现了各种问题，再或者是在SIEM查询过程中耗时较长导致的。后面我们尝试引导用户使用【重排】按钮重新执行一下Playbook，用户表示不能接受这种操作，所以这一部分后面我们在功能优化的过程中尝试不再以插件执行为优化重点，而是以Playbook执行成功率作为优化点做整体的建设。 坦率的讲，这个问题目前其实没有一个比较好的解决方案，不管是使用云函数，还是使用卡片式拖拽，都不能很好的去解决Playbook配置成本的问题。这个问题比较核心的矛盾点实际上是在于配置Playbook的同学是否有真正的专家经验和内部系统是否足够标准化，因为我看到很多商业的SOAR产品都有一个插件商店或者是叫做marketplace的功能，这一部分实际上就是基于社区或者是厂商的安全运营能力做的一个类似于App Store的开箱即用的功能，但是从实际落地的角度来看，marketplace这种机制在外企反而可以落地，但是在国内成功落地的几率实际上是非常的低的，主要有两个原因，第一个原因是因为国内安全建设实际上几乎是没有标准的，都是以业务为导向去建设对应的安全能力（不管是打补丁式的纯外挂安全，还是业务集成度很高的原生安全），第二个是因为marketplace里面的Playbook真的不一定就能够完成跑下来，这一点可以通过执行成功率去看一下。 短期之内，Playbook配置的成本一定不会很低，但是长期来看，由于类似于ChatGPT之类的Copilot产品的引入，说不定会能降低一些。 就目前而言，SOAR的很多能力甚至包括带有marketplace的SOAR产品核心关注点还是在DFIR领域，也就是能力全都放在告警的运营和处置上面。但是从企业安全建设的角度来看，安全相关的工作必须要围绕业务来进行，也就是说业务的安全需求很可能并不是仅仅局限在DFIR领域，比如说合规领域、内容安全领域、数据安全领域等，这些领域的安全运营动作也是可以依托于Playbook提升运营效率的，所以在SOAR的建设层面，需要立足于业务本身的安全需求，建设一些通用的能力而避免过于focus某一个人或者某几个人身上，要正确筛选出大众需求和小众需求 。 若你的基础设施标准化程度高，而且需要关注的信息安全比较多而且比较杂，并且安全相关的运营指标长期没有一个质变，这个时候可以考虑建设一些SOAR能力（标准化做得好的甚至可以使用商业产品），用来提升人效和运营效率，让运营相关指标有一个质变。 但是如果你的基础设施定制化程度很高，而且企业内部有充足的研发资源用来支持运营平台的研发，同时有足够基数的安全专家来提供专家经验，这一部分的话可以考虑自行建设SOAR能力来降低整个安全运营工作的TCO，也会收到不错的效果。
原文始发于微信公众号（君哥的体历）：e1knot：实践之后，我们来谈谈如何建设SOAR
