中文字幕一区二区三中文字幕-亚洲天天久久精品中文字幕av-美女破处视频在线免费观看-女女女女女女BNBBBB毛-欧美老熟妇黄色三级在线观看资源-人妻丰满熟妇啪啪区-国产一级精品色特级色国产-激情五月天综合激情网-91久久大香伊蕉在人线国产

Sr. No.

(1)

商品或物品

(2)

印度標準

(3)

印度標準名稱

(4)

基本要求

(5)

41

監(jiān)控攝像機

IS 13252: Part 1: 2010

信息技術(shù)設備—通用安全要求

對監(jiān)控基本要求見附件（后附附件內(nèi)容）

Sr. No.

類目

測試參數(shù)

測試內(nèi)容

所需文件

1.

Hardware Level Security Parameter (supported by software)

硬件級安全參數(shù)（軟件支持）

1.1 驗證應用層調(diào)試接口（例如 USB、UART 和其他串行變體）是否已禁用或受復雜密碼保護。

1. 通過被測設備中使用的 SoC 的數(shù)據(jù)表來識別調(diào)試接口（例如 USB、UART 和其他串行變體）的可用性

2. 驗證和確認生產(chǎn)設備中啟用的端口/接口以及供應商文檔中聲明用以保護其的相關(guān)的訪問控制機制

3. 在 OEM 團隊在場的情況下進行測試，以驗證所有端口和調(diào)試接口（例如 USB、UART 和其他串行變體）的啟用/禁用，使用其相關(guān)的基于硬件的調(diào)試器和訪問控制機制（如果啟用了接口）。

4. 制造工廠的流程驗證，以驗證供應商關(guān)于在供應期間關(guān)閉/禁用的調(diào)試接口的聲明。 [例如，通過塊連接圖描繪主微控制器及其與各種子組件/外設的交互之間的引腳連接。]

供應商應提供以下內(nèi)容

a. 設備中使用的 SoC 數(shù)據(jù)表。

b. 與生產(chǎn)設備中啟用的端口/接口以及用于保護其的相關(guān)訪問控制機制相關(guān)的文檔。

c. 設備制造/供應的工藝流程

1.2 驗證加密密鑰和證書對于每個單獨的設備是否都是唯一的

識別設備生態(tài)系統(tǒng)中使用的所有密鑰和證書并通過以下方式進行驗證：

? 在 OEM 團隊在場的情況下進行測試

? 代碼審查

? 密鑰生命周期流程的流程審核

供應商應提交以下材料：

1. 設備生態(tài)系統(tǒng)中使用的所有密鑰和證書的清單

2. 密鑰管理生命周期（用途、生成、存儲、銷毀/清零、有效性、密鑰轉(zhuǎn)換/輪換）

1.3 驗證片上調(diào)試接口（例如 JTAG 或 SWD）是否已禁用，或者可用的保護機制已啟用并正確配置。

1. 通過被測設備中使用的 SoC 的數(shù)據(jù)表來識別調(diào)試接口（例如 USB、UART 和其他串行變體）的可用性

2. 驗證和確認生產(chǎn)設備中啟用的端口/接口以及供應商文檔中聲明用以保護其的相關(guān)的訪問控制機制

3. 在 OEM 團隊在場的情況下進行測試，以驗證所有端口和調(diào)試接口（例如 USB、UART 和其他串行變體）的啟用/禁用，使用其相關(guān)的基于硬件的調(diào)試器和訪問控制機制（如果啟用了接口）。

4. 制造工廠的流程審查，以驗證供應商關(guān)于在供應期間關(guān)閉/禁用的調(diào)試接口的聲明。 [例如，通過塊連接圖描繪主微控制器及其與各種子組件/外設的交互之間的引腳連接。]

供應商應提供以下資料：

a. 設備中使用的 SoC 的數(shù)據(jù)表。

b. 與生產(chǎn)設備中啟用的端口/接口以及用于保護其的相關(guān)訪問控制機制相關(guān)的文檔。

c. 設備制造/供應的流程

