关于安全:实践之后我们来谈谈如何做好威胁建模

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 遇到的挑战

遍及威逼建模流程和技术能够无效晋升企业的平安建设程度，作为互联网企业，要施行麻利的软件开发流程，威逼建模流动也应尽量便捷，但理论工作起来并不简略，落地过程中也会遇到不少挑战。按优先级排序，挑战包含以下几个方面：

1. 不足优良的自动化建模工具；
2. 平安团队没有工夫和精力对每个利用都施行建模；
3. 不足对威逼建模足够的理解，知识库波及不同畛域、专家教训难以共享；
4. 建模流动、输入后果没有融入业务的麻利研发流程；
5. 繁难的建模流动基于问卷或者表格记录剖析，并没有理论的更新、积攒和进一步剖析。

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，从产品安全负责人的角度思考：这个产品卖出去，能够提供什么平安能力？呈现安全事故事先该怎么做？
4. 发展架构评审中威逼建模的几个子过程，包含定义资产、辨认威逼、评估危险、给出缓解措施等，将在上面的“施行威逼建模”章节具体开展说。
5. 威逼建模的阶段性成绩交付物会是不同模式，如平安白皮书、平安设计领导、威逼评估报告。业务团队能够从平安给出的长期修复计划和平安布局中获益。最终报告最好有平安团队外部双人复核机制，不同平安专家视角里对威逼的了解是不一样的，双人复核的另一个益处是能够缩小工作量，比方分工辨别 A - 治理端、B-Agent、A- 代码、B- 设计实现或者 A - 评审、B- 复查分工。给出威逼建模后果前肯定要同业务团队再次沟通，确认哪些危险是平安视角被谬误了解的，哪些是曾经在业务视线中，哪些是业务团队认知不到位的。修复计划要辨别承受、缓解、转移、解决危险四种状况。沟通时对应报告每个威逼项要求业务方给出明确的排期。短期能够走平安工单，长期纳入业务的布局排期中，辨认出的共性平安问题作为平安专项制订孵化相应的平安工具和我的项目，补全平安建设的蓝图。
6. 发现危险总是容易，解决危险才是这项工作的价值。减缓发现的威逼可能须要业务从新设计，须要排除万难达成指标，不然评审过的零碎带来的虚伪安全感，还不如没有安全感。一个乏味的现状是解决威逼时对于平安团队是业务在修复破绽，对于业务是在满足平安团队提出平安需要。平安团队以往的视角总是急切心愿业务立刻去修复，其实大可不必焦急，无妨就依照平安需要去沟通。评审发现的问题不少是架构和设计方面的问题，比方认证、鉴权、数据安全方面，须要业务方进行大的设计变更，要建设对应的公共根底服务，要了解业务（反正危险曾经存在很长时间了，敬畏业务的修复老本，尊重技术客观规律），只有能解决问题即可。好的修复计划肯定是思考性价比的，而且可行性大于必要性，每个团队的资源都不是有限的，依照解决的优先级进行排序工作。对辨认出临时不能解决的问题能够做出对应的监控、审计伎俩，如果要染指培训此时也是好的阶段，优良的工程师总是想把握到不同的常识，培训不是被动地聚在一起讲 PPT，而是互动交换，建设平安文化的积极性。
7. 在业务方确定处理危险结束后，平安团队复查修复是否实现，修复是否引入新的问题，业务方是否对计划了解到位。这个过程要和业务团队放弃互动，平安评审并不是单纯平安测试，而是领导平安能力的晋升，完结时能够给业务踊跃的反馈，放弃衰弱的平安文化。
8. 威逼评估的流动最好定期反复进行。平安防护为什么要与时俱进？第一，随着制度法规的欠缺，对业务的安全性提出更高的要求；第二，企业平安基础设施能力一直晋升，可为业务提供的公共安全能力一直加强；第三，业务零碎可能随着工夫的变动，平安现状有质的扭转，随着信息系统所承载的业务欠缺或稳固，业务有勾销合并的迭代。

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 工具的凭据，而后必须有镜像仓库操作写的权限，而后部署歹意镜像。

辨认到威逼后对威逼进行几个解决步骤：

1. 标记详情，附加参考资料、变更记录；
2. 威逼影响级别：从机密性、完整性、可用性，利用难度四个角度进行评估。掂量危险没有必要强制依照 DREAD、CVSS 评分模型，很大水平依赖于参加的平安专家对攻击者的视角、平安建设的成熟度、业务的可承受能力进行定级，个别给出高中低即可。

