内容提要：本篇将继续对ISO 21434每一节中的内容详细解释。

《ISO 21434汽车网络安全标准概述（上）》对ISO/SAE DIS21434草案的结构进行分析和简述，本篇将继续对ISO 21434每一节中的内容详细解释。

ISO 21434 回顾：

第1节 明确本规范的范围。

第2节 参考规范。

第3节 明确本文中使用的缩略语和术语的定义。

第4节 描述汽车生态系统、组织网络安全管理和相关汽车生命周期。

第5节 介绍组织的网络安全战略、政策和目标。

第6节 明确风险管理要求，其中包括确定道路使用者在受到潜在的环境或事件威胁时的应对的计划和方法。

第7节 概念阶段描述，通过威胁分析和风险评估确定网络安全目标；为实现网络安全目标确定网络安全要求。

第8节 描述了具体到产品开发阶段的网络安全要求的实施和验证。

第9节的重点是生产、运行和维护，并给出了具体的要求，以确保网络安全规范在生产的产品中得到落实；本节还描述了现场网络安全活动。

第10节介绍了支持程序，包括组织程序。附件也提供了相关信息。附件中给出了一些活动、例子和方法，但在制定标准时，并未就此部分是否需要强制执行达成一致意见。

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

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

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)而定制信息安全活动。

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段)涉及对已查明的威胁情况进行分类(根据影响和攻击的可行性)和选择适当的风险处理方案。

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

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

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

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

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)鲁棒性、可验证性和适合软件修改的特性。

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

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

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

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

总结

ISO/SAE 21434委员会的重要任务之一就是为汽车行业的特殊性制定一个全新的信息安全标准，而非根据之前已存在的标准来制定。虽然SAE J3061已经进步了很多，但业内也认识到，这本指南和ISO/SAE 21434是不一样的，它不可能在道路车辆的信息安全工程方面发挥ISO/SAE 21434的类似作用，该标准更像是ISO 26262。汽车领域的信息安全是一个全新的领域，制定一个包括信息安全流程要求的框架和利益相关者之间沟通和管理信息安全风险的共同语言是及其有必要的。实际上，该标准没有规定与信息安全有关的具体技术或解决方案，这就导致对流程和方法的描述让人更加模糊。

另外一个高目标是给出明确的手段，以便全球行业在面对网络安全威胁时，能作出一致的反应。要实现这一目标困难很大。这方面有一个非常典型的例子，就是在风险评估过程中，ISO 26262中的汽车安全完整性等级（ASIL）的对应物CAL。本来应该用CAL来定义适用的严格方法，但由于在如何确定和处理这样一个参数上还没有找到共识，所以这部分内容也只被移到了附件中。因此，目标中鼓励采用面向风险的方法来确定行动的优先次序，提出信息安全措施，但在最佳做法或商定的方法方面，目标中未作具体阐述。

最后，对所做的工作给予高度评价。第一个共同制定的标准是行业朝着正确的方向迈出的重要和重大的一步。虽然有了标准，但并不是所有与方法、准则和最佳做法就能从标准中找到答案。因此，制定标准的目的就是为了分享行业专家和研究人员之间讨论和交流的基础。该标准中的描述往往是全局性的，或者说是很抽象的描述了在实际场景中的应用，该标准并非为了提供与方法、指导线和最佳实践有关的问题的答案。

因此，这项工作的目的之一是为行业专家，特别是研究人员提供一个对标准进行初步审查的基础。更重要的一点抛砖引玉，促进行业标准的完善，提出在标准和领域背景下应用的最佳做法和方法的建议。我们鼓励行业专家相互沟通，从而制定/改进目前最先进的标准。

作者：牛喀网专栏作者
牛喀网文章，未经授权不得转载！