PASTA 与 VAST 威胁建模

• PASTA 七阶段的内容与顺序
• 业务视角与风险驱动的建模思想
• PASTA 与 STRIDE 的差异

PASTA 是"攻击模拟与威胁分析的流程"，共七个阶段：1) 定义业务目标（Define objectives）；2) 定义技术范围（Define technical scope）；3) 分解应用（Decompose application）；4) 威胁分析（Threat analysis）；5) 漏洞与弱点分析（Vulnerability & weakness analysis）；6) 攻击模拟（Attack modeling & simulation）；7) 风险分析与影响（Risk & impact analysis）。整个过程从业务目标出发，逐步细化到技术范围、应用分解、威胁枚举、漏洞分析、攻击模拟（如攻击树）与风险量化，最终输出风险等级与缓解策略，是"业务对齐、风险驱动"的建模方法。

与 STRIDE 从"技术元素"出发不同，PASTA 从"业务目标"出发，把威胁建模与业务风险、投入产出挂钩，更适合需要向管理层汇报风险、做安全投资的场景。

• 建模输入缺失的应对策略
• 访谈、代码分析、运行时观察等补齐手段
• 不盲目建模的重要性

当架构文档、DFD 与资产清单缺失时，不能盲目建模，应通过多途径补齐输入：1) 与架构师、开发、运维访谈，了解系统职责、数据流与信任边界；2) 通过代码分析（静态分析、依赖扫描）梳理组件、数据流与外部依赖；3) 通过运行时观察（日志、调用链、网络抓包）确认实际数据流与暴露面；4) 从 CMDB、云资源清单、DNS 等盘点资产。补齐后再绘制 DFD 并开始建模，保证分析的准确性。

建模输入的质量决定产出质量。直接从残缺信息建模会把"假设"当"事实"，导致威胁遗漏或误判。补齐输入是"磨刀不误砍柴工"。

• PASTA 从业务目标出发的建模思想
• STRIDE 从技术元素出发的建模思想
• 两种视角的适用场景

PASTA 是业务对齐（business-aligned）的：从业务目标、业务影响出发，把威胁映射到业务风险，用风险等级与业务损失表达，适合向管理层汇报与安全投资决策。STRIDE 是技术视角（technical）的：从系统技术元素（DFD 的进程、数据流、数据存储）出发逐类枚举威胁，重点在技术层面的威胁识别，适合工程师在开发阶段做系统分析。两者侧重不同：PASTA 回答"业务上风险多大、值不值得投入"，STRIDE 回答"系统哪些技术环节可能被攻击"。

实际中两者常互补——PASTA 提供业务与风险框架，STRIDE 提供技术威胁枚举细节。选择取决于受众与目标：面向管理层用 PASTA，面向开发团队用 STRIDE。

• 攻击者视角的核心思想
• 攻击者画像、动机与能力分析
• 攻击模拟与攻击树

PASTA 强调攻击者视角（attacker-centric），即站在攻击者的角度思考"如何攻击该系统"。具体包括：构建攻击者画像（攻击者类型、动机、能力、资源），分析攻击者的目标与可能利用的攻击路径，用攻击树模拟攻击者从目标反推的多种攻击方式，结合威胁情报（CVE、ATT&CK）验证攻击路径的真实性。通过攻击者视角，PASTA 能识别出"防御者盲区"——即防御者认为安全但攻击者实际可利用的路径。

攻击者视角的建模更贴近实战，能发现传统防御视角遗漏的威胁。它把"我们能做什么"转为"攻击者会怎么做"，提升威胁分析的针对性与真实性。

• 攻击树从资产目标反推攻击路径的方法
• 结合 CVE、MITRE ATT&CK 等真实威胁情报
• 用真实情报验证与充实攻击树

提升攻击树质量的关键是让攻击树建立在真实威胁情报而非纯逻辑推演之上：1) 资产目标反推时，优先采用攻击者实际使用的手法（如通过 MITRE ATT&CK 技术项匹配到达该目标的已知路径）；2) 查证目标资产对应组件/软件栈的已知 CVE，将可被利用的漏洞节点纳入攻击树；3) 结合公开漏洞利用（PoC）、威胁情报报告与红队经验，标注攻击路径的可行性与条件；4) 用渗透测试或自动化工具验证攻击树节点的可达性，剔除纸面不可达的路径。这样攻击树才真实反映攻击面。

