摘要 ? ?

網(wǎng)絡安全越來越被認為是汽車系統(tǒng)的一個重要話題，特別是在聯(lián)網(wǎng)和自動駕駛領域。即將出臺的法規(guī)對汽車領域的網(wǎng)絡安全提出了多層次的要求，以獲得型號批準。在組織層面，需要一個涵蓋整個車輛生命周期和生態(tài)系統(tǒng)的網(wǎng)絡安全管理系統(tǒng)（CSMS）。此外，必須對申請型號批準的每一種車輛類型的網(wǎng)絡安全進行論證。

由于這些要求與現(xiàn)有的型號批準要求相比具有新穎性，因此正在進行測試階段。CSMS的組成部分和范圍是一個開放的問題。本文概述了CSMS的要求，確定了方法和差距，并對能夠滿足這些要求的潛在框架進行了展望。

I.簡介

汽車正在從孤立的、主要是電子機械系統(tǒng)向帶輪子的連接計算機發(fā)展。目前，這是由監(jiān)管和汽車工業(yè)提供額外服務的愿望所驅動的。進一步邁向部分和全自動化的車輛只會加速這一趨勢。像進一步減少交通事故或減少交通能源這樣的目標，只有通過合作和自動駕駛車輛才能實現(xiàn)。為了實現(xiàn)安全、自動化和交互的車輛，網(wǎng)絡安全需要提高。最近的評估和披露顯示，目前車輛的幾乎所有連接元件都存在多個漏洞。

為了確保越來越高的安全水平，聯(lián)合國歐洲經(jīng)濟委員會（UNECE）WP29自動駕駛/自主駕駛和聯(lián)網(wǎng)汽車工作組（GRVA）啟動了一個網(wǎng)絡安全和軟件更新（CS/OTA）的特別小組。圖1給出了作為UNECE WP29的締約國的62個國家的概況（狀態(tài)2016）。簽約國意味著在這些國家銷售車輛所需的車輛型號認證是基于ECE的法規(guī)。在此，我們將重點討論整車型式認證（WVTA）。圖2給出了關于車輛類型批準過程的概述。



圖2. 整車型式認證（WVTA）過程

該工作組制定并提交了一份關于整合網(wǎng)絡安全和軟件更新的法規(guī)以進行車輛類型審批的建議。關于網(wǎng)絡安全的建議包含以下幾章： (1)簡介 (2)定義（和縮略語） (3)網(wǎng)絡安全原則 (4)對車輛系統(tǒng)和生態(tài)系統(tǒng)的威脅 (5)緩解措施 (6)網(wǎng)絡安全程序的要求和如何證明其應用 (7)結論和對進一步程序的建議 (8)附件A 關于引入網(wǎng)絡安全條例的建議草案 (9)附件B 威脅和相應的清單 (10)附件C 與緩解措施有關的安全控制措施清單，包括例子。

(11)附件D 參考文件清單 根據(jù)已交付的建議，目前有一個測試階段正在進行。在這個測試階段，對需求進行評估，必要時進行完善。同時，指導文件也被制定。 在第二節(jié)中重點討論了網(wǎng)絡安全流程的要求和如何證明其應用，以及附件A關于引入網(wǎng)絡安全條例的建議草案，以確定和分析汽車領域的網(wǎng)絡安全流程要求。

之后，在第三節(jié)中概述了汽車網(wǎng)絡安全的現(xiàn)有構建模塊和開放點。在第四節(jié)中，提出了一個起點來定義一個符合CSMS的流程，涵蓋整個生命周期。

II.對網(wǎng)絡安全流程的要求和擬議的法規(guī)

建議的要求分為三個部分。第一部分描述了汽車行業(yè)中網(wǎng)絡安全管理系統(tǒng)（CSMS）的要求。下一節(jié)描述了后期生產(chǎn)階段的要求，最后一節(jié)涉及到車型的批準。對于擬議的法規(guī)，有一個章節(jié)描述了cms合規(guī)證書，一個章節(jié)描述了網(wǎng)絡安全管理系統(tǒng)的要求，然后是車輛類型的要求。在下面幾節(jié)中總結了這些需求。

A.網(wǎng)絡安全管理系統(tǒng)

網(wǎng)絡安全管理系統(tǒng)是一個總的結構，它收集了所有與網(wǎng)絡安全有關的過程。汽車制造商必須確保供應商和服務提供商實施CSMS。?

