一、ISO 21434 的诞生背景
在智能网联和自动驾驶相关功能引入到汽车领域之前，功能安全工程一直是重中之重。因此，功能安全方法和过程也是汽车行业标准和发展的关键部分。如今，随着各种智能网联汽车和自动驾驶汽车的出现，汽车连接性功能、车辆维护和交通安全信息共享等变得越来越普及，同时也增加了不同动机的黑客攻击车辆的可能性，从而给车辆网络安全带来了新的风险。

考虑到汽车网络安全所面临的新挑战，相关从业者们需要努力通过新的工程方法和特殊技术手段来应对车辆整个生命周期中出现的威胁、风险管理、安全设计、意识和网络安全问题。因此，安全可靠的智能网联汽车的生产和设计已成为行业焦点。在解决汽车网络安全的问题上，尽管可以借鉴其他领域的经验，但是，汽车行业所面临的”专属挑战“仍不可避免。

于是，汽车行业意识到需要通过特定的行业标准来解决汽车网络安全问题并保护个人资产。国际标准化组织（ISO）/美国汽车工程师学会（SAE）近期联合起草发布了“ ISO / SAE DIS 21434道路车辆-网络安全工程”国际规范。从汽车行业的角度来看，该标准就产品开发和整个供应链设计的安全性方面达成了共识。

二、已发布的功能安全和信息安全框架
功能安全和信息安全往往相互密不可分，二者都专注于系统级功能且彼此的定义和过程相互关联。

功能安全标准
安全工程已经成为汽车工业和安全标准不可或缺的一部分。例如，在汽车工业中已经建立了道路车辆的功能安全规范ISO 26262及其基础规范IEC 61508；在汽车开发过程中也指定了标准化的安全分析技术，如故障模式和影响分析（FMEA）和故障树分析（FTA）等。

IEC 61508 Ed 2.0提供了综合功能安全和信息安全的一种方法。在该方法中，危害分析的过程应将安全威胁考虑在内。但是，标准中并未详细地指定某个特定的威胁分析，且Ed 3.0需要就安全意识的问题给出更详细的说明。

2018年底发布的ISO 26262 Ed 2.0就功能安全与信息安全之间相互作用提出了更多建议。具体来说，针对如何在汽车标准化中处理功能安全和信息安全进行初步讨论之后，给出了单独的功能安全与信息安全之间相互作用标准。ISO 26262：2018的附录E从管理、协调计划、项目进度、现场监督等方面提供了有关功能安全与信息安全之间相互作用的其他指南。在概念形成阶段，着重于处理HARA与TARA之间的相互作用以及对策之间的协调。在开发阶段，重点是连续分析和确定各标准之间的潜在影响。此外，附件总结了生产阶段功能安全与信息安全的交互作用，并给出相应的指导。

信息安全标准

SAE J3061 是ISO / SAE 21434的前身，该指南通过以下方式为网络安全建立了一套高级指导原则，包括：

–定义完整的生命周期流程框架
–就常见的现有工具和方法提供相关信息
–给出信息安全的基本指导原则
–总结下一步的标准制定

SAE J3061指出，信息安全有一个适当的生命周期，该周期的定义类似于ISO 26262中描述的流程框架。此外，对于功能安全和信息安全，是要使二者维持在同一安全水平上且相互独立，还是要使二者的过程互相集成，在这点上并没有限制。

该指南还建议对潜在威胁进行初步评估，同时对与信息安全相关或关联的系统进行风险评估，以确定是否存在可能导致违反安全规定的信息安全威胁。基于此，发表了有关SAE J3061应用的报告。

尽管其他标准（例如IEC 62443 或ISO 27000系列）并不是直接针对汽车系统的，但这些标准涉及到汽车的生产和后端系统。

在ISO 26262（2011）和SAE J3061的背景下，本文回顾了适用的威胁分析方法以及SAE J3061指南中对于威胁分析和风险评估方法（TARA）的建议。除了对适用分析方法以及提出的威胁分析方法进行评估之外，本文还根据ISO 26262（2011）和SAE J3061对复杂汽车系统的功能安全和信息安全相关方面的信任边界和攻击向量识别进行了研究。本文提出了一种在现有的ASPICE环境中用于集成信息安全和功能安全工程的结构化方法。

除此之外，本文介绍了ISO / SAE 21434的发展和现状。基于威胁模型的安全分析工具和一种名为RISKEE的网络安全风险评估方法，提出了新的安全分析工具—ThreatGet。该方法能够通过攻击图和钻石模型并结合FAIR来评估和计算风险。同时，探讨了正在进行的安全系统开发，审查了方法指南的现状，并首次对将网络安全与现有流程融合进行了评估。

三、ISO/SAE DIS21434

