IDS车载入侵检测系统

1.1 入侵检测系统IDS （Intrusion Detection System）

        检测网络入侵行为的系统。而入侵行为包括任何（可能）损害到数据机密性、完整性或者可用性的非授权访问。 它是在防火墙之上的第二层保护。

        汽车IDS由车载IDS和云端组成。

1.2 IDS与防火墙区别

以公司保护为例子，

防火墙（管谁能进，谁能出，但不关心进去后在里面做什么）：

        就像公司门口的门禁，没有卡的人进不去。

• 它有一套明确的规则：比如“没有工牌的人不能进”、“快递员只能在前台停留”、“访问技术部需要额外预约”。

• 它的工作是执行这些规则，在门口就把不符合条件的人或物直接拦下。它只管 “谁能进，谁能出，以及能到哪里” ，但一般不关心进去的人在里面具体做什么。

IDS（进去之后，监测他的行为）：

• 假设一个坏人通过某种方式（比如伪装成员工）进入了公司，门禁（防火墙）没有拦住他。

• 此时，巡逻的保安和摄像头（IDS）就开始工作，监视内部的行为。一旦发现这个人正在偷拍机密文件或撬保险柜（入侵行为），就会立即发出警报。

1.3 IDS的两种检测手段

（1）基于签名的入侵检测系统（Signature-based intrusion detection system, SIDS）（基于已知攻击）

这种方法是基于已知攻击的数据库，通过设定规则监控数据包，识别出符合特征的攻击。这里的签名指的是已知攻击的特征，例如攻击数据包具有特定的字节长度或者入侵序列等。

以上述例子来看，这种方法就相当于：

假如定义同时有三个人举着横幅通过门禁，就认为这些人可能是来搞事情（入侵）的，发起警报。

• 好处：规则特征已知且精确，误报少，
• 缺点：不能对付未知的攻击，需要数据库及时更新。

（2）基于异常的入侵检测系统（Anomaly-based intrustion detection system, AIDS）（和正常基准偏差大）

这种方法是先建立正常网络情况下的活动基准，如果实际活动情况和正常基准相差较大，就认为是入侵。

同样以上述例子来讲解，这种方法就相当于：

近一个月正常情况下，公司每天进出400到600人，从早9点到晚9点结束，以此作为基准。如果哪天有人早上4点就进入门禁，那么就认为这人可能是来搞事情（入侵）的，发起警报。

• 好处：可以应对暂时未知的攻击，
• 缺点：容易引起误报。

1.4 IDS在汽车领域的应用

AUTOSAR在2018年发布的版本中加入了IDS的相关标准设计和描述。

在汽车领域应用IDS并不是将IT那一套简单的即插即用，因为在汽车电子领域的IDS应用还有一些额外的约束：

1. 分布式架构。 整车电子电气架构目前还主要是分布式的，很多功能需要在多个ECU上实现。目前整车使用较多的是多个功能域控制器，下面再连接各个传感器或子控制器的架构。汽车中央电脑统一处理各个功能域的方案更多还是OEM的预研项目，短时间内还难以量产。
2. 软硬件异构多样性。 汽车产业的一个特征就是产业链上下游丰富，一台整车上的所有电子部件可能来自于几十家不同的供应商。每个控制器采用的核心处理器、操作系统、软件模块都不同。当然也有AUTOSAR这样的组织通过合理抽象和统一架构，力图让异构多样的软硬件能在“同一频道”沟通。下文也会介绍AUTOSAR的IDS方案。
3. 资源有限。 相比计算机，汽车上控制器的资源，比如算力、存储空间等捉襟见肘。诸如机器学习、人工智能的IDS方案都需要车云结合等方案来实施。

2.1 IDS在AUTOSAR下的设计

针对汽车领域的这些特点，不同厂商会有不同的策略。接下来我们看看作为汽车架构领导者的AUTOSAR所设计的方案。

