自动化编排已经成为行业内讨论很多的话题，但自动化编排的场景、如何实现自动化编排，还在探索中。本文从软件定义安全的角度，讨论了安全编排的必要性、关键支撑技术、实现架构和发展方向。
一、安全为什么要编排
1 什么是软件定义安全
Gartner 自提出了软件定义安全的理念，为安全防护指出了一个可行的方向。软件定义安全连续多年被列入了十大新技术。软件定义安全从概念上借鉴了软件定义网络，即将安全的控制平面和数据平面解耦，控制面关注安全业务逻辑，数据面关注能力抽象和性能提升，从而避免厂商锁定，提高整个安全防护的灵活性和响应速度。
需要说明的是软件定义安全虽然源于软件定义网络 SDN，也可以借助 SDN 的流量调度、控制技术加快安全防护的速度、增加安全防护的能力，但软件定义安全强调的是安全自身的体系重构，最终分离为安全应用、安全控制器和安全设备（资源池）三层，该体系是可以独立于 SDN、NFV 及其他特定的业务系统。
在云中的软件定义安全落地技术有：
- CWPP，对于云中业务变化频繁的特点，不能依赖固定的安全防护机制，需要感知业务迁移，动态部署相关的安全机制。
- 软件定义分段（或微分段），可根据业务而非固定的网络地址进行全局的网络隔离和访问控制，访问控制策略是通过控制平面下发到不同的 enforcer 中，可能是主机上的 agent，也可能是网络设备。
所以本文讨论的软件定义安全不会聚焦于如何调度流量、如何对接虚拟化平台，而是假定安全应用具备了流量调度、资源管理和策略下发的能力，进一步关注应用间的编排：这些应用于不同场景的应用彼此间什么关系，不同应用的策略如何生效。
2 编排是软件定义安全的核心价值
随着云计算等应用持续发展，安全平台与业务系统的管理平台对接已日趋完善。如主流的公有云和私有云平台内部都支持了 SDN 和 NFV 技术，安全厂商的设备可以 SaaS 服务的方式与之对接，形成如脆弱性评估、Web 安全、DDoS 缓解等特定的防护能力。
这个机制可遵从软件定义安全的架构：
控制层，安全控制和分析平台对接云平台，进行流量控制和安全虚拟机部署， 应用层，租户访问 SaaS 应用，配置策略和查看事件 数据层，安全设备部署和接入后，根据策略对流量进行检测或阻断 然而，随着业务的发展和攻防场景的不断深化，面向单攻击场景的单个安全应用无法应对拥有多种网络武器库的攻击团伙，那就需要一种机制，能够将现有的安全应用组织起来，根据当前的上下文和攻击者行动灵活调用相应的安全应用，进而快速、稳定、一致地准备好安全应对能力。
这就需要使用到编排技术，编排（Orchestration）的本意是在如大型的交响乐演奏中，乐者各司其职，根据指挥的指令演奏乐章中自己的部分。同样，如果将安全应用比喻成乐者，那么要实现敏捷、弹性的软件定义安全机制，就需要有两个核心：
- 剧本（即前述的乐章），体现了安全防护的逻辑，指示如何调度安全能力，我们称之为剧本（Playbook）；
- 编排引擎，一套能够根据剧本有效指挥安全应用的机制。
如果说云环境中，用户在网页中下发策略将安全防护简单化、傻瓜化，那通过编排引擎，自动化、API 化地驱动各应用，却是将安全防护规模化、敏捷化、智能化了。
而且用户可以根据自己的需求，编写灵活简单的剧本，去按需调用某些应用，实现某些特定场景中的安全功能，摆脱了以往只能依靠安全厂商标准化产品的窘境。
所以安全编排大大地扩展了安全防护的场景，提升了安全防护的能力，加快了各类安全机制协同的速度，是实现软件定义安全体系的核心能力。
Gartner 近年提出了 SOAR（Security Orchestration Automation and Response），并列入十大新技术，可见软件定义安全理念落地时，编排已经成为非常有前景的使能技术。
二、如何编排安全
1 编排系统的架构
安全控制器的核心功能是对虚拟化资源、网络流量和安全策略进行控制，安全应用的编排更多的是发生在业务层面，例如入侵检测系统发现挖矿软件外联行为，接下来应该如何处理，应该调用防护墙阻断，还是通知 EDR 杀掉异常进程，则应由编排逻辑决定。
所以，在原有的软件定义安全体系的应用层之上，可独立加一层编排层，如图 2 所示。虽然安全控制器可实现诸多控制层面的功能，如资源池化，策略拆解、设备管理等，但不可否认在现阶段安全控制器无法接管所有厂商的安全设备和安全工具，所以作为重敏捷的编排系统，必须能够支持第三方的安全应用，这些安全应用可以直接操作安全设备或工具，这样安全运营团队就可以最短的时间驱动现有的安全功能。
其核心是编排引擎，输入是剧本和订阅事件，输出则是到安全应用的策略。
编排系统还会和其他业务系统对接，例如 Splunk 收购 Phantom Cyber 后，将大数据分析平台与编排系统打通，形成检测事件到行动的闭环；而 ThreatConnect 则将编排系统与威胁情报平台对接，当发现异常的 IOC 后，则转入自动处置的环节。
当然还有一些提供 MDR 和 MSSP 安全服务商，为了降低大规模应急响应处置的边际成本，为应急响应团队的提供简单的编排运行时环节，不需要很重的安全平台，只需要利用现有的小工具，也能快速的处置，但这样的编排系统需要与服务报告系统打通。
2 编排实例
绿盟科技 2019 年《安全事件响应观察报告》（以下简称《报告》）中给出了几个典型的安全事件场景，其中有勒索软件、挖矿软件、Web 入侵等，利用编排引擎，可以大大提升这些场景下的安全处置效率。
2.1 勒索软件的处置
勒索软件是近几年日益显著的威胁之一，典型的如《报告》中所提的 GrandCrab、Satan 等，我们可总结其共性特征，利用多种安全机制实现对勒索软件的快速检测和处置，具体针对每类恶意软件，则有针对性地编写剧本。
编写剧本前需了解客户环境中所具有的安全能力，我们假定客户 A 的办公环境中是 Windows 台式机组成的局域网，网络边界有防火墙 FW，网络中部署入侵检测系统 IDS，客户终端部署 EDR 软件，并存在 EDR 的管理平台 EDRM。设备和平台的告警数据都接入大数据分析平台 SIEM。
安全团队分析完需求后，整理出现有安全能力：EDR 具有终端侧的行为检测（如勒索软件批量加密并删除文件）和响应（将恶意代码清除、删除持久化文件或注册表）能力，IDS 具有网络侧的异常流量（如勒索软件与 CnC 通信）识别能力，防火墙具有网络侧流量（如勒索软件与 CnC 通信）阻断能力。在编写剧本的时候也应注意，优先处理靠前攻击阶段的告警，这样避免在勒索软件最后对文件加密造成不可挽回的后果。整理如下的流程图：
该剧本启动后，会定期地从 SIEM 中获得告警信息，如果发现某终端存在勒索行为，或 IDS 发现存在符合勒索软件通信的流量，则转入处置环节。此时，剧本会寻找找到被入侵终端上的 EDR 软件，执行清除勒索软件的指令；但如果 EDR 软件没有安装，则向防火墙下发策略，阻断勒索软件和主控端的通信，并切断感染主机的传播通道。如果没有任何安全处理机制，则在 SOC 中提交一个工单，让安全管理团队人工处理。
运营团队通过自动化工具画出上图后，系统自动转化成如下代码：
import sdk.nsfocus.com as sdk
def on_start(container):
filter_1(container=container)
def block_ip_1(action=None, success=None, container=None, results=None,
handle=None, filtered_artifacts=None, filtered_results=None):
config = [ {
'plugin': "nsfocus_firewall",
"asset": "firewall_1"
}, ]
ret_artifacts_1 = sdk.collect2(container=container, datapath=[
'filtered-data:filter_1:condition_1:artifact:*.cef.destinationAddress',
'filtered-data:filter_1:condition_1:artifact:*.id'])
parameters = []
for ret_artifacts_item_1 in ret_artifacts_1:
if ret_artifacts_item_1[0]:
parameters.append({
'ip': ret_artifacts_item_1[0],
})
sdk.act( "block ip", parameters=parameters, callback=test_callback,
config=config, name="block_ip_1")
return
def filter_1(action=None, success=None, container=None, results=None,
handle=None, filtered_artifacts=None, filtered_results=None):
ret_artifacts_1, ret_results_1 = sdk.condition(
container=container,
action_results=results,
conditions=[
["artifact:*.name", "==", "挖矿程序连接DNS矿池服务器通信"],
["artifact:*.name", "==", "watchdogs挖矿木马DNS通信"]
],
logical_operator='or',
name="filter_1:condition_1")
if ret_artifacts_1 or ret_results_1:
block_ip_1(action=action, success=success, container=container, results=results, handle=handle, filtered_artifacts=ret_artifacts_1, filtered_results=ret_results_1)
return
ret_artifacts_2, ret_results_2 = sdk.condition(
container=container,
action_results=results,
conditions=[
["artifact:*.name", "==", "批量加密操作"],
],
name="filter_1:condition_2")
if ret_artifacts_2 or ret_results_2:
call_agent_1(action=action, success=success, container=container, results=results, handle=handle, filtered_artifacts=ret_artifacts_2, filtered_results=ret_results_2)
return
def call_agent_1(action=None, success=None, container=None, results=None,
handle=None, filtered_artifacts=None, filtered_results=None):
config = [ {
'plugin': "nsfocus_edr",
"asset": "edr_platform"
}, ]
ret_artifacts_1 = sdk.collect2(container=container, datapath=[
'filtered-data:filter_1:condition_1:artifact:*.cef.destinationAddress',
'filtered-data:filter_1:condition_1:artifact:*.id'])
parameters = []
with open('Clean_Wanna_Virus.py', 'r') as f:
script = f.read()
for ret_artifacts_item_1 in ret_artifacts_1:
if ret_artifacts_item_1[0]:
parameters.append({
'ip': ret_artifacts_item_1[0],
"script": script
})
sdk.act( "call_agent", parameters=parameters, callback=callback,
config=config, name="call_agent_1")
return
def on_finish(container, summary):
return
if __name__ == "__main__":
on_start("ransomware")
将流程图转换为代码是一个常规自动化的过程，但在运营过程中可能需要针对勒索软件变种的新行为对原剧本做一些微调，这要求安全团队有一定的开发能力。此外，真正的剧本代码会比上图更复杂，比如 satan 恶意软件除了连接主控端外，还会以蠕虫的方式传播，所以防火墙的策略不仅要阻断恶意网站下载、恶意软件连接主控端的流量，还需要对受害主机和内网其他主机进行隔离，以防其进一步感染内网。
2.2 大规模安全应急处置
报告中提到的 “利用 WebLogic 组件漏洞挖矿” 等案例，根源在于攻击者会将新出的漏洞利用加入到自己的武器库，并快速扫描互联网上可用脆弱主机并入侵。在安全漏洞爆发的开始阶段，安全团队需要检查企业生产环境大量的服务器是否受到影响，如是则进行临时缓解，等待安全补丁发布并进行升级，通过剧本可以显著提升处置效率。
由于生产环境有比较复杂，所以剧本还需要做大量的环境判断工作，以提高处置的准确率。例如需要关注当前安全漏洞处置的阶段，是漏洞刚曝光，安全设备已有缓解策略，还是已经有完整的安全更新，每种情况都需要做相应的处置。此外，TTL 很小的容器环境中，不应对容器实例进行安全评估，而应对容器仓库的镜像进行评估。
如下为安全处理的流程图，当{X}集合非常大时，剧本的执行效率会非常高，而且通过闭环化的安全评估，最终可以使所有受到影响的终端得到及时修复，整个过程是完整、一致和可验证的。
图 6 处理流程图
由于流程较为复杂，此处就不给出具体的剧本伪代码了，有兴趣的同学可自行编写。
3 编排自动化后不需要人了吗？
既然编排可以通过脚本化的剧本实现，那是否就不需要安全运营团队，实现全自动的流程实现秒级响应呢？
诚然，编排可以将以往大量繁琐、重复的人工活动变成自动化的流程，从而大大提高处置效率。然而，不可否认编排系统还需要人的参与，原因有两点：
安全运营始终是安全团队根据现有的需求建立安全体系，该体系中大量的工作是非技术的人力投入，安全工具也只是技术体系中的一个辅助手段，所以编排系统只是一个不错的补充，不能代替现有的流程。 攻防情势总是在变化，剧本只能处理已知的流程，当出现新的安全威胁或处置请求时（特别是阻断、隔离和删除操作），如果没有专家参与和确认，容易产生严重的后果。
三、下一代安全编排
安全控制器为自动化安全功能提供了驱动数据平面资源的能力，编排系统为自动化安全业务提供了驱动控制平面（安全策略）的能力，所以两者提供了自顶向下的敏捷自动化的能力。但剧本中如何指示安全应用目前大部分还是通过简单的程序控制逻辑，缺乏对环境变化的适应性。
1 智能化决策
可预见，自动化和智能化结合会是安全编排的未来：首先通过学习以往经专家处置事件的报告，以及建立自学习的攻防靶场，下发策略后评估效果，训练得到模型和参数；当运行时获知安全事件后，剧本可通过分析当前的安全上下文，做出准确的判断，进而进行一系列合理有效的处置。
分析过程中，剧本可以通过人工智能或机器学习的算法，构造输入事件、输出策略的模型和参数，如通过深度学习的模型可以隐藏决策过程中的特征集合，但同样能够得出正确的结论，而非使用现有剧本的 if-then 这样的固定规则，避免攻击者通过改变若干变量就可绕过安全处置。
当然，如果防守方采用了人工智能的方式，攻击者也会利用人工智能寻找决策模型中的过拟合部分，进行自动化攻击，这就对决策的机器学习模型的健壮性和稳定性提出了要求。
2 策略冲突消除
应用策略的目标、颗粒度、作用域是业务相关的，所以多个安全应用之间的策略可能会出现不一致的地方，比如 DLP 应用 A 发现虚拟网络中出现数据泄露，需要对 10.0.0.0/16 网段的主机进行隔离；而 BCM 应用 B 则认为网络地址为 10.0.0.10 的主机是重要资产，通信不能中断，那么此时编排系统是否能获知下发的策略是否存在冲突，甚至在策略下发之前就预测并消除潜在的策略冲突。
在《软件定义安全》一书的 1.2.2 和 4.3.4 小节介绍了 NFV 和 SDN 方面的策略冲突消除的工作，从笔者的经验来看，根据业务的特性，为策略定义优先级，是消除冲突的可行的方法。但即便如此，也不能完全保证通过算法冲突消除是合理的，所以让应用和运营者感知到发生的潜在策略冲突，也是编排系统需要支持的功能。
3 跨厂商的剧本兼容
前面我们提到，安全控制器无法支持所有厂商的设备，那就可能出现没有安全控制器支持的第三方应用。那么会出现以下场景：客户 C1 侧有厂商 A 的防护设备 DA，但未接入安全控制器，则运营者快速根据 X 的接口编写了应用 APP1 和剧本 PB1，PB1 通过 APP1 向 DA 下发策略，而如果运营者发现另一个客户 C2 也有此需求，但 C2 只有厂商 B 的防护设备 DA，那就只能再编写新的应用 APP2 和剧本 PB2，虽然 PB1 和 PB2 大体相差不大，但调用应用部分还是有区别。随着剧本中调用的第三方应用频次和类型增加，剧本的管理复杂度会呈指数级上升。
所以是否能够对应用的语义本身做一层抽象，实现相同功能的应用也形成池化，编排引擎通过应用语义和剧本需求寻找到合适的应用，然后通过应用适配器下发策略。
四、总结
在网络对抗过程中，攻击者手法多变，防守者所处的环境上下文、拥有的安全能力也难标准化，所以造成了既有固定的安全机制难以有效对抗恶意攻击。安全编排可编写特定场景下的剧本，灵活调度安全能力，是解决上述难题的有效手段。
尽管安全编排有诸多优点，同样也存在很多挑战。例如：
攻防对抗日益加剧，攻击者能在小时级利用新漏洞导入已有武器库，防守方也同样需要在小时级完成漏洞分析和规则更新，以及部署相关安全能力，这就要求安全公司具有快速响应能力，企业安全团队具有一定的编码能力，对安全应用和剧本做一定的微调以适应其环境。