浅谈ISO/SAE 21434汽车网络安全标准（一）：整体要求及项目网络安全管理
01
概述
ISO/SAE 21434 是SAE和ISO共同制定的第一个全球性的汽车行业的网络安全标准，它全面规定了道路车辆及其部件和接口的网络安全要求，详细描述了如何根据网络安全问题实现网络安全管理目标。ISO/SAE 21434 被看作一项业界共识，是目前网络安全方面监管和认证机构的重要参考文件。
整体网络安全管理 基于项目的网络安全管理 持续网络安全活动
后续的7个章节按照产品全生命周期的顺序，定义了从风险评估、概念开发、验证到生产、运维、退役等各阶段对于车辆网络安全的要求。
最后一章“分布式网络安全活动”主要介绍当前车辆分布式合作开发的背景下，对于资产识别，要求报价，责任分布等方面的网络安全要求。
每个章节都是从“概要、目的、输入、要求和建议、工作产品”5个角度进行叙述，在后续的文章中，将对每个章节进行逐一解读。
02
整体要求
第5章 全局网络安全管理（overall cybersecurity management）规定了公司/组织层面网络安全管理的战略要求。其中心思想是：对车辆的全生命周期，站在全公司层面，制定网络安全管理战略和措施。
标准提出了8个全局层面的网络安全管理要求：
[RQ-05-01]：组织必须定义一个网络安全方针。
[RQ-05-02]：组织应建立和维护组织层面的规则和流程以支持相关要求的实现和网络安全活动的执行。
[RQ-05-03]：组织应对网络安全活动的职责进行分配和授权 [RQ-05-04]：组织应提供解决网络安全问题所需的资源。 [RQ-05-05]：组织应识别与网络安全相关的专业领域，并建立和维护这些领域之间的沟通渠道。 [RQ-05-06]：组织必须在风险矩阵中定义一个风险值。
这里所说的风险矩阵会在8.8 风险确定 中详细说明
[RQ-05-07]：组织必须建立和维护网络安全文化 [RQ-05-08]：组织必须保证参与网络安全的人员具有相应的能力和意识
组织应建立和维护持续改进的流程
[RQ-05-09]：网络安全风险管理应符合ISO 31000 [PM-05-01]：组织可保持网络安全风险管理与企业风险管理的一致性
[RQ-05-11]: 应进行网络安全审计以独立判断组织的流程是否达到了本标准的要求
[RQ-05-12]: 组织应定义环境条件，考虑组织内部和外部哪些共享是必须的、允许的，哪些是被禁止的
[RQ-05-13]: 组织应按照国际标准或同等标准建立和维护一个质量管理体系来支撑网络安全工程 [RQ-05-14]: 量产产品的网络安全配置信息应在产品终止维护前保持可用 [RC-05-01]: 应制定针对生产制造流程的网络安全管理体系
[RQ-05-15]: 应对能够影响相关项目、系统和组件的工具进行管理 [RC-05-02]: 在对产品支持结束之前，一个支持网络安全事件响应补救措施的相应环境必须可复制。
例如用于复现漏洞的测试环境，必须在支持周期结束之前一直保持可复制
信息安全管理（Information security management)
[RC-05-03]: 网络安全计划要求的工作产品的相关信息属性应该由一个信息安全管理系统来管理
[WP-05-01]: 网络安全方针、规则和流程 [WP-05-02]: 能力管理、意识管理和持续改进的证据 [WP-05-03]: 组织层面的网络安全审计报告 [WP-05-04]: 组织管理体系的证据 [WP-05-05]: 工具管理的证据
*RQ: Requirement; RC: Recommandation; PM: Permission；WP：Work Product
可以看出，21434在这一章里主要阐述了组织层级对于网络安全应采取的活动，在主机厂的实施过程中，这项工作的归口在公司的体系部门，质保和IT等部门作为支持。由于涉及整个公司层面的流程，组织架构和管理措施，因此整车厂通常是根据自身原有的流程，匹配21434相应的要求，并在工作产品上突出网络安全方面的证据，以符合标准的要求。
实际上，这种自上而下、逻辑驱动的网络安全体系建设是比较理想的情况，现实中更多的情况是由法规驱动的体系建设。整车厂为了满足VTA的形式认证要求，首先以产品为落脚点进行网络安全要求的研究，一边保证技术上的合规，一边再自下而上地推动体系的建设。毕竟体系上的"文审" 有比较宽松的操作空间，但产品上的形式认证如果没有通过，则很有可能被“一票否决”。
03
项目网络安全管理
项目相关的网络安全管理（Project dependent cybersecurity management) 一章给出了一个普适性的，项目层面的网络安全管理要求。其中包含了需要实施的网络安全活动，各项活动的职责分配，裁剪原则，以及网络安全案例和网络安全评估的要求。
网络安全职责及其分配（Cybersecurity Responsibility and Their Assignment)
根据上一章[RQ-05-03]的原则进行沟通和分配。
网络安全计划（Cybersecurity Plan)
首先确定哪些组件与网络安全有关，21434在附录D这种给出了一个判断的流程。 分析组件时新开发还是复用，从而确定是否需要进行裁剪 根据以上的分析结果，结合[RQ-05-03]，[RQ-05-04]的要求，制定网络安全计划并分配职责。
网络安全计划应被纳入项目的开发计划当中 网络安全计划概念阶段和产品开发阶段的活动必须符合本标准中的要求（在之后的章节会提到） 网络安全计划必须包含：
活动的目的 对其它活动或信息的依赖性 活动的负责人 进行活动所需的资源 开始、结束的时间点以及持续时间 工作产品的标识
相关的活动，工作成果需进行维护和更新 如果活动涉及供应商，需按照本标准中第15章的要求进行网络安全活动的计划 所有网络安全产生的工作产品，都要进行配置管理需求管理和文件管理。
网络安全活动的裁剪（Tailoring of the Cybersecurity activities)
在21434中允许对网络安全活动进行必要的裁剪，如果实施了裁剪，必须提供相应的证据，以证明裁剪后仍然可以充分实现网络安全的相关目标。
在标准中规定了三种可进行裁剪的情况，分别是复用、需求外的组件和已有的组件，在这三种情况下，需根据标准中的要求和建议进行裁剪。
复用（Reuse)
组件复用在整车研发中非常的常见，虽然复用的组件使用的是已有的架构，接口和安全方案，但是由于运行环境、配置信息等的变化，以及攻击技术的不断发展，新漏洞的发现，仍然需要对其进行必要的分析，实施相应的网络安全活动。
识别在本项目中，组件所在环境的变更，设计变更以及配置或校准数据的变更； 分析组件是否能满足当前项目的网络安全要求，现有的工作产品是否足以支持其集成到新项目中； 识别出缺少的工作产品及网络安全活动，制定针对该组件的网络安全计划。
超出当前需求的组件（Component out of context)
超出当前需求的组件通常指供应商预开发或预埋的组件，这些组件通常是因为平台化开发而预留的，不在当前产品需求的Scope里。
对于此类组件，21434要求在工作产品中对其预期的用途、环境和接口进行记录，并且这些组件必须基于预期用途的网络安全要求来开发。
现有组件（Off-the-shelf Component）
现有组件指那些不是专门为项目开发的软件，如第三方的软件，开源软件库等。对于此类组件，21434要求必须收集其相关的网络安全信息，保证其相关的证据文档足以支撑当前项目的网络安全要求。
网络安全案例（Cybersecurity case)
网络安全案例就是网络安全评估的对象，案例必须提供一系列网络安全计划所需的工作产品，以证明在这个项目上网络安全的实施程度。
网络安全审核（Cybersecurity Assessment)
网络安全审核的目的是判断对象或者组件的网络安全实现程度，确定其是否能达到本标准要求的网络安全目标。
对于网络安全活动是否执行，实现程度的审核主要基于对工作产品和文档证据的审核，下图显示了网络安全审核涉及的主要内容：
评估的结果包括接受、带条件接受和拒绝。带条件接受通常会在评估结果中提出整改要求，并会在项目各个阶段对整改项的完成情况进行监控。
用于后期开发的发布（Realease for Post-Development)
网络安全案例 网络安全评估报告 后期开发的网络安全要求
小结：本章对于项目层面网络安全的实施要求进行了定义，包括如何制定网络安全计划，如何识别项目范围，裁剪的原则，以及审核的原则。相对上一章，本章更加贴近实际的工作，笔者目前参与的项目也是从这个阶段开始进行的，在后续的VTA认证中，很大程度会参考本章中网络安全审核的要求来进行。不过标准中的要求很多都是十分宽泛的，具体的网络活动要如何实施，实施到什么程度，都还没有一个明确的基线，也没有所谓的”最佳实践案例“，各大OEM和咨询机构都还在等待着”第一个吃螃蟹“的主机厂。
04
持续的网络安全活动
与传统整车研发中大部分的工程活动不同，网络安全活动是一个贯穿了产品整个生命周期的持续性的活动。OEM不仅要在开发阶段进行必要的风险分析、网络安全开发，还要在后续的整个产品生命周期实施网络安全监控和运维，建立网络安全事件应急响应的机制，持续地保证车辆的网络安全。新漏洞的发现、网络安全突发事件和新攻击技术的出现等都可能触发网络安全活动。
网络安全监控
网络安全事件评估
脆弱性分析
脆弱性管理
网络安全监控（Cybersecurity Monitoring)
通过网络安全监控持续地收集组件的潜在威胁、脆弱性和可能的解决措施等信息，以应对已知和新出现的威胁。监控获取的信息可作为脆弱性管理和网络安全事件响应的输入。
监控的信息可来源于外部或内部。
外部来源：网络安全研究者、商业/非商业来源、供应链、客户、政府
内部来源：脆弱性分析结果、现场获取的信息（如脆弱性扫描报告，维修信息，客户使用信息）、配置信息（如软硬件材料清单）
是否来源于已知的可信来源 根据[RQ-09-05]确定该信息在各威胁场景下的风险； 信息的类型（主动攻击、POC测试等）
输出产品：
网络安全监控来源清单、网络安全信息分类结果
网络安全事件评估（Cybersecurity Event Assessment)
网络安全事件评估的目的是确定网络安全事件的严重性，以决策是否采取响应的活动。根据脆弱性分析对事件进行分析，确定该网络安全事件是否影响相关组件。如果不影响，可不实施相应的网络安全活动。如果影响，则应进行脆弱性管理或网络安全事件应急响应。
输出产品：
网络安全事件评估结果
脆弱性分析（Vulnerability Analysis)
脆弱性分析的输入可来源于之前的网络安全事件评估、过去的脆弱性分析文档、验证报告、安全应急事件响应信息等。目的是检查某个脆弱点的脆弱程度，评估其是否会被利用来进行网络安全攻击。
缺少要求或规范 架构或设计上的脆弱点，包括不正确的安全协议设计 实施中的脆弱点，包括硬件和软件缺陷，安全协议的错误实施 操作过程和流程中的脆弱点，包括误用和不充分的用户培训 使用过时或者弃用的函数，包括保密算法
根据第8章的攻击路径分析、攻击可行性分析方法，确定每个脆弱点的攻击可行性等级。
输出产品：
脆弱性分析结果
脆弱性管理（Vulnerability Management）
根据之前脆弱性分析和网络安全事件的评估结果，进行脆弱性管理，保证相应的风险被处置。在这项活动中，必须定义一个风险处置的原则，确保每项风险都有对应的处置措施，风险处置原则可基于脆弱性分析结果，风险判定结果等信息，对于脆弱性处置的具体方法会在第8、9、10章中介绍。
注：接受风险也是一种风险处置措施，但需要解释记录风险被接受的合理原因。
输出产品：
脆弱性管理基本原理
最后用一张表总结一下本章中介绍的四项活动的输入和输出：
- 用户评论
