入侵检测系统 IDS

驾驶哥

2021年10月11日 09:35

作者 | 一骥绝尘

出品 | 焉知

入侵检测系统（IDS）在IT界由来已久

网络安全（cyber security）在汽车行业属于正在兴起的领域，但是在IT界已经研究已久。例如数据加密、防火墙等，相信作为互联网用户的各位同仁都不会陌生。入侵检测系统（Intrusion Detection System）作为网络安全的重要一环同样也在IT界由来已久。

图1：入侵检测系统概念设计图

早在1986年，美国人DorothyE.Denning和PeterNeumannn就提出了入侵检测系统的概念，并进行了系统性研究。这些年来IDS一直在网络安全中发挥重要作用。但是随着网络结构越来越复杂，IDS经常会因为误报而被人们贴上不够可靠的标签。而近年来云计算和人工智能的发展，为IDS提供了再度焕发活力的机会。

入侵检测系统，顾名思义就是用于检测网络入侵行为的系统。而入侵行为包括任何（可能）损害到数据机密性、完整性或者可用性的非授权访问。它是在防火墙之上的第二层保护。以公司园区保护为例子，防火墙就像公司门口的门禁，没有卡的人进不去。而IDS就像门口的监控摄像头以及坐在安保室监控的保安，监控着有没有入侵行为发生。

IDS的检测手段主要有两种：

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

这种方法是基于已知攻击的数据库，通过设定规则监控数据包，识别出符合特征的攻击。这里的签名指的是已知攻击的特征，例如攻击数据包具有特定的字节长度或者入侵序列等。以上述公司园区为例子，这种方法就相当于定义如果同时有三个人举着横幅通过门禁，就认为这些人可能是来搞事情（入侵）的，发起警报。这种方法的好处是规则特征已知且精确，误报少，但缺点就是不能对付未知的攻击，需要数据库及时更新。

（2）基于异常的入侵检测系统（Anomaly-based intrustion detection system, AIDS）

这种方法是先建立正常网络情况下的活动基准，如果实际活动情况和正常基准相差较大，就认为是入侵。同样以上述公司园区为例子，这种方法就相当于近一个月正常情况下，公司每天进出400到600人，从早9点到晚9点结束，以此作为基准。如果哪天有人早上4点就进入门禁，那么就认为这人可能是来搞事情（入侵）的，发起警报。这种方法的好处就是可以应对暂时未知的攻击，但缺点是容易引起误报。

IDS在汽车领域的应用

虽然IDS由来以久，但是由于传统汽车电子电气架构相比计算机网络来说较为简单，IDS与其他IT界的网络安全手段类似，早前并没有在汽车控制器上部署。但近年来随着汽车新四化的发展，汽车电子也在进化，汽车网络安全方兴未艾，IDS同样是这个舞台上一个重要的角色。连AUTOSAR也在2018年发布的版本中加入了IDS的相关标准设计和描述。

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

1. 分布式架构。 整车电子电气架构目前还主要是分布式的，很多功能需要在多个ECU上实现。目前整车使用较多的是多个功能域控制器，下面再连接各个传感器或子控制器的架构。汽车中央电脑统一处理各个功能域的方案更多还是OEM的预研项目，短时间内还难以量产。

2. 软硬件异构多样性。 汽车产业的一个特征就是产业链上下游丰富，一台整车上的所有电子部件可能来自于几十家不同的供应商。每个控制器采用的核心处理器、操作系统、软件模块都不同。当然也有AUTOSAR这样的组织通过合理抽象和统一架构，力图让异构多样的软硬件能在“同一频道”沟通。下文也会介绍AUTOSAR的IDS方案。

3. 资源有限。 相比计算机，汽车上控制器的资源，比如算力、存储空间等捉襟见肘。诸如机器学习、人工智能的IDS方案都需要车云结合等方案来实施。

IDS在AUTOSAR下的设计

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

我们首先看看IDS方案的宏观架构。

图2：车端的分布式IDS架构

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

下面重点来看车端。车端各个控制器上存在四种类型的IDS功能模块，分别是：

1. Host based Sensors

这是针对控制器内部行为的监控模块，例如监控控制器内部的内存使用情况等。同样以上面公司园区保护的例子，这就相当于在公司内部巡逻的保安队员，主要监控公司内有没有什么可疑人物出现或者有没有什么异常情况发生。

2. Network based Sensors

这是针对网络行为的监控模块，例如监控LAN Switch上的流量或者防火墙的拦截情况。以上述例子就相当于监控门口摄像头情况的保安，主要监控门口进出的人流量或者有没有人堵在门禁不让其他人进出。

3. IdsManager

上述两个Sensor发现潜在攻击行为时，就会上报给IdsManager，作初步分析。Sensor上报的事件叫Security Event （SEv）。如果IdsManager分析认为事件符合条件，那该事件就是Qualified Security Event （QSEv）。在上述例子中，这就像保安队长，需要对下属上报的潜在入侵事件作分析判断，看行为是否够格上报。

4. IdsReporter

IdsManager分析后的QSEv都统一传输给IdsReporter。它一般部署在TBox等无线通讯模块，将数据打包发往云端。上述例子中，这就相当于集团的联络专员。各个子公司的保安队长发现入侵行为时，就会汇总给这个专员，由TA统一报警。

车上有CAN、CANFD、以太网等多种网络，多个功能域控制器下挂着若干传感器和子控制器，是目前典型的电子电气架构。这个方案的大体思路就是分层部署，各司其职。这就针对性地满足了分布式、资源有限和车云交互的需求。

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

下图可以进一步展示该方案在控制器内部的实施细节。实际上两种类型的Sensors可以是特殊设计的一个软件组件（SWC），也可以直接利用现有的其他基础软件模块来充当Sensors。下图中的蓝色箭头表示Sensors把潜在事件上报给IdsManager，例如SecOC鉴权失败的状态可以上报，EthDrv的以太网驱动异常状态也可以上报，这都是复用其他基础软件的例子。IdsManager接到SEv后，按条件判断，若确实够格上报，则将QSEv通过PduR将安全事件以例如SOMEIP等通讯方式发送给IdsReporter。而同时够格的安全事件也应该作相应的本地储存，即下图的橙色箭头。AUTOSAR拓展了原来的Diagnostic Event Manager (Dem)，使原来的诊断存储区内可以配置相应的安全事件区域（Security Event Memory, Sem）。而非易失性存储区管理模块Nvm可以选择将安全事件加密存储到安全区HSM中，亦即下图的绿色路线。实际上每个安全事件都应该可以单独配置限制规则、是否上报IdsReporter、是否本地存储、存储是否加密等，以保证IDS在每个控制器上都可以高效利用资源的自由度。