摘要 ? ?

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

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

I.簡介

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

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



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

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

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

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

II.對網絡安全流程的要求和擬議的法規

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

A.網絡安全管理系統

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

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


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

?組織中的網絡安全管理

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

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

?在開發和生產過程中的安全測試

?檢測和應對針對車輛類型的網絡攻擊

?識別和管理新的網絡威脅和車輛類型的脆弱性

?風險評估的更新

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

B.后期生產階段

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

C.車輛類型

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

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

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

III.汽車網絡安全框架的技術現狀

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

?在開發、生產和后期制作中管理網絡安全的流程

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

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

A.汽車網絡安全風險管理

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

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

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

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

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

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

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

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

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

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

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

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

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

B.汽車網絡安全供應鏈管理

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

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

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

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



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

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

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

C.汽車網絡安全保障

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

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

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

IV.CSMS框架

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

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

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



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

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

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

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

V.結論

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

審核編輯：劉清