威胁风险建模
当你开始设计一个web应用时，进行应用风险建模是必需的；否则你将因没有关注真正的风险控制而浪费资源，时间和金钱。有许多种途径进行风险建模，列表如下：
- 以软件为中心的威胁建模
- 以安全为中心的威胁建模
- 以资产或风险为中心的威胁建模。
下面代表一个威胁建模工具和产业参考的混合物。用于评估风险的方法并不像实际执行结构化威胁风险建模那么重要。微软认识到，他们的安全改进计划中最重要的一个因素是企业采用威胁风险建模。许多考虑因素之一是微软的风险威胁建模过程，它很容易被设计师，开发者，代码审计和质量保障团队运用。下面的章节提供一些总括性的信息。
威胁风险建模
威胁风险建模是保障web应用安全开发的一个关键过程，它能够使公司决定正确的控制，在预算时做出有效的对策。例如，为欺诈风险可以忽略不计的系统花费$100000美元进行欺骗控制没有意义。
使用微软威胁建模过程执行威胁风险建模， 需要去替换，因为这些步骤对威胁情景和步骤没有影响。
微软威胁风险建模有5步，枚举如下，并在下图图形化展示：
1. 识别安全目标
2. 服务应用
3. 分解
4. 识别威胁
5. 识别漏洞
让我们更加详细地考虑这些步骤
确定安全目标
领导层（或者项目管理层）和软件开发和质量保障团队一样，都需要理解安全目标。为了达到这一目的，先把安全目标分解程以下几类：
- 身份：应用程序是否保护用户身份免受滥用？是否有足够的控制措施来确保身份证明（如许多银行申请所要求的）？
- 财务：评估企业的财务风险等级快沦为补救措施了，作为一个潜在的金融损失。例如，论坛软件可能比互联网银行应用的金融风险低。
- 名声：由应用的被滥用或者被成功攻击，量化估计应用名誉的损失
- 隐私和监控：应用保护用户的数据的界限在哪？论坛软件本身就是公开的，但在大多数国家，税务准备申请须遵守税务法规和隐私权立法要求。
- 可用性保障：根据服务级别协议（SLA）或类似保证，应用程序是否可用？是否是全国性的保护的基础设施？应用需要符合哪一种协议层级？高可用性的技术当然更贵，所以采用合适的控制跟踪技术将节省许多时间，资源和金钱。
这绝不是一个详细的列表，但它提供了一些对于选择和创建安全控制上的商业风险处理意见。其他风险指导来源于： - 法律（如私人或金融法律）
- 规章（如银行或电子商务规定）
- 标准（如ISO177）
- 法律协议（如支付卡行业标准或商业协议）
- 公司信息安全政策
应用程序概述
一旦安全目标得到定义，就该分析应用程序的设计来确定内容，数据流，和信任边界。
可以通过调查应用程序的架构和设计文档来做到这一点。这样的高级组件图通常足以理解数据如何以及为什么流向各个地方。例如，数据穿过一个信任边界时（如从因特网到web层，或从业务逻辑到数据库服务器）需要很小心地分析，而在相同信任级别内流动的数据不需要多少检查。
分解应用程序
一旦应用程序架构被理解，然后进一步分解它，以识别需要评估的安全影响的特征和模块。举例来说，当审查身份认证这一模块时，理解数据如何进入这个模块，模块又是如何验证和处理数据，数据流向哪里，数据怎样被存储，模块做出了什么基本决策和假设。
确定威胁
写下未知的威胁是不可能的，但同样不太可能创建新的恶意软件来利用定制系统中的新漏洞。因此，关注于已知的风险将很容易地从列表中运用工具和技术演示。
微软建议用两种不同的方式来记录威胁，一个是威胁图，像下图所示，另一个是结构化列表。
一般来收，威胁图能够明晰地展示更多的信息，但制作时间同样多；而一个结构化列表更容易建造但将花费更长时间来使威胁变得明显化。
- 攻击者可能会读取其他用户的信息
- 用户可能没有在公共电脑上注销登陆
- 数据验证可能会导致SQL注入
- 实现数据检验
- 授权可能失败，允许了未授权的身份进入
- 实现授权检测
- 浏览器缓存可能保存着许多信息
- 在HTTP头实现无缓存管理
- 如果窃听风险很高，用SSL
需要明白的是利用威胁需要活跃的攻击者；他们通常想要从你的应用中得到一些东西或者拜托控制。为了理解相关风险，运用以下类别去理解可能会攻击应用的人会是谁：
- 意外发现：普通用户在应用程序中遇到功能错误，只需要使用web浏览器就可访问特权信息或功能。
- 自动恶意软件：程序或者脚本搜寻已知漏洞，然后将结果报告回中央收集站
- 好奇的攻击者：一个安全研究者或者普通用户，注意到应用程序的错误，并决定进一步探索。
- 脚本小子：常见叛徒，为了附带收益，臭名昭著或政治议程去寻找妥协或诽谤应用，或许用OWASP的web应用渗透检查表来进行攻击。
- 有动机的攻击者：潜在的，一个不满的有内部知识的工作人员或付费的职业攻击者。
- 组织犯罪：寻求高利润支出的罪犯，比如出于电子商务后者企业银行应用，或者金融目的。
理解你需要抵抗预防的攻击者水平是很重要的，例如一个有动机的攻击者，且理解应用的内部过程，通常回避脚本小子更加危险。
STRIDE（首字母缩写）
STRIDE是一类根据攻击者类型的描述威胁的主题。STRIDE这个单词来源于下面所列的每个单词的首字母。
Spoofing Identify(身份欺骗) "身份诈骗"是存在于有很多用户但是提供单一应用数据层执行内容的关键风险，特别的，一个用户不能变成另一个用户或者是别的用户的属性。
Tampering with Data(数据篡改) 用户可以默认修改面向他们的数据，因此默认的客户端的认证，GET和POST的结果，cookies缓存，HTTP头等。应用不应该向用户发送数据，如利益比率和期限，这应该仅仅在应用自身中。应用应该仔细地检查从用户输入的数据，并确保数据是完整的可用后再运用和存储。
Repudiation(否认)用户可能会怀疑交易，当缺少对它们活动的审计和记录时。举例来说，如果一个用户说，“我并没有向这个账户转账啊！”而你不能跟踪他的应用活动，那么这笔交易将被记录为亏损。
因此，考虑到应用需要不可否认控制，比如web登录日志，每层审计跟踪，或者从顶到底的用户数据同步。更合适的是，应用只应该以用户权限运行而没有更高权限，但这对于许多现成的应用框架不太可能。
Information Disclosure(信息披露) 用户在提交私人信息到系统时应该感到谨慎。如果攻击者可以公开获得大量用户信息，无论是匿名的还是真实认证的，都将会造成应用信誉和公信力的下降。因此，应用必须对用户ID篡改和滥用进行强有力的预防，尤其是当他们使用单个环境来运行整个程序时。
也应该考虑到用户的浏览器可能会泄露信息。一些web浏览器可能忽视HTTP头中的无缓存指令后者错误的处理。相应的，每一个安全浏览器都有责任在浏览器中最小化存储信息，以防万一出现的信息泄漏，而这可能会被攻击者利用而获得应用，用户的细节信息，或者伪装成其他用户。
最后在持久化存储数据时，需要注意隐藏域的运用本质上是不安全的。这样的存储不应该被用来存储安全敏感信息或者提供充足的个人隐私保障。
Dinial of Service(服务拒绝) 应用设计者需要明白他们的应用可能遭受到决绝服务攻击。因此，昂贵的资源运用，如大文件，复杂计算，高度研究，或者长查询都只应该面向已认证和授权的用户，而对匿名用户拒绝。
如果应用没有这么庞大，那么应用的每一面都应该做一些尽可能的工作。比如，用更快更少的数据库查询，避免生成大量文件或为每一个用户生成独立链接，以防止低级的拒绝服务攻击。
Elevation of Privilege(特权提升) 如果一个应用提供不同的用户类型和管理角色，那么确保用户不能把自己的权限提高一个层级是很重要的。特别的，简单地不显示特权角色链接是不够的。取而代之，所有的活动应该通过一个授权模块，以确保只有被允许的角色可以获取享有特权的功能。
DREAD（首字母缩略字）
DREAD是一个对每一个评估的威胁进行量化，比较，排序的类别。DREAD这个首字母缩略字是由下面所列的每一类的第一个字母缩略拼接的结果。
DREAD模型在设置风险值后影响了思考方式，也被直接用来排序风险。下面展示的DREAD算法被用来计算一个风险值，是5类风险的平均值。
Risk_DREAD = (DAMAGE + REPRODUCIBILITY + EXPLOITABILITY + AFFECTED USERS + DISCOVERABILITY) / 5
这个计算经常产生一个介于0和10之间的数字；数字越大，风险越大。
这里是一些如何运用DREAD算法的例子
Damage Potential(潜在伤害)
- 如果一个风险被利用了，多大的损失会发生？
- 0 = 没有损失
- 5 = 个人用户数据被盗用或影响
- 10 = 整体的系统或数据破坏
Reproducibility(复现性)
- 重复利用这个漏洞的难度有多大？
- 0 = 非常困难或者不可能，即时对于应用管理员
- 5 = 需要一步或两步，可能需要变成授权用户
- 10 = 仅仅一个浏览器和地址栏就ok,不需要身份认证
Exploitability(攻击指数)
- 需要什么才能利用这个漏洞？
- 0 = 高级程序和网络知识，以定制的或高级攻击工具
- 5 = 互联网上存在恶意软件，或者此漏洞可被轻易地利用，和可用的攻击工具
- 10 = 仅仅一个web浏览器就可以
Affected Users(受影响的用户)
- 多少用户将被影响？
- 0 = 没有
- 5 = 一些用户，但不多
- 10 = 所有用户
Discoverability(可发现性)
- 发现这个可利用风险有多困难？
- 0 = 非常困难，甚至不可能； 需要源码或者管理员权限
- 5 = 可以通过猜测或者监测网络活动来发现
- 9 = 错误的细节已经在公共平台上披露，而且可以用搜索引擎轻易发现
- 10 = 信息在web浏览器的地址栏或者表单里可见
注意：当对已有应用进行安全审计时，“可发现性”将依照惯例被设置为10，也就是默认此风险会被发现。
注意：刚开始运用DREAD的方法可能会有点困难。去思考再现性，可利用性，和可发现性对于发现潜在的损害和受影响的用户是有益的。运用影响比可能性的方法（这会遵从类似定义在NIST-800-30的最佳实践中），我将改变形式去让影响的分数和可能的分数一样。否则可能的分数会增加。
供选择的威胁建模系统
OWASP认识到微软建模过程可能不会被所有组织采用。如果STRIDE和DREAD模型因为一些原因被接受，我们建议你的组织只运行针对现有应用程序或设计讨论的其他威胁风险模型。这将使你决定哪一个方案最适合你，而且在你的组织中采用最适当的威胁建模工具。
总的来说，执行这一威胁建模会比几乎其他任何控制手段都有更大信息。因此，进行威胁风险建模应该是在应用设计的早期就进行的。
Trike(框架名称)
Trike是一个威胁建模框架，和微软威胁建模过程有些相似。然而，Trike不同点在于它运用基于风险的方法来清楚地实现威胁风险建模，而不是用STRIDE或DREAD的框架（攻击，风险，漏洞点）。从Trike白皮书来看：Trike的目标有：
- 通过系统利益相关者的协助，确保这个系统承担的风险对于每一个系统相关者都可接受。
- 能够讲出来我们是否做了这些。
- 向其他相关者交流我们做出的努力和影响。
- 使得其他利益相关者能够理解并减少对于他们的风险，而且他们领域的风险自己也能减少。
更多细节请参考6.9节.
AS/NZS 4360:2004 （澳大利亚/新西兰4360：2004风险管理）
澳大利亚/新西兰标准AS/NZS 4360，第一次1999在年提出，然后在2004年修改，是世界上第一个正式的有关文档编辑与风险管理的标准，而且是几个正式风险管理标准之一。这个标准内容很简单（仅仅28页），灵活，可重复进行。而且，它不会将企业制约进一个特殊的风险管理方法论中，这个方法论只是实践了AS/NZS 4360标准里的5步。也提供了几个风险表作为示例，而且允许组织去免费开发适用于自己的程序。
AS/NZS 4360标准的5步如下：
- 建立范围：创建风险范围，例如，哪一个系统或者模块是重要的？
- 识别风险：在风险范围内，哪一个特殊的风险是显而易见的？
- 分析风险：审视风险，并决定是否有相应的支持控制
- 评价风险：决定剩余风险
- 解决风险：描述解决风险的方法，因此商业性的风险可以被避免
AS/NZS 4360假设风险会被一个存在的风险团队管理，组织有独特的技巧和风险管理资源去识别，分析，和解决风险。
AS/NZS 4360(澳大利亚/新西兰4360标准)的优势： - AS/NZS 4360作为风险管理方法对于企业遵从Sarbanes-Oxley 协议的表现很好；
- AS/NZS 4360为企业现代化管理风险的帮助很大，就像运用可能性和结果去决定全部的风险是很好的；
- AS/NZS 4360对于全世界的绝大多数风险管理很熟悉，而且你的公司可能也已经实现了AS/NZS 4360标准的兼容运行。
- 假如你是澳大利亚企业，可能被要求用此框架作为常规，或者你可以证明为什么不用。幸运的是，之前讨论的STRIDE/DREAD 模型与AS/NZS 4360是兼容的。
AS/NZS4360的局限性： - AS/NZS 4360标准更适合用于商业或者系统风险，而不是技术风险。
- AS/NZS 4360没有对有结构的风险威胁模型实践做出方法论层面的定义；
- 尽管AS/NZS 4360标准是通用风险管理框架，它没有提供任何架构性的检测web应用安全风险的方法。
尽管AS/NZS 4360标准可能被用来安全风险的大致审计，缺少有组织的列举web应用安全风险的方法，让它比之前提到的其他方法论表现差一点。
CVSS（通用漏洞评分系统）
美国国土安全部(DHS)成立了NIAC漏洞披露工作组，将思科系统，赛门铁克，国际空间站，Qualys（美国一家提供漏洞管理和合规性解决方案的公司）, 微软，计算机应急小组，eBay（美国著名购物网站）的数据整合在一起。而这个工作组的一个成果就是 通用漏洞平分系统（CVSS）。
CVSS的优势：
- 你已经从一个安全研究者或其他来源得知你的产品有漏洞，而且你希望去保证它有一个精确的标准严重等级，所以在发布的时候提醒你的客户进行合适的活动。
- 你是一个安全研究者，而且在测试应用的时候已经找到几种威胁。你将会用CVSS系统来产生可信赖的风险比率，保证独立软件开发商将依据他们的等级慎重处理漏洞。
- CVSS已经被工作组推荐给美国政府部门应用。但在此文完成的时候CVSS会成为政策性强制还是被广泛应用还不明确。
CVSS的局限性： - CVSS并没有将攻击范围降低，或者帮助统计任何片段代码，它仅仅是一个评分系统，而不是一个方法论模型。
- CVSS比STREAD/DREAD更复杂，因为它致力于计算应用于部署的软件和环境因素对其的已宣布的漏洞的风险。
- CVSS 的风险等级是复杂的——假设CVSS已经将特定漏洞识别了和定义了，一个电子表格是需要去计算这些风险的，或者一个蠕虫或木马已经针对少数攻击向量发布。
- 计算CVSS的风险等级的上界可能会非常高，如果进行一个彻底的代码审查的话，可能会在250分甚至更高。
OCTAVE
OCTAVE是源于卡耐基梅隆大学软件工程学院（SEI）与CERT(计算机紧急应急小组)的一个合作项目的重量级风险方法论。OCTAVE关注与企业风险，而非技术风险。OCTAVE有两个版本：完全的OCTAVE，面向大型企业；和OCTAVE-S版本面向小组织，两个版本都有独立的操作，档案，工作项目的文档化输出模型。
OCTAVE在许多站点流行适用：
- 实现一个企业文化的风险管理和控制变得越来越有必要。
- 记录并测度商业风险变得越来越及时。
- 记录并测度整体的IT安全风险，尤其是与之合作方的IT风险，变得越来越必要。
- 记录风险周边系统环境变得越来越必需；
- 能够适应根本性的重组，比如当一个公司没有工作风险的管控理论，而需要一个健壮的风险管理框架的时候。
OCTAVE的局限性： - OCTAVE与AS/NZS 4360框架是不相容的，因为它将可能性置为1（即：它假设风险永远会发生）而这对许多企业是不合适的。OCTAVE-S使得这个选项变得可以改变（即可以设为可能性为零点几），但这不是更复杂的OCTAVE的标准。
- 包含了18个变量，OCTAVE是庞大而复杂的，有许多项目内容和实践工作需要去做。
- 不提供一系列“盒子外面”的实践，去评估和减轻web应用安全风险。
因为这些问题，OWASP预期OCTAVE不会被应用设计师或开发者运用，因为它并没有将威胁风险考虑进去，而这在整个开发和所有人员参与者中是很重要的，能够减轻应用风险演变为可攻击的漏洞。
ThreatModel SDK(风险模型软件开发包)
风险模型软件开发包是一个简化的Java库，提供了基本的基于普通威胁建模工具产生的分析报告的能力。推荐风险建模工具：
- 微软威胁建模工具2016
有计划的威胁建模工具： - Mozilla SeaSponge(火狐社区建模工具)
更多信息请看： https://github.com/stevespringett/threatmodel-sdk
结论
在这一章节中，我们讨论了威胁风险建模，风险管理以及web应用安全的基本原则，利用这些原则的基本意图的应用程序将比其对应方更安全，只有通过包括特定控制才能最小化兼容性。