1.4 驗證可信執(zhí)行是否已實施并啟用（如果設備 SoC 或 CPU 上可用）。

通過供應商提交的SoC數(shù)據(jù)表和技術(shù)文檔來識別設備中是否提供TEE/SE/TPM。

根據(jù)以下定義的適用于設備的場景進行進一步評估：

情況 1：TEE/SE/TPM 不可用：

沒有進一步評估

情況 2：TEE/SE/TPM 可用并已啟用：

通過代碼審查驗證加密函數(shù)是否通過 TEE/SE/TPM API 調(diào)用。

情況 3：TEE/SE/TPM 可用，但供應商未啟用：

稱為不符合要求。 OEM 需要啟用和實施 TEE/SE/TPM。

供應商應提供以下資料：

1. 設備中使用的 SoC 的數(shù)據(jù)表。

2. 設備的用戶手冊/技術(shù)規(guī)格

3. TEE API 調(diào)用的代碼片段（如果適用）

1.5 驗證敏感數(shù)據(jù)、私鑰和證書是否安全存儲在安全元件、TPM、TEE（可信執(zhí)行環(huán)境）中，或使用強加密技術(shù)進行保護。

識別設備生態(tài)系統(tǒng)中使用的所有密鑰和證書、敏感數(shù)據(jù)及其存儲機制； 并通過以下方式進行驗證：

? 在 OEM 團隊在場的情況下進行測試

? 代碼審查

? 密鑰生命周期流程的流程審核

供應商應提交以下材料：

1. 設備生態(tài)系統(tǒng)中使用的所有密鑰和證書的清單

2. 所有敏感數(shù)據(jù)的清單及其預期用途以及隨設備中啟用的安全配置一同實施的安全存儲機制

3. 密鑰管理生命周期（用途、生成、存儲、銷毀/清零、有效性、密鑰轉(zhuǎn)換/輪換）私鑰和證書。

1.6驗證是否存在防篡改和/或篡改檢測功能。

在 OEM 團隊在場的情況下進行測試，以驗證設備中實施的防止軟件和硬件篡改的措施。

供應商應提交以下材料：

1. 設備中可采取的防止軟件篡改的措施。

2. 設備中可采取的防止硬件篡改的措施。

1.7 驗證芯片制造商提供的任何可用的知識產(chǎn)權(quán)保護技術(shù)是否已啟用。

在 OEM 團隊在場的情況下進行測試，以驗證芯片制造商提供的知識產(chǎn)權(quán)保護技術(shù)（如果有）的啟用情況。

供應商應提交以下材料：

1. SoC 數(shù)據(jù)表

2. 芯片制造商提供的已啟用的知識產(chǎn)權(quán)保護技術(shù)的文檔。

3. 如果芯片制造商沒有提供知識產(chǎn)權(quán)保護技術(shù)，則需要對該技術(shù)進行聲明。

1.8驗證設備是否在加載前驗證了啟動映像簽名。

在 OEM 團隊在場的情況下進行測試，以驗證以下內(nèi)容：

1. 當提供有效的啟動映像時，設備通過記錄的安全啟動過程成功啟動。

2. 當提供篡改過的啟動映像（如簽名缺失、簽名無效）時，設備無法啟動。

供應商應提交以下材料：

1. SoC 數(shù)據(jù)表

2. 設備有關(guān)安全啟動的技術(shù)規(guī)范（應包括所涉及的密鑰及其管理生命周期*、簽名驗證過程以及任何其他安全機制（如果已實施）。））

1.9 驗證嵌入式設備上加密安全偽隨機數(shù)生成器的使用（例如，使用芯片提供的隨機數(shù)生成器）。

驗證供應商提供的有關(guān)設備中使用的隨機數(shù)生成器的文檔。

通過代碼審查驗證設備中是否使用了隨機數(shù)生成器或相關(guān)庫（如果適用）。

供應商應提交有關(guān)設備中使用的隨機生成器（基于硬件或基于軟件或兩者）及其預期用途的文檔。

