在本系列文章Part I 中我们对智能网联汽车进行了基础的介绍，顺手在文章的最后列出了资产分类的图例。按照信息安全工作的惯常思路，完成了资产定义部分的说明，接下来就该做威胁分析了。

      其实在《ENISA Good practices for security of smart cars》中对威胁分类和威胁场景有详细描述，但以图谱和列表的形式呈现，直接贴上来有点生硬，索性跳过，我们直接来看安全措施，也就是说按照良好实践的经验建议，我们到底该怎么做？

     安全措施整体来说分三类，政策流程、组织管理和技术实践，虽然下方就是译文来袭，还是想highlight下重点。

      政策流程方面，首先还是得基于整车开发全生命周期流程开展相应的信息安全工作，此时信息安全的流程建设就显得特别重要了，设计过程中要考虑数据方面的法规要求，比如GDPR，对于资产管理建立采用工具化管理，风险威胁方面，定期进行风险评估，建立完善的威胁情报流程。。

     组织管理方面，还是我们常说的供应商关系处理、意识管理、安全管理、事件管理。对于技术人员来说，一直都不太看重这一块，但对于信息安全管理人员，或者说信息安全团队创建者来说，这些管理工作是入门的基础，软知识清楚之后，硬知识有了铺垫，相对就容易些了。

     最后就是大家渴望看到的技术措施实践建议，包括检测、网络和协议的保护、软件安全、云安全、密码学、访问控制、系统自我保护等方面

     以上，算是对本次系列的热身内容，接下来是译文正文，大家可以细品。如果你想在良好实践中找到支撑实际项目开发的指导意见，那得再往前走两步，但是想了解信息安全常用的思路和方法以及汽车信息安全的关键要素，增长信息安全方面的见识，倒也不妨看一看，希望能够对你有所帮助。

      最后，还是感谢我们青骥安全公益小组的小伙伴龚恒毅@MonsterGon的精心翻译，感谢公益小组其它成员的技术支持。

安全措施和良好做法

4.2 政策

第一类安全措施包括为确保适当的网络安全水平，而在组织内建立的不同政策和程序。

与政策有关的信息安全措施涵盖信息安全及隐私两方面，并分为四个主要的信息安全范畴，即“按设计安全”、“按设计隐私”、“资产管理”及“风险及威胁管理”。

由于OEM和供应商之间的联系紧密，本节中的安全措施在两个方面都有涉及。

4.2.1设计安全

这些安全措施强调需要从产品开发的一开始，整个供应链和整个智能汽车全生命周期都考虑安全方面的问题。

•PS -01:采用“通过设计实现安全”的方法，从车辆和基础设施的角度考虑智能汽车的网络安全。

•PS-02:在每个相关的规范文档中解决安全性问题，以确保从概念阶段一开始就考虑安全性方面的问题，而不是事后才考虑。

•PS -03:提倡使用方法，考虑安全的每一个阶段开发阶段和操作阶段(例如DevSecOPS48、安全开发生命周期(SDL)49等)。

•PS-04:考虑在产品工程团队中加入一个安全角色来领导安全相关的任务。

4.2.2设计隐私

该安全领域包括一组安全措施，主要保护用户收集、处理和/或存储的私有数据

•PS-05:考虑应用本地和国际隐私相关法规，如GDPR，以防止隐私问题。

•PS-06:进行隐私影响评估(PIA)，考虑使用环境，以识别任何与隐私相关的风险，并定义适当的应对措施来减轻它。

•PS-07:在智能汽车开发和后端系统期间定期执行隐私审计，例如，至少一年一次，以确保遵守隐私相关政策。

4.2.3资产管理

下面概述资产发现、监控、管理和维护的安全措施。

•PS -08:使用支持资产管理的工具，可以自动发现、识别和列举特定于组织和智能汽车生态系统的资产。

•PS-09:确保组织保持一致的和最新的资产清单。

•PS -10:仅根据已建立、已接受和已沟通的变更管理流程，将新设备或软件变更引入车辆。

4.2.4风险与威胁

管理该安全域收集与风险和威胁管理过程相关的安全措施

•PS-11:采用一种专门适用于汽车行业的风险管理方法，考虑针对智能汽车的新兴威胁和攻击场景。

•PS-12:在设计过程的早期阶段进行网络安全风险分析，在重大变化或重大安全漏洞检测或重大安全事故发生时，应至少每年对其进行修订。

•PS-13: 重点监控安全漏洞，定期关注市场上的车辆，例如每6个月或更频繁地根据风险评估。

