ISO/SAE21434是SAE和ISO共同制定的第一个全球性的汽车行业的网络安全标准，它全面规定了道路车辆及其部件和接口的网络安全要求，详细描述了如何根据网络安全问题实现网络安全管理目标。ISO/SAE21434被看作一项业界共识，是目前网络安全方面监管和认证机构的重要参考文件。
后续的7个章节按照产品全生命周期的顺序，定义了从风险评估、概念开发、验证到生产、运维、退役等各阶段对于车辆网络安全的要求。
最后一章“分布式网络安全活动”主要介绍当前车辆分布式合作开发的背景下，对于资产识别，要求报价，责任分布等方面的网络安全要求。
第5章全局网络安全管理（overallcybersecuritymanagement）规定了公司/组织层面网络安全管理的战略要求。其中心思想是：对车辆的全生命周期，站在全公司层面，制定网络安全管理战略和措施。
标准提出了8个全局层面的网络安全管理要求：
这里所说的风险矩阵会在8.8风险确定中详细说明
例如用于复现漏洞的测试环境，必须在支持周期结束之前一直保持可复制
信息安全管理（Informationsecuritymanagement)
*RQ:Requirement;RC:Recommandation;PM:Permission；WP：WorkProduct
可以看出，21434在这一章里主要阐述了组织层级对于网络安全应采取的活动，在主机厂的实施过程中，这项工作的归口在公司的体系部门，质保和IT等部门作为支持。由于涉及整个公司层面的流程，组织架构和管理措施，因此整车厂通常是根据自身原有的流程，匹配21434相应的要求，并在工作产品上突出网络安全方面的证据，以符合标准的要求。
实际上，这种自上而下、逻辑驱动的网络安全体系建设是比较理想的情况，现实中更多的情况是由法规驱动的体系建设。整车厂为了满足VTA的形式认证要求，首先以产品为落脚点进行网络安全要求的研究，一边保证技术上的合规，一边再自下而上地推动体系的建设。毕竟体系上的"文审"有比较宽松的操作空间，但产品上的形式认证如果没有通过，则很有可能被“一票否决”。
网络安全职责及其分配（CybersecurityResponsibilityandTheirAssignment)
根据上一章[RQ-05-03]的原则进行沟通和分配。
网络安全计划（CybersecurityPlan)
网络安全活动的裁剪（TailoringoftheCybersecurityactivities)
在标准中规定了三种可进行裁剪的情况，分别是复用、需求外的组件和已有的组件，在这三种情况下，需根据标准中的要求和建议进行裁剪。
复用（Reuse)
组件复用在整车研发中非常的常见，虽然复用的组件使用的是已有的架构，接口和安全方案，但是由于运行环境、配置信息等的变化，以及攻击技术的不断发展，新漏洞的发现，仍然需要对其进行必要的分析，实施相应的网络安全活动。
超出当前需求的组件（Componentoutofcontext)
超出当前需求的组件通常指供应商预开发或预埋的组件，这些组件通常是因为平台化开发而预留的，不在当前产品需求的Scope里。
对于此类组件，21434要求在工作产品中对其预期的用途、环境和接口进行记录，并且这些组件必须基于预期用途的网络安全要求来开发。
现有组件（Off-the-shelfComponent）
网络安全案例（Cybersecuritycase)
网络安全案例就是网络安全评估的对象，案例必须提供一系列网络安全计划所需的工作产品，以证明在这个项目上网络安全的实施程度。
网络安全审核（CybersecurityAssessment)
网络安全审核的目的是判断对象或者组件的网络安全实现程度，确定其是否能达到本标准要求的网络安全目标。
对于网络安全活动是否执行，实现程度的审核主要基于对工作产品和文档证据的审核，下图显示了网络安全审核涉及的主要内容：
评估的结果包括接受、带条件接受和拒绝。带条件接受通常会在评估结果中提出整改要求，并会在项目各个阶段对整改项的完成情况进行监控。
用于后期开发的发布（RealeaseforPost-Development)
小结：本章对于项目层面网络安全的实施要求进行了定义，包括如何制定网络安全计划，如何识别项目范围，裁剪的原则，以及审核的原则。相对上一章，本章更加贴近实际的工作，笔者目前参与的项目也是从这个阶段开始进行的，在后续的VTA认证中，很大程度会参考本章中网络安全审核的要求来进行。不过标准中的要求很多都是十分宽泛的，具体的网络活动要如何实施，实施到什么程度，都还没有一个明确的基线，也没有所谓的”最佳实践案例“，各大OEM和咨询机构都还在等待着”第一个吃螃蟹“的主机厂。
与传统整车研发中大部分的工程活动不同，网络安全活动是一个贯穿了产品整个生命周期的持续性的活动。OEM不仅要在开发阶段进行必要的风险分析、网络安全开发，还要在后续的整个产品生命周期实施网络安全监控和运维，建立网络安全事件应急响应的机制，持续地保证车辆的网络安全。新漏洞的发现、网络安全突发事件和新攻击技术的出现等都可能触发网络安全活动。
网络安全监控（CybersecurityMonitoring)
通过网络安全监控持续地收集组件的潜在威胁、脆弱性和可能的解决措施等信息，以应对已知和新出现的威胁。监控获取的信息可作为脆弱性管理和网络安全事件响应的输入。
输出产品：
网络安全事件评估（CybersecurityEventAssessment)
网络安全事件评估结果
脆弱性分析（VulnerabilityAnalysis)
根据第8章的攻击路径分析、攻击可行性分析方法，确定每个脆弱点的攻击可行性等级。
输出产品：脆弱性分析结果
脆弱性管理（VulnerabilityManagement）
根据之前脆弱性分析和网络安全事件的评估结果，进行脆弱性管理，保证相应的风险被处置。在这项活动中，必须定义一个风险处置的原则，确保每项风险都有对应的处置措施，风险处置原则可基于脆弱性分析结果，风险判定结果等信息，对于脆弱性处置的具体方法会在第8、9、10章中介绍。
注：接受风险也是一种风险处置措施，但需要解释记录风险被接受的合理原因。
脆弱性管理基本原理
最后用一张表总结一下本章中介绍的四项活动的输入和输出：