纯逻辑推演的攻击树容易"纸面可达、实际不可达"。引入 CVE/ATT&CK 等威胁情报，让攻击树锚定真实攻击手法，质量与实战价值显著提升。

• 三种方法的特点与定位
• 各自适用场景与成本
• 选型考量因素

STRIDE 是轻量、技术导向、DFD 驱动的分类枚举法，适合开发团队在迭代中快速识别技术威胁，成本低、易上手。PASTA 是重量级、业务导向、风险驱动的流程方法，适合高风险系统、需要向管理层汇报风险与做安全投资的场景，成本高。VAST 是可视化、敏捷、简单（Visual, Agile, Simple）的方法，强调两个视图（架构视图+攻击者视图）与自动化集成，适合 DevOps/DevSecOps 快速迭代场景。工程取舍看：团队规模与成熟度、系统风险等级、是否需要业务风险度量、CI/CD 集成需求。

没有绝对最优，只有最合适。低成本团队常用 STRIDE 打底，高风险系统用 PASTA 深入，追求敏捷持续化用 VAST。可组合使用，如 STRIDE 做技术枚举、PASTA 做业务风险。

• 持续化建模与一次性建模的差异
• 每个 sprint 增量建模与需求变更触发重估
• 自动化集成

持续化威胁建模把建模嵌入迭代节奏而非一次性工作坊：每个 sprint 的增量建模（对新增/变更的功能做增量威胁分析，而不是全量重做）、需求变更触发重估（当用户故事或需求改变时自动评估受影响威胁）、将威胁建模纳入 Definition of Done 与 CI 门禁（如 VAST 的自动化视图扫描）。VAST 通过可视化与 CI 集成天然支持持续化，PASTA 也可分解为阶段随迭代执行。这样威胁模型与代码同步演进。

一次性工作坊的模型会快速过时。持续化建模低侵入、随开发节奏运行，是 DevSecOps 的核心实践，保证威胁覆盖不落后于代码演进。

• 攻击模拟的落地手段
• 渗透测试、自动化工具与红队的职责
• 攻击树可达性验证

PASTA 攻击模拟的落地包括：用渗透测试（人工测试利用攻击树中的路径）验证攻击树节点是否真实可达；用自动化攻击工具（如扫描器、漏洞利用框架）批量验证已知漏洞与攻击路径；与红队协作进行对抗性演练，验证攻击树未覆盖的绕行路径。这些活动把攻击树从"纸面推演"转化为"实证验证"，剔除不可达节点，识别真实风险并据此调整缓解优先级。

攻击模拟的验证环节是 PASTA 区别于纯分析的关键——它用实证而非推演确认威胁。渗透/红队成本高，通常聚焦攻击树中高风险路径，自动化工具做广度覆盖。

• 工作坊的参与者构成（架构师、开发、安全、运维）
• 输入输出模板与时间盒设计
• 产出录入 backlog 的闭环

威胁建模工作坊的组织要点：参与者包括架构师（提供架构与 DFD）、开发工程师（了解实现细节）、安全工程师（引导威胁枚举与缓解）、运维（了解部署与基础设施）、必要时产品（明确业务目标）。输入模板包括架构文档、DFD、资产清单、威胁与环境上下文；输出模板包括威胁清单、缓解措施、风险等级与追踪项。时间盒设计：限定单次工作坊时长（如 60-120 分钟），聚焦一个功能或组件，避免过度冗长。产出（威胁缓解项）录入 backlog，作为安全任务跟踪直至关闭。

工作坊成败取决于参与者完备与时间盒聚焦。跨角色参与保证威胁覆盖全面，时间盒控制成本，backlog 录入保证落地闭环。

• STRIDE 的输出物（威胁列表）
• PASTA 的输出物（攻击场景、风险分析）
• 输出物差异与用途

STRIDE 的主要输出物是"威胁列表"——按 STRIDE 分类枚举的威胁及对应缓解措施，偏技术性的威胁清单。PASTA 的主要输出物是"攻击场景"与风险分析——包括攻击树（攻击路径）、攻击模拟结果、风险等级与业务影响，输出更偏"攻击场景+风险量化"而非简单列表。STRIDE 列表适合工程团队逐项修复，PASTA 场景适合管理层理解风险与决策。

