商业领域的IT系统和嵌入式产品的IT系统正在融合为一种多功能系统。相应地，关注汽车网络安全的ISO 21434标准应运而生。该标准的意义在于提供了一个指南，可用于降低产品、项目和组织中存在的安全风险。为了有效实施ISO 21434标准，本文介绍了遵循ISO 21434的系统级安全工程实践方法，并通过实例进行分析。
汽车网络安全风险
汽车网络领域的犯罪正在急剧增加。在过去几年，网络犯罪的投资回报发生了巨大变化。通过应用勒索软件，如今的网络犯罪比毒品交易更加有利可图。据估计，网络犯罪每年造成的损失高达6000亿美元，而毒品交易的同期金额是4000亿美元[1]。由图1可见，网络攻击几乎呈现出指数增长的趋势[1]。
01 报告的针对车辆的严重网络安全攻击
网络犯罪的影响是多方面的，例如改变车辆功能导致车辆意外行为、操纵数据和软件导致故障，或通过DOS攻击和勒索软件破坏常规功能等。在上述所有网络攻击场景中，对于制造商发布的各种组件，其质量不再能够得到保证，而这也意味着车辆不应该继续在道路上行驶，因为车辆本身已成为安全风险。显然，没有网络安全就无法达到功能安全。为应对汽车网络安全的挑战，主机厂和供应商必须对整车的电子电气系统进行有效保护。
以风险为导向的网络安全管理方法
面向风险的网络安全管理方法会将安全需求、设计决策以及测试联系起来[1, 2, 3, 4]。为实现安全性，在车辆开发过程中需要考虑以下事项：
> 对于面向完整开发过程的系统级流程，需要流程模型来对其进行标准化。这一流程模型应当从需求分析开始，覆盖设计、开发以及组件和网络的测试环节。
> 通过快速的软件更新来修复ECU软件中的漏洞。
> 使用最先进且满足长期安全需求的可靠协议。由于这些协议通常要用到加密密钥，因此，必须要实现覆盖车辆全生命周期的密钥管理。
> 车载网络和系统架构必须具备灵活性和可扩展性，其在设计时应当充分考虑网络安全问题。
以风险为导向的网络安全管理方法，有助于平衡日益严重的网络安全威胁与产品在全生命周期中日益增加的复杂性。而在网络安全的概念设计阶段，要对遭受攻击造成损失所带来的成本与产品全生命周期进行安全加固所产生的成本进行平衡。图2显示ISO 21434所要求的以风险为导向的网络安全方法。
02 面向风险的网络安全分析流程
ISO 21434 标准概括
在2021年发布之前的几年，ISO 21434已经成为汽车网络安全领域的重要参考。由于传统的信息安全标准主要关注管理和商业信息系统，对车辆场景下的安全问题指导意义有限。因此作为ISO 21434标准的最初起草者之一，Vector Consulting长期投入到ISO 21434标准的起草工作之中。
ISO 21434基于以风险为导向的方法，明确区分了产品、项目和组织级别的措施，并与ISO 26262密切相关。与ISO 26262相比，ISO 21434更加抽象：既没有规定任何具体的技术、解决方案或补救方法，也没有对自动驾驶汽车或道路基础设施提出独特的要求。这是为了避免安全标准对产品造成过度约束。另一方面，虽然ISO 21434涵盖最先进的网络安全原则，但并没有为实施过程提供太多的指导。因此这一标准将随着时间的推移而不断扩展。
ISO 21434问世后，人们常常难以分辨ISO 21434与SAE J3061的区别。事实上，几年前SAE J3061曾被作为汽车网络安全问题的短期修复方案。但由于多方面的原因，ISO 21434在发布后已直接取代SAE J3061。乍看之下，这两个标准的高层面安全流程大体兼容。其中SAE J3061在附录A中介绍了威胁和风险分析（TARA）的各种方法。而ISO 21434提供了一个与功能安全解耦的网络安全流程，它只关注网络安全。而且为了提高效率和减少冗余，ISO 21434引用了ISO 26262，并与之共享一些方法。总之，ISO 21434对网络安全的工作产品、组织和方法（如TARA）的要求更为精确。Vector Consulting的经验表明，如果已经成功应用了SAE J3061，那么可以很容易地切换到ISO 21434。
ISO 21434可用于构建网络安全管理系统（UNECE R.155 CSMS），包括网络安全风险管理和治理。其中，组织层面的活动主要是建立所需的网络安全管理条例，并在公司中灌输网络安全文化。这还应包括在不同项目团队之间建立信息共享系统，采购所需的新网络安全工具并提供培训。组织应重新评估现有的IT安全系统并计划组织层面的审计。
根据ISO 21434，要开展项目层面的活动，首先需要一个定义明确的管理系统，在项目中明确定义角色和职责。通过应用诸如Automotive SPICE（ASPICE）这样的流程框架，可以满足ISO 21434标准对于流程方面的大部分要求。在实践中，Vector Consulting在功能安全、网络安全和ASPICE领域识别到了一些相似的弱点，比如项目团队在需求工程、可追溯性、测试方法、项目管理和风险管理等方面通常存在不足。
ISO 21434标准建议，在网络安全规划之初，就应当清晰地定义相关角色和职责。同时，ISO 21434还包含了使用复用组件，引入第三方组件，直接使用像开源模块这样的非市场流通组件等的指南。最后，ISO 21434还提供了在项目层面进行网络安全评估的相关信息。
03 ISO/SAE 21434:2021 结构（来源： ISO ）
基于 ISO 21434 的安全工程实践
本节通过一个简化后的ADAS客户项目案例，展示如何在实践中逐步应用ISO 21434。虽然示例经过简化，但意义在于介绍安全工程。
第 1 步：相关项定义
相关项定义不仅是确定元素边界所必须的，而且一直都是定义系统资产所需的重要参考。在该案例中，广义的相关项就是整个ADAS系统，其顶层网络架构如图4所示。
04 ADAS 网络架构示例
简单起见，假设所有通信都通过CAN总线完成。对于外部接口，要根据底层架构来识别。该系统可通过4G网络与OEM云基础设施进行通信，并拥有可连接到网关的OBD接口。
第 2 步：资产识别
下一步是识别并列出相关项中的所有资产。在选择资产时，要基于其价值或受到损害时的风险等，比如功能安全目标、财务风险、运营成本和隐私等。以下是ADAS系统的资产示例：
> A1：ADAS接收或发送的网络报文
> A2：ADAS软件，包括安全机制
**>**A3：安全密钥
> A4：驾驶历史和记录的数据
第 3 步：威胁分析和风险评估
基于已经识别出的资产，下一步要进行TARA分析。通过TARA可以系统性地分析在受到攻击时威胁所带来的影响程度，以及实现攻击的难易程度。然后结合影响等级和攻击可行性等级，按照从1（非常低）到5（非常高）的尺度来划定风险等级。之后，根据风险等级的高低来计划和实施进一步的风险应对措施。除此之外，ISO 21434还建议按照从CAL1（低）到 CAL4（高）的尺度，对每项资产划定网络安全保障级别（CAL）。
示例中，我们列出了一些针对已识别资产的攻击，以及相应的威胁，资产和威胁都各自有专属ID。以下是一些攻击路径的示例：
> A1-AT1：车辆制动相关报文被阻塞；
**>**安全机制（即手动接管期间无车道保持）遭到破坏，无法正常工作。
在此基础上，可识别出相应的威胁，即：
> A1-AT1-T1：尽管驾驶员踩下制动踏板，但车辆不制动（危害：如果制动失效，可能引发事故并造成伤害）
> A2-AT1-T1：手动接管期间保持车道（危害：因接管失败而造成重伤）。
表1显示了根据识别出的攻击内容和威胁场景进行评估所获得的攻击可行性等级和影响等级，进而判定出风险级别和网络安全保障级别（CAL）。
表 1 TARA 分析示例
第 4 步：安全目标和安全要求
为了降低风险，要根据风险可能造成的影响来识别和评估安全目标。安全目标是高层面的安全要求。从每个安全目标出发，可以衍生出一个或多个功能级安全要求，而对于每个功能级安全要求，又可以衍生出一个或多个技术级安全要求。在这个例子中：
> 安全目标：A1-AT1-T1-SG1：系统必须阻止对驾驶员辅助系统所发送消息的操纵行为。
> 功能级安全要求：SG1-FSecR1：必须确保驾驶员辅助系统和传感器之间通信的完整性。
> 技术级安全要求：SG1-FsecR1-TSecR1：MAC应由符合安全硬件扩展（SHE）的硬件信任锚（HTA）使用算法RSA2048计算获得。SG1-FsecR1-TSecR2：MAC值应在x字节后进行截断。
第 5 步：可追溯性
可追溯性有助于保持一致性并降低责任风险。即使在发生变更，增量构建或持续构建的过程中，可追溯性对于确保覆盖率和一致性也是必不可少的。
图5展示了将需求、设计和测试相关联的一种抽象模型。在应用该模型时，设计者从负面需求（即黑客的需求）开始，提炼出解决方案以降低这些攻击的可行性，进而确保从初始TARA分析结果和安全要求定义出发的追溯关系的完整性。
05 网络安全可追溯性
第 6 步：设计
由于在安全相关资产的TARA分析中发现了相应风险，因此ADAS系统需要在设计上进行变更来应对这一风险。根据安全目标SG1，系统必须具备识别和预防机制来避免攻击者对网络信号的操纵。通过落实功能级安全要求和技术级安全要求，可设计出相应的识别和预防机制。
在落实安全要求的过程中，硬件设计可能会相应地发生变更。在本文所研究的案例中，必须使用HTA。同时，通过应用MISRA和CERT提供的指南进行安全编码，可以避免设计和代码错误可能导致的安全漏洞。应当始终牢记，大多数攻击得逞的原因是设计不足，而非密码学的限制。
第 7 步：集成和验证
该步骤的主要目的是验证实施和集成的安全机制是否满足网络安全目标和要求。为实施这一步骤，推荐以下具有相互依赖性的典型方法：
> 单元级验证：静态和动态代码质量分析侧重于MISRA和CERT等安全编码指南以及单元级鲁棒性。自动工具用于执行代码质量分析（CQA）并生成测试报告。
> 功能测试：基于需求的测试有助于识别系统设计和架构中的基本缺陷。在该案例中，对最初在相关项定义中描述的实际功能进行了系统级别的测试，以确保功能表现不会因为额外的安全措施而受到损害。
> 模糊测试：模糊测试用于测试超出预期范围和边界的各类车辆通信协议。
> 渗透测试：渗透测试是在组件和系统级别上独立执行的测试策略。灰盒渗透测试[5]因其高效率和有效性，已被证明能够实现这一策略。
第 8 步：开发后阶段
在开发阶段，除了做好充分的测试，也必须为开发后的活动做好相关准备。这包括相关项的生产、运行、维护以及最终报废。因此需要为这些活动预留预算、时间和能力储备，比如紧急事件响应团队、安全警报通知和软件补丁交付等。该阶段可分成以下几个环节：
> 生产：在相关项的制造和组装过程中，必须遵循一些网络安全要求。例如，在这个案例中，对于在下线阶段向HTA的内存中注入供应商或OEM关键材料的过程，应当进行充分的计划和处理。
> 运营和维护：作为持续网络安全活动的一部分，每个组织都需要维护一个独立的项目监控团队。当网络安全事件触发时，运营团队必须按照预先定义和商定的网络安全事件响应计划来进行事件响应。
> 报废：报废过程与网络安全密切相关，因为相关项可能包含需要安全处置的信息。
结论
随着车辆信息系统与企业信息系统在开发、生产及运营阶段的融合，汽车网络安全相关问题日益显著[1, 2, 3, 4]。由于汽车网络安全是功能安全的先决条件，因此必须全面而系统地应对网络安全问题。ISO 21434为汽车网络安全提供了一个框架，但它还不是指南，不能直接用于定义开发过程。因此，在应用ISO 21434时需要强有力的指导来有效且高效地进行实施。对未来需要在法律诉讼中证明安全措施有效性的场景，尤其如此。
网络安全不仅仅是一个安全团队的职责，更是每个工程师的责任。网络安全需要一个整体方法去应对，即以系统工程的方式深化落实，并在整个产品生命周期中建立完整的追溯关系。