执行脱离上下文的威胁分析和风险评估

网络安全在嵌入式系统中越来越受关注，嵌入式系统曾经被认为与外部世界的威胁相隔离。车辆内部和外部组件之间不断扩大的互联性导致了复杂的操作环境和越来越多的攻击媒介。

汽车信息安全领域的标准ISO 21434在2021年正式发布，为沟通和管理网络安全风险提供了框架和通用语言。车辆不是一个单一的系统，它是由不同供应商生产的许多部件组成，主要部件本身同样由各种供应商生产的子部件组成，因此使用通用语言来量化、缓解并分担风险是必要的。

在本文中，我们将探讨:

• 将ISO 21434应用于通用软件组件;

• 执行SAFERTOS网络安全分析;

• 将威胁分析和风险评估 (TARA) 结果评估回馈到产品功能安全生命周期;

• 执行TARA获得的经验；

• 该过程的实际输出-SAFERTOS增强型安全模块。

1. 将ISO 21434标准应用于通用软件组件

ISO 21434承认供应链的存在，并试图解决标准对现成组件的适用性。

有两种方法可以管理第三方组件的使用，可以将其视为脱离上下文的组件(out of context)，也可以直接视为现成组件(off the self)。两者之间不是互斥的，它更多地与集成的方式有关，如图1所示。

1.1  现成组件

当选择使用现成组件时，由用户确定组件是否可以完成工作。

从网络安全的角度来看，需审查文档，确定是否可以满足分配的网络安全需求，确定组件是否适合在上下文中使用，以及现有的文件是否足以支持持续的网络安全观点。

如果现有文档不足以实现所需的网络安全目标，则需要识别和执行符合ISO 21434所需的活动。

1.2  脱离上下文组件

未假定特定应用场景开发的组件，称之为脱离上下文的组件，它可以部署到许多应用程序中。与现成组件的不同之处在于，供应商已意识到网络安全责任，并通过文档说明了预期用途、预期的上下文和外部接口的假设。

在这种情况下，供应商应根据文档假设生成并实施网络安全需求。在上下文中部署组件时，网络安全声明是有效的。

2. 执行SAFERTOS网络安全分析

对于SAFERTOS这样的组件，在最终用户应用的上下文中缺乏明确的外部接口。RTOS通过API为应用程序提供服务。如果组件供应商不知道应用程序的用途，它将如何部署，或者组件被破坏的后果是什么?

我们已经完成了SAFERTOS API的网络安全分析，识别弱点并将结果记录下来，归类为TARA过程的一部分，如图2所示。

图2 SAFERTOS网络安全分析

2.1  使用假设

对于脱离上下文的产品，一些假设是必要的，否则无法确定威胁边界。对于SAFERTOS，假设与处理器的功能和配置以及SAFERTOS在整个系统中的位置相关。

1)启动过程中的漏洞

在应用开始运行时初始化并启动调度程序。部署模型是SAFERTOS直接链接到主机应用，这意味着SAFERTOS不能减轻与启动过程相关的威胁，因此假设使用加密的启动过程。如果固件在源头遭到破坏，则软件组件无法减轻威胁。

2)处理器架构

为了在安全环境中提供分区或保护，RTOS需要MPU或MMU单元。假设模块存在，由SAFERTOS支持，并且根据SAFERTOS安全手册进行配置。

我们假设主机架构至少支持两种特权级别:特权模式和非特权模式。特权模式允许访问所有数据区域。

3)部署

SAFERTOS是作为未知硬件环境中未知应用程序的一部分部署的，因此假设与直接物理访问相关的所有威胁都不在组件的范围之内。

在初始TARA过程完成之后，这些假设在TARA中记录，并归类为“分担”需求。

2.2  定义组件上下文及范围

该过程的关键是确定威胁边界。作为一个通用的软件组件，不适合使用通信总线或外部接口来描述，我们将SAFERTOS内核与主机应用之间的接口作为威胁的边界(图3)。在某些情况下，应用代码通过hook函数或API与RTOS接口。在其他情况下，接口在内核及应用访问数据对象时形成。

图3 在SAFERTOS中定义威胁边界

2.3  执行脱离上下文的TARA分析

1)资产识别

对SAFERTOS来说，跨越威胁边界的接口被认为是资产。在网络安全上下文 (图4)中，跨越威胁边界的每个接口都被视为TARA实践的一部分。

图4 TARA过程

2)威胁场景识别

资产可以具有多个网络安全属性，存在多个框架。我们选择STRIDE (欺骗、篡改、拒绝、信息披露、拒绝服务、特权提升) 模型，针对每个威胁场景考虑每个资产 。

3)影响等级