输出物差异反映两者定位：STRIDE 是"技术威胁枚举"，PASTA 是"业务风险分析"。威胁列表直观、易追踪，攻击场景更深入、更适合风险沟通。

• PASTA 漏洞分析阶段与漏洞管理的关联
• 威胁建模与漏洞扫描的输入输出
• 闭环衔接

PASTA 的第五阶段（漏洞与弱点分析）与漏洞管理衔接：PASTA 识别出的威胁与攻击路径，需要漏洞管理提供实际漏洞数据（扫描结果、CVE、补丁状态）来验证威胁是否可被利用；反之，PASTA 的攻击树可为漏洞管理提供优先级依据（哪些漏洞针对高价值资产、位于高可达路径）。两者闭环：漏洞扫描发现的漏洞反馈给 PASTA 攻击树验证，PASTA 的风险排序指导漏洞修复优先级。

威胁建模是"预测性"分析，漏洞管理是"实证性"数据。衔接使预测与实证互相校验，避免威胁建模脱离实际漏洞、漏洞管理无优先级依据。

• VAST 的 Visual、Agile、Simple 含义
• 与 DevOps/DevSecOps 的契合
• 自动化与可扩展性

VAST（Visual, Agile, and Simple Threat modeling）的设计哲学是"可视化、敏捷、简单"：Visual 强调用可视化模型（流程图）表达架构与攻击面，便于团队理解与沟通；Agile 强调与敏捷开发节奏融合，支持增量建模与持续更新；Simple 强调降低建模门槛与成本，让非安全专家也能参与。VAST 通过两个视图（架构视图+攻击者视图）和自动化集成，契合 DevOps/DevSecOps 的快速迭代与深度集成需求。

VAST 的设计目标是把威胁建模从"专家一次性活动"变为"团队持续化轻量实践"，通过可视化降低门槛、自动化保证覆盖，是云原生与 DevOps 团队常用的方法。

• 架构视图的用途（面向系统架构师）
• 攻击者视图的用途（面向安全/开发团队）
• 两视图的互补

VAST 提供两个互补视图：架构视图（architectural view）面向系统架构师，用流程图描述系统组件、数据流、信任边界与依赖，用于理解系统如何组成、威胁如何跨组件传播；攻击者视图（attacker view）面向安全与开发团队，从攻击者角度描述攻击面、攻击路径与漏洞利用方式，用于模拟攻击与制定缓解。两者共用同一套系统模型，但视角不同，互补覆盖"系统如何构成"与"攻击者如何攻破"。

两个视图分离设计，让不同角色各取所需：架构师聚焦架构视图做设计决策，安全/开发聚焦攻击者视图做攻击分析与缓解，避免观点混淆。

• 威胁模型文件的版本化与可解析
• CI 流水线中的静态分析与门禁
• 自动化威胁扫描

VAST 强调模型文件可版本化、可被工具解析，从而能在 DevOps 流水线中实现自动化门禁：将威胁模型文件纳入版本控制，在 CI 中运行自动化威胁扫描（分析 DFD、数据流、信任边界与依赖），当新代码引入新的攻击面、未缓解的高风险威胁或模型变更时，流水线阻断构建或告警，形成"威胁建模门禁"。这使威胁建模随每次构建持续执行，而非人工定期检查。

自动化门禁的关键是模型可机器解析。它将威胁建模从"人工活动"变为"CI 中的自动检查"，实现 DevSecOps 的"安全左移"与持续保障。

• 可视化（流程图、模型可读性）
• 敏捷（增量建模、持续更新）
• 团队（全员参与、协作）

VAST 的视角体现在三方面：可视化——用流程图模型表达系统架构与攻击面，降低理解门槛，使非安全专家也能读懂威胁；敏捷——与敏捷迭代同步，支持增量建模与持续更新，威胁模型随代码演进；团队——强调跨角色协作（架构师、开发、安全、运维共同参与），让安全成为团队共同责任而非安全工程师独担。三者共同使威胁建模成为团队日常工程实践。

