软件安全系列 | 从架构层面发现不安全的设计 威胁建模知易行难

在软件安全系列选题开篇中，我们谈到，软件应用的安全风险潜藏于软件的全生命周期，涉及需求设计、研发测试、发布部署、应用维护、更新迭代、废弃下线等整个流程。二十一世纪早期，微软提出了安全开发生命周期SDL，从安全角度指导软件开发过程的管理模式，在需求分析、设计、代码开发到发布所有阶段，都引入安全和隐私原则。

基于SDL的方法指导，OWASP中国团队独立发布并主导了安全软件开发生命周期S-SDLC的研究项目，将安全全方位融入软件开发生命周期SDLC的每个阶段，以此来实现软件整体的安全级别。其主要的应用场景是瀑布开发模式，软件复杂规模庞大，版本迭代成本较高，并不需要高频次的部署和交付。

随着发展，为了促进开发与运维团队之间的协作，以及云计算、容器等新技术的兴起，以DevOps为代表的敏捷开发模式被广泛采用，强调持续集成和持续部署CI/CD，所有的活动都是并行和连续的。DevSecOps应运而生，强调安全责任共担，贯穿整个业务生命周期的每一个环节，其不仅是一系列技术和工具的集成，更是一种文化和协作方式的转变。

安全起步：通过威胁建模洞察软件设计缺陷

SDLC与DevSecOps作为SDL理念在不同应用场景下的解决方案，在软件定义一切以及软件安全性被前所未有地重视的趋势下，逐渐成为企业实现安全数字化转型的关键驱动力。无论是哪种开发模式，开发过程中所遵循的一系列步骤和流程都起始于需求分析和设计，即确定软件需求，明确项目目标和功能，创建系统架构和详细设计文档。对应地，S-SDLC与DevSecOps在实践上强调将安全考虑前置到软件开发流程的早期阶段，甚至在需求分析和设计阶段就开始考虑安全问题。

根据多年的实践和经验，软件的很大一部分安全问题是由于不安全的设计引起的，在设计阶段造成的安全缺陷在后期修复的成本比较高。因此，这个早期阶段的安全活动在于发现架构或功能设计方案中的安全威胁，而不是代码的安全，与软件需求分析和设计阶段同步进行，具体措施上首先需要定义安全需求，并且设计安全架构，以初步风险评估，识别潜在安全威胁。

软件在进行安全设计时，通用的方法是威胁建模。这是由微软的安全工程和通信部门开发的一种方法论，定义中明确，“威胁建模是一项工程技术，可以使用它来帮助确定会对您的应用程序造成影响的威胁、攻击、漏洞和对策。您可以使用威胁建模来形成应用程序的设计、实现公司的安全目标以及降低风险。”

这是一种结构化的分析方法，通过绘制软件系统的架构图、分析数据流和识别可能的攻击途径，帮助开发团队提前预见并解决安全问题。需要将系统分解为组件，采用逆向思维，像攻击者一样来思考分析每个组件的安全威胁，这些威胁的合集就构成了系统的威胁清单，通过添加控制措施消除或者减缓威胁，从而降低对业务造成的影响，避免在后期修复漏洞所带来的高成本和风险。

实施威胁建模的关键流程包括识别资产及目标、创建架构图和数据流图、识别潜在威胁、制定缓解措施和进行安全验证：

在初始阶段，需要确定系统中需要保护的关键资产（如数据、功能），根据敏感数据以及相关因素进行分类分级，以及确定攻击者可能的目标。

架构图和数据流图通常以图形方式展示系统，将系统分解为多个关键组件，并标识数据输入、输出、存储和处理的路径。

接下来使用威胁分类模型识别潜在威胁，主流的模型框架包括STRIDE、攻击树Attack Trees、PASTA、VAST、Trike等等，这里主要介绍常用的几种：

STRIDE：微软提出的一种威胁分类方法，对应六类威胁，欺骗Spoofing、篡改Tampering、抵赖Repudiation、信息泄露Information Disclosure、拒绝服务Denial of Service、权限提升Elevation of Privilege；

Attack Trees：以树的形式描述对系统的攻击的图表，根节点表示攻击目标，每个子节点表示实现该攻击目标的可能步骤，每个目标都表示为一个单独的树；

PASTA：一种基于风险的威胁建模方法，强调从攻击者视角进行分析，包含定义业务目标、技术范围分析、应用程序分解、威胁分析、漏洞分析、攻击模拟、风险分析和管理七个阶段。

之后需要评估每个威胁的可能性和影响，使用风险评估矩阵对威胁进行优先级排序，为高风险威胁制定缓解措施。以DREAD风险模型为例，从潜在损害Damage Potential、可重复性Reproducibility、利用难度Exploitability、受影响用户Affected Users、发现难度Discoverability五个方面进行评分。

