将风险建模与 DevOps 集成

本文由 Simone Curzi、Anthony Nevico、Jonathan Davis、Rafael Pazos Rodriguez和 Ben Hanson 创作

介绍

风险建模是一种重要的安全方法，可帮助识别应用程序或系统最重要的风险缓解措施并为其设置优先级。 本文包含对如何更有效地采用风险建模，将其与现代 DevOps 方法和工具集成，并专注于为软件开发生命周期中的所有不同参与者提供的价值进行的一些思考。

本文适合哪些读者？

本文是微软安全和风险建模专家小组的工作成果，并结合了微软外部一些最著名专家的意见和想法。 本文试图解决一个简单但紧迫的问题：我们应该做些什么来确保我们使用的风险建模流程已更新到敏捷方法和 DevOps 强加的现代要求，从而以最低的成本提供所需的价值？

如果你是产品负责人、安全团队成员，或者只是一名正在考虑在开发生命周期中采用风险建模的开发人员，那么你就非常适合阅读本文。

当然，如果你已经采用了风险建模，你也仍然可以在本文中找到改进流程的实用想法。

不过，本文的宗旨在于介绍改进当前流程或在 DevOps 流程中成功采用风险建模的想法。 本文不会介绍具体的工具或产品，即使我们希望看到这些想法在未来通过一些工具或产品实施。 因此，你在本文中不会找到新工具的公告或即将推出的功能的预览。

风险建模为何重要？

风险建模是安全设计软件解决方案的主要方法之一。 通过风险建模，你可以分析系统，识别攻击途径，并制定措施缓解这些攻击带来的风险。 适当的风险建模是任何风险管理流程的一个重要组成部分。 风险建模还可以尽早发现和修正设计问题，从而帮助降低成本。 NIST 早期的一项研究估计，修正生产代码中的设计问题的成本大约是设计阶段修复成本高出 40 倍。 风险建模还可以避免由于最终设计问题的安全事件而产生的成本。 不妨考虑一下，IBM Security 和 Ponemon Institute 的《2022 年数据泄露成本报告》估计，数据泄露的平均成本为 435 万美元。 对于所谓的大型泄露，即被盗用记录超过 5000 万条的事件，平均成本甚至高达 3.87 亿美元！

风险建模是确保解决方案安全的首要活动，因为它直接作用于解决方案的设计。 这一特性使其成为可以应用于 SDLC 的最有效的安全实践。

微软在风险建模方面有着悠久的历史。 1999 年，两名（时任）微软员工 Loren Kohnfelder 和 Praerit Garg 起草了一份文档 《对我们产品的威胁》。 该文章介绍了一种名为 STRIDE 的方法，这正是微软风险建模流程的同义词。

风险建模是一个不断进化的流程

风险建模不是一个静态的流程；而是会需求和技术的变化而发展。

• 最近针对 SolarWinds 等的供应链攻击表明，风险建模需要涵盖比解决方案本身更多的应用场景，也包含开发和部署。

• 最近针对 Log4j 等的开放源代码漏洞表明，有必要在当前采用软件构成分析工具方法的基础上进一步补充，通过防御性地设计解决方案来扫描易受攻击的组件，从而限制其风险。

• 机器学习等新技术的应用引入了新的攻击途径，必须加以理解和控制。 例如，需要考虑如 https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/carlini 中所述，播放人耳听不见的恶意声音，导致 AI 服务执行命令的可能性。

在微软，不同的产品组会根据其特定的安全要求实践不同的风险建模变体。 每种变体分别旨在保证其所应用场景具有足够的安全保障水平，但这里“足够”的含义取决于具体上下文。

例如，保护 Windows 安全与保护 Azure 认知服务安全就不尽相同，这两种系统的大小和特性都截然不同。 风险建模的一个关键特性是平衡其成本与应用程序的风险承受能力。 虽然这可能会导致我们判定在某些应用场景下完全避免风险建模，但如果使用得当，风险建模是非常有效的，因此我们只能建议在任何 IT 提议中（包括软件开发和基础结构部署项目）都采用风险建模。