2016年1月，《信息物理汽车系统网络安全指南SAE J3061》第一版发布，这标志着从2016年9月起，ISO与SAE开始合作来共同制定道路车辆网络安全标准。这套标准（ISO/SAE 21434）的目的有三个，分别是：(a)确定一个结构化的流程，以确保信息安全设计；(b)实现降低攻击成功的可能性，减少损失；(c)提供清晰的方法，以帮助车企应对全球行业共同面对的信息安全威胁。

如前所述，ISO/SAE DIS 21434主要应用于公路车辆，重点是制定汽车信息安全工程的最低标准。该标准没有给出信息安全技术、解决方案或补救措施的具体内容，也没有给出对自动车辆或道路基础设施的特殊要求。鼓励采取以风险为导向的方法来确定行动的优先次序，该标准还提出了信息安全措施。

3.1、ISO/SAE DIS 21434 的结构和章节

ISO/SAE DIS 21434侧重的关键原则是车辆生命周期所有阶段的信息安全活动；从设计和开发、生产、运行和维护到车辆报废。本节将对ISO/SAE DIS21434草案的结构进行分析和简述。

3.2、ISO/SAE DIS 21434 第4节：一般考虑因素

本节介绍了车辆生态系统、组织信息安全管理和相关的汽车生命周期。汽车信息安全是指保护车辆中的所有资产免受信息安全威胁。因此，汽车信息安全是基于(a)对车辆或车辆部件的威胁，(b)对生态系统的威胁，这种威胁针对的是利用了车辆内部的漏洞对车辆以外的资产产生的威胁。此外，该标准提供了信息安全管理和信息安全生命周期的一般组织概述。

3.3、ISO/SAE DIS 21434 第5节：信息安全管理

本节的目的：

a. 说明企业组织在信息安全方面的目标和实现这些目标的组织战略b. 规范企业组织所实施的信息安全策略、规则和流程c. 指定网络安全工程的职责和相应的权限d. 提供所需的资源e. 培养信息安全文化f. 管理需要执行信息安全活动的能力g. 实施持续改进h. 进行组织信息安全审计i. 管理信息安全过程之间的交互

在标准的第5.1.4.7段详细说明了信息安全过程与组织内现有的过程之间的交互。本节中还阐明信息安全、功能安全、隐私和与实现信息安全等应与其他标准，比如信息安全和功能安全之间有有效的沟通渠道，以交换相关信息（如威胁和危险信息、违反网络安全目标或安全目标的情况）。关于这方面，SAHARA方法也是同样的目的。

在标准的第5.1.4.6段描述了信息安全审核的要求，该段指出应进行信息安全审核，独立判断企业导入信息安全的过程是否实现了本标准的过程相关目标。该段还指出，独立性方案可以基于汽车SPICE、IATF 16949与ISO 9001或ISO 26262进行。

除此之外，还对概念阶段和产品开发(第5.2段)以及生产、运行和维护(第5.3段)期间的信息安全管理作了一般性说明。其中还包括为再利用(5.2.4.2.2)、系统或组件的非正常开发(5.2.4.2.3)和现成开发(5.2.4.2.4)而定制信息安全活动。

3.4、ISO/SAE DIS 21434 第6节：风险评估方法

本节中包含了一个风险管理方法介绍部分(6.1)说明的很详细。该段一般涉及组织层面的风险评估，但没有说明任何具体的风险评估方法，也没有提出应采用的方法。如果你想了解应采用什么样的方法来做风险评估。

SafeComp2016会议上分析了一些可能的在汽车领域的适用性的TARA分析方法，此外，近期有研究学者提出了一种应用定量信息安全风险评估方法实现协调风险管理的解决方案。该方法用一个综合模型扩展了既有的安全保障风险分析方法，用于说明攻击者和受害者之间的关系，包括攻击的能力大小和基础设施。该模型用于估计抵抗强度和威胁能力，以确定攻击概率和安全风险。其他相关方法有EVITA方法、HEAVENS模型和威胁矩阵方法。如上文提到的，网络安全中的风险评估方法称为RISKEE，是基于攻击图和Diamond模型，然后再结合FAIR方法进行风险评估和计算。在结构化威胁分析和威胁建模方面，将会描述所介绍的用于安全分析的ThreatGet工具。

第6.2段涉及资产识别，因此侧重于(a)资产，(b)其安全属性（如CIA）和(c)在其安全属性丧失的情况下的损害情形（如安全、财务、业务或财务影响）。为此，应确定候选资产和潜在的损害情景，并对潜在的损害情景进行影响分析；这里没有提出具体的方法或办法。

接下来的几段描述了威胁分析（6.3）、影响评估（6.4）和脆弱性分析（6.5）。威胁分析的目的，是确定可能损害物品安全特性的威胁情况。此外，影响评估还可以评估特定损害情景的影响或损害程度。影响是指利益相关者（如道路使用者或企业）将经历或最终承受的事情。脆弱性分析的结果是：(a) 列出安全漏洞，(b) 区分缺陷和弱点，(c) 将这些安全漏洞与攻击联系起来的攻击路径。