仅考虑通用组件如SAFERTOS时，无法对攻击的安全(Safety)、财务(financial)、运行(operational)和隐私(privacy)后果做出判断，只有了解应用才能正确地评估。一旦坏人进入，几乎所有的攻击路径都允许流氓任务获得特权，将导致严重的系统退化。

由于损害的种类不能脱离上下文确定，所有风险被归类为影响所有类别。

4)攻击路径分析

考虑了每个威胁场景，以确定攻击是否可行，这是确定攻击成功可行性的关键输入。

5)攻击可行性评级

以数字值描述攻击路径的五个属性(专业知识、机会之窗、设备/努力、需要的时间和了解程度)，并将这些数值结合起来，以确定攻击可行性的带状评级。

1、专业知识：假定没有防火墙或安全通信等。它从门外汉等级到了解整个系统的通信接口以植入非法任务或篡改主机内存;

2、机会之窗：与外部环境连接(CAN总线到无线和远程方式)的程度未知。因此，机会之窗被视为无限，即对组件的访问没有限制。

3、设备/努力：设备访问接口被假定为“标准”-手机或笔记本电脑，但要运行专门为黑客攻击(穷举搜索、字典攻击)开发的软件。

4、需要的时间：开发一个方法所需的时间，应≤1天;

5、了解程度：WHIS提供的文档受到限制，但不能假设集成方有文件控制措施。因此，该项目的知识必须被认为是任何人都可以免费获得，即“公共的”。

6)风险值确定

潜在风险发生的影响是无限的，因为如果不知道系统的范围和上下文，所有损害都可能发生。在此基础上，所有威胁造成的影响都被视为“极其严重”-最大风险值。

7)风险处理决策

根据每个识别的风险，做出处理决定。许多风险被确定为“分担”，只能通过部署和配置SAFERTOS的方式来减轻。一些风险可以通过在产品中提供额外的保护措施来减轻风险，被归类为“降低”。

由于主机应用引入系统的特权代码，其中的风险不能减轻，必须接受。

3. 将结果反馈到产品功能安全生命周期

分类风险建立后，需要将发现和更改重新引入与ISO 26262兼容的安全关键产品中。将每个已识别的风险需采取的行动记录到网络安全目标中。

通过网络安全目标，确定并记录功能安全需求和集成需求。然后将网络安全需求引入功能安全流程，如图5所示。

工程团队精通功能安全需求管理，因此功能安全和网络安全需求的集成非常容易。

图5 网络安全、功能安全与功能需求的集成

4. 执行SAFERTS安全分析获得的经验

这个过程中最困难的部分在开始阶段：

• 在未达成上下文定义的情况下尝试TARA流程是不可能的。如果开发脱离上下文，应该基于一个典型的汽车用例，以允许合理地识别资产和可能的威胁。本文中呈现的背景是几次错误尝试的结果，但一旦上下文确定，资产和威胁就可以被识别；

• 资产定义可能很困难，过高的级别无法识别所有威胁。考虑一个独立的元素时，过多专注于实物资产也会产生误导;

• 对脱离上下文的元素的攻击可行性、影响等级和风险值的确定，我们决定做最坏的打算，但这也存在问题，因为它可能导致你认为需要进行不切实际的渗透和模糊测试;

• 对于脱离上下文的元素，会有分担的威胁，这些威胁只能通过应用采取行动或以许可的方式使用和配置产品来缓解，我们的目标是尽可能把这一点说清楚。

5. SAFERTOS增强型安全模块

TARA过程的最大成果是SAFERTOS增强型安全模块(ESM)。即使在使用MMU或MPU内存保护机制时，API的性质使受损的任务可以很容易地损害整个系统。为此，SAFERTOS提供了增强型安全模块，为应用程序开发人员提供了更多工具来限制单个任务的行为，如图6所示。

SAFERTOS ESM依靠硬件支持，通过MPU或MMU来强制将数据和代码分配到指定区域，允许任务到任务和任务与内核的空间分离。SAFERTOS ESM包含一个上层API封装模块，该模块针对SAFERTOS API执行对象句柄模糊、API访问控制策略和对象访问控制策略。它还需要一个安全感知的可移植层，以确保任务上下文数据的安全性，并在任务和内核执行之间提供最紧密的API边界。这些元素一起工作，提供了一个强大而安全的实时操作系统。

仅靠ESM并不能保证嵌入式应用程序的安全性。它需与其他安全保护机制一起使用，例如安全启动(信任根)，通信通道的安全密钥和加密，以及由硬件设计或物理使用限制驱动的物理安全技术。

图6 SAFERTOS和ESM

随着车辆变得更加互联以及自动驾驶汽车的逐渐增加，以网络安全的思维来设计和实施汽车软件变得至关重要。SAFERTOS基于威胁分析和风险评估方法，推出了SAFERTOS增强型安全模块，提供了一种降低互联汽车部件风险的结构化方法。