提示
本文仅为这次体验的个人意见，不针对被体验的产品或这个技术，可能有偏颇。
SOAR的概念已经很早出现了，最新的一版Garter对其的描述中写：
SOAR 是一类从各种来源获取输入，并应用工作流来拉通各种安全过程与规程，从而为安全运营人员提供机器协助的解决方案。这些过程和规程可以被编排（通过与其它技术的集成）并自动执行以达成预期结果，譬如分诊管理，事件响应，威胁情报，合规性管理和威胁猎捕。
英文原文：SOAR are solutions that add machine assistance to human security operators by taking inputs from various sources and applying workflows aligned to processes and procedures. Those procedures can then be orchestrated (via integrations with other technologies) and automated to achieve a desired outcome, such as triage management, incident responders, threat intelligence, compliance managers, and threat hunting.
其余的有关于SOAR的原理或解释就不多描述了，有需要的可以参考如下文章：
SOAR部署
开源产品选择：
测试场景
选择一个完整的安全的场景相对较重，需要去对接扫描器或防火墙或其他设备，这里仅为了测试功能，场景选择了之前提到的地铁延误推送场景：
最终的剧本逻辑如下图所示，其中天气查询、核酸结果查询和BARK推送三个APP是自己开发并上传，非原产品中自带：
测试结果
剧本运行正常并推送结果完成，3个APP开发时间大概30分钟吧，调试时间大概小半天（要熟悉产品中传参的逻辑，熟悉了可能会缩短时间）。
总结
这次就测试了下一个简单的场景，整体的使用逻辑基本了解清楚，业界也有一些知名的国内外SOAR产品，在剧本的逻辑复杂程度，APP的丰富程度和AI作战室等其他功能上有更多的设计。
但就个人而言，有以下几个观点，最终确实没能实际感受到SOAR的优势（再次强调非针对平台）：
- 除非SOAR平台的app已经丰富到开箱即用，否则与实际工作中需要的平台对接仍然要重新开发，时间并不节省
- 既然都是需要重新开发，直接写http接口对接我理解会更快，对于运营人员，在soar上是拖app，可以改成调用包装好的函数接口
- app的入参和出参相对固定，如果需求灵活，要么app的出参相对复杂导致剧本复杂度增加，要么做几个重复app浪费工时
- 弄个api网关，把所有的app或工作内容包装成函数，开发人员直接上手写代码逻辑不是更灵活么？
以这次体验为例，部署+开发app+调试的时间我感觉我能写5个同等体量的剧本源代码…也许未来的某一天，SOAR平台能和低代码开发平台整合，或许我认为是有极大的减轻工作量的可能的。
发表回复