随着智能网联汽车技术的迅速发展，车辆信息安全已成为保障行车安全和保护用户隐私的重要基石。为响应这一趋势，GB44495-2024《汽车整车信息安全技术要求》对车辆制造商提出了明确的持续监控要求。木卫四深入解读该法规中的持续监控要求及其细则范围，并分享在实践中的成功案例，助力行业伙伴共同提升车辆信息安全的整体水平。
法规中的持续监控是什么
01持续监测的定义
强标 5.2
建立确保对网络攻击、网络威胁和漏洞进行持续监控的过程，且车辆纳入监控范围的时间应不晚于车辆注册登记的时间。
基于这一强标要求，木卫四结合过往过审经验，认为持续监控需要车辆制造商建立并实施一套能够实时对车辆信息安全状态监控的系统和运营团队，及时发现、识别和应对网络攻击、网络威胁和漏洞。这包括：
实时检测：对车辆可能受到的网络攻击和异常行为进行实时监控。
数据取证：收集和保存相关的安全事件日志和证据，支持后续的分析和处理。
持续监控：根据新型攻击技术情报，不断优化监测策略和防护措施。
02法规要求的核心要点
根据GB 44495-2024《汽车整车信息安全技术要求》，木卫四总结了如下持续监控的核心要点：
识别能力：具备针对车辆网络攻击的识别能力，能够及时发现并预警。
监控能力：持续监控与车辆相关的网络威胁和漏洞，保持对车辆安全威胁的持续跟踪。
取证能力：在发生安全事件时，能够提供完整的日志和证据，支持事件调查和溯源。
03持续监控的安全风险范围
网络攻击：针对车辆网络系统的攻击行为，如拒绝服务攻击、远控指令重放攻击等。
网络威胁：潜在的安全风险，如调试模式打开、不安全的通信协议等。
安全漏洞：关注车辆系统和组件中的安全漏洞，及时进行补丁和更新。
持续监控实施细则有哪些
根据GB 44495-2024《汽车整车信息安全技术要求》，木卫四从持续监控的实施范围和对象着手，梳理出如下监控事件细则，旨在覆盖并满足强标要求：
01车辆外部连接安全
Event 001
车辆远控指令事件
例如：用于车辆远控功能的通信模块，需监控其网络连接状态和远控指令日志的异常状态。
——覆盖强标 7.1.2
Event 002
车辆物理接口访问事件
例如：USB接口、OBD接口等，这些接口已被用于物理接入车辆系统，需监控其访问和使用日志的异常状态。
——覆盖强标 7.1.4
02车辆通信安全
Event 003
认证/访问失败事件
例如：非法用户尝试登录车辆的远程控制系统，但由于身份验证失败而被拒绝；或用户使用过期凭证试图访问车内通信网络，导致访问失败。
——覆盖强标 7.2.1、7.2.2、7.2.4、7.2.7、7.2.8、7.2.9
Event 004
无线接口连接事件
例如：蓝牙、Wi-Fi、NFC等无线通信接口已成为潜在的远程攻击入口，需实时监控这些接口的连接行为日志，以预防潜在风险。
——覆盖强标 7.2.3
Event 005
拒绝服务事件
例如：攻击者向车载网络发送大量无效请求，导致车载网络超负荷，需要监控关键服务的运行状态。
——覆盖强标 7.2.10
Event 006
加解密失败事件
例如：车载系统在接收远程指令时，由于解密密钥错误导致指令无法正确解密，或车辆内部的加密密钥被篡改，造成数据加解密失败。
——覆盖强标 7.2.5、 7.2.6、7.2.11
Event 007
企业 TARA 分析的其他通信安全事件
例如：某车型特定远程控制功能或软件升级过程中的通信安全事件。
——覆盖强标 7.2.12
03车辆软件升级安全
Event 008
身份认证事件
例如：包含与 OTA服务器建立连接时的身份认证成功/失败事件、签名验证成功/失败、升级密钥错误事件。
——覆盖强标 7.3.2.1
Event 009
加解密失败事件
例如：升级包完整性校验失败事件。
——覆盖强标 7.3.2.2
Event 010
其他升级过程事件
例如：升级版本回退或降级事件、升级包不兼容事件、多次升级失败重试事件等。
——覆盖强标 7.3.2.3
04车辆数据安全
Event 011
关键数据被修改事件
例如：胎压篡改事件、动力电池参数篡改事件、安全气囊展开阈值篡改事件和制动参数篡改事件等。
——覆盖强标 7.4
05安全漏洞持续监测
Event 012
远控和第三方应用外部连接系统漏洞事件
对远控和第三方应用引用的开源组件、第三方库及操作系统进行漏洞跟踪。
——覆盖强标 7.1.1.1
Event 013
车载软件升级系统漏洞事件
对升级软件引用的开源组件、第三方库及操作系统进行漏洞跟踪。
——覆盖强标 7.3.1.2
构建持续监控体系的关键步骤
木卫四依据GB 44495-2024和过往项目经验，提出构建持续监控体系的5个最佳步骤：
01｜构建组织架构
信息安全管理委员会：
该委员会负责战略决策、资源分配与监督，确保VSOC持续监控平台的建设和运营符合GB 44495-2024标准的各项要求。委员会还负责协调各部门资源，以支持信息安全战略的全面实施。
安全运营部门：
专职负责安全策略的制定、实施和管理，确保持续监控平台的技术要求与GB 44495-2024标准保持一致。该部门还负责持续改进监控技术和流程，提升平台的安全监控能力。
跨部门协作机制：
包括IT部门、研发、生产、供应链管理等相关部门共同参与，建立紧密的协作机制。通过整合各方资源和技术能力，确保信息安全监控体系的高效运作，并形成统一的响应机制以应对潜在安全风险。
02｜定义监控场景（USECASE）
参考标准规定：根据GB 44495-2024的具体条款，制定符合要求的监控策略和流程。
确定监控范围：参考标准要求的车辆外部连接、车辆通信、车辆软件升级和车辆数据安全要求，以具体车型的风险评估为具体策略设计，识别攻击与风险，制定针对性的USECASE。
确定数据收集范围：依据监控策略，确定需要收集的日志和事件数据类型，如安全事件日志、系统性能指标等。
确定漏洞监控场景：根据GB 44495-2024安全要求，对远程控制功能的系统、授权的第三方应用以及车载软件升级系统中引用的开源组件、第三方库文件等，建立车辆SBOM库，确保漏洞快速识别和响应。
03｜部署监控系统
车端部署安全日志：根据GB强规要求，在车端控制器上统一部署安全日志收集模块（如Security Log），确保关键数据的实时采集和存储。此模块为安全事件的分析与响应奠定基础，有助于全面满足合规要求。
云端部署监控平台：部署具备持续监控能力的云端平台（如VSOC），提供全方位的异常检测和情报收集服务。平台具备先进的威胁检测功能，并严格遵循标准对数据处理与存储的安全规范。
04｜开展威胁分析和响应
USECAE分析工具：使用安全信息和事件管理系统对海量车辆安全日志进行实时分析，基于预设的监控场景（Use Cases）检测异常，识别潜在威胁。
人工研判：安全专家对识别出的可疑事件进行深度分析，结合具体业务场景评估事件的真实性和潜在风险，确保分析的精准性与可靠性。
威胁情报：从国内外权威漏洞信息平台获取最新汽车领域威胁情报，并与行业伙伴共享，构建更全面的威胁情报网络，以提高安全监控的准确性和前瞻性。
告警和响应机制：建立符合行业标准和企业特殊要求的告警分级系统及响应流程，确保不同严重等级的安全事件均能得到及时、适当的处理和响应。
漏洞处置和修复：制定漏洞处置优先级规则，并实施闭环工单管理流程，确保漏洞在被识别后能够快速得到修复与验证，以降低安全风险。
05｜推动持续改进
安全事件记录与取证：详细记录所有安全事件及处理过程，保留完整的日志和取证数据。这不仅满足数据合规和取证要求，更为未来的安全左移策略提供基础数据支持，促进在开发早期识别和预防安全风险。
经验总结与流程优化：对每个安全事件进行原因分析，从技术和流程上识别潜在漏洞和不足，尤其关注新型攻击模式。制定并实施改进措施，推动安全设计理念贯穿于系统开发生命周期的各个阶段，以提高下一代车型的整体防御能力。
人员培训与模拟演练：不断提升团队对新兴威胁和攻击手段的认知，加强安全设计理念的培训。定期进行包括新型攻击情景的应急演练，提升团队在真实攻击下的响应能力，确保安全防护始终走在威胁前面。
最小化持续监控实践
01网络攻击和威胁持续监控USECASE参考
在GB强标的框架下，已针对车辆外部连接、车辆通信、车辆软件升级以及车辆数据安全提出了详细的安全监控要求，基于这些技术要求，木卫四深入分析了历史上发生的典型汽车网络攻击案例，梳理了以下网络攻击与威胁监控的USECASE用例，供行业内各方参考。
7.1.4 外部接口安全要求
安全事件用例1：
车机连接USB设备异常事件检测
测试方法：
安全事件用例2：
车机连接USB设备异常行为检测
7.1.4.1 应对车辆外部接口进行访问控制保
护，禁止非授权访问。
安全事件用例1：
车机调试口认证监控
测试方法：
1. 多次尝试以错误凭证访问车机调试口
2. 验证调试口是否被锁定，并确认是否生成了事件记录
3. 确认监控平台是否能接收、分析并对该异常行为发出预警
安全事件用例2：
OBD口访问控制异常监控
测试方法：
1. 尝试未经授权访问OBD接口
2. 验证系统是否阻止未经授权的访问并生成相应事件记录
3. 确认监控平台是否能接收、分析并对该异常行为发出预警
7.2.3 车辆应采用完整性保护机制保护除
RFID、NFC之外的外部无线通信信道。
安全事件用例1：
车机蓝牙应用异常行为检测
测试方法：
安全事件用例2：
车机蓝牙异常行为监控 - 配对或连接失败
测试方法：
7.2.4 车辆应具备对来自车辆外部通信通道
的数据操作指令的访问控制机制。
安全事件用例1：
远程控制系统访问控制异常监控
测试方法：
安全事件用例2：
车机无线入侵指令访问控制检测
测试方法：
7.2.10 车辆应具备识别车辆通信通道遭受
拒绝服务攻击的能力，并对攻击进行相应
的处理。
安全事件用例1：
车载娱乐系统以太网拒绝服务攻击监控
测试方法：
安全事件用例2：
TBOX模块以太网拒绝服务攻击监控
测试方法：
7.4.4 车辆应采取安全防御机制保护存储
在车内的关键数据，防止其被非授权删除
和修改。
安全事件用例1：
整车CAN信号异常检测 - 连接超时
测试方法：
安全事件用例2：
网关与ECU配置一致性检查异常检测
测试方法：
安全事件用例3：
车辆行驶时车门异常打开检测
测试方法：
安全事件用例4：
胎压异常值检测
测试方法：
02漏洞持续监控的最小化SBOM清单参考
在汽车行业的智能化服务应用中，OTA升级、远程控制和第三方应用等功能通常依赖于诸如远程登录、文件传输、数据压缩与解压缩、数据加密算法、消息传输协议，以及第三方库文件等开源组件。然而，这些开源组件由于其公开性质，存在已知的安全漏洞，可能为恶意攻击者提供攻击入口，带来严重的潜在安全风险。
针对这一问题，GB强标已明确要求，所有涉及OTA升级、远程控制和第三方应用的系统必须关注汽车行业相关的安全漏洞，木卫四基于自有威胁情报梳理出了OTA、远控及其他汽车智能服务场景中常见开源组件的SBOM清单及潜在的威胁风险，供行业内各方参考。
1OTA场景中引用的开源组件
OpenSSL
潜在威胁风险：
1. 利用漏洞获取通信权限；
2. 中间人攻击；
3. 恶意软件注入；
4. 拒绝服务攻击；
注：目前存在已知漏洞251个，成为黑客可利用漏洞攻击的开源组件，同样在汽车领域值得监测。
OpenSSH
潜在威胁风险：
1. 远程代码执行攻击；
2. 数据窃取攻击；
3. 中间人攻击；
注：目前存在已知漏洞116个，成为黑客可利用漏洞攻击的开源组件，同样在汽车领域值得监测。
BusyBox
潜在威胁风险：
1. 功能滥用攻击；
2. 权限提升攻击；
3. 后门植入攻击；
注：目前存在已知漏洞39个，成为黑客可利用漏洞攻击的开源组件，同样在汽车领域值得监测。
XZ Utils
潜在威胁风险：
1. 缓冲区溢出攻击;
2. 中间人攻击;
3. 拒绝服务攻击;
4. 命令注入攻击;
注：目前存在已知漏洞5个，成为黑客可利用漏洞攻击的开源组件，同样在汽车领域值得监测。
2智能控车场景中引用的开源组件
MQTT
潜在威胁风险：
1. 身份认证方面攻击；
2. 消息加密和完整性攻击；
3. 流量攻击；
注：目前存在已知漏洞1个，成为黑客可利用漏洞攻击的开源组件，同样在汽车领域值得监测。
libpcap
潜在威胁风险：
1. 缓冲区溢出攻击；
2. 拒绝服务攻击；
3. 权限提升攻击；
4. 恶意软件注入攻击；
注：目前存在已知漏洞8个，成为黑客可利用漏洞攻击的开源组件，同样在汽车领域值得监测。
ZeroMQ
潜在威胁风险：
1. 缓冲区溢出攻击；
2. 中间人攻击；
3. 权限提升攻击；
注：目前存在已知漏洞4个，成为黑客可利用漏洞攻击的开源组件，同样在汽车领域值得监测。
Crypto++
潜在威胁风险：
1. 缓冲区溢出攻击；
2. 恶意代码注入攻击；
3. 中间人攻击；
4. 拒绝服务攻击；
注：目前存在已知漏洞13个，成为黑客可利用漏洞攻击的开源组件，同样在汽车领域值得监测。
3其他智能场景中引用的开源组件
TensorFlow
潜在威胁风险：
1. 模型篡改攻击；
2. 输入数据攻击；
3. 安全漏洞利用攻击；
注：目前存在已知漏洞430个，成为黑客常利用漏洞攻击的开源组件，同样在汽车领域值得监测
Scikit-learn
潜在威胁风险：
1. 数据投毒攻击；
2. 模型窃取攻击；
3. 权限提升攻击；
注：目前存在已知漏洞3个，成为黑客常利用漏洞攻击的开源组件，同样在汽车领域值得监测。
log4j
潜在威胁风险：
1. 远程代码执行攻击；
2. 拒绝服务攻击；
3. 恶意软件植入；
注：目前存在已知漏洞14个，成为黑客常利用漏洞攻击的开源组件，同样在汽车领域值得监测。
ROS
潜在威胁风险：
1. 恶意节点注入攻击;
2. 通信劫持攻击;
3. 数据篡改攻击;
4. 拒绝服务攻击;
注：目前存在已知漏洞1个，成为黑客常利用漏洞攻击的开源组件，同样在汽车领域值得监测。
关于木卫四
木卫四（北京）科技有限公司是由全球首批专注于汽车网络安全的技术专家创立、由全球知名机构投资、具备多项自主知识产权的国家高新技术企业。木卫四正为全球智能汽车领域、自动驾驶和高级驾驶辅助系统的领军企业提供强有力的网络安全支持。客户包括但不限于宝马中国、福特中国、赛力斯、奇瑞、上汽、广汽、蔚来、合众等汽车行业佼佼者。木卫四的发展得益于众多生态伙伴的大力支持，包括华为云、亚马逊云、百度、腾讯云、微软云、地平线、天准科技、艾拉比、德勤、普华永道等知名企业。