制造商及其供應商和服務提供商的CSMS由審批機構或技術服務部門評估。雖然審批機構或技術服務部門可以在任何時候要求重新評估，但基本有效期為三年。如果有可能影響評估的變化，車輛制造商必須通知審批機構或技術服務部門。CSMS中定義的流程必須包括開發(fā)、生產(chǎn)和后期生產(chǎn)，并考慮對車輛的風險和威脅的監(jiān)測以及事故響應流程。 對于流程的定義需要在汽車領域的不同生命周期之間有所區(qū)別(參見圖3)。對于歐洲經(jīng)委會的條例，生命周期是指車輛類型的生命周期，例如從開發(fā)到開始生產(chǎn)到停止生產(chǎn)。如果看一下ISO 26262]和SAE J3061，生命周期的重點是一個系統(tǒng)（元素，組件）的工程，可以在多個車輛中使用。對于車輛本身，有生產(chǎn)、使用和退役的生命周期。為了獲得型號批準，例如，開始生產(chǎn)，OEM需要證明該組織和所有參與的供應商都有一個經(jīng)過認證的CSMS。


?
圖3.汽車領域的不同生命周期 這些流程需要確保安全問題得到充分考慮，并包括以下重點：

?組織中的網(wǎng)絡安全管理

?對車輛類型風險的管理（識別、評估、歸類和處理）

?驗證對已識別風險的充分管理

?在開發(fā)和生產(chǎn)過程中的安全測試

?檢測和應對針對車輛類型的網(wǎng)絡攻擊

?識別和管理新的網(wǎng)絡威脅和車輛類型的脆弱性

?風險評估的更新

此外，汽車制造商必須確保所有流程在分布式開發(fā)環(huán)境中工作。

B.后期生產(chǎn)階段

對生產(chǎn)后階段的要求主要是對CSMS的要求進行細化，以確保網(wǎng)絡安全被整合到車輛的生命周期中。車輛制造商必須證明如何在車輛生命周期內保持對法規(guī)的遵守和保護。這包括監(jiān)測威脅狀況和漏洞的變化。需要對已實施的安全措施的有效性進行監(jiān)測。重點是確保不斷變化的環(huán)境不會導致對安全和可用性的影響。為了確保這一點，需要建立事件響應程序。

C.車輛類型

只有當原始設備制造商和所有供應商的CSMS認證到位后，才能進行整車型式批準。整車型式批準的證據(jù)需要包括： ?在風險評估中如何考慮已知的漏洞和威脅。風險評估需要考慮整個車輛、所有車輛系統(tǒng)以及它們之間的相互作用。 ?在風險評估中被確定為關鍵的要素，被設計成適當?shù)陌踩胧?，以使風險降低到可接受的水平。

要素包括： –車輛架構和系統(tǒng) –與網(wǎng)絡安全有關的組件和系統(tǒng) –與網(wǎng)絡安全有關的部件和系統(tǒng)與其他車內和外部系統(tǒng)之間的相互作用 ?從確定的風險到實施的緩解措施再到測試結果的追蹤，以證明所有的風險都得到了充分的覆蓋

如果車輛支持售后軟件、服務、應用程序或數(shù)據(jù)的存儲或執(zhí)行，則需要有專門的受保護環(huán)境。所需要的信息需要通過整個供應鏈收集和驗證。

III.汽車網(wǎng)絡安全框架的技術現(xiàn)狀

UNECE對CSMS的要求是一個完整的網(wǎng)絡安全流程框架，涵蓋了在整個車輛生命周期中與實現(xiàn)網(wǎng)絡安全相關的所有活動。它必須涵蓋所有可能影響網(wǎng)絡安全的利益相關者。這個框架應該產(chǎn)生證據(jù)，證明為什么車輛的網(wǎng)絡安全得以實現(xiàn)。 雖然這樣的整體框架還不存在，但已經(jīng)有了發(fā)展的起點。我們將在接下來的章節(jié)中概述a）汽車領域現(xiàn)有的網(wǎng)絡安全流程和b）現(xiàn)有的保證方法。在這個過程中，必須在以下方面有所區(qū)別：

?在開發(fā)、生產(chǎn)和后期制作中管理網(wǎng)絡安全的流程

?處理汽車領域的分布式性質的過程

第一套流程可以被概括為風險管理流程，第二部分可以被概括為汽車供應鏈管理。

A.汽車網(wǎng)絡安全風險管理

ISO 31000中提出了通用的風險管理流程。風險管理被定義為一個反復的過程，它必須在整個生命周期中執(zhí)行。NIST對組織和系統(tǒng)層面的風險管理進行了更詳細的描述。

這兩種方法都在高層次上涵蓋了CSMS風險管理的要求。

1)風險識別：汽車風險識別的一個著名方法是威脅建模。事實表明，威脅建模可以貫穿整個車輛生命周期，用于識別由于設計漏洞和潛在威脅造成的風險，甚至可以用來監(jiān)測已部署系統(tǒng)的漏洞。

最近的方法證明了威脅建模如何支持安全測試過程，也可以作為安全和保障的組合方法的一部分。威脅建模依賴于有關威脅和網(wǎng)絡安全狀況的最新知識，其中包括對整體威脅狀況的監(jiān)測，也包括對車輛的取證能力。

