青骥原创编译 | Auto-ISAC汽车信息安全最佳实践·8：《汽车信息安全SDL最佳实践指南》

来源：公众号“汽车信息安全”

2020-05-12

1985

本系列最后一篇将从开发的视角与您分享汽车信息安全所关注的要素。本期统筹编译为公益翻译团荣誉创始成员黄镇@theoneandone 和 @龚桓毅 同学，校稿为荣誉创始成员 韩方旭@油落西裤 ，为他们的无私奉献点赞。

本篇概述

欢迎大家来到AUTO-ISAC BP系列的最后一篇《安全开发生命周期》，也就是我们常说的SDL, 汽车的SDL是基于之前描述的六个最佳实践指南，并将它们集成起来，其中的关键信息作为汽车SDL原则的参考。本篇是以汽车研发全生命周期开发为基础的，对于传统信息安全试图了解汽车研发流程是非常有帮助的，下面开始我们顺着文档的思路重点给大家介绍。

汽车SDL有哪些关键要素和特点？

Safety 关键系统	驾驶员、乘员和道路使用者的safety是系统设计的重点。对于安全关键系统，在极端情况（事故，规避操作，极端天气）下需要保证操作的可靠性。
共享组件	通常汽车开发中会有很大的组件重用(相同/相似的ECU在不同的制造商和模型)，因此重用组件(旧车型年份)的脆弱性也可能影响仍在开发中的新车型
长生命周期	OEM开发一个新产品平均需要大约4年的时间，一辆汽车可能会投入生产好几年。
长消费周期	即使车辆已经停产，由于司机的持续使用，OEM可能在较长的时间内要保证车辆安全。乘用车的平均寿命为8年或更长，而商用车的平均寿命可能更长，在这段时间内维护安全是一项挑战
高度复杂的系统	车辆有许多电子控制单元(ECU)，每个单元都结合了硬件、软件和固件，还包括多个内部车辆网络(如can、Flexray、Ethernet)和外部接口(如Wi-Fi、蓝牙，近场通信(NFC))。现代车辆上的软件规模(大约1亿行代码)正在增加，而种类繁多的车载操作系统的模块化又增加复杂性。与此同时对于汽车而言，还有严格的实时需求(保证/确定/实时方法)和严格的可用性需求(快速启动、低延迟等).
高度受限制的操作	环境常常限制了微处理器的计算能力、数据存储和网络带宽，这对于在生产后期添加相应策略是个挑战。此外，车辆需要在认证经销商，OEM服务中心和第三方维修店能够维修和校准等。车主可能不会进行定期的维护和软件/固件更新。此外，车辆所有权经常变化，很难追踪。车主的人口是多样化的，不受OEM的限制
复杂供应链	汽车开发包含全球多个供应商，多个车辆ECU也有可能由Tier1和OEM同时开发

汽车全生命周期开发流程

对于汽车SDL开发流程来说，包括概念阶段、设计阶段、开发阶段、验证阶段、生产阶段，最后是运维阶段和报废阶段，不管是ISO 21434，还是SAE J3061基本都是按照以上阶段描述关键阶段和信息安全需求。对于汽车信息安全从业人员来说对每个阶段的工作重点要所有了解。概念阶段主要确定保护对象，可采用分层次分类别的方式，对安全保护对象进行分解。识别每个对象所面临安全威胁，明确这些安全保护对象的安全保护目标，确定需要遵从哪些安全标准和法律规定，需要满足哪些定制化安全需求，从而定义出本产品的安全技术需求。开发阶段主要明确安全设计思想，细化安全技术需求，设计出相应的技术解决方案。在开发过程中遵循SDL的安全开发流程，按照相应的信息安全编码规范，并使用置信度较高的安全工具进行安全设计、安全开发等一系列活动，从而开发出能够满足信息安全设计规格的产品。测试验证阶段主要目的是为在确保研发的产品与信息安全要求、设计的一致性、正确性、完整性，通过不同测试环境、不同测试工具的综合性测试来发现产品的信息安全脆弱性，进而保证产品的安全性。生产阶段主要是为了满足生产过程满足设计开发提出的信息安全需求，而且不引入新的安全漏洞。

各阶段重点内容

在本文档中，汽车SDL的每个重点领域被分解为四个子部分：相关者、输入、流程和输出。一个阶段的输出作为下一个阶段的输入，以此创建一个整体的方法帮助具有不同网络安全能力的组织应用结构化的方法来构建或改进SDL。由于本篇重点以SDL为主。

3.1 需求设计

确定汽车网络安全目标是得出网络安全要求的第一步。目标可能是提供不允许对汽车控制系统进行未经授权操纵的产品或将车辆盗窃数量减少到零的产品。这些看似简单的目标推动了识别控制系统、相关攻击面、访问控制机制等方面的研究。研究人员可以结合其他需要满足的目标，开发了一系列需求合集，并可以针对特定的车辆电气架构及其连接的组件进行定制在需求设计过程中我们需要输入什么？首先是网络安全原则，基于安全原则的安全架构可以提供分层的网络安全防御，其目标是使攻击者不值得花费时间或资源来尝试漏洞利用和攻击开发。风险评估结果，组织可能使用风险分析来确定安全目标，进而确定安全需求，然后确定设计的安全体系架构，最后是安全的设计和开发过程，这通常以并行和迭代的方式完成。最后是产业标准，在需求梳理之初就需要考虑合规性需求。在此过程需要做的是威胁建模，它是可能对Security产生影响的所有信息的结构化表示（更多详细的内容可以参考OWASP和微软的SRIDE），因此，威胁建模是使用汽车SDL保护产品的最直接和最有价值的方法之一。它直接利用项目设计，并以安全为中心指导设计决策。一旦知道了设计中所有元素的各种威胁，就可以在项目的早期做出对应的决策，进而得出安全需求和安全设计。威胁建模几乎与项目的每个阶段都有相关性，这也决定了威胁建模是一个迭代过程，如需求阶段就会包括多轮威胁建模。