如果使用基于硬件的隨機數(shù)生成器，供應商應提交以下內(nèi)容：

1. SoC 數(shù)據(jù)表

2. 隨機生成器裝置的技術(shù)規(guī)格

如果使用基于軟件的隨機數(shù)生成器，供應商應提供用于該隨機數(shù)生成器的庫。

2.

Software/Firmware

軟件/固件

2.1 驗證嵌入式/物聯(lián)網(wǎng)操作系統(tǒng)是否啟用了 ASLR 和 DEP 等內(nèi)存保護控制（如果適用）。

在 OEM 團隊在場的情況下進行測試，以使用基于命令行的工具/命令或任何其他開源工具（如 DEP、EMET 工具）來驗證設備中是否可用并啟用聲明的內(nèi)存保護控制。

供應商應提交設備中可用和啟用的內(nèi)存保護控制的聲明。

2.2 驗證固件應用程序是否使用傳輸層安全性來保護傳輸中的數(shù)據(jù)。

1. 驗證設備是否支持強加密算法和安全 TLS 版本以建立安全通信。

2. 驗證該設備是否正確驗證服務器的 TLS 證書，以確保其受信任且未被篡改。

3. 測試可能影響 TLS 連接安全的漏洞，例如密文填塞攻擊或弱密碼套件。

4. 使用 Nmap 等工具來識別可訪問設備，從而導致意外的數(shù)據(jù)檢索的開放端口。

5. 驗證 TLS 會話是否能夠抵抗使用 Burpsuite 等工具的中間人攻擊攔截和解密網(wǎng)絡流量的嘗試。

供應商應提交與傳輸層安全相關(guān)的應用程序和固件中可用配置有關(guān)的規(guī)格和文件。

2.3 驗證固件應用程序是否驗證服務器連接的數(shù)字簽名

1. 識別設備與外界建立服務器連接時的場景并驗證以下內(nèi)容：

? 安全功能，與安全服務器連接和數(shù)字簽名驗證相關(guān)，如強密碼套件、安全 TLS 版本、SSL 固定等，由代碼演練支持。

?設備中實施了正確的證書驗證、證書鏈驗證和證書吊銷檢查。

2. 測試可能影響 TLS 連接安全的漏洞，例如密文填塞攻擊或弱密碼套件。

3. 使用 Nmap 等工具識別可訪問設備導致意外數(shù)據(jù)檢索的開放端口。

4. 驗證 TLS 會話是否能夠抵抗使用 Burpsuite 等工具的中間人攻擊攔截和解密網(wǎng)絡流量的嘗試。

供應商應提交一份文件，提及設備與外部世界建立服務器連接時的用例，并詳細說明在驗證服務器連接的數(shù)字簽名時所采取的安全措施。

2.4 驗證是否用適當?shù)陌踩刃Ш瘮?shù)替換了任何被禁止使用的 C 語言函數(shù)。

在 OEM 團隊在場的情況下，通過以下任一方法使用許可的靜態(tài)分析工具進行安全代碼審查（自動和手動）：

1. 供應商攜帶固件代碼前往評估機構(gòu)，并在其系統(tǒng)中安裝評估機構(gòu)提供的許可靜態(tài)分析工具。【推薦】

2. 供應商攜帶固件代碼和可用的任何許可的靜態(tài)分析工具訪問評估機構(gòu)，并在評估機構(gòu)代表在場的情況下演示代碼審查活動。

3. 向評估機構(gòu)提供對供應商站點系統(tǒng)的遠程訪問，以安裝其可用的許可靜態(tài)分析工具。

4. 向評估機構(gòu)提供對供應商站點的系統(tǒng)的遠程訪問，其中包含固件代碼以及供應商提供的許可靜態(tài)分析工具。

供應商應提供：

1. 用于代碼審查的固件二進制文件。

2. 內(nèi)部代碼審查報告

2.5 驗證每個固件是否維護軟件材料清單，對第三方組件、版本控制和已發(fā)布的漏洞進行編目。

通過在固件上運行 FACT 等自動化工具來驗證提交的第三方組件列表。