•PS-14:在开发阶段进行安全评估，如渗透测试，然后，在事件驱动方法的基础上，定期进行安全评估，例如，在新的威胁或漏洞的情况下，以及重大更新之后。

•PS -15:考虑建立一个威胁情报流程，以便了解新出现的攻击类型和来源，以及新的相关漏洞。

•PS-16:在智能汽车的整个生命周期中，每年至少定期评估一次安全控制，并部署补丁(在测试之后)以减少漏洞

•PS -17:定期检查，至少每六个月在智能汽车的生命周期，安全假设(如操作环境假设)仍然有效。特别地，考虑为网络安全定义通信和终止/保修期外状态处理程序。

4.3 组织管理

组织和治理过程对确保智能汽车的安全至关重要。在接下来的内容中，将详细介绍一组组织规则和最佳实践。它们涵盖了与供应商的关系、员工培训、事件管理等多个方面

4.3.1供应商关系

•OP-01:在保护知识产权的同时，促进不同利益相关者之间的安全相关信息共享

•OP-02:定义供应链伙伴关系的网络安全相关方面，为供应商制定安全要求和采购指南50。

4.3.2培训和意识

•OP-03:以现有的信息共享与分析中心(ISACs)为例，在包括分包商、供应商和第三方在内的所有组织之间共享相关信息，以增强智能汽车的安全性。

•OP-04:对员工进行整体的安全培训和安全意识，包括组织所有级别的员工，并考虑将其扩展到供应商。

•OP -05:确保安全培训持续、定期、经常更新。

•OP -06:定期提高车主、司机和乘客对安全问题的认识，以及如何预防。

4.3.3 安全管理

•OP-07:考虑建立一个OEM安全运营中心(SOC)，明确定义角色、职责和网络安全能力，集中网络安全知识，监控和预测潜在威胁。

•OP-08:指定一个或多个专门的安全团队，由安全专家组成，在安全相关主题(如风险评估、渗透测试、安全设计等)方面具有多样化和广泛的能力。

•OP-09:定义一个覆盖智能汽车全生命周期的专用信息安全管理系统(ISMS)

•OP-10:考虑成立一个内部工作组，包括董事会级别的管理层，以指导与安全相关的战略决策，并促进问责制。

4.3.4 事件管理

•OP-11:原始设备制造商和第三方供应商应该建立一个事件处理流程，该流程应该至少每年进行测试和修订，并且在发生重大变化时尽快进行。

•OP-12: OEM和第三方供应商应该考虑建立产品安全事故应变小组(PSIRT)及电脑保安事故应变小组(CSIRT)每个小组将分别致力于处理与产品和基础设施相关的安全事件，如果有SOC，则与SOC一起工作。

•OP-13:向后端服务器报告事件，确保系统在其生命周期内是安全的。

•OP-14:定义并分类相关网络安全事件，以便能够识别最关键的事件并根据其潜在影响或更广泛的影响(例如)确定其优先级。

•OP -15:考虑建立一个安全可靠的检测和处理过程其电台行为不当，例如撤销其电台行为不当的凭证。

4.4 技术实践

除了上述的政策和组织惯例外，还应实施一套技术安全措施，以保护智能汽车和相关的后端系统。下面，我们将概述这些技术实践，包括软件安全、云安全、检测、访问控制等几个方面。

4.1.1 检测

•TM -01:在车辆和后端级别部署入侵检测系统(IDSs)，以检测恶意活动或策略违规。

•TM -02:维护受适当保护的审计日志，以防止其泄露给未经授权的实体，同时明确定义其存储位置和保存期限。

•TM -03:考虑定期检查网络日志、访问控制权限和资产配置。

•TM -04:执行数据验证，检查输入信息的正确性。

•TM -05:定义适当的取证程序，以支持事件重建，促进事故调查，防止类似的攻击和/或出于问责的目的。

4.4.2 网络和协议的保护

•TM -06:通过相互认证和访问控制机制保护远程监控和管理接口，防止对智能汽车系统的非法访问。

•TM -07:保护所有关键的车内内部通信的完整性和真实性。

•TM -08:保护智能汽车与它所交互的所有不同实体之间的所有外部通信的完整性和真实性。

•TM -09:针对不同的通信会话(例如管理)实施会话管理策略，以避免会话劫持。

•TM -10:时间戳所有使用可靠的时间源(例如，由安全的嵌入式组件或来自卫星系统)交换的消息，以减轻重放攻击。

•TM -11:管理无线电频率和信标54和其他重复消息的频率，以防止分布式DoS (DDoS)攻击。

•TM -12:实施频率灵活性功能，以防止信号干扰，如果适用的话。

