2024 年 6 月 27 日，在第三届中国车联网安全大会上，一汽 - 大众汽车有限公司产品信息安全开发负责人王嘉明认为，当前主机厂在信息安全开发过程中面临诸多问题，主要是从风险评估到导出安全概念以及安全规范的过程，其中最重要的是提好需求，让 Tier1 更好开发。

王嘉明强调，信息安全需求需要从风险评估而来，如何通过风险评估得到准确明了的安全需求，风险评估至关重要。无论是欧洲的 UNECER155 法规还是国内的汽车整车信息安全技术要求，都强调对车辆进行完整的风险评估。

王嘉明｜一汽 - 大众汽车有限公司产品信息安全开发负责人

以下为演讲内容整理：

OEM 网络安全开发概述

当前，众多主机厂都已基于 ISO 21434 标准建立起了一套完善的信息安全开发流程。目前，我们要求大多数的 Tier 1 供应商也遵循这一流程进行信息安全开发，并且已有许多 Tier 1 供应商成功获得了 ISO 21434 的认证。与 Tier 1 供应商的主要区别在于，作为主机厂，我们还需要对整车的整体框架性要求进行把控。

图源：一汽 - 大众

其次是风险评估，我们会从整车角度出发进行风险评估，进而明确后续的安全概念及安全规范。作为合资厂商，我们会将这些安全需求统一传达给 Tier 1 供应商，由他们负责具体的开发实施。在开发模型中设有相应的测试验证阶段，这一阶段会识别出潜在的漏洞和难以处理的风险。对于可接受的风险，我们将通过安全手段进行减弱；对于残余的风险，我们将进行风险处置，这包括继续修复或选择接受，并在后续进行监控和日后处理。最终，当所有风险均达到我们可接受的范围内，即达到预设的阈值，我们将进行安全释放和安全认可。

作为主机厂，我们与 Tier 1 供应商的主要区别在于我们具备一个从整车角度出发的安全策。它规定了整车信息安全开发过程中的基础框架。通常它包含如下部分内容：第一部分详细阐述了开发的前提条件，为整个开发过程设定了基调。第二部分则是对我们在整车开发过程中所使用的开发文档的概述。包括企业标准、安全基线、所遵循的法律法规，以及开发过程中采用的具体工具和模板等。第三部分详细描述了整车开发过程中应遵循的总体流程，这一流程确保了开发活动按照既定的步骤和顺序进行，从而保障产品的质量和安全性。安全政策定义好后，就可以深入到主机厂的信息安全开发过程。

在分布式开发模式中，传统主机厂向 Tier 1 供应商提供安全需求以便开展后续的开发工作。因此，我们面临的核心挑战之一是确保安全需求的准确性和明确性。从风险评估到导出安全概念及制定安全规范，每一步都依赖于对需求的精准把握。我们进行了经验总结。

最佳实践：传统 OEM 安全开发

在主机厂的信息安全开发中，安全需求并非凭空产生，而是基于深入的 TARA 分析和风险评估。这些需求均源自对潜在风险的全面识别与评估。法规的遵从性也是信息安全风险评估的重要依据，例如欧洲 UNECE R155 法规和国内汽车整车信息安全强制标准，都明确规定了主机厂需对其车辆进行完整的信息安全风险评估，以确保能够准确识别并应对各类风险。因此，进行信息安全风险评估是导出风险、明确信息安全需求的必要环节。

风险评估作为信息安全工作的重要环节，目的在于识别和分析车内系统存在的风险，并根据这些风险制定相应的安全措施，以降低风险至可接受的水平。在进行风险评估时，我们通常从两个角度衡量风险的大小。横轴代表攻击可能带来的潜在影响，这一影响通常通过人身安全、经济影响、功能影响、个人敏感信息泄露四个维度评估。纵轴是被攻击的可能性，被攻击可能性越高代表该车越容易被攻击、风险越大，因此最终风险的高低是由被攻击的可能性和被攻击后所能造成的影响两个维度决定的。

在 ISO 21434 的框架内，风险评估的首要步骤是相关项定义，即识别车内哪些资产是需要我们保护的。接下来，我们需要针对这些资产确定它们的安全属性，通常包括保密性、完整性和可用性。针对已分析出的资产及其所具备的安全属性，我们需要进一步分析这些属性被破坏后可能带来的影响以及潜在的攻击路径。之后从潜在影响和攻击可能性两个维度进行综合评估，以确定风险值，该风险值将基于其高低与我们设定的可接受阈值进行比较。对于超出阈值的高风险，我们将提出相应的安全措施。

基于上述风险评估流程，市场上的众多 OEM 和 Tier 1 供应商在进行风险评估时，仍然倾向于使用 Excel 等工具。尽管有些主机厂已经采用了更为电子化和采购的专用工具，但从总体思路来看，它们仍然遵循着前述的流程，这也导致了某些共性问题的出现。在实际操作中，我们观察到评估结果往往篇幅巨大，大量重复，甚至包括了一些针对安全目标强行分析的现象。因此往往导致评估结果大量冗余，可视效果差，质量下降，难以导出准确而有效的风险控制措施，而更多地停留在分析的层面，有较大的提升空间。

在 " 相关项定义 " 中，从行业角度而言，一个有效的风险评估并非是简单地分析所有可能的项目，而是需要有针对性地进行筛选和聚焦。在相关项定义的过程中，如何实现 " 做减法 " 呢？以车载传感器为例，在进行资产识别和分析时，传感器通常会被视为一类资产。从最终的风险评估结果来看，对车载传感器进行物理测量过程或测量数据更改的分析，往往未能导出有效的安全措施。因此，在风险评估的过程中，我们需要采取一种更为合理的思路。如果传感器是通过专线与 ECU 相连，那么我们可以将该传感器视为 ECU 的一部分。在分析过程中，将传感器与 ECU 作为一个整体来考虑，而不需要单独分析每一个传感器。对于类似传感器，我们可以在资产识别过程中对其做减法而不影响最终结果。

