摘要 ? ?
網(wǎng)絡(luò)安全越來越被認為是汽車系統(tǒng)的一個重要話題,特別是在聯(lián)網(wǎng)和自動駕駛領(lǐng)域。即將出臺的法規(guī)對汽車領(lǐng)域的網(wǎng)絡(luò)安全提出了多層次的要求,以獲得型號批準(zhǔn)。在組織層面,需要一個涵蓋整個車輛生命周期和生態(tài)系統(tǒng)的網(wǎng)絡(luò)安全管理系統(tǒng)(CSMS)。此外,必須對申請型號批準(zhǔn)的每一種車輛類型的網(wǎng)絡(luò)安全進行論證。
由于這些要求與現(xiàn)有的型號批準(zhǔn)要求相比具有新穎性,因此正在進行測試階段。CSMS的組成部分和范圍是一個開放的問題。本文概述了CSMS的要求,確定了方法和差距,并對能夠滿足這些要求的潛在框架進行了展望。
I.簡介
汽車正在從孤立的、主要是電子機械系統(tǒng)向帶輪子的連接計算機發(fā)展。目前,這是由監(jiān)管和汽車工業(yè)提供額外服務(wù)的愿望所驅(qū)動的。進一步邁向部分和全自動化的車輛只會加速這一趨勢。像進一步減少交通事故或減少交通能源這樣的目標(biāo),只有通過合作和自動駕駛車輛才能實現(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)于車輛類型批準(zhǔ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é)涉及到車型的批準(zhǔn)。對于擬議的法規(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)、使用和退役的生命周期。為了獲得型號批準(zhǔ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認證到位后,才能進行整車型式批準(zhǔn)。整車型式批準(zhǔn)的證據(jù)需要包括: ?在風(fēng)險評估中如何考慮已知的漏洞和威脅。風(fēng)險評估需要考慮整個車輛、所有車輛系統(tǒng)以及它們之間的相互作用。 ?在風(fēng)險評估中被確定為關(guān)鍵的要素,被設(shè)計成適當(dāng)?shù)陌踩胧?,以使風(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)鏈?zhǔn)占万炞C。
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)險識別方法中。一個成熟的方法是由評估攻擊概率的通用標(biāo)準(zhǔn)來定義的。攻擊概率可以根據(jù)現(xiàn)有的信息和生命周期階段進行調(diào)整。這被用作EVITA項目的出發(fā)點。在HEAVENS項目中,收集了一套風(fēng)險識別和評估方法并發(fā)表了報告。在CySiVuS項目中,開發(fā)了一個基于FAIR的統(tǒng)一的安全和保障的定量風(fēng)險評估。
3)風(fēng)險歸類:風(fēng)險分類目前仍是一個開放的話題?,F(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)代汽車擁有廣泛的接口,可以作為潛在的攻擊面。我們的目標(biāo)是盡量減少接口的數(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ò)安全工程標(biāo)準(zhǔn)的進一步發(fā)展,計劃于2020年發(fā)布。 除了這些主要關(guān)注于整體工程過程的標(biāo)準(zhǔ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)險得到了充分的處理。這方面的保證要求可以從通用標(biāo)準(zhǔn)和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)先級標(biāo)準(zhǔn),選擇一個報告的故障或事件進行調(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ì)。
審核編輯:劉清
評論