Threat Risk Modeling Learning

相关学习资料

http://msdn.microsoft.com/en-us/library/aa302419(d=printer).aspx
http://msdn.microsoft.com/library/ms994921.aspx
http://sourceforge.net/projects/coras/
http://sourceforge.net/projects/easy-tra/
http://sourceforge.net/projects/ratiso17799/
https://www.owasp.org/index.php/Threat_Risk_Modeling
http://msdn.microsoft.com/library/ms954176.aspx
http://msdn.microsoft.com/library/ms978516.aspx
http://outsourcing-center.com/category/manage-relationship/service-level-agreement-sla
http://www.service-level-agreement.net/
http://www.whatis.com.cn/word_5214.htm
http://www.octotrike.org/
http://www.octotrike.org/papers/Trike_v1_Methodology_Document-draft.pdf

 

目录

1. Threat Risk Modeling Introduce
2. Threat Modeling Process using Threat Modeling Process
3. STRIDE Threat Model
4. DREAD Threat Model
5. Trike Threat Modeling Systems
6. AS/NZS 4360:2004 Risk Management
7. CVSS 
8. OCTAVE Threat Modeling Systems 

 

1. Threat Risk Modeling Introduce

对于一个即将开始WEB应用程序架构设计的技术人员、管理者来说，提前应用"风险威胁模型"来对IT系统进行评估是非常必要的。这可以有效避免因为错误的判定真实的威胁而导致的IT资源、时间、金钱的浪费。
威胁风险建模是安全的Web应用开发的一个重要过程。它使组织能够确定正确的信息系统控制流程、并在预算范围内产生合理的对策。例如，如果一个系统存在极其微小的欺诈威胁，却花费100000美元去建立欺诈控制系统是一件毫无意义的工作。
从某种程度上来说，安全和效能之间是需要找到一个平衡点的，或者换个角度来看，一些小范围的安全风险是可以通过其他方面的控制方案得到覆盖控制的。

 

2. Threat Modeling Process using Threat Modeling Process

风险模型部署过程可以大致分为以下5步

1. Identify Security Objectives
2. Survey the Application
3. Decompose it
4. Identify Threats
5. Identify Vulnerabilities

转换为流程图如下:

应该通过重复执行步骤 2 至步骤 5 来逐步细化威胁模型。随着应用程序开发周期的向前推进，您会发现有关应用程序设计的更多内容，并能够添加更多细节。

0x1: Identify Security Objectives: 确定安全目标

企业(或项目)的主管、软件开发人员、以及质量保证团队都需要了解当前将要建立的信息系统的安全目标。为了更好的进行安全目标的识别，我们可以把应用程序的安全目标为以下几类：

1) Identity: 身份
    1.1) 应用程序是否需要保护用户的身份信息不被"滥用(包括盗号、泄漏、劫持等)"
    1.2) 当前系统是否有建立有效的身份控制机制，同时，应用提供方需要能够向用户证明自己确实采取了相应的防御策略，即需要提供相应的证据。这在一个真正的互信系统中是十分重要的
(例如银行系统)

2) Financial: 金融
评估一个组织在进行风险修复时可能会付出的资金上的损失。可以简单地理解为，企业为了提高当前系统的安全性而进行代码审计、或者处于监控目的为部署的日志系统、以及当发生真实安全事件
后泄漏数据对企业带来的损失，这些因素都是在评估安全目标时的"金融因素"

3) Reputation: 声誉
评估当企业的应用系统遭受到滥用、或者被黑客成功攻击的时候，企业的声誉遭受到的损失，包括对产品、业务的影响

4) Privacy and Regulatory: 隐私和监管
应用程序能在多大程度上保护用户的隐私数据？同时对数据的公开和监管在不同的社会领域也存在巨大差别，例如对于论坛系统、博客系统来说，信息公开、共享性是主要特点，但是对于税务系统
来说，处于国家政策法规的要求，数据的私密性必须得到最严格的保证。