在完成相关项定义后，需要针对已识别的相关项的信息安全属性进行识别，一些优秀的主机厂可能会定义 6 种或 7 种安全属性，并根据特定规则确定各类资产所具备的安全属性。同样， 安全属性也可以做减法。以认证性这一属性为例，在车内通信中，主机厂通常会预先定义好 ECU 之间的通信信号，只有当某个 ECU 被授权向另一个 ECU 发送信号时，这种通信才会被允许。若未经授权的 ECU 尝试发送信号，则说明其真实性受到破坏，在此情况下，认证性实际等同于真实性。对车内通信而言，若已经对真实性进行了深入分析，那么再对认证性进行分析会产生与真实性分析相同的结果。为了避免冗余，我们在分析过程中可以考虑将认证性与真实性合并。

在完成了安全属性的优化后，要对这些属性被破坏后可能造成的影响进行深入分析。在进行影响分析时，我们也可以采用一定的方法和思路简化评估过程。首先，我们可以对资产可能造成的损害进行分类。以车内信号为例，不同的信号具有不同的功能和重要性。一些信号直接用于控制车辆，而另一些则仅用于在屏幕上显示信息，能够控制车辆的信号如果被破坏，所造成的损害将更为严重。因此在风险评估过程中，我们可以将那些仅用于显示的信号视为低风险资产，无论其被攻击的可能性有多高，所造成的风险通常都较低，基于这一认识，我们在进行风险评估时，可以省略对这类信号后续步骤的深入分析，因为它们的风险水平不会超过风险接受的阈值。

在进一步延伸关于风险评估的讨论时，无论采用何种风险评估矩阵，评估流程通常都遵循先分析影响再评估被攻击的可能性的顺序。如果某个潜在风险的影响被评估为非常低，存在无论该风险被攻击的可能性有多高，其整体风险水平都不会超出阈值的情况。因此，在进行风险评估时，一旦在影响分析阶段确定某个风险的影响非常低，那么接下来的步骤中，无需再详细考虑该风险的攻击路径和攻击可行性，这种简化的评估方法不会影响最终的风险评估结果。

完成损害程度评估后，分析攻击可行性同样可以做取舍。假设攻击者采用最简单的攻击路径对目标进行攻击，如果这种最简单的攻击路径是无法防范的，如直接进入车内对 CAN 总线信号进行 DOS 攻击等物理攻击，那么针对更困难的攻击路径所造成相同或更小的损害而提出安全措施并不会降低相应风险，因此针对更复杂的攻击路径提出安全措施是没有意义的。

在针对评估出的最终风险实施安全控制措施后，必须进行预先定义的攻击可行性评估。这一评估的核心在于确认安全措施是否能在不改变风险影响程度的情况下，有效降低被攻击的可能性。通过量化分析，我们需要预先定义安全措施对攻击可行性的降低程度，结合这些量化分析的结果，需要重新审视 TARA 的结果。特别是要关注在采取了安全措施后，由于攻击路径变得更为复杂和困难，风险水平是否已降至组织所设定的可接受阈值之下。如果风险降低至可接受范围内，则表明所实施的安全控制措施是有效且有意义的。反之，如果风险水平仍高于可接受阈值，则表明当前的安全控制措施可能不足以充分应对所评估出的风险，需要进一步审视和加强相应的安全措施。

在安全控制的实施过程中，一个经常被厂商忽视的步骤是对安全控制措施中的新增资产进行全面的风险评估。例如采用加密的安全措施会引入密钥，密钥作为一项重要的安全资产，其完整性、机密性和真实性一旦被破坏，将可能导致严重的安全风险。因此，密钥的引入必须重新纳入 TARA 分析流程中，以全面评估其可能带来的风险。

经过深入的安全评估后，许多主机厂或供应商提出的安全需求往往过于笼统和表面化。例如，他们可能仅指出 " 由于安全通信的重要性，我们需要采用 TLS 加密协议作为传输层协议来保护数据的保密性和完整性 "。然而，这样的需求表述是不够的。更为优秀的供应商可能会结合相关法规和标准，进一步指定采用 TLS 1.2 版本，因为该版本在安全性上可能更为可靠。然而，这仍然不够全面。TLS 协议包含大量的扩展功能，这在互联网领域是常见的，例如压缩和 False Start 等技术用于加速 TLS 通信。但是，当 TLS 被应用于车内以太网环境时，这些扩展功能可能并不适用，甚至可能带来安全风险，因此在实际应用中，针对车内以太网采用 TLS 时，需要关闭这些可能引发问题的扩展功能。

因此，从 TARA 分析、安全规范以及安全概念的角度出发，风险评估结果所导出的应当是安全概念，而非安全规范。安全概念是一个宏观的类别，可能是传输层安全，外部接口安全，也可能是操作系统安全等等，针对每一个类别都应该有更为详细的需求。这是在分布式开发过程中真正能够提供给 Tier1 供应商做开发的安全需求，即安全规范。 这也是作为传统主机厂历经多年最重要的积累，未来也一定是国内主机厂和 Tier1 的发展方向。

（以上内容来自一汽 - 大众汽车有限公司产品信息安全开发负责人王嘉明于 2024 年 6 月 27 日在第三届中国车联网安全大会发表的《智能网联汽车信息安全分布式开发实践》主题演讲。）