前言

Canva 的使命是成为全球最受信任的平台。为了获得并保持客户的信任，我们实施了多种机制和系统，尽量减少恶意攻击者获取我们系统权限和客户数据的可能性。一般来说，我们专注于保护面向公众的系统，如 Canva 产品和支持它的基础设施。然而，我们也致力于保护那些可能被滥用来访问这些基础设施的系统，特别是发放给 Canva 员工的笔记本电脑。举个例子，LastPass 在 2022 年受到了影响，黑客通过员工笔记本中的一个存在漏洞且未修补的应用程序入侵，进而利用键盘记录器获取凭证，访问其他公司系统。

这个问题看起来似乎容易解决，当发布了新的补丁，就应该更新它。然而，当你尝试在大规模环境中解决这个问题时，复杂性就显现出来。每个应用程序的安装程序都托管在不同的网站上，用户可能不知道哪些已经过时，也可能没有把更新当作优先事项。更新需要时间，而这些时间本可以用来做其他有价值的工作，或者已安装的应用程序数据可能不可用。在 Canva，我们实施了多种流程和系统，帮助我们在大规模环境下解决这个问题。我们的终端设备数量超过 5000 台，分布在全球多个国家。我们没有找到一个能做所有事情的工具，因此我们将多个供应商的产品整合在一起，构建了一个与多个供应商产品互动的系统。本文将解释它是如何工作的。

定义 SLA 和责任边界

在实施解决方案之前，明确谁负责什么，以及参与团队在解决问题时的时间框架非常重要。我们会与相关团队共同定义时间框架，而不是单方面指定。在 Canva，我们的安全团队负责发现和报告漏洞，而 IT 团队负责解决这些漏洞。两个团队之间有良好的合作关系，因此我们不会让一个团队单独承担某个步骤的责任。相反，我们定义每个步骤的负责人，其他团队则提供支持。

当我们确定了责任之后，我们会定义 SLA。SLA 对优先级排序和责任追踪非常重要。定义 SLA 不是一门精确的科学，它依赖于感知的紧急性和团队的能力。我们是澳大利亚公司，因此我们的SLA基于澳大利亚信号局的网络安全中心发布的《Patching Applications and Operating Systems》文档。请记住，SLA 应当是可以审查的。当我们引入新的流程时，我们从宽松的 SLA 开始，允许团队进行调整，并随着工作改进逐渐收紧。我们根据漏洞的严重性将 SLA 分为低、中、高和危急四个级别。

数据流可视化

下图展示了数据在我们系统中的流动方式。如果看起来有点复杂，不用担心，接下来我们会深入讲解各部分的内容。

数据流

获取应用程序和漏洞数据

数据帮助我们确定问题的范围并衡量我们的方法是否有效。为了获取应用程序数据，我们依赖于 SentinelOne，这是一款 EDR 解决方案。EDR 代理程序有一个模块，可以列出所有终端设备上安装的所有应用程序，并将数据聚合后在控制台上显示，并通过 API 提供查询功能。在 EDR 收集的数据中，我们能够获取应用程序名称、设备标识符、应用程序版本和应用程序供应商等信息。当我们将这些数据上传到控制台时，我们的 EDR 供应商会为每个应用程序版本组合分配漏洞。然后，我们可以通过控制台或 API 获得以下附加数据：分配的常见 CVE ID、常见 CVSS 分数、检测日期和最后一次见到的日期。

还有其他方法可以获得这些数据。你可以使用 MDM 解决方案或设备数据收集工具来获取应用程序的版本和名称。通过在设备上部署osquery可以为你提供进入这些宝贵数据的通道。掌握了这些信息后，你可以将其与CVEProject数据进行交叉引用，识别你设备中的存在漏洞的应用程序。

以下是漏洞记录的一个示例。

{
"application": "Docker 4.19.0",
"applicationName": "Docker",
"applicationVendor": "Docker Inc",
"applicationVersion": "4.19.0",
"cveId": "CVE-2023-5165",
"detectionDate": "2023-09-27T06:03:02.387819Z",
"daysDetected": 15,
"endpointId": "1654713486719847187",
"id": "1",
"lastScanDate": "2024-03-31T10:42:19Z",
"lastScanResult": "Succeeded",
"nvdBaseScore": 8.80,
"nvdCvssVersion": "3.1",
"osType": "macos",
"publishedDate": "2023-09-25T16:15:00Z"
}