专注 ROI 的重要性

在过去的几年里，人们对风险建模作为一个关键的软件开发流程的兴趣稳步增加。 这种兴趣源自于针对基础结构和解决方案的攻击正呈指数增长。 NIST 推荐的供应商或开发人员代码验证最低标准和风险建模宣言等提议使当前的方法已经显示出一些局限性，这进一步增加了这方面的需求。 例如，风险建模的成果在很大程度上取决于所采用的流程和执行风险模型的人员。 因此，人们担心能否从体验中不断获取更高的质量。

但是，质量对风险建模意味着什么？ 对我们来说，高质量的风险模型必须具有以下特征：

• 必须确定可操作的缓解措施，即可以采取哪些活动以减少攻击造成的潜在损失。 可操作性意味着这些缓解措施必须得到很好的定义，这意味着你可以获得足够的信息来实施它们，然后测试实施情况。 这也意味着必须能够对外提供，以便开发团队轻松使用。 DevOps 和敏捷意味着可以通过一条简单的路径将缓解措施导入到积压工作中。

• 对于每个缓解措施，必须确定其状态。 一些缓解措施是新的，而另一些已经存在。 风险模型必须识别出已经存在的缓解措施，并专注于当前的风险，以确定如何改善这种情况。

• 风险模型必须将每个缓解措施与相应威胁相联系，从而清楚地确定需要每个缓解措施的原因。

• 此外，缓解措施对每种威胁都具有一个相对优势。 例如，TLS 加密可以有力地缓解传输中的数据被泄露的风险，同时，它也可以几乎完全缓解服务器被欺骗的风险。

• 威胁必须可信、定义明确，并对应特定解决方案。

• 威胁必须具有关联的严重性，应考虑其概率和影响。 严重性必须合理且理想情况下不带偏见。

• 应该能够用于全面了解风险以及如何应对这些风险。 这种观点将有助于推动与安全团队和业务决策者进行有意义的对话，并使我们能够隐藏不必要的复杂性。

这个列表已经显示了一个重要的概念：即风险建模可以为软件生命周期中涉及的许多角色提供价值，但每个角色都有不同的需求和要求。 例如，开发人员需要接收关于他们需要实施什么以及如何验证其实施的内容是否符合预期的明确信息。 另一方面，安全团队通常关注组织拥有的基础结构和应用程序生态系统的整体安全：因此，他们需要接收信息，以便决定范围内的系统是否足够安全并满足其合规性要求。 最后，产品负责人和业务决策者需要了解使风险为组织所接受的必要条件。

这些不同的需求要求对风险模型提供不同的视图，每个视图分别专注于特定的使用方案。

风险建模面临的一个典型问题是，它越成功，就越难以通过少数可用的专家满足需求，同时仍能提供这种体验所期望的高质量。 结果是，在某些情况下，质量可能会受到负面影响。 在风险建模再也无法提供显著高于投资的价值之前，一切都是好的。 许多组织都受到了此问题的影响。 已经有多份报告称，业务决策者开始质疑风险建模，因为与成本相比，它无法带来显著的价值。

这里的价值指的是业务价值，即提供所需信息以理解范围内系统所代表的风险，并推动有意义的决策流程以选择要实施的适当缓解措施的能力。 此外，价值还与向开发人员和测试人员提供正确的信息有关。 最后，价值还与所有相关方沟通剩余风险有关。 例如，我们可以通过度量风险建模流程的影响来度量其价值。 假设我们通过为每个威胁的严重性分配一个数字来度量解决方案的总体风险。 在这种情况下，我们预计总体风险会因为风险模型的每个效应随着时间的推移而递减。 如果总体风险保持不变或增加，我们可能会遇到问题。 递减幅度越大，风险模型的影响就越大。 当然，风险模型无法控制已实施的缓解措施。 产品负责人的职责是决定必须执行的缓解措施。 但是，将风险模型的有效性与缓解措施的实际实施联系起来的好处是，能够增加解决方案对实际安全性的影响，降低了风险模型仍然是一种理论练习的风险。

