摘要 ? ?

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

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

I.簡介

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

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



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

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

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

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

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

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

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

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

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


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

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

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

?驗證對已識別風(fēng)險的充分管理

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

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

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

?風(fēng)險評估的更新

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

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

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

C.車輛類型

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

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

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

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

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

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

?處理汽車領(lǐng)域的分布式性質(zhì)的過程

第一套流程可以被概括為風(fēng)險管理流程，第二部分可以被概括為汽車供應(yīng)鏈管理。

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

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

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

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

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

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

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

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

在此基礎(chǔ)上，風(fēng)險處理的技術(shù)措施主要分為四個層次。

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

IV.CSMS框架

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

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

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



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

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

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

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

V.結(jié)論

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

審核編輯：劉清