2. IoT安全威胁与风险建模
IoT系统的安全风险并不只来自“设备被黑”这一件事。一个智能门锁从出厂到用户日常使用，会经过固件烧录、云平台注册、App配网、消息通信、远程升级等多个环节，每个环节都可能成为攻击者的入口。要系统性地识别这些风险，需要先理解攻击面、威胁来源和攻击链，再借助STRIDE、DREAD等建模方法把“可能被怎么打”转化为可排序、可处置的风险清单。
一、典型IoT攻击面与威胁来源
攻击面可以理解为“攻击者能够接触并试图利用的接口、数据、服务或物理通道的总和”。在IoT场景中，攻击面通常分布在四个层面：
- 设备端：调试串口（UART/JTAG）、固件存储、启动流程、本地Web管理页、蓝牙/BLE配网接口、物理按键与传感器。
- 通信层：Wi-Fi、Zigbee、MQTT/CoAP、TLS证书校验、消息重放与中间人攻击。
- 云平台：设备注册接口、设备影子、OTA升级服务、API鉴权、租户隔离。
- 移动App与用户侧：账号体系、令牌存储、配网绑定流程、权限控制。
威胁来源则决定了“谁可能来打、动机是什么”。常见来源包括：机会型攻击者（扫描暴露端口、尝试默认口令）、有组织犯罪（勒索、僵尸网络租用）、内部人员（供应链投毒、越权访问）、以及自动化恶意软件（Mirai类蠕虫）。不同来源的能力和资源差异很大，直接影响风险等级判断。
二、攻击链：从侦察到持久化
攻击链（Cyber Kill Chain）把一次完整入侵拆成若干阶段，帮助防御者在早期环节设卡。IoT攻击链通常表现为：
- 侦察：通过Shodan、Masscan扫描暴露的MQTT 1883端口或设备管理页。
- 武器化：准备默认口令字典、固件提取脚本或恶意OTA包。
- 投递：利用弱口令登录、伪造配网热点、或向设备推送篡改固件。
- 利用：触发命令注入、越权API调用或签名校验绕过。
- 安装：写入后门、修改启动脚本、植入持久化服务。
- 命令与控制：设备回连C2服务器，加入僵尸网络。
- 目标达成：发起DDoS、窃取用户数据或横向渗透家庭内网。
攻击链的价值在于：越靠前的环节被阻断，代价越小。例如在“侦察”阶段关闭不必要的1883端口、强制TLS，就能显著减少被扫描利用的概率。
三、STRIDE：把威胁分类说清楚
STRIDE是微软提出的威胁建模分类法，六类威胁分别对应不同的安全属性破坏：
| 威胁类型 | 破坏属性 | 智能家居示例 |
|---|---|---|
| Spoofing 仿冒 | 真实性 | 伪造设备证书接入云平台 |
| Tampering 篡改 | 完整性 | 修改OTA固件包内容 |
| Repudiation 否认 | 不可否认性 | 用户否认曾下发开锁指令 |
| Information Disclosure 信息泄露 | 机密性 | MQTT明文传输家庭状态 |
| Denial of Service 拒绝服务 | 可用性 | 大量伪造设备耗尽云连接数 |
| Elevation of Privilege 权限提升 | 授权 | 普通账号调用管理员API |
使用STRIDE时，建议沿着数据流图逐条边、逐个进程提问：这条消息能否被伪造？存储的数据能否被篡改？操作能否被抵赖？这样比泛泛讨论“设备安全吗”更容易得到具体威胁条目。
四、DREAD：给风险排优先级
识别出威胁后，需要判断先修哪个。DREAD从五个维度打分（通常1～10分），再取平均值作为风险分值：
- Damage Potential：一旦被利用，损害有多大？
- Reproducibility：复现难度如何？是否稳定触发？
- Exploitability：利用门槛高不高？是否需要特殊工具？
- Affected Users：影响多少用户或设备？
- Discoverability：漏洞是否容易被发现？
例如“MQTT未启用TLS”这一威胁，损害程度可打8分（可窃取家庭状态），复现难度9分（抓包即可），利用难度7分（工具成熟），影响用户数9分（全量设备），可发现性8分（扫描即可发现），平均约8.2分，属于高优先级。而“调试串口未锁定”若设备已封装且需拆机，利用难度和可发现性较低，平均可能只有5分左右，可排后处理。
五、智能家居威胁建模实战
下面以一个“智能门锁+网关+云平台+App”的示例系统，完成一次简化的威胁建模。假设系统数据流为：门锁通过BLE与网关配网，网关经MQTT over TLS连接云平台，App通过HTTPS调用云API下发开锁指令，云平台通过MQTT向网关推送指令，网关再经BLE转发给门锁。
第一步：画数据流图并标出信任边界。信任边界包括：门锁与网关之间（BLE）、网关与云之间（公网）、App与云之间（公网）、云内部服务之间。跨边界的每条数据流都是重点分析对象。
第二步：对每条数据流套用STRIDE。以“App→云API下发开锁指令”为例：
- S：攻击者伪造App身份调用开锁API；
- T：指令在传输中被篡改；
- R：用户否认下发过开锁指令；
- I：API响应泄露门锁状态；
- D：高频调用导致API不可用；
- E：普通家庭成员账号越权开锁。
第三步：用DREAD打分并排序。假设团队约定评分标准后得到如下结果（示例评分，非实测）：
| 威胁 | D | R | E | A | D | 均值 | 优先级 |
|---|---|---|---|---|---|---|---|
| 伪造App调用开锁API | 9 | 7 | 6 | 8 | 7 | 7.4 | 高 |
| 开锁指令被篡改 | 9 | 6 | 5 | 7 | 6 | 6.6 | 高 |
| 用户否认开锁操作 | 5 | 8 | 8 | 6 | 7 | 6.8 | 中高 |
| API响应泄露门锁状态 | 4 | 8 | 7 | 9 | 8 | 7.2 | 高 |
| 高频调用导致API不可用 | 6 | 9 | 8 | 9 | 9 | 8.2 | 高 |
| 家庭成员越权开锁 | 8 | 5 | 4 | 5 | 4 | 5.2 | 中 |
第四步：制定缓解措施并回填验证。针对高分项，可采取：开锁API强制双向TLS+设备指纹；指令携带时间戳与随机数防重放；API响应最小化字段；对开锁接口做频率限制与异常告警；家庭成员账号采用角色权限模型，开锁权限单独授权。每项措施落地后，重新评估对应DREAD分值是否下降，形成闭环。
总结来看，IoT安全威胁建模的核心路径是：先看清攻击面和威胁来源，再用攻击链理解攻击者如何一步步推进，接着用STRIDE把威胁分类说清楚，用DREAD把风险排出优先级，最后落到具体产品上形成可执行的缓解措施。这套方法不依赖昂贵工具，但要求团队对系统数据流有真实、准确的认识。