ISO/SAE 21434对汽车意味着什么？

安全是汽车发展的一个永恒话题，而且随着汽车往智能网联化的方向发展，安全在汽车行业的要求也都会多元化起来，安全相关的活动在产品开发过程中的分量也日益增加，网络安全就是个典型例子。

网络安全本身在其他行业，比如金融，IT行业已经是历史悠久，但对于汽车行业算是其安全领域的一个新合规方向，这是行业发展趋势的必然，生命毕竟要排在安全的第一考量，因为没有网络安全汽车的网联化没有什么价值可言，试想一下一辆声称具备高级别自动驾驶的车辆其网络安全没有保证的话你愿意掏钱购买吗？或者说你敢驾驶这样一辆车辆上路吗？

在此背景下，在2021年8月份针对汽车的网络安全标准ISO/SAE 21434正式版发布了。从直观意义上来讲，该标准的正式发布意味着汽车行业多了一个需要满足的标准。而对于主机厂来讲这意味着需要一个专业的网络安全团队应对汽车在网络安全领域的挑战。

未来的汽车是智能网联的高度智能化交通工具，交通出行是其原始功能，彼时他将是互联网上智能终端的一份子，具备智能设备的一切功能，这也意味着未来的汽车将成为网络攻击的一大目标，而且是非常具有吸引力的目标。网络安全将是未来汽车的一个重要考虑点，ISO/SAE 21434正是迎合汽车这个发展趋势而形成的一个标准。

那么，标准针对汽车的网络安全提了什么要求呢？主机厂该如何将该标准体系导入现有的开发体系呢？接下来让我们聊一聊标准本身。如下图1，标准的内容框架总览，看看标准由哪些内容结构组成。

图1——ISO/SAE 21434标准框架

图1中列出从第4章到第15章内容框架，每章对应内容如下：

第4章（一般注意事项）仅供参考，包括本文件中道路车辆网络安全工程方法的背景和观点。

第5章（组织网络安全管理）包括组织网络安全政策、规则和流程的网络安全管理和规范。

第6章（项目相关网络安全管理）包括项目层面的网络安全管理和网络安全活动。

第7章（分布式网络安全活动）包括在客户和供应商之间分配网络安全活动责任的要求。

第8章（持续网络安全活动）包括为持续风险评估提供信息的活动，并定义了在网络安全支持结束前电子/电子系统的脆弱性管理。

第9章（概念）包括确定项目网络安全风险、网络安全目标和网络安全要求的活动。

第10章（产品开发）包括定义网络安全规范、实施和验证网络安全要求的活动。

第11章（网络安全验证）包括车辆级别项目的网络安全验证

第12章（生产）包括物品或组件制造和组装的网络安全相关方面。

第13章（操作和维护）包括与网络安全事件响应和项目或组件更新相关的活动。

第14章（网络安全支持和退役的结束）包括项目或组件支持和退役的结束的网络安全考虑因素。

第15章（威胁分析和风险评估方法）包括模块化的分析和评估方法，以确定网络安全风险的程度，从而进行治疗。

第5章至第15章有自己的目标、规定（即要求、建议、许可）和工作成果。工作产品是满足一个或多个相关要求的网络安全活动的结果。

该内容框架对应的思维导图如下：

图2——ISOSAE 21434 标准内容拓扑结构

正式发布版本的内容框架中没有体现第1至第3章，虽然这几章都是些通用的说明性内容，但对于理解标准还是非常由帮助的。第1章定义了标准的适用范围，即在本标准发布之后的量产乘用车电子电气系统及其零部件和接口。同时本标准未规定网络安全相关的具体技术和解决方案，而是定义了针对汽车电子电气系统及其零部件和接口在生命周期内的网络安全风险管理相关要求。

由此可见，本标准侧重从流程的角度实施网络安全风险管理。第2章是关于规范文件引用的说明，在此略过。第3章是标准涉及的术语及相关定义，这一章如同ISO26262标准的第1部分，对标准中的专业术语进行了解释说明，类似于数学中的定理，对于下文的展开起着重要作用。在这里我想提一提网络安全中一些重要的术语。

>资产(Asset)：对组织具有价值的信息或资源，是安全策略保护的对象。