我们首先看看IDS方案的宏观架构。 汽车IDS由车载IDS和云端组成。

 这是一个车载分布式IDS方案，车端最终通过无线通讯单元把数据上传给云端作分析判断。云端部分可以更多地融合IT界的方案，可以做更复杂的运算以作最终判断。当然车端控制器也要作适当的初步判断和筛选，否则车云通讯的带宽不支持。以上述例子来说，云端就相当于警察，他们有指纹库、犯罪记录库、专业的盘问方法等丰富资源，可以更准确地判断是否构成入侵行为。车端就相当于公司园区的监控设备和保安，掌握第一手实时信息，但也需要作初步分析和筛选，不能一股脑碰到所有疑似情况都去报警。

2018年，AUTOSAR实现了IDS标准化的第一步：在AUTOSAR 4.4中定义了安全事件和安全事件存储器（Sem）。

2.2 车端四种类型的IDS功能模块

车端各个控制器上存在四种类型的IDS功能模块，分别是：

1) Host based Sensors（控制器内部的监控模块）

这是针对控制器内部行为的监控模块，例如监控控制器内部的内存使用情况等。

同样以上述例子来讲解，这就相当于在公司内部巡逻的保安队员，主要监控公司内有没有什么可疑人物出现或者有没有什么异常情况发生。

2）Network based Sensors（网络行为的监控模块）

这是针对网络行为的监控模块，例如监控LAN Switch上的流量或者防火墙的拦截情况。

同样以上述例子来讲解，就相当于监控门口摄像头情况的保安，主要监控门口进出的人流量或者有没有人堵在门禁不让其他人进出。

主流方式：Sensor 直接将负载等数据传给 IDSM

在大多数现代车载IDS中，sensor（如ECU或专用监控节点）会持续将总线负载的原始数据或计算出的负载指标（如百分比）发送给中央IDSM（入侵检测系统管理器）。然后，IDSM负责分析这些数据，并判断是否超过阈值（如80%），从而决定是否上报VSOC（车辆安全运营中心）。

3）IdsManager（接收sensor上报的潜在攻击行为，做初步分析，若符合条件，上报给idsR）

上述两个Sensor发现潜在攻击行为时，就会上报给IdsManager，作初步分析。Sensor上报的事件叫Security Event （SEv）。如果IdsManager分析认为事件符合条件（调用规则库），那该事件就是Qualified Security Event （QSEv）。

1）idsm调用规则库

IdsM，它是检测的大脑。它接收来自Sensors的数据，并调用规则库进行分析，判断是否存在入侵，即是否为Qsev。

2）idsm调用防护策略

若是QSEV，则执行防护策略（可选）：由IdsM触发，在车端立即执行本地防御动作，如丢弃恶意报文、重置会话等。

以上述例子来讲解，这就像保安队长，需要对下属上报的潜在入侵事件作分析判断，看行为是否够格上报。

4） IdsReporter（接受所有idsM发送的QSEv，通过无线模块，发往云端）

IdsManager分析后的QSEv都统一传输给IdsReporter。它一般部署在TBox等无线通讯模块，将数据打包发往云端。

以上述例子来讲解，这就相当于集团的联络专员。各个子公司的保安队长发现入侵行为时，就会汇总给这个专员，由TA统一报警。

按照控制器本身功能的重要性部署Host based Sensors，按照控制器节点在整车网络的位置重要性部署Network based Sensors。功能和网络位置都重要的控制器可以同时部署两种Sensors。部署了Sensors的控制器就会同时部署IdsManager，Sensors负责监控基础变量，发现潜在入侵行为则内部传输给IdsManager，由其在控制器层面初步评估后再与IdsReporter通讯。

2.3 Autosar IDS方案在控制器内部的具体实施细节

图里的橙色箭头和绿色路径都是可选路径。

1）两种类型的Sensors（这两种类型可以结合使用）：

1、特殊设计的一个软件组件（SWC）（该组件就是我们通常所说的“探针”）

