自主安全：将安全自动化推向新高度

概述

自动驾驶汽车行业定义了无人驾驶汽车的 6 个级别：

• L0 - 无自动化
• L1 - 驾驶辅助
• L2 - 部分自动化
• L3 - 有条件自动化
• L4 - 高度自动化
• L5 - 完全自动化。

SRE（站点可靠性工程）领域已经采用 Autonomous System（自主系统）一词来指代对自动化的审慎应用，但 Autonomous Security（自主安全）一词在安全行业中尚未得到广泛使用。

对 SRE 而言，自动化是力量倍增器，而不是万能药。当然，仅仅倍增力量并不会自然而然地改变这股力量作用点的准确性：不假思索地实施自动化，制造的问题可能和它解决的问题一样多。因此，尽管我们认为在大多数情况下基于软件的自动化优于人工操作，但比这两种选择更好的，是一种两者都不需要的更高层次的系统设计——自主系统。换句话说，自动化的价值既来自它所做的事情，也来自对它的审慎应用。

没有人会否认，安全自动化对于在任何组织内扩展安全运营都至关重要。我们所处环境的规模、多样性和复杂性，使得当前依靠人力和人工流程来应对大量漏洞和事件的做法难以扩展。扩充团队最终会受限于我们能招聘多少人，而扩充流程最终会严重拖累组织的生产力。

Autonomous Security 的目标是将决策过程自动化。例如，在漏洞扫描的场景中，这可能表现为隔离存在漏洞的机器、设置防火墙规则或部署补丁；在事件响应的场景中，这可能表现为转储内存以进行取证分析，以及收紧对关键系统的访问。

要实现如此高程度的自动化，离不开有效的技术，以及一个用于衡量哪些有效、哪些无效并发现缺失之处的反馈循环。

本文在安全扫描的背景下提出 Autonomous Security 这一概念，并概述了所需的技术模块和策略。最终目标是将遏制措施自动化，并利用反馈循环来弥补缺失部分和盲区。

本文定义了 5 个等级来反映不同的成熟度水平。在接下来的章节中，我们将定义每个模块，并说明如何在实现完全 Autonomous System 这一目标的过程中提升其成熟度。

1. 资产清单与发现

资产清单是指列出资产并收集有用的元数据，例如归属、用途（生产环境与开发环境）以及目标定位信息。例如，列出组织内所有台式机，并收集 MAC 地址、IP 地址和所属员工等元数据。

在安全扫描中，资产清单用于安排扫描、分派待修复的漏洞、呈现某一环境安全状况的汇总视图，以及推动战略性的修复工作。

如果资产清单纯粹以安全为导向，就很难维护；最好不要由安全团队来运营。资产清单的维护无论从技术角度还是流程角度来看都是一项挑战。在大多数情况和环境中，我们需要维护的资产清单面临着各不相同甚至相互矛盾的要求，例如高度易变的资产与不可变的资产、数量少但变化频繁的资产与数量多但很少变化的资产，或者归属模糊的资产与归属层级分明的资产。因此，构建并维护一个能够满足所有这些要求的基础设施是一个极具挑战性的问题。

例如，扫描台式机与扫描数据库服务器就不同：台式机会经常更换 IP 地址，并且只有一个所有者；而数据库服务器很少更换 IP 地址，它所运行的服务则有各自不同的所有者。

此外，资产清单可以服务于广泛的用途，例如跟踪资源消耗（财务）、监控部署（生产）。因此，如果由生产来驱动，资产清单会更容易维护，因为这通常是保持其最新状态的最佳方式。

一个典型的例子是 Spotify 新近开源的项目 Backstage：Backstage。据该项目背后的团队介绍，由于 Backstage 提供了创建和监控部署的工具，它自然而然地成为了他们资产清单的唯一可信来源。

虽然最新的资产清单是理想状态，但由于人为因素或技术限制造成的盲区，这在实践中是无法实现的。

由于确定盲区代价高昂，资产清单应始终辅以一个外部发现组件，用于尝试定位相应的盲区。发现组件应持续尝试找出仍未被覆盖的疏漏。

发现系统并不局限于域名暴力破解之类的技术工具，还可以借助其他手段，例如跟踪使用企业信用卡进行的付款，从而找出未登记的云项目。

2. 扫描

扫描有 3 个维度，即调度、编排和检测，具体如下：

2.1 调度

调度解决的是何时扫描的问题；它要么基于时间，要么基于事件。基于时间，例如每天一次。基于事件，例如每次提交时或每次创建新容器时。调度由资产的生命周期和漏洞报告的生命周期决定。

