📚 课程目录第3章安全需求工程概述

3. 安全需求工程概述

威胁分析做完了，STRIDE 也画了，攻击树也建了。然后呢？

很多团队卡在这一步。手里一堆威胁场景，却写不出一条能落地的安全需求。我见过不少项目，威胁分析报告写了上百页，安全需求文档里就三行字——「芯片要防侧信道攻击」「固件要防篡改」「总线要防非法访问」。这种需求，设计团队看了想打人。

说白了，威胁是「坏人想干什么」，安全需求是「我们要怎么防住他」。中间缺了一个翻译过程。今天我们就聊聊这个翻译怎么做。

我个人习惯用一张表来做映射。左边是威胁场景，右边是安全需求。中间加一列，写「安全目标」——也就是我们到底要保护什么资产。

威胁场景	安全目标	安全需求
攻击者通过 JTAG 端口读取内部固件	保护固件机密性	JTAG 端口必须在产品部署后永久禁用（efuse 控制）
攻击者通过故障注入跳过安全启动校验	保证启动流程完整性	安全启动必须包含故障检测机制，检测到异常时立即复位
攻击者通过 DMA 读取加密引擎内部密钥	保护密钥机密性	密钥存储区域必须对 DMA 访问不可见（MMU/MPU 隔离）
攻击者通过功耗分析提取 AES 密钥	保护密钥机密性	AES 引擎必须实现掩码和随机延时插入的侧信道防护

你看，每条需求都是可设计、可验证的。不是「要安全」，而是「JTAG 用 efuse 关掉」「DMA 过不去」「故障注入就复位」。这才叫需求。

我的经验：写需求时，问自己三个问题——这条需求设计团队能看懂吗？验证团队能写测试用例吗？流片后能测吗？三个「能」都满足，才算合格。

需求写出来了，但资源有限。不可能所有需求都在第一版芯片里实现。怎么办？

按风险排序。风险 = 可能性 × 影响程度。

我见过有人把风险矩阵搞得很复杂，十几个维度，算出来分数自己都解释不清。其实没必要。我一般用三档：

举个例子。我之前做过一颗车规芯片，威胁分析发现 CAN 总线存在重放攻击风险。这个风险的可能性高（攻击者容易接入 CAN 总线），影响也高（可以伪造刹车指令）。所以优先级是 P0，必须在硬件层面加入消息序列号和时间戳校验。

而另一个威胁——通过 UART 输出调试信息泄露固件版本号——可能性低（产品出厂后 UART 默认关闭），影响也低（版本号本身不直接导致攻击）。优先级就是 P2，放到下一版再处理。

  优先级排序的核心原则：先堵死那些「攻击者最容易下手、后果最严重」的漏洞。别在边角料上浪费宝贵的芯片面积和功耗预算。

需求写好了，优先级排好了，接下来要落到文档里。安全需求文档不是写给自己看的，是写给整个项目团队看的——设计、验证、测试、项目经理、甚至客户。

我踩过坑。有一次，我写了一条需求：「AES 引擎必须实现 DPA 防护」。设计团队看了，问：「DPA 防护具体指什么？掩码？隐藏？还是随机延时？」我这才意识到，需求写得不够细。

后来我总结了一套模板，每条需求包含以下字段：

字段	说明	示例
需求编号	唯一标识，方便追溯	SEC-HW-0032
安全目标	对应哪个安全属性	机密性、完整性、可用性
威胁来源	对应哪个威胁场景	THR-0017：JTAG 固件读取
需求描述	具体、可验证的描述	JTAG 端口在 efuse 烧写后必须进入不可恢复的禁用状态
优先级	P0/P1/P2	P0
验证方法	如何验证这条需求	ATE 测试：烧写 efuse 后尝试 JTAG 访问，返回 0xFF
设计约束	对架构或实现的影响	efuse 区域需分配至少 1 bit 用于 JTAG 禁用控制

注意：「验证方法」这个字段最容易被人忽略。没有验证方法的需求，等于没写。设计团队做完了，你说「测一下」，人家问「怎么测」，你说「我也不知道」——这就尴尬了。

另外，文档的版本管理也很重要。我习惯在文档开头加一个变更记录表：

嗯，这里要注意。安全需求文档不是写一次就完事的。随着架构设计深入、威胁分析更新、甚至流片后的测试反馈，需求会不断调整。版本记录能帮你追溯「为什么这条需求变了」，避免后期扯皮。

把上面这些串起来，整个流程大概是这样的：

这个流程看起来线性，其实不是。我做过一个项目，需求文档评审时发现一条 P0 需求的设计约束和现有架构冲突，不得不回头重新分析威胁场景，调整需求描述。迭代是常态，别怕改。

  一句话总结：威胁是故事，需求是规矩。把故事讲清楚，把规矩定明白，芯片才能安全落地。