入侵檢測系統 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在每個控制器上都可以高效利用資源的自由度。