杭州瑞诺标准技术服务有限公司

Sr. No.

(1)

商品或物品

(2)

印度标准

(3)

印度标准名称

(4)

基本要求

(5)

41

监控摄像机

IS 13252: Part 1: 2010

信息技术设备—通用安全要求

对监控基本要求见附件（后附附件内容）

Sr. No.

类目

测试参数

测试内容

所需文件

1.

Hardware Level Security Parameter (supported by software)

硬件级安全参数（软件支持）

1.1 验证应用层调试接口（例如 USB、UART 和其他串行变体）是否已禁用或受复杂密码保护。

1. 通过被测设备中使用的 SoC 的数据表来识别调试接口（例如 USB、UART 和其他串行变体）的可用性

2. 验证和确认生产设备中启用的端口/接口以及供应商文档中声明用以保护其的相关的访问控制机制

3. 在 OEM 团队在场的情况下进行测试，以验证所有端口和调试接口（例如 USB、UART 和其他串行变体）的启用/禁用，使用其相关的基于硬件的调试器和访问控制机制（如果启用了接口）。

4. 制造工厂的流程验证，以验证供应商关于在供应期间关闭/禁用的调试接口的声明。 [例如，通过块连接图描绘主微控制器及其与各种子组件/外设的交互之间的引脚连接。]

供应商应提供以下内容

a. 设备中使用的 SoC 数据表。

b. 与生产设备中启用的端口/接口以及用于保护其的相关访问控制机制相关的文档。

c. 设备制造/供应的工艺流程

1.2 验证加密密钥和证书对于每个单独的设备是否都是唯一的

识别设备生态系统中使用的所有密钥和证书并通过以下方式进行验证：

• 在 OEM 团队在场的情况下进行测试

• 代码审查

• 密钥生命周期流程的流程审核

供应商应提交以下材料：

1. 设备生态系统中使用的所有密钥和证书的清单

2. 密钥管理生命周期（用途、生成、存储、销毁/清零、有效性、密钥转换/轮换）

1.3 验证片上调试接口（例如 JTAG 或 SWD）是否已禁用，或者可用的保护机制已启用并正确配置。

1. 通过被测设备中使用的 SoC 的数据表来识别调试接口（例如 USB、UART 和其他串行变体）的可用性

2. 验证和确认生产设备中启用的端口/接口以及供应商文档中声明用以保护其的相关的访问控制机制

3. 在 OEM 团队在场的情况下进行测试，以验证所有端口和调试接口（例如 USB、UART 和其他串行变体）的启用/禁用，使用其相关的基于硬件的调试器和访问控制机制（如果启用了接口）。

4. 制造工厂的流程审查，以验证供应商关于在供应期间关闭/禁用的调试接口的声明。 [例如，通过块连接图描绘主微控制器及其与各种子组件/外设的交互之间的引脚连接。]

供应商应提供以下资料：

a. 设备中使用的 SoC 的数据表。

b. 与生产设备中启用的端口/接口以及用于保护其的相关访问控制机制相关的文档。

c. 设备制造/供应的流程

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 验证敏感数据、私钥和证书是否安全存储在安全元件、TPM、TEE（可信执行环境）中，或使用强加密技术进行保护。

识别设备生态系统中使用的所有密钥和证书、敏感数据及其存储机制； 并通过以下方式进行验证：

• 在 OEM 团队在场的情况下进行测试

• 代码审查

• 密钥生命周期流程的流程审核

供应商应提交以下材料：

1. 设备生态系统中使用的所有密钥和证书的清单

2. 所有敏感数据的清单及其预期用途以及随设备中启用的安全配置一同实施的安全存储机制

3. 密钥管理生命周期（用途、生成、存储、销毁/清零、有效性、密钥转换/轮换）私钥和证书。

1.6验证是否存在防篡改和/或篡改检测功能。

在 OEM 团队在场的情况下进行测试，以验证设备中实施的防止软件和硬件篡改的措施。

供应商应提交以下材料：

1. 设备中可采取的防止软件篡改的措施。

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

1.7 验证芯片制造商提供的任何可用的知识产权保护技术是否已启用。

在 OEM 团队在场的情况下进行测试，以验证芯片制造商提供的知识产权保护技术（如果有）的启用情况。

供应商应提交以下材料：

1. SoC 数据表

2. 芯片制造商提供的已启用的知识产权保护技术的文档。

3. 如果芯片制造商没有提供知识产权保护技术，则需要对该技术进行声明。

