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

“静态”的安全建设弊端大家都很清楚，如何让安全建设变成可持续的动态化的安全建设，那么安全运营应声而起。接下来的系列篇章，将介绍在一家营收规模超百亿，安全团队不超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；紫色部分为成熟的开源组件