汽車安全不可避免的數位化轉型

創提科技
2022/04/07

分享到

編寫好的軟體很難,確保軟體安全就更難了。它需要專業知識(即對常見程式設計缺陷和規範的認識),檢查輸入尺寸,管理記憶體分配和解除配置,處理字串格式化,避免野指針等等,不勝枚舉。通常情況下,編寫安全的程式碼與開發人員編寫“流暢”的程式碼、專注於正確處理業務邏輯,而不是保護所編寫的每一行程式碼的自然願望是相反的。

 
那麼出現以下情況並不奇怪:雖然大多數軟體漏洞都是由一小部分編碼錯誤引起的,但儘管改進開發實踐多年,行業平均每1000行交付的程式碼中仍有40-70個錯誤。這些錯誤中的一小部分將導致可利用的安全問題,但對於部署了數千萬行程式碼的產品,這可能很快會導致系統安全受到破壞。
 
漏洞通常被定義為“一個可以被壞人利用的弱點”;這個詞作為一種現代管理方式的標誌,最近在領導力和組織諮詢文獻中很常見;在文獻中,領導者和員工都被鼓勵利用漏洞的透明性,以更好地提高工作積極性和績效,但這些幸運理論的基本假設是信任的前提。
 
將漏洞透明性的這些概念引入軟體行業本可能會令人振奮,但當您的產品部署到設計上具有敵意的環境中時,例如在車輛或汽車產品安全性的情況下,會發生什麼?作為一個製造商,當您無法控制產品的使用地點和使用方式時,會發生什麼?他們將與哪些系統交互,誰使用它們或誰可能(有意地或惡意地)訪問它們?在這種環境中,管理程式碼內漏洞的任務就變得至關重要。


汽車行業的安全挑戰
 
還有一些其他因素加劇了汽車行業管理漏洞的挑戰:
 
    1. 遺留問題——汽車軟體發展已經有大約50年的歷史了。通常一輛汽車的壽命至少是12年。車輛平臺每5-7年更換一次,但大部分傳統的軟硬體都是從老的平臺反覆運算到新的平臺的。汽車開發人員使用的主要軟體語言和開發工具是C和C++,這兩種語言在設計上是不安全的,儘管它們為開發人員提供了巨大的靈活性,但沒有提供任何防止系統引入安全性漏洞的保護措施。雖然通過引入編碼標準(如MISRA-C)已經做了一些工作以確保編碼安全,但這些指南很難實施,而且在一些複雜的作業系統(OS)中,遵守這些指南也不切實際。
 
    2. 供應鏈——汽車行業的分散式開發實踐是獨特的,因為它有多層供應商,每一層都向更高的系統集成層提供軟體。一輛典型的汽車可能有50-150個不同的計算單元,由10-20個不同的供應商提供,其中每個元件可能依次包含多個CPU、數十個週邊硬體元件和大量的套裝軟體。由於有這麼多的協力廠商程式碼,考慮到OEM實際上只負責實際編碼的很小一部分,軟體不透明成為了常態,這使得製造商很難評估其安全性。
 
   3. 開源軟體(OSS)——OEM和供應商越來越多地引入主要基於Linux和Android的開源軟體,並集成了來自開源社區的大量庫。這種開發實踐是由面對不斷增長的客戶需求時更快、更敏捷的需求所驅動的。這種對OSS的依賴導致了安全性進一步惡化。


從最佳實踐到監管
 
這些都是棘手的問題,也是過去十年來汽車網路安全界關注的焦點,也做出了各種努力來引導行業朝著正確的方向發展。我也親自參與了其中一些倡議,值得肯定的是,這對當時日益成熟的安全實踐做出了貢獻:
 
    1. The 2016 SAE J3061 "Cybersecurity Guidebook for Cyber-Physical Vehicle Systems"
 
    2. The 2016 NHTSA "Cybersecurity Best Practices for Modern Vehicles"
 
    3. The "Best Practices Guides" by the Auto-ISAC consortium of OEMs and suppliers
 
