top of page
2024年4月23日

印度BIS認證更新：CCTV閉路監視系統必須通過BIS認證，符合IS 13252-1標準

印度電子與訊息技術部（MEITY）宣布，從2024年10月9日起，所有在印度銷售的CCTV錄影機 (cameras) 和系統 (system) 必須符合BIS標準IS 13252：第1部分：2010的要求。


  1. 強制性合規要求：

    所有CCTV錄影機 (cameras & systems) 必須符合IS 13252-1附錄A中規定的基本要求，包括五個主要安全標準：物理安全、存取控制、網路安全、軟體安全和滲透測試。

  2. 認證要求：

    製造商必須通過BIS認證，並提交來自BIS認可實驗室的測試報告，以確保產品符合印度政府規定的安全和品質標準。

  3. 提升安全標準：

    新規範在於加強消費者保護，確保CCTV攝像機符合嚴格的安全基準，減少電氣危害風險，提高產品可靠性。

  4. 市場影響：

    更新後的規定乃透過標準化的安全要求促進公平競爭和消費者信心，確保印度市場上的所有CCTV攝像機安全可靠。

  5. 合規時間表：

    新規定將於2024年10月9日生效，為製造商提供了確保產品符合新要求的清晰時間表。


 

法規摘錄

編號

商品或物品

印度標準

印度標準標題

基本要求

41

CCTV攝像機 (CCTV Camera)

IS 13252：第1部分：2010

訊息技術設備 - 安全一般要求

根據附錄對CCTV的基本要求

CCTV 安全性基本要求

確保 CCTV（閉路監視器）系統的安全對於保護敏感訊息和確保系統正常運作至關重要，關鍵測試包括網路服務的暴露、設備通訊協定、對設備 UART、JTAG、SWD 等的物理存取、記憶體和硬體的提取能力、韌體更新過程的安全性以及數據的儲存和加密，以下是 CCTV 系統的安全性基本要求：


  1. 物理安全：使用防篡改的攝像機外殼和鎖定機制，防止物理干擾。

  2. 存取控制：採用身份驗證和基於角色的存取控制 (RBAC)，並定期審查和更新存取權限以反映人員變動。

  3. 網路安全：透過加密技術確保數據傳輸安全。

  4. 軟體安全：進行定期更新，禁用未使用功能，並採用強密碼政策。

  5. 滲透測試：進行滲透測試以評估系統抵禦網路攻擊的能力，並及時修補漏洞。

編號

類別

測試參數

測試內容

文件需求

1.

硬體安全參數（軟體支援）

1.1 驗證應用層除錯介面（如 USB、UART 等）被禁用或受複雜密碼保護

1. 透過測試設備中使用的 SoC（系統級晶片）數據表，確認是否存在除錯介面，例如 USB、UART 和其他序列變體 (serial variants)。

2. 驗證和確認生產設備中啟用的傳輸埠/介面及相關的存取控制機制，以確保這些傳輸埠/介面的安全性，這些資訊應在供應商文件中聲明。

3. OEM 團隊在場的情況下進行測試，驗證所有傳輸埠和除錯介面的啟用/禁用狀態，例如 USB、UART 和其他序列變體，使用相關的硬體除錯和存取控制機制（如果介面已啟用）。

4. 驗證製造設施的流程，以確認供應商聲稱在設備配置期間已關閉或禁用除錯介面的狀態。（例如，可透過顯示主/微控制器與各種子組件/周邊設備之間引腳連接的框圖來進行驗證）。

供應商應提供以下文件：

1. 所使用設備的 SoC (系統級晶片) 規格表。

2. 生產設備中啟用的傳輸埠/介面及其相關的存取控制保護機制的文件。

3. 設備的製造/配置流程文件。




1.2 驗證加密金鑰和證書是否對每個設備都是唯一的。

識別設備生態系統中使用的所有金鑰和證書，並透過以下方式進行驗證：

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

2. 代碼審查

3. 關鍵金鑰生命周期過程的流程審核

供應商需提交以下資料：