2、也可以直接利用现有的其他基础软件模块来充当Sensors。

• 独立探针和利用现有的基础软件模块可以且应该同时存在于一个控制器上，它们从不同维度、不同层级采集安全信息，最终通过IdsM和PduR的统一调度，全部上报给IdsR，从而形成一个立体的、深度的入侵检测网络。

2）图中的蓝色箭头表示Sensors把潜在事件上报给IdsManager，例如SecOC鉴权失败的状态可以上报，EthDrv的以太网驱动异常状态也可以上报，这都是复用其他基础软件的例子。

IdsManager接到SEv后，按条件判断，若确实够格上报，则将QSEv通过PduR将安全事件以例如SOMEIP等通讯方式发送给IdsReporter。

3）IdsManager判断够格后：

1、QSEv通过PduR发送到另一个ECU上的IdsR（图中棕色箭头）

2、本地存储（可选）（橙色箭头）：非易失性存储区管理模块Nvm可以选择将安全事件加密存储到安全区HSM中，亦即图里的绿色路线（可选），并以IdsM检测的方式存储数据。

• 实际上每个安全事件都应该可以单独配置限制规则、是否上报IdsReporter、是否本地存储、存储是否加密等，以保证IDS在每个控制器上都可以高效利用资源的自由度。
• 上报IDSR和本地存储是两个可以独立开关的动作，并非绑定关系

3）AUTOSAR拓展了原来的Diagnostic Event Manager (Dem)，使原来的诊断存储区内可以配置相应的安全事件区域（Security Event Memory, Sem）。

Sem（逻辑管理）（决定“存什么”和“如何管理”）：

• 当IdsM确定一个安全事件“够格”被记录后，SEM负责接收这个事件，并为其分配一个逻辑位置。它管理的是事件的 “元数据” ，比如：事件ID、发生次数、时间戳、状态等。

NVM 非易失性存储管理器（物理存储）（负责“存在哪里”和“怎么存”）：

• 将数据（包括应用数据、配置数据，以及我们这里讨论的安全事件）真正写入到Flash等非易失性存储介质中，确保ECU重启后数据还在。

2.4 Vector IDS

ISO/SAE 21434（道路车辆-网络安全工程）是车辆安全标准，定义了当攻击发生时如图所示的5个步骤。

IDS检测针对ECU和网络的外部攻击，将其收集后发送到汽车制造商的后端-安全运营中心（VSOC：Vehicle Security Operations Center）。汽车制造商对数据进行评估并决定如何应对。

步骤 3：Analyze（分析）

• 中文翻译：针对单车和整个车队的安全事件数据进行分析。

• 详细解释：这是云端VSOC的核心能力。它不仅仅看单一车辆的一次事件，而是汇聚整个车队成千上万辆车的上报数据。通过大数据分析和AI算法，它可以：

  • 发现攻击模式：识别出针对某一车型或零部件的广泛攻击。

  • 关联分析：将多个看似无关的孤立事件关联起来，还原出复杂的攻击链。

  • 威胁定级：判断威胁的严重程度和影响范围。

• 为什么要结合整个车队分析：

步骤 4：Develop（开发）

• 中文翻译：开发威胁响应措施，例如实施和测试对抗方案。

• 详细解释：在确认威胁并分析清楚后，VSOC团队（或自动化系统）需要制定具体的应对策略。这可能包括：

  • 编写新的检测规则（涉及idsm会调用来判断是否为Qsev）：以便车端探针在未来能直接识别这种新型攻击。

  • 开发安全补丁：修复某个ECU软件中的安全漏洞。

  • 制定缓解策略：例如，命令车辆在检测到攻击时自动限制某些高危功能（idsm识别为Qsev后，会调用防护策略）。

步骤 5：Deploy（部署）

• 中文翻译：部署软件更新以缓解威胁。

