在汽车行业,网络安全(cyber security)属于正在兴起的领域,但是在IT界已经研究已久。例如数据加密、防火墙等。入侵检测系统 (Intrusion Detection System)作为网络安全的重要一环同样也在IT界由来已久。
早在1986年, 美国人DorothyE.Denning和PeterNeumannn就提出了入侵检测系统的概念,并进行了系统性研究。这些年来IDS一直在网络安全中发挥重要作用。但是随着网络结构越来越复杂,IDS经常会因为误报而被人们贴上不够可靠的标签。而近年来云计算和人工智能的发展,为IDS提供了再度焕发活力的机会。
入侵检测系统,顾名思义就是用于检测网络入侵行为的系统。而入侵行为包括任何(可能)损害到数据机密性、完整性或者可用性的非授权访问。 它是在防火墙之上的第二层保护。
举个例子,这个例子在后文会反复使用: 以公司保护为例子,防火墙就像公司门口的门禁,没有卡的人进不去。 而IDS就像门口坐在安保室监控的保安,监控着有没有入侵行为发生。
这种方法是基于已知攻击的数据库,通过设定规则监控数据包,识别出符合特征的攻击。这里的签名指的是已知攻击的特征,例如攻击数据包具有特定的字节长度或者入侵序列等。
以上述例子来看,这种方法就相当于: 假如定义同时有三个人举着横幅通过门禁,就认为这些人可能是来搞事情(入侵)的,发起警报。
这种方法的 好处 是规则特征已知且精确,误报少 缺点 就是不能对付未知的攻击,需要数据库及时更新
这种方法是先建立正常网络情况下的活动基准,如果实际活动情况和正常基准相差较大,就认为是入侵。
同样以上述例子来讲解,这种方法就相当于 近一个月正常情况下,公司每天进出400到600人,从早9点到晚9点结束,以此作为基准。如果哪天有人早上4点就进入门禁,那么就认为这人可能是来搞事情(入侵)的,发起警报。
这种方法的 好处 就是可以应对暂时未知的攻击 缺点 是容易引起误报
IDS 虽已问世多年,但受限于传统汽车电子电气架构相较于计算机网络的简易性,早期并未在汽车控制器上部署,这一点与 IT 领域多数网络安全手段的应用历程相似。近年来,伴随汽车 "新四化" 浪潮的推进,汽车电子技术实现跨越式升级,汽车网络安全领域迎来蓬勃发展期,IDS 也由此成为该领域的核心技术角色之一。值得关注的是,全球汽车电子领域的权威标准体系 AUTOSAR,早在 2018 年发布的版本中,就已纳入 IDS 的相关标准设计与技术描述。
当然,在汽车领域应用IDS并不是将IT那一套简单的即插即用,因为在汽车电子领域的IDS应用还有一些额外的约束:
分布式架构特征。当前整车电子电气架构仍以分布式架构为主流,大量功能需依托多个电子控制单元(ECU)协同完成。现阶段量产车型广泛采用的架构方案为:上层部署多台功能域控制器,下层直接对接各类传感器与子控制器。而通过汽车中央电脑对全功能域进行集中统一处理的技术路径,目前更多停留在整车厂(OEM)的预研阶段,短期内难以实现规模化量产。
软硬件异构多样性特点。汽车产业的显著特征之一是产业链上下游生态丰富,一台整车的电子部件往往源自数十家不同供应商。这使得各控制器搭载的核心处理器、操作系统及软件模块呈现出显著的异构性与多样性。对此,AUTOSAR 等行业标准组织通过标准化的架构抽象与接口定义,致力于打破软硬件异构壁垒,实现不同组件间的高效兼容与协同通信。
控制器资源受限现状。相较于通用计算机,汽车控制器的核心资源(如算力、存储空间等)普遍存在明显短板。正因如此,基于机器学习、人工智能等技术的 IDS 方案,往往需要依托车云协同等分布式部署模式,才能实现功能落地与高效运行。
针对汽车领域的这些特点,不同厂商会有不同的策略。接下来我们看看作为汽车架构领导者的AUTOSAR所设计的方案。
我们首先看看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)。对于功能与网络位置兼具重要性的核心控制器,可同步部署上述两种传感器。所有搭载传感器的控制器,均需配套部署IDS 管理器(IdsManager)。其工作流程为:传感器负责实时监控系统基础运行变量,一旦识别潜在入侵行为,立即将相关数据传输至本地 IDS 管理器;IDS 管理器完成控制器层面的初步风险评估后,再与 IDS 上报模块(IdsReporter)进行通讯交互。
下图可以进一步展示该方案在控制器内部的实施细节。 实际上两种类型的Sensors 可以是特殊设计的一个软件组件(SWC),也可以直接利用现有的其他基础软件模块来充当Sensors。
图中的蓝色箭头表示Sensors把潜在事件上报给IdsManager,例如SecOC鉴权失败的状态可以上报,EthDrv的以太网驱动异常状态也可以上报,这都是复用其他基础软件的例子。
IdsManager接到SEv后,按条件判断,若确实够格上报,则将QSEv通过PduR将安全事件以例如SOMEIP等通讯方式发送给IdsReporter。
而同时够格的安全事件也应该作相应的本地储存,即图中的橙色箭头。
作为可选项,Nvm可以加密数据(绿色箭头),并以IdsM检测的方式存储数据。棕色箭头显示除了本地存储之外的第二种方式,QSEv通过PduR发送到另一个ECU上的IdsR。
AUTOSAR拓展了原来的Diagnostic Event Manager (Dem),使原来的诊断存储区内可以配置相应的安全事件区域(Security Event Memory, Sem)。
而非易失性存储区管理模块Nvm可以选择将安全事件加密存储到安全区HSM中,亦即图里的绿色路线。
实际上每个安全事件都应该可以单独配置限制规则、是否上报IdsReporter、是否本地存储、存储是否加密等,以保证IDS在每个控制器上都可以高效利用资源的自由度。
简而言之,汽车IDS由五部分组成:
E/E架构的每个节点可以包含本地IdsM,彼此之间没有层次依赖关系。在安全工程过程中,汽车制造商决定E/E架构的哪些节点具有IdsM。