获取并处理数据

可以想象，我们通过这种方式生成了大量的漏洞数据。我们会为每个终端上的每个应用程序的每个 CVE 记录生成单独的记录，这会迅速导致产生大量数据，因为应用程序可能有多个 CVE（而且通常来说，应用程序越旧，漏洞越多）。我们的数千台终端通常安装了多个应用程序，可能让人觉得有些难搞。然而，如果我们稍微退一步看，我们其实只需要了解几个关键点：

  • 应用程序的名称和供应商。

  • 哪些版本存在漏洞。

  • 最关键的漏洞的严重性。

  • 这个漏洞所在的设备。

尽管其他细节也很有帮助，但因为修复漏洞的方式通常是通过更新，我们更关心的是哪些应用程序需要更新，哪些终端上安装了这些应用程序。

更新应用程序

确保在整个设备队列中保持应用程序的最新状态是最棘手的部分。幸运的是，我们的 MDM 可以管理某些应用程序的更新。我们利用 MDM 来管理超过 70 个应用程序（还在不断增加）。我们有很好的覆盖率，因为大部分设备使用一组常见的应用程序，我们也可以管理一些专门团队使用的应用程序的更新。对用户的影响最小：当更新准备好时，我们的 MDM 代理会通知用户并提供更新选项。当用户点击更新按钮时，应用程序会关闭、更新并重新启动。

不支持的应用程序

对于 MDM 不支持的应用程序，我们依赖于一种基于统计风险的方法，利用我们 EDR 收集的数据。我们使用 AWS Lambda 函数查询 EDR 的 API 并提取漏洞信息。经过一些聚合后，函数会判断某些脆弱应用程序在一定比例的设备中存在（我们设置的比例为 40%，随着补丁处理能力的提升，这个比例已逐渐降低），并为 IT 团队创建工单进行审查和调查。我们根据受影响的设备数量和最严重的漏洞优先处理这些工单。

这种方法可能会因为人工审查环节而成为瓶颈。因此，我们与 IT 团队紧密合作，确保他们有足够的资源来处理我们上报的漏洞。我们只有在达成协议后才会略微和缓慢地调整比例。该方法的好处是，我们能被及时通知管理的包含漏洞的软件超过定义阈值的漏洞。这使我们确信我们的流程是有效的。例如，当一个新的 Chrome 漏洞被发布时，我们预期会收到一个工单。由于 Chrome 是被 MDM 管理的应用程序，我们不会对这个工单采取任何行动，期望它在几天内通过 MDM 自动解决。

根据这些漏洞的风险，我们采取多种方法来降低风险。虽然将受影响的应用程序添加到 MDM 管理的应用程序列表中是我们首选的方案，但这并非总是可行。我们还可以采取更手动的更新步骤，如部署全组范围的脚本或要求用户手动更新。对于最关键的问题，且当没有补丁时，我们可以暂时阻止应用程序的运行，等待我们评估其他解决方案。然而，我们力求在采取这种极端行动时，尽量减少对用户的影响。为了实现这一点，我们主动向用户推荐频繁更新的替代应用程序，以作为替代品。

默认情况下，我们根据最严重漏洞的 CVSS 分数来确定风险。但在某些情况下，我们会使用其他来源和数据点来帮助评估风险，比如评估我们威胁情报团队的报告，或当漏洞被主流媒体曝光时。此时，漏洞通常非常容易被远程利用且几乎不需要用户交互，或者已经有黑客活跃地利用它们。

以下是这些工单的样子。

工单

工单的截止日期会根据 CVSS 的严重性和在标准中定义的 SLA 自动计算。

测试过程

到此为止，我们对流程的运作方式已经很满意，但我们希望知道它是否有效。为此，我们拿了一台测试笔记本，安装了几款受特定 CVE 影响的旧版本应用程序。我们安装的应用程序中包括了受CVE-2019-17026影响的 Firefox 72.0 版本。我们可以在下次应用程序扫描后，在 EDR 控制台中看到漏洞。我们的自定义系统也报告了这个漏洞，并生成了正确的工单。当我们在 MDM 中设置自动更新 Firefox 时，我们还收到了通知用来提示笔记本更新该应用。

如何衡量成功

除了从提取的漏洞数据创建工单之外，我们还将其传送到数据仓库，供我们进行分析、寻找模式，确保各项数据走势正常。以下是其输出样式。