通過公開可用的漏洞數(shù)據(jù)庫識別第三方組件中的漏洞

驗證和確認供應商定義的流程，以定期提供固件安全更新和補丁，以解決第三方組件中的任何已知漏洞。

供應商應提交以下材料：

1. 有關(guān)軟件物料清單信息的文檔，包括第三方組件和版本。

2. 以下組織流程和政策：

? 解決并修補第三方組件中任何已識別的漏洞。

? 向客戶通報安全問題或漏洞，并提供安全更新和補丁。

3. 配置管理系統(tǒng)和相關(guān)策略，用于維護固件和第三方二進制文件、庫和框架以及向設備發(fā)布的補丁/修復。

2.6 驗證所有代碼（包括第三方二進制文件、庫、框架）是否經(jīng)過硬編碼憑據(jù)（后門）審查。

通過以下任一方法使用許可的靜態(tài)分析工具進行獨立的安全代碼審查[自動和手動]：

1. 供應商攜帶固件代碼前往評估機構(gòu)，并在其系統(tǒng)中安裝評估機構(gòu)提供的許可靜態(tài)分析工具。 [推薦]

2. 供應商攜帶固件代碼和可用的任何許可的靜態(tài)分析工具訪問評估機構(gòu)，并在評估機構(gòu)代表在場的情況下演示代碼審查活動。

3. 向評估機構(gòu)提供對供應商站點系統(tǒng)的遠程訪問，以安裝其可用的許可靜態(tài)分析工具。

4. 向評估機構(gòu)提供對供應商站點的系統(tǒng)的遠程訪問，其中包含固件代碼以及供應商提供的許可靜態(tài)分析工具。

供應商應提供：

1. 用于代碼審查的固件二進制文件。

2. 內(nèi)部代碼審查報告

2.7 驗證固件應用程序是否將數(shù)字簽名固定到受信任的服務器。

1. 識別設備與外界建立服務器連接時的場景并驗證以下內(nèi)容：

? 安全功能，與安全服務器連接和數(shù)字簽名驗證相關(guān)，如強密碼套件、安全TLS 版本、SSL 固定等，由代碼演練支持。

? 設備中實施了正確的證書驗證、證書鏈驗證和證書吊銷檢查。

供應商應提交一份文件，提及設備與外部世界建立服務器連接時的用例，并提供有關(guān)驗證服務器連接的數(shù)字簽名時所采取的安全措施的詳細信息。

2.7 驗證安全控制是否到位以阻止固件逆向工程（例如刪除詳細的調(diào)試符號）。

在 OEM 團隊在場的情況下進行測試，對供應商提供的用以阻止固件逆向工程的安全控制措施進行驗證

供應商應提交有關(guān)阻止固件逆向工程的安全控制的文檔。

2.8 驗證固件更新過程不易受到檢查時間與使用時間攻擊。

在 OEM 團隊在場的情況下進行測試，以驗證設備中實施的使其能夠抵抗檢查時間與使用時間攻擊的措施。

供應商應提交設備為抵御檢查時間與使用時間攻擊而采取的措施。

2.9 安裝前驗證設備是否使用代碼簽名并驗證固件升級文件。

在 OEM 團隊在場的情況下進行測試，以驗證以下內(nèi)容：

1. 當提供有效的更新包時，設備將通過記錄的安全升級過程成功更新。

2. 當提供被篡改的更新包（如缺少簽名、無效簽名）時，設備無法啟動。

供應商應提交實現(xiàn)安全固件升級的過程，該過程應包括所涉及的密鑰及其管理生命周期*、簽名驗證過程以及任何其他安全機制（如果實施）。

2.10 驗證設備是否無法降級到有效固件的舊版本（防回滾）。

在 OEM 團隊在場的情況下進行測試，以驗證設備無法降級到有效固件的舊版本（防回滾）。

供應商應提交實現(xiàn)安全固件升級的過程，該過程應包括所涉及的密鑰及其管理生命周期*、簽名驗證過程以及任何其他安全機制（如果實施）。