5) Availability Guarantees: 可用性保证
企业组织需要正确评估当前信息系统对维护系统可用性的安全防御措施的需求。从某种程度上来说，安全技术的目的就是保证系统能按照原本设定的功能正常运行(即使在受到攻击的情况下)，即安
全保证可用性。那是不是可用性越高越好呢？从技术上来说当然是这样，但是我们同时要认识到，维持高可用的技术和基础设备是需要花费更多的资金、时间、资源的，我们必须正确评估当前信息
系统所需求的可用性要求，合理利用现有的安全防御组件来达到可用性和商业方面的平衡。
在互信系统中，作为服务提供商，往往需要向用户提供服务等级协议(service-level agreement，SLA)，是关于网络服务供应商与客户间的一份合同，其中明确了网络服务供应商提供的具体服
务。许多网络服务提供商(ISP)都会向客户提供这一协议。近来，许多大企业的网络服务部门采用拟定服务等级协议的方法来衡量、验证他们向客户(企业其它部门的用户)提供的服务，有时会与外
部网络供应商提供的服务进行比较。
服务等级协议（SLA）可能包括的项目如下
    1) 可提供的服务时间，包括保证每年最大断线时间
    2) 能同时服务的客户数目
    3) 明确服务标准，以便客户定期与服务商实际提供服务的质量进行对比
    4) 在发生网络变化，通过发出公告的方式，对可能影响用户行为前进行通知安排
    5) 客户出现各类问题时服务供应商对其提供技术帮助的响应时间
    6) 拨入访问可用性
    7) 运用统计学

6) Laws (such as privacy or finance laws)
评估确定相关国家对隐私、金融方面的法律规定

7) Regulations (such as banking or e-commerce regulations)
评估确定相关国家对信息安全的监管条例方面的规定

8) Standards (such as ISO 17799)
评估确定当前系统是否需要遵循某些国际安全标准

9) Corporate Information Security Policy 
评估确定当前系统是否需要遵循业内、或者国际协会制定的安全策略

另一方面，从纯技术的角度来说，对信息系统的安全目标的评估，我们需要注意，对于不同层面的系统来说，安全目标是很不同的，例如:

1) 基础网络设施
对于这个层面上的系统(或者叫硬件设备)来说，面向可用性的安全性是重点关注的目标，在云计算时代，这常常涉及到"机房安全"，即保护云机房的物理设备电源安全、防御针对网络带宽的DDOS
攻击、物理设备破坏攻击的防御、针对硬件虚拟化沙箱的虚拟机安全等等
2) OS操作系统
不管是针对传统的单主机的操作系统、还是针对基于云计算的弹性虚拟操作系统来说。操作系统层的安全目标主要针对系统级服务的代码漏洞、缓冲区漏洞、风险端口、补丁风险等等
3) WEB服务器、软件层
对于这一层面的系统软件、传统应用软件、SaaS云软件服务来说。代码安全、API函数非授权访问、应用级的身份认证漏洞等等常见的漏洞是关注重点

2. Survey the Application/Application Overview: 目标应用基础架构分析

在风险模型的建立中，一旦完成安全目标的定义，下一步就可以开始分析应用程序的架构设计，以此来确定"组件"、"数据流"、以及"信任边界"。
我们可以通过研究应用的体系架构、设计文档、UML组件图。通过这种高层次组件图是的方式来更好地理解以下几点:

1) 当前系统中有哪些数据
2) 数据都在哪些组件之间流动
3) 数据的流动方面、判断条件是什么

例如，数据从一个"信任边界"(如从互联网上Web层，或从业务逻辑数据库服务器)移动到另一个不同安全等级的"信任边界"(例如用户浏览器)，这种场景需要安全人员仔细的分析。相对的，数据流在相同的信任级别之间流动不需要那么多的审查(这和MAC、DAC模型的思想是一样的)