1. 設備生態系統中使用的所有金鑰和證書清單

2. 密鑰管理生命周期（包括用途、產生、儲存、銷毀/清零、有效性、金鑰更換/輪替）



1.3 確認晶片內除錯介面，例如 JTAG 或 SWD（序列式除錯器），已被禁用或可用的保護機制已啟用並配置適當。

1. 識別測試設備中使用的 SoC 資料表中是否提供除錯介面，如 USB、UART 和其他序列變體。

2. 驗證和確認在生產設備中啟用的傳輸埠/介面以及供應商文件中聲明的相關存取控制機制的保護措施。

3. OEM 團隊的在場下進行測試，確認所有傳輸埠和除錯介面的啟用/禁用狀態，如 USB、UART 和其他序列變體，使用相關的硬體除錯工具和存取控制機制，如果介面已啟用。

4. 對製造設施進行流程審計，以驗證供應商在設備供應期間關閉/禁用除錯介面的聲明。 （例如，透過顯示主/微控制器與各種子組件/外圍設備之間引腳連接的框圖來進行驗證）。

供應商應提供以下資料：

1. 使用於設備中的 SoC（系統級晶片）的數據表。

2. 關於生產設備中已啟用的傳輸埠/介面及其相關保護存取控制機制的文件。

3. 設備製造/供應過程的流程圖。



1.4 驗證在設備的 SoC（系統單晶片）或 CPU 上，若有可用的受信執行環境，則需確認其已實施並啟用。

透過 SoC 資料表和供應商提交的技術文件，識別設備中是否具備 TEE（受信任執行環境）、SE（安全元件）或 TPM（信賴平台模組），進一步的評估將根據以下設備適用的情境進行：

情境 1：如果 TEE/SE/TPM 不可用：不需進一步評估。

情境 2：如果 TEE/SE/TPM 可用且已啟用：透過程式碼審查驗證加密功能是否透過 TEE/SE/TPM API 被呼叫。

情境 3：如果 TEE/SE/TPM 可用但未由供應商啟用：此情況被視為不符合要求，OEM（原設備製造商）需啟用並實施 TEE/SE/TPM。

供應商應提供以下文件：

1. 使用於設備中的 SoC 資料表。

2. 設備的使用手冊或技術規格。

3. TEE API 呼叫的程式碼片段（若適用）。



1.5 驗證敏感數據、私密金鑰和證書是否安全儲存在安全元件（Secure Element）、TPM（信賴平台模組）或 TEE（受信任執行環境）中，或使用強加密技術進行保護。

識別設備生態系統中使用的所有金鑰和證書、敏感數據及其儲存機制，並透過以下方式進行驗證：

1. 在原廠團隊在場的情況下進行測試

2. 代碼審查

3. 金鑰生命周期流程的審計

供應商應提交以下資料：

1. 設備生態系統中使用的所有金鑰和證書的清單。

2. 所有敏感數據的清單，包含其預期用途和實施的安全儲存機制，以及需要在設備中啟用的安全配置。

3. 金鑰管理生命周期的詳細資訊，包括目的、產生、儲存、銷毀/歸零、有效期間、金鑰更換/輪換的流程，適用於私密金鑰和證書。



1.6 驗證防篡改和/或篡改檢測功能的存在

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

供應商應提交以下資料：

1. 設備中可用的防止軟體篡改的措施。

2. 設備中可用的防止硬體篡改的措施。



1.7 驗證晶片製造商提供的任何知識產權保護技術是否已啟用。

在OEM團隊在場的情況下進行測試，以驗證晶片製造商提供的知識產權保護技術是否已啟用（如果有提供的話）。

供應商需提交以下文件：

1.使用於設備的SoC資料表。

2. 有關晶片製造商提供並已啟用的知識產權保護技術的文件；若晶片製造商未提供任何知識產權保護技術，則需提交一份聲明說明此情況。



1.8 驗證設備在加載啟動映像 (Boot Image) 之前是否驗證了啟動映像簽名。

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

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

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

供應商需提交以下文件：