1.8验证设备是否在加载前验证了启动映像签名。

在 OEM 团队在场的情况下进行测试，以验证以下内容：

1. 当提供有效的启动映像时，设备通过记录的安全启动过程成功启动。

2. 当提供篡改过的启动映像（如签名缺失、签名无效）时，设备无法启动。

供应商应提交以下材料：

1. SoC 数据表

2. 设备有关安全启动的技术规范（应包括所涉及的密钥及其管理生命周期*、签名验证过程以及任何其他安全机制（如果已实施）。））

1.9 验证嵌入式设备上加密安全伪随机数生成器的使用（例如，使用芯片提供的随机数生成器）。

验证供应商提供的有关设备中使用的随机数生成器的文档。

通过代码审查验证设备中是否使用了随机数生成器或相关库（如果适用）。

供应商应提交有关设备中使用的随机生成器（基于硬件或基于软件或两者）及其预期用途的文档。

如果使用基于硬件的随机数生成器，供应商应提交以下内容：

1. SoC 数据表

2. 随机生成器装置的技术规格

如果使用基于软件的随机数生成器，供应商应提供用于该随机数生成器的库。

2.

Software/Firmware

软件/固件

2.1 验证嵌入式/物联网操作系统是否启用了 ASLR 和 DEP 等内存保护控制（如果适用）。

在 OEM 团队在场的情况下进行测试，以使用基于命令行的工具/命令或任何其他开源工具（如 DEP、EMET 工具）来验证设备中是否可用并启用声明的内存保护控制。

供应商应提交设备中可用和启用的内存保护控制的声明。

2.2 验证固件应用程序是否使用传输层安全性来保护传输中的数据。

1. 验证设备是否支持强加密算法和安全 TLS 版本以建立安全通信。

2. 验证该设备是否正确验证服务器的 TLS 证书，以确保其受信任且未被篡改。

3. 测试可能影响 TLS 连接安全的漏洞，例如密文填塞攻击或弱密码套件。

4. 使用 Nmap 等工具来识别可访问设备，从而导致意外的数据检索的开放端口。

5. 验证 TLS 会话是否能够抵抗使用 Burpsuite 等工具的中间人攻击拦截和解密网络流量的尝试。

供应商应提交与传输层安全相关的应用程序和固件中可用配置有关的规格和文件。

2.3 验证固件应用程序是否验证服务器连接的数字签名

1. 识别设备与外界建立服务器连接时的场景并验证以下内容：

• 安全功能，与安全服务器连接和数字签名验证相关，如强密码套件、安全 TLS 版本、SSL 固定等，由代码演练支持。

•设备中实施了正确的证书验证、证书链验证和证书吊销检查。

2. 测试可能影响 TLS 连接安全的漏洞，例如密文填塞攻击或弱密码套件。

3. 使用 Nmap 等工具识别可访问设备导致意外数据检索的开放端口。

4. 验证 TLS 会话是否能够抵抗使用 Burpsuite 等工具的中间人攻击拦截和解密网络流量的尝试。

供应商应提交一份文件，提及设备与外部世界建立服务器连接时的用例，并详细说明在验证服务器连接的数字签名时所采取的安全措施。

2.4 验证是否用适当的安全等效函数替换了任何被禁止使用的 C 语言函数。

在 OEM 团队在场的情况下，通过以下任一方法使用许可的静态分析工具进行安全代码审查（自动和手动）：

1. 供应商携带固件代码前往评估机构，并在其系统中安装评估机构提供的许可静态分析工具。【推荐】

2. 供应商携带固件代码和可用的任何许可的静态分析工具访问评估机构，并在评估机构代表在场的情况下演示代码审查活动。

3. 向评估机构提供对供应商站点系统的远程访问，以安装其可用的许可静态分析工具。

4. 向评估机构提供对供应商站点的系统的远程访问，其中包含固件代码以及供应商提供的许可静态分析工具。

供应商应提供：

1. 用于代码审查的固件二进制文件。

2. 内部代码审查报告

2.5 验证每个固件是否维护软件材料清单，对第三方组件、版本控制和已发布的漏洞进行编目。

通过在固件上运行 FACT 等自动化工具来验证提交的第三方组件列表。

通过公开可用的漏洞数据库识别第三方组件中的漏洞

验证和确认供应商定义的流程，以定期提供固件安全更新和补丁，以解决第三方组件中的任何已知漏洞。

供应商应提交以下材料：

