威胁建模记录与报告
Sytance · 更新于
威胁模型记录产品架构、攻击场景、防护措施和验证结果。这些记录之间应有明确的对应关系，让评审人员看出每项措施针对什么攻击，以及选择该措施的依据。下文说明各类记录需要包含什么，以及如何评审；工业网关示例展示了这些记录之间的关系。
模型如何组织
将架构图和分析记录放在一起，或者使用稳定标识符关联。小规模评审可以使用文档；当同一控制对应多个威胁，或需要比较不同版本时，结构化记录更便于维护。
在 Sytance 中，团队直接在工作区编辑系统架构和威胁记录，关联安全需求、设计与验证记录。文档模块再根据工作区信息组织报告内容。
产品信息与分析假设
明确产品版本、部署方式、用途和使用人员。说明分析包含哪些部分、依赖哪些外部系统，以及哪些排除项会影响攻击路径。
OWASP 的系统分解方法区分入口、资产和信任级别。描述架构时应区分这三类信息，无需把每项受保护资产都画成图中的处理节点。
- 产品信息：产品、版本、运行环境、用途和评审负责人。
- 系统架构：架构图版本、处理过程、存储、外部实体和数据流。
- 保护目标：需要保密性、完整性或可用性保护的数据与功能。
- 分析假设：每项待确认条件、负责人和确认方法。
每条记录说明一个攻击场景
为每项威胁分配固定编号，并关联架构图中的相关节点或数据流。记录攻击者、所需访问条件、攻击动作、利用的弱点和后果。场景依赖特定条件时，也需要说明。
示例 TM-01：只读网关用户调用配置写接口。如果接口仅验证登录、不检查写权限，该用户就能够修改遥测目的地址。相关数据流是浏览器到管理接口，攻击影响的是配置数据的完整性。
只填写“权限提升，高风险”无法表达这个场景。应补充风险判断的依据：需要什么账户、接口如何暴露、可能造成什么实际影响，以及考虑了哪些现有控制。
防护措施、实现与验证
对于 TM-01，拟采用的控制 AC-01 要求管理接口在每次配置写入时检查操作权限和资源权限。实现记录应注明具体修改，验证记录应包含相应产品版本的实际测试结果。
- 处理决定：降低、消除或接受风险，以及理由和责任人。
- 控制措施：要求的行为，以及它要阻止的攻击步骤。
- 实现信息：对应组件、变更记录和产品版本。
- 验证信息：环境、操作、预期结果、实际结果和证据链接。
- 剩余风险：尚未解决的问题，以及有权作出决定的人员给出的评审结论。
预期结果与实际结果
网关示例的预期结果是：只读身份的写请求被拒绝，存储配置保持不变。实际结果记录测试时观察到的行为；尚未执行测试时，该字段保持待验证。
控制措施同样如此。“计划实现签名验证”与“已实现并测试签名验证”表达的可信程度不同。将记录转成报告或迁移到其他工具时，应保留这个差别。
模型复核
请评审人员从架构图选取一条攻击路径，找到所选措施及测试结果。如果找不到对应内容，应确认是缺少记录，还是攻击过程没有说明清楚。
复核内容包括分析版本与架构图是否一致、每个场景是否有处理决定，以及已接受的风险是否记录了作出该决定的人员。尚未确认的假设继续保留，并注明负责人和确认方法。
更新工作区记录后，在文档模块选择相应报告。Sytance 根据工作区配置与订阅方案提供 HTML 预览及 PDF、DOCX 输出。用于评审前，核对报告中的产品版本、分析内容和验证证据是否与当前记录一致。