尽管读者中的安全人员现在可能充满渴望,但是未经加工的威胁列表往往对时间和预算有限、按照时间表创建新(或者禁用不安全的)功能的软件开发人员没有什么帮助。因此,这时候采用系统的衡量标准,对威胁列表进行排名或者优先性的区分非常重要,这样你就可以有效地分配有限的资源,处理最严重的威胁。
安全风险的排名有许多衡量标准。经典而简单的一种风险量化方法由如下的公式表示:
风险=影响×可能性
这种衡量标准确实很容易理解,甚至加强了一个组织中业务和安全部门之前的协作。例如,业务影响的量化可能由首席财务官(CFO)承担,而可能性的估计可能由首席安全官(CSO)承担,CSO负责监督安全和业务持续性过程(Business Continuity Process,BCP)团队。
在这个系统中,影响通常以货币形式表现,可能性则取0到1之间的值。例如,一个具有100000美元影响的漏洞,可能性为30%,则危险等级为3万美元($100,000×0.30)。这样的硬通货估算一般能够得到管理层的注意,加强了风险量化的实用性。这个公式可以进一步拆分,将影响分解为(资产×威胁),可能性分解为(漏洞×缓解措施)。
其他流行的风险量化方法包括信息风险因素分析(Factor Analysis of Information Risk,FAIR),这种方法与上述的模型相似,也是我们对这个重要任务的建议方法之一。通用安全漏洞评分系统(Common Vulnerability Scoring System,CVSS)提供了常见软件漏洞风险的一种创新的表现形式(我们确实喜欢这种组件化的方法,它用应用特有的时间和环境因素去影响基本的安全风险评分)。Microsoft的DREAD系统(破坏可能性、再现性、可利用性、受影响的用户和可恢复性),以及Microsoft安全响应中心在其安全公告的严重性评分中使用的简化系统是另外两种方法。所有这些系统的更多信息都可以在本章结尾处的“参考与延伸阅读”小节中找到。
我们鼓励你对这些方法进行增补,确定哪一种方法适合你以及你的组织。你甚至可以根据从每种方法中得到的概念或者从头开始开发自己的方法。风险量化受到感知能力的很大影响,即使你的团队人数不多,你也不可能找到一种获得一致同意的系统。只要记住重要的一点:长时间一致地采用你所选择的系统,这样相对的威胁等级就会一致。这就是目标——确定哪个威胁优先处理。
我们还发现,设置一个风险级别阈值(或称“故障门槛”)是很有益的,在这个级别以上的威胁必须得到缓解。在完成排名过程之前,这个阈值必须得到广泛的一致意见。故障门槛保持不同发行版本中的一致性,防止简单地变动阈值与系统进行博弈。(这也更有可能找出故意设置低于故障门槛的分数而进入系统的人)。