1. 使用於設備的SoC資料表。

2. 關於設備安全啟動的技術規格（應包括涉及的金鑰及其管理生命週期、簽名驗證過程和其他已實施的安全機制）。



1.9 驗證嵌入式設備上使用的加密安全隨機數產生器（例如，使用晶片提供的隨機數產生器）

1. 驗證文件：確認供應商提供的文件，了解設備中使用的隨機數產生器類型。

2. 代碼審查：透過代碼審查，檢查設備中實際使用的隨機數產生器或相關庫。

供應商應提交的文件：

1.隨機數產生器文件：提供有關設備中使用的隨機數產生器（硬體或軟體或兩者皆有）的文件，說明其預期用途。

2. 如果使用硬體隨機數產生器：提交SoC的資料表。

提交關於設備隨機數產生器的技術規格。

如果使用軟體隨機數產生器：提供用於隨機數產生的軟體資料庫的詳細資訊。

2.

軟體/韌體

2.1 驗證嵌入式/物聯網操作系統是否啟用了記憶體保護控制，例如ASLR（地址空間配置隨機化）和DEP（資料執行防護），如果適用。

測試：在OEM團隊的見證下，使用命令行工具/指令或其他開源工具（如DEP、EMET工具）驗證設備中可用且已啟用的記憶體保護控制。

供應商應提交的文件：

1. 設備中可用且已啟用的記憶體保護控制的聲明。



2.2 驗證韌體應用程式是否使用傳輸層安全性（TLS）保護數據在傳輸過程中的安全性

驗證過程：

1. 確認設備是否支援強加密算法和安全的TLS版本以建立安全通信訊。

2. 驗證設備是否能正確驗證伺服器的TLS證書，確保其可信且未被篡改。

3. 測試影響TLS連接安全性的漏洞，如填充Oracle攻擊（Padding Oracle Attack）或弱加密套件。

4. 使用Nmap等工具識別開放傳輸埠，這些傳輸埠可能允許對設備進行存取並導致意外數據檢索。

5. 使用Burpsuite等工具驗證TLS對話 (Sessions) 是否能抵禦攔截和解密網路流量的中間人攻擊。

供應商需提交的文件：

與應用程式和韌體中傳輸層安全性配置相關的規格和文件。



2.3 驗證韌體應用程式是否驗證伺服器連接的數位簽章

識別設備與外界建立伺服器連接的情境，並檢查以下安全功能：

1. 與安全伺服器連接和數位簽章驗證相關的安全特性，例如：強加密套件、安全的TLS版本、SSL Pinning等，透過代碼檢查進行支援。

2. 確認設備是否實施了正確的證書驗證、證書鏈驗證和證書吊銷檢查。

3. 測試可能影響TLS連接安全性的漏洞，例如：填充Oracle攻擊或弱加密套件。

4. 使用Nmap等工具識別設備的開放傳輸埠，這些傳輸埠可能導致未預期的資料檢索。

5. 驗證TLS對話 (Sessions) 是否能抵抗攔截和解密網路流量的攻擊，例如：使用Burpsuite進行的中間人攻擊。

供應商需提交：供應商需提交文件，列出設備與外界建立伺服器連接的使用情境，並詳細說明在驗證伺服器連接數位簽章時所採取的安全措施。



2.4 驗證是否已將任何被禁用的C語言函數替換為相應的安全等效函數

進行安全代碼審查（包括自動和手動方式），在OEM團隊的見證下，使用授權的靜態分析工具，透過以下任一方法進行：

1. 供應商帶著韌體代碼拜訪評估機構，並在該機構的系統中安裝其授權的靜態分析工具進行代碼審查。（推薦方法）

2. 供應商帶著韌體代碼和任何可用的授權靜態分析工具拜訪評估機構，並在評估機構代表的見證下展示代碼審查活動。

3. 提供可遠端存取供應商網站的系統，讓評估機構能夠安裝其可用的授權靜態分析工具。

4. 提供遠端存取供應商網站的系統，該系統包含韌體代碼和供應商可用的授權靜態分析工具。

