| 编辑推荐: |
本文主要介绍了什么是威胁建模，威胁建模的价值，遇到了哪些挑战，威胁建模的能力要求，评估流程，实施威胁建模以及经验教训等相关内容。
来自于美团技术团队,由火龙果软件Anna译、推荐。 |
|
对美团安全团队来说，引入领先的安全技术设计能力，构建全方位、多维度智能防御体系，是我们不懈追求的目标。美团有众多基础设施，核心业务系统也需要以成熟的方法论进行威胁评审。本文将着重分享威胁建模是如何帮助美团安全团队评估、发现大量安全设计的风险，以及互联网企业应该如何大范围地实施威胁建模并完整地进行落地。
1 写在前面
1.1 什么是威胁建模
孙子兵法：知彼知己，百战不殆；不知彼知己，一胜一负；不知彼不知己，每战必殆。
微软：威胁建模实践使开发团队可以在计划的运行环境的背景下，以结构化的方式思考、记录并讨论系统设计的安全影响。威胁建模是帮助保护系统、应用程序、网络和服务的有效方法。这是一种工程技术，用于识别潜在的威胁和建议，以帮助降低风险并在开发生命周期的早期实现安全目标。
OWASP: identifying, communicating, and understanding
threats and mitigations within the context of protecting
something of value.
计算机发明后不久，人们就发现需要为这些信息系统处理威胁。早在1994年，NSA和DARPA就提出了攻击树、威胁树等概念。1999年微软内部发表了题为《The
threats to our products》的文章，为定义Windows全系产品面临的安全威胁正式提出了STRIDE助记符。随着2002年比尔·盖茨著名的《可信任计算备忘录》宣言发布，微软承诺改善软件产品的安全性，随即正式在SDL（安全开发生命周期）中采用了威胁建模。
威胁建模数十年来不断取得大家的认可，在业内也有STRIDE、Trike、OCTAVE等多种方法论实践。安全行业的从业人员普遍认识到，在研发团队的安全例行活动中，对于一些拥有重要数据资产、安全事件影响力大的系统除了要进行常规的渗透测试、黑白盒代码扫描之外，更应该系统地定期开展威胁建模活动并对业务赋能。
1.2 威胁建模的价值
识别体系化的结构缺陷：大多数安全问题是设计缺陷问题，而不是安全性错误。威胁建模能帮助识别这些设计缺陷，从而减少风险敞口，指导安全测试，并降低因安全漏洞而造成的品牌损害或财务损失等可能性。
节约组织安全成本：通过对威胁进行建模，并在设计阶段建立安全性需求，降低安全设计缺陷导致的修复成本。在需求管理和威胁分析阶段，与业务开发团队高效互动，释放安全团队的专业能力，专注于高性价比的安全建设。
落地DevSecOps文化：通过威胁建模跑通开发和安全工具的流程集成，把风险管理嵌入产品的完整生命周期，从而推动形成完整的DevSecOps工具链。
满足合规要求：威胁建模是国际安全行业通用的方法论，通过向管理层和监管机构提供产品的风险管理活动的完整记录，帮助团队遵守全球法律法规要求，包括PCI
DSS、GDPR、HIPAA、CSA STAR等。
1.3 遇到的挑战
普及威胁建模流程和技术可以有效提升企业的安全建设水平，作为互联网企业，要实施敏捷的软件开发流程，威胁建模活动也应尽量便捷，但实际工作起来并不简单，落地过程中也会遇到不少挑战。按优先级排序，挑战包括以下几个方面：
缺乏优秀的自动化建模工具；
安全团队没有时间和精力对每个应用都实施建模；
缺乏对威胁建模足够的了解，知识库涉及不同领域、专家经验难以共享；
建模活动、输出结果没有融入业务的敏捷研发流程；
简易的建模活动基于问卷或者表格记录分析，并没有实际的更新、积累和进一步分析。
2 准备威胁建模
2.1 能力要求
在进行复杂的威胁分析时，并不是SDL一个团队就可以独立完成的，还需要数据安全、IT安全、风控合规等安全团队协作，评审活动也涉及到内容、网络、隐私保护、法务、运维各个领域。各参与者最好提前建立对公司基础设施、安全分工的认知，相对清楚各个产品的作用、特点、接入办法、适用场景。建议实施威胁建模的参与人员都了解有关产品的设计、接入文档材料，看不懂不用担心，多浏览几遍，逐步熟悉即可。
对于实施威胁建模的负责人有四个层面的基本技术能力要求，包括：
懂常用的安全技术、安全机制、攻击方法、危害、加密算法；
懂业务、流程、内部技术服务、产品与产品之间、组件和组件之间的关系；
组织人员策略资源来推动项目实施；
将安全规划、安全流程、治理模型组合来符合纵深防御原则。
威胁评审，重点是评和审，对参与威胁评审的人员软实力要求，包括：
一定程度了解业务；
合格的文档编写能力；
有意识地优化企业体系结构中的研发安全流程；
有意愿传播安全能力，以支持增强安全团队话语能力。
2.2 评估流程
准备
实施威胁评估时，首先要取得业务团队负责人的认同：不管有没有事件驱动，安全团队的参与都将为业务系统提供产品竞争力。哪怕现阶段安全并不能完全赋能给业务，但长期来看，威胁建模应该在业务技术迭代的每个环节都去自助实施。随着技术的积累，业务团队独立完成威胁技术安全分析是有可能的。
团队
参与团队以“Two-Pizza Teams”团队为最佳，建立工作团队后，按需引入相关人，以后这个工作组聚焦为业务提供安全能力。保持沟通是构建产品安全的诀窍，实施威胁建模的效果深受团队如何组织和交流的影响。
周期
实施这项活动的整个周期除了解决风险的阶段稍长，从问卷调查到给出威胁评估报告，建议持续时间为1到2周；如时间太短，团队成员之间不能建立足够的信任，不能充分给出安全评估的结果；如时间太长，会忘记之前讨论的结果，耗费双方团队精力。威胁评估迭代的周期保持灵活，在人力充足的情况下以重大变更、功能模块迭代的数月、半年一轮为佳，人力不足的时候应尽量把评审过程由人力到工具化、自动化、服务化。
流程
安全架构评审的核心是威胁建模，详细参考可以参考 《安全架构评审实战》
一文。当然，传统的建模流程太重了，虽然尊重业务的设计过程很复杂，威胁分析也没有理由取巧走捷径，是改善安全必须付出的成本，但应尽量在复用现有流程的同时针对敏捷开发做出适当精简——通过问卷简化核心安全要素的分析、通过组织流程优化沟通方式、通过融入研发流程快速闭环。总结出比较适合互联网企业的评估工作流程如下：
1.首先是立项，增量尽量都覆盖。存量根据攻防优先级选择合适的重要系统开始评估，建议由业务方和安全一致的选择目标范围，一般建议从基础设施系统自下而上，从IaaS/PaaS层开始比较合理。因为基础设施的安全状况改进了，整个业务线都可以覆盖接入受益。评审不仅仅需要安全方面投入资源，也需要业务团队有人力参与问卷填写、项目介绍、多轮访谈、核对威胁、解决风险，需双方共同意识到：达成安全目标需要业务人员共同参与进来，安全和业务都很专业。双方建立的关系不应该是例行安全审计那样的“你问我答”，氛围可以尽量轻松。对齐发现的安全风险并不是哪个团队做得不好，而是认清事实，及时止损，发现风险、解决技术债务，交付和设计安全的代码也是开发的长期挑战，双方应着眼于改善产品未来的安全状况。
2.第二步问卷调查或文档填写的目的是收集必要的业务信息。文档/问卷应精心设计，不要采用过于专业的术语，目的是扫除业务方知识盲点，建立对产品初步的安全现状认知。不清楚的问卷选项可以不填，填就尽量保证准确。建立工作群后发出问卷调查要求，问卷是启动威胁建模项目的起点，业务方认真填写问卷是项目良好开展的前提。
3.同业务的访谈要反复进行多次，安全团队的风格要么过于强硬，要么容易脸皮薄，觉得和业务打交道要对方多次配合，不好意思打扰业务，这是错的，需要纠正。
访谈由安全评审人主持，时间尽量控制在40分钟以内，人数最小是4人左右。第一次访谈可以从问卷的内容开始，就每一个问卷选项进行交流，确保业务正确理解问卷中提到的问题，确保问卷的填写结果是业务想要表达的意思，确保业务不清楚的、有分歧的可以通过讨论给出一致结论。问卷访谈时不用过于讨论技术细节、系统不足和实际修复方案，主要是了解业务的基本安全情况。访谈的第二个议题是邀请业务方对软件设计文档、架构图进行讲解。最后的总结5分钟左右，会后遗留三项To
Do：①填写应用信息收集表，包括技术文档地址、代码仓库地址、域名、CI\CD发布项、技术栈、测试环境账户；②下一次沟通时间；③安全对接专人。
第二次访谈之前，安全人员应多阅读业务方的文档、代码，进行适度的安全测试。这次访谈希望有业务方架构师、代码开发负责人参与，对于安全前期整理的所不理解的调用关系问题、现有的安全控制措施问题、流程细节、组件、认证方式等其他技术细节进行讨论，分歧点和讨论结果通过文档记录方便查阅。
日常发现的疑问可以多次随时沟通，评审是一项“开卷考试”，很多黑白盒发现的安全风险无需花大精力执行安全测试，通过向业务方咨询就能得到确认。
访谈的对象通过产品、架构设计、开发人员类型的不同视角可以发现业务自身的讹误，业务如有不清楚的地方或历史遗留问题，不用在这里卡壳，先弄懂能弄清楚的来逐步拼接“拼图”。
最简单的威胁建模，就是关于威胁的“头脑风暴”而已。访谈的原则要把自己作为业务的CISO，从产品安全负责人的角度考虑：这个产品卖出去，可以提供什么安全能力？出现安全事故事前该怎么做？
开展架构评审中威胁建模的几个子过程，包括定义资产、识别威胁、评估风险、给出缓解措施等，将在下面的 “实施威胁建模”章节详细展开说。
威胁建模的阶段性成果交付物会是不同形式，如安全白皮书、安全设计指导、威胁评估报告。业务团队可以从安全给出的长期修复方案和安全规划中获益。最终报告最好有安全团队内部双人复核机制，不同安全专家视角里对威胁的理解是不一样的，双人复核的另一个好处是可以减少工作量，比如分工区分A-管理端、B-Agent、A-代码、B-设计实现或者A-评审、B-复查分工。给出威胁建模结果前一定要同业务团队再次沟通，确认哪些风险是安全视角被错误理解的，哪些是已经在业务视野中，哪些是业务团队认知不到位的。修复方案要区分接受、缓解、转移、处理风险四种情况。沟通时对应报告每个威胁项要求业务方给出明确的排期。短期可以走安全工单，长期纳入业务的规划排期中，识别出的共性安全问题作为安全专项制定孵化相应的安全工具和项目，补全安全建设的蓝图。
发现风险总是容易，解决风险才是这项工作的价值。减缓发现的威胁可能需要业务重新设计，需要排除万难达成目标，不然评审过的系统带来的虚假安全感，还不如没有安全感。一个有趣的现状是解决威胁时对于安全团队是业务在修复漏洞，对于业务是在满足安全团队提出安全需求。安全团队以往的视角总是急迫希望业务立即去修复，其实大可不必着急，不妨就按照安全需求去沟通。评审发现的问题不少是架构和设计方面的问题，比如认证、鉴权、数据安全方面，需要业务方进行大的设计变更，要建设对应的公共基础服务，要理解业务（反正风险已经存在很长时间了，敬畏业务的修复成本，尊重技术客观规律），只要能解决问题即可。好的修复方案一定是考虑性价比的，而且可行性大于必要性，每个团队的资源都不是无限的，按照处理的优先级进行排序工作。对识别出暂时不能解决的问题可以做出对应的监控、审计手段，如果要介入培训此时也是好的阶段，优秀的工程师总是想掌握到不同的知识，培训不是被动地聚在一起讲PPT，而是互动交流，建立安全文化的积极性。
在业务方确定处置风险完毕后，安全团队复查修复是否完成，修复是否引入新的问题，业务方是否对方案理解到位。这个过程要和业务团队保持互动，安全评审并不是单纯安全测试，而是指导安全能力的提升，结束时可以给业务积极的反馈，保持健康的安全文化。
威胁评估的活动最好定期重复进行。安全防护为什么要与时俱进？第一，随着制度法规的完善，对业务的安全性提出更高的要求；第二，企业安全基础设施能力不断提升，可为业务提供的公共安全能力不断增强；第三，业务系统可能随着时间的变化，安全现状有质的改变，随着信息系统所承载的业务完善或稳定，业务有取消合并的迭代。
3 实施威胁建模
绘制数据流图，识别定义威胁、处置威胁、验证风险得到正确处理是威胁建模的四个常用步骤。
3.1 数据流关系图都不准确，尽量有用而已
为什么我们需要建模？因为实施威胁建模时往往系统并未完整构建，模型会帮助思考系统的设计，以攻击者和防守方的方式思考对应的安全威胁。
经过初步问卷和访谈后，安全团队也收集到大量业务反馈的信息，产品和应用安全团队聚在一起讨论软件架构和潜在的安全问题。使用威胁建模工具、审查数据流图、威胁模型的目标都是为了达成更充分讨论的目的而服务。建议安全团队基于业务的流程图、调用关系同业务一起绘制DFD数据流图。一般常见的数据流形式有：①白板上作为会议随堂讨论的示意图，辅助提高沟通效率，一般用于说明系统层级架构；②业务现有文档中的时序图、UML图辅助理解复杂问题和技术细节。
画系统架构的目标是解决利益相关者的关注点，业务实现安全功能，安全实现安全设计。大家普遍反映实施威胁建模时都在画架构图时遇到最大的困难，纠结于用什么工具。在绘制DFD图的工具选择上：
微软的Microsoft Threat Modeling Tool工具的优点是，适合初学者接触熟悉了解外部实体、数据流、过程、存储、信任边界的基本概念，缺点是除了Windows应用程序和Azure示例之外没有合适的威胁模板。
OWASP Threat Dragon的优点是表达方式更丰富，但是不能支持动态拖拽和自动导出威胁列表。大家没有必要将整理数据流图视为困难，实战中威胁建模能力只能通过多练习、反复挑战的方法熟悉技能。
回过头看早期的一些对威胁模型的判断往往不准确的，没有关系，毕竟你曾经“实施”过威胁建模了。绘制数据流的过程可以理解业务、确保安全视角没有遗漏。威胁建模完全自动化基本是伪需求，没有足够多的业务产品需要持续进行建模评审、大量的原始信息来自于文档、架构师的经验、场景和知识极其复杂。建议尽快上手可以使用系统自带的流程图，使用Visio和Draw.io最方便。
数据流的细粒度也难以抉择，谨慎地选择信息的层级和粒度并不是一件容易的事情，初学者刚开始的时候总是觉得每个功能都得拆分，每个功能都要求加密，灵活程度取舍于所使用的架构模型、架构师的经验和系统的复杂度。根据笔者的经验，一种C4
Model结合微软威胁模型图例的方法容易取得合作方业务架构师的认同，以下给大家做个简单的示例。
系统上下文图（System Context Diagram）
在这一层级中细节并不重要，只显示系统概况。重点应该放在人员（角色）和软件系统上，而不是技术，协议和其他低层级细节上，从而使非技术人员也能够看得懂。这个图也是明确需求的重要图示。这表示一个应用和其他系统的下辖有调用关系。不需要完整表示数据的流向，只要大致描述清楚系统的周边关系，不遗漏关键步骤。
上述这个层级的示范是微软Azure的威胁建模的数据流图，优点是通过数字表示了流程顺序。
应用图（Application Diagram）
应用是可单独运行/可部署的单元（例如，单独的进程空间）执行代码或存储数据。应用图显示了软件体系结构的高层结构以及如何分配职责。它还显示了主要的技术选择以及容器之间的通信方式。
一个应用包含多个服务，如果一个系统有多个子系统，应该对每个子系统都进行分析。通过威胁建模应该尝试了解整体情况，包含应用本身、数据库、交互、部署场景、云服务、接入的基础服务。下图是模拟一个支付应用的示例。
服务图（Service Component diagram）
服务图显示了服务如何由多个“组件”组成，每个组件是什么，它们的职责以及技术/实现接口（API）或者细节。这个细粒度的分解是建模最大的工作量，为分解的各个通用组件创建的威胁模型结果可以复用在其他应用上。比如Kubernetes被分为Kube-Proxy、ETCD、Kubelet、Kube-APIServer、Scheduler、Container、Pods等。
代码层级
这一层是可选的，可以使用UML类图、实体关系图、函数调用关系或类似的图。对于分析特定代码层级的漏洞很方便。推荐使用白盒扫描工具、IntelliJ
IDEA的依赖矩阵、Diagrams、Flow插件进行分析。
数据流图这项技术本身存在的不足是：关注组件的交付是还是相对偏数据流动视角，不少人的交互场景如钓鱼、敏感功能误操作不能表示出来；不能完全遍历出程序的全部功能（除非图足够复杂）；基于程序设计图之上绘制却又丢失了设计细节，无法自动化；数据流会额外显示出基础设施引起的风险，并不仅仅是业务自身的安全。
3.2 识别威胁是互动过程
威胁建模是一种协作行为，一类结构化的思维方式，一项实践的科学。以软件程序为中心的威胁建模、枚举威胁、解决威胁、验证来解决四个问题：具体业务是什么？哪些地方可能出现风险？如何规避解决？是否覆盖完整。
所以识别威胁的第一步是灵活定义攻击者的目标，组织要保护的资产和信任级别，如：S3存储、源代码、主机、数据库、凭据、行级数据，知识产权等。公有云、私有云不同的责任共担模型就清晰给出了不同的业务需要关注哪些资产的示例，云上资产的建模更关注安全的信任边界。
第二步给出明确的攻击路径，定义攻击者：比如恶意内部员工、外部攻击者，竞争对手、好奇者等，攻击路径的抉择直接影响攻击面和信任边界的划定。
第三步即威胁评估的过程不能缺少架构分类思维。一般使用 ASTRIDE（隐私、欺骗、篡改、信息泄露、否认性、拒绝服务和特权提升）和攻击树模型作为常用的威胁建模技术指导原则。
| ASTRIDE ?(Advanced STRIDE )
微软已经不再维护STRIDE，采用ASTRIDE更符合面向消费者的网络安全行业的发展。
将系统分解为相关的组件，分析每个组件对应的威胁。有个技巧是从外部实体逐次开始，关注有交互的进程，没有交互的进程一般没有威胁。
上图中，数据存储仅是保存日志信息时才有抵赖的威胁。
分析威胁模型和业务互动时，按照上面的两张表考虑每个元素对应的威胁，实施时要对照进行思考当做Checklist来分类。ASTRIDE是帮助认识归类威胁的工具，而不是分类定义，某些威胁比如没有启用HTTPS，从中间人攻击的角度分析实际的风险既是数据泄露，也属于篡改、隐私分类，有的威胁如IoT设备的爆炸、丢失不属于以上任一分类，没有必要强行去分类，反正已经发现记录威胁了。另外，信任边界很重要，安全本质是信任问题，攻击面的定义直接影响威胁的划分。
几个安全概念的区别
威胁是应用潜在存在的安全弱点。
漏洞是对威胁的利用，产品实现了预期之前的功能，影响了安全性。
Bug是未实现的功能。
风险是发生的，对资产有危害的可能性。
风险=（威胁+漏洞）*可能性。
举个例子：存在新冠肺炎病毒是“威胁”，没带口罩是“漏洞”，存在感染病毒可能是“风险”，人体不能解决病毒是“Bug”，主动免疫是安全需求。
对于威胁的判断来源，可以参考：
业界同类产品的安全白皮书，如各家公有云的材料相对比较全，要思考这些同类产品都有哪些安全功能，有没有安全需求，能不能实现。
通过内部工单系统搜索该部门名下的历史漏洞：经常一个产品历史出现过越权漏洞，是因为整个产品都没有鉴权；一个接口不符合编码规范，同一份代码的另一个接口出现安全问题的风险高。
开源产品的安全设计方案，历史漏洞。
专利、论文、行业知识库，对于新的技术的如人脸识别、机器学习、大数据业务这方面的材料很宝贵。
以上举个简单的例子，场景是租户通过第三方开放平台登录后通过微服务处理业务。
对于API网关，存在的威胁包括：
认证和授权
未强制HTTPS
缺失二次认证措施
日志和监控
缺失日志记录和审计模块
日志本地留存
对于IAM服务服务器，存在的威胁包括：
信息泄露：用户身份信息泄露
认证
暴力破解对外发送的管理平台Token
授权策略绕过
可用性
单机实例，误操作可导致宕机风险
对于MySQL服务，部分存在的威胁包括：
认证：攻击者获取凭据后可以直接访问、修改、删除业务数据
权限提升：攻击者可以从普通用户提升至Root，获取数据库完全控制权限
信息泄露：SQL注入导致所保存的业务数据泄露
评估风险结果没有列出来有些是自动认可忽略的，有些是放在基线等安全控制措施，大多数的威胁发现都是基于参与者的经验，可以从安全最佳实践、加固指导、历史案例形成知识库积累下来。具体实施的过程目前没有完全的自动化工具，但是检测项一般有共识：比如从域名系统查看是否启用强制HTTPS、S3对象存储查看是否启用服务器端加密、硬编码问题、是否加入FIDO等。
虽然威胁建模的一个要点是避免关注漏洞而不是威胁，但基本没有一个系统是从零搭建的。新的项目也会大量引入框架、组件、第三方服务，适当的安全测试是必要，原则是聚焦发现设计方面高层次的风险，但如果参与人员具备一些实际攻防能力，可以将其他安全工具发现的问题纳入一起解决，百利而无一害，本身建模的一个目标就是指导安全测试的方向。测试时要注意常见的攻防案例是影响机密性，也要考虑攻击者破坏应用的可用性和完整性。
| 攻击树模型
安全专家大都熟悉实战中通过哪些攻击手段可以损害资产。很多网络上的渗透测试报告就是以攻击链路形成的思维导图为例，可以据此细化出一个产品的攻击树。攻击树模型有两种方法：自下而上和Use
Case型。前者是全部覆盖到实现目标的入口，后者基于前者的细节，在确定攻击的前提下展示出实际的攻击，涉及大量用例的、业务逻辑复杂的、有交互过程的、系统已经设计完成的，通过攻击树很容易发现安全威胁。攻击树模型一般遵循以下的定义图例：
通过下面举个例子，攻击者尝试持久化在Kubernetes集群内部执行命令，可以通过部署恶意镜像、容器内执行命令、提权控制宿主机多种方法。在部署恶意镜像这一步，自下而上浏览首先要具备访问Kubernetes
API权限的认证信息或Kubelet工具的凭据，然后必须有镜像仓库操作写的权限，然后部署恶意镜像。
识别到威胁后对威胁进行几个处理步骤：
标记详情，附加参考材料、变更记录；
威胁影响级别：从机密性、完整性、可用性，利用难度四个角度进行评估。衡量风险没有必要强制按照DREAD、CVSS评分模型，很大程度依赖于参与的安全专家对攻击者的视角、安全建设的成熟度、业务的可接受能力进行定级，一般给出高中低即可。
3.3 处理威胁是重中之重
经过上述的活动，我们获取了一个大的威胁列表，下一步就是处置评估出来的每个风险，这方面的材料可以参考ISO27001和ISO31000的系列指导。分为四个应对措施。
缓解
采取措施加大攻击者的利用时间。就像Google Project Zero的原则“Make 0-Day
Hard”。比如发现密码猜解的威胁，采用二次认证、风控验证码的技术，缓解和解决风险的界限往往并不清晰。仔细想想大部分的日常安全工作都是缓解威胁，比如部署WAF、制定安全规章制度、监控和响应。
解决
完全解决该威胁。解决是最乐观的情况，常见的安全方案是基于现有的代码实现，比如防SQL注入组件，使用加密套件解决硬编码问题。如果威胁建模是发生在编码之前，可以使用现有的安全方案如Security
SDK、密钥管理服务、身份认证方案，当然也可以引用新的安全技术去建设。
转移
转移是将威胁承担交由其他系统去处理，比如用户协议和隐私条款、免责声明，变更管理的二次认证、外包、购买网络安全保险。但是安全也不能对业务给个方案说你得买一份保险，这需要找到安全和业务的平衡感。
接受
接受风险也是面对安全成本的一个合理处理方式，不同层级的业务负责人对待安全的视角是有不同考虑的。比如在物理安全领域，我们往往做得适度投入，背后的原因是接受了战争、核武器等不可抗拒因素。
依据上述的威胁定义补充是等级、优先级、修复成本、负责人、排期、安全测试结果、解决方案记录结果，报告文字要规范，避免使用安全特定术语、缩略语如PoC、RCE、SSRF、HIDS字样。给出前瞻性的安全方案是区分安全测试和威胁建模的主要区别。对于共性问题建立孵化安全解决方案，有安全专项的也进行标记，后续可以比对安全项目的效果。
解决威胁的抽象原则要区分出安全建设的原则纵深防御、最小权限原则、默认（强制）安全并不一定适用于业务系统，业务更熟悉安全架构设计的5A原则：
身份认证（Authentication）：用户主体是谁？
授权（Authorization）：授予某些用户主体允许或拒绝访问客体的权限。
访问控制（Acccess Control）：控制措施以及是否放行的执行者。
可审计（Auditable）：形成可供追溯的操作日志。
资产保护（Asset Protection）：资产的保密性、完整性、可用性保障。
5A的划分容易让业务理解到开发架构、逻辑架构、数据架构、技术架构、业务架构中，从而避免因为安全缓解措施的影响导致原本的业务需求不能实现，或者性能、编码、成本变更得太多。
完成威胁建模的标志是双方团队对图表没有异议，可以依据数据流图，复述清楚数据流向、攻击面如何、已经做了什么、存在哪些风险、应该做到什么。让业务没有安全知识的提升的建模是失败的，业务方应当是下一个产品迭代中安全提升的主动贡献者。
以下是威胁列表的结果示例模板：
3.4 验证威胁达到闭环
修复问题就是安全团队复查威胁得到合理的处置，高标准就是合理。跟踪威胁的解决不要拘泥于使用的安全内部的工单系统，在业务的研发管理系统记录也是一个明智的选择。同业务方制定单双周的沟通会，确保每个风险在跟进按时解决。威胁建模并不是一次性活动，每次双周沟通都简短沟通，花5-10分钟再一次实施建模：沟通下遇到什么困难，有什么安全需求，积累建模的习惯，通过反复执行这个活动可以从设计层面识别大量的安全风险。
我们总是提安全要Shift Left（左移），建模给了产品团队良好的“右移”机会。团队之间的知识共享帮助大家理解安全的本质，知道安全这件事该如何做，从而逐步改善公司的安全状况。Security
by Design要求安全前置介入到需求和设计阶段，真正让介入需求阶段，安全又总是无从下手，其实需求阶段的安全活动包括用例验证、资产识别、安全基线，将权限、日志、操作安全、加密需求、编码规范、基础服务纳入安全相关基线，设计阶段主要有方案评审、安全特性设计，最重要的更是威胁建模。团队互动的过程要以文档的形式完整记录，这种材料是给其他团队下一次威胁建模的有效输入。
4 如何评价这件事做得好坏
威胁建模不能立竿见影，建模没有什么特别的，对于业务方来说应该是同编码、测试、交付一样很普通的工作，安全也仅仅是日常工作的一部分。事情的主要目标是建立产品的安全属性，可以通过最终的安全缺陷改进情况、评审覆盖度、修复解决率作为过程指标，安全成熟度、安全事故数作为结果指标。实施投入威胁建模本身已经是一件技能很复杂的事情了，对参与人员引导做正确的事，不需要设置发现威胁数等硬性指标。
威胁建模在于对评估可能的风险、分析潜在攻击者的手法、攻击路径，提升产品的抗攻击韧性方面有独特的优势。这项方法论根本没有什么最佳实践，没有单一的“最好”或执行威胁建模的“正确”方法，而是为了满足解决这些威胁而实施的一系列复杂和多维度的权衡，唯有不断修正迭代才能完善。但如果没有威胁建模过程参与，组织不会清楚现有系统的安全现状。不管怎样，一旦你取得阶段性的成果，组织内部就认识到这样的协作可以对改善总体安全状况产生较大的作用，是高性价的投入，就可以克服关于威胁建模耗费人力、周期长、难点大这些阻力的声音，从而真正从事预防性的安全建设。
5 经验教训
美团内部实施威胁建模时，首先就设立了如下的目标：
覆盖基础设施相对重要的公共组件服务和重要管理平台；
形成一套可复用的安全评审流程，知识库和工具；
及时发现公司管理平台的运营安全类风险，排期止损加固。
通过制定的威胁建模计划同业务部门深入开展合作，团队完成了数十个项目的评估，发现了数百个高危设计缺陷，从而试图解决两类核心问题：①人为操作导致的安全风险；②安全融入基础架构。识别提炼出孵化出特权账户管理平台、服务鉴权、执行沙箱、全程票据、安全知识库等安全子项目。当然建模的效果有好有坏，我们仍需学习、调整、迭代。我们总结了如下的经验教训：
关注真实的威胁，从技术威胁入手延伸到业务威胁；
安全没有“银弹”，使用其他应用安全措施补充威胁建模；
见木不见林，致力于高效的建模，而不纠结于细节；
关注安全的沟通协作，改善研发解决安全问题的思维方式，胜于投入精力在安全测试。
业界关于威胁建模的实施方法论在物联网、机器学习、Serverless场景依旧很有生命力，说明在软件工程领域这会是识别威胁真正有效的办法。相信Threat
Model Driven Approach for Security Testing（威胁模型驱动的应用安全测试）将成为应用安全的又一主流安全测试方法。
| 
