4. 风险评估
各位好，欢迎来到第四章。前面我们聊了合规框架和基线要求，但说句实在话，光有合规还不够。你想想看，就算你照着标准把文档填得满满当当，设备该有漏洞还是有漏洞。所以这一章，我们得动真格的了——做风险评估。
ETSI TR 103 621 这套方法论，说白了就是告诉你：怎么系统地找出风险，再给它排个优先级。我在好几个物联网项目里都拿它当底本，效果还不错。今天我就把里面的核心思路掰开揉碎了讲给你听。
核心观点：风险评估不是一次性的“交差活”，而是贯穿产品全生命周期的“体检单”。TR 103 621 的价值在于它把资产、威胁、风险等级串成了一条可执行的流水线。
4.1 资产识别：你得知道自己要保护什么
很多人一上来就急着找漏洞，这是本末倒置。你连自己家里有什么值钱东西都不知道，怎么装防盗门？资产识别就是干这个的。
TR 103 621 把资产分成了三大类，我习惯用一个表格来梳理：
| 资产类别 | 典型示例 | 安全属性（CIA） |
|---|---|---|
| 硬件资产 | 主控芯片、传感器、通信模组、PCB | 完整性、可用性 |
| 软件资产 | 固件、操作系统、通信协议栈、App | 完整性、机密性 |
| 数据资产 | 设备密钥、用户隐私、配置参数、日志 | 机密性、完整性 |
一个小技巧：做资产清单的时候，别只盯着技术资产。我记得有一次帮客户做评估，他们漏掉了“出厂默认配置”这个资产。结果呢？攻击者利用默认密码直接拿下了整个设备群。所以，配置本身也是资产。
4.2 威胁建模：站在攻击者的角度思考
资产清单有了，下一步就是琢磨谁会动这些资产、怎么动。TR 103 621 推荐了几种建模方法，我个人最常用的是 STRIDE，因为它够直观。
STRIDE 把威胁分成六类，每一类对应一个安全属性：
- S - 欺骗（Spoofing）：冒充合法设备或用户。比如伪造设备ID接入网络。
- T - 篡改（Tampering）：修改数据或代码。比如篡改固件升级包。
- R - 抵赖（Repudiation）：否认做过某个操作。比如设备否认发送过恶意指令。
- I - 信息泄露（Information Disclosure）：敏感数据被偷看。比如抓包获取密钥。
- D - 拒绝服务（Denial of Service）：让设备或服务不可用。比如发起DDoS攻击。
- E - 权限提升（Elevation of Privilege）：拿到不该有的权限。比如从普通用户提权到root。
你可能会问：“这六类怎么对应到我的具体设备上？”嗯，我一般会画一张数据流图（DFD），把设备、外部实体、数据存储、数据流都标出来，然后对每个数据流问一遍：“这里能不能S？能不能T？……”
注意：威胁建模最怕“想当然”。我曾经遇到一个团队，觉得自家设备用的是私有协议，攻击者肯定看不懂，所以没把“信息泄露”当回事。结果呢？攻击者直接拿逻辑分析仪抓了SPI总线上的明文密钥。所以，永远不要低估攻击者的耐心和工具。
4.3 风险等级判定：给风险排个队
威胁找出来了，少说几十个，多则上百个。你不可能全修，也没那个预算。所以得给它们排个优先级。TR 103 621 用的是经典的风险 = 可能性 × 影响公式。
具体怎么打分？我一般用 1-5 的标度：
| 等级 | 可能性（1-5） | 影响（1-5） |
|---|---|---|
| 1 | 几乎不可能发生 | 几乎无影响 |
| 2 | 低概率 | 轻微影响（如功能降级） |
| 3 | 可能发生 | 中等影响（如部分数据泄露） |
| 4 | 高概率 | 严重影响（如设备被控） |
| 5 | 几乎必然发生 | 灾难性影响（如批量设备瘫痪） |
然后算乘积：
- 1-6 分：低风险 —— 可接受，持续监控即可。
- 7-14 分：中风险 —— 需要制定缓解措施，限期整改。
- 15-25 分：高风险 —— 必须立即处理，否则产品不能上市。
举个例子：某智能门锁的“固件OTA包被篡改”威胁。可能性我给了3（因为攻击者需要物理接触或中间人位置），影响给了5（一旦成功，所有门锁都能被远程开锁）。3×5=15，高风险。那这个就必须在发布前搞定签名校验。
4.4 避坑指南：我踩过的几个雷
最后，分享几个我在实际项目中遇到的教训，希望能帮你少走弯路：
- 别把“可能性”和“影响”搞混。 有些人觉得“这个攻击很难实现”，就把影响也打低了。这是错的。难实现不代表后果不严重。
- 别忘了第三方组件。 你的设备可能用了开源库、云服务、第三方芯片。这些也是资产，也有威胁。我曾经因为忽略了某个开源协议栈的已知漏洞，导致整个产品线回炉重造。
- 风险等级不是一成不变的。 今天的中风险，明天可能因为新漏洞曝光变成高风险。所以，风险评估报告要有版本号，要定期更新。