相反，成本与执行风险模型本身所需的活动有关，即所有相关方制作风险模型并进行讨论所需的时间。

这就引出了一个问题：我们能否定义一个专注于业务价值最大化和成本最小化的风险建模流程？

DevOps 的重要性

确保风险建模是一种与 DevOps 流程集成的有价值的实践，我们已经强调了其重要性。 这意味着流程必须对所有小组成员都可用，这通常通过简化和自动化来实现。 最重要的是，专注于 DevOps 的风险建模意味着我们需要确保体验与现有 DevOps 流程深度集成。

威胁建模不应成为另一个负担，但它应该是一个资产，以促进安全要求产生和收集，安全解决方案的设计，将活动包含在所选的任务和 Bug 跟踪工具中，以及评估给定解决方案的当前和未来状态的剩余风险。

与 DevOps 对齐

我们可以使用各种技术将风险建模与当前的 DevOps 实践对齐。

威胁和缓解措施

首先，我们必须使风险建模流程专注于需要完成的操作。 威胁，即攻击模式及其可能发生的方式，对于解释团队为何需要实施安全控制是必要的。 它们也是规定何时应实施缓解措施的因素之一。 但是，真正的目标应该是规定需要完成的操作：即缓解措施。 因此，该方法必须能够快速识别所需的缓解措施，并且必须告知判定流程，以便更容易地确定何时该执行什么操作。 该判定流程的主要可交付成果是将所选择的缓解措施纳入积压工作，使其成为标准过程的一部分。 理想情况下，应同步威胁建模工具和任务和 bug 跟踪工具，以反映威胁模型中缓解状态的更新。 这将允许动态自动修改剩余风险，这对于支撑合理的决定至关重要，这也是所采用的敏捷方法（如 Sprint 计划会议）的常见编排的一部分。

你现在可以做什么？

作为威胁建模专家，应确保实施一个威胁建模过程，该流程能够清楚地识别操作，并将其包含在所选的任务和 Bug 跟踪中。 一种方法可以是采用能够自动化这一流程的众多风险建模工具中的一种。

作为开发人员，你应该专注于确定为必要的安全控制。 该流程设计的提供方式应与你期望接收任何其他活动的方式相同。

功能、用户情景和任务

我们已经说过，缓解措施代表了风险模型产生的有关 DevOps 集成的最重要的项目。 因此，必须明确定义在所选任务和 Bug 跟踪工具上从这些缓解措施中创建的对象类型。 有些缓解措施可能会持续超过一次冲刺。 因此，最佳方式是将其创建为功能。 但许多更简单的缓解措施可以在一个冲刺中实施；因此，可以将其表示为用户情景或任务。 虽然也可以生成其他工作项类型，但这可能会导致流程复杂，从而导致错误和混乱。 因此，坚持使用单个工作项类型似乎更实用。 考虑到缓解措施可以视为用户情景的子项，你可以考虑将其表示为任务，这意味着放宽了在单个冲刺中执行所述工作项类型的要求。

你现在可以做什么？

确保在积压工作中体现风险模型确定的缓解措施。 确定一种方式清晰地表示它们。

用户情景

缓解措施并不是威胁模型的唯一项目部分，可以而且应该与任务和 Bug 跟踪工具中的内容保持一致。 例如，你可能也想表示威胁。 这一目标可以通过在通常的“作为[我是谁]，我想[我想要什么]，这样我就可以[做什么]。”中添加一个 WITHOUT 子句来扩展用户情景的方式来实现。例如：“作为用户，我想用我的信用卡付款，这样我就可以购买一些商品，但不能让我的信用卡数据被盗”。 WITHOUT 子句可以映射到一个或多个威胁，有时还可以用来表示安全要求。 通过确保在风险模型中明确威胁和 WITHOUT 子句之间的一致性，我们就可以确保团队反应并处理了可能的风险，因为这些风险已包含在用户情景中。 你还可以使用此关系将每个被标识为用户情景一部分的安全要求映射到至少一个威胁。