数据表

我们使用这些数据创建了以下视图。请注意，展示的数据并不是真实的。在某些情况下，图表可能显示漏洞管理方法存在的问题。但这仅仅是用于说明的目的，并不反映 Canva 实际的数据或漏洞管理流程的状态。用于查询和样本数据的代码可以在GitHub上找到，供有兴趣深入了解细节的观众参考。

漏洞随时间变化

漏洞随时间变化

这张图展示了我们减少漏洞的措施是否有效。值得注意的是，这张图和其他类似的图表显示了一个趋势，随着时间的推移，更多应用程序的漏洞被发现并公开发布，因此如果不采取措施，漏洞数量会自然增加。

该图显示了每天报告的漏洞数量及其严重程度。理想情况下，如果补丁工作有效，条形图应该下降。如果它们保持不变，说明我们可能没有解决某些漏洞。我们预期在大范围影响的漏洞新发布时会有大幅增加，例如当操作系统或浏览器发布了新的安全更新时。

漏洞数据可能根据终端设备和应用程序数量的变化而每日波动。特别是当你应用一个补丁解决多个漏洞，或者发布了一组新的漏洞时，这种波动尤其明显。使用包含漏洞应用程序的平均数量有助于了解漏洞随时间的变化趋势，并稳定这些波动。

最广泛的存在漏洞的应用程序

存在漏洞的应用程序分布

这个视图让我们能够直观地了解哪些应用程序对组织构成最大风险。这有助于我们优先管理这些应用程序。它显示的只是最新漏洞扫描报告的快照。特别是在前面提到的图表中，显著变化出现时，它帮助我们识别最可能导致这些变化的应用程序。

漏洞生命周期变化

漏洞什么周期

这个视图提供了环境中漏洞生命周期的有趣数据。图表趋于上升，因为漏洞每天都会变老（距离发布的那一天），但它能帮助我们了解那些未被处理的漏洞有多久没有解决。

我们在这个图表中使用了百分位，而刻意避免使用平均值，因为平均值有时会产生误导。如果你的平均值较低，可能是因为你快速解决了大部分漏洞，而只有少数旧漏洞留在环境中太久。百分位数提供了更好的上下文，帮助我们推断数据的分布。

前面的图表显示了到3月5日，大约一半的漏洞是一天以内的，而另一半则是一日以上的，如 P50 线所示。从这一点来看，我们可以推断出，大部分漏洞非常新，并且大部分漏洞得到了及时解决。图表还表明，至少有一个漏洞已经多天未解决，如 P95 线所示。在我们测量漏洞生命周期的第五天，至少 5% 的报告漏洞已经有 5 天之久。由此，我们可以确定，在大多数情况下，漏洞修补工作有效，但至少有一个漏洞似乎一直存在。在更大的数据集中，使用额外的百分位值和图表来比较最老漏洞值也是很有用的。

超出 SLA 的广泛管理漏洞应用程序

超出SLA的广泛管理漏洞应用程序

这个视图是 Canva 最有效的输出之一。它比之前的视图更为复杂，使用了一个外部表来确定哪些应用程序我们进行了集中管理。

理想情况下，这个图表应该仅显示出突发的高峰。和第一个图表类似，每当一个漏洞被发布，它就会在我们修复前出现在该报告中。当供应商发布更新并且我们应用补丁时，数字应该迅速下降。如果数字持续高位，则说明我们未能解决漏洞，这可能由多个原因导致。可能没有补丁，更新过程可能没有按预期进行，或者补丁可能引入了新的漏洞。

过程中遇到的问题