最值得注意的是,近年來汽車行業圍繞國際標準ISO/SAE21434的發佈展開了合作——這是SAE J3061工作的延伸。與此同時,隸屬WP.29《車輛法規協調》工作組的聯合國歐洲經濟委員會(UNECE)已經開始制定相關規定,在汽車網路安全方面,OEM和製造商必須遵守這些規定才能發放整車型式認證。沒有整車形式認證,汽車就不能售賣。ISO標準和WP.29工作都包括一項指令,要求在從開發到售後的整個汽車生命週期中,對漏洞進行持續管理和監控。
 
我們在這裡見證的是一個由最佳實踐驅動的行業向受監管的行業的轉變,就像汽車品質和安全在過去的演變一樣。


安全數位化轉型
 
擁有一個清晰、規範的流程是改善車輛安全狀況邁出的一大步,但僅靠流程是不夠的。隨著軟體複雜性的不斷增加,大規模管理漏洞也面臨著多重挑戰:
 
1. 可見性——汽車行業歷來是在功能元件這個概念的基礎上組織起來的;因此,OEM都優化了他們的資產管理系統,以管理供應商的零部件,但這些對零部件的內部軟體組成卻知之甚少。這些系統在硬體元件(以及機械部件)層面上管理複雜的供應鏈分配非常出色,但在軟體層面上卻沒什麼用處。通常情況下,產品安全團隊面臨的最大挑戰是洞察系統上的漏洞和威脅,而這些系統的內部卻缺乏可見性。
 
2. 相關性——另一個挑戰是“穿過噪音”。NVD是軟體漏洞的主要來源,平均每年報告超過16000個CVE,其中90%以上的CVE在汽車行業沒有應用,但沒有先進的軟體能夠將這些資料接合軟體的上下文應用到實際的車輛領域,安全團隊花費很多時間檢查數千個漏洞,只是為了確認它們“無關”。
 
3. 可追溯性——在一個元件或開發程式中發現的漏洞很可能與其他元件或開發程式相關,但是對於在垂直項目中工作的團隊來說,無法協調多個程式之間的流程,安全從業者也發現很難“通讀”他們開發的整個系統。
 
4. 可實施性——安全團隊的一項關鍵任務是管理定位漏洞並不斷改善系統狀況的開發工作;對於不同的個體和完全不同的組織結構來說,如果不能以有組織和可擴展的方式進行管理,這將成為一大挑戰。
 
所有這些挑戰都強調了汽車行業安全數位化轉型的必要性。人們認識到,只有人+機器的方法才能提供所需的規模來確保安全,而且自動化和工作流技術的引入對支援新標準和法規所要求的漏洞管理實踐的轉型至關重要。


總結
 
讓我以個人的觀點來總結:我從2013年開始在Cisco工作,後來又在TowerSec和Harman工作,一直從事汽車網路安全領域,銷售產品和服務,以提高聯網汽車的安全性。隨著汽車行業從最佳實踐驅動型向監管化轉變,以及對安全數位化轉型和自動漏洞管理系統的明確需要,我可以清楚地看到新一波產品和技術的出現將帶我們經歷這種轉變。因此,我最近加入Cybellum,因為它在支持行業數位化轉型中具有獨特地位。它使製造商能夠開發和維護安全的產品,無論是在開發階段還是後期生產階段。通過使用一套創新技術,它使OEM和供應商能夠在網路安全數位孿生副本中展示元件和軟體,從而在包級別提供軟體的細細微性可見性。通過監控所有漏洞提要並提供相關的包含上下文資訊的資料來支援貫穿企業內部的工作流管理,Cybellum確保產品安全團隊能夠應對即將到來的挑戰並遵守標準和法規。


關於作者
 
ASAF ATZMON
 
Cybellum的汽車戰略主管。一位經驗豐富的經理,在綜合管理、創新、產品戰略、產品管理和行銷以及業務發展方面擁有超過 20 年的經驗。我是使用者驅動的產品設計和設計思維方法的堅定信徒和宣導者,以建立一個成功的產品戰略,具有很高的市場產品契合機會。我的專業知識涵蓋多個領域,包括網路安全、汽車、物聯網、網路、數位電視、IP 電視、內容推薦、視頻網路、消費者網路和移動。