>威胁(Threat)：可能导致对系统或组织危害的不希望事故潜在起因。

>脆弱性(Vulnerability)：可能被威胁所利用的资产或若干资产的薄弱环节，俗称为“漏洞”。

>脆弱点(Weakness)：可能导致不良行为的缺陷或特征。

Jet Note: 脆弱点可能是漏洞，但漏洞一定是脆弱点。

>攻击(Attack)：试图破坏、暴露、更改、禁用、盗窃或未经授权访问或未经授权使用资产。（参考 ISO/IEC 27000）

>攻击路径(Attack path)：实现威胁情景的一组/一套蓄意的行为/操作。

>攻击可行性(Attack feasibility)：攻击路径的属性，描述成功执行相应行为/操作的容易程度。

>渗透测试(Penetration test)：网络安全测试，模拟真实世界的攻击，以识别危害网络安全目标的方式。

这里之所以提这些术语，因为相对于功能安全，这些术语是网络安全所特有的(当然，这里并未列全)，这也意味着对于组织原有的功能安全团队，这些概念是全新的，需要组织的功能安全团队去学习和扩展这方面的知识，或者组织需考虑建立相应的网络安全团队。

》第4章，总则。介绍了相关项的概念，及标准对于相关项的适用范围，组织的网络安全风险管理适用于网络安全相关的产品的全生命周期开发的各阶段，如下图3所示。

                                                 图3 整体网络安全风险管理示意图

这和功能安全类似，实施全生命周期安全管理，意味着组织可以将功能安全管理与网络安全管理融合在一个流程当中，通过各阶段的工作成果进行流程管控。这里有点需要强调，就是如何界定产品开发过程中的“网络安全相关性”？或者说如何判断所开发的产品是网络安全相关的呢？图4中给出了该问题的示例性判断方法。

                                                           图4——网络安全相关性判断流程

》第5章，开始正式讲组织的网络安全管理，从组织的层面对网络安全提了具体的要求。这一章节从方针/策略、文化培养、信息共享、管理系统、工具、审计的角度对网络安全管理提了相关要求，需要提一下的是，这里的信息共享算是网络安全相对于功能安全在安全管理方面独具特色的一项，因为网络安全和网络强相关，组织需要将产品的安全漏洞信息通过规定的流程以适当的方式进行披露。

另外，网络安全管理系统也有一些具体的标准可参考，如ECE/TRANS/WP.29中有关CSMS(Cybersecurity Management System)的符合性要求。其他方面由于都是从流程的宏观层面提要求，在形式上和功能安全相比并无明显差异，只不过这里针对的是网络安全。这也意味着，这部分在流程上可以和功能安全的开发流程进行融合。关于组织的网络安全治理框架可参考下图5.

                                                          图5——网络安全治理框架

》第6章开始是从项目层面谈网络安全管理，这一章从项目的网络安全责任划分、网络安全计划、管理过程中的复用和裁剪、脱离上下文开发的零件和现成零件在项目开发过程中的网络安全、网络安全档案与网络安全评估、生产释放的角度提了相关要求。

这些活动也是服从V模型的开发流程，从流程的角度和功能安全并无差异，这也意味着，从项目管理的角度这部分内容在流程上可以和功能安全的流程进行融合。不过，这里需要提到的是，网络安全评估流程有具体的流程规范和相关标准要求（e.g. ISO/IEC 15408），这意味着流程中具体的活动的实施需要专业的相关安全专业人员实施。网络安全评估流程可参考下图6。

                                                            图6——网络安全风险评估流程

》第7章讲的是分布式网络安全活动，类似于功能安全中的分布式开发，主要对责任划分、报价、供应商能力评估提要求，这些在流程上完全可以和功能安全进行融合，通过工作成果加以区别。比如，在开发接口协议中通过RASIC的方式对分布式开发的网络安全活动进行职责划分，当然在这个接口协议中可以同时对功能安全的活动进行责任划分。

》第8章讲的是持续网络安全活动，主要包括网络安全监控、漏洞分析和漏洞管理。相较于功能安全这部分内容是网络安全所独有的活动，目的是为了：