http://machunguang.hrbeu.edu.cn/course/81ea4e3b8bbf95ee63a75236548c5f3a52368bbf95ee63a75236.pdf

我们可以发现，研究系统的安全风险模型的一个很重要的环节就是对数据流的流动分析，因为大多数的攻击(例如SQL注入、隐私文件窃取等)都和数据流的污点跟踪有关。因此，在安全风险模型研究中，对数据流的污点研究具有重要意义。

0x3: Decompose Application: 分解应用

利用"分而治之"的思想，在了解目标系统的整体架构的基础上，我们可以开始进一步地对它的功能组件进行拆分，这样，我们就可以对单独的相对简单的组件进行安全风险分析。
例如，当我们在分析一个身份验证系统的时候，我们需要理解信息输入模块、数据的存储模块、数据验证/处理模块、数据流动策略、系统的基本配置策略(例如default by deny原则)

0x4: Identify Threats: 识别风险

到了这一步，我们已经完成了对目标系统的"分解"，即我们的风险识别对象是相对简单的单独模块、组件。
从理论上说，我们不可能列出"未知漏洞(0DAY)"，这是安全攻防对抗中的一个尚待解决的问题，安全工程师的防御策略总是慢于黑客的攻击，防御者的动作总是落后于攻击者。
因此，风险模型建立中的"漏洞风险识别"主要针对的是已知的漏洞，通过使用相应的工具和技术，我们很容易从BugTraq中获得已知的漏洞风险细节信息。
识别漏洞风险点有两种方法:

1. 威胁风险图: 简单直观，但构建过程较麻烦
2. 威胁风险结构化列表: 易于构建，但是相比之下更不容易被人理解

1. 威胁风险图

2. 威胁风险结构化列表

1. 攻击者有可能非法获取到其他用户的信息
2. 用户可以在公共场所使用我们的系统，然后并未进行log off登出操作就离开了机器，这可能导致会话劫持攻击
3. 输入验证环节存在SQL注入的风险
4. 实现安全有效的输入验证
5. 身份认证模块被绕过，导致非法越权、提权访问
6. 实现安全有效的身份认证检查
7. 浏览器的缓存可能包含有隐私信息
8. 在HTTP头中指定让浏览器在访问当前系统时禁止使用缓存
9. 使用SSL来保证通信链路的安全

0x5: Identify motivated attacker: 识别潜在攻击者

信息系统可能会遭受到来自四面八方的各种各样的攻击者，大致可以分为以下几类:

1. 偶然意外发现/触发漏洞
一个普通用户偶然发现了功能漏洞，仅仅通过浏览器偶然获得获取更多信息和功能的特权
2. 使用自动化的漏洞扫描工具
这类攻击者使用现有的扫描工具、攻击脚本对目标系统进行有针对目标的攻击、信息收集等，并将结果回传到一个信息收集中心数据库中
3. 为了改善目标系统安全的安全研究员(白帽子)
这类人通常被称为白帽子，它们会主动发现、挖掘一些漏洞，在进行测试性的渗透、攻击测试之后就会立刻停止"攻击"，并将漏洞情况以及细节报告给相关的厂商
4. 脚本小子
5. 有恶意动机、或者雇佣的攻击者
拥有恶意动机的一类攻击者，它们可能是企业内部的对企业不满的员工、或者是来自外部的雇佣黑客
6. 有组织的犯罪
这类攻击者往往会寻找具有高回报的目标，例如电商系统、银行系统。这类攻击者往往拥有极高的技术水平、甚至采用APT方式渗透进企业内部进行长期攻击

 

3. STRIDE Threat Model

STRIDE风险评估模型根据真实或潜在的攻击者的动机、或利用方式为评估标准，它将漏洞风险分成了6种风险类别，而"STRIDE"正是每种类别的头字母

0x1: Spoofing Identity: 身份欺骗

