日本无码免费高清在线|成人日本在线观看高清|A级片免费视频操逼欧美|全裸美女搞黄色大片网站|免费成人a片视频|久久无码福利成人激情久久|国产视频一二国产在线v|av女主播在线观看|五月激情影音先锋|亚洲一区天堂av

  • 手機站
  • 小程序

    汽車測試網(wǎng)

  • 公眾號

    • 汽車測試網(wǎng)

    • 在線課堂

    • 電車測試

汽車試驗：汽車信息安全通用技術(shù)要求

2021-12-17 22:16:44·  來源：汽車測試網(wǎng)  
　
隨著智能化和網(wǎng)聯(lián)化技術(shù)快速發(fā)展和應用，汽車從相對孤立的電子機械系統(tǒng)逐漸演變成能與外界進行信息交互的智能系統(tǒng)，汽車網(wǎng)聯(lián)化衍生的信息安全問題隨之而來。與通
隨著智能化和網(wǎng)聯(lián)化技術(shù)快速發(fā)展和應用，汽車從相對孤立的電子機械系統(tǒng)逐漸演變成能與外界進行信息交互的智能系統(tǒng)，汽車網(wǎng)聯(lián)化衍生的信息安全問題隨之而來。
與通信等行業(yè)的信息安全主要造成財產(chǎn)損失不同，作為高速行駛的載人和載物的交通工具，當發(fā)生汽車信息安全問題，不僅會造成財產(chǎn)損失，還將嚴重威脅人身和公共安全。
本文件基于汽車信息安全風險危害及誘因，針對保護對象制定通用技術(shù)要求(汽車整車及其電子電氣系統(tǒng)和組件的技術(shù)要求可根據(jù)功能設計和風險評估結(jié)果而定)，與其他管理要求標準配合使用，指導建立汽車信息安全技術(shù)體系。標準框架如圖1所示，在規(guī)定原則性要求、系統(tǒng)性防御策略要求等基礎技術(shù)要求的同時，從以下八個維度針對子保護對象制定具體技術(shù)要求：
a) 真實性；
b) 保密性；
c) 完整性；
d) 可用性；
e) 訪問可控性；
f) 抗抵賴；
g) 可核查性；
h) 可預防性。