要达到良好的成熟度水平并不总是顺利的。以下是我们在过程中遇到的一些问题：

  • 补丁问题： 我们不得不进行大量实验以确保自动补丁工作顺利。在我们将所有补丁通过 MDM 推送之前，我们也曾使用一些供应商提供的补丁工具。特别是，我们在处理 Microsoft Teams 时遇到了困难。尽管设置正确，且没有报告问题，但我们从仪表板中发现补丁并未安装。

  • 偏门的软件： 我们的 EDR 在应用程序可见性方面存在一些问题，只有符合特定标准的应用程序才会被视为已安装，比如应用程序必须被 Spotlight 索引，而不仅仅是磁盘上存在。当用户运行应用程序时，如果它不在标准位置（例如在 ~/Downloads文件夹中），则我们的 MDM 就无法对其进行更新。

  • 库存陈旧： 默认情况下，我们的 EDR 每周只会列出一次应用程序清单。这在应用程序修复后会引入一些延迟，导致漏洞报告在最多七天内依然显示为漏洞。我们通过通过 API 触发每日自动刷新清单来解决了这个问题。

  • 误报： 我们的终端设备主要是 macOS 设备。有时我们会收到误报，显示软件漏洞仅影响 Windows 终端。这是因为我们收到的漏洞报告仅考虑应用程序和版本，而不考虑操作系统。当我们最初构建聚合和报告系统时，我们添加了排除功能，这帮助我们迅速删除了误报。遗憾的是，我们尚未找到有效的自动化处理方法。

未来工作

尽管前述工作已经大大降低了风险，但它并没有消除所有风险。以下将描述我们计划探索的一些方向。我们还打算遵循并应用Essential Eight Maturity Model这一正式框架，以改进我们的漏洞管理项目。

在漏洞评估中使用可利用性

我们用来优先解决漏洞的方式有些僵化，缺乏有价值的上下文。CVSS 框架考虑了漏洞的易利用程度以及是否有官方补丁可用。然而，我们从工具中得到的结果只是一个分数，没有更多的细节。我们希望考虑每个漏洞是否已有公开利用，并且是否有威胁行为者在积极利用该漏洞。我们可以使用这些信息来补充我们的优先级排序工作，并优先处理那些最容易被利用的漏洞。美国的CISA提供了已知漏洞利用目录，我们可以利用它来进行此项工作。

在姿态评估中使用漏洞数据

如果设备上有高严重性的漏洞应用程序并且补丁已经发布，我们希望在设备尝试访问敏感数据之前，用户能先进行补丁更新。为了促使用户执行此操作，我们可以添加一个检查，要求试图访问敏感数据和应用程序的设备必须保持最新状态。

用户通知

目前，任何希望了解自己设备漏洞的用户都可以运行报告，然后根据需要采取行动并进行更新。另一种方法是向用户发送通知，告知他们应用程序存在漏洞并需要更新。这种方法需要大量的微调，因为我们希望避免打扰用户，以免他们忽视这些通知。

总结

作为一家快速增长的公司，处理大规模漏洞管理至关重要。我们希望提高终端设备队列的安全性，同时最小化对员工的影响。我们在这方面的工作还带来了一些额外的好处。当一个影响流行库或应用程序的高严重性漏洞（例如最近 libwebp 中的漏洞，CVE-2023-4863）发布时，我们能更好地了解漏洞在我们环境中的位置、修复速度以及是否需要采取其他措施，比如在补丁发布之前暂时停用应用程序或实施其他控制措施。

如果你也打算实施类似的漏洞管理解决方案，可以通过一些免费的工具或者供应商的帮助来完成。以下是一些主要的要点：

  • 要准备投入一些精力去自研。即使有供应商的支持，找到一个完全符合需求的解决方案也非常困难，因此你可能需要构建一个连接不同产品的系统。

  • 制定包含明确 SLA 的文档是与利益相关者对齐期望的好方法。

  • 集中管理的应用程序和更新对减少终端设备漏洞在大规模环境中的传播至关重要。记住，你需要解决的是整个设备队列中的问题，而不是过分关注单个应用程序或漏洞。考虑投入的努力是否值得。

  • 保持用户体验为核心。我们的做法是通知用户并提供更新选项，用户可以在方便时进行更新。如果用户在规定时间内没有更新，更新会被强制进行。这样，用户可以选择更新的时间，从而减少干扰并简化流程。

  • 设置有限的范围；不要试图解决所有应用程序上的所有漏洞。应用程序和漏洞几乎是无限的。通过限定漏洞管理项目的范围，你可以有效地消除部分风险，并在此基础上不断改进方法。随着项目变得更加有效并且你更有信心时，可以逐步扩大范围。

  • 不在范围内的项目可能需要不同的处理方式。一个单一的解决方案可能不适用，因此你可以考虑其他方法来应对那些不在范围内的问题。

  • 利用数据！定期检查数据是确保解决方案有效并找出需要关注的漏洞的关键。通过构建 Dashboard，可以让这一过程更加简单。

以上内容编译自 Canva

声明：本文来自RedTeam，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。