2. 应急响应组织架构：CSIRT的组建、角色与职责、跨部门协作机制
好，咱们接着聊。上一章我们讲了应急响应流程的总体框架，这一章我重点说说“人”的问题。
你想想看，流程再完美，如果没人去执行，那就是一纸空文。车载安全应急响应，说白了就是一场“抢修战”。谁负责指挥？谁负责排查？谁负责修车？谁负责对外沟通？这些必须提前定好。
我个人习惯，在项目启动的第一天，就把CSIRT（计算机安全应急响应团队）的架子搭起来。别等到漏洞爆了再临时拉人，那时候就晚了。
2.1 CSIRT的组建：别搞成“草台班子”
很多公司刚开始搞车载安全，应急响应团队就是“谁有空谁上”。嗯，这其实是个大坑。我在项目中遇到过，有一次OTA升级包被篡改，结果发现负责签名的同事正在休假，临时找人顶替，光交接就花了半天。
所以，CSIRT必须是一个常设机构，哪怕平时不干活，也得有明确的编制和备选方案。
组建时，我建议至少包含以下几类角色：
- 核心成员：全职或半全职，负责日常监控、事件研判、技术分析。
- 扩展成员：按需加入，比如某个ECU的底层驱动工程师、云端平台的运维人员。
- 外部专家：芯片供应商、Tier1的安全顾问，必要时可以远程支援。
关键点：CSIRT的规模不是越大越好。我见过一个团队，光“观察员”就拉了20个人，结果开会时七嘴八舌，反而延误了决策。核心团队控制在5-7人最合适。
2.2 角色与职责：每个人都要知道自己该干嘛
角色定好了，职责必须清晰。我最怕听到的一句话是：“这个事你看着办吧。”在应急响应里，模糊就是灾难。
下面这张表，是我在多个项目里反复打磨过的，你可以直接拿来用：
| 角色 | 职责描述 | 避坑指南（我的经验） |
|---|---|---|
| 应急响应经理 | 统筹全局，协调资源，对外汇报，做决策。 | 我曾经让一个技术大牛当经理，结果他总想自己动手修漏洞，忘了指挥。经理不需要懂所有技术细节，但必须懂流程。 |
| 安全分析工程师 | 分析漏洞根因，复现攻击路径，提取IOC（入侵指标）。 | 这个角色最累。我建议至少配2人，可以互相复核，避免误判。 |
| 固件/软件工程师 | 负责打补丁、改代码、做OTA升级包。 | 注意！他们不能直接修改生产环境代码，必须走变更流程。我见过有人为了赶时间，直接在产线服务器上改代码，差点把整个批次搞废。 |
| 法务与合规 | 评估法律风险，决定是否上报监管机构（比如UN R155要求）。 | 这个角色容易被忽略。其实很重要，因为有些漏洞不报是违法的。 |
| 公关与客户支持 | 对外发布公告，安抚客户，处理媒体问询。 | 记住：永远不要对客户说“我们还在调查”。哪怕只说一句“我们已经发现并正在处理”，也比沉默强。 |
小技巧：每个角色都要有一个备份人。我习惯在团队里搞“AB角”制度，A角休假或生病，B角能无缝顶上。别问我为什么，有一次半夜三点出漏洞，A角电话打不通，B角顶上后，我才发现平时没让他参与演练，结果手忙脚乱。从那以后，每次演练我都要求AB角同时参加。
2.3 跨部门协作机制：别让信息“断在墙里”
车载系统太复杂了。一个漏洞可能涉及T-Box（远程通信模块）、IVI（车载娱乐系统）、网关、甚至云端。如果各部门各自为战，那应急响应就变成了“猜谜游戏”。
我总结了一套协作机制，核心就三个字：快、准、通。
2.3.1 建立“战时”沟通渠道
平时大家用邮件、企业微信都行。但一旦进入应急响应状态，必须切换到专属频道。
- 即时通讯群：拉一个“应急响应XX事件”的临时群，所有核心成员必须在线。我要求群内消息5分钟内必须回复，哪怕回一句“收到，正在排查”。
- 每日站会：如果事件持续超过24小时，每天早上9点开15分钟站会。每个人只说三件事：我昨天做了什么、今天打算做什么、有什么卡点。
- 决策升级机制：如果某个问题在30分钟内无法解决，必须升级给应急响应经理。别自己闷头搞，我曾经见过一个工程师为了修一个CAN总线问题，自己搞了3小时，结果发现是云端配置错了。
2.3.2 信息共享的“唯一真相源”
应急响应最怕信息不一致。安全分析工程师说“漏洞在网关”，固件工程师说“我查了网关没问题”，结果两个人用的日志版本都不一样。
我建议建立一个共享文档（比如Wiki或在线表格），里面记录：
- 事件时间线（精确到分钟）
- 已发现的IOC列表
- 当前排查结论（谁、什么时候、确认了什么）
- 待办事项清单（负责人+截止时间）
警告：这个文档必须实时更新。我见过最离谱的事，是安全团队在文档里写“已确认漏洞根因”，但固件团队没看到，还在重复排查。浪费了整整半天。所以，我要求每次更新后，在群里@所有人。
2.3.3 与外部供应商的协作
车载系统里，很多模块是供应商提供的。比如T-Box可能是华为的，网关可能是博世的。一旦漏洞涉及他们的代码，怎么协作？
我的做法是：
- 提前签好SLA：在合同里就写明，安全事件的响应时间。比如“接到通知后2小时内提供技术接口人，4小时内提供初步分析”。
- 建立“白名单”通道：把供应商的安全接口人拉进一个专门的群。注意，只拉技术对接人，别拉销售和商务，否则群里全是“这个要收费”之类的废话。
- 共享部分证据：比如把抓到的攻击报文脱敏后发给他们。别藏着掖着，你想想看，供应商比你更懂他们的代码，你不给他们数据，他们怎么分析？
举个例子：有一次，我们发现某个T-Box在特定条件下会泄露车辆位置。我们自己查了三天没找到根因。后来把日志给了供应商，他们半天就定位到是某个GPS驱动库的bug。如果早一点共享数据，至少能省两天时间。
2.4 演练：别让组织架构停留在纸上
组织架构搭好了，角色定好了，协作机制也建了。然后呢？
我建议每季度搞一次桌面推演。不用真的去修车，就是模拟一个漏洞场景，看看大家的反应。
比如，我出个题目：“今天下午3点，测试车队报告，有10台车在行驶中突然失去动力，初步怀疑是OTA升级包被篡改。请各角色开始行动。”
然后观察：
- 应急响应经理有没有第一时间拉群？
- 安全分析工程师有没有去拿日志？
- 固件工程师有没有去查代码版本？
- 法务有没有问“要不要上报”？
演练结束后，一定要做复盘。别走过场，要真刀真枪地找问题。我记得第一次演练时，我们发现公关团队居然没有提前准备“对外声明模板”，结果现场写稿子，措辞不当，差点引发媒体误读。从那以后，我们提前准备了3套不同严重等级的声明模板。
我的习惯：每次演练，我都会故意制造一个“意外”。比如让某个关键角色“失联”，或者让供应商的接口人“临时开会”。看看团队有没有备份方案。说白了，应急响应就是一场“压力测试”，平时多流汗，战时少流血。
好了，这一章就讲到这里。组织架构是应急响应的“骨架”，骨架正了，后面的流程才能跑得顺。下一章，我们聊聊具体的漏洞发现与上报机制——也就是“怎么知道出事了”。