通常我们说解决问题的第一步是承认存在问题。这听起来很像忠告，但在IT脆弱性风险管理的问题上，这样表述要好得多：“第一步是找出你面临什么风险。”

通常风险相关的问题冒出来，是因为某个特别的东西出错了。一个城市垃圾堆或者华尔街日报文章冒出了敏感信息，或者就像一位最近的客户的情况那样—因为处理政策的缺失某个报废设备的一部分出现在了eBay上。

无论IT的风险是什么，查找、修复并保护组织的数据、应用、网络、系统等组件中常见或不常见的漏洞都有一套基本的最佳实践。本提示将就如何创建一个脆弱性评估流程提供建议。

脆弱性风险以很多形式出现

风险的常见定义是某件不好或令人不快的事情会发生的机率。IT专业人士的挑战是指，负面事件会以哪种形式出现。

最终把风险看作是单一“东西”的组织太多了。在IT中，风险不是单个的。就像我前面指出那样，脆弱性有多个来源。还有，比如说像应用里面的一个风险，往往是多层面的责任。无法识别出安全隐患的多个引发点很容易就会导致不切实际的期望，也会导致最后应用被视为难以令人满意。

导致情况更糟糕的是，该领域的脆弱性检测和风险管理软件供应商往往把自己的应用定位成客户自己描述的单个问题的点解决方案。在这些情况下，组织把自己认为如外科手术版精准的策略和在概念上看起来难以置信的技术组合起来，但最终在脆弱性风险评估当中却几乎没有收到任何实际效果。用这种办法不大可能对医院病人采取医用鸡尾酒疗法，按照配方根据其“疾病”的诊断进行治疗。

最适合脆弱性风险管理的团队组织法

今年的5月13号星期五被称为全国责怪他人日（National Blame Someone Else Day）。说到软件、系统、数据等安全泄露时，每天似乎都是这个节日。大多数对“这是怎么发生的？”的调查都是从怪罪开始的，总有个人要被严加斥责。谁该指责往往跟你在组织图上出现的位置有关，这种情况太经常了。

如果你身居高位的话，你得到的好处就是只用告诉那帮家伙追根溯源并任命那帮人的领导就行。如果不是的话，你必须争取更高层的支持，因为大多数脆弱性风险评估都必须是跨职能的，是要跨越组织性和技术平台边界的。主管的话事权往往是鼓励全面协作的的必要条件。无论是哪一种情况，当文化具备包容性和协作性特点时这一流程都会进行得最顺畅，但情况往往不总是这样，事情很少能在你控制之内。

降低风险程度的三个问题

为了把风险的大问题削减下来聚焦到可以有效处理的程度，有3组问题是脆弱性风险评估团队必须回答的。

1、哪种类型的漏洞会导致风险？

A、组织外部的攻击？

B、组织内部的破坏？

C、不合规的汇报和审计？

D、隐私侵犯？

2、在我们的总体环境当中什么地方是敏感链的薄弱环节？

A、我们的网络安全吗？

B、我们的应用集成架构—尤其是涉及到云方面的？

C、我们的验证或鉴权协议和过程？

D、我们的数据管理策略和相应的执行吗？

E、还是上述全部？（提示：这几乎总是正确的答案）

3、如果我们不对此薄弱环节做任何处置的话会有什么代价？

A、会导致我的组织或我个人金钱损失吗？

B、会妨碍我们实现目标的能力吗？

C、会导致法律风险吗？

D、会导致有害的困局吗？

这些问题必须都要回答，因为回答的相互对照可以聚焦最需要引起注意的领域。大多数情况下，优先级最高的风险是潜在相关成本最高的那些—尽管有时候为了展示响应能力也会从最容易处理的开始。（当风险跟法院或合规性扯上关系时这一点尤其重要）

建立风险阻止团队

现在你已经知道应该吧精力放在什么地方了，接下来可以开始确定谁应该加入初始的风险管理团队了。很多情况下，详细审查之下的风险性质使得这一步成为很明显的事情，即便优先级还没确定的情况下—比方说，诉讼的漏洞意味着你必须把公司律师放进来，并且强烈建议你“早”点邀请那些人过来谈。

毫无疑问，在处理信息问题时你的候选人清单可能要把“通常的嫌犯”列进来：

• 资深高管
• 合规性经理
• 法律顾问
• 档案经理
• IT员工（开发者、架构师、运营经理等）

出事的时候除了当事人以外，部门负责人往往也难辞其咎

注意，漏洞评估流程的形成和团队建设取决于风险背景，同时还会受到上述对每个风险关切的多重性的影响。与信息处理的方式相比，风险跟信息本身不那么直接相关。因此，你可能需要考察审视角度比典型信息管理更高级的更元级别的问题—比方说，更少基于词汇更多地基于业务流程的思维。

此外，还有两个重要角色是大多数漏洞评估流程团队都需要的：

1、档案经理和IT人士应该成为几乎每一支你组建团队的一员。要管档案的家伙是因为他们的角色主要是管理和保护关键的业务信息，并且具备丰富的相关知识和经验，而IT专业人士是因为几乎所有东西都是在计算机上跑的。

2、说到IT和跟IT讨论东西时，要确保会话包括任何你用到的云提供商。这一原因似乎明显，但你会对这一点往往被忽视感到惊讶。这些情况下，你的信息和基础设施的完整性严重依赖于他们的，因为你的东西是在对方的系统上跑的。所以他们必须成为团队的一员。

像Woodward和Bernstein一样行动

团队组建完毕后，实质工作现在就可以开始了。这一流程的核心看起来很像调查报道，也是要团队去寻找信息管道当中薄弱或者破裂环节的迹象。

下面这些是无价之宝：

邮件发件人、接收者以及附件：涉及到的这些是否足够安全？

系统时间戳：登入和登出、文件访问、边界攻击。

不合规的通知：来自监管者、审计方等

Web上提到的未被许可材料：应该属于私密内容的东西被公开曝光

漏洞评估流程调查包括了在系统内外流动的人和文档，首先要确保只有合适授权的能进来，其次只有得到批准的信息能出去。聚焦到谁以及哪个文档上面应该反映出你要减轻的风险的本质—应该能够把我们带回到以非单一化的方式对待风险的重要性。

仅仅承认有风险存在是不够的。有了漏洞评估流程就位之后，组织就能够前瞻性地识别和抵消风险了。