致我心中的“散装”SOAR，当Thehive遇到n8n
写在最前面
2022这一年有太多琐碎的事，导致这个“作业”从2022年“成功”被我拖到了2023年。如果你和我一样，尝试用开源组件来构建一套安全运营平台，并且恰巧你也正在使用Thehive来管理日常安全运营工作，同时在寻求提升运营效率的途径。那么，我觉得这篇文章应该会对你有所帮助。
现状
由于一些历史原因，当前SIEM不仅负责多数据源的关联分析，也同时兼顾对日常告警的自动化响应。在初期团队资源有限的情况下可以用这种方式去“顶一顶”，到了后期如果你不去对功能做解耦，你的SIEM可能会变的越来越“笨重”。是的，SIEM并不擅长做自动化响应类的工作。随着时间的推移，你会发现它越来越难“胜任”这份工作。例如：
自动化响应能力单一，无法实现复杂事件的自动化响应
随着，安全事件的复杂程度不断的上升，我们在很大一部分的安全事件中是无法直接“断言”并采用简单粗暴的方式进行响应。更多情况下我们需要进行一系列的研判分析后，再决定启用对应的遏制动作。
响应流程通过代码实现，维护成本较高不利于后期管理
由于前期是通过脚本开发的自动化响应功能，未采用Workflow（工作流）的直观展现方式。在后期不利于团队多人协作，并且对于一个新入职的小伙伴而言短期内很难维护。
SIEM平台上分析与响应耦合度太高，导致很难对SIEM功能进行扩展
所以，我们需要SOAR（安全编排与自动化响应）来帮助我们承接安全事件中响应侧的需求，从功能上进行“解耦”。
自SOAR这个概念在2017年被提出后，经过5年的迭代无论国内还是国外都已经有了相对成熟的商业产品了。商业产品的我就不过多介绍了，开源的项目介绍几个比较火的：
开始搬砖🚧
这里我使用了n8n与Thehive进行集成，这也是Thehive官方推荐的方案之一。我尝试把SIEM上的响应逻辑迁移到了n8n上，并且也顺带重新设计了响应剧本的Workflow。一个典型的SOAR剧本应聚焦在 分析 与 遏制 2个阶段上，因为只有让分析研判尽可能的全面才能更好的去支撑下一阶段的遏制。下面和大家分享一下使用了n8n作为SOAR之后的一些理解吧，欢迎大家交流！
1. 剧本自身要分类
我们在设计剧本的时候也应当为剧本自身做好分类，这是为了便于后期更好的在其他剧本中复用这些节点。一个主剧本必然是通过不同的子剧本“组装”而来。我觉得这和写代码很像，要先把“类”抽象好，然后在下面不断的去完善“功能”。切记，不要一上来就想整一个“复杂”的剧本，尽可能的把它拆细了拆小了。
以下是我在n8n上编排的威胁情报剧本，它可以是任何一个复杂剧本的分支，支持将内容输出到TheHive，并将告警推送到Slack上。
n8n
主剧本
这里是一个Suricata alert的主剧本，将会由不同的分支子剧本共同“支撑”
子剧本
它可以是任何一个”大”剧本的分支，例如这是一个威胁情报的子剧本
Slack
当命中威胁情报后调用Slack发送告警并升级当前Case等级
TheHive
- 所有的分析记录与事件详情通过Thehive来汇总与呈现
- 为每个响应阶段创建对应的Task
- 执行结果更新到Task的logs
- 将威胁情报Tags更新到observables，便于分析人员直观的了解当前IoC的信息
2. 内容呈现很关键
对于调查取证的剧本而言，查询结果呈现非常的关键。如果SOAR运行之后无法直观的展现数据，想看详细数据还得让你去下载一个文本，这对分析人员而言并不是很友好且割裂感很强。这里我就要推荐一下Thehive了，如果你的安全事件都是推送到了Thehive上，你完全可以将输出的内容设置为Markdown格式，TheHive能够帮助你更好的呈现自动化节点输出的结果。就像下面这个示例，为了帮助分析人员缩短研判时间，现需要对威胁情报的剧本进行扩展。我们会对IP类型IoC进行PDNS的反查，将反查的域名再次与威胁情报进行匹配，并通过Shodan收集攻击者的主机信息。在这种情况下，对于数据的呈现就提出了要求。一个好的展现方式可以让分析人员更快的了解信息，反之将适得其反。
TheHive
- 虽然查询的数据源比较多，不过通过TheHive的Markdown格式起来还算比较直观
3. 你的下一个剧本不应该只是“响应”
我们要知道当一个安全事件触发时，我们为安全事件所做的任何动作都是在”响应”这个事件。SOAR中R（Response）所指的响应，也并不只是在最后遏制的时候才叫做响应。不论哪种类型的剧本，它的目的都是为了提升安全事件的处置效率。这里建议大家千万不要觉得SOAR上的Playbook（剧本）必须都是要标配有遏制的动作。为什么这么说？是因为在一些企业中有SOP（安全事件指导手册），SOP中都会标注遏制方法或者响应措施，导致有些小伙伴认为SOAR上的剧本需要按照SOP做1:1的还原。
另外一方面在实际运营中，对于一个安全事件想要完全自动化走完剧本还是挺“艰难”的，能够被自动化走完的更多是“专项”场景，这类安全事件针对性强处理流程和模式相对固化。所以，我们在实际工作中，遇见此类告警的机率相对于还是比较少的。对此，我们应尽可能的完善分析类型的剧本，将可被“固化”的分析逻辑集成到剧本中，利用自动化提升分析的效率，也可以帮助我们规避因为分析师经验问题导致的分析“面”缺失。例如，我们可以提取Payload中需要被执行回连的IP或者Domain，并在当前网络中检索是否有对应的请求数据，从而研判这个攻击是否成功。就像之前描述的那样，这并不是一个遏制类的剧本，它是一个分析研判类的剧本，但它确实起到了效果。
n8n
- Hunting Callback IoC
- 子剧本
TheHive
- 一旦检测到内部流量存在Callback IoC的数据则升级告警等级，反之则认为攻击并未成功，告警降级自动关闭Case。
- 尽可能利用TheHive的task logs，输出有价值的信息。也许它并不能帮助你实现自动关闭Case，但是它可以帮助分析师更快的查阅已被自动化执行的结果
4. 对入SOAR的告警提出要求
如果我们想要用好SOAR，就应当对入SOAR的告警提出要求。首先我们得确保入库告警的质量，如果你的告警本身置信度就不高，我相信SOAR在这并不能帮助你什么。SOAR本身就是辅助安全运营，所以本质对安全能力的成熟度也是有要求的。例如：
- 企业自身平台的自动化程度，很多时候SOAR都必须通过API调用的方式查询。例如：CMDB资产平台，很多时候我们是需要调用CMDB资产平台查询主机的业务信息、端口开放情况、安全组等。
- 本身人员的代码能力，就n8n而言，一些扩展事项还是需要通过代码实现的，至少Python、JS得会写。
- 企业自身安全能力的成熟度，如果连基础的安全能力都不具备也没有专职的安全分析人员，我建议暂且可放一放。搞搞基础建设，它不香吗？！安全运营，本身就是一个 P(无)D(限)C(循)A(环)的过程。
写在最后
对于SOAR我是这么理解的，不要“一味”的追求大（D）而（炸）全（天）的剧本，就像SIEM厂家“鼓吹”的我们有N个牛P的检测场景一样，工作中你能遇到的又有多少？对于SOAR的剧本，能够被复用就好，能够提升效率就好。不要“迷信”每个剧本都必须有“遏制”的动作，有的时候“分析研判”的剧本真的很“香”。如果你一定会去做些什么，为什么不让它自动化并且找个“好看”的地方“放”（展现）起来。
好了，就啰嗦到这吧。后面如果还有空的话会再补充，欢迎大家交流，写的不对的地方也欢迎指正。在新的一年想创建一个SOAR Playbook的社区，有没有志同道合的小伙伴一起？欢迎扫码加好友，可以一起聊一聊。