对应用程序来说，身份欺骗是一个高风险漏洞，它导致非法用户能够获取到其他用户的密码、隐私数据等等。产生这种漏洞的原因有很多，而应用系统没有对应用层和数据层进行"上下文执行环境隔离"(或者叫域隔离)是促使这种漏洞进一步扩展危害的原因。常见的域隔离方法有:

1) 基于网络的域隔离，例如:
    1.1) 生产网、开发网物理隔离
    1.2) VPN虚拟网
2) 虚拟沙箱隔离
通过为用户的上下文设置虚拟沙箱进行域隔离，有能效阻止用户进行提权、越权操作

0x2: Tampering with Data: 数据篡改
这种类型的漏洞常常发生在服务端将关键数据发送到客户端，随后又接收由客户端发送的数据。
"数据篡改攻击"常常发生在以下场景中

1. 在购物页面的表单中，通过使用hidden输入框来保存商品价格，随后服务端接收来自客户端发送的商品价格
2. 在密码找回页面中，通过使用hidden输入框来保存当前需要找回密码的账户名username，随后服务端接收来自客户端发送的账号名

0x3: Repudiation: 否认

当用户的账户遭遇盗窃攻击而导致资产损失时，用户可能会声称某次交易并不是自己的操作，同时应用系统也不能在信息系统内部追踪每一个操作过程并给出明确证明来证明某次操作确实是用户自己的"本人操作(这是一个概念意义上的本人操作，例如通过RSA私钥签名)"，则这个交互毫无疑问将被认定为误操作，企业应当为这次损失承担责任。
因此，应用系统的安全架构人员应该考虑在信息系统中增加"不可否认控制机制"，例如:

1) WEB访问日志
2) 对通信双方进行审计追踪
3) 公钥签名机制

0x4: Information Disclosure: 信息泄漏

用户完全有理由担心自己把隐私数据发送到应用系统上存在安全隐患，这种情况在云计算和云存储时代更加突出。一旦企业遭受到数据泄漏、脱库攻击，它的名声、用户信息会立即受到一个致命损失。为此，信息系统必须采用极其严格的身份认证、授权访问控制机制，尤其是在目标应用系统将所有的用户都放在同一个上下文中运行的情况下。
关于信息泄漏，我们需要考虑的另一个问题是用户客户端的信息泄漏。一些浏览器会忽略HTTP数据包头部中的no-cache指令、或者对缓存文件处理不当。
一个好的安全原则是:

"将尽量少的隐私信息保存在客户端"，例如在cookie中只保存一个USERID，而将身份信息都保存在服务端，通过客户端发送的USERID来和服务端保存的相应信息建立映射关系

0x5: Denial of Service: 拒绝服务攻击

信息系统的架构师应该事先想到它们的应用系统迟早会受到DDOS攻击(随着业务规模的扩张)、以及CC攻击(一种针对应用层的攻击)。
一般来说，攻击者能够发动拒绝服务攻击的场景如下:

1) 对大文件的处理
2) 涉及复杂计算
3) 高负载的深度搜索
4) 耗时的长SQL

对于这类"资源消耗性"的操作，应该确保它们只能被"受验证"、"被明确授权"的指定用户使用，而不是简单的开放给所有公共匿名用户

0x6: Elevation of Privilege: 特权提升

应该防止非法用户通过简单的URL访问获得特权提升、或角色提升。要注意的是，仅仅通过隐藏"特权提升链接"来进行防御是没有意义的，攻击者可以通过简单的扫描器获得这些隐藏的链接。
防御特权提升问题，本质上来说是授权控制的问题，所有的操作应该采用"授权矩阵"的方式进行控制(类似ACL的"对象-资源"控制思想)，保证只有策略指定的用户才可以进行特权操作

 

4. DREAD Threat Model