2)風險評估：對于風險評估，存在不同的方法，這些方法部分包含在風險識別方法中。一個成熟的方法是由評估攻擊概率的通用標準來定義的。攻擊概率可以根據(jù)現(xiàn)有的信息和生命周期階段進行調整。這被用作EVITA項目的出發(fā)點。在HEAVENS項目中，收集了一套風險識別和評估方法并發(fā)表了報告。在CySiVuS項目中，開發(fā)了一個基于FAIR的統(tǒng)一的安全和保障的定量風險評估。

3)風險歸類：風險分類目前仍是一個開放的話題?，F(xiàn)有的方法是，它將威脅分為安全相關和非安全相關。在提出了安全、財務、操作和隱私（SFOP）的分類。其他方法使用自動方法對風險進行分類。

4)風險處理：風險處理包括所有適合緩解和減少風險的措施，以及驗證所應用措施有效性的必要步驟。深度防御策略是汽車領域的一個合適的出發(fā)點。

在此基礎上，風險處理的技術措施主要分為四個層次。

1)接口：現(xiàn)代汽車擁有廣泛的接口，可以作為潛在的攻擊面。我們的目標是盡量減少接口的數(shù)量，并確保所有的接口都受到保護。

2)網(wǎng)關：網(wǎng)關用于互聯(lián)不同的總線系統(tǒng)，因此很適合放置額外的安全措施，以隔離網(wǎng)絡部分和控制訪問。

3)網(wǎng)絡：汽車車輛使用多個內部通信系統(tǒng)，為各自的性能和安全要求量身定做。性能限制了密碼學解決方案的適用性。由于機器對機器通信的預定性質，入侵檢測系統(tǒng)是一個很好的方法。

4)控制單元:保護控制單元的大多數(shù)方法都使用基于硬件的安全性，以確保設備完整性、關鍵功能的隔離和啟用受保護的存儲。這些方法也可以用于篡改保護和確保安全引導。 風險管理的過程需要被整合到生命周期中，以確保在生命周期的正確階段考慮風險識別、評估和分類，并確保以安全的方式實施風險處理措施。

5)過程:為了安全開發(fā)，最早的方法之一是SAE J3061，它基于ISO 26262定義的過程模型。ISO/SAE 21434是汽車系統(tǒng)網(wǎng)絡安全工程標準的進一步發(fā)展，計劃于2020年發(fā)布。 除了這些主要關注于整體工程過程的標準外，IEC 62443還適用于生產(chǎn)環(huán)境和NIST出版物，如用于密鑰管理。另外，安全編碼指導和如何使用基于硬件的安全指導也可以被整合。

B.汽車網(wǎng)絡安全供應鏈管理

根據(jù)UNECE的要求，這里的供應鏈不僅包括汽車工業(yè)的分層結構，還包括售后市場。 對于汽車領域的互動，確保供應商的網(wǎng)絡安全能力的方法可以基于現(xiàn)有的能力和評估方案。

例如，OEM可以要求其供應商根據(jù)TISAX評估證明其系統(tǒng)的信息安全，以確保關鍵信息得到保護。一個受保護的生產(chǎn)環(huán)境可以通過基于IEC 62443的環(huán)境評估來證明。汽車SPICE評估，擴展了安全，也可用于評估流程。

對于責任和任務的分配，可以使用現(xiàn)有的安全的方法。開發(fā)界面協(xié)議（DIA）是為安全關鍵系統(tǒng)的分布式開發(fā)而開發(fā)的。類似的接口協(xié)議可以用來定義車輛生命周期不同階段的責任。例如，監(jiān)測不斷變化的威脅和漏洞的責任可以由汽車制造商以外的組織來承擔。我們看到像AUTO-ISAC這樣的組織在這方面的初步做法。

在這里，關于如何分享事件信息的方法也很重要。圖4給出了不同類型的接口協(xié)議如何涵蓋生命周期的不同階段的例子。



圖4. 生命周期中不同接口協(xié)議的例子

與汽車制造商沒有合同關系的組織的管理更具挑戰(zhàn)性。反向工程顯示，許多目前可用的安卓汽車信息娛樂系統(tǒng)應用程序包括潛在的漏洞。這里的問題是，汽車制造商是否可以通過為第三方應用程序提供安全的執(zhí)行環(huán)境來解決這個問題，或者除此之外，系統(tǒng)需要被限制，只允許由汽車制造商測試的應用程序。

一個類似的分析表明，當車輛在維修店訪問時，診斷界面是一個潛在的風險因素。解決這個問題的一個建議是擴展的車輛概念。擴展的車輛概念包括由外部組織控制對車輛數(shù)據(jù)的訪問，該組織根據(jù)實施情況充當數(shù)據(jù)交換中心或認證機構。這里的一個挑戰(zhàn)是安全和控制訪問與競爭法的規(guī)定之間的潛在沖突。

