配备现代信息娱乐和远程信息处理系统的汽车拥有多种无线、软件控制接口，如全球移动通信系统（GSM）、通用移动通信系统（UMTS）、长期演进技术（LTE）、蓝牙（Bluetooth）或无线网络（WiFi）。此外，远程信息处理功能将无线连接与关键车辆功能（如灯光、发动机、制动或转向控制）相结合，以实现远程维护或紧急呼叫等功能。

这种从以专有软件技术为主的封闭式车辆系统，向开放式、网络化车辆信息技术系统的技术转变，使车辆在配置、隐私和未授权访问方面面临风险。

尽管将无线连接与安全关键型车辆系统联网所带来的风险和危害已得到广泛认可，但汽车电子和软件开发实践仍缺乏适当的标准、流程、方法和工具。

汽车安全风险可分为以下几个领域：

· 配置保护（Configuration Protection）：保护车辆配置数据免受未授权篡改

· 隐私保护（Privacy Protection）：保护存储在车辆中的客户数据免受未授权访问

· 访问保护（Access Protection）：保护车辆运行免受不必要的干扰和篡改

汽车电子电气系统（EE）开发中的网络安全工程旨在强化软件控制接口，防止未授权入侵（图 1 展示了汽车中典型的软件控制接口）。此外，嵌入式网络安全工程旨在通过应用授权和加密技术等方式，强化电子电气系统及电子电气网络，抵御未授权访问和篡改。由于许多电子电气系统承担着安全关键型功能，因此在电子电气系统开发过程中，需要协调并整合网络安全工程与功能安全工程活动。

                                         图 1、汽车软件控制接口示例

本文将阐释功能安全和网络安全标准 ISO 26262和 ISO 15408，并探讨其在车辆电子开发中的适用性，同时分析和讨论汽车电子开发中网络安全工程与功能安全工程的接口及重叠部分。针对当前流程中已识别的不足，提出解决方案构想，并给出总结与展望。

ISO 26262 作为车辆系统功能安全标准被引入汽车电子开发领域，这极大地改变了汽车行业对安全风险的认知和处理方式。ISO 15408 则是一套用于评估软件系统网络安全目标的标准，尽管该标准尚未针对汽车行业的特定需求进行调整，但已被应用于许多汽车中实际使用的标准软件组件。本节将简要介绍、讨论并比较这两项标准。

2.1 ISO 15408 的应用理念

ISO 15408（信息技术安全评估通用准则，CC）采用分层方法，指导和规范信息系统的开发、评估及针对特定网络安全目标的防护工作。其核心概念之一是将通用网络安全要求（网络安全功能要求，SFR）整合到软件系统类别的保护轮廓（PP）中。根据 ISO 15408 开发某一特定类别的软件系统，意味着需要纳入、实施并评估相应保护轮廓中的网络安全功能要求。为评估保护轮廓实施的可信度（评估对象，TOE），ISO 15408 提供了网络安全保证要求（SAR）。网络安全功能要求的实施将按照评估保证等级（EAL）确定的范围和方法（在网络安全保证要求中规定）进行测试和评估。简而言之，根据 ISO 15408，若所开发系统通过评估，则系统的可信度取决于所应用的网络安全功能要求和评估保证等级。

汽车软件密集型系统的网络安全目标可依据 ISO 15408 进行捕捉和保障。目前尚未存在针对汽车应用的通用网络安全目标和要求目录（例如远程信息处理功能的保护轮廓）。在实践中，需为每个具体案例制定并评估一套特定的网络安全功能要求和网络安全保证要求。制定汽车领域的保护轮廓将有助于简化并改进网络安全相关系统的开发。

为证明符合标准要求，需要由独立机构进行定期且标准化的评估。目前，针对汽车制造商和供应商的汽车电子开发专用评估方案尚未存在。

2.2 ISO 26262 的应用理念

ISO 26262 是汽车行业的一项标准，旨在确保汽车电子电气系统的功能安全。该标准界定了安全相关汽车电子电气系统开发和验证的当前技术水平，致力于预防或控制可能危及人体物理完整性和生命安全的系统性错误和随机错误。为此，该标准定义了一个流程模型，并基于预先确定的汽车安全完整性等级（ASIL），提出了分层的开发和保证任务模型。