1） 监控网络安全信息，以识别网络安全事件；

2） 评估网络安全事件，以识别脆弱点；

3） 从脆弱点中识别漏洞；和

4） 管理已识别的漏洞。

以上活动的实施需要用的一些专用工具和方法，比如“监控网络安全信息，以识别网络安全事件”需要通过建立分类器收集网络安全信息的各类来源，这些信息来源可以是内部的可以是外部的（如，国家安全机构、安全公司、行业组织发布的一些网络安全事件），通过将收集到的信息进行分类和关联分析来确定是否会成为网络安全事件，这是一种动态感知态势。

若经过分析收集到的网络安全信息会成为网络网络安全事件，则进一步分析识别其中的脆弱点，进而识别相关漏洞并对漏洞进行管理。漏洞可以通过收集网络上的漏洞信息来识别，并进行分类和管理，还可通过一些专业工具，比如漏洞扫描器（e.g. Nmap, Nessus etc.）来发现系统的漏洞，这些活动都需要专业的工具和人员来实施，意味着要实现这些活动组织需要具备相关的专业技术人员及配套的工具链。

》第9章到第14章开始正式进入网络安全相关产品的开发阶段，覆盖了网络安全开发的全生命周期，从概念阶段到产品开发，网络安全验证和确认，生产、操作、维护和报废整个V模型产品生命周期过程的相关要求都在这些章节有具体的要求，本文是概述性质，暂不展开讲这些章节涉及的具体活动内容。

这些章节在流程上的写法和ISO26262对应阶段的要求高度一致，在功能安全从业人员看来这就是在模仿ISO26262的写法。这意味着，从流程的角度组织可以将网络安全和功能安全的活动进行融合，通过各自要求的工作成果过加以区别，当然前提依然是各自的活动需要有对应的专业人员来实现。简化的网络安全产品V模型开发过程中的活动如图7所示。

                                               图7——简化的网络安全V模型开发活动

》第15章作为标准的最后一个章节聚焦在威胁分析及风险评估，简称TARA。本章的主要目的有：

1） 识别资产及其网络安全属性及其损害场景；

2） 识别威胁场景；

3） 确定损害场景的影响等级；

4） 识别实现威胁场景的攻击路径；

5） 确定攻击路径可被利用的难易程度；

6） 确定威胁场景的风险值；和

7） 为威胁场景选择适当的风险处理方案。

不得不说TARA像极了ISO26262中的危害分析及风险评估(HARA)，同样可以将TATA拆分成两个过程再合并完成整个活动，即将TARA拆成威胁分析(TA)和风险评估(RA)两个过程，因为这两个过程在流程上具有先后顺序，所有采用这种“先分后总”的方式未尝不是一种高效的方式。

如图8展示了TARA和概念阶段相关活动的关系。

                                                           图8——TARA与概念阶段的交互

TARA分析是一个定性与定量分析相结合的分析过程，比如“确定对损害场景的影响等级”这一活动，影响等级本身可以是定性的描述，如下图9中所示，可以给安全影响等级的定性描述进行相应的赋值，如从低到高定性描述依次为：忽略不计，中等，重要，严重。对应的赋值可以是：1，2，3，4。这可为后面风险值计算时提供定量的输入。

关于TARA分析这里暂不展开，因为该活动具体实施过程涉及的步骤比较多，这些步骤将在后面的文章中进行分步描述。

关于标准把TARA安排在了最后一章节不知是处于何考虑，毕竟这一活动要作为概念阶段的一个输入，个人理解可能是因为TARA是一个持续动态的过程，你是怎么看的呢？

以上是个人对ISO/SAE 21434标准整体内容框架一些粗浅的概述，就当是学习过程。

总的来说网络安全对于汽车来说意味着行业内的上下游厂家，从主机厂到零部件供应商都需要花力气去搭建自身产品网络安全开发的能力，不管是内部现有安全团队自身进行这块的能力建设也好还是组建新的网络安全团队，总之是这部分的能力需要厂商投入额外的资源去建立，随着更多的标准和法规出台，这将不是愿不愿意的问题而是必须这么做的问题。

更多精彩内容欢迎关注微信公众号：功能安全落地漫谈