闲谈：最近经常和同事来交流SOAR的问题，正巧最近也在做涉及SOAR的项目，结合和同事们交流的心得与自己工作的感悟,笔者写了这篇文章.

概述

SOAR(Security Orchestration,Automation and Response)，简单字面来讲就是安全编排、安全自动化、安全响应。人们往往忽略了威胁情报(Threat intelligence)。

实际上根据Gartner的定义，一个优秀的SOAR会将事件响应、剧本编排、自动化、威胁情报、记录、工作流程集成在一个平台上。

安全分析师通过平台根据自身的经验，进行场景分析，然后剧本设计，将流程固化，工作标准化；从而辅助安全工作开展分析，运营，处置，响应。

过多的概念性知识就不再赘述了，Google搜搜或者找两个产品的白皮书，文章大把。

SOAR的价值：

1、安全设备集中化

这里的意思并不是通过SOAR进行集中管理安全设备，而是通过SOAR平台将所需安全设备的功能集中起来，并且这样可以按实际日常工作流程中，按需调用你需要的功能。

2、节省工作时间

SOAR是通过代码实现自动化工作流程，会减少你工作中某些机械工作所耗掉的时间，这个不必多说。老生常谈的场景:封禁IP。

3、打通与其他部门协作

一般在某些大企业里，基础设施部，安全运营部，这个部，那个部，其实有些时候并没有想象中那么容易推进。工作越久越发现内部往往是最难推动的，恰恰有时和外部沟通很容易。

举个例子，比如我需要封许多IP,可能想象中其实就是防火墙的一条Deny安全策略，地址对象里录一些IP，其实不复杂，但是一次两次很容易，三次四次可能就不是那么好推动。只是打个比方，大家懂表达的意思即可。

4、提升工作效率

通过SOAR打通其他安全设备，可以辅助安全工作开展。

例如：IP信誉查询；批量处置安全事件；安全事件的告警通知；终端安全扫描；主机断网下线；工单下发等等。

将工作中某些流程进行融合，提升工作效率。

5、灵活编排设计。

根据场景中需要解决的问题，选择对接不同安全设备，自定义条件逻辑判断，编排剧本流程。

SOAR的总结

结合目前工作中体验，SOAR其实可以简要概括四个模块。

SOAR的模块分类：

• 输入

• 剧本

• 输出

• 应用

SOAR的应用场景分类：

• 自动化

• 半自动化

之所以会分为自动化与半自动化，是由于某些场景由于对业务风险的考虑或输入的限制，导致需要不能完全依赖于自动流程，需要人工分析处置或流程审批。

SOAR的主要应用场景

运维：

• 设备改密

• 终端断网

• 邮件通知

• 系统监控

• 安全设备运维

• ……

安全：

• IP信誉查询

• 封禁IP

• 终端病毒扫描

• 资产发现

• ……

SOAR的剧本设计流程

1. 熟悉企业的网络结构与策略，沟通讨论构想的剧本中是否会带来安全隐患或安全事故。

2. 了解或熟悉上游输入的基本信息和能力。

3. 了解或熟悉下游接受输出应用的基本信息和能力。

4. 根据编排的剧本，沟通各方需要提供的接口和工作，讨论剧本中某些环节的合理性。

5. 就剧本中的细节达成共识，打通上下游。

6. 申请网络策略，测试运行一段时间，观察实际效果。

7. 按需调整剧本的实际需求。

8. 上线。

SOAR的剧本举例

老生常谈，封IP。

可能你觉得这个没难度，简单。但是这个是最实用的。往往实用的才是最好的。

PS：这个剧本笔者在设计时候，默认已与网络部门达成共识，提前规定好Deny的安全策略置顶，并且协商好地址对象的名称格式。所以就没涉及封禁策略与其他安全策略间会不会有优先级冲突或策略交叉的情景。

其实对照这个剧本，你可以发现一个简单的IP封禁,其实涉及了：

• 你要对防火墙功能有一定的了解,例如地址对象，安全策略等。

• 还需要调研防火墙能提供的能力，也就是下游接受输出应用的能力。

• 例如：地址对象的上限数量,地址组的上限。（一般地址对象上限4096，但是也有不一般的，例如某XXX，地址对象的上限128个……）

• 也还需要调研上游输入的基本信息。

• 例如：是否需要手工输入IP封禁或者直接取某些精准告警的IP，那可能输入的最大值是多少，防火墙这个接口并发是否支持同时写入这么多的IP到地址对象中?

• 沟通各方所需要的接口和工作，沟通某些环节的合理性。

• 举一个例子：下午向研发同事请教他的经验。我才了解到，实际有时候接到的需求根本不会对地址对象的上限做校验，实际上就是无脑地将IP写入地址对象中。当时我觉得这样不是很合理，所以我问：“那地址对象如果上限了，怎么办？？？直接会判断新建地址对象写入？”他给我的回答是：”写不下就直接报错呗。其实往往实际上不是我不想做校验，是有的防火墙的接口压根不给我这个查询的权限，我也没有办法。

• 所以设计剧本时候，需要多想想这个剧本中某些环节的合理性。

• 按需调整剧本的实际需求。

• 例如：我如果支持手工写入IP,那是否需要支持使用文本批量导入IP?

• 例如：我是否需要一个解封IP的前端功能？

• 例如：我是否需要一个容错机制，当防火墙接口网络抖动或者多次调用失败时，是否需要封禁到WAF上？

• 例如：我的实际网络中防火墙是三层主主模式？我是否需要考虑当这个主网络不可达时，封禁到另一个防火墙上？（只是举个例子，勿喷，实际场景中，还是三层主备多一些。）

• 整体剧本测试跑通后，我的实际需求是否需要延伸或调整？

剧本设计的注意事项

1. 别人的剧本不一定适合你，应该想想日常运营那些环节自动化或者半自动化能提升你的效率再去设计。不要为了有而有，这样就舍本逐末了。

2. 某些剧本可以结合内部的规章制度来设计。

3. 设计剧本时要尽可能发散一些糟糕的场景，通过糟糕的场景去延伸覆盖设计，慢慢精细化剧本。

4. 剧本设计要兼顾考虑上下游输入和输出的能力，初期设计请尽可能降低预期，流程跑通后，提高要求。

5. 多思考这个剧本场景下，是否需要逃生或容错的机制。

6. 设计剧本时一定要多考虑下是否会带来业务风或安全事故，多想想总归是好的。

7. 不要过于理想化，你设计出来的剧本，一定要是你见过的流程！（一个国外大佬视频的观点，笔者觉得非常有道理。）

产品只是辅助提升人们工作效率的工具，最重要的还是人、工具、流程的结合。其实并没有垃圾的工具，只要我们物尽其用！

【FreeBuf粉丝交流群招新啦！

在这里，拓宽网安边界

甲方安全建设干货；

乙方最新技术理念；

全球最新的网络安全资讯；

群内不定期开启各种抽奖活动；

FreeBuf盲盒、大象公仔......

扫码添加小蜜蜂微信回复“加群”，申请加入群聊】