通过威胁建模，可以得到应用程序体系结构的安全方面的文档以及威胁的列表，最终输出安全设计方案，项目团队基于安全设计方案进行系统功能设计和开发，减轻攻击风险。

落地困境：威胁建模如何跟上敏捷开发的步伐

理论上，威胁建模从早期源头最大程度地识别并缓解了架构级别的安全风险，是安全开发过程中不可或缺的步骤。但在现实中，业务竞争压力驱使着很多互联网厂商和中小型企业在采用敏捷开发模式时，过度地强调快速交付和迭代更新，这种快速开发节奏可能导致很多安全措施，特别是威胁建模阶段的缺失。比如在威胁模型选用上，STRIDE成熟且易于采用，但可能很耗时，Attack Trees易于理解，但要求分析师具有较高的安全专业知识。

在实际的项目中，我们观察到，行业头部的甲方用户在考虑威胁建模时，对于流程的繁琐程度、人工投入的要求高低非常敏感，在落地时会将安全需求分析和架构设计过程结合，对威胁建模过程进行优化，让安全活动尽可能地适应业务的敏捷快速迭代开发模式。以证券行业为例，华泰证券提出了一种基于场景化的轻量级威胁建模方法，供大家参考：

（1）问卷调研。目的是要了解系统的关键信息，为后面的攻击面分析及威胁建模做准备。调研问卷主要包括系统架构、使用场景、重要数据、部署方式等。其中系统架构关注统架构图、技术实现方案等，使用场景关注用户场景、用户群体、角色、访问方式等，数据关注是否有敏感数据，而部署关注部署架构及物理资产。

（2）攻击面分析及业务场景识别。根据调研情况，进行攻击面分析，识别对应的业务场景。

（3）威胁识别。基于业务场景与安全威胁库进行匹配，识别出系统面临的威胁点。

（4）安全设计方案。根据威胁分析结果，匹配安全需求标准库，输出进行威胁缓释需要实施的安全需求基线，制定最终的安全设计方案。

另一方面，受制于技术能力的缺失、成本资源的限制，甲方用户在开发软件系统时，也越来越倾向于引入第三方安全厂商提供的威胁建模系统。采用专业工具的好处在于，安全厂商长期沉淀的安全专家知识库和自主研发的威胁模型算法，可以帮助企业以尽量小的成本和最高的效率为软件系统的开发植入先天安全基因。

我们了解到，默安科技的威胁建模分析系统——雳鉴STAC，基于自研的AI算法，能够做到不同业务场景的精准匹配，自定义更新知识库储备，同步输出威胁建模报告，无缝对接软件需求设计环节，跨部门高效传达安全风险。

雳鉴STAC以问卷形式对项目中涉及到的合规要求、需求场景、设计架构、中间件、对外暴露面、系统重要级别等信息进行调研和数据收集，为后续威胁分析和安全需求提供分析依据。支持AI智能解析，客户只需上传需求报告，便可智能解析各项关键信息，自动匹配问卷选项，减轻安全人员工作压力。支持联动默安科技雳鉴IAST，一键自动化验证威胁建模阶段提出的安全需求、安全设计在测试阶段是否进行闭环，还可以将雳鉴IAST新发现的安全风险反哺到雳鉴STAC知识库中，不断更新与完善。同时，支持知识库自定义功能，客户可根据自身的业务场景进行补充和完善，提高威胁建模的准确性。

比瓴科技的应用安全威胁建模系统——瓴知TMA，以安全专家知识库为核心，增强式LLM、需求识别及决策引擎为驱动，通过场景问答、标签筛选的方式向用户提供轻量化、便捷式的安全威胁建模能力。

安全专家知识库基于其安全专家团队十数年的安全行业积累形成，内容覆盖信息安全相关国家标准及监管要求，可覆盖金融、互联网、政务等行业的核心业务场景。通过多维度的标签体系将知识库条目相互关联形成结构化多维知识网络，并配合语义识别技术构建需求识别和决策引擎，以提供自动化的安全需求分析能力。利用增强式大语言模型LLM和检索增强RAG技术，高效整合海量安全专家知识库和企业内部安全知识，为用户在开发安全领域提供深度知识的快速访问。无安全经验的业务人员及安全经验欠缺的开发人员均可通过该系统快速完成安全分析，降低威胁建模门槛，节省80%威胁建模工作量。

总 结

威胁建模是一种行之有效的安全实践，以前瞻性的目光识别系统中的潜在威胁和漏洞，为软件的安全开发流程奠定良好基础。同时，威胁建模的输出结果也会融入后续的开发、测试等阶段，定期回顾和更新威胁模型以应对新出现的威胁。

关注威胁建模的落地实施，我们需要通过持续评估和快速反馈来保持安全与开发速度的平衡，优先识别和处理最关键的安全风险，确保在每个迭代中逐步提升系统的安全性，而不是试图在一开始就解决所有潜在问题。