C.汽車網(wǎng)絡安全保障

根據(jù)ISO/IEC/IEEE 15025-1的定義，保證是 "有理由相信一項要求已經(jīng)或將要實現(xiàn)"。這是通過一個保證案例來完成的，該案例由一個系統(tǒng)的論證及其支持的證據(jù)和假設組成，以證明一個最高級別的要求已經(jīng)實現(xiàn)。雖然ISO/IEC/IEEE 15025對保證案例的結構給出了數(shù)學定義，但GSN等圖形符號也有好處。這兩種方法都有一個挑戰(zhàn)，那就是需要考慮網(wǎng)絡安全不斷發(fā)展的性質，例如，威脅者的能力在不斷增強。

證據(jù)需要顯示網(wǎng)絡安全的完整性和充分性。完整性表明，根據(jù)目前的最先進的技術，所有的風險都得到了考慮。充分性表明，處理風險的方式是充分的。?

完整性可以通過提供證據(jù)證明在整個生命周期內采用了系統(tǒng)的程序來證明。充分性的證據(jù)需要表明風險得到了充分的處理。這方面的保證要求可以從通用標準和NIST的測試指南中獲取。提出的技術從文件審查開始，包括對已經(jīng)使用的系統(tǒng)進行持續(xù)測試和評估的技術。對于網(wǎng)絡安全保障來說，一個挑戰(zhàn)是如何確定什么時候產(chǎn)生的證據(jù)是足夠的。

IV.CSMS框架

正如前面幾節(jié)所概述的，需要一個總體框架，涵蓋完整的生命周期并整合開發(fā)和運營。我們提出了一種DevOps的方法，它適合于將開發(fā)、生產(chǎn)和運營的過程構建成一個一致的框架。提出的框架是基于Dobaj等人以前的工作，結構上分為兩個主要部分，如圖5所示：

1)第五代的車輛E/E架構，首先，能夠將車輛系統(tǒng)連接到云系統(tǒng)，以便繼續(xù)監(jiān)測；其次，提供技術基礎，以建立一個可以輕松更新和重新配置的模塊化系統(tǒng)架構。

2)在模塊化的E/E架構之上，可以建立一個DevOps生命周期，以實現(xiàn)持續(xù)的改進周期。



圖5. 擬議的DevOps框架涵蓋了從開發(fā)到生產(chǎn)再到運營的整個車輛生命周期 監(jiān)控和分析過程是這個生命周期的核心特征，因為這些過程為檢測開發(fā)和運行期間的故障和安全事件提供了基礎。 如圖5中的V型模型所示，擬議的DevOps框架與基于V型模型的傳統(tǒng)系統(tǒng)開發(fā)流程是兼容的。無論是系統(tǒng)開發(fā)周期還是系統(tǒng)改進周期，都由同樣的三個主要階段組成：計劃、創(chuàng)建/實施和驗證與確認（V&V）。

開發(fā)周期由業(yè)務需求觸發(fā)，而改進周期則由監(jiān)控和分析過程自動觸發(fā)，只要在V&V階段或車輛運行期間檢測到故障或安全事件。 在成功的V&V階段之后，在持續(xù)的質量階段進行集成測試、故障注入測試和滲透測試，以保證系統(tǒng)的安全、保障和質量。

在隨后的發(fā)布階段，代碼簽名和信息安全管理被應用，以提供一種措施來確保分布式軟件部署過程中的系統(tǒng)完整性。在隨后的預防階段，安全由每輛車單獨確保。異常情況會在本地進行分析，并傳送到外部系統(tǒng)進行進一步調查。

每當車輛運行過程中檢測到事故或故障，響應階段就會轉發(fā)一份報告。然后，該響應在預測階段由人工處理和分析，或通過[50]中提出的自動推理機制進行處理和分析。獲得的結果被轉發(fā)到故障或事件庫，這是CSMS的一部分。這個存儲庫在適應階段經(jīng)常被掃描，根據(jù)優(yōu)先級標準，選擇一個報告的故障或事件進行調查，從而觸發(fā)下一個持續(xù)改進周期。

V.結論

本文提出了在汽車領域即將到來的網(wǎng)絡安全法規(guī)的挑戰(zhàn)，并確定了現(xiàn)有的構建模塊。對于CSMS的整體結構，介紹了一種DevOps的方法。 公開的挑戰(zhàn)是將構件映射到DevOps流程中，例如，對流程進行細化以包括方法和活動。此外，需要一個分布式的DevOps流程來考慮汽車領域的分層結構，而即將出臺的法規(guī)不僅涉及網(wǎng)絡安全，還涉及軟件更新，需要通過質量認證。認證取決于保證，這需要考慮汽車工程的分布式性質和網(wǎng)絡安全的演變性質。

審核編輯：劉清