DREAD(Damage Potential、Reproducibility、Exploitability、Affected Users、Discoverability)
是一个用户考察、比较、评估风险系数分值的算法模型。DREAD模型常常被用于计算风险系数值，并对其进行排名。正如DREAD的名字所示的那样，DREAD模型总共有5个考察维度，通过对这5个考察维度取平均值，最终得到某个风险的风险值:

Risk_DREAD = (DAMAGE + REPRODUCIBILITY + EXPLOITABILITY + AFFECTED USERS + DISCOVERABILITY) / 5

风险值越大，表示风险越高

0x1: Damage Potential: 潜在破坏性
如果这个"漏洞风险被攻击者利用"进行攻击，会对企业和组织造成多少破坏:

0 = 没有任何影响
5 = 个人用户的数据会遭受到泄漏和破坏
10 = 整个系统的数据都会遭受到破坏

从"纵深防御"的角度来看，一个好的安全互信系统不仅仅是可以保护用户的数据不受到黑客的攻击，而且还应该有灾难发生处理的机制和意识，即事先就要对系统进行评估，假设真的发生了攻击事件，那么对于企业来说的损失底线在哪里，该采取怎样的措施来最大程度的减少收到的损失。很显然，对密码进行盐化HASH加密就是一种很好的灾难防御思想。

0x2: Reproducibility: 重现难度
要重现这个漏洞攻击的难度有多大:

0 = 甚至对于系统管理员来说都很难重现对应的攻击
5 = 需要一个通过身份认证的用户，并经过1、2步的步骤来重现对应的攻击
10 = 只要通过浏览器的简单操作就可以重现攻击

重现难度或者叫复现率是一个exploit的重要考察因素，因为很多时候一个攻击从发动到成立利用并获取目标信息是需要很多"前提条件"的，这些前提条件有些可以通过另一种攻击方式来实现，有些则是遵循某种概率出现，另一些则是因为一些硬件、软件bug而偶然出现的crash，它们的利用难度是不同的。、

0x3: Exploitability: 可利用性
要发送这个攻击需要哪些条件

0 = 高级编程、网络知识，并且需要配合定制化的高级攻击工具
5 = 互联网上现存的恶意程序，或者通过很简单的手段即可发送攻击
10 = 只要一个浏览器

0x4: Affected Users: 受影响用户
有多少用户会遭受到这个风险漏洞的影响

0 = 没有任何用户
5 = 一部分用户
10 = 所有用户

0x5: Discoverability: 发现难度
对于黑客或者白帽子来说要发现这个漏洞的难度有多大

0 = 需要管理员级的权限，并且需要白盒代码审计才能发现，故非常难、甚至不可能
5 = 可以通过fuzzing、网络数据包嗅探技术发现
9 = 通过搜索引擎就可以获取这个系统的漏洞，这种现在在CMS中常常发生
10 = 漏洞的细节完全被公开在网络上

 

5. Trike Threat Modeling Systems

Trike是一个风险模型评估方法手册，它用户帮助安全审计人员建立一套可遵循的、可重复的、可审计的安全风险评估操作指南

http://www.octotrike.org/
http://www.octotrike.org/papers/Trike_v1_Methodology_Document-draft.pdf

 

6. AS/NZS 4360:2004 Risk Management

AS/NZS即Australian/New Zealand Standard的意思，是于1999年首次提出，并于2004被修改。"AS/NZS风险模型"是世界上第一个正式被文档化的风险模型管理模型。
该标准的特点是灵活、迭代，并且"AS/NZS"标准并不强制规定组织应该遵循它规定的步骤，它更像是一个框架性标准，只要满足了它的基本步骤的模型算法都可以看成是"AS/NZS"的一种实现。

0x1: The five steps of the AS/NZS 4360 process are: 风险评估步骤