3.3 解决威逼是重中之重

通过上述的流动，咱们获取了一个大的威逼列表，下一步就是处理评估进去的每个危险，这方面的资料能够参考 ISO27001 和 ISO31000 的系列领导。分为四个应答措施。

缓解

采取措施加大攻击者的利用工夫。就像 Google Project Zero 的准则“Make 0-Day Hard”。比方发现明码猜解的威逼，采纳二次认证、风控验证码的技术，缓解和解决危险的界线往往并不清晰。认真想想大部分的日常平安工作都是缓解威逼，比方部署 WAF、制订平安规章制度、监控和响应。

解决

齐全解决该威逼。解决是最乐观的状况，常见的平安计划是基于现有的代码实现，比方防 SQL 注入组件，应用加密套件解决硬编码问题。如果威逼建模是产生在编码之前，能够应用现有的平安计划如 Security SDK、密钥治理服务、身份认证计划，当然也能够援用新的平安技术去建设。

转移

转移是将威逼承当交由其余零碎去解决，比方用户协定和隐衷条款、免责申明，变更治理的二次认证、外包、购买网络安全保险。然而平安也不能对业务给个计划说你得买一份保险，这须要找到平安和业务的平衡感。

承受

承受危险也是面对平安老本的一个正当解决形式，不同层级的业务负责人看待平安的视角是有不同思考的。比方在物理平安畛域，咱们往往做得适度投入，背地的起因是承受了和平、核武器等不可抗拒因素。

根据上述的威逼定义补充是等级、优先级、修复老本、负责人、排期、平安测试后果、解决方案记录后果，报告文字要标准，防止应用平安特定术语、缩略语如 PoC、RCE、SSRF、HIDS 字样。给出前瞻性的平安计划是辨别平安测试和威逼建模的次要区别。对于共性问题建设孵化平安解决方案，有平安专项的也进行标记，后续能够比对平安我的项目的成果。

解决威逼的形象准则要辨别出平安建设的准则纵深进攻、最小权限准则、默认（强制）平安并不一定实用于业务零碎，业务更相熟平安架构设计的 5A 准则：

1. 身份认证（Authentication）：用户主体是谁？
2. 受权（Authorization）：授予某些用户主体容许或回绝拜访客体的权限。
3. 访问控制（Acccess Control）：控制措施以及是否放行的执行者。
4. 可审计（Auditable）：造成可供追溯的操作日志。
5. 资产爱护（Asset Protection）：资产的保密性、完整性、可用性保障。

5A 的划分容易让业务了解到开发架构、逻辑架构、数据架构、技术架构、业务架构中，从而防止因为平安缓解措施的影响导致本来的业务需要不能实现，或者性能、编码、老本变更得太多。

实现威逼建模的标记是单方团队对图表没有异议，能够根据数据流图，复述分明数据流向、攻击面如何、曾经做了什么、存在哪些危险、应该做到什么。让业务没有平安常识的晋升的建模是失败的，业务方该当是下一个产品迭代中平安晋升的被动贡献者。

以下是威逼列表的后果示例模板：

3.4 验证威逼达到闭环

修复问题就是平安团队复查威逼失去正当的处理，高标准就是正当。跟踪威逼的解决不要拘泥于应用的平安外部的工单零碎，在业务的研发管理系统记录也是一个理智的抉择。同业务方制订单双周的沟通会，确保每个危险在跟进按时解决。威逼建模并不是一次性流动，每次双周沟通都简短沟通，花 5 -10 分钟再一次施行建模：沟通下遇到什么艰难，有什么平安需要，积攒建模的习惯，通过重复执行这个流动能够从设计层面辨认大量的平安危险。

咱们总是提平安要 Shift Left（左移），建模给了产品团队良好的“右移”机会。团队之间的常识共享帮忙大家了解平安的实质，晓得平安这件事该如何做，从而逐渐改善公司的平安情况。Security by Design 要求平安前置染指到需要和设计阶段，真正让染指需要阶段，平安又总是无从下手，其实需要阶段的平安流动包含用例验证、资产辨认、平安基线，将权限、日志、操作平安、加密需要、编码标准、根底服务纳入平安相干基线，设计阶段次要有计划评审、平安个性设计，最重要的更是威逼建模。团队互动的过程要以文档的模式残缺记录，这种资料是给其余团队下一次威逼建模的无效输出。

4 如何评估这件事做得好坏

