威胁建模介绍

2020年3月31日
来源：https://xz.aliyun.com/t/2061

威胁建模介绍

Who? What? When? Why? How?

1 谁做/需要做威胁建模？

  • 软件开发和测试
  • 架构师、操作员和管理员
  • 客户
  • 安全专家

2 什么是威胁建模

利用抽象来帮助思考风险
威胁建模是通过识别目标和漏洞来优化系统安全，然后定义防范或减轻系统威胁的对策的过程。
威胁建模是分析应用程序安全性的一种方法。这是一种结构化的方法，使您能够识别，量化和解决与应用程序相关的安全风险。威胁建模不是代码审查方法，但却是对安全代码审查过程的补充。在 SDLC 中包含威胁建模可以帮助确保从一开始就以内置的安全性开发应用程序。这与作为威胁建模过程一部分的文档相结合，可以使审阅者更好地理解系统。这使得审阅者可以看到应用程序的入口点以及每个入口点的相关威胁。威胁建模的概念并不新鲜，但近年来有了明显的思维转变。现代威胁建模从潜在的攻击者的角度来看待系统，而不是防御者的观点。微软在过去的几年里一直是这个过程的强有力的倡导者。他们已经将威胁建模作为其SDLC的核心组件，他们声称这是近年来产品安全性提高的原因之一。
当在SDLC之外执行源代码分析时（例如在现有的应用程序上），威胁建模的结果通过推广深度优先方法与宽度优先方法来帮助降低源代码分析的复杂性。您可以不用同等重点地审查所有源代码，而是将安全代码评估放在优先级上，这些组件的威胁建模已经排在高风险威胁之下。

3 在软件开发安全生命周期中进行威胁建模

威胁建模可以在软件设计和在线运行时进行， 按照“需求-设计-开发-测试-部署-运行-结束”的软件开发生命周期，威胁建模在新系统/新功能开发的设计阶段，增加安全需求说明，通过威胁建模满足软件安全设计工作；如果系统已经在上线运行，可以通过威胁建模发现新的风险，作为渗透测试的辅助工作，尽可能的发现所有的漏洞。

4 为什么要做威胁建模？

  • 在早期发现 Bug
  • 理解安全需求
  • 建造和交付更好的产品
  • 标记其他技术不能发现的问题

5 如何做威胁建模

5.1 图表

  • 理解上下文环境
    根据业务需求和开发框架理解业务遭受的威胁环境
  • 设定攻击场景
  • 画流程图
    • 外部实体，外部实体可以浏览器、移动设备、人、进程等实体
    • 数据流，可以是功能调用、网络数据流等
    • 过程，可以是服务、组件
    • 数据库，除了数据库也可以是文件、注册表、共享存储、缓存等
    • 可信边界
      • 添加与数据流相交的信任边界
      • 攻击者可以插入的点/表面
      • 物理边界，特权边界，完整性边界是信任边界的例子
      • 本地进程中的线程通常在信任边界内，因为它们共享相同的权限，权限，标识符和访问权限
      • 通过网络进行通讯的过程总是有一个信任边界
        5个元素的示例见下图：

5.2 威胁分析

  • STRIDE 介绍
    • 欺骗（Spoofing threats）
      身份欺骗的一个例子是非法访问，如使用其他用户的身份验证信息（用户名和密码）进行认证。
    • 篡改（Tampering threats）
      数据篡改涉及恶意修改数据。示例包括未经授权的对持久性数据（例如数据库中的数据）所做的更改以及在两台计算机之间通过互联网等开放网络进行传输中的数据更改。
    • 否认（Repudiation threats）
      拒绝威胁与拒绝执行操作的用户相关联，并且没有其他方面有任何证明的方式 - 例如，用户在系统中执行非法操作，该系统不能追踪被禁止的操作。不可否认是指系统有抵制否认威胁的能力。例如，用户使用了转账业务，但是随后不承认转账过，系统需要证明用户的行为。
    • 信息泄露（Information disclosure threats）
    • 拒绝服务（Denial of service threats）
      拒绝服务（DoS）攻击会拒绝有效用户的服务，例如，使Web服务器暂时不可用。必须防止某些类型的DoS威胁，以提高系统可用性和可靠性。
    • 提权（Elevation of privilege threats）
      在这种类型的威胁中，非特权用户获得特权访问权限，从而有足够的权限来妥协或破坏整个系统。提升特权威胁包括攻击者已经有效地渗透所有系统防御措施，成为可信系统本身的一部分。
      元素与 STDRE 的关系：
  • 隐私威胁
    除了微软的典型的STRIDE分析方法，现在同样需要考虑隐私威胁，国内可以参考国标GBT 35273-2017《信息安全技术个人信息安全规范》，业务数据如果涉及了个人信息要考虑对隐私数据的威胁和保护。
  • 攻击树
    示例见下图：

    攻击树可以根据组织业务经验进行积累，如组织同类型业务早期的攻击树分析，近期攻击者利用的漏洞、使用的技术等。

