01 SOAR 是真实刚需吗？
近年来，随着部、省、市三级监管部门大型攻防演练行动的深入推进，当前市场上很多中大型客户基本已经构建并完善各自网络空间的纵深防御体系，部署了主机安全防护产品、网络流量高级威胁检测设备、态势感知分析平台、蜜罐系统等各种相关配套的网络安全产品。在这样的一个背景下，SOAR 类产品对于客户来说还会是真正的刚需吗？
我们以入侵事件响应处置为例，如下图所示，在实战中，网络安全入侵事件处置方面主要存在以下问题：
1.1 处置流程相互脱节
对安全事件的管理和响应设计最终用户、IT 团队、NOC 团队和其他的利益相关方，目前在大部分客户内部实际工作缺乏统一规范的协同机制和平台。
情境不断变化
跨安全工具的协调包括转换情境、引导返工和零散的数据记录。
KPI 指标不足
安全团队缺乏时间、灵活性和集中的数据来可视化相关指标并跟踪效能。
1.2 响应技术分散孤立
威胁阻断类产品能力分散孤立
企事业单位内、外部安全防控点分布较多，部署的安全产品的厂商品牌来源相对较多，难以集中管理，设备之间难以聚合关联，无法联合发现和联合抵制隐藏的恶意行为和攻击事件。
无法有效覆盖微服务新架构
随着微服务等新型架构快速兴起，尤其在主机侧和容器侧的威胁行为缺乏有效的管控点：一是无法有效管控东西向流量；二是缺少进程级的联动和隔离阻断机制，无法处理主机内、容器内的恶意进程、恶意文件和高危账户等实体。
因此，目前亟需利用安全管理中心联动相关安全产品，让安全控制点形成一道道控制面，形成自动化的统一安全运维管理体系。
1.3 安全运维负重前行
日益增长的告警：>1 万次告警（每周）
威胁形势的发展和变化太快，公司生产业务的增长产生了更大的网络流量，安全告警数量实在太多了，事件响应需要手动干预过程又太多。
我们的 MTTR（平均恢复时间）过于漫长。每增加一天都会转化为金钱的损失和公司品牌的风险 -- 首席信息安全官
缺乏有经验的分析人员：2 百万安全专业人才的缺口
未能掌握足够的技能来跟上安全分析和运维的需要，安全运维人员数量以及技能均不够。
我们经验丰富的宝贵安全人员被爆炸式的安全告警彻底淹没了，无法找到最关键且真正需要处理的安全事件。 -- 安全运营经理
应急响应：没有统一的流程，且缺乏量化指标
已部署的安全产品和工具太多，且响应流程不完善，很难真正地了解整个内部和外部的安全处置态势，安全运维变得越来越困难。
处理问题只能通过电话或者邮件沟通，处理应急需要在各个厂商不同的安全产品上消耗非常多的时间 -- 安全运维人员
1.4 小结
综上所述，“SOAR” 为代表的自动化联动处置技术平台是真正的刚需。
我们需要按照 “纵深防御” 思路，构建一套具备处置自动化和应急响应线上化的工作机制、决策模型和技术平台，一是将孤立的安全检测与处置响应实现无缝衔接；二是将碎片化分散在网络层、系统层、应用层的各类联动处置技术手段整合增强，形成纵深立体、规范统一的威胁阻断和排查验证两大类联动处置技术服务；三是通过跨区域、跨网络的联动协同机制，按照 “顶层设计、统筹协同” 的思路，实现内、外部各级网络安全防护响应能力、威胁情报和专家队伍在线联动和情报数据共享，提升整体防护响应能力和安全事件快速处置效率。
02 SOAR 选型需重点考虑哪些方面？
目前来看，国内外市场已经出现了较多的 SOAR 类产品，技术路线和特点大体相同，那么从甲方角度来看，在进行 SOAR 产品的选型时我们需要重点关注哪些方面呢？
从安全运维实战角度出发，通过研究 Gartner 相关报告和国内外市场上主流 SOAR 类产品功能进行归纳总结，笔者认为选择一款 SOAR 类产品需要特别重点关注以下两个方面的核心需求：
2.1 是否具备标准统一的联动接口
2.1.1 标准统一的 API 接口屏蔽同品类不同安全厂商产品之间的差异
在安全事件快速处置方面，基于 “标准统一的纵深立体联动响应体系” 构建联动处置技术支撑模块，将分散的检测与响应机制整合集成，提供统一的威胁阻断和排查验证两大类联动处置技术服务，做到不仅是网络层并且需要深入到服务器主机内、容器内，实现进程实体级别的防御，这是提升整个安全响应效率的基础设施。客户现有自动化编排系统或 SOC/SIEM/态势平台能够通过该模块联动全网相关安全产品，如防火墙、入侵检测、APT、终端安全管理软件等，实现联动分析和威胁阻断，对于主机/容器层面可以实现进程/文件/账号实体级别的联动阻断。
特别要强调的一个关键点是：非常有必要从威胁阻断类和排查验证类两个角度出发对网络侧、主机侧、容器侧的安全响应需求抽象出规范统一的联动响应接口 API，只有按照这样的建设思路才能妥善地解决在满足大部分实战场景的情况下友好的屏蔽各个厂商不同型号产品之间的差异，这样才能较好地保障相同 Usecase 和相关处置流程可以在各个不同客户 IT 环境共享复用，客户安全运维人员面对种类繁多的威胁事件时可以复用行业专家 Usecase，避免花费大量时间和资源去深入研究不同安全厂商产品的各种联动 API 细节，然后再针对各种 Usecase 进行二次优化适配，如果 API 细节适配不到位，那么自动化联动处置的实战效果就发挥不出来。
从笔者所带领的研发团队与深信服、绿盟等友商安全产品联动 API 对接的情况来看，每对接一个新的安全产品平均需要花费 60 人天左右。这个工作量是在第三方安全厂商友好配合的情况下所耗费的，即从友商及时提供产品的最新版 API 文档开始，我方团队技术人员结合官方产品用户手册、API 文档和友商实际产品来研究对接产品的技术细节，初步映射到安全狗自研的 “纵深联动响应体系 API” 模型，这中间频繁需要友商技术人员配合确认和答疑各种 API 参数含义、字段字典、多个 API 协同调用次序、返回结果含义等诸多技术细节。这个过程结束后，研发人员开始设计、编码适配该产品的联动响应驱动程序，再往后就是跟友商提供的测试环境（也遇到无法提供测试环境，直接到甲方生产环境）进行联调测试，如果测试中出现技术细节遗漏或双方沟通理解不到位的情况，而且友商安排技术人员积极协助确认，则能相对较快地排查到问题原因，研发人员及时重新返工修改设计和编码，测试重新验证测试，这样处理一个问题的返工过程往往就要耗费 7～10 天左右的时间。
所以，笔者此处想要重点强调的观点是了解不同厂商安全产品联动 API 技术细节是一个耗时费力的 “重体力活。”
2.1.2 构建纵深立体的联动响应体系全面覆盖威胁阻断和排查验证场景
那么 “标准统一的联动响应 API 接口” 体系模型如何构建呢？
通过研究国内、外主流安全厂商的大量安全产品后，笔者发现可以从威胁阻断类和排查验证类两大方面进行抽象与总结，由此可构建相应的 “纵深立体联动响应 API 体系” 模型。
2.2 平台是否同时具备自动化和半自动化处置能力？
在实战中，产品在功能上，既要支持针对单个攻击、或单个漏洞、单台失陷主机等少数特例场景提供 “一键式” 人工交互式的联动处置功能，同时也要支持针对一种钓鱼邮件、一种挖矿木马、所有网络扫描探测等这样对某一类问题进行自动化批量联动处置的功能。
因此，在安全编排和响应自动化平台功能设计上，需要包括 “一键式” 联动处置功能和 “自动化” 编排处置功能，具体如下：
“一键式” 联动处置功能
针对漏洞、外部攻击、内网渗透、外联威胁、恶意文件、定向攻击、告警事件、失陷主机场景，对接网络侧和主机侧联动处置 API 接口，实现安全事件核查处置 “一键式” 联动处置操作。
同时提供主机侧联动处置、网络侧联动处置和预留级联处置管理三个功能，实现与主机侧和网络侧联动处置接口 API 无缝对接，提供统一的联动策略新建、下发、查询、修改、删除等生命周期管理和审计功能。
“自动化” 编排处置功能
如下图所示，自动化编排处置功能以 “统一纵深联动响应体系为基础”，主要提供各种数据源对接插件和 SOAR 的编排、自动化和响应功能。
SOAR 功能需求如下图所示：
03 研发 SOAR 产品面临的困难挑战
从技术层面评估来看，SOAR 平台本质上是按照 “SOAR” 产品理念构建的一个类似 “安全处置中间件” 技术平台，对现有成熟安全技术和客户已有的安全产品进行整合集成，其中涉及到的工作流引擎技术、可视化编排技术和配套的 Usecase 知识库等方面均不存在新技术预研的风险。
那么从乙方安全厂商的角度来看，研发出一款贴合实战的 SOAR 产品真正面临的困难挑战会是什么呢？笔者认为主要有以下两个方面：
3.1 标准统一的联动接口体系构建难
现实中，客户按照 “纵深防御” 的思路在其 IT 环境中的不同部位部署了众多不同厂商的各类安全产品，即使同品类不同厂商的安全产品针对同一类威胁的响应处置 API 接口在格式内容、调用方式、调用次数等众多细节方面都有很大的差异，如果 SOAR 平台的响应组件直接对接在各个厂商的具体产品的 API 上，那么使用该平台的用户就必须花费大量的时间去了解这些技术细节，构建的 Usecase 也与具体厂商的某个型号的安全产品紧密耦合在一起，这也意味着行业专家、从业人员针对各类威胁处置场景构建的众多 Usecase 模型库在每个部署客户 IT 环境中都需要根据不同厂商的安全产品进行二次调整优化。
从甲方客户的角度来看，这对于已经负重前行的安全运维团队来说，无异于雪上加霜，SOAR 产品内置的 Usecase 如同鸡肋，引入 SOAR 的同时也带来了更多学习时间的花费、改造成本投入等问题的发生，其后果往往就是 SOAR 产品很难用起来，最终演变成有限地使用了几个 usecase，或者极端的情况就是 “无卵用”。
从乙方厂商的角度来看，如果不能构建一套 “标准统一的联动接口 API 体系” 模型来屏蔽各个友商安全产品的技术细节，则其内置的各种 Usecase 的适用性就会存在很大的局限性，随着在甲方客户部署的数量越多，其有限的 Usecase 专家就得花费越来越多的精力协助甲方安全运维人员进行二次调优以及投入更多技术支撑，其专家资源很快就会消耗殆尽。
因此，作为 SOAR 产品研发厂商的乙方必须迎难而上，以 “标准统一的联动响应 API 接口模型” 为基础集成对接友商各种安全产品 API 接口，保障来自安全厂商、行业专家和甲方内部安全运维团队成员的各种 “Usecase” 专家知识库可共享复用，在此基础上，才能真正地给甲方用户带来 “减负增效” 的简便性，并形成 “联防联控” 的协同效果。
3.2 生态体系丰富程度难以形成规模
SOAR 平台在客户安全体系中起到类似 “桥梁” 的作用，需要各种安全产品对接协同，其协同对接生态体系如下图所示：
面对国内外网络安全产品市场如此众多的友商和安全产品，SOAR 要针对这些 “跨厂商、跨产品” 的协同对接工作就显得极其艰巨繁杂。因此，SOAR 产品厂商必须探索一条技术体系开放、标准规范统一、商业模式创新的道路，才有可能吸引各个生态厂商主动参与并积极拥抱协同对接，才能形成较为丰富的生态体系，然而这项工作的推动极其艰巨！
04 总结
面对各种各样的网络攻击，在防御上实现攻击入侵自动化联动响应是企业安全自始至终的核心诉求。实际上，各种防护类、分析类等安全产品，最终目标还是为了对网络攻击入侵做出合理的响应。
新型的 SOAR 技术能否解决安全运营中最后一公里的问题，以及落地建设需要重点考量哪些方面，有哪些实践经验可供参考借鉴等问题？笔者作为一个 SOAR 产品团队负责人，通过调查研究 Gartner 研究报告和国内外众多的 SOAR 产品功能、以及国家电网实际项目落地经验等等方面归纳和思考，站在甲方、乙方和产品生态的等角度给出了自己的见解供大家参考。