补充知识

WITHOUT 子句并非制作本页面的团队的原创想法。 我们不确定是谁首先提出了这个想法，但我们感谢提出这个想法的人。

图 1：对齐要求

例如，上图显示了以下情况：

• 威胁 A 通过子句 WITHOUT 1 与用户情景 1 相关联。

• 威胁 B 通过子句 WITHOUT 2 与用户情景 2 相关联。

• 威胁 B 也与用户情景 3 相关联。 但是用户情景 3 没有分配给任何 WITHOUT 子句。 为什么？ 这代表了一种潜在异常，您应该对此进行调查。

• 威胁 B 也与用户情景 1 相关联。 目前还不清楚我们是否应该允许将用户情景与多个威胁相关联。

• 威胁 C 与用户情景 4 相关联，而用户情景 4 与 WITHOUT 3 和 4 相关联。 目前还不清楚我们是否应该允许多个 WITHOUT 子句。

• 威胁 D 没有与任何用户情景相关联。 我们缺少的是用户情景还是 WITHOUT 子句？

• 用户情景 5 与一个 WITHOUT 子句相关联，但它没有关联的威胁。 我们缺少的是威胁还是只是用户情景和威胁之间的关联？

我们很少将安全要求确定为风险模型的一部分。 因此，WITHOUT 子句通过扩展了具有安全要求的风险模型并将其与相关用户情景相关联，为进一步整合体验带来了机会。 这种方法将在风险建模体验的发展方面发挥重要作用，使其从一种长期重复的评估转变为 DevOps 的安全设计工具。

你现在可以做什么？

开始在用户情景中使用 WITHOUT 子句。

使用 WITHOUT 子句将识别的威胁映射到用户情景，反之亦然。

整合的体验

你可以将同样的想法应用于其他应用场景。 例如，威胁模型可以将安全要求与威胁模型本身内的项目（如威胁和缓解措施）以及跟踪和 Bug 跟踪工具中的项目相关联。 例如，实施监视以识别正在进行的攻击的要求应映射到与监视相关的所有缓解措施，然后映射到 Task & Bug 跟踪工具中的相应项目。 这样的结果是很容易识别出没有实现安全要求的情况：事实上就是没有与任何事情关联的情况。

可以在任务和 Bug 跟踪工具中的项目与威胁模型标识的威胁和缓解措施之间使用相同的链接，以促进安全活动的优先顺序。 安全性通常在最后实施，有时是为了解决某些工具或渗透测试发现的反应性漏洞。 相反，最有效的方式是将缓解措施与关联的用户情景或功能一起实施。 为什么要被动等待实施控制措施来保护信用卡详细信息的安全，何不将其与关联的付款功能一起实施？ 风险模型应该强调这些关系，并提供一种简单的方法来规定在冲刺期间实施某些功能时需要实施某些相关的安全功能。 例如，在冲刺计划会议期间，可以使用这些信息进行有意义的讨论，并推动明智地设置优先级。 机制很简单。 假设我们处理的项目的产品负责人决定为下一个冲刺计划一个用户情景。 上述用户情景中有一个与威胁关联的 WITHOUT 子句。 风险模型确定了针对同一威胁的几种缓解措施。 因此，我们可以立即推断，我们应该为一个或多个已确定的缓解措施设置优先级。

图 2：为安全性设置优先级

例如，在上图中，我们可以看到用户情景 1 与到威胁 1 相关联，而威胁 1 又与缓解措施 A 和 B 相关联。因此，我们还应该考虑实施其中一种或两种缓解措施。

你现在可以做什么？

使用风险模型作为参考，将带有 WITHOUT 子句的用户情景与所选择缓解措施相对应的工作项相关联。 在计划下一个冲刺时，当你使用 WITHOUT 子句实施其中一个用户情景时，请确保为关联的安全活动设置优先级。

通过集成来突出不对齐的情况