•TM -13:在不同的层(如ECU和传感器、移动网络通信等)进行数据包过滤，分析传入和传出的数据包，丢弃不合理的流量。

•TM -14:为敏感数据提供端到端的保密和保护使用安全协议的完整性。

4.4.3软件安全

•TM -15:保护设备和服务的默认配置，确保设备(或服务)默认使用最安全的操作模式。

•TM -16:安装前确保软件的真实性和完整性，确保只使用正版软件。

•TM -17:根据组织基于风险分析制定的变更管理政策，实施和记录配置中的变更。

•TM -18:OTA固件安全更新，避免固件操作、泄露或回滚到易受攻击的版本

•TM -19:定义一个安全的OTA更新流程。

•TM -20:实现安全启动过程，确保系统的完整性和真实性。基于风险的方法可以用来确定什么时候确实需要安全引导。

•TM -21:确保软件依赖的漏洞和限制，特别是开源库，在风险评估中得到缓解或解决。

•TM -22:保护移动应用程序不受逆向工程(例如通过代码混淆技术)和二进制代码篡改(例如通过签名)的影响。

•TM -23:在移动设备上安全存储敏感数据(如密码)，保护移动应用创建的本地文件。

4.4.4  云安全

•TM -24:在与云安全提供商的协议中涵盖安全性和可用性方面，如果适用的话。

•TM -25:在基于云的应用程序和集中系统的环境中，确保防止单点故障。

•TM -26:在private56或至少是hybrid部署模型中运行关键系统和应用。

•TM -27:保护云中的所有数据，并在传输过程中确保云服务提供商不能访问解密密钥，从而降低云攻击带来的任何潜在风险。

4.4.5 密码学

•TM -28:加密所有敏感的、个人的和私人的数据，以防止其泄露给非法实体。此外，在确保个人资料的机密性的同时，可能会使用经认证的加密技术，以避免对个人资料的处理。

•TM -29:使用众所周知的、标准化的密码方案和协议广泛认为是安全的，并避免使用专有方案。

•TM -30:使用存储加密来保护用户的数据以及加强智能车安全所需的数据(例如使用的密钥、安全证书等)。

•TM -31:实施安全的密钥管理流程。该过程应该涵盖密钥生命周期的所有步骤:根据密钥生命周期选择密钥长度、使用来自可靠来源的适当熵级别生成密钥、安全的密钥存储、密钥旋转和撤销等。

•TM -32:考虑使用专用的和防篡改的硬件安全模块安全执行加密算法和安全密钥存储。

4.4.6 访问控制

•TM -33:在后端服务器上应用安全控制;包括策略、物理和逻辑安全方面，以及内部网络和数据的安全。

•TM -34:应用最少特权原则，使用个人账户访问设备和/或系统。

•TM -35:通过开发一套控制和监控远程通信的规则来隔离远程访问。

•TM -36:允许并鼓励使用强大的认证机制，如多因素认证(MFA)、定义账户锁定功能等。

•TM -37:对GNSS系统实施差异监控，以确保准确的本地化数据。

•TM -38:在不同级别(如设备、网络、后端等)上应用加固方法，以减少攻击面。

•TM -39:加强接口的健壮性，例如应对缓冲区溢出或模糊。

•TM -40:考虑使用可信的软件技术，在运行时加强应用程序隔离。

•TM -41:应用系统、子域和网络隔离，在适当的地方使用物理和逻辑隔离技术(基于风险评估)。

4.4.8(半自治)系统的自我保护和网络弹性

•TM -42:考虑使用内置惯性导航系统(INS)或现有的航迹推算方法来获取定位数据，即使是在GNSS失效的情况下

•TM -43:保护关键的自动传感器，防止旨在改变智能汽车环境感知的不同攻击。

•TM -44:加强对抗攻击，防止AI和ML组件被欺骗。

•TM -45:防止人工智能和ML方面的数据伪造或操纵。

•TM -46:使用数据冗余机制(如传感器数据融合)，在做出决定之前，将从车辆不同传感器获得的数据与通过V2X通信获得的数据进行关联。

•TM -47:通过添加额外的硬件组件来使用硬件冗余机制能够执行所需的操作和自动驾驶任务。

4.4.9操作的连续性

•TM -48:确保通知易于理解，并帮助用户找到补救措施或解决方案。

•TM -49:创建业务连续性计划(BCP)和业务恢复计划(BRP)，覆盖第三方方面，并定期测试，至少每年一次，以确保智能汽车系统的弹性。

•TM -50:为组织的业务连续性定义重要的参数，例如恢复时间目标(RTO)、最大可容忍停机(MTO)等。