1 范圍
本文件規(guī)定了汽車信息安全的保護對象和技術(shù)要求。
本文件適用于M類、N類汽車整車及其電子電氣系統(tǒng)和組件。
2 規(guī)范性引用文件
下列文件中的內(nèi)容通過文中的規(guī)范性引用而構(gòu)成本文件必不可少的條款。其中，注日期的引用文件，僅該日期對應的版本適用于本文件；不注日期的引用文件，其最新版本(包括所有的修改單)適用于本文件。
GB/T 29246-2017 信息技術(shù) 安全技術(shù) 信息安全管理體系 概述和詞匯
GB/T 34590.3-2017 道路車輛 功能安全 第3部分：概念階段
3 術(shù)語和定義
GB/T 29246-2017 界定的以及下列術(shù)語和定義適用于本文件。
3.1 汽車信息安全 vehicle cybersecurity
汽車的電子電氣系統(tǒng)、組件和功能被保護，使其資產(chǎn)不受威脅的狀態(tài)。
3.2 真實性 authenticity
一個實體是其所聲稱實體的特性。
[來源：GB/T 29246-2017，2.8，有修改]
3.3 保密性 confidentiality
信息對未授權(quán)的個人、實體或過程不可用或不泄露的特性。
[來源：GB/T 29246-2017，2.12]
3.4 完整性 integrity
準確和完備的特性。
[來源：GB/T 29246-2017，2.40]
3.5 可用性 availability
根據(jù)授權(quán)實體的要求可訪問和可使用的特性。
[來源：GB/T 29246-2017，2.9]
3.6 訪問可控性 access controllability
確保對資產(chǎn)的訪問是基于業(yè)務和安全要求進行授權(quán)和限制的特性。
3.7 抗抵賴 non-repudiation
證明所聲稱事態(tài)或行為的發(fā)生及其源頭的能力。
「來源：GB/T 29246-2017，2.54]
3.8 可核查性 accountability
確?？蓮囊粋€實體的行為唯一地追溯到該實體的特性。
3.9 可預防性 prevent ability
對信息異常行為和攻擊行為進行識別、偵測以及相應安全響應的能力。
3.10 拒絕服務 denial of service；DoS
因阻止對系統(tǒng)資源的授權(quán)訪問或延遲系統(tǒng)運行和功能實現(xiàn)而導致授權(quán)用戶的可用性受損。
3.11 分布式拒絕服務攻擊 distributed denial of service；DDoS
通過損害或控制多個系統(tǒng)對攻擊目標系統(tǒng)的帶寬和資源進行泛洪攻擊而實現(xiàn)拒絕服務。
3.12 后門 backdoor
能夠繞過系統(tǒng)認證等安全機制的管控而進入信息系統(tǒng)的通道。
3.13 安全重要參數(shù) security important parameter
與安全相關(guān)的信息，包含秘密密鑰和私鑰、口令之類的鑒別數(shù)據(jù)或其他密碼相關(guān)參數(shù)的信息。
3.14 訪問控制 accesscontrol
確保對資產(chǎn)的訪問是基于業(yè)務和安全要求進行授權(quán)和限制的手段。
[來源：GB/T 29246-2017，2.1]
4 縮略語
下列縮略語適用于本文件。
CAN： 控制器局域網(wǎng)絡(Controller Area Network)
DoS： 拒絕服務(Denial of Service)
DDoS：分布式拒絕服務攻擊(Distributed Denial of Service)
ECU： 電子控制單元(Electronic Control Unit)
FTP： 文件傳輸協(xié)議(FileTransfer Proto coDSZ c
HSM： 硬件安全模塊(Hardware Secure Module)
ICCID： 集成電路卡識別碼(Integrate Circuit Card Identity)
IMSI： 國際移動用戶識別碼(International Mobile Subscriber Identity)
JTAG： 聯(lián)合測試工作組(Joint Test Action Group)
LIN： 局域互聯(lián)網(wǎng)絡(Local Interconnect Network)
OBD： 車載診斷(On-Board Diagnostics)
TCM： 可信密碼模塊(Trusted Cryptography Module)
TEE： 可信執(zhí)行環(huán)境(Trusted Execution Environments)
Telnet：電信網(wǎng)絡協(xié)議(Telecommunication Network Protocol)
TFTP： 簡單文件傳輸協(xié)議(Trivial FileTransfer Protocol)
TLS： 傳輸層安全協(xié)議(Transport Layer Security)
TPM： 可信平臺模塊(Trusted Platform Module)
V2X： 車輛與車外其他設備之間的無線通信(Vehicle to Everything)
Wi-Fi： 無線保真(Wireless Fidelity)
5 保護對象
5.1 概述
按照保護對象范疇，汽車可劃分為三類子保護對象：車內(nèi)系統(tǒng)、車外通信和車外系統(tǒng)，如圖2所示。
注1：本文件不涉及車外系統(tǒng)。
注2：為了更好地理解保護對象在不同維度的技術(shù)要求，在附錄A的A.1和A.2中分別列舉了車內(nèi)系統(tǒng)和車外通信所面臨的典型的安全威脅。

5.2 車內(nèi)系統(tǒng)
車內(nèi)系統(tǒng)分為如下子保護對象：
a) 軟件系統(tǒng)；
b) 電子電氣硬件；
c) 車內(nèi)數(shù)據(jù)；
d) 車內(nèi)通信。
注：車內(nèi)通信即車內(nèi)系統(tǒng)、組件之間的通信， 例如CAN通信、LIN通信、以太網(wǎng)通信等。
5.3 車外通信
車外通信分為如下子保護對象：
a) 車外遠距離通信；
b) 車外近距離通信。
注1：車外通信是指整車與車外終端的通信。
注2：車外遠距離通信是指蜂窩移動通信、衛(wèi)星導航等。
注3：車外近距離通信是指藍牙、近場無線通信和Wi-Fi等。
6 技術(shù)要求
6.1 原則性要求
6.1.1 業(yè)務適用性原則
產(chǎn)品的信息安全設計應結(jié)合業(yè)務或功能環(huán)境的實際需求，同時考慮對業(yè)務或功能的正常使用的影響。
6.1.2 軟件無后門原則
軟件系統(tǒng)不應留有后門。
6.1.3 功能最小化原則
無用的軟件組件、協(xié)議端口和ECU硬件調(diào)試接口應禁用或移除；器件的管腳信息不宜暴露。
6.1.4 最小化授權(quán)原則
產(chǎn)品的訪問和信息處理活動應只授予必要的權(quán)限。
6.1.5 權(quán)限分離原則
重要保護對象的信息處理活動應具備兩個或兩個以上的權(quán)限，且各權(quán)限應相互分離和單獨授予。
6.1.6 默認設置原則
產(chǎn)品應完成默認的信息安全設置；該設置對用戶的信息安全設置訴求應做到最小化和最簡單化。
6.2 系統(tǒng)性防御策略要求
6.2.1 總則
產(chǎn)品可采用下列系統(tǒng)性防御策略的一種：
a) 縱深防御；
b) 主動防御；
c) 韌性防御。
注：系統(tǒng)性防御策略，是基于構(gòu)建系統(tǒng)的整體信息安全防護而采取的整體防御策略，以避免因各個信息安全防護措施相互孤立而造成整體防護能力不足的問題。
6.2.2 縱深防御要求
縱深防御符合以下要求：
a) 根據(jù)保護對象所處的環(huán)境條件和信息安全管理的要求，應由外到里對保護對象實施層層設防的防護措施；
b) 各層次的安全措施應相互依托，形成系統(tǒng)化的防護機制，從而提高系統(tǒng)的整體抗攻擊能力。
6.2.3 主動防御要求
主動防御應采用包括但不限于情報分享、入侵檢測技術(shù)、信息安全策略動態(tài)調(diào)整和各信息安全模塊之間協(xié)同等措施，以降低信息系統(tǒng)在遭受網(wǎng)絡攻擊時所面臨的風險。
6.2.4 韌性防御要求
信息安全設計應綜合考慮可靠性、功能安全等多個方面的工程設計，以提高系統(tǒng)的生存能力和自愈能力。
6.3 保護維度要求
6.3.1 車內(nèi)系統(tǒng)的保護要求
6.3.1.1 軟件系統(tǒng)的保護要求
6.3.1.1.1 真實性
軟件系統(tǒng)應符合以下真實性要求：
a)當升級、加載和安裝時，驗證提供方的身份真實性和來源的合法性；
b)驗證登錄用戶身份的真實性和合法性。
6.3.1.1.2 保密性
軟件系統(tǒng)應支持防被逆向分析，宜采用代碼混淆或加殼等措施。
6.3.1.1.3 完整性
當軟件系統(tǒng)在啟動、升級、加載和安裝時，應驗證其完整性。
6.3.1.1.4 可用性
當軟件系統(tǒng)設計符合GB/T 34590.32017中A SILC和D級時， 其應支持防DoS/DDoS攻擊。
6.3.1.1.5 訪問可控性
軟件系統(tǒng)應符合以下訪問可控性要求：
a) 具備訪問權(quán)限控制的管理機制；
b) 驗證對各軟件系統(tǒng)資源和數(shù)據(jù)資產(chǎn)的訪問、操作和使用的權(quán)限；
c) 驗證軟件系統(tǒng)的升級、加載和安裝的權(quán)限。
6.3.1.1.6 抗抵賴
軟件系統(tǒng)應具備在請求的情況下為數(shù)據(jù)原發(fā)者或接收者提供數(shù)據(jù)原發(fā)證據(jù)和數(shù)據(jù)接收證據(jù)的功能。
示例：采用數(shù)字簽名技術(shù)等。
6.3.1.1.7 可核查性
軟件系統(tǒng)應符合以下可核查性要求：
a) 記錄重要信息安全事件，包括但不限于用戶活動和操作指令；記錄內(nèi)容宜包含事件的時間、用戶、事件類型、事件處置結(jié)果等信息；
b) 保護審計日志不被非法篡改、刪除和偽造。
6.3.1.1.8 可預防性
軟件系統(tǒng)應具備對自身受到信息安全攻擊的感知能力，當檢測到信息安全攻擊時，宜進行日志記錄、信息安全告警或攻擊阻止的響應。
6.3.1.2 電子電氣硬件保護要求
6.3.1.2.1 完整性
對ECU的封裝(外殼、封條等) 應采用完整性保護。
示例：使用揭開時能留跡象的封條。
6.3.1.2.2 訪問可控性
電子電氣硬件應移除或者禁止不必要的調(diào)試接口。
注：為了更好理解保護對象在不同維度的技術(shù)要求，在A.1.2中列舉了車內(nèi)硬件所面臨的典型安全威脅。
6.3.1.3 車內(nèi)數(shù)據(jù)保護要求
6.3.1.3.1 保密性
安全重要參數(shù)應符合如下保密性要求：
a) 不以明文方式傳輸；
b) 存儲在安全的環(huán)境中。
示例：存儲在TPM、TCM、HSM或TEE等安全環(huán)境中。
6.3.1.3.2 完整性
安全重要參數(shù)應支持完整性校驗。
6.3.1.3.3 可用性
安全重要參數(shù)應防止丟失和被誤刪除，宜采用備份或?qū)Ｓ冒踩臻g存儲等措施。
6.3.1.4 車內(nèi)通信的保護要求
6.3.1.4.1 真實性
車內(nèi)通信應驗證通信雙方身份的真實性。
6.3.1.4.2 保密性
車內(nèi)通信應進行加密保護機制。
6.3.1.4.3 完整性
車內(nèi)通信應采用完整性保護機制。
6.3.1.4.4 可用性
車內(nèi)通信應具備通信流量控制能力。
示例：當受到惡意軟件感染或拒絕服務攻擊而造成車內(nèi)通信流量異常時，仍有能力提供可接受的通信。
6.3.1.4.5 訪問可控性
車內(nèi)通信應符合如下訪問可控性要求：
a) 將車內(nèi)網(wǎng)絡劃分為不同的信息安全區(qū)域，每個信息安全區(qū)域之間宜進行網(wǎng)絡隔離；
b) 信息安全區(qū)域間采用邊界訪問控制機制對來訪的報文進行控制。
示例：采用報文過濾機制、報文過載控制機制和用戶訪問權(quán)限控制機制等。
6.3.1.4.6 可核查性
車內(nèi)通信應具備日志記錄的能力。
示例：記錄流量過載、高頻率的收到異常報文等現(xiàn)象。
6.3.1.4.7 可預防性
車內(nèi)通信應對異常報文具有感知能力；當感知到異常報文時，宜具有告警或其他安全響應的能力。
示例：接收到高頻率的重放報文或被篡改過的報文等異?，F(xiàn)象。
6.3.2 車外通信的保護要求
6.3.2.1 車外遠距離通信的保護要求
6.3.2.1.1 真實性
車外遠距離通信應符合如下真實性要求：
a) 開啟3G、4G、5G通信網(wǎng)絡層的雙向認證功能；
b) 蜂窩移動通信網(wǎng)絡層之上支持獨立的雙向認證機制。
6.3.2.1.2 保密性
車外遠距離通信應符合如下保密性要求：
a) 具備3G、4G、5G通信網(wǎng)絡層的加密功能；
b) 蜂窩移動通信網(wǎng)絡層之上支持獨立的加密機制， 宜采用TLS 1.2版本及以上的安全協(xié)議。
6.3.2.1.3 完整性
車外遠距離通信應符合如下完整性要求：
a) 具備3G、4G、5G通信網(wǎng)絡層的完整性保護功能；
b) 蜂窩移動通信網(wǎng)絡層之上支持獨立的完整性機制， 宜采用TLS 1.2版本及以上安全協(xié)議。
6.3.2.1.4 可用性
與外部通信的部件應支持防DoS/DDoS攻擊。
6.3.2.1.5 訪問可控性
車外遠距離通信應具備對通信報文進行訪問控制的能力。
示例：白名單訪問控制、報文過濾、防通信流量過載機制等。
6.3.2.1.6 抗抵賴
車外遠距離通信應符合如下抗抵賴要求：
a) 確保蜂窩移動通信網(wǎng)絡層通信ID(如：國際移動用戶識別碼IMSI、集成電路卡識別碼ICCID等)的唯一性；
b) 蜂窩移動通信網(wǎng)絡層之上支持獨立的抗抵賴機制(如：使用證書機制等)。
6.3.2.1.7 可預防性
車外遠距離通信應具備對通信報文的安全監(jiān)控能力和攻擊行為的感知能力；當受到信息安全攻擊時，宜進行報文清洗、流量控制或阻止攻擊行為的響應。
6.3.2.2 車外近距離通信保護要求
6.3.2.2.1 真實性
車外近距離通信應開啟身份認證功能。
6.3.2.2.2 保密性
車外近距離通信應開啟加密功能。
6.3.2.2.3 完整性
車外近距離通信應開啟完整性保護功能。
6.3.2.2.4 可用性
與外部通信的部件應支持防DoS/DDoS攻擊。
6.3.2.2.5 可核查性
車外近距離通信應具備記錄近距離通信信息安全相關(guān)事件的能力；記錄的內(nèi)容宜包含來訪用戶ID和通信時間。
附 錄 A
(資料性)
信息安全威脅
A.1 車內(nèi)系統(tǒng)信息安全威脅
A.1.1 軟件系統(tǒng)的信息安全威脅示例
表A.1列舉了軟件系統(tǒng)可能面臨的信息安全威脅。