开始考虑如何将构成威胁模型的项目与 Task & Bug 跟踪工具中的项目链接在一起后，可以更轻松地识别改善这两者质量的机会。 关键是利用其关系来突出差异，并利用其中一个中存在的信息来补充、整合和解释另一个中的信息。 如上所述，你可以在不显著影响团队工作方式的情况下做到这一点。 这是因为该方法依赖于现有信息，并在不同世界中的不同对象之间创建关系。 因此，风险模型将成为解决方案安全性的真相来源。 同时，积压工作可以与解决方案的状态持续对齐。

你现在可以做什么？

定期验证不存在未映射的威胁或带有 WITHOUT 子句的用户情景。

风险建模和运营

所有这些想法主要专注于 DevOps 的开发方面。 我们还能做些什么来改善运营吗？ 我们认为可以。 例如，可以使用风险建模作为辅助根本原因分析的工具，因为风险建模从安全的视角提供了系统的全面视图，从而可以更好地理解某些攻击的影响。 为了实现这一点，有必要将风险模型与所选监视工具的现有信息提要相集成。 这种方法可以是对所选 SIEM 的补充。

将风险建模与运营相结合的另一个想法是使用前者来推动设计后者的发生。 一个例子是解决方案的事件设计。 风险建模可以识别可能的攻击，我们可以使用这些知识来识别范围内的解决方案在这些攻击失败时可能会引发的事件。 如果进行严格的输入验证，恶意攻击者需要多次尝试才有可能成功。 最初的尝试都会失败，直到最后会有一次尝试成功。 如果使每次失败都会引发事件并在达到某个阈值时触发警报，就能够检测到攻击并采取行动进行修正。 如果仅限于监视基础结构，就很少能检测到这些情况。 因此，有必要加入自定义事件，团队必须设计和实施这些事件，以便 SOC 能够利用。

此外，后者可能对解决方案了解不多。 因此，SOC 可能无法确定在输入验证失败时如何回应。 当不幸发生数据泄露时，必须迅速做出回应，以减少直接损害以及最终罚款的概率和实体。

因此，我们需要提前计划需要监视什么，在什么条件下我们可能会出现问题，以及发生问题时该怎么办。 识别这些事件的最佳方法是依靠风险模型。 因此，利用风险模型生成标准化项目，以指导和加速必要配置的实施，从而推动监视和审核，并辅助事件响应，这些都将是很有帮助的措施。

你现在可以做什么？

积极使用风险模型来识别可以针对每个威胁提出的事件。 这些事件可以由基础结构提供，也可以是应用程序必须引发的。 在积压工作中包含工作项，以确保这些事件得到实施。

积极与运营和安全团队（包含 SOC 团队）合作，以确保利用事件发出警报并识别安全事件。

对 ROI 的影响

你可能好奇为什么这些技术会对风险建模的 ROI 产生积极影响。 从我们的角度来看，这些技术对于提高 DevOps 团队的风险建模价值至关重要。 我们反复看到的问题是，这些团队认为安全性的成本价值有限，还需要大量不可预见的工作。 有时，人们不清楚他们为什么要投入这么多时间来修正安全问题。 结果是，安全不再是一个机会，而是一个问题。 风险建模有可能克服这些问题，因为它提供了实施安全性的理由。 此外，风险建模可以在开发流程的早期开始，避免设计错误，如果没有尽早检测到这些错误，可能会付出高昂的成本。 上述技术旨在将风险建模与 DevOps 更好地集成。 这确保了业务决策者和开发人员将风险建模视为开发和运营流程的自然补充。 因此，由于与已经使用的各种工具的集成，采用风险建模所获得的价值就会增加，成本就会递减。

简化风险建模人员的工作

提高风险建模 ROI 所必需的另一个重要方面是降低其成本，增加能够提供风险建模的人员数量，同时保持更均匀的质量水平。

可以通过许多尝试来解决胜任人员短缺的问题。 其中一些尝试基于整个 DevOps 团队积极参与风险建模实践。 这个想法在于确定一个提议的领导者，即对该流程具有适当知识但不一定是专家的人，并让她领导其他小组成员之间的讨论。 这一方法得到了《风险建模宣言》签署方的积极认可。