供應商需提交：

用於代碼審查的韌體二進位文件。

內部代碼審查報告。



2.5 驗證每個韌體是否維護了軟體物料清單（SBOM），包括第三方元件、版本控制和已發佈的漏洞。

驗證方式：

1. 使用自動化工具（如 FACT）對提交的第三方元件清單進行驗證。

2. 透過公共漏洞數據庫識別第三方元件中的漏洞。

3. 驗證和確認供應商針對韌體中的已知漏洞提供定期安全更新和補丁的流程。

供應商應提交以下文件：

1. 關於軟體物料清單的訊息文件，包括第三方元件及其版本。

2. 組織處理程序和政策，包括：針對在第三方元件中發現的任何漏洞進行修補的措施。

3. 通知客戶有關安全問題或漏洞，並提供相應的安全更新和補丁。

4. 配置管理系統及相關政策，用於維護韌體和第三方二進位文件、函式庫和框架，以及對設備發佈的補丁/修復。



2.6 驗證所有代碼，包括第三方二進位文件、函式庫和框架是否經過硬性編碼 (hardcoded credentials) 憑證（後門）的審查。

進行獨立的安全代碼審查（包括自動和手動），使用有許可的靜態分析工具，透過以下方法之一：

1. 供應商帶著韌體代碼前往評估機構，並在其系統中安裝評估機構提供的有許可的靜態分析工具。（建議使用此方法）

2. 供應商帶著韌體代碼和其自有的有許可靜態分析工具拜訪評估機構，並在評估機構代表的見證下進行代碼審查活動。

3. 供應商提供遠端存取其已部署系統的權限給評估機構，以便安裝其自有的有許可靜態分析工具。

4. 供應商提供遠端存取其已部署系統的權限給評估機構，其中包含韌體代碼和供應商提供的有許可靜態分析工具。

供應商需提供以下文件：

1. 用於代碼審查的韌體二進位文件。

2. 內部代碼審查報告。



2.7 確認韌體應用程式將數位簽章固定到受信任的伺服器

驗證項目：

識別設備與外界建立伺服器連接的情境，並驗證以下內容：

1. 相關於安全伺服器連接和數位簽章驗證的安全功能，例如：強大的加密套件、Secure TLS版本、SSL pinning等，這些都是透過程式碼逐步審查 (Code Walkthrough) 來支援和實現的。

2. 正確的證書驗證、證書鏈驗證及證書撤銷檢查是否在設備中實施。

供應商應提交的文件：

文件應該描述設備在何種使用情境下與外界建立伺服器連接，並詳細說明在驗證伺服器連接的數位簽章時所採取的安全措施。



2.7 驗證是否已實施安全控制措施以防止韌體的逆向工程（例如：移除詳細的除錯符號）。

在OEM團隊的見證下進行測試，驗證供應商所提供的防止韌體逆向工程的安全控制措施。

供應商應提交以下文件：

防止韌體逆向工程的安全控制措施相關文件。



2.8 驗證韌體更新過程是否不易受到「檢查時間與使用時間攻擊」(time-of-check vs. time-of-use attacks) 的影響。

在OEM團隊的見證下進行測試，驗證設備中實施的措施是否能抵禦「檢查時間與使用時間攻擊」。

供應商應提交以下文件：

設備中實施的、抵禦「檢查時間與使用時間攻擊」的相關措施文件。



2.9 驗證設備在安裝前是否使用程式碼簽章並驗證韌體升級文件。

在OEM團隊的見證下進行測試，以驗證以下事項：

1. 當提供有效的升級包時，設備可以按照記錄的安全升級流程成功更新。

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

供應商需提交的文件：

有關安全韌體升級過程的詳細文件，應包括使用的金鑰及其管理生命周期、簽章驗證過程，以及所有實施的安全機制。



2.10 驗證設備是否無法降級至舊版本的有效韌體（回滾保護）。

在原廠設備製造商（OEM）團隊在場的情況下進行測試，確保設備無法降級至舊版本的有效韌體（回滾保護）。