在调度方面，并非所有资产都一视同仁。例如，扫描公开网站需要持续的基于时间的规则，而容器则需要基于事件的扫描：在创建时进行扫描，以及在检测到影响容器某个依赖项的新 CVE 时进行扫描。

基于事件的扫描始终优于基于时间的扫描，因为它缩小了可能出问题的时间窗口。遗憾的是，这并非总能实现。以网站的黑盒扫描为例，在无法衡量网站如何变化或演进的情况下，我们唯一的选择就是基于时间的方法。

当前基于时间的方法可以通过避免完全重新扫描、利用以往的扫描结果和覆盖范围而得到大幅改进。 以扫描网站为例，扫描器不必每次扫描都进行完整爬取，而是可以利用以往的爬取结果来加快扫描、检测变化并聚焦测试。

一个完全 Autonomous Security 的流水线不需要用持续不断的扫描去猛烈冲击某个资产，而是可以采取更聪明的方法。如果某个资产是静态网站，并且在过去 6 个月内没有变化，系统应能够降低扫描频率。

2.2 编排

编排定义了如何处理扫描的生命周期，例如发生故障时该怎么做、在扫描的不同阶段通知谁、是否应触发一组额外的处置步骤或通知、是否应创建一个用于扫描的专用副本环境。

借助服务网格类架构（例如 Istio），可以通过复制一组服务来创建一个用于扫描的 testing garden（测试花园），例如根据某个请求头的值将扫描流量路由到新的网格，并对数据库或消息队列等共享组件的访问施加配额。

编排对于 PCI-DSS 或 FedRamp 等合规制度通常至关重要。一个完全 Autonomous Security 的流水线可以定义一组 Hook 来触发面向业务的逻辑，例如通知特定人员、更新特定仪表板、生成特定报告等。

2.3 检测

当我们谈论安全扫描时，大多数人想到的通常就是检测。检测固然重要，但它只是庞大机器中的一个齿轮。

恰当的检测必须减少误报和漏报，并结合上下文来评定严重程度。找到既适合组织规模、又与环境严重程度相匹配的平衡点，是一项重要的权衡。

绘制组织所拥有的资产类型图并建立覆盖范围图，有助于识别缺失的能力。一个简化的覆盖图可以简单到这样：

* Network:
    * IPv4: CHECK 
    * IPv6: MISSING

* Web:
    * Known Vulnz: CHECK
    * non-SPA: CHECK
    * SPA: MISSING
    * Authenticated: MISSING

* Mobile:
    * Android: CHECK
    * iOS: CHECK
    * Mobile Backend: CHECK

* Cloud:
    * VM: MISSING
    * Containers: CHECK
    * Serverless: MISSING

 ...

也可以复杂到这样：

* Web:
    * SQL Injection:
      * Postgrs:
        * WHERE Clause: CHECK
        * FROM Clause: MISSING
        * ORDER Clause: LIMITED

虽然检测是一个非常宏大的话题，但该领域一个常见的抱怨是，安全厂商往往承诺过多而交付不足。这是一份很好的资料，说明了安全行业为何因技术无效而失败

所有安全解决方案都可以拆分为 2 个技术部分：一个 Analysis Engine（分析引擎）和一组 Rules（规则）。引擎通常接收一个程序、一个网站或一个 IP，并执行一系列转换或交互。

Analysis Engines 的示例：

• 依赖指纹引擎：查找依赖项和第三方组件。
• 污点引擎：生成面向对象的污点图，以找出 source 与 sink 之间的关联。
• 动态引擎：收集堆栈跟踪、方法和参数。
• 模糊测试引擎：注入输入并收集数据流和崩溃报告。

随后，Rules 会利用引擎的输出来检测存在漏洞的行为。规则通常类似于：

• 如果应用名称为 libjpeg、版本 < 2.0.1 且启用了 BMP，则存在内存破坏漏洞。
• 如果加密 API 使用了 ECB 模式，则存在不安全加密模式漏洞。

Rules 一直以来都由专家手工编写，并且通常只使用单一 Analysis Engine 的结果。由于编写 Rules 的经济性和成本问题， 对于不太常见的框架中不太可能出现的漏洞，即便其后果严重，也很少有人去检测。

3 策略

策略是指导原则，它为做出决策设定了框架。策略在经过正确渠道（CTO、CISO……）审核后，可以帮助组织及时采取行动，减少升级处理和来回讨论的需要。

传统的策略是补丁策略。它根据漏洞的严重程度规定漏洞应在何时修复。例如，高危问题应在 1 个月内修复。如果未能修复，就可以对存在漏洞的资产采取强制措施（见第 4 节）或进行升级处理（见第 5 节）。

