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)，我们将在接下来的章节中深入讨论