3、安全测试方法论：威胁建模、STRIDE与攻击树分析、安全测试流程（准备、执行、报告）、合规与标准（如ISO 21434）
TinyML设备的安全测试不能依赖“发现漏洞再修补”的被动思路。由于终端设备数量庞大、算力受限、固件更新困难，一旦批量部署后暴露安全问题，修复成本极高。因此，安全测试必须前置到设计阶段，以系统化的方法论驱动。本章聚焦四块核心内容：威胁建模的工程化落地、STRIDE与攻击树两种分析工具的配合使用、从准备到报告的完整测试流程，以及ISO 21434等合规标准的映射与剪裁。理解这些方法论，是构建可重复、可度量、可追溯的TinyML安全测试体系的前提。
3.1 威胁建模：从资产识别到风险分级
威胁建模不是画几张数据流图就结束，而是要在TinyML设备的全生命周期中，系统性地回答四个问题：我们保护什么？攻击者从哪里进来？最可能的攻击路径是什么？哪些风险必须优先处理？对于TinyML设备，资产不仅仅是固件和模型权重，还包括训练数据、推理结果、设备身份密钥、用户隐私信息以及OTA更新通道。
核心操作流程：
- 资产清单建立：列出所有有价值且可能被攻击者觊觎的对象。例如：模型参数（可能被逆向复制）、推理输入（传感器数据可能包含隐私）、设备密钥（用于云端认证）、固件本身（可能被提取分析）。
- 数据流图绘制：从传感器采集→预处理→模型推理→输出执行→云端通信，每个环节标注数据流向、信任边界、存储位置。TinyML设备尤其要关注“模型加载到内存”和“推理结果返回”这两个边界。
- 攻击面枚举：物理接口（JTAG、UART、USB）、无线接口（BLE、Wi-Fi、LoRa）、侧信道（功耗、电磁辐射）、调试接口（如果未禁用）、OTA更新通道、云端API。
- 风险分级：结合攻击难度、影响程度、利用概率，将威胁分为高/中/低三档。高优先级是“可远程触发且导致设备完全失控”的威胁。
3.2 STRIDE与攻击树分析：两种工具的协同使用
STRIDE提供威胁分类的“检查清单”，确保不遗漏常见攻击类型；攻击树则深入分析特定攻击目标的实现路径。两者结合，既能保证覆盖面，又能聚焦深度。
STRIDE在TinyML中的典型映射：
| STRIDE类别 | TinyML具体场景 | 典型攻击手段 |
|---|---|---|
| Spoofing（仿冒） | 伪造传感器数据输入 | 向I2C/SPI总线注入虚假温度/图像数据 |
| Tampering（篡改） | 修改模型参数或固件 | 通过UART写入恶意权重，或篡改OTA包 |
| Repudiation（抵赖） | 设备否认发送过某条指令 | 日志缺失或时间戳被篡改 |
| Info Disclosure（泄露） | 模型参数/推理结果泄露 | 侧信道攻击提取模型，或内存未清零导致数据残留 |
| DoS（拒绝服务） | 耗尽设备算力/电量 | 持续发送无效推理请求，或触发死循环 |
| Elevation（提权） | 从用户态获取内核权限 | 利用驱动漏洞或缓冲区溢出 |
攻击树构建步骤：
- 定义根节点：例如“获取设备中模型权重”。
- 分解子目标：物理提取（拆芯片读Flash）、逻辑提取（通过调试接口）、侧信道恢复（功耗分析）。
- 标注AND/OR关系：物理提取需要“拆开外壳”AND“找到测试点”AND“使用编程器”；逻辑提取需要“调试接口未禁用”OR“存在固件漏洞”。
- 评估每条路径的成本与可行性：攻击者需要多少时间、设备、专业知识。
3.3 安全测试流程：准备、执行、报告
一个规范的安全测试流程，应当像软件测试一样可重复、可度量。TinyML设备由于资源受限，测试设计必须考虑时间盒和优先级。
阶段一：准备（占整体时间30%）
- 明确测试范围：是仅测试固件，还是包含硬件、通信链路、云端接口？
- 搭建测试环境：准备开发板、调试器（J-Link/ST-Link）、逻辑分析仪、功耗测量设备、无线抓包工具（如nRF Sniffer）。
- 制定测试计划：基于威胁建模输出，将高风险项转化为具体测试用例。例如“通过UART尝试进入AT命令模式”或“发送畸形MQTT包观察设备响应”。
- 准备测试数据：构造边界值输入（如超大图像、空传感器数据）、恶意载荷（如超长字符串）。
阶段二：执行（占50%时间）
- 按优先级执行测试用例，先测远程可利用的漏洞，再测物理接触类。
- 记录每一步操作和观察结果：设备是否重启？LED状态？串口输出？功耗曲线变化？
- 对疑似漏洞进行复现验证，排除偶然因素。
- 使用工具辅助：如用OpenOCD尝试读取Flash，用Wireshark分析BLE通信，用功耗分析仪采集加密操作时的功耗轨迹。
阶段三：报告（占20%时间）
- 每个发现的问题需包含：漏洞描述、复现步骤、影响范围、CVSS评分（如适用）、修复建议。
- 输出风险矩阵：横轴为攻击难度，纵轴为影响程度，将问题分为立即修复、计划修复、可接受风险。
- 提供回归测试建议：修复后如何验证漏洞已消除。
3.4 合规与标准：ISO 21434及行业适配
ISO 21434是道路车辆网络安全工程的国际标准，虽然TinyML设备不全是车规级，但其威胁分析与风险评估（TARA）方法论、供应链安全要求、漏洞管理流程，对任何物联网设备都有参考价值。
ISO 21434核心概念映射到TinyML：
| ISO 21434概念 | TinyML实践对应 |
|---|---|
| 资产识别 | 模型、固件、密钥、用户数据 |
| 威胁场景 | STRIDE分类后的具体攻击场景 |
| 损害场景 | 隐私泄露、设备失控、财产损失 |
| 攻击路径分析 | 攻击树分析 |
| 风险值计算 | 结合攻击可行性、影响程度、可控性 |
| 网络安全目标 | 如“防止未授权读取模型参数” |
| 网络安全需求 | 如“Flash读保护启用”“OTA包签名验证” |
合规落地建议：
- 如果产品面向汽车市场，必须完整执行ISO 21434的TARA流程，并保留文档证据。
- 如果产品是消费级IoT，可剪裁标准，但至少应保留“威胁建模→风险分析→安全需求→验证测试”的闭环。
- 关注GDPR等隐私法规：TinyML设备处理个人数据（如人脸、语音）时，需在测试中验证数据最小化、加密存储、删除机制。
3.5 总结与常见误区复盘
安全测试方法论的核心价值，在于将“安全”从模糊的感觉转化为可执行的工程活动。本章内容可归纳为以下要点：
- 威胁建模是起点：没有资产清单和攻击面分析，后续测试就是盲人摸象。
- STRIDE+攻击树是黄金组合：前者保证广度，后者保证深度。
- 测试流程必须闭环：准备不充分会导致漏测，报告不清晰会导致修复延迟。
- 合规是底线而非目标：ISO 21434提供框架，但真正的安全取决于执行质量。
常见误区：
- 只测软件不测硬件：TinyML设备的安全短板往往在物理接口和侧信道。
- 忽略供应链安全：第三方模型库、RTOS组件、通信协议栈都可能携带漏洞。
- 测试一次就结束：威胁环境动态变化，应建立持续安全测试机制。
- 报告过于技术化：应面向管理层和开发团队分别输出不同详略程度的报告。