您会惊讶地发现，例如向管理层展示一个列出超出 SLO 问题的仪表板，能在多大程度上帮助加快修复。

这种补丁策略并不足够，因为它是对安全问题的被动响应，按定义来说总是滞后的。一个很好的补充是新鲜度策略，它要求软件、依赖项和应用的陈旧程度不超过 x 个月。黑天鹅策略是另一个很好的例子，它规定了在出现需要多个团队多人同时投入的高度严重漏洞时应该怎么做。

策略不仅从安全角度来看必不可少，从运维角度来看也同样重要。它们能保持生产环境健康，避免技术债务和生产债务的积累。

许多组织都有类似的恐怖故事：某个对生产至关重要的应用，没有人知道该如何构建或 部署它，而它却已经在生产环境中运行了好几年。

要实现完全 Autonmous Security 的系统，需要一个强制执行策略，用于规定自动化强制执行如何运作：是否需要人在回路中（human in the loop）或人在回路上（human on the loop）、如何进行紧急破窗（break glass）操作，以及哪些系统符合条件。

人在回路中（Human-in-the-loop，HITL）被定义为需要人工交互的模型。人在回路上（Human-on-the-loop，HOnTL）被定义 为处于人类操作员监督之下、由操作员推翻行动的模型。人在回路外（Human-out-the-loop，HOutTL）被 定义为没有任何人工交互或监督的模型。

4. 遏制：修复与强制执行

修复是最被低估、但矛盾的是又最关键的模块。遏制有助于修复漏洞或消除漏洞。

修复很难做好。它往往首先是一个人的问题，而且难点贯穿始终：从设法找到正确的负责人来修复问题，到建立适当的激励机制推动修复，再到找到合适的沟通渠道来报告和跟踪修复，最后还要有办法验证漏洞是否被正确修复。

云平台提供了出色的工具，可在不影响生产工作流的情况下帮助对修复进行验证，例如用于复制完整项目的 Terraform，或用于金丝雀部署的 Istio 等服务网格，都非常有助于解决这些问题。

强制执行是 Autonomous Security 系统的巅峰，它有助于防止漏洞慢慢渗入您的系统，同时也能有力地激励开发和运维团队加快修复。

然而，强制执行应考虑到首先保证生产可靠性的重要性，并在需要时提供可验证、可追溯的紧急破窗手段。没有管理层的支持，强制执行就无法开展；最好从小处着手，先应用于面向互联网的实验性系统，然后是内部系统，再到非关键的生产系统。

强制执行可以从人在回路中开始，即由人批准强制执行操作，然后过渡到人在回路上，即只需审查已经采取的行动。

云平台提供了强制执行安全部署以及从入侵中恢复的工具，例如 TUF 和 Notary。

5. 仪表板与指标

Dashboard 和 Metrics 是自主安全系统的关键组成部分。它们衡量系统的健康状况，提供一种可量化的方式来计算投资回报，并能借助有据可依、以数据为支撑的决策来推动战略行动。

Dashboards 有助于为合适的人提供适量的信息，以便做出明智的决策并确定行动的优先级。能够了解自身的安全态势、了解情况如何改善（或没有改善），并定量衡量哪些方面存在缺失，这正是安全领域常常缺少的东西。

Dashboards 部分由 Metrics 驱动，有助于识别趋势、衡量并防止缓慢恶化，同时衡量进展和投资回报。

面向整个组织的仪表板，例如按业务部门或团队列出漏洞数量的仪表板，能有效 促使人们采取行动。您会惊讶地发现，没有人愿意排在图表的最底部，而排行榜能够 激发良性竞争。

仪表板必须针对每类用户量身定制，以帮助他们做出可执行的决策。例如，安全团队的仪表板会侧重于漏洞的严重程度和数量；C 级高管的仪表板会侧重于整体健康状况、业务组织状态和最紧急的问题；开发人员的仪表板则会侧重于他们负责或参与的代码。

仪表板必须提供有用的视图，以便得出有数据支撑的结论并采取明智的行动。

下一步是什么？

Ostorlab 的创建初衷，就是提供便于在任何组织内集成 Autonomous Security 解决方案的工具。这首先包括：与专业的应用商店和资产清单 API 集成，提供强大的技术发现工具（例如面向移动应用的 Android 和 iOS 应用商店），专注于以高置信度检测高严重程度漏洞（例如过时的依赖项、密钥泄露），以及简化监控规则的创建。

如需及时了解最新动态，请订阅我们的月度新闻通讯。