3.2 设计

此阶段的工作重点是基于前期定义的安全需求分解，然后进行设计开发，重点包括以下内容： 需求分解：在设计过程中，组织可以将需求分解成更小的可管理和可测试的小需求，一般在安全需求的某些部分将在另一需求中使用时会发生这种情况。如果期望从需求中派生出额外的需求，那么分解需求也会有所帮助。这一步可以为汽车SDL提供分层的方法以及较好的可读性和可追溯性。安全控制设计：安全控制设计可以借鉴事件响应和漏洞管理流程、行业最佳实践指南、汽车行业或类似行业(如医疗、航空、物联网)中的历史问题等方面的经验教训和其他情报。在设计阶段，能够帮助组织设计的安全控制措施包括设计、访问控制、密钥管理等网络安全策略。组织应考虑在设计阶段采取适当的控制以加强系统的网络安全。安全设计审查：安全设计审查有助于确保系统设计体现了安全需求、相关的安全标准以及安全设计原则。一个整体的系统设计安全审查也有助于确定系统外的其他漏洞，如在ECU中挑战-响应认证机制的种子随机性不够强，同时它还可以作为包含阶段的入口。设计审查通常作为处理过程中设计阶段的出口，安全设计审查将是设计审查的前奏和输入。在安全设计审查阶段确认的问题也需要评估风险，组织也可以从其中学习经验教训。在OEM安全设计审查期间，OEM可以在安全体系结构中确认供应商对其组件上下文的假设，并理解实现的深度防御控制。

3.3 开发

在需求和设计阶段中对安全的关注能够推动安全汽车开发、集成和生产。虽然这些基本阶段(需求和设计)是构建整体安全产品的核心，但在开发过程中，由于实施人员、过程或技术等原因，那些以安全为重点的需求和设计时可能会出现错误。使用安全实施最佳实践可以确保在实现过程中，最大满足需求分析和安全设计。安全软件开发：为了确保安全的软件开发实践在开发人员的头脑中处于最重要的位置，团队应该与项目和组织需求保持一致安全配置：需要实现安全配置，并遵循默认安全原则和最低权限原则，如为ECU审查防火墙规则，在项目的早期阶段应用最严格的防火墙规则，定期检查防火墙规则并记录必要的、不可避免的例外情况。通常，对配置安全性的审查应该是测试计划的一部分。安全编码：安全编码实践始于OEM定义供应商和内部开发人员需要遵循哪些实践的期望，以及需要提供哪些证据来确保遵循这些实践。由于OEM通常不能直接看到代码或拥有代码，因此必须考虑如何确保OEM作为系统所有者，对安全编码应用有足够的洞察力或把握，这也包括在工作说明书和/或标准条款和条件中。OEM或已经明确定义了审计、执行威胁检测和响应(TDR)或执行抽查的方法。软件的可追溯性：为了减少风险，组织可以要求在所有的开发组件中包含详细的物料清单(BOM)，以便进行跟踪。这个详细的BOM可以映射到特定车辆上的VINs和ECU序列号。

3.4 测试与验证

信息安全测试：实际的测试发生在产品的实现阶段期间和之后的多个迭代中。网络安全测试是一种重要的“health check”，体现了正确实施了安全需求，并在发现漏洞后为剩余风险评估提供输入。在车辆及其生态系统的实现过程中，在计划的关键节点处进行网络安全测试有助于公司确保计划的安全措施是有效的、识别潜在的漏洞，并在车辆部署之前纠正这些漏洞。发现的漏洞越早，用于补救的时间和预算就越少。内部信息安全验证：内部信息安全验证流程是向开发项目的相关者提供最终确认的一种方式，确认所有与安全相关的工作都已完全完成。这将确保网络安全控制得到适当实施、常见漏洞得到评估并在必要时得到修复、网络安全测试已经完成且符合预期。在整个产品生命周期的计划里程碑上，可以对每个组件/软件开发项目执行此确认。

3.5 生产与运营

关注汽车开发生命周期的每个阶段的安全性可以生产出安全的汽车。然而，在产品的生命周期中保持产品的安全性存在着开发后的挑战。其中一些挑战包括车辆的长生命周期、适用性和维护。这些挑战可以在早期考虑，并可能影响车辆及其部件的要求和设计。尽管将安全性设计到产品中是在产品从生产线上生产出来之前很久就开始了，但是值得注意的是，维护过程为开发过程提供了有价值的反馈。其中一些后期生产过程可以为未来的安全产品设计提供信息，包括事件响应、漏洞管理和安全监控。这些过程可以扩展到单个产品之外，并可以增强组织的整体安全态势。从这些挑战中获得的经验教训可以应用到汽车SDL过程的需求和设计阶段，以帮助持续改进安全性以上就是今天要介绍的汽车安全声明周期SDL，集成了前面六篇的关键要素，对于整车开发流程或者汽车全生命周期的安全工作也有了整体的概念。从执行摘要到现在的SDL，我们连续八篇文章描述了AUTO-ISAC BP系列，这个系列偏管理，偏实践，对于试图了解汽车信息安全工作的同学来说，希望有所帮助。最后感谢大家的关注和支持，后续我们将会持续更新，谢谢！

--主编: 杨文昌@VincentYang

下为全文预览