第一章 软件供应链威胁的背景

本章概述了核心主题，例如攻击者的诱因、软件供应链攻击的剖析以及相关的里程碑式案例。

1.1 攻击者激励因素

供应链攻击规避了传统的外围防御，使其对攻击者非常有吸引力。组织在防火墙、入侵防御和访问控制方面投入了大量资金。这些保护措施是针对直接针对组织基础结构的“推送”式攻击的防御措施。供应链攻击助长了一种更像是“拉动”的场景，即信息技术（IT）的合法用户故意请求一次恶意软件更新，从而破坏其组织。由于请求源自受信任的用户，并且来自公司组织内部，或者是已通过第三方风险管理流程评估后的受信任实体，因此这个更新是认为可信的。结果看起来是组织自己伤害了自己。
在探索防御攻击所需的控制措施时，仅考虑单层架构作为有效的防御措施是不够的。就像网络基础设施管理员意识到他们需要监控出站流量或实施基于主机的控制一样，这种向纵深防御的转变，尤其是跨边界，至关重要。出于各种原因，包括云、移动、社交媒体和现代应用程序基础设施，边界的概念也不断拓展。它不再是一个静态的边界，而是需要被视为信任区域之间的隔离层，无论它们是位于网络边缘、还是作为应用程序或访问控制机制内的逻辑屏障。因此，我们的控制和由此产生的威胁建模必须考虑整个攻击面，并探索每个交互点和信任关系。
供应链攻击也能起到力量放大器的作用。通过识别关键依赖关系或广泛使用的软件，攻击者可以将恶意代码注入任何环境，然后利用该代码。这种情况屡见不鲜，类似于水坑式攻击的概念，攻击者入侵目标群体使用的广泛使用的网站，例如工业控制系统 (ICS) 集成商使用的可编程逻辑控制器 (PLC) 网络论坛。如果攻击者可以入侵访问论坛的每个用户，理论上他们就可以访问这些集成商工作的任何关键基础设施实体。同样，这些集成商使用的任何被入侵的软件都可能将不必要的恶意功能引入安装该软件的环境中，即使在这些顾问转入下一个项目很久之后。
所有这些都意味着软件供应链攻击对攻击者来说非常有利可图。网络间谍活动有一个经济因素，它极大地受益于可重复使用的漏洞和供应链攻击的低入门成本。此外，许多最近的攻击都结合了通过软件供应链部署的勒索软件，这不仅使攻击变得容易，而且为勒索软件运营商带来了直接的经济收益，并让那些担心业务中断的组织越来越担心
1.2 威胁模型