威逼建模不能空谷传声，建模没有什么特地的，对于业务方来说应该是同编码、测试、交付一样很一般的工作，平安也仅仅是日常工作的一部分。事件的次要指标是建设产品的平安属性，能够通过最终的平安缺点改良状况、评审覆盖度、修复解决率作为过程指标，平安成熟度、安全事故数作为后果指标。施行投入威逼建模自身曾经是一件技能很简单的事件了，对参加人员疏导做正确的事，不须要设置发现威逼数等硬性指标。

威逼建模在于对评估可能的危险、剖析潜在攻击者的手法、攻打门路，晋升产品的抗攻打韧性方面有独特的劣势。这项方法论基本没有什么最佳实际，没有繁多的“最好”或执行威逼建模的“正确”办法，而是为了满足解决这些威逼而施行的一系列简单和多维度的衡量，唯有一直修改迭代能力欠缺。但如果没有威逼建模过程参加，组织不会分明现有零碎的平安现状。不管怎样，一旦你获得阶段性的成绩，组织外部就意识到这样的合作能够对改善总体平安情况产生较大的作用，是高性价的投入，就能够克服对于威逼建模消耗人力、周期长、难点大这些阻力的声音，从而真正从事预防性的平安建设。

5 经验教训

美团外部施行威逼建模时，首先就设立了如下的指标：

• 笼罩基础设施绝对重要的公共组件服务和重要治理平台；
• 造成一套可复用的平安评审流程，知识库和工具；
• 及时发现公司治理平台的经营安全类危险，排期止损加固。

通过制订的威逼建模打算同业务部门深入开展单干，团队实现了数十个我的项目的评估，发现了数百个高危设计缺点，从而试图解决两类外围问题：①人为操作导致的平安危险；②平安融入基础架构。辨认提炼出孵化出特权账户治理平台、服务鉴权、执行沙箱、全程票据、平安知识库等平安子项目。当然建模的成果有好有坏，咱们仍需学习、调整、迭代。咱们总结了如下的经验教训：

• 关注实在的威逼，从技术威逼动手延长到业务威逼；
• 平安没有“银弹”，应用其余利用安全措施补充威逼建模；
• 见木不见林，致力于高效的建模，而不纠结于细节；
• 关注平安的沟通合作，改善研发解决平安问题的思维形式，胜于投入精力在平安测试。

业界对于威逼建模的施行方法论在物联网、机器学习、Serverless 场景仍旧很有生命力，阐明在软件工程畛域这会是辨认威逼真正无效的方法。置信 Threat Modeling Application Security Testing（威逼模型驱动的利用平安测试）将成为利用平安的又一支流平安测试方法。

参考资料

• https://michenriksen.com/blog/drawio-for-threat-modeling/
• https://github.com/cncf/financial-user-group/tree/master/projects/k8s-threat-model
• http://ceur-ws.org/Vol-413/paper12.pdf
• https://community.iriusrisk.com/
• https://aws.amazon.com/marketplace/pp/ThreatModeler-ThreatModeler/B07S65ZLPQ
• https://threatdragon.org/login
• http://mozilla.github.io/seasponge/#/
• https://insights.sei.cmu.edu/sei_blog/2018/12/threat-modeling-12-available-methods.html
• http://www.owasp.org.cn/owasp-project/OWASP_Top_10_Proactive_Controls_V3v1.1.pdf
• http://www.woshipm.com/it/1663882.html
• https://developer.ibm.com/zh/components/redhat-openshift-ibm-cloud/articles/threat-modeling-microservices-openshift-4/
• https://docs.microsoft.com/en-us/archive/msdn-magazine/2006/november/uncover-security-design-flaws-using-the-stride-approach
• https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html
• https://csrc.nist.gov/publications/detail/sp/800-154/draft
• https://github.com/google/end-to-end/wiki/Threat-model

浏览美团技术团队更多技术文章合集

前端 | 算法 | 后端 | 数据 | 平安 | 运维 | iOS | Android | 测试

| 在公众号菜单栏对话框回复【2020 年货】、【2019 年货】、【2018 年货】、【2017 年货】等关键词，可查看美团技术团队历年技术文章合集。

| 本文系美团技术团队出品，著作权归属美团。欢送出于分享和交换等非商业目标转载或应用本文内容，敬请注明“内容转载自美团技术团队”。本文未经许可，不得进行商业性转载或者应用。任何商用行为，请发送邮件至 tech@meituan.com 申请受权。