供應商需提供以下文件：

確保安全韌體升級的流程文件，應包含所使用的金鑰及其管理生命周期、簽名驗證過程，以及所有已實施的安全機制。



2.11 驗證韌體是否能夠根據預定時間表自動進行韌體更新。

驗證應根據適用的情境進行：

情境 1：支援自動 OTA（無線）更新：

供應商需提交一份針對已部署設備進行自動更新/升級的標準操作程序，該程序將依據 OWASP 開放標準中的 C20、C21 和 C22 安全要求，由評估機構進行評估。

情境 2：不支持自動 OTA 更新且供應商提供手動更新：

供應商需提交一份針對已部署設備進行手動更新/升級的標準操作程序，該程序將依據 OWASP 開放標準中的 C20、C21 和 C22 安全要求，由評估機構進行評估。

供應商需提供以下文件：

1. 可用的更新模式（如自動、手動或兩者皆有）。

2. 有關設備更新發佈的組織流程和政策。

3.

安全流程符合性

3.1 驗證無線通訊是否相互認證。

在原廠團隊的見證下進行測試，以驗證供應商文件中所述的相互認證過程。

1. 供應商應提供設備在啟動無線通訊時所實施的相互認證流程文件。

2. 如果設備不支援無線通訊，供應商應提供相應的聲明。



3.2 驗證無線通訊是否透過加密通道進行

識別通訊過程中使用的所有安全機制，並透過以下方式進行驗證：

1. 在原廠設備製造商（OEM）團隊在場的情況下進行測試

2. 程式碼審查

3. 金鑰生命週期過程的流程審核

供應商應提供文件，詳細說明設備中實施的安全措施，以防止透過無線通訊模式傳輸的數據被篡改。

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



3.3 驗證設備元件是否來自受信任的來源，即是否使用受管理的物料清單（Bill of Materials, BOM）來管理關鍵硬體元件（如與安全功能相關的系統級晶片SoC）


供應商應提交關鍵硬體元件（如與安全功能相關的SoC）的物料清單（BOM）。



3.4供應鏈風險必須進行全面的識別、評估、優先排序和緩解降低風險 (mitigation)

供應商應提交供應鏈風險/業務持續性計劃的政策文件、處理供應鏈中斷的應急方案，以及事件後總結文件，並展示相應的措施。

供應商應提交以下文件：

1. 供應鏈風險識別、評估、優先排序和緩解降低風險 (mitigation) 的文件。

2. 供應鏈風險/業務持續性計劃政策文件，處理供應鏈中斷的應急方案，以及事件後總結文件。



3.5 驗證設備中是否使用了專有的網路協定；如果有，則需提供完整的實施細節和原始碼，提交設備中使用的網路協定文件。


提交設備中使用的網路協定文件。

4.

在產品開發階段進行安全合規性檢查

4.1 提供印刷電路板組裝 (PCBA) 一直到系統級晶片 (SoC) 層級的設計和架構詳細資訊，以幫助防範偽造和檢測惡意軟體。


需提交直到 PCBA 一直到 SoC 層級的設計和架構文件。



4.2 針對受污染和假冒產品的威脅緩解策略應在產品開發過程中實施。

需提交相關的流程和方法文件，並展示實施過程。




4.3 在代碼驗收和開發過程中應部署一種或多種最新的惡意軟體檢測工具，在最終包裝和交付之前，應使用惡意軟體檢測技術（例如，使用一種或多種最新的惡意軟體檢測工具對成品和組件進行掃描）。

需要提交已識別為需要追蹤污染/偽造目標的組件清單和配置管理工具（CM工具），同時，也需要提交品質保證過程的相關文件並進行展示。




4.4 必須進行供應鏈風險的識別、評估、優先排序和緩解降低風險 (mitigation)。


需要提交供應鏈風險/業務持續性計劃政策文件、應對供應鏈中斷的策略手冊以及事後總結報告，並展示相關內容。


標記：

33 次查看
bottom of page