ISO 26262 的关键措施包括危害分析和风险评估，通过这些分析评估可确定系统故障的潜在原因和影响。每个已识别的危害都会被标记为 ASIL A 至 D 级（非关键场景标记为 QM 级），这将决定后续开发活动的严格程度和投入力度。为此，需要对危险场景的严重程度、暴露时间和可控性进行评估。

ISO 26262 的另一个核心要素是安全概念，该概念由功能安全要求和技术安全要求集合构成，为每个已识别的安全危害制定了应对措施。这些应对措施既涉及开发流程（如质量评估和严格测试），也涉及产品的技术特性（如关键系统组件的运行时诊断）。

2.3 ISO 15408 与 ISO 26262 的应用

在实践中，网络安全工程与功能安全工程在很大程度上存在重叠。例如，当在具有安全关键型功能的控制设备中实施网络安全应对措施时，或者当向原本非安全关键型设备扩展远程信息处理功能并与安全关键型设备联网时，便会出现这种重叠情况（图 2 展示了汽车电子电气开发中网络安全工程与功能安全工程的应用领域）。

图 2、汽车电子电气（EE）系统中的网络安全与功能安全领域

如果在具有安全关键型功能的控制设备中实施网络安全应对措施，那么相关网络安全功能必须按照安全标准（如 ISO 26262）进行开发，因为这些网络安全功能可能会与同一设备上的安全关键型功能产生干扰。否则，必须证明其不存在干扰。

如果将与网络安全相关的非安全关键型功能 A 扩展为可与安全关键型功能 B 交互，则需要做出决策：若可行，安全标准是否也适用于功能 A；或者是否可以采用分离但协调的网络安全工程与功能安全工程活动相结合的方式。

除上述情况外，可单独应用安全标准或网络安全标准。

2.4 网络安全工程与功能安全工程方法

功能安全和网络安全工程领域均采用归纳和演绎分析方案，例如故障模式及影响分析（FMEA）或故障树分析（FTA）。从本质上讲，这两个领域的目标都是将系统运行过程中达到临界状态的概率降低到可接受水平。这两个领域的显著差异在于应用过程中所考虑的系统状态不同。此外，功能安全和网络安全工程方法的应用基于不同的前提、假设和限制，本节将简要解释并比较这些差异。

安全分析会在指定的系统行为基础上扩展故障状态进行研究。为便于解释，假设系统行为以有限状态机的形式进行指定。通过将失效模型应用于关键、易发生故障的系统组件，可确定一组有限的故障状态。由于 ISO 26262 要求全面探究指定行为，因此通常需要采用抽象和分区技术，将状态空间缩减到可行范围。为此，在安全分析过程中，可能会忽略事件的同时发生。此外，即使某些事件危害极大，但如果发生概率极低，也可能被忽略。因此，安全分析无需考虑组合事件和同时发生的事件，即使这些事件可能因恶意操纵而极有可能发生。对于已探究的故障到安全关键型驾驶场景的关键路径，必须通过在系统中部署特定应对措施来覆盖。此类应对措施的实施必须在严格的开发和质量保证流程中进行验证和确认（例如 ISO 26262 的要求）。

网络安全工程必须考虑通过系统接口可访问的完整系统行为，即指定状态和未指定状态。此外，必须考虑事件的同时发生，因为攻击者可能会以任意顺序、组合和时间节点生成事件。而且，必须假设攻击者会造成最大程度的破坏，因此无论某些关键攻击场景发生的概率看似有多低，都不应被忽略。当然，可以通过特定应对措施处理已知的攻击路径（如黑客攻击或漏洞）。然而，在大多数情况下，全面探究整个状态空间是不可行的，实际上在分析过程中可能仅能覆盖极小一部分状态空间。因此，网络安全工程师可能会决定采用通用应对措施（如防火墙），并根据网络安全要求对最终系统进行评估。如果评估发现严重缺陷，则需重复此过程；否则，可接受残余风险。

