2021年10月11日 | 威胁建模：为长远的物联网成功进行风险评估

物联网 (IoT) 应用将外围传感器、网关和云计算资源结合在一起，由于包含的潜在攻击面和安全漏洞数量众多，因而正成为网络攻击的前所未有目标。随着企业将这些物联网应用与其基础设施更紧密地联系在一起，更清楚地了解此类威胁、可能的攻击以及造成的影响变得更加紧迫。通过采用有条不紊的威胁和风险评估方法，开发团队可以在必要之处加强安全性，或者就可接受的风险做出明智决策。

连接系统中广泛存在的安全漏洞在新闻报道中频繁出现，即使是快速浏览头条新闻，也会发现攻击范围之广，这些包括从公开的大规模分布式拒绝服务 (DDoS) 攻击，到极其隐蔽的高级持续威胁 (APT)，它们甚至可以潜伏，并悄悄地提取有价值的数据，以便为更极端的攻击做好准备。

尽管这些漏洞攻击耸人听闻，但从中吸取的最重要教训之一是安全机制的采用和安全系统的构建并不是一回事。有些黑客成功地侵入了使用各种安全机制构建的系统，即使是最注重安全的开发团队也可能在不知不觉在设计中留下脆弱的攻击面。

当今许多设计的高度复杂性增加了对其脆弱面攻击的机会，尤其是对于物联网应用等多层连接系统。当大量不同类型的可编程设备连接到云端时，端到端安全性更多地是依靠统计概率而非绝对确定性。这种相互关联系统中的每个元素都为系统安全贡献了其特定的功能，同样也有自己的一组漏洞。通过充分了解每个漏洞如何成为对整个应用的威胁，企业可以判断攻击该漏洞造成的相关风险是否会超过可接受阈值，并决定最终是否需要某些缓解措施。

如果能够对风险的性质取得这种可预见性，则可以提供极大的战略价值。同时，通过将安全漏洞与风险评估相结合，开发团队可以设计一个战术路线图，以便防范这些针对连接系统几乎无休止的威胁，并进行实际响应。如果没有通过威胁和风险评估而获得更深入的理解，即使是最有经验的开发团队也只是在用他们系统和应用的安全性进行赌博。但是，要获得这些知识，首先要清楚地了解系统的潜在威胁，这可以通过记录良好的威胁模型来实现。

威胁模型会捕获与系统设计相关的特定安全漏洞。创建威胁模型在概念上似乎很简单，例如，开发人员通过分析他们的设计可以识别与每个底层组件相关的安全漏洞。然而，在实践中，威胁建模涉及更多的工作、研究和策略，可能比这个简单的概念想法所暗示的要多得多，并且可能会超出技术安全问题的范畴。通过更广泛地应用，威胁建模还可以识别相关生命周期过程中的漏洞以及与 IoT 应用相关的总体安全策略。最终，可接受的威胁模型可能会因它们所服务的物联网应用和机构而异，不同的威胁模型可能会共享某些特性，任何威胁建模方法都将遵循一些常见步骤。

威胁建模

威胁建模始于对系统的准确描述，即所谓的评估目标 (TOE)，它与特定用例（例如公用事业水表的操作）相关。如果威胁模型用来描绘系统漏洞的场景，那么 TOE 描述就是画布。通过扩大或收紧 TOE 范围，威胁建模团队可以扩大或缩小威胁识别过程的关注点。例如，Arm 的智能水表威胁模型（2018 年）对其 TOE 进行了严格限制，仅关注系统核心。

当然，如果将 TOE 限制在更大、更复杂的系统或程序的单个子集中，则意味着识别威胁、评估风险和制定有效缓解计划的能力同样有限。对于物联网应用等复杂的系统，经验丰富的威胁建模师可能会创建一系列威胁模型，涵盖从对整个系统的抽象描述，到对组织机构特别重要或需要关注子系统详尽信息描述。

无论采用何种方法，TOE 描述中都没有对详细程度的绝对要求。如果在建模方法中试图提供每个组件详尽无遗的细节，只会让流程中的参与者感到疲惫不堪。另一方面，过于抽象的模型可能会掩盖细微的漏洞，或不能识别深埋在依赖链路（chain of dependencies）以及第三方软件库中的漏洞。

一个有效的折衷方式是收集不断发展的细节水平，使其达到所需要的程度，并能够捕获所有跨越系统中独立、独特区域之间“信任边界”的交互信息。例如，一个物联网应用可以包含多个与云端资源、网关、物联网终端设备和用户相关的区域。跨越信任边界操作的交易特别容易受到对传输数据、安全凭证或协议的一系列特殊攻击，即便看似完美的跨越信任边界通信尝试也可能成为指纹攻击的一条路径，黑客可以使用系统响应中包含的已知特征来确定系统的底层组件，以便为更直接的攻击做准备。

当然，如果一些组件来自第三方，那么了解每个区域中底层组件之间的交互就变得尤为重要。例如，使用第三方传感器驱动器的 IoT 设备可能容易受到来自驱动器边界的威胁。