我们一致认为，这种方法可以获取良好的价值，并代表着对当前情况的改善。 这种方法还提供了很好的见解，使团队能够发展其安全文化。 然而，这种方法也并非没有缺点，因为它只涵盖几个问题，但也遗漏了很多问题。 这就造成了一致性问题，因为太容易陷入困境，把宝贵的时间浪费在次要问题上，而错过重要问题。 为了防止这些情况发生，领导者的经验将发挥重要作用。 此外，这种方法要求所有小组成员花费大量时间来讨论每个问题。

出于这个原因，即使每次冲刺只花费几个小时进行这项实践，也可能带来重大的投入。 每个人都知道，大多数团队往往会把时间浪费在涉及所有人的大型会议上，这些风险建模会议也不会例外。 不过，这种方法对于小型产品来说还是很好的，因为这些团队往往由少数高级成员组成。

另一种不同的方法

鉴于先前方法的局限性，我们倾向于限制会议的次数、时间长度和参与者人数。 因此，风险建模人员的职责将更加重要：不仅要领导访谈，还要创建和维护风险模型本身。 此方法需要更重要的胜任度和专长。 风险建模人员可以由安全拥护者或内部安全团队成员代表。 大多数组织都会选择第一种，因为安全团队通常早已经不堪重负。

安全拥护者是 DevOps 团队中对安全特别感兴趣的成员。 他们绝不是专家，但他们有基本知识，并愿意改善团队的安全状况。 这个想法是在安全拥护者和内部安全团队之间建立一种特权关联，这样第一个团队就有权帮助其团队做正确的事，而安全团队可以减少工作负载。 通过风险建模，安全拥护者将充当风险建模人员，内部安全团队的职责则是指导他们并审查其工作。

你现在可以做什么？

调查采用安全拥护者计划的可能性，并利用该计划进一步加强安全软件开发生命周期。

知识库的作用

风险建模的一个重要问题是确保无论谁执行风险模型，DevOps 团队的体验质量和价值都很高。 有了安全拥护者，这个问题变得更加紧迫。 解决这一问题的一个想法是提供知识库来推动风险模型的创建。 风险建模的知识库是关于特定上下文的信息包：它们包含与该上下文关联的实体的定义、对这些实体的可能攻击模式以及可以应用的标准缓解措施。 知识库使组织能够获得更好、更一致的结果，因为它们代表了以规定的方式指导风险建模人员的参考材料。 知识库应该具有允许我们自动将威胁和缓解措施应用于系统的规则。 这种自动化将使我们能够克服这样一个事实，即一些风险建模人员可能不具备确定是否应该应用威胁或某些缓解措施是否有效所需的经验。

知识库并不是一个新想法：许多当前的风险建模工具已经以某种形式支持知识库。 但当前的许多实施都有显著的缺点。 例如，知识库应该能够轻松地维护。 知识库的可维护性是一个尚未解决的问题。 例如，要确定用于构建知识库的最佳信息来源并不容易。 此外，维护通常需要手动进行。 创建和维护知识库应该是组织内部安全团队的职责。 我们希望公司能够开始为最常见的风险建模工具提供知识库，以减轻未来客户的一些负担。 这些知识库应该非常灵活地支持和促进其采用，即使最成熟组织也能够使所述知识库适应其实践、策略和法规。

你现在可以做什么？

考虑将集中式安全团队的部分工作量用于开发知识库的可能性，使这些知识库可供各个开发团队用于加速风险建模。

使用知识库

知识库的另一个问题是，有时它们过于复杂，无法使用。 许多知识库试图通过包含基本问题和不太关键的问题来做到全面。 不幸的是，并非所有系统都需要全面的知识库。 如果你所分析的系统很小并且无需处理敏感数据时，你可能希望采用更简单的方法。 相反，如果系统很复杂，并且需要处理 PII 和高业务价值数据，那么你会希望更深入的知识库。 因此，应该可以根据上下文应用不同版本的知识，或者将一些攻击模式和关联的缓解措施标记为“TOP”。 这样，风险建模人员就能够决定他们是想要全面的体验，还是轻松地将所需的工作降至最低。

