IBM安全总监Jack Danahy：风险评估步骤

Jack Danahy为IBM安全系统部高级安全总监

网络安全顶多是一门不准确的科学。“纵深防御”和“没有银弹(没有什么捷径)”这样的词语频繁的用于修饰公司的网络安全，因为公司在网络安全方面的脆弱性是显而易见的，包括不同的因素以及不断变化的攻击目标。退伍军人都知道完美的安全是像一个幽灵，这个诀窍就是将多种因素，例如意识，过程和技术等等组合到一起从而建立起一个可管理的，错落有致的，近乎合理的保护措施。

随着新的挑战不断出现，以及企业希望旧貌换新颜，一些公司期望有新鲜的力量能够应对新的威胁，这些解决方案并不能真正的完全解决问题，而且我们整个行业整体上的普遍看法是非常短视的。但是，终有一天会觉得做总比不做强，真的是这样吗?

这种观点感觉很有道理。它包含“我已经尽力了”的含义，并且通常做到足以满足行业监管所规定的最低标准。但是，现实情况真的是这样吗?公司的安全情况好转了吗，当制度上或经验上不能真正的或完整的解决一个问题时，他们会选择“尽其所能”吗?

我不认为他们会这样做

除非一个可用的解决方案无法解决这个安全问题，这个安全问题是不同寻常的(从未遇见过)，企业才会重视它，否则，不完整的解决方案会导致两个直接结果。首先，解决问题所面临的压力和公司承担的责任会被削弱甚至被消除。其二，对多少比例的初始风险真正被消除做出分析并不常见。这两方面的影响造成的结果就是企业对于所遇到的安全问题习惯了掉以轻心，对于所做的事情自我感觉良好。这听起来企业变得更安全了吗?

什么是隔离?

关注这个的原因是因为当面临新的威胁时，相对于我们平时理解和所提供的安全方案而言，解决方案的目的被定义的不够准确。其结果就是，抵御20%的威胁比抵御0%的威胁所做的更好，不幸的是，消除20%的威胁并没有任何帮助，如果剩下80%的威胁仍然足以能够摧毁你的企业。

我的意思是：

让我们使用评估技术作为一个案例，将我们健康的身体模拟成企业的安全性。如果我感到疼痛和发热，并且喉咙难以下咽任何东西，我的第一反应也许是寻找一个温度计量体温。我这样做是为了确定是否发烧。同样的道理，如果我要检查一个应用程序是否有漏洞，我会进行一次简单的扫描，寻找一些容易被识别的漏洞。对于判断是否“健康”来说，温度计和扫描两者将是非常有效的工具。

然而，在我发烧的时候，我可能也会思考是什么引起的发烧：我吃了不该吃的东西(食物中毒)?最近我受过伤(感染)?我的喉咙受到刺激以及发炎了?为了让温度计的度数有其真正的价值，我需要从一个简单的评估继续做一个更加详细的诊断，例如去看医生，验血和培植细胞，或者也许需要做一个核磁共振成像。 我不仅仅要开几天的阿司匹林还要不能忘记吃药。如果我不是量体温以及发现自己发烧，我肯定不会这样做。

如果我们回顾一下其他一些关于应用程序评估的案例，通常会发生什么?根据我的经验，当漏洞通过工具或类似的服务程序发现时，公司通常会立即做出处理。在评估后，寻找缺陷类型或启动原因分析以便找出漏洞原因，这些更加细化的评估并不能保持连续性。某些评估是作为独立的服务机构负责的，并没有适当考虑或使用模型进行综合整治。因为简单的评估被看作是“聊胜于无”，从某种意义上，系统已经被评估了，漏洞已经被发现及修复了，评估过程已经完成。

做完一次简单的评估后，会有很多理由终止评估过程，这种评估的模式已经足以满足PCI(支付卡行业 数据安全标准 )标准第六条的要求或者针对应用程序安全性的一般要求。这个评估过程已经取得了应有进展。由于缺乏自我反省的欲望，这个问题已经被清除，因此，不需要再继续进行下去了。