功能安全和网络安全工程方法在分析和评估方法的使用上有相似之处，但目标不同，且应用的前提和限制也不同。安全工程旨在确保系统按预期使用时不存在不可接受的风险，这将安全问题简化为探究指定系统状态和一组有限的故障状态。通过应用抽象和简化技术，还可以进一步缩减探究范围。与之相反，网络安全工程必须探究系统的预期使用和非预期滥用相关的漏洞。事实上，在大多数实际情况下，不存在能够全面探究系统预期和非预期行为的适当方法和工具。因此，网络安全工程往往会采用通用应对措施（如加密、授权、防火墙），并部署售后流程，以快速应对新的威胁和漏洞。此外，功能安全和网络安全应对措施可能存在冲突。例如，在嵌入式软件中部署加密和授权功能可能会消耗计算时间和内存。安全分析可能会发现，资源减少可能导致安全关键型系统状态，进而可能需要对系统进行大幅重新设计。尽早协调功能安全和网络安全工程活动，并采用全面的分析方法，有助于减少解决此类冲突所需的工作量和时间。

2.5 功能安全和网络安全的协调

在工业规模上开发与功能安全和网络安全相关的产品（如汽车电子），需要制定精确的工作模型，并明确网络安全工程与功能安全工程之间的接口。

基于前一节所述原因，可以认为需要建立分离的功能安全和网络安全工程流程、角色模型及接口。

本文提出了一个包含功能安全和网络安全工程接口的企业工作模型（如图 3 所示）。图 3 展示了同时进行的功能安全和网络安全工程任务的一部分，省略了中间的开发和验证活动。

图 3、功能安全和网络安全工程流程的协调

假设功能安全和网络安全工程任务是受管理的开发项目的一部分，包括适当的开发、质量、变更和配置管理活动。最初，应在时间安排、目标、接口和系统边界方面协调功能安全和网络安全工程活动。由于实际开发活动在时间安排和进度上通常会存在差异，因此应建立频繁的协调机制和变更委员会。

依据 ISO 26262 的安全工程遵循详细的流程模型，该模型包括多项分析、开发和质量保证任务。在开发过程的早期阶段，需定义系统功能的汽车安全完整性等级，并将其分解到系统组件中。对危害和风险进行分析和优先级排序，识别原因，制定、验证和确认应对措施。

依据 ISO 15408 的网络安全工程始于网络安全风险和危害分析，定义系统及其组件的评估保证等级。详细的原因分析可能会揭示攻击场景，需针对已识别的漏洞制定应对措施。由于 ISO 15408 未规定具体的开发活动，因此建议应对措施的开发遵循标准开发流程模型（如 ASPICE）。系统及已开发应对措施的评估将依据 ISO 15408，结合系统的评估保证等级进行。

需要考虑的是，安全危害和风险的原因可能在网络安全工程已推进到后续阶段时才被识别出来。某个关键安全风险的原因可能被确定为恶意操纵，这就需要将其作为额外的保护属性提交给网络安全工程，从而导致网络安全工程流程的回退。

此外，对系统及其网络安全应对措施的评估可能会发现残余风险，这些残余风险应作为安全危害的潜在原因提交给安全工程，进而导致安全工程流程的回退。

这种协调流程将极大地受益于对安全相关保护属性遭受恶意操纵的残余风险的定量评估。然而，此类风险的定量分析方法实施成本高且耗时。网络安全危害定量评估的方法和工具是当前的研究热点。对于实际应用，建议采用简化的残余风险估算和分类方法。此外，建立通用的优先级排序方案（如评估保证等级与汽车安全完整性等级的转换方案），可提高协调式功能安全和网络安全工程活动的效率。

2.6 总结

本文阐释了功能安全和网络安全标准 ISO 26262 和 ISO 15408，并讨论了它们在汽车电子开发中的应用。在功能安全和网络安全工程方法中，对系统使用、滥用、同时发生的事件、低概率事件的考虑以及应对措施的部署方式，是存在显著且必要的差异的。功能安全和网络安全工程活动应作为同时进行、相互协调的开发任务来开展。安全工程活动的输出可能会为网络安全工程提供额外输入，反之亦然。因此，本文提出了一种协调功能安全和网络安全工程活动的方法。

当前的研究旨在开发实用的风险量化方案和方法。此外，汽车电子电气组件的网络安全设计指南和保护轮廓将是我们未来的研究方向。