• 详细解释：开发并测试完成的应对措施（新的检测规则、安全补丁等）需要通过OTA的方式，下发到受影响的车辆上。这实现了从“发现问题”到“解决问题”的闭环，使整个车队能够免疫于已发现的威胁，并提升对未来类似攻击的检测能力。

• 

注意事项：

• 在分布式系统（如汽车E/E架构）中，中央ECU无法掌握其他ECU的所有安全事件。因此，IDS必须是分布式系统。
• 出于安全原因，应避免单点故障，最好的方法是使用分布式IDS。
• 为了避免整个系统设计变得不必要地复杂，汽车制造商需要一致的接口——即使软件和硬件平台是异构的。
• 需要考虑ECU的特定限制，如有限的计算能力和存储空间。
• 避免无线网络上不必要的负载，例如，在向云端报告安全事件之前进行收集和验证。
• 根据实时性要求确定安全事件。

2.5 汽车IDS结构

汽车IDS由五部分组成：

• 安全传感器是软件算法，检测攻击并将其作为安全事件报告给入侵检测系统管理器。
• 在入侵检测系统管理器（IdsM）中，当满足指定条件时，安全事件通过过滤器并成为合格安全事件（QSEv）。IdsM发送与中央入侵检测报告器相关的QSEv，并将其存储在安全事件存储器中。
• 入侵检测报告器（IdsR）将QSEv转发给汽车制造商的安全运营中心。
• 工作在安全运营中心（SOC）的安全专家检查数据的合理性，采取措施消除检测到的威胁，并提高未来针对类似攻击的保护对策。
• 安全事件存储器（SEM）能够将安全事件存储在单独且特别安全的区域中

在安全工程过程中，汽车制造商决定E/E架构的哪些节点具有IdsM。

自AUTOSAR 20/11以来，入侵检测系统管理器（IdsM）已成为标准的一部分，重点关注：

• 面向分布式车载IDS的高层架构
• 基础软件模块和应用软件组件向IdsM报告安全事件的接口
• 对报告的安全事件进行判断的资格过滤器
• IdsM和IdsR之间的通信
• 标准化特定基础软件模块的安全事件类型

2.6 入侵检测和防御系统

• 入侵检测系统（IDS，Intrusion Detection System）：可以检测网络中可能发生的不同类型的攻击，如拒绝服务(DoS，Denial of Service)/分布式拒绝服务(DDoS, Distributed Denial of Service)、端口扫描、恶意软件或勒索软件等。
• 入侵防御系统（IPS，Intrusion Prevention System）：帮助减轻或避免上述攻击，防止其对车载系统造成破坏。

IDPS: 兼具检测和防御功能的能够使安全防护效果加倍：

一方面监视系统并保护网络免受入侵者的攻击，另一方面在网络环境中发生攻击时向管理员提供报告，帮助进一步反馈响应措施。

2.7 IDPS的原理

入侵检测防御系统IDPS的核心功能是入侵检测和响应阻止。完整的车辆IDPS系统是车端云端相结合的动态防御系统，能够实现车载网络安全攻击和异常事件的有效收集、检测与应对，其典型的工作拓扑结构如图所示。

当车辆遭受黑客攻击时，数据采集模块会实时采集车端各组件或车载总线网络（如CAN/CANFD、以太网等）中的报文数据和安全状态信息，并将其发送给入侵检测模块，用于检测车载网络中的异常流量和车内操作系统中的异常行为。此外，检测规则库中的规则能够为入侵异常检测提供有效支撑。当检测到异常后，需要向IDPS事件管理模块上报入侵事件。事件管理模块对安全事件进行一定的处理过滤，生成相应的报警日志和响应措施。其中，报警日志会上传给云端安全运维中心（VSOC），进行所有车辆相关事件和状态的管理和呈现。同时会通过OTA等方式，更新车端的安全防护策略，以提高车辆的安全等级。

1. 车端 - 数据采集

• 原文：“网络报文数据采集” & “关键ECU状态采集”

