【51CTO.com快译自12月15日外电头条】因特网安全行业出现过各种各样失败的安全解决方案。虽然也有例外,但是一个人可以根据事情失败的原因学到一些通用的原理。下面则是一些这方面意见的总结。
最薄弱环节
“安全措施的好坏只取决于最薄弱环节的强度”。这可能是最著名的格言。然而令人惊讶的是,很多安全措施都是因为这个而失败的,因为最薄弱的环节往往不能很明显的看出来。加密业务的几个例子很好的证明了这一点。拿你可以找到的具有最长密钥长度的最好加密算法做例子。我们假设它百分之百安全。那么在选择加密键值的时候你使用同样级别的技术了吗?如果你的加密键值是基于一个密码,举个例子,可能只是基于一个位数较少的数字,然后通过加密软件扩充到位数更多的密钥。然而,它的安全性能还是取决于那个较少位数的数字,比你想象的要脆弱的多。
然后就是你怎么拿这个密钥跟别人通信的问题。很多时候,通信交流是最薄弱的环节。一个经典的例子就是OTP的使用,这个东西在第二次世界大战时期就已经开始用了。OTP密钥基本上跟普通加密的文档一样长,因此能够证明OTP可以提供完美的安全。那么真是这样的吗?不是的,弱点存在于你怎么跟别人通信交流这个OTP的过程中,以及你以后怎样使用它。
即使你给别人发送了一个携带那个密钥的消息而且保证没有被破解,然而一旦在运行过程中出现普通的问题都会让这个过程变得非常的脆弱。如果由于某些原因,你不止一次的使用了某些OTP,那么就会有简单的解密方法允许第三方破译并阅读你的交流内容。美国能够破译苏联的一个间谍网络靠的就是这个原理。就像你所看到的,弱点经常存在于安全措施主要部分(你知道或者认为非常稳固的)的周边。
行业标准vs专用解决方案
使用专用解决方案可能会有些优点由于“无名安全(隐蔽运作安全)”,但是使用没有广泛验证的解决方案会很危险。加密又是一个很好的例子。
使用像AES这样的行业标准意味着很多的专家已经研究过这个算法,而且没有发现严重的问题。如果他们确实发现过问题,你也会知道。拿第一代的WiFi加密方法做例子。这个方法很快就被发现存在严重的漏洞。由于他是一个标准,所以很快就被禁止了,并且被更加强有力的方法代替。尤其是要警惕那些不公开算法而对其技术实力信口开河的的供应商。——51CTO鲜橙加冰:以前一直觉得公共安全算法没有自己写的安全,后来发现自己写的未经严格论证过的算法,在职业破解人员面前完全不堪一击,一反就反出来了。
文不对题
如果想使安全措施有效,那么你需要清楚的确定到底是什么问题。否则,你最后只能发现你自己有一个好的方案但是却不能解决你的真正问题。以防火墙为例。虽然它对于某些问题来说是较好的解决方案,但是如果你有个数据库在防火墙后面运行,那么它将不能阻止应用层的攻击,比如SQL渗透。这些虽然是普通的危险攻击,但是大多数防火墙技术都不能搞定他们,这个问题需要专门的解决方案。
人的因素
“如果你依赖用户处理,那么安全问题会很多。”如果你依靠最终用户,而且最终用户对此不是很懂或者不能被打搅,那么安全就会严重滞后。下面的几个例子可以说明这个问题。首先,我发现大多数的个人防火墙没有用处。什么是一个好的防火墙,如果问一个没有经验的用户“你想允许微软MAPI协议吗?”用户应该说什么呢?想?不想?如果你回答错了,你可能会阻击一个重要的服务,也可能会给攻击者敞开大门。
一个更严重的问题是网络钓鱼欺诈。这可能是最难防御的。基本上,如果有人能够利用网上的假表格来骗你输入你的银行账户密码,或者甚至通过电话能得手的话,那么这无疑会成为id盗贼的欺诈方法。为什么这个很难防御呢?因为这涉及到人的因素。现在你不可能控制或者知道这种花招是否是在行骗,如果你只用密码进行认证的话那么就遭了。就算是你在银行网站使用两重因素认证系统,你还是可能会把有价值的信息(比如你的社保号码)泄露给错误的人。
可用性
安全措施必须能够使用才能成功。最好的安全是切断所有的链接,然而这是极端的做法,而且一点用也没有。所有,配置简单和使用简单是让他安全的东西。毕竟,如果你不能或者将来不能使用它,也就没有安全性可言了。
我脑袋里马上想到的一个例子就是入侵检测系统(IDS)。虽然这个系统很重要,但是很多人已经不用他们了,因为他们会产生太多的输出和日志。所以,这个解决方案不是非常的有效,除非你有足够的带宽来查看所有的这些日志。类似的,很多入侵防护措施和数据丢失防护措施会产生错误肯定,因此可能阻止授权的网络流量。这就是为什么很多公司不会 “成行的(in-line)”使用他们。通常情况下,只有最基础的、最明显的流量是通过“成行的”进行控制的,其余大多数流量只是写入日志以便管理员日后查看。很明显,这也不是一个理想的方案。
总结
上面所讲的内容都是说起来容易做起来难。安全是难以捉摸的,而且一直在变化。然而,在做安全决定的时候记住这些原理是非常有帮助的。好好的确认你的问题,找到最薄弱环节,符合行业标准,尽量减少用户的参与并且尽量让使用变得简单。
【51CTO.com译稿,非经授权请勿转载。合作站点转载请注明原文译者和出处为51CTO.com,且不得修改原文内容。】
原文:Top Five Reasons For Security FAIL 作者:Adi Ruppin