1. Establish Context: 
建立风险模型环境，可以理解为确定安全目标(企业/系统中哪些资源需要哪些程度的保护) 
2. Identify the Risks: 
在风险模型环境中，哪些漏洞风险需要特别注意，列出一个清单
3. Analyze the Risks: 
分析指定的漏洞风险，确定是否采取了正确的防御措施，如果没有则立刻着手部署相应的防御措施
4. Evaluate the Risks: 
评估剩余的风险，这是一个迭代的过程
5. Treat the Risks: 
采取相遇的技术、部署相应的设备对识别出的漏洞风险进行修补

0x2: The advantages of AS/NZS 4360: 优势

1. "AS/NZS 4360"很适合需要遵循"萨班斯-奥克斯利法案"的企业组织
2. "AS/NZS 4360"很适合倾向于使用传统方式评估风险的企业，例如根据"可能性和后果"来评估一个漏洞的风险
3. "AS/NZS 4360"具有很好的方案兼容性，例如"STRIDE/DREAD"就可以看成是"AS/NZS 4360"的一种实现

0x3: The limitations of AS/NZS 4360: 限制

1. "AS/NZS 4360"方案适于评估商业或体系风险，但对技术性的漏洞风险的评估效果较差
2. "AS/NZS 4360"方案只是提供了一个供其他方法学遵循的风险评估框架，并未提供实际的操作手则，它缺少一种结构化的评估方法学 

 

7. CVSS  

CVSS的全称是Common Vulnerability Scoring System(通用漏洞披露系统)，CVE就是参考了CVSS的思想而创立的。
CVSS的创立起源于美国国土安全部的一项计划，US Department of Homeland Security (DHS 国美国土安全部)建立了NIAC Vulnerability Disclosure Working Group，该组织通过整合来自Cisco(思科)、Symantec(赛门铁克)、ISS、Qualys、Microsoft(微软)、CERT/CC、eBay的漏洞评估报告，并得出一系列的安全风险报告，其中一个就是CVSS。

0x1: The advantages of CVSS: 优势

1. 作为企业或者组织，可以只接收到来自安全研究员或者其他安全研究机构发现的和自己企业有关的漏洞，并且CVSS能够确保一个准确、规范的安全等级标识(中、低、高)，这样，企业就能根据
漏洞的严重性选择不同的措施通知本次漏洞受影响的用户并发布相应的补丁
2. 作为独立研究员或白帽子来说，CVSS也是一个很好的平台，当他们发现了一个应用系统中的漏洞或可利用风险时，它们可以利用CVSS的漏洞披露和排名系统建立一个可信的漏洞披露公告，并确
保ISV(独立软件开发商)能够按照相应的排名对漏洞进行修复

0x2: The limitations of CVSS: 限制

1. 要注意的是，CVSS只是一个漏洞披露系统，它只提供漏洞的排名，而并非一个风险评估框架
2. CVSS的漏洞评分系统十分复杂，涉及到相当多的因素。并且进行CVSS漏洞评分的开销很高，仅仅对一个代码审计过程进行漏洞风险评估，就需要涉及到超过250项检查项目

 

8. OCTAVE Threat Modeling Systems

OCTAVE是一个重量级的风险评估方法学，起源于卡内基梅隆大学的SEI(Software Engineering Institute 软件工程协会)和CERT的合作项目。和"AS/NZS 4360"类似，OCTAVE主要关于的企业组织的风险，而非技术性的风险。
目前，OCTAVE有两个版本:

1. Full OCTAVE: 针对大型企业
2. OCTAVE-S: 针对小型企业

0x1: OCTAVE is popular with many sites and is useful when: 利用场景

1. 实现部署一个企业的风险管理和风险控制的文化开始变得必要，当企业发展到一定程度时
2. 文档化、流程化商业风险开始变得紧迫
3. 文档化、流程化全部IT安全风险变得十分必要
4. 识别并文档化系统周边、和外部的安全风险变得十分必要
5. 企业需要建立一个安全风险的流程化管理机制，在整个运转环节的方方面面

 

Copyright (c) 2014 LittleHann All rights reserved