5.3 缓解措施

缓解模式，举些例子：

  • 认证缓解欺骗
    • 认证：
      • 基本＆摘要认证
      • LiveID身份验证
      • Cookie认证
      • Windows身份验证（NTLM）
      • Kerberos身份验证
      • PKI系统，如SSL / TLS和证书
    • 安全
      • 数字签名的数据包
      • 验证代码或数据
      • 数字签名
      • 消息认证码
      • 哈希
  • 完整性缓解篡改
    • Windows强制完整性控制
    • 访问控制列表
    • 数字签名
    • 消息认证码
  • 不可否认性缓解否认
    • 强认证
    • 安全的日志记录和审计
    • 数字签名
    • 保护时间戳
    • 值得信赖的第三方
  • 加密缓解信息泄露
    • 加密
    • 访问控制
  • 可用性缓解拒绝服务
    • 访问控制
    • 过滤
    • 配额
    • 授权
    • 高可用性设计
  • 授权缓解提权
    • 访问控制
    • 组或角色成员资格
    • 特权管理
    • 输入验证
  • 缓解隐私威胁
    • 数据清洗
    • 数据脱敏
    • 传输/存储加密
    • 访问控制
    • 授权

5.4 威胁建模过程

  • 微软提供的方法
    过程如下图：

    1. 预设场景
      • 场景，会哪里使用该产品？
      • 使用案例
      • 为场景/用例增加安全性
      • 结构化的方式来思考“你告诉客户有关产品的安全性？”
    2. 图表化场景/过程
    3. 识别威胁
      • 如果不知道从哪开始，可以从外部实体或驱动动作的事件开始
      • 不要忽略每一个威胁，因为你可能不知道它的利用方法
      • 聚焦易实现的威胁
    4. 提供每个威胁的缓解措施
    5. 验证所有威胁和缓解措施
      • 图表是否匹配最终的代码？
      • 列举的威胁是？
      • 最小化：触及信任边界的每个元素的STRIDE
      • 有测试检查模型？
        • 创建适当的测试计划
        • 测试者的方法经常发现与TM或问题的细节
      • 每个威胁是否得到缓解？
      • 缓解措施是否正确

      另外有套类似风险评估的方法，需要计算每个风险的值，以区分风险级别
      过程见下图：

    6. 识别资产：确定哪些是包含敏感或隐私信息的关键资产/信息/文件/位置
    7. 创建体系结构概述：创建体系结构图以清楚地了解建议的应用程序及其托管环境
    8. 分解应用程序：分解体系结构图以识别各种进入和退出标准
    9. 识别威胁：使用STRIDE（欺骗，篡改，拒绝，信息披露，拒绝服务和特权提升）以及可能发生这些威胁的可能威胁
    10. 记录威胁：识别各种资产，威胁和控制。捕获缺少安全控制的威胁列表，并为每个威胁提供适当的修复建议
    11. 评估威胁：在与相应的客户/客户进行讨论之后，遵循DREAD（潜在损害，可重复性，可利用性，受影响的用户，可发现性）模型来对每个已识别的威胁
      详细可以参考：https://msdn.microsoft.com/en-us/library/ff648644.aspx
  • OWASP 过程
    1. 分解应用程序。威胁建模过程的第一步是关注如何理解应用程序以及如何与外部实体交互。这包括创建用例来了解应用程序的使用方式，确定入口点以查看潜在攻击者可以与应用程序交互的位置，识别资产（即攻击者感兴趣的项目/区域），以及识别代表应用程序将授予外部实体的访问权限。此信息记录在“威胁模型”文档中，也用于为应用程序生成数据流图（DFD）。 DFD 显示通过系统的不同路径，突出特权边界。
    2. 确定并排列威胁。识别威胁的关键在于使用威胁分类方法。可以使用诸如 STRIDE 的威胁分类，或定义诸如审计和日志记录，认证，授权，配置管理，存储和传输中的数据保护，数据验证，例外管理等威胁类别的应用安全框架（ASF）。威胁分类的目标是帮助识别来自攻击者（STRIDE）和防御角度（ASF）的威胁。在步骤1中生成的DFD有助于从攻击者的角度确定潜在的威胁目标，例如数据源，进程，数据流和与用户的交互。这些威胁可以进一步确定为威胁树的根源;每个威胁目标都有一棵树。从防御的角度来看，ASF 分类有助于将威胁识别为这种威胁的安全控制的弱点。常见的威胁列表和例子可以帮助识别这些威胁。使用和滥用案例可以说明现有的保护措施可以被绕过，或者缺乏这种保护措施。可以使用诸如 DREAD 的基于价值的风险模型或基于一般风险因素（例如可能性和影响）的较不主观的定性风险模型来确定每个威胁的安全风险。
    3. 确定对策和缓解措施。缺乏对威胁的保护可能意味着可以通过实施对策来减轻风险。这种对策可以使用威胁对策映射列表来识别。一旦将风险等级分配给威胁，就可以将威胁从最高风险分类到最低风险，并且优先化缓解工作，例如通过应用所识别的对策来对这些威胁进行响应。风险缓解策略可能涉及评估这些威胁所带来的业务影响，并降低风险。其他选择可能包括承担风险，假设业务影响是可接受的，因为补偿性控制，通知用户威胁，完全消除威胁构成的风险，或者是最不可取的选择，即什么都不做。