2.11 驗證固件是否可以按照預定義的計劃執(zhí)行自動固件更新。

根據(jù)適用場景進行驗證：

情況 1：可以進行自動 OTA 更新：

供應商需要提交用于向現(xiàn)場設備發(fā)布自動更新/升級的標準操作程序，然后由評估機構(gòu)根據(jù) OWASP 開放標準的 C20、C21 和 C22 安全要求進行評估。

情況2：自動OTA更新不可用，供應商提供手動更新：

供應商需要提交對現(xiàn)場設備進行手動更新/升級的標準操作程序，然后由評估機構(gòu)根據(jù) OWASP 開放標準的 C20、C21 和 C22 安全要求進行評估。

供應商應提供以下資料：

1. 可用的更新模式，即自動、手動或兩者兼而有之。

2. 有關(guān)發(fā)布設備更新的組織流程和政策。

3.

安全流程一致性

3.1 驗證無線通信是否經(jīng)過相互驗證。

在 OEM 團隊在場的情況下進行測試，以驗證供應商文檔中規(guī)定的相互身份驗證過程。

供應商應提供有關(guān)啟動無線通信時在設備中實現(xiàn)的相互身份驗證過程的文檔。 如果設備不支持無線通信，供應商應提供相應聲明。

3.2 驗證無線通信是否通過加密通道發(fā)送。

通過以下方式識別通信過程驗證中使用的所有安全機制：

? 在 OEM 團隊在場的情況下進行測試

? 代碼審查

? 密鑰生命周期流程的流程審核

供應商應提供文件，說明設備為防止通過無線通信模式發(fā)送的數(shù)據(jù)被篡改而采取的安全措施。

如果設備不支持無線通信，供應商應提供相應的聲明。

3.3 驗證是否使用可信來源采購設備組件，即通過管理關(guān)鍵硬件組件（與 SoC 等安全功能相關(guān)）的材料清單使用可信供應鏈。

供應商應提交關(guān)鍵硬件組件（與 SoC 等安全功能相關(guān)）的物料清單。

3.4 應進行供應鏈風險識別、評估、優(yōu)先排序和緩解。需要提交供應鏈風險/業(yè)務連續(xù)性規(guī)劃政策文件、反映如何處理供應鏈中斷的操作手冊、事故后總結(jié)文件，并證明這些文件。

供應商應提交以下文件：

供應鏈風險識別、評估、優(yōu)先排序和緩解文件。

供應鏈風險/業(yè)務連續(xù)性規(guī)劃政策文件、反映如何處理供應鏈中斷的操作手冊、事故后總結(jié)文件。

3.5 驗證設備中沒有使用專有網(wǎng)絡協(xié)議。 如果是，則應提供完整的實現(xiàn)細節(jié)及其源代碼。

設備中使用的網(wǎng)絡協(xié)議的文檔。

4.

產(chǎn)品開發(fā)階段的安全合規(guī)性

4.1 提供 PCBA 和 SoC 級的設計和架構(gòu)細節(jié)，以幫助減少假冒和檢測惡意軟件。

PCBA 和 SoC 級別的設計和架構(gòu)文檔。

4.2 應在產(chǎn)品開發(fā)過程中實施降低有毒和假冒產(chǎn)品威脅的戰(zhàn)略。

需要提交流程和方法工件并進行演示。

4.3 應部署一種或多種最新的惡意軟件檢測工具作為代碼驗收和開發(fā)過程的一部分。

在最終包裝和交付之前應使用惡意軟件檢測技術(shù)（例如，使用一種或多種最新惡意軟件檢測工具掃描成品和組件中是否存在惡意軟件）。

已確定需要跟蹤污染/偽造目標的組件列表、CM 工具。

需要提交并證明質(zhì)量保證流程。

4.4 應進行供應鏈風險識別、評估、優(yōu)先排序和緩解。

需要提交并證明供應鏈風險/業(yè)務連續(xù)性規(guī)劃政策文件、反映如何處理供應鏈中斷的操作手冊、事故后總結(jié)文件。