在過去的 5 年中，大多數汽車制造商都采用了能夠提供駕駛員輔助功能的先進硬件，例如自動轉向、制動、自適應巡航控制、自動泊車、防撞、變道輔助等等。

其中一些高級駕駛輔助系統(tǒng)（ADAS）如特斯拉自動駕駛儀AI，大眾ID.3和其他系統(tǒng)，如通用汽車的Super Cruise，是標準配置并配備在車輛中。其他駕駛員輔助系統(tǒng)作為外部設備提供，例如 comma.ai，您可以將其直接插入車輛的車載診斷II（OBD-II）端口，以訪問車輛的計算機并體驗2級（轉向和加速）自動駕駛。

ADAS依賴于從車輛外部環(huán)境收集的多個實時數據源，以便安全地執(zhí)行其功能。來自攝像頭的視覺數據、來自 LiDAR 的成像、用于距離測量的雷達、速度、位置和跟蹤等遙測數據以及車對車通信只是值得一提的幾個數據源。

遠程信息處理、網關、信息娛樂系統(tǒng)和其他支持ADAS的ECU之間也需要進行協(xié)作和通信，并通過控制器局域網（CAN總線）進行。通信擴展到各種技術，如藍牙，高速寬帶或移動網絡，如LTE和5G，您可以在其中鎖定和解鎖車門，啟動發(fā)動機并查看車輛狀態(tài)或停車位置。所有這些都是通過手機應用程序完成的。請務必不要忘記您的個人識別碼（PIN）！

雖然擁有一個秘密的 4 位數 PIN 會讓您感到溫暖和舒適，但這還不足以確保您的車輛網絡安全。隨著當今的互聯(lián)、自動化和自動駕駛汽車變得越來越復雜，潛在網絡攻擊的危險也大幅增加。

ECE WP.29 車輛網絡安全

經過大量準備，聯(lián)合國歐洲經濟委員會（UNECE）于2020年6月23日發(fā)布了監(jiān)管要求，概述了汽車制造商必須在其組織和車輛中采用的新流程和技術。這不僅適用于原始設備制造商 （OEM），也適用于第 1 層和第 2 層軟件和硬件組件以及移動服務。

新法規(guī)適用于54個國家，被稱為UNECE WP.29網絡安全和網絡安全管理系統(tǒng)（CSMS）。這意味著汽車制造商需要在組織結構中加入基于風險的管理框架，以發(fā)現(xiàn)、分析和防范相關威脅、漏洞和網絡攻擊。我相信您可以按照ISO 26262-2的要求將安全性納入現(xiàn)有的質量管理體系（QMS）和流程中，以實現(xiàn)質量和安全。

此外，ECE WP.29對車輛類型（M類和N類，如果從3級開始配備自動駕駛功能，則包括L6和L7類別）有要求，包括測試其網絡安全控制的實施和通過檢查。成功實現(xiàn)組織和車輛ECE WP.29關鍵要求意味著制造商從批準機構獲得合規(guī)證書。2022 年 6 月之后，沒有此證書的新車將無法在歐盟銷售。

ECE/TRANS/WP.29/2020/79附件5表B1中威脅和相應緩解措施的一小部分樣本列表如下所示。表 B1 重點介紹了與車輛通信渠道相關的威脅和緩解活動。請注意，緩解“應”語句表示必須滿足的要求，而緩解“應該”語句表示努力緩解威脅的演示。

WP.29第7.3.3段還提到車輛制造商應如何進行詳盡的“風險評估”，但沒有告訴您如何進行該評估。然而，第5.3.1（a）段暗示了有關風險評估知識的各種標準。其中之一是汽車網絡安全標準ISO/SAE 21434 - 道路車輛 - 網絡安全工程。

ISO/SAE 21434 道路車輛—網絡安全工程

來自 ISO 和 SAE 組織的聯(lián)合工作組于 2020 年 5 月發(fā)布了針對汽車制造商和供應商的 ISO/SAE 21434 表格草案。該標準旨在確保：

網絡安全風險得到成功管理。

定義了網絡安全策略和流程。

培養(yǎng)網絡安全文化。

標準草案分為各種“條款”或部分。引起我注意的條款之一是“風險評估方法”，其中需要考慮威脅和損害情況。威脅，例如向動力總成ECU欺騙CAN消息的攻擊路徑，可能導致失控和可能的傷害。由于攻擊可能來自各種媒介，如藍牙、LTE、USB 或物理訪問 ISO/SAE 21434，因此威脅已按攻擊可行性評級進行分類：

高

中等

低

非常低

縱深防御方法是指在攻擊可以穿透一層的情況下利用網絡安全措施層，需要記錄并實施。道路車輛將解決安全影響 - 功能安全標準ISO 26262。

網絡安全保證級別

威脅路徑也與損害相吻合。定義了以下?lián)p壞影響等級：

嚴重

主要

溫和

微不足道

可以根據威脅和損害場景確定網絡安全保證級別 （CAL）。CAL 4 級別要求在網絡安全設計、測試和審查方面具有最高水平的嚴格性。CAL 1 要求嚴格程度較低。

基于影響和攻擊向量參數的 CAL 確定示例

分配給軟件或硬件組件的 CAL 級別可能會影響用于其開發(fā)和測試的方法。例如，有推薦的集成驗證方法，例如基于需求的測試、接口測試、資源使用評估、控制流和數據流以及軟件的靜態(tài)代碼分析。在代碼單元級別，建議在語句或分支進行結構覆蓋。下表顯示了派生測試用例的推薦方法。復選標記表示建議。

派生測試用例的方法

整個 SDLC 的網絡安全

根據 ISO/SAE 21434，網絡安全必須從 V 模型的左側和右側解決。作為嵌入式工程師，您知道這代表了整個軟件開發(fā)生命周期。從需求到設計、實施、集成以及驗證和確認（V&V）。

因此，請確保您擁有可靠的應用程序生命周期管理 （ALM） 或需求管理 （RM） 工具。除了您的利益相關者和所有其他安全監(jiān)管要求外，還需要滿足ECE WP.29網絡安全要求。采用可追溯性矩陣將確保不會錯過任何網絡安全要求。

對于 V&V，ISO/SAE 21434 推薦了靜態(tài)代碼分析、控制和數據流驗證、邊界值分析、結構代碼覆蓋率等測試方法。

開始滿足網絡安全要求的理想場所是使用 SEI CERT、CWE、OWASP 和 MISRA C：2012 等編碼標準。這些編碼標準和其他類似標準可以在編寫代碼和/或作為持續(xù)集成 （CI） 管道的一部分時檢測安全漏洞。

按照標準的建議采用結構代碼覆蓋率，以便您知道哪些軟件尚未經過測試?？紤]汽車行業(yè)正在發(fā)生的進化轉型，以及它將如何影響ISO/SAE 21434標準，以及正在使用的開發(fā)工具。確保他們可以輕松適應這種進展。例如，檢查該工具是否已通過 TüV 認證，可用于安全關鍵系統(tǒng)。當該工具也獲得用于網絡安全關鍵系統(tǒng)的認證時，它將做好充分準備。

審核編輯：郭婷