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. Identify Security Objectives
2. Survey the Application
3. Decompose it
4. Identify Threats
5. Identify Vulnerabilities

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函数非授权访问、应用级的身份认证漏洞等等常见的漏洞是关注重点

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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