3. 安全需求工程与合规基线

很多团队做 IoT 产品安全时，会先收集一堆标准与法规文本，然后在评审会上说“我们要满足 GDPR、ISO 27001、ETSI EN 303 645”。这句话本身没有错，但它不是需求。需求必须能被设计、被实现、被测试，并且能给出明确的通过/不通过判据。本节要解决的核心问题就是：如何把这三类来源不同的合规要求，翻译成产品级、可验证的安全需求规格说明书（Security Requirements Specification，SRS）。

三类合规来源的定位差异

先要分清它们各自“管什么”，否则翻译时容易错位。GDPR 是法律层面的个人数据保护要求，它约束的是“处理个人数据的合法性、目的限制、数据主体权利、跨境传输与泄露通知”，并不直接规定设备要开哪个端口。ISO 27001 是信息安全管理体系标准，它约束的是组织级的管理控制（如资产清单、访问控制策略、供应商管理、事件管理、持续改进），落地到产品时通常转化为流程与职责要求。ETSI EN 303 645 则是面向消费级 IoT 的产品基线，直接给出 13 项条款，例如禁止通用默认口令、实现漏洞披露、保持软件更新、安全存储敏感参数、加密通信、最小化暴露攻击面、保证输入数据有效性、最小化个人数据、增强抗拒绝服务能力、检查数据完整性、限制本地与远程接口等。

因此，合规基线到产品需求的映射不是“一对一翻译”，而是“分层落地”：法律与体系要求决定“必须做什么、由谁负责、留什么证据”，产品基线决定“设备上具体实现成什么行为、用什么参数、如何测试”。

从条款到需求：一个可操作的翻译过程

以 ETSI EN 303 645 第 5.1 条“禁止通用默认口令”为例，演示完整翻译过程。第一步，提取控制目标：设备在出厂状态下不得存在可被公开猜测或跨设备复用的口令。第二步，定义产品行为：设备首次上电时，若检测到出厂口令仍为默认值，则强制进入配网/改密流程，未完成前不允许接入业务网络；口令复杂度至少 8 位且包含大小写字母与数字；同一批次设备不得使用相同初始口令。第三步，写出可验证判据：使用默认口令尝试登录管理接口，应返回失败并触发改密引导；连续 5 次失败后锁定 5 分钟。第四步，指定验证方法：黑盒测试 + 代码审查 + 出厂配置抽查。第五步，关联证据：测试记录、配置截图、代码提交记录。

再以 GDPR 的“数据最小化”为例。法律原文不会告诉你设备该上传哪些字段，但你可以把它翻译为：智能温控器仅上传温度、设定值、设备 ID 与时间戳，不上传用户姓名、精确地理位置与手机号；若业务确需位置用于天气联动，则采用城市级粗粒度并单独征得同意。对应的验证方法是抓包分析 MQTT/HTTPS 载荷，确认字段清单与隐私声明一致。ISO 27001 的供应商管理条款则可翻译为：所选云平台必须提供 ISO 27001 证书且在有效期内，合同包含数据泄露 72 小时通知条款，每年复核一次。

可验证安全需求规格说明书的字段结构

为了让需求可追踪、可审计，建议 SRS 中每条需求至少包含以下字段。下表给出一个可直接参考的示例结构，字段值属于教学示例，实际项目应按产品调整。

合规覆盖矩阵与常见陷阱

完成需求编写后，应建立一张“条款—需求—测试”覆盖矩阵，确认没有条款被遗漏，也没有需求无来源。常见陷阱有三个。第一，把标准条款直接抄成需求，例如“应保证通信安全”，这无法测试；应改为“设备与云平台之间使用 TLS 1.2 及以上，禁用 SSLv3 与 TLS 1.0，证书校验失败时终止连接”。第二，只写功能需求不写安全需求，例如只写“支持 OTA 升级”，没写“升级包签名校验与回滚保护”。第三，忽略证据留存，导致审计时无法证明已满足，例如做了渗透测试却没有保留报告与修复记录。

最后给出一个可执行的检查清单，用于评审 SRS 是否达到“可验证”标准：每条需求是否有唯一 ID；是否标注来源条款；是否包含明确的通过判据；是否指定验证方法；是否有对应测试用例；是否指定证据留存方式；是否覆盖 ETSI EN 303 645 的 13 项条款；是否覆盖 GDPR 的数据主体权利与泄露通知；是否覆盖 ISO 27001 中与产品相关的访问控制、供应商与事件管理条款。满足这些条件后，安全需求才真正成为设计、开发与测试之间的契约，而不是停留在文档里的合规口号。