安全运营之SOAR:架构雏形 – 作者:bigface

企业安全建设往往容易处于一种“静态”,是什么样的静态?如季度漏洞扫描,创建定时的扫描任务,扫描对象往往不变(静态);如设计蜜网,一次设计一次规划后,蜜罐数量、蜜罐位置与蜜罐功能往往不变(静态);如采购安全产品,部署使用等待安全事件(告警),而产品结合企业安全需求充分使用其功能的思维往往不会出现。

“静态”的安全建设弊端大家都很清楚,如何让安全建设变成可持续的动态化的安全建设,那么安全运营应声而起。接下来的系列篇章,将介绍在一家营收规模超百亿,安全团队不超6人的企业,安全团队如何高效应对繁重的安全任务,以及安全建设如何可持续运营的思考以及落地实战经验。

可持续运营思考

安全运营,重在将安全的元素持续运营。有业界前辈理解安全运营主要有两点:安全的风险直观化、建设期已过开始追求结果。其实这也是一个动态的运营过程,先是基于经验的安全建设,随后发现风险产生安全事件,通过分析安全事件的来龙去脉,将事件处理结果记录总结,持续优化安全建设。所以,我们需要建设一个能基于安全事件结果,调整安全事件的属性(级别、出现频率、描述等),优化分析策略的运营平台,像是一个“反向传播”的过程。

与此同时,安全工作普遍存在突发性,这就要求安全团队必须具备随时关联分析IT基础信息(如CMDB中存放的资产信息、网络设备信息)、业务请求、安全设备事件、外部威胁情报等等数据的能力,并按照一定的安全分析逻辑快速得出一个粗糙的结论。所以,我们需要一个能快速的基于需求,编排安全分析任务的安全运营平台。

基于以上思考,我们开始基于开源组件自行构建安全编排自动化平台(SOAR)。

SOAR(Security Orchestration, Automation and Response)平台,简单来说主要提供丰富的事件响应与处理编排能力、自动化方式处理能力,一个编排逻辑常被称为剧本(playbook),那么使用playbook就能很好的解决突发性的需求,以及周期维护运营的问题。

我们设计SOAR平台的选型与搭建,主要遵循的原则:

  1. 选用开源组件必须是大众熟悉的,有官方团队在持续支持优化的。
  2. playbook编写必须是简洁的,任何一个具备入门级开发能力的小伙伴都能快速上手。

SOAR平台解决的是可灵活编排事件或数据、周期日常运维的工作,对于密集型实时分析,我们将这块分析任务交给专门的产品或组件模块(flume、flink、openresty等),通过它们产生信息作为playbook的输入。

目前国内外都有优秀的厂家在做SOAR平台,为什么我们经过测试对比后没有选择采购呢,主要原因有:

SOAR产品对接的安全设备(版本差异、定制产品差异)以及开源组件接口较少,若符合企业安全需求,需要厂家投入大量人天对接企业产品的接口,使得项目存在很多不确定性,影响产品验收。

Playbook的安全分析以及日常运营经验沉淀太少,SOAR产品应沉淀更符合甲方企业安全运营的Playbook,很多实践经验,可直接在预设的Playbook中直接实现效率更高。

Playbook自定义灵活性较差,需要安全团队人员花大量时间学习厂家产品,才可自行对接接口、开发Playbook

整体架构

SOAR平台最核心的部分就是编排引擎,开源工作流引擎有很多,如Airflow、Azkaban等。通过对比测试,最终我们选择使用Airflow作为编排引擎。使用Ariflow的DAG(有向无环图)可以编排我们所需要的任务,通过设计任务,最终编排成playbook,Airflow具备很多天然的优势如playbook错误重试、数据追赶等等。为了兼容后续的Airflow更新,我们的二次开发均以插件的形式接入Airflow。

拥有了一个核心引擎以后,打造SOAR平台,我们还需要使用的核心的组件有:ELK、jenkins、kafka、Postgresql、Flask&Celery等。

整体架构如下:

其中红色部分Airflow引擎组件,使用celery作为worker,当playbook任务繁重时可快速水平扩展worker,减轻任务压力;绿色部分提供playbook运转所需要使用到的API、管理playbook功能、处理playbook事件等功能,主要以Flask为api的开发模块,负载使用nginx;紫色部分为成熟的开源组件

来源:freebuf.com 2020-12-08 16:44:42 by: bigface

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论