• 解读：这是检测的基础。相当于AUTOSAR架构中的 “Sensors”。

  • 网络报文采集：由通信驱动（如EthDrv、CanDrv）和协议栈（如SOME/IP）负责，监控总线流量。

  • ECU状态采集：由SecOC、加密模块、操作系统等基础软件模块负责，提供内部安全状态信息。

2、车端 - 核心检测

• 原文：“入侵检测模块” & “检测规则库”

• 解读：这部分的组合，完全对应AUTOSAR架构中的 “IDS Manager”。

  • 检测规则库：存储着检测逻辑和规则的文件或配置区。

  • 入侵检测模块：即 IdsM，它是检测的大脑。它接收来自Sensors的数据，并调用规则库进行分析，判断是否存在入侵。

3. 车端 - 响应与上报

• 原文：“防护策略执行” & “上报入侵事件”

• 解读：这是检测后的动作分支。

  • 防护策略执行：由IdsM触发，在车端立即执行本地防御动作，如丢弃恶意报文、重置会话等。

  • 上报入侵事件：即IdsM将“够格”的安全事件封装成QSEv，通过PduR发送给 “IDS Reporter”。

4. 云端 - 分析与决策

• 原文：“事件管理模块对安全事件进行一定的处理过滤，生成相应的报警日志和响应措施。”

• 解读：这描述的是云端VSOC平台的功能。它接收来自全车队IdsR上报的事件。

  • 事件管理：对海量事件进行聚合、去重、关联分析。

  • 生成响应措施：分析后，决定要采取的行动，最常见的就是生成新的检测规则或防护策略。

5. 云端 -> 车端 - 进化与闭环

• 原文：“通过OTA等方式，更新车端的安全防护策略”

• 解读：这是闭环中最关键的一步。云端将分析后得出的新知识（新的攻击特征）以更新“检测规则库” 或 “防护策略” 的形式，通过OTA下发给车辆。这使得整个车队具备了免疫新威胁的能力。

根据描述和AUTOSAR标准，日志的存储是分阶段、分位置的：

1. 原始数据和本地事件记录：

• 存储在产生事件的ECU上。 例如，一个网关ECU检测到攻击，它的IdsM会指示NVM将事件记录加密存储在本地Flash的SEM中。这是为了事后取证，即使车辆没有网络，记录也在。

2. 准备上报的警报日志：

• 暂存在 IDS Reporter 所在的控制器（通常是TBOX或中央网关）中。

• 工作流程是：

  • 源ECU（如网关）的IdsM将事件发送给它的IdsR。

  • 该IdsR会临时缓存这些事件，等待网络可用时批量发送。

  • 一旦成功发送到云端VSOC，它可能会根据策略删除已成功上报的日志，以释放存储空间。

  • 如果发送失败，日志会继续保留在IdsR的存储区内，直到发送成功。

2.8 IDPS分类

根据检测对象的不同，入侵检测与防御系统IDPS可分为主机型、网络型和混合型，介绍如下：

（1）基于主机的入侵检测防御系统（H-IDPS，Host-based IDPS）

H-IDPS主要对易受攻击的关键ECU进行监视和保护，通过监控T-BOX、中央网关、IVI等具有操作系统或对外接口的主机系统，采集和分析其文件完整性、网络连接活动、进程行为、资源使用情况、日志字符串匹配等事件特征，实现系统异常行为的检测。

（2）基于网络的入侵检测防御系统（N-IDPS，Network-based IDPS）

N-IDPS主要检测车辆内部网络的入侵事件，通过采集车载网络总线上的报文数据，进行特定网络段或设备的流量数据监控、数据载荷解析和字段匹配等活动，以识别网络中出现的异常流量和潜在攻击行为。

（3）混合式入侵检测防御系统（Hybrid IDPS）

混合式IDPS是基于网络的IDPS与基于主机的IDPS的结合。对于智能网联汽车来说，混合IDPS的使用最广泛，且更有利于全面地检测和应对车辆的可疑威胁。