A.1.2 硬件的信息安全威脅示例
表A.2列舉了電子電氣硬件可能面臨的信息安全威脅。

A.1.3 車內(nèi)數(shù)據(jù)的信息安全威脅示例
表A.3列舉了車內(nèi)數(shù)據(jù)可能面臨的信息安全威脅。

A.1.4 車內(nèi)通信的信息安全威脅示例
表A.4列舉了車內(nèi)通信可能面臨的信息安全威脅。

A.2 車外通信的信息安全威脅
A.2.1 車外遠距離通信的信息安全威脅示例
表A.5列舉了車外遠距離通信可能面臨的信息安全威脅。

A.2.2 車外近距離通信的信息安全威脅示例
表A.6列舉了車外近距離通信可能面臨的信息安全威脅。

參 考 文 獻
[1] ISO/IEC 21827：2008 Information technology—Security techniques—Systems Security Engi-neering—Capability Maturity Model
[2] ISO/IEC 27033-1：2015 Information technology—Security techniques—Network security—Part 1：Overview and concepts
[3] ISO/IEC 27039：2015 Information technology—Security techniques—Selection， deployment and operations of intrusion detection and prevention systems(IDPS)

分享到：
 
反對 0 舉報 0 收藏 0 評論 0
滬ICP備11026917號-25