说到效率，必须确保活动尽可能简化和自动化，以减少所需工作量。 我们认为，执行中等大小解决方案的风险模型的最佳时间应该是风险建模人员 1 天的工作量。 只有当所选择的工具能够提供加速器以实现削减所需的时间，才能获得这样的结果。 例如，如果该工具在 100 个不同的地方应用了 20 种不同类型的缓解措施，并且要求你为每种缓解措施指定其状态，那么专注于前者（而不是后者），你的效率会提高 5 倍。 所选择的工具应提供这种功能，同时仍允许在需要时进行更彻底的工作。

你现在可以做什么？

如果你当前使用的知识库不支持“TOP”威胁和缓解措施的概念，请考虑移除很少用到或不太有用的内容的可能性，以便只专注于真正重要的内容。

有时问题是，试图使所采用的知识库成为通用知识库，并涵盖多个应用场景。 你可以通过专业的知识库来改善这种情况。

询问正确的问题

在我们的分析过程中，我们考虑了使用工具支持问题框架来推动分析的第一阶段的可能性。 我们注意到，大多数缺乏经验的风险建模人员无法提出正确的问题来获取分析所需的信息。 我们的一些专家已经证明，可以根据范围内的系统关系图来确定一些关键问题。 这些问题甚至可以通过一些生成规则自动应用。 问题是，这种方法可能无法提供它所承诺的价值。 这是因为你需要理解每个问题背后的理由。 否则，你将无法评估答案并确定其是否令人满意。 不过，自动化生成问题可以为不太专业的风险建模人员提供重要价值，提高他们对范围内系统的理解。

你现在可以做什么？

采用结构化的提问方式。 例如，我们的团队采用微软 STRIDE 作为参考，取得了良好的效果。 你可以通过询问解决方案的每个组成部分来做到这一点，例如：

• 欺骗：组件如何对其使用的服务和资源进行身份验证？

• 篡改：组件是否验证其接收到的消息？ 验证是宽松还是严格？

• 否认性：组件是否在审核日志中记录交互？

• 信息泄漏：流量进出组件是否加密？ 允许使用哪些协议和算法？

• 拒绝服务：组件是否配置为高可用性？ 它是否受到 DDoS 攻击保护？

• 特权提升：是否为用户分配了所需的最低特权？ 该解决方案是否混合了针对普通用户和高特权用户的代码？

可以教授这样的技术，并且可以通过经验来改进。 因此，重要的是要实施一种连续学习方法，旨在收集所学知识并在组织内传播。

对 ROI 的影响

最重要的是，可以确定许多想法来提高风险建模体验的效率、质量，并最终提高 ROI。 不过，这一努力应被视为一个持续的过程，应致力于不断改进这一实践。

结论

风险建模是提高组织安全性的绝佳方法。 如果做得正确，可以以非常合理的成本提供价值。 我们已经确定了各种可能对提高风险建模的价值以确保现代解决方案的安全至关重要的技术，包括：

• 通过以下方式将风险模型与 DevOps 实践对齐

  • 专注于缓解措施

  • 将缓解措施与用户情景相关联

  • 强调风险模型和积压工作之间的差异

  • 使用风险模型推动更全面的安全监视和审核

• 简化风险模型的创建并提高结果的一致性

  • 依靠安全拥护者

  • 采用知识库自动识别威胁和缓解措施

  • 创建更好的知识库

  • 提供支持自动化的问题框架

希望在你选择的风险建模工具中已经可以找到其中一些技术。 将来还会包含其他技术。 我们知道，风险建模 ROI 最大化是一项长期工作，还需要一些我们尚未得到的答案。 我们也知道，有些问题仍然未知。 本文应该能为你提供一些思考的素材，希望能帮助你改进风险建模的方式。 我们希望本文能成为你们和我们的灯塔，并将有助于指导我们在未来几年的努力。