这种模式导致了目前的情况，在面对20年前老旧的SQL注入攻击手法以及通过未加密数据传输和存储造成的数据意外泄露时，那些技术上所谓的真正高手仍然表现的不堪一击。过于简单明了的评估解决方案曝露出公司所需求的复杂性，这个需求就是让公司变得更安全。评估软件，系统或常规做法都是已知的解决方案的一部分，很显然如果不清楚这些将会导致隐藏风险和漏洞的不断增加及扩散。如果对于低烧我只是一直服用阿司匹林，而真正的问题也许是由链锁状球菌或阑尾炎引起的，最终我会遇到大麻烦。

那么，答案是什么呢?

目前，我总能听到这样的抱怨：在与安全性方面的持久战中最终会以失败告终，因为不可能完全成功。那么，现在我会告诉你如果有一半的措施实施也会弊大于利。重点是什么呢?

秘密就是将其中的一部分解决方案包含有真正的功能并且将其用于目前的方案中。我们有责任去了解找到了什么以及没有找到什么。我们要对企业自身已经发现的漏洞以及正在寻找的漏洞保持透明度。我们不必对问题的广度做深入的调查，我们应该将风险降低到最低限度的工作做好。

回到我们进行的简单评估案例，这里我推荐具有实际价值意义的五个评估步骤。

步骤1

你正在试图确定评估的类型。这相当于一次健康检查吗? Gary McGraw 博士(Cigital公司的首席技术官和董事会成员)曾经称它为“不良检测” 。或者你正在试图评估这个应用程序是否安全吗?如果这是一次健康检查，一定要确保进行沟通交流。如果为了提高安全性，那么我们进行第二步。

步骤2

在软件或系统中需要对安全特性进行定义。你是否对加强激活程序(加密，认证，审核记录)，验证架构(通用安全数据库的使用，安全编码协议)或者识别错误(缓存溢出，错误输入验证)感兴趣呢?你所要考虑的这些手段，对于搜索漏洞而言过于简单了，如果想要具体追其根源就会无从考证。

步骤3

相互间的沟通交流将决定方法的使用。这些沟通包括一系列造成无法评估和验证的不安全因素。应该尝试去将整合的识别信息做出一份报告，并搜寻未检测的漏洞。然而，不对这些问题深究其原因看似有很多且合情合理。它们可能会说由于专业的差距，时间紧促，预算压力或者其它的任何理由进行推脱。最重要的一点是措施手段的局限性，并且每当对安全性进行广泛讨论时总要重新对它进行反复争论。

步骤4

从你的合作伙伴中增加透明度。这些工具会识别出什么?服务公司搜寻的是哪种问题?内如团队如何利用这个过程或服务公司所提供的解决方案?你所期望的与任何参与者的需求都一样，具体来说就是它们没有搜寻到漏洞以及它们的盲点。当这个透明度增加了，就可以很容易的讨论价值，价格以及预期收益了。

步骤5

将安全性进行自然的细化。我们知道安全性本身就是一个复杂的难题，它在很多方面都需要很长一段时间才能被解决。就如同许多形状不规则的物体,可能存在不同尺度上的相似性，为你所要了解的和提高的安全性的每一种因素建立一种更高的有限性和积极性。突破以往所测试的热点位置，例如，自身存在的应用程序安全，网络安全或者ID管理组件，在一种新的和高透明度的方法下进行测试。

问题的根源

正如我所做的工作一样，使我深深地感到持续增长的安全性作为一个真正需要关注的问题。目前，在安全性问题上已经花费了数十亿美元，很难找到任何一个风险已经被消除的公司。我们一直专注于是用更好的工具和手段消除这些风险，然而未被检测出来公司的风险不断地增加并且日益严重。我们要对已经完成检测的公司负责，而剩下的，你应该确保它们选择“最合适的服务公司”，而不是“聊胜于无”。

Jack Danahy介绍:

Jack主要负责安全风险产品的整合开发，并且负责IBM战略，推广以及产品管理。他负责IBM 高级安全研究院的工作，并且负责在重要的IBM行业部门负责提高安全意识和关注度。在2009年计入IBM之前，Jack是两家成功的安全软件公司的CEO和创始人，分别是于2000年卖给Watchguard公司的Qiave技术公司和 2009 年被 IBM 收购的Ounce Labs公司。他拥有五个安全技术专利，并且是在商业需求与安全控制之间的安全，保证系统安全和战略平衡方面的倡导者。