【车联网】整车信息安全工程师工作手册
刷到过很多公众号发布的文章，讲车企整车信息安全做法，但是很多都是讲的V模型方法论，譬如第一步做TARA分析，然后分解需求，然后验证需求
但实际上，整车信息安全工程师要做的远不止这些，整车二字，意味着所有的工作都围绕着整车开发的生命周期，在不同的项目节点，整车信息安全工程师都有不同的内容和重点
首先声明，每个车企内的开发流程略有不同，本文所有观点仅限于笔者个人经历
一、立项前期
在立项前期，核心工作是填写项目材料辅助立项
譬如技术可行性评估，整车信息安全工程师要填写车型信息安全初步方案，结合当前现状如何才能满足GB 44495/R155的技术要求
譬如项目投资预算表，整车信息安全工程师要测算项目满足GB 44495/R155需要的合规开发费，控制器信息安全开发费通常由控制器工程师根据供应商报价自行测算
譬如法规可行性分析，整车信息安全工程师要根据当前车型或法规升级的车型的现状，判断GB 44495/R155法规是否已满足，如果不满足，整改措施和周期以及费用
譬如项目一级计划，整车信息安全开发属于法规项，所以整车信息安全工程师要和法规认证部门对齐信息，比如什么时间开始公告认证，当前认证节点对信息安全开发是否有风险等，经常要经过多次沟通才能锁定一个最终的可接受的时间
二、计划编排
在正式立项之前，项目组释放项目一级计划，一级计划内容通常包括开发节点（P1-P8），造车节点（OT、VFF），公告认证（认证参数收集、认证样车发运，公告测试开始）
整车信息安全工程师需要结合项目一级计划编排信息安全二级计划
整车信息安全的二级计划制定需要对齐三根线：项目一级计划线、整车软件基线计划线、造车节点计划线
对齐一级计划线判断在什么节点哪些人需要完成什么事情，譬如按照一级计划线规定所有控制器在4月20日必须完成信息安全软件功能开发，6月20日必须完成整车信息安全验证测试并提交报告等等
对齐整车软件基线计划线判断某个版本的整车基线控制器的信息安全功能开发进度，进而判断信息安全开发整体的进度是否存在风险，如果有风险需要及时提出
对齐造车节点计划线判断什么时间会有实车进行信息安全测试以及信息安全测试的周期
除了整车信息安全计划外，还有系统层级的IDPS-VSOC计划
系统层级的开发计划仍然需要对齐四根线：整车信息安全二级计划线、整车软件基线计划线、造车节点计划线、对手件软件基线计划线
对齐整车信息安全二级计划线是要在整车信息安全验证测试之前完成所有IDPS节点的部署以及和云端VSOC平台之前的通信调试，使整车具备法规要求的网络安全攻击事件检测能力，支撑整车信息安全验证测试
对齐整车软件基线计划线是明确每一版整车软件基线版本IDPS的功能状态，是否有BUG
对齐造车节点计划线是在判断何时在实车环境验证IDPS功能
对齐对手件软件基线计划线是保证IDPS能够被正确组入整车软件基线版本，防止某版整车软件基线并未携带IDPS组件，IDPS对手件通常包括：车机、TBOX、网关、自驾，VSOC平台对手件通常是TSP
譬如某版整车软件基线时间是6月20日，这是所有控制器软件版本的目标，这一版软件是生成车间装车造车使用，所以需要尽可能的规避BUG，所以车机（或TBOX等）可能计划在6月18日出一版软件，留下两天时间对功能进行测试，保证软件基线不出问题，所以这就要求IDPS在6月18日之前就要完成代码开发和代码编译，释放IDPS软件给车机
所以IDPS的开发计划，一定需要对齐对手件的软件版本计划
有一点需要注意：计划是在某一个阶段内实现什么清晰的目标，并推进实现目标，但开发过程中不可避免的遇到未知因素，所以计划不会是一成不变的，是会根据开发过程中的进展进行动态调整
三、方案设计
项目正式立项后，进入V模型左侧顶端，核心工作是设计信息安全技术方案
这一阶段，需要获取到整车功能清单进行整车TARA分析，将信息安全需求分解到车端每个ECU控制器，并依次和控制器进行需求握手，收集供应商对需求的满足程度以及根据实际情况对需求进行适当调整
但这一步的需求分解可能并不会顺利，因为整车TARA分析依赖于整车功能清单，整车功能清单在项目立项初期并不会释放，而立项初期同时也是控制器准备定点采购的时期，供应商需要输入信息安全需求评估费用和开发周期，所以会产生一个问题：整车信息安全工程师无法在控制器定点过程提出精准的需求，就可能会导致供应商虚高报价，或者定点后无法满足信息安全需求
对于这个矛盾，笔者以为或许可以通过“先繁后简”的方法
首先，整车信息安全工程师需要整理一份涵盖信息安全法规的信息安全需求基线库，这个库里面有对整车的需求，也有对控制器的需求
接着，整车信息安全工程师向所有控制器收集信息安全属性信息，譬如硬件是否存在调试接口，是否有USB接口，是否可以远程升级，是否有操作系统，是否需要存储密钥，等等
然后整车信息安全工程师通过收集到的属性信息，从需求基线库中筛选需求，譬如某个控制器没有USB接口，那么从基线库中将USB相关的需求删除，有硬件调试接口，那么从基线库中将调试接口相关的需求勾选
如此，形成对每个控制器的初版信息安全需求，可以支持控制器进行需求分析
等到整车功能清单释放后，进行整车TARA分析，将TARA分析后的需求和初版进行比对，进行小范围的更改
这种方法更灵活，不依赖于整车TARA分析，但不可否认，这样的需求并不精确，但这样的好处是，整车TARA分析后的需求只会比初版需求少，不会多，就意味着信息安全需求更全面，可以对控制器进行适当的需求删减
这种方法有两个前提：
- 整车信息安全工程师有涵盖信息安全法规的信息安全需求基线库，并且能够持续维护更新
- 整车信息安全工程师收集的信息安全属性很全面，不会遗漏
这两点仅靠车企内的工程师可能有些捉襟见肘，但如果有相关的信息安全供应商，就会容易的多
需求确定后，需要让供应商根据信息安全需求编写开发规范，整车信息安全工程师审核，确保供应商的开发方案能够满足信息安全需求
除了控制器的信息安全技术方案外，还有IDPS-VSOC技术方案
车端IDPS通常部署在车机、TBOX、网关、智驾智能操作系统内，在本阶段，就要设计IDPS的技术方案
譬如IDPS自身架构，主从架构还是分布式架构，如果是主从，哪个控制器是主哪个控制器是从，主和从之间如何通信；如果是分布式，如何做到分布式
譬如IDPS联网方案，如何在系统内上网
譬如CAN IDS数据上报方案
只有方案确认好了，下一步才能顺利开发
四、需求开发
车端ECU信息安全需求和开发方案以及IDPS-VSOC方案锁定后，按照方案推进开发
这个阶段，整车信息安全工程师最容易犯的一点错误是，只规定了信息安全全功能实现的节点，对ECU供应商信息安全开发进度不管不顾，因为从CSMS体系要求来看，体系对需求锁定后的代码开发过程并没有要求，但实际中，整车信息安全工程师至少要通过整车软件基线统计整车信息安全整体的开发进展，通过开发进展识别对信息安全后续活动是否产生影响，譬如整车信息安全验证测试是否能按照预期时间进行
整车信息安全工程师虽然不参与控制器的代码开发工作，但是从整车项目开发角度，信息安全开发的中间过程作为整车功能开发的子过程需要有管控动作
这一阶段整车信息安全工程师的重点聚焦于资源协调层面，譬如供应商开发过程中有疑问难点或者需要主机厂输入规范材料，譬如IDPS开发所需要的控制器样机，线束需求，譬如开发过程中遇到的BUG需要其他控制器协调参与的等等
整车信息安全工程师要确保在规定的信息安全全功能实现的节点之前，所有控制器和IDPS都完成了功能开发
五、需求验证
这一阶段进入V模式右端，对前期释放的信息安全需求进行验证测试，测试是否符合信息安全需求
同样的，需求验证需要对齐整车软件基线计划线
在某一个整车软件基线开始整车信息安全测试，对于测试的不符合项，进行记录，并知会相关方，同时定期召开信息安全问题总结会，综合讨论信息安全问题的根因和解决措施，并针对问题修复的版本达成一致
下一个整车软件基线开始整车信息安全回归测试，测试前一次的不符合项
对于IDPS的验证，同样也是按照软件基线推进
除了在台架上测试外，实车环境同样有必要测试，因为台架环境和实车环境可能存在不同之处
IDPS验证重点关注安全事件监测功能和车云通信日志上报功能
其中车云通信实车环境至少要考虑三种场景：
- 车机关闭了WIFI
- 车机从休眠环境下唤醒
- 车辆信号被屏蔽后恢复信号
这三种场景下都要求IDPS保持稳定的车云通信连接
笔者曾遇到过车机从休眠唤醒后系统网卡名称变更，IDPS无法获取最新的上网网卡，导致唤醒后无法连接VSOC平台
六、体系运行
整车信息安全工程师面向的是GB 44495和UN R155法规，两个法规都要求主机厂编制网络安全管理体系
所以整车信息安全工程师在推进整车信息安全开发的过程中，还需要注意按照企业编制的汽车网络安全管理体系要求进行运行记录的填充
譬如立项初期，车辆的电子架构图释放，整车信息安全工程师按照电子架构图识别每个ECU控制器对应的负责人，形成管理体系要求的《网络安全小组清单》
譬如供应商定点时要求供应商签署《网络安全接口CIA协议》，信息安全需求锁定后供应商编写《控制器网络安全开发规范》
以上等等体系文件，通常在管理体系内《汽车网络安全生命周期管理办法》文件内有详细的描述
公告认证启动时，认证机构通常就会审查车辆的信息安全开发是否按照网络安全管理体系进行，是否具备管理体系文件内规定的运行记录文件
整车信息安全工程师不仅仅只是进行整车TARA分析释放需求验证需求的方法论而已，整车信息安全开发作为整车功能开发的子功能，贯穿车辆整个生命周期，需要按照整车开发节奏一步一步推进，其中的跨多个部门，多个操作系统，多个信息安全场景，是考验整车信息安全工程师综合能力的战场