4、项目级管理：网络安全计划、裁剪、评估与审计
好，我们进入第4章。前面聊了组织层面的网络安全管理和文化，现在要落到具体项目上了。
说白了，ISO 21434 不是让你把一套流程死板地套在所有项目上。一个车载信息娱乐系统和一套制动控制系统的安全风险能一样吗？肯定不能。所以，项目级管理的关键词是：量身定制。
我个人习惯，接手一个新项目，第一件事不是看代码，而是先看这个项目的 网络安全计划。没有这个计划，后面的工作全是乱的。
4.1 网络安全计划：项目的“作战地图”
网络安全计划（Cybersecurity Plan）是项目启动时的第一个交付物。它定义了整个项目生命周期里，谁、在什么时候、做什么、产出什么。
我见过一些团队，上来就写代码，做到一半才想起来“哦，我们好像需要做个TARA”。结果发现架构已经定了，改起来成本巨大。这就是典型的没有计划。
一个合格的网络安全计划，至少应该包含以下内容：
| 要素 | 说明 |
|---|---|
| 安全目标 | 这个项目要达成什么样的安全等级？防止哪些攻击路径？ |
| 角色与职责 | 谁是安全经理？谁是安全工程师？谁负责评审？ |
| 活动与里程碑 | 什么时候做TARA？什么时候做安全测试？什么时候做审计？ |
| 交付物清单 | 需要输出哪些文档？比如威胁分析报告、安全需求规范、测试报告。 |
| 裁剪决策 | 哪些活动可以简化？哪些必须严格执行？理由是什么？ |
4.2 裁剪：别拿大炮打蚊子
裁剪（Tailoring）是 ISO 21434 里非常务实的一个概念。标准本身是通用的，但你的项目是具体的。一个只有几个工程师的小型控制器项目，和一个几十人团队开发的域控制器项目，流程复杂度肯定不一样。
裁剪不是让你偷工减料，而是让你基于风险评估的结果，合理地调整活动的深度和广度。
我曾经在一个后装OBD设备项目上，客户要求完全按照最高安全等级走流程。我评估了一下，这个设备根本不涉及车辆控制，只读取排放数据。如果硬套全流程，成本翻倍，周期拉长，完全没有必要。后来我们通过裁剪，只保留了数据通信安全和隐私保护相关的活动，客户也认可了。
裁剪时，你需要考虑几个因素：
- 攻击可行性： 攻击者需要多大的成本才能攻击这个组件？
- 影响程度： 攻击成功后，对人身安全、财产、隐私的影响有多大？
- 组件类型： 是安全关键件（如制动、转向）还是非安全关键件（如娱乐系统）？
- 开发现状： 是全新开发，还是基于现有平台的复用？
裁剪的决策必须记录在案。审计的时候，这是必查项。如果你裁剪了某个活动，但拿不出合理的理由，那审计师会直接给你开一个不符合项。
4.3 网络安全评估：别等到最后才“验货”
网络安全评估（Cybersecurity Assessment）不是一次性的活动，它贯穿项目始终。我把它分为三个层次：
- 自评估： 开发团队自己检查，比如代码走查、单元测试中的安全用例。
- 同行评审： 找其他项目的安全工程师来评审你的TARA或安全设计。旁观者清，很多自己看不出来的问题，别人一眼就能发现。
- 独立评估： 由独立于项目组的第三方或内部审计团队进行。这是最严格的，通常用于关键里程碑或最终发布前的确认。
评估的核心是验证：我们声称的安全目标，是不是真的实现了？
4.4 网络安全审计：流程的“体检报告”
审计（Audit）和评估（Assessment）不一样。评估是看“产品安不安全”，审计是看“流程走没走对”。
审计师会问你：
- 你的网络安全计划在哪里？
- 裁剪的理由是什么？谁批准的？
- TARA的评审记录在哪里？
- 安全需求的变更流程是怎样的？
- 测试报告和需求能对应上吗？
嗯，这里要注意。很多团队产品做得很好，但文档一塌糊涂。审计师看不到证据，就会认为你没做。所以，“没有记录，就没有发生” 这句话，在汽车网络安全领域是铁律。
4.5 项目级管理核心流程
为了让你更直观地理解，我画了一张图，把项目级管理的几个核心环节串起来。
你看，整个流程是闭环的。从计划开始，到裁剪，到执行，再到评估和审计，最后归档。任何一个环节出了问题，都要回溯到计划层面去调整。
4.6 总结一下本章的核心
- 计划先行： 没有计划，就没有管理。
- 裁剪要合理： 基于风险，而不是基于感觉。
- 评估要客观： 用证据说话，而不是拍胸脯。
- 审计要严格： 流程合规是底线，记录是生命线。
我个人觉得，项目级管理最考验的是一个团队的“工程纪律”。技术可以学，工具可以买，但纪律和习惯，需要长期培养。希望这一章能帮你建立起这个意识。