VAST 的"团队"视角打破安全与开发隔阂，通过可视化降低专业门槛、通过敏捷保证时效，让全员参与安全，符合 DevSecOps 文化。

• 三种方法的特点与适用场景
• 选型考量（团队、风险、成本、集成）
• 组合使用

选型参考：STRIDE 适合轻量、技术导向、快速枚举威胁，常见于开发团队在迭代中做系统分析，成本低；PASTA 适合高风险系统、需要业务风险度量与投资决策，过程较重、成本高；VAST 适合 DevOps/DevSecOps 快速迭代、需要 CI 自动化集成与可视化协作的团队。选型考量：团队规模与成熟度、系统风险等级、是否需要业务风险汇报、CI/CD 集成需求、成本预算。实践中也可组合——用 STRIDE 做技术枚举，用 PASTA 做业务风险，用 VAST 做持续化集成。

没有绝对最优方法，应结合团队与场景权衡。多数团队可从轻量 STRIDE 起步，随风险等级与合规需求升级到 PASTA/VAST。

• 风险登记表的构成
• 缓解计划的制定与跟踪
• 风险登记到缓解计划的闭环

威胁建模产出的风险登记（risk register）记录每条威胁的风险等级、影响、可能性、缓解措施与责任人与状态；缓解计划（mitigation plan）针对风险登记中的高风险项制定具体的缓解行动、时间表与验收标准。风险登记与缓解计划结合，形成"识别风险→登记→制定缓解→执行→验证关闭→复审"的闭环，并与漏洞管理、backlog 联动，保证风险持续受控。

风险登记是"静态对照表"，缓解计划是"动态执行清单"。两者结合使威胁建模产出可落地、可跟踪，是安全治理的载体。

• 攻击树在 PASTA 中的产出
• 缓解清单的生成
• 从攻击路径到缓解措施

是的，PASTA 的产出包括攻击树与缓解清单。攻击树是在第六阶段（攻击建模）生成的，从高价值资产目标反推攻击路径，用 AND/OR 关系表达多种攻击方式；缓解清单是基于攻击树与威胁分析，针对每条可达攻击路径设计对应的缓解措施（修复漏洞、加固配置、增加检测等），并按风险等级排序。攻击树回答"怎么被攻破"，缓解清单回答"怎么防/怎么减轻"，两者共同支撑风险决策。

攻击树是 PASTA 的核心分析产物，缓解清单是分析成果的落地。由攻击树推导缓解清单，保证每条缓解措施都有明确的攻击路径依据。

• 哪些环节可自动化（模型扫描、依赖分析、门禁）
• 哪些环节需人工（威胁识别、缓解设计、评审）
• 自动化与人工的边界

威胁建模与 CI 集成的自动化边界：可自动化的环节包括——模型文件解析与扫描（检测 DFD、信任边界、依赖变化）、依赖与组件漏洞扫描（接入 SCA 工具）、触发式门禁（新增攻击面/高风险威胁时阻断）、威胁模型的版本化与差异分析。需人工的环节包括——威胁识别与判断（哪些威胁适用、风险等级评定）、缓解措施设计、安全评审与验收。自动化做"可机器判定的广度覆盖"，人工做"需要判断的深度分析"，边界在于"能否用规则/算法可靠判定"。

明确边界避免过度自动化（把需要判断的威胁识别交给机器）或不足（遗漏可自动化的门禁）。自动化替代重复劳动，人工保留专业判断。

• 风险等级到安全需求的转化
• 验收标准与验证
• 责任归属与跟踪

PASTA 风险评分产出风险等级，落地时：1) 高/中风险对应的威胁转化为具体安全需求（如"对服务间通信启用加密"），写入需求文档；2) 每条安全需求定义可验证的验收标准（如"SSL 证书有效、无明文传输"），供测试与评审验收；3) 明确责任归属——为每条需求指定负责人与团队，纳入 backlog 跟踪直至实现并验证。通过风险等级→需求→验收→责任的四步转化，把风险评分落到可执行、可验证、可追责的工程实践。

风险评分若不落地则流于形式。转化为需求、验收标准与责任归属，使风险分析与工程执行闭环，保证"评了风险就能改"。