OWASP的方法也是介绍了风险值的计算方法，详细说明见：https://www.owasp.org/index.php/Application_Threat_Modeling

6 实际的威胁建模示例

以简单的用户登录情况示例

  1. 设定场景
    用户使用浏览器登录Web应用系统，登录时检查是否为HTTPS请求，如果不是重定向到HTTPS，用户提交用户名和密码到应用服务器，应用服务网从后台数据库查询是否为正确的输入，如果用户名和密码正确，则认证成功，登录用户自己的首页界面。
  2. 图表化过程
    使用微软的建模工具辅助作图，过程见下图：
  3. 识别威胁
    结合本文 STRIDE 介绍部分，外部实体 User 可能存在欺骗、否认的威胁，否认可能是用户否认某次登录请求。
    过程“提交登录请求”可能存在篡改、拒绝服务威胁，篡改可以是拦截非 HTTPS 请求重定向到一个钓鱼站点。
  4. 缓解措施
    根据识别的威胁分析可以实施的缓解措施，最后整理成报告格式，可以用表格描述（下图只是个示例）

7 威胁建模工具

8 攻击库

参考

加个章节说下落地
前面说过，威胁建模的使用场景有2个部分：

  • 在业务需求生成后，软件设计前进行，形成软件开发的安全需求文档。这个需要跟业务和开发部门沟通配合，如果从0开始，可以考虑从一些不重要的或者开发时间充裕的需求开始。让参与的业务和开发了解项目开发可能遇到的风险，通过头脑风暴的会议讨论形成威胁建模报告，可能第一次考虑不全，但是只要一直继续下去，效果会越来越好。
  • 另一个场景是业务已经在线上运行，安全人员可以通过梳理业务功能，通过威胁建模的方式发现可能存在的风险点，结合渗透测试，查看是否有控制措施，控制措施是否有效，并能减少渗透测试遗漏的测试点。这个与其他部门沟通的工作较少，主要是能够全面了解组织的业务，安全人员可以自己来做。

威胁建模不算是风险评估，比实际的风险评估工作的范围和工作量要小，是 SDLC 过程的一部分，不要觉得很难很麻烦就不做，实际做起来要比想象中的难度小，同样威胁建模的工作过程也是对开发和业务的安全意识培训，有条件的话约早执行越好。
外包开发工作，加入一个安全需求的要求就行，要求甲方安全人员参与和监督威胁建模的执行，审核软件开发的安全需求，确定好关系人员和责任。

 


如果给你带来帮助，欢迎微信或支付宝扫一扫，赞一下。