1. 有关软件物料清单信息的文档，包括第三方组件和版本。

2. 以下组织流程和政策：

• 解决并修补第三方组件中任何已识别的漏洞。

• 向客户通报安全问题或漏洞，并提供安全更新和补丁。

3. 配置管理系统和相关策略，用于维护固件和第三方二进制文件、库和框架以及向设备发布的补丁/修复。

2.6 验证所有代码（包括第三方二进制文件、库、框架）是否经过硬编码凭据（后门）审查。

通过以下任一方法使用许可的静态分析工具进行独立的安全代码审查[自动和手动]：

1. 供应商携带固件代码前往评估机构，并在其系统中安装评估机构提供的许可静态分析工具。 [推荐]

2. 供应商携带固件代码和可用的任何许可的静态分析工具访问评估机构，并在评估机构代表在场的情况下演示代码审查活动。

3. 向评估机构提供对供应商站点系统的远程访问，以安装其可用的许可静态分析工具。

4. 向评估机构提供对供应商站点的系统的远程访问，其中包含固件代码以及供应商提供的许可静态分析工具。

供应商应提供：

1. 用于代码审查的固件二进制文件。

2. 内部代码审查报告

2.7 验证固件应用程序是否将数字签名固定到受信任的服务器。

1. 识别设备与外界建立服务器连接时的场景并验证以下内容：

• 安全功能，与安全服务器连接和数字签名验证相关，如强密码套件、安全TLS 版本、SSL 固定等，由代码演练支持。

• 设备中实施了正确的证书验证、证书链验证和证书吊销检查。

供应商应提交一份文件，提及设备与外部世界建立服务器连接时的用例，并提供有关验证服务器连接的数字签名时所采取的安全措施的详细信息。

2.7 验证安全控制是否到位以阻止固件逆向工程（例如删除详细的调试符号）。

在 OEM 团队在场的情况下进行测试，对供应商提供的用以阻止固件逆向工程的安全控制措施进行验证

供应商应提交有关阻止固件逆向工程的安全控制的文档。

2.8 验证固件更新过程不易受到检查时间与使用时间攻击。

在 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 验证无线通信是否经过相互验证。

在 OEM 团队在场的情况下进行测试，以验证供应商文档中规定的相互身份验证过程。

供应商应提供有关启动无线通信时在设备中实现的相互身份验证过程的文档。 如果设备不支持无线通信，供应商应提供相应声明。

3.2 验证无线通信是否通过加密通道发送。

通过以下方式识别通信过程验证中使用的所有安全机制：

• 在 OEM 团队在场的情况下进行测试

• 代码审查

• 密钥生命周期流程的流程审核

供应商应提供文件，说明设备为防止通过无线通信模式发送的数据被篡改而采取的安全措施。

如果设备不支持无线通信，供应商应提供相应的声明。

3.3 验证是否使用可信来源采购设备组件，即通过管理关键硬件组件（与 SoC 等安全功能相关）的材料清单使用可信供应链。

供应商应提交关键硬件组件（与 SoC 等安全功能相关）的物料清单。

3.4 应进行供应链风险识别、评估、优先排序和缓解。需要提交供应链风险/业务连续性规划政策文件、反映如何处理供应链中断的操作手册、事故后总结文件，并证明这些文件。

供应商应提交以下文件：

供应链风险识别、评估、优先排序和缓解文件。

供应链风险/业务连续性规划政策文件、反映如何处理供应链中断的操作手册、事故后总结文件。

3.5 验证设备中没有使用专有网络协议。 如果是，则应提供完整的实现细节及其源代码。

设备中使用的网络协议的文档。

4.

产品开发阶段的安全合规性

4.1 提供 PCBA 和 SoC 级的设计和架构细节，以帮助减少假冒和检测恶意软件。

PCBA 和 SoC 级别的设计和架构文档。

4.2 应在产品开发过程中实施降低有毒和假冒产品威胁的战略。

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

4.3 应部署一种或多种最新的恶意软件检测工具作为代码验收和开发过程的一部分。

在最终包装和交付之前应使用恶意软件检测技术（例如，使用一种或多种最新恶意软件检测工具扫描成品和组件中是否存在恶意软件）。

已确定需要跟踪污染/伪造目标的组件列表、CM 工具。

需要提交并证明质量保证流程。

4.4 应进行供应链风险识别、评估、优先排序和缓解。

需要提交并证明供应链风险/业务连续性规划政策文件、反映如何处理供应链中断的操作手册、事故后总结文件。