威胁建模是一个经常被谈及的主题，但根据作者的经验，大多数组织很少在实践中执行。作为一个行业，我们经常以相当通用的方式讨论威胁，而从未探索正确建模这些威胁所需的软件或系统的背景。然而，这些活动的核心是攻击面（交互点）的定义，以及对可能出现的问题的探索。
为了确保提供最大的清晰度，我们将定义几个关键术语：
威胁 威胁是一种会造成不良后果的负面事件。威胁可能是自然发生的、本质上是良性的，也可能是明显的恶意行为。
例如，您企业的计费系统无法捕获交易条目，或者数据中心被龙卷风摧毁。
威胁代理 威胁代理是导致威胁发生的实体。例如，黑客活动分子、恶意内部人员、心怀不满的业务合作伙伴、受到攻击的顾问，甚至是天气模式。人们注意到，威胁归因经常是错误的，对攻击模式的特定威胁代理的假设可能会导致对保护特性的错误假设。例如，如果您认为一个容易受到勒索软件攻击的国家可能是威胁代理，但您却面临着一个更专注于间谍活动的威胁代理，这会如何改变您的安全态势？实际的原产国是否重要，还是会造成不当偏见？
威胁行动 这是威胁主体采取的行动，最终导致威胁发生。例如，威胁主体（如黑客活动分子）可能会贿赂您的系统管理员重新配置计费系统，从而导致最终造成财务影响的威胁。
威胁模型 这是记录系统和威胁的过程，这样我们就可以对与威胁相关的某些类型的系统风险管理决策进行建模。威胁建模有不同的目标，包括一般网络风险管理、系统设计和分析，甚至信息共享模型。
威胁建模方法
威胁建模方法有几种类型。我们先来讨论一下 STRIDE。
Stride
STRIDE 是一种非常常见的威胁方法，用于帮助确定可能出现的问题，尽管它并不是唯一使用的方法。STRIDE 分解为与首字母缩略词一致的助记符：
S欺骗：冒充其他用户或系统组件以获取其对系统的访问权限
T篡改：以某种方式更改系统或数据，使其对目标用户的用处降低
R否认：合理地否认在给定用户或流程下采取的行动
I信息披露：向未经授权的各方发布信息（例如，数据泄露）
D拒绝服务：使系统对目标用户不可用
E特权提升：未经授权授予用户或进程对系统的额外访问权限
大多数供应链攻击都是操作系统的结果，而传统模型（如 STRIDE）是为对系统进行更直接的攻击而设计的，而不是当管理员请求更新其应用程序（以前称为良好，但后来却变成恶意）时发生的间接影响。
Stride-LM
洛克希德马丁公司的研究人员通过添加第七个维度（称为横向移动）扩展了 STRIDE 方法。虽然 STRIDE 对于系统设计很有用，但它不能满足网络防御者的需求。
STRIDE-LM 为防御者提供了一种机制来设计控制措施，使其在最初的入侵点之外更有效地进行防御。
在评估威胁模型是否适用于软件供应链攻击时，请问问自己该模型的设计目的是什么以及它将如何应用于所讨论的场景。例如，许多供应链攻击通过恶意更新或滥用信任来滥用维护阶段，从而绕过旨在检测初始软件入口点的控制措施。同样，由于软件供应链固有的单点故障，这些行动的下游影响可能无法在原始 STRIDE 方法中得到有效建模。随着我们探索本书中的里程碑式案例，您将开始看到横向移动的使用如何为建模提供额外的背景，并使 STRIDE-LM 更适用于面向供应链的攻击.
开放式全球应用安全项目 (OWASP)风险评级方法
OWASP 方法被用作一种定量评分模型，通过利用技术威胁和业务影响标准来得出分数，从而评估特定风险。其核心是使用相当标准的影响 × 可能性计算，但有趣的是等式的两边是如何创建的。以下描述试图捕捉这个公式的基础，但应该注意的是，在实际使用中，改变因素或对非常重要的特定因素施加权重的情况并不少见。例如，在关键基础设施中，我们发现许多实体希望在业务影响中添加第五个“安全”因素，并且通常会赋予它比其他因素更高的权重.
Likelihood = AVG(Threat Agent + Vulnerability)
其中威胁代理 = 技能、动机、机会和规模；漏洞 = 发现的难易程度、利用的难易程度、意识和入侵检测。
Impact T = AVG(Technical Impact + Business Impact)
其中技术影响 = 机密性、完整性、可用性和责任感的丧失；业务影响 = 财务损失、声誉损害、不合规和隐私。
Risk Score = Likelihood X Impact
OWASP可用于评估已识别的风险并确定其优先级以采取行动，但作为威胁建模技术，它对识别未知风险的作用较小。在应用其他威胁建模技术后，将 OWASP 纳入您的流程可能是有意义的。根据我们的经验，它远远优于优先级机制，例如通用漏洞评分系统 (CVSS) 评分，但它确实需要上下文才能发挥作用.
DREAD
DREAD 是 Microsoft 创建的一种传统技术，但我们很少看到它被使用，它通常被认为是一种“过时”的方法。DREAD 使用了类似于 STRIDE 的助记符：
D损害：攻击会有多严重？
R可重复性：重现攻击有多容易？
E可利用性：发起攻击需要多少工作量？
A受影响的用户：有多少人会受到影响？
D可发现性：发现威胁有多容易？
使用攻击树
攻击树（请参阅 http://schneier.com/academic/archives/1999/12/attack_trees.html）是一种从意外或不良后果逆向工作的可视化方法（以便您可以了解该事件如何发生以及最有可能的攻击载体），以及一种创建要实施的优先控制列表以防止该后果的方法。在图 1.1 中，你可以看到，对攻击者来说，最便宜的途径就是直接打开保险箱。优先考虑物理安全控制，以防止他人进入保险箱，或者花更多的钱购买能够抵御此类攻击的保险箱，这可能是明智之举。虽然内部威胁是一种可行的攻击媒介，但攻击者的经济状况使他们不太可能选择这种方法.
这是一种有效的方法，可以开始了解供应链攻击，并了解与更传统的攻击相比，供应链攻击有多么容易实施。对于传统攻击，一半的战斗是获得物理访问权限，甚至试图绕过访问控制。在供应链攻击中，受信任的实体正在采取破坏系统所需的行动。然而，需要穿越的障碍要少得多。让我们看图 1.2 中的攻击示例，它使用了域名抢注攻击，即攻击者提供名称与真实软件包相似的恶意软件包，将恶意组件伪装成 GitHub 上的合法库。这是一个完整的例子。
为了更好地理解这一点，请考虑执行攻击所需的步骤。洛克希德马丁公司开发了一种称为网络杀伤链 (http://lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html) 的方法，它描述了攻击的各个阶段。虽然有很多细微差别，但这些是对手方法的基本步骤（见图 1.3）。
如果对手可以跳过大部分步骤并直接进入指挥和控制，会怎么样？对于对手来说，降低实施攻击的成本和复杂性，并通过了解他们可以实现这些目标的途径，是非常有吸引力的。
威胁建模过程
在本节中，我们将描述一个典型的威胁建模过程。首先，您必须定义您正在构建或更新的系统或应用程序。确定其组件以及这些组件如何相互作用。这开始为识别系统的攻击面奠定基础。它可能是外部可用的应用程序编程接口 (API) 或超文本传输协议 (HTTP) 服务。也许还有其他依赖项，例如需要通信以执行应用程序逻辑或利用联合的身份验证服务的中间件或数据库服务器，但对核心架构理解的需求是启动此过程的基础。
OWASP 应用程序安全验证标准 (ASVS；http://owasp.org/www-project-application-security-verification-standard) 将这种基本的架构理解定义为一项基本要求，包括在设计和未来变更周期中进行威胁建模的需要。OWASP 软件组件验证标准 (SCVS；http://owasp.org/www-project-software-component-verification-standard) 通过要求软件物料清单进一步扩展了这一概念，我们将在本书后面进一步探讨这一点。然而，很明显，要理解威胁以及如何防御威胁，就必须牢牢掌握需要保护的内容.
可以使用许多工具来记录您的系统；其中一种常用工具是 Microsoft 威胁建模工具。多年来，它是唯一可行的选择，但过去几年来，这一领域已经发生了很大变化。威胁建模工具允许软件架构师在开发过程的早期识别威胁，以免补救成本过高。它使用 STRIDE 模型来记录威胁。
在图 1.4 中，您可以看到一个简单的应用程序容器，它将 Internet 访问公开的 Web 服务的上下文与本地访问的上下文分离到文件系统级别，使用信任边界将这些应用程序构造分隔开来。通过以这种方式剖析您的系统，您可以确定潜在威胁代理如何与您的系统交互，并可以开始回答此过程第二部分的问题。还有其他免费工具，例如 OWASP 的 pytm，这是一种基于 Python 的方法，使用常见攻击模式枚举和分类 (CAPEC) 定义自动进行威胁建模，我们将在本章后面进行探讨，以及 Threat Dragon，它更类似于 Microsoft 工具。还有非常强大的商业工具可用，例如 Threat Modeler 和 IriusRisk，它们也采用了 ASVS 设计原则中的先前概念。
威胁建模过程的下一步是确定可能出现的问题。这可能只是简单的错误情况或未接受正确使用应用程序培训的用户，也可能是攻击者试图造成伤害。为了我们的目的，我们将重点关注恶意网络破坏场景来探讨这个主题。
为了说明潜在的软件供应链威胁场景，请考虑图 1.4，其中恶意行为者将恶意日志条目注入 Web 服务，当该服务在本地使用并由日志查看器打开时，会在用户的浏览器中执行恶意 JavaScript。如果许多下游用户使用此 Web 服务，则一次日志注入攻击可能会导致许多依赖此服务的下游用户全部受到攻击。然后，它创建了一个场景，其中攻击者已经破坏了一个 Web 服务，并利用它来破坏许多其他组织，并且现在已经建立了一个滩头阵地，对这些组织或信任它们作为其供应链一部分的下游客户进行进一步攻击。这种数据篡改攻击可能会对下游产生巨大的影响。
知道了可能出现的问题后，您就需要了解可以实施哪些控制措施来最大限度地减少威胁。此阶段的一部分可能包括优先级排序，因为可能无法消除所有潜在威胁；但是，关注最有影响力且成功率较高的场景可能有助于指导控制对话。
例如，在前面描述的场景中，也许清理日志输入或转义字符可能会产生针对此攻击的额外保护。由于攻击者可以通过多种方式绕过传统保护措施，例如为防止跨站点脚本 (XSS) 而实施的保护措施，因此查看类似的保护措施可能会有所帮助，例如 OWASP XSS 预防备忘单中记录的保护措施，该备忘单提供了防止 XSS 漏洞的指导。备忘单列出了防止或限制 XSS 攻击影响的技术 (http://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html)。
威胁建模的最后阶段通常涉及评估威胁模型的完整性，并问自己图表是否足够完整以涵盖所有场景，以及是否清楚地标识了信任边界。首先，确定您是否已涵盖所用模型（例如 STRIDE）中定义的所有威胁操作，以及是否已探索所有数据流。最后，确定是否已为所有已识别的威胁制定了风险结果或行动计划，即使已经确定担心所需的缓解措施是否超出您的控制范围且无法采取行动是不可行的。每次在系统中引入重大架构更改时，您都应该关闭模型上的循环并重新验证模型。
此外，我们发现以下概念在软件供应链威胁主题中发挥着重要作用，因此需要花一些时间来定义它们：
溯源(Provenance) 溯源是指工件来自何处。它常常与谱系(Pedigree)混淆（见下一项）。溯源应用于软件时，可能包括特定软件组件的来源或谁为特定库贡献了代码。组织很少在个人贡献者层面进行跟踪，但对于高安全性场景，这可能是值得的。我们通过经验看到，几乎每个广泛使用的开源库都会有来自可能被视为敌对国家的贡献，因此对于选择深入到这一细节级别的组织，可能需要额外的缓解控制或更深入的安全分析来确定这些贡献是否有问题。
谱系(Pedigree) “跟踪和追踪”的概念并不新鲜，事实上，它是法医科学的一个核心概念，与“保管链”日志的应用密切相关，该日志可识别从创建到交付接触过工件的任何人。跟踪指示工件的移动，而保管链则归因于接触工件的个人或组织。安全设备交付的概念同样也出现了，用于跟踪物理资产在全球范围内的运输方式，包括通过 GS1 系列标准使用唯一标识符（如批次 ID 和全球贸易标识符）和保护措施（如物理不可克隆功能 (PUF)）。由于我们主要描述与软件透明度相关的数字工件，因此使用加密和透明度日志可以满足这些要求。与软件透明度相关的谱系可能表示软件包或该软件的安全补丁的历史记录，并且它是一个可以记录在某些软件物料清单格式中的概念。同样，谱系还可以跟踪原点随时间变化的位置，例如 GitHub 存储库从一个维护者更改为新维护者，或者供应商剥离了产品线并将其出售给第三方。这些概念我们将在本书后面进一步探讨。
如今，许多威胁建模框架（如 DREAD 和 STRIDE）被用于各种目的。此类框架通常用于描述安全设计和分析。爱达荷国家实验室 (INL) 的后果驱动网络信息工程 (CCE) 框架侧重于控制与特定业务后果相关的威胁，而不一定控制攻击面的每个点。然后是 STIX 和 PRE-ATT&CK 等框架，它们专为信息共享和其他准备阶段而设计。CAPEC 和 MITRE ATT&CK 等框架具有特定的技术或情境重点。特定于组织的框架包括 NIPRNet/SIPRNet 网络安全架构审查。
同样，大规模威胁建模的一个关键重点往往是关注攻击模式。组织无法正确执行威胁建模的原因在于，大规模执行威胁建模非常困难。Microsoft 安全开发生命周期 (SDL) 将威胁建模列为 12 项活动中的第 4 项——紧接着定义安全要求和关键绩效指标 (KPI)，紧接着定义设计。在设计新系统时，这一点非常有意义，但我们如何在整个环境中大规模地对数百或数千个应用程序进行威胁建模？通常，我们最终会走捷径。这就是攻击模式如此受欢迎的原因，特别是如果我们可以根据已识别的对手或已识别的对手目标群体减少攻击模式的数量。
CAPEC 是 MITRE 托管的公开攻击描述目录，最初由国土安全部创建。此目录包含一个供应链条目 (http://capec.mitre.org/data/definitions/437.html)，可帮助防御者了解这些攻击的构造方式，以便更好地识别防御措施。此供应链攻击的 CAPEC 条目描述了此类攻击，如下所示
此类别中的攻击模式侧重于通过操纵计算机系统硬件、软件或服务来破坏供应链生命周期，以进行间谍活动、窃取关键数据或技术，或破坏关键任务操作或基础设施。供应链运营通常是跨国的，零件、组件、组装和交付发生在多个国家/地区，为攻击者提供了多个破坏点。
此类攻击模式还包括：
■ 挖掘
■ 软件完整性攻击
■ 制造过程中的修改
■ 分发过程中的操纵
■ 硬件完整性攻击
此外，参考 MITRE ATT&CK 也会有所帮助，例如供应链入侵条目 (http://attack.mitre.org/techniques/T1195)，其中还包含三种额外的子技术以及一些可能对防御者有帮助的缓解措施：
■ 入侵软件依赖项和开发工具
■ 入侵软件供应链
■ 入侵硬件供应链
不幸的是，他们目前对供应链的覆盖范围还比较基础，将这种方法与更专业的工作（例如云原生计算基金会 (CNCF) 的工作）相结合可能更有意义，这些工作可能提供防御这些威胁所需的更多特异性。
CNCF 的软件供应链攻击目录还包括一个索引 (https://github.com/cncf/tag-security/blob/main/supply-chainsecurity/compromises/compromise-definitions.md)，其中定义了几种类型的攻击。我们将讨论这些攻击类型，以便共享软件供应链中一些主要攻击媒介的词汇表。攻击类型索引包括：
■ 开发工具
■ 疏忽
■ 发布基础设施
■ 源代码
■ 信任和签名
■ 恶意维护者
■ 攻击链
值得注意的是，有几种攻击类型与现有框架相关，例如 MITRE 的 ATT&CK，其中有专门针对供应链攻击的部分 (http://attack.mitre.org/techniques/T1195)，包括软件依赖项、开发工具和软件供应链本身。
开发人员工具攻击是对用于促进软件开发的工具的攻击。这可能是开发人员的终端设备、软件开发工具包 (SDK) 和工具链。MITRE 建议使用完整性检查机制，例如验证和扫描下载以查找恶意签名。如果恶意行为者能够破坏开发工具，他们就能够从软件开发生命周期 (SDLC) 开始就引入潜在的恶意代码，并玷污所有后续应用程序开发活动和消费者。
疏忽是未能遵守最佳实践，这很常见，因为有太多应用程序安全最佳实践需要了解，而且我们生活在一个日益复杂的数字生态系统中。忽略验证依赖项名称这样简单的事情可能会对组织产生重大影响。恶意攻击者越来越多地使用一种称为域名抢注的攻击方法，如前所述，这种方法利用了对依赖项名称细节的缺乏关注。攻击者通常会瞄准流行的框架或库，以与原始库类似的名称添加恶意代码，然后等待毫无戒心的受害者下载并在其应用程序中使用它。
随着组织现在普遍使用持续集成/持续交付 (CI/CD) 管道和平台来交付软件工件，发布基础设施变得越来越重要。一种缓解技术是代码签名，它有助于确保已发布代码的完整性。但是，正如您将在我们的第一个里程碑案例中看到的那样，对 CI/CD 基础设施本身的攻击可以允许恶意行为者合法地签署软件工件，从而向下游消费者展示它们值得信赖。这种攻击方法可能是毁灭性的和邪恶的，它强调了为什么发布基础设施必须像生产环境一样得到保护，并且它们必须与新兴框架保持一致，例如软件工件的供应链级别 (SLSA)，我们将在接下来的章节中讨论它。
源代码攻击涉及对源代码存储库的攻击，要么直接来自开发人员，要么通过对开发人员凭据的攻击。 2022 年 Verizon 数据泄露调查报告 (DBIR；http://verizon.com/business/resources/reports/dbir) 发现，超过 80% 的数据泄露都涉及凭证泄露。这包括影响源代码或源代码存储库的情况。针对源代码和存储库的恶意行为者通常会尝试将漏洞或后门引入源代码，以便以后利用它们或影响下游消费者。
完整性对于软件供应链的信任至关重要。这通常由数字签名和证明等活动来促进。对代码进行签名为下游消费者提供了一定程度的保证，确保代码的来源及其完整性。话虽如此，泄露签名可能会引发软件供应链攻击。因此，纵深防御等基本安全概念仍然是关键。纵深防御是一种长期存在的网络安全实践，使用多层防御，以确保没有任何一个漏洞或弱点导致整个系统或组织的妥协。恶意行为者需要利用多层防御和安全措施来实现其目标，而不是单一的漏洞或弱点。在前面的例子中，仅使用数字签名是不够的，而且可以被利用。这是 CNCF 索引中列出的攻击类型之一，并被 MITRE 在其 ATT&CK 框架的供应链妥协部分中引用。潜在威胁包括盗窃或私钥、错置信任和滥用证书颁发等活动，如美国国家标准与技术研究所 (NIST) 在其“代码签名的安全注意事项”白皮书中所述（http://csrc.nist.gov/CSRC/media/Publications/white-paper/2018/01/26/security-considerations-for-code-signing/final/documents/security concernances-for-code-signing.pdf）。缓解技术涉及建立可信用户、分离角色、使用强加密和保护签名密钥等活动。
鉴于软件供应链的复杂性以及维护者活动通常具有自愿性质，并非所有威胁都源自项目外部。恶意维护者攻击媒介是 CNCF 索引中列出的威胁之一，涉及维护者或冒充维护者的人故意将恶意软件或漏洞注入供应链或源代码。这可能是由于维护者决定采取恶意行为，或者他们的帐户或凭据已被外部实体泄露而发生的。这些攻击的动机范围从黑客活动分子到那些冒充参与维护者的人，他们只会滥用其权限和访问权限来达到邪恶的目的。
最后，攻击和漏洞不会孤立发生。恶意行为者可能会将多个漏洞和攻击媒介串联在一起，以开展他们的活动和预期意图。看看我们提到的一些攻击类型，一个假设的场景可能涉及恶意行为者冒充感兴趣的贡献者或维护者，只是为了滥用他们的访问权限、插入恶意代码、滥用签名等等。将多个攻击媒介串联起来可能会造成毁灭性的影响，这通常被称为攻击链，Nikki Robinson 博士等研究人员对此进行了研究和讨论。
还有其他新兴方法和框架可以保护软件供应链，并威胁模型可能被恶意行为者利用，例如软件工件的供应链级别 (SLSA)，我们将在接下来的章节中深入讨论
1.3 里程碑案例一：SolarWinds

如果不讨论 SolarWinds 网络攻击，那么现代软件供应链安全事件的讨论就不完整。SolarWinds 是市场上最大的数字系统管理工具提供商之一。2019 年，SolarWinds 开始遭受网络攻击，现在这些攻击被归咎于俄罗斯外国情报局。攻击发生时，SolarWinds 拥有 300,000 个客户，其中包括许多美国政府机构和大多数财富 500 强公司。据估计，在这 300,000 个客户中，有 18,000 个（包括联邦政府机构和客户）收到了受损的软件更新。据说恶意行为者随后专门针对了他们认为是高价值目标的受损客户子集。
虽然在攻击的初始阶段情况并不十分明朗，但现在已经有许多事后报告揭示了恶意行为者的技术复杂性以及受影响的公共和私营部门组织生态系统的下游影响。其中一份由美国政府问责局 (GAO) 编写的报告称 SolarWinds 的网络安全漏洞是“有史以来针对联邦政府和私营部门最广泛、最复杂的黑客攻击之一”(http://gao.gov/blog/solarwinds-cyberattack demands-significant-federal-and-private-sector-response-infographic)。
美国政府问责署还制作了图 1.5 所示的报告 (http://gao.gov/products/gao-22-104746)，以帮助传达与 SolarWinds 攻击相关的活动的高级时间表。
SolarWinds 是一个诱人的目标和典型的软件供应链攻击，因为恶意行为者不太可能对 Solar Winds 作为最终目标感兴趣，而是对 SolarWinds 的客户和下游消费者感兴趣。在这次网络安全攻击之前，SolarWinds 在其网站上吹嘘其强大且备受瞩目的客户名单，该名单随后被删除。SolarWinds 网络安全攻击最初不是由该组织本身发现的，而是由其客户之一 FireEye 发现的，而 FireEye 恰好专注于网络安全。据报道，一名 FireEye 员工被提示重置其多因素身份验证设置，这促使该员工将其提请其团队注意。这随后导致 FireEye 调查该事件并将其追溯到 SolarWinds 的恶意软件，特别是他们的 Orion 软件。 FireEye 的事件响应公司 Mandiant 的首席技术官 (CTO) 表示，该公司检查了 50,000 行代码，才确定 SolarWinds 中存在后门。FireEye 发现 SolarWinds 的软件受到感染后，立即联系了供应商和执法部门，告知他们发现的情况。
虽然攻击时间表的某些细节因来源而异，但前面提到的同一份 GAO 报告提供了一些基本事实。时间表可以从私营部门活动和公共部门参与两个角度来查看，当时联邦执法部门意识到了这一点，联邦调查局和网络安全基础设施安全局 (CISA) 等联邦机构也参与其中。
从时间表的角度来看，据说 2019 年 9 月 SolarWinds 内部系统最初遭到入侵。尽管如此，SolarWinds 首席执行官 Sudhakar Ramakrishna 在 2021 年 RSA 大会上表示 (www.cyberscoop.com/solarwinds-ceo-reveals-much-earlier-hack-timeline-regrets-company blaming-intern)，最初的侦察活动现在可以追溯到 2019 年 1 月。在 2019 年 9 月首次系统攻击的同时，恶意行为者还将测试代码注入 SolarWinds 环境，以验证他们确实破坏了系统并可以执行其预期活动。
恶意行为者使用名为“Sunspot”的恶意软件破坏 SolarWinds 软件开发过程并构建系统。然后，他们在 2020 年 2 月左右将一个现在称为“Sunburst”的后门注入 SolarWinds 的 Orion 产品中。2020 年 3 月，向客户提供了一个修补程序，随后 18,000 名 SolarWinds 客户下载了该修补程序。 2020 年 6 月，威胁行为者删除了其在 SolarWinds 构建的机器上放置的恶意软件。直到 2020 年 12 月，SolarWinds 才收到 Sunburst 的通知。SolarWinds 随后向美国证券交易委员会 (SEC) 提交了一份 8-K 报告 (http://sec.report/Document/0001628280-20-017451)，该报告提供了 SolarWinds 当时所了解的有关情况的见解。
2020 年 12 月 15 日，SolarWinds 发布了软件修复程序来解决受影响的 Orion 产品。当然，这提出了一个有趣的难题，因为供应商之前的软件更新包含恶意软件并影响了客户。 CISA 于 2020 年 12 月 17 日发布了警报 (AA20-352A；http://cisa.gov/uscert/ncas/alerts/aa20-352a)，警告存在一种高级持续性威胁 (APT)，正在危害政府机构、关键基础设施和私营部门。此警报表明，五个不同版本的动态链接库 (DLL) 受到了影响。该警报还特别指出了威胁行为者的耐心、复杂性以及与攻击相关的整体高水平间谍技术。2021 年 1 月还发现了与 Sunspot 相关的其他发现。
网络安全公司 CrowdStrike 发布了对 SolarWinds 网络攻击的详细技术分析 (http://crowdstrike.com/blog/sunspot-malware-technical-analysis)。分析发现，恶意攻击者使用名为 Sunspot 的恶意软件破坏 SolarWinds 构建过程，并将其 Sunburst 后门插入 SolarWinds Orion IT 管理产品中。Sunspot 通过监控编译 Orion 产品所涉及的过程，用 Sunburst 后门代码替换原始源文件之一。然后，该后门促成了恶意攻击者创建反向 shell，以访问运行受影响版本的 SolarWinds Orion 的受感染受害者的基础设施。
关于 SolarWinds 网络攻击及其相关恶意软件和后门，还有更多内容可以写出来，这是迄今为止规模最大、最复杂的软件供应链攻击之一。几位联邦和商业技术领导人将 SolarWinds 网络攻击称为一次警钟，并强调需要加强行业对软件供应链保护的严格要求。
SolarWinds 网络攻击之所以如此邪恶，部分原因是恶意行为者利用了网络安全领域长期存在的最佳实践，即确保在供应商提供更新时修补软件。在这种情况下，更新被毒害，因此那些遵循最佳实践并及时更新/修补的人可能会受到影响。通过破坏构建过程，恶意行为者还能够将被感染的软件伪装成已签名且合法的软件。
自 SolarWinds 事件爆发以来，该公司已在其软件构建流程和功能方面投入了大量资金。一些报告和评论（例如 SolarWinds 首席信息安全官 Tim Brown 的报道）声称，他们修订后的“安全设计”计划每年将花费高达 2000 万美元（http://cybersecuritydive.com/news/solarwinds-1-year-later-cyber attack-orion/610990）。SolarWinds 参加了题为“保护软件开发构建环境”的网络广播（http://cybersecuritydive.com/news/solarwinds-software-build-reproducible-cyberattack-code/596850），他们在其中讨论了他们的安全设计方法，其中包括使用可重现的构建来消除二进制代码中的差异。这涉及到组织如何管理版本和依赖关系的变化，包括拥有恶意行为者需要破坏的多个环境才能成功破坏组织的代码。可重复构建 (http://reproducible-builds.org) 在 SLSA 等框架中被引用，特别是在其最高成熟度和严谨度级别 SLSA 4 级 (http://slsa.dev/spec/faq)。我们将在以下部分讨论可重复构建，但值得强调的是，它是一种成熟的实现，很可能最初被主要软件生产商采用，而且正如 SolarWinds CISO 所指出的那样，这不是一项廉价或轻松的任务
1.4 里程碑案例二：Log4j

虽然 SolarWinds 网络攻击是针对软件供应商的，但 Log4j 事件却大不相同，因为它针对的是广泛使用的开源软件 (OSS)。Log4j 事件于 2021 年 12 月 9 日开始引起公众关注，当时安全研究人员发现了流行软件库 Log4j 中的一个漏洞。Log4j 是一个基于 Java 的日志实用程序，是 Apache 软件基金会项目 Apache Logging Services 的一部分。当时，Log4j 主要用于记录与调试和其他活动相关的信息，以帮助开发人员。在事件发生时，据估计 Log4j 存在于超过 1 亿个环境和应用程序中。
2021 年 12 月 10 日，NIST 的国家漏洞数据库 (NVD) 将 Log4j 漏洞在其通用漏洞评分系统 (CVSS) 上归类为 10.0，并将其与通用漏洞和暴露 (CVE) CVE-2021-44228 相关联。随后还发布了与 Log4j 相关的 CVE，其中不仅包括远程代码执行漏洞，还包括拒绝服务 CVE。
零日漏洞公布后不久，新西兰计算机应急响应小组 (CERT) 警告称，该漏洞已在野外被利用 (http://cert.govt.nz/it-specialists/
advisories/log4j-rce-0-day-actively-exploited)。随后，CISA 发布了一项紧急指令 (http://cisa.gov/news/2021/12/17/cisa-issuesemergency-directive-requiring-federal-agencies-mitigate-apache-log4j)，要求联邦机构缓解 Apache Log4j 漏洞。不久之后，2021 年 12 月 22 日，CISA、FBI、NSA 和国际合作伙伴发布了一份联合公告 (http://cisa.gov/news/2021/12/22/cisa-fbi-nsa-andinternational-partners-issue-advisory-mitigate-apache-log4j)，以缓解 Apache Log4j 漏洞。此联合公告是为了应对全球范围内对 Log4j 漏洞的积极利用而发布的。CISA 主任 Jen East 曾称 Log4j 漏洞对世界各地的组织和政府构成了严重且持续的威胁，合作伙伴国家也表达了类似的看法。您可以在图 1.6 (http://unit42.paloaltonetworks.com/apache-log4j-vulnerability-cve-2021-44228) 中查看 Log4j 事件时间线。
与影响特定供应商的特定产品系列的 SolarWinds 不同，Log4j 的影响更加多样化和分散。Log4j 的应用范围非常广泛，从开发人员工具、云服务产品到安全供应商产品，无所不包。正如我们将在本书以云为重点的章节中讨论的那样，最大的云服务提供商 (CSP)，例如 Amazon Web Services (AWS)、Microsoft Azure 和 Google Cloud，都发布了有关 Log4j 的指导，因为在事件发生时，Log4j 已用于他们的许多云服务产品中。当然，这不仅会对直接使用云服务的客户产生下游影响，还会对在 CSP 的基础设施和服务之上构建的其他组织产生下游影响，这不仅强调了易受攻击的软件组件的影响，还强调了由于软件供应链中的服务提供商，它可能产生的连锁影响.
除了 GAO 和其他机构提供的见解外，网络安全安全审查委员会 (CSRB) 还将 Log4j 作为其调查和报告的第一个网络事件 (http://cisa.gov/sites/default/files/publications/CSRB-Report-on-Log4-July-11-2022_508.pdf)。CSRB 是根据网络安全行政命令 (EO)“改善国家网络安全”成立的 (http://cisa.gov/sites/default/files/publications/Cyber​​%20Safety%20Review%20Board%20Charter_508%20Compliant.pdf)。CSRB 的成立也类似于国家运输安全委员会 (NTSB)，其目标是审查重大网络事件并提出具体建议，以推动公共和私营部门的改进。委员会的成员包括具有不同独特专业知识的公共和私营部门领导人。他们的第一份报告（如前所述）重点关注 Log4j，其中大量提到了软件透明度、库存和治理的必要性，而软件物料清单 (SBOM) 是这一追求的核心组成部分。该报告呼吁组织利用 SBOM 来提高 IT 资产和应用程序清单的准确性，并呼吁管理和预算办公室 (OMB)、国家网络总监办公室 (ONCD) 和 CISA 等组织在生态系统成熟时提供有效使用 SBOM 的指导。该报告 18 次提到 SBOM，呼吁公共和私营部门组织在 SBOM 和软件透明度领域采用并增加投资
CSRB 的 Log4j 报告内容全面，将其建议分为四类。这些建议包括解决 Log4j 的持续风险、推动现有的安全卫生最佳实践、构建更好的软件生态系统以及进行未来投资。报告承认，组织将在未来几年内努力应对 Log4j 漏洞，并应继续报告和观察 Log4j 的利用情况。报告呼吁组织投资于识别易受攻击系统的能力，建立漏洞响应程序，并继续开发准确的 IT 和应用程序清单，这是 SBOM 在软件组件和 OSS 消费环境中发挥作用的地方。企业中拥有强大软件组件清单的组织将能够更好地应对下一次 Log4j 类型的事件，了解其组织是否易受攻击以及在何处易受攻击。报告呼吁 OSS 开发人员参与基于社区的安全计划，并投资培训开发人员进行安全软件开发，这是 OpenSSF OSS 安全动员计划中的一项关键建议，我们将在本书后面讨论。它还呼吁改进 SBOM 工具和采用，并投资于关键服务的 OSS 维护支持。最后，该报告还呼吁在关键领域进行投资，例如联邦政府供应商的软件透明度基本要求、探索网络安全报告系统 (CSRS) 以及研究构建安全软件的激励结构。所有这些建议都与公共和私营部门其他领先组织的建议一致，例如 NIST、Linux 基金会、OpenSSF 等。
为了承认易受攻击的 OSS 组件（例如本案中的 Log4j）威胁的普遍性，FBI 和 CISA 于 2022 年 11 月发布了联合网络安全咨询，宣布美国联邦民事行政部门 (FCEB) 的一个机构遭受了伊朗政府支持的攻击。恶意行为者利用未打补丁的 VMware Horizo​​n 服务器中的 Log4Shell 漏洞，安装加密挖掘软件，甚至横向移动到域控制器 (DC) 并泄露凭据以实施反向代理，从而在环境中保持持久性 (www.cisa.gov/uscert/sites/default/files/publications/aa22-320a_joint_csa_iranian_government-sponsored_apt_actors_compromise_federal%20network_deploy_crypto%20miner_credential_harvester.pdf)
1.5 标志性案例三：Kaseya

另一个值得讨论的非常突出的软件供应链攻击是 Kaseya 勒索软件攻击。Kaseya (http://kaseya.com) 是一家统一的 IT 管理和安全软件公司，专门为托管服务提供商 (MSP) 和 IT 团队提供帮助。他们的解决方案旨在帮助团队在 IT 安全、效率和服务交付方面取得进步。
Kaseya 勒索软件攻击发生在 2021 年 7 月，估计已影响了 2,000 家组织。它被归咎于 REvil 勒索软件组织，这是一个主要讲俄语的恶意行为者团体。REvil 组织的个人与 Kaseya 等攻击有关，但也与针对美国企业甚至政府实体的其他攻击有关。
Kaseya 为客户提供本地和基于软件即服务 (SaaS) 的软件解决方案。2021 年 7 月 2 日，该组织的事件响应 (IR) 团队检测到其名为 Kaseya VSA 的远程管理软件存在潜在的安全事件。初步调查引起了足够多的关注，以至于该组织建议其所有本地客户关闭 VSA 服务器，直至另行通知，并且他们还关闭了自己的基于 SaaS 的产品 (http://helpdesk.kaseya.com/hc/en-gb/articles/4403440684689)。Kaseya 建议客户关闭服务器至关重要，因为攻击者在初始攻击期间删除了 VSA 的管理访问权限。
随后，Kaseya 与 FBI 和 CISA 的外部权威机构和专家合作开展 IR 活动。Kaseya 迅速提供了工具，帮助组织确定他们是否因尝试检测入侵而受到影响。在 CISA 和 FBI 等组织与 Kaseya 合作的同时，他们也开始为可能受到影响的客户提供指导 (http://cisa.gov/uscert/ncas/current-activity/2021/07/04/cisa-fbi-guidancemsps-and-their-customers-affected-kaseya-vsa)。他们的指导包括使用 Kaseya 提供的检测工具、加强身份验证流程以及最大限度地减少与已知可信 IP 地址的网络通信等活动。
与此同时，Kaseya 开始测试补丁以解决问题并实施其他缓解安全控制措施。他们还发布了客户指南，试图为即将到来的补丁活动做好准备（http://helpdesk.kaseya.com/hc/en-gb/articles/4403709150993）。
在此过程中，2021 年 7 月 8 日，白宫发表官方声明，将此次袭击归咎于俄罗斯。美国政府领导层也发表声明，承诺追究俄罗斯对此次袭击的责任。虽然 Kaseya 努力为本地和云端的客户解决问题，但有传言称，该组织的高管此前已在数年内被警告过其软件存在缺陷（http://krebsonsecurity.com/2021/07/kaseya-left-customer-portal-vulnerableto-2015-flaw-in-its-own-software）。更有趣的是，涉及的 CVE CVE-2015-2862 属于 Kaseya 自己。
虽然据称此次攻击本身仅影响了该组织 40,000 多名客户中的 0.1%，但根据该组织首席执行官 Fred Voccola 的评论，这一比例仍然相当于 800 到 1,500 家小型到中型组织，这些组织通过使用 Kaseya 软件的 MSP 受到影响。这种涓滴效应是现代软件供应链复杂性的完美例证，以及单个软件的影响如何影响数千个下游消费者。大多数消费者都无法了解他们的 MSP 用于向他们提供服务的软件，因为软件供应链不透明，尤其是在与 MSP 和 CSP 等外部服务提供商打交道时。下游消费者只知道他们直接从提供商那里消费的服务或软件在交付过程中使用。
值得注意的是，回到白宫关于追究责任人责任的评论，已经逮捕了相关人员。美国司法部 (DOJ) 于 2021 年 11 月宣布 (http://justice.gov/opa/pr/ukrainian-arrested-and-charged-ransomware-attackkaseya)，俄罗斯国内安全机构逮捕了 14 名与 REvil 勒索软件组织有关的个人。这还包括缴获与该组织各种勒索软件漏洞相关的 610 万美元。司法部领导层还强调，他们将继续针对那些专注于美国受害者的个人。
1.6 案例的启示

从这些案例中得出的最重要的结论是，专注于传统的“最后一英里”防御措施（如散列和代码签名）是远远不够的，而且可能会给人一种虚假的安全感。最成功的攻击发生在这些过程的上游，签署恶意代码可能比根本不签署造成更大的危害。
其次，就像传统的网络防御一样，建立“正常”的基线可以为异常检测创建标准参考。这包括许多软件物料清单工件的生成，以及有关这些工件的元数据，如散列和代码签名。虽然不是明确的（这似乎与上一段相矛盾），但这些仍然是有效的技术，但它们必须在流程的早期执行，并在流程的每一步进行验证和重新验证。
除了这些静态工件之外，了解软件的代码执行流程和网络行为对于识别恶意功能也很有价值。例如，在 SolarWinds 的案例中，是行为变化（不一定是在代码审查中发现的任何东西）揭示了这种妥协。安全软件开发是一个包含多个阶段和许多妥协机会的过程。虽然零信任架构的概念是为身份和资源访问（例如应用程序访问控制）而设计的，但核心原则同样适用于安全软件开发。作为零信任核心原则的提醒，这些原则包括:
■ 用户和身份
■ 设备
■ 网络和环境
■ 应用程序工作负载
■ 软件供应链
■ 数据
安全软件需要在整个生命周期内采用多学科方法。虽然软件物料清单之类的技术是工具带中的一种工具，但它无法阻止诸如 SolarWinds 之类的复杂攻击。没有“一刀切”的安全工具可以解决这些问题，它需要彻底改变我们今天开发软件的方式以及我们在软件开发过程的所有阶段和整个软件供应链中管理信任的方式。交付代码的组织要对他们交付的所有代码负责，而不仅仅是他们编写的代码，这意味着上游输入的验证与他们自己的开发团队制作的软件一样重要，甚至更重要。
1.7 小结

在本章中，我们讨论了软件供应链威胁的背景以及攻击者的一些相关诱因。我们还讨论了软件供应链攻击的潜在结构。我们介绍了威胁建模的基础知识及其在防止软件供应链攻击中可以发挥的作用。最后，我们讨论了一些具有里程碑意义的软件供应链攻击，这些攻击影响了各种实体，例如专有软件供应商、OSS 组件和托管服务提供商 (MSP)。