第6.6段描述了攻击分析的目标，即制定和/或更新一套可被利用来实现威胁情景的攻击路径。对这些攻击途径的可被利用性的评估是攻击可行性评估的主要方面（第6.7段所述）。

最后，风险评估(第6.8段)和风险处理(第6.9段)涉及对已查明的威胁情况进行分类(根据影响和攻击的可行性)和选择适当的风险处理方案。

3.5、ISO/SAE DIS 21434 第7节 - 概念阶段

该标准的这一节描述了正在开发的系统是否与信息安全有关(第7.1段)，确定信息安全背景下的项目定义(7.2)，以及在概念阶段启动产品开发(7.3)。本节中还包括与ISO 26262方法相一致的信息安全目标定义（7.4）和信息安全概念（7.5）。在此，需要特别提到该方法与SAHARA方法的联系，SAHARA方法是最早将安全HARA分析映射到信息安全挑战上的方法之一。

信息安全目标的项目定义和挖掘与ISO 26262中已知的安全相关方法非常一致。信息安全概念同样由ISO 26262中的信息安全要求组成，这些要求实现了信息安全目标，并在适当的架构层次上进行了分配。

同时，信息安全的概念中也包含了信息安全要求。通过独立实施的方式来实现信息安全目标。

3.6、ISO/SAE DIS 21434 第8节 - 产品开发

本节标准描述了其余产品的开发阶段。第8.1段中所述的系统开发阶段，可与ISO 26262第4部分相联系，硬件开发阶段（第8.2段），可与ISO 26262第5部分相联系，软件开发阶段（第8.3段），可与ISO 26262第6部分相联系。另外，8.4段是关于验证和确认，8.5段是关于开发后发布。在此背景下，文献《Security Application of Failure Mode and Effect Analysis (FMEA)》中提出了一个称为FMVEA安全主题FMEA应用。

同时，在该文献中还提到了在系统开发的各个阶段的不同风险评估活动类型，但没有详细说明类型种类；该文献描述了在概念阶段对项目及其运行环境的威胁进行评估，在系统开发阶段对造成残余风险的系统规范漏洞进行评估和对造成残余风险的系统集成漏洞进行评估。但是该文只提到了系统开发应规划确定系统开发和信息安全活动的方法和措施。

第8.1.4.2.2.3条提到以下信息安全设计的最佳做法：

1. 最低特权原则2. 认证3. 授权4. 审核5. 端到端安全6. 架构信任度（接口的隔离、防御的深度）7. 接口隔离(以便进行适当的网络安全分析)8. 保护服务期间的可维护性（测试接口、OBD）9. 开发过程中的可测试性(测试界面)和运行过程10. 默认的安全(简单、不复杂、不依赖专家用户)

此外，系统集成应结合适当的方法进行验证和测试，即(a)基于需求的正向和反向测试，(b)接口测试，(c)渗透测试，(d)漏洞扫描和(e)模糊测试。对于硬件设计，应考虑以下确保信息安全功能的机制(条款8.2.4.3.3)：

-设计信息安全领域(领域分离)

-安全功能自我保护

-防绕过安全功能

-确保安全功能初始化

此外，与信息安全有关的硬件元素的所有物理和逻辑接口，应按其目的、用途和参数加以识别。由于接口是网络安全攻击的潜在切入点，应作为脆弱性分析的投入。

对于信息安全相关的软件开发，必须从系统信息安全需求中推导出软件信息安全需求，并分配到软件模块。软件单元设计规范及其实现需要进行静态和动态验证。因此，应考虑安全设计规则和编码准则、域分离、自我保护、非旁路特性和安全初始化定义。第8.3.4.6.5段规定了软件单元设计和源代码级实现的设计原则。该段中还提到了(a)子程序和函数的正确执行顺序，(b)接口的一致性，(c)数据流和控制流的正确性，(d)简单性、可读性和可理解性，(e)鲁棒性、可验证性和适合软件修改的特性。

3.7、ISO/SAE DIS 21434 第9节 - 生产、操作和维修

为了确保开发中的信息安全规范在生产的项目中得到落实，和确保落实过程防止引入更多的信息安全漏洞，本节主要介绍了生产方面(第9.1段)。信息安全监控（9.2段）要有收集相关信息安全信息和审查网络安全信息的流程，此外，为了介绍如何处理信息安全事件和更新基本的息安全要求和能力(9.4)，本节中还提到了处理和事件应对(9.3)程序。

3.8、ISO/SAE DIS 21434第10节- 支持性程序

本节所述流程支持信息安全活动，并界定了客户和供应商之间的交互、依赖关系和责任。该流程包括描述客户和供应商之间的关系以及工具管理(10.4)的管理系统(第10.2段)、分布式信息安全活动(10.3)。虽然没有提到用于开发过程的标准工具，但在信息安全工具的工具鉴定方面，还是有少量提到ISO 26262、IEC 61508、DO-178B等安全标准。