尽管适当详细的描述对于威胁建模至关重要，但识别与这些细节相关的特定威胁才是真正的回报。在 Arm 的水表威胁模型中，建模者提供每个资产相关威胁的简单语言列表，例如固件、测量数据以及可能涉及 TOE的外部实体（如用户、管理员和攻击者）交互.

对于固件，该模型描述了某些特定威胁，包括安装受损固件、修改用于验证固件更新的相关安全证书、克隆等。根据资产列表和已识别的漏洞，开发团队可以制定一组相应的安全目标和缓解方法。例如，Arm 的水表模型最后列出了一系列安全要求，包括固件要求，例如安全启动、固件身份验证、对身份验证失败的响应等。

可用资源

在识别潜在威胁时，很少（如果有的话）有开发组织能够及时了解可能适用于其 TOE 描述中包含的详细资产和流程的所有可能威胁，但好消息是工程师能够找到几个已发布的资源来帮助完成该过程。开发人员可以使用公共资源，例如常见的攻击模式枚举和分类 (CAPEC) 列表，自上而下地查看最可能的攻击类型。然后，他们可以自下而上地确定常见弱点枚举 (CWE) 名单中列出的可能攻击目标，CWE名单描述了系统设计方法中的固有缺陷，例如使用硬编码证书。在设计人员确定其设计中使用的特定硬件或软件组件后，他们可以参考常见漏洞和暴露 (CVE) 列表，其中列出了所用硬件或软件组件中的特定软件缺陷或潜在漏洞。

对于风险评估，通用漏洞评分系统 (CVSS) 等资源能够提供一种一致的方法，以便针对与特定漏洞相关的风险进行评级。尽管风险与特定漏洞的性质有关，但它还包括其他因素，例如用于执行攻击的路径（向量）、需要利用漏洞进行攻击的复杂性等。例如，通过网络执行的攻击比需要物理访问攻击带来的风险要大得多。同样，执行简单的攻击比执行高度复杂攻击带来的风险也要大得多。使用 CVSS 计算器，工程师可以快速考虑这些不同的影响因素，得出与具体威胁或某些类型威胁相关风险级别数值。对于 Arm水表用例，CVSS 计算器发现固件攻击所涉及的因素组合代表了 9.0 的关键风险评分。

由于实际应用中涉及的需求和技术范围广泛，因此业界有许多自动化工具可帮助开发人员完成建模过程，例如 Open Web Application Security Project (OWASP) 的 Threat Dragon Project、Mozilla的SeaSponge以及微软的威胁建模工具等。它们都采用不同的威胁建模方法，例如，从 Threat Dragon Project 和SeaSponge中的系统图表，到微软的详细 STRIDE（Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege，欺骗、篡改、否认、信息披露、拒绝服务和特权提升）方法。尽管这些工具已有数年历史，并且通常是为企业软件系统而构建，但威胁建模是一个广泛适用的常青过程，更多地依赖于当前的攻击向量、弱点和漏洞列表，而不是特定的方法。然而，目前也出现了一些新工具，它们有望在系统描述和威胁识别之间建立更紧密的联系。虽然深度学习技术在其他领域已经迅速兴起，但将这些技术应用于自动化威胁和风险评估仍然存在重大挑战。即便如此，智能建模和评估工具可能会很快出现。

与此同时，开发人员可以找到各种列出安全弱点、漏洞和攻击模式的完全集合，它们是如此之多，以至于所有可用的细节似乎都让人不知所措，尤其是对于那些刚刚开始从事威胁建模的开发人员，通常见到的用来规避威胁建模的借口之一是它太复杂了。但工程师可以从更简单的方法开始，只关注最常见的威胁，而不是跳到细节的最大深度。 OWASP 的 10 大物联网安全威胁列表提供了一个有用的出发点，开发人员只需访问他们首选的新闻网站即可找到顶级漏洞和漏洞利用的完备目录。

对于能够快速超越基础知识的机构而言，这些相同的方法在解决物联网设计中极其重要的安全问题方面被证明是非常宝贵的。机器设备控制回路中使用的系统通常面临与功能安全相关的关键任务要求，在这些系统中，安全和功能安全相互交织在一起，因此适合于这些系统的威胁模型可能需要包括这样一些场景，其中的安全或安全弱点同样会导致切实的风险。同样，安全和隐私在许多方面也重叠在一起，任何一方的弱点都可能导致披露个人身份信息的相同结果。

结论

在复杂系统中，威胁建模和风险评估的有效应用远远超出了任何可用选项和技术的简单列表。与每个特定系统一样，每个开发组织都有其所长，有其所短。一个系统或机构的需求可能完全不符合于另一个系统或机构，唯一的共同要求可能是首先需要进行威胁和风险评估。即便如此，企业是否应该尝试创建“完整”的威胁模型和风险评估？最简洁的答案是不，这样做的尝试或许达不到所期待的完美目标。

可以肯定的是，不可能完美地预测任何结果。因此，世界的混乱进程和系统努力减轻威胁以及黑客攻击之间潮起潮落，这些自然会最终影响任何追求完美的尝试。但同时，如果不构建威胁模型和利用风险评估提供的安全路线图，同样不可取，因为这样做不能避免任何安全漏洞的陷阱和弯路，导致一些不可避免的严重后果。