IBM®
跳转到主要内容
    中国 [选择]    使用条款
 
 
Select a scope: Search for:    
    首页    产品    服务与解决方案     支持与下载    个性化服务    
跳转到主要内容

developerWorks 中国  >  Security  >

软件安全性原则: 第一部分

链条的坚固程度只与其最薄弱的环节一样

developerWorks
文档选项

未显示需要 JavaScript 的文档选项


级别: 初级

Gary McGraw (gem@cigital.com), 负责企业技术的副总裁, Cigital
John Viega (viega@cigital.com), 资深副研究员兼顾问, Cigital

2000 年 10 月 01 日

在本系列文章中,Gary 与 John 给出了设计与构建安全系统时要记住的最重要的 10 个要点。这一部分探讨了加固系统最薄弱 ― 也是最敏感 ― 部分的重要性。值得注意的是:问题并不一定是软件中的弱点。

软件安全性的确是一个广泛而复杂的主题。这一领域的最大挑战之一是:总可能有完全不符合所有已知模式的新型安全性缺陷出现。举一个好的例子,我们只需看一看密码术就行了,在密码术中构建抵御对其它算法最有名的攻击的算法相对较容易。而保护免受未知攻击却是一个大得多的挑战。而且,还有大量产生某个攻击的余地;每隔几年就有重大攻击产生。另外一个严重的挑战是:仅仅跟上已知的问题就很困难,因为这样的问题如此之多。

的确,要保护免受各种可能类型的攻击是不切实际的。然而,我们可以通过在设计和构建软件时运用一组好的原则来避免被大量的知识所淹没。

在接下来的几部分中,我们将给出 10 条用于开发安全软件的原则。这些原则的目标是要提炼出在设计与构建安全系统时应该记住的最重要点。遵循这些原则将帮助您避免许多常见的安全性问题。当然,这组原则不能涵盖可能出现的每一种可能的缺陷。我们并不佯称有任何一组原则能解决所有问题;我们仅仅试图遵守“90/10”规则 ― 通过遵守 10 条简单准则来避免 90% 的潜在问题。现在我们将从第一条原则开始,这条原则将精力集中于系统最薄弱的部分。

原则 1:保护最薄弱的环节

安全性社区中最常见的比喻之一是:安全性是根链条;系统的安全程度只与最脆弱的环节一样。结论是系统最薄弱部分就是最易受攻击影响的部分。

攻击者往往设法攻击最易攻击的环节,这对于您来说可能并不奇怪。如果他们无论因为什么原因将您的系统作为攻击目标,那么他们将沿阻力最小的路线采取行动。这意味着他们将试图攻击系统中看起来最薄弱的部分,而不是看起来坚固的部分。即便他们在您系统各部分上花费相同的精力,他们也更可能在系统最需要改进的部分中发现问题。

这一直觉是广泛适用的。银行里的钱通常比便利店里的钱多,但是它们哪一个更易遭到抢劫呢?当然是便利店。为什么?因为银行往往有更强大的安全性防范措施;便利店则是一个容易得多的目标。

让我们假定您拥有一家普通的银行和一家普通的便利店。是为保险库添加额外的门并将安全人员的数目翻倍,还是为便利店花费同样数目的钱雇佣安全官员更划算呢?银行可能已经将出纳员置于防弹玻璃之后,并安装了摄像机、配备了安全保卫、装备了上锁的保险库以及具有电子密码的门。相比之下,便利店可能装备了没那么复杂的摄像机系统以及很少的其它设备。如果您将对您的金融帝国的任何一部分进行安全性投资,那么便利店将是最佳选择,因为它的风险要大得多。

这一原则显然也适用于软件世界,但大多数人并没有给予任何重视。特别地,密码术不太会是系统最薄弱的部分。即使使用具有 512 位 RSA 密钥和 40 位 RC4 密钥的 SSL-1,这种被认为是难以置信的薄弱的密码术,攻击者仍有可能找到容易得多的方法进入。的确,它是可攻破的,但是攻破它仍然需要大量的计算工作。

如果攻击者想访问通过网络传输的数据,那么他们可能将其中一个端点作为目标,试图找到诸如缓冲区溢出之类的缺陷,然后在数据加密之前或在数据解密之后查看数据。如果存在可利用的缓冲区溢出,那么世界上所有的密码术都帮不了您 ― 而且缓冲区溢出大量出现在 C 代码中。

因为这一原因,虽然加密密钥长度的确对系统的安全性有影响,但在大多数系统中它们并不是如此的重要,在这些系统中更重要的事情都有错。同样地,攻击者通常并不攻击防火墙本身,除非防火墙上有众所周知的弱点。实际上,他们将试图突破通过防火墙可见的应用程序,因为这些应用程序通常是更容易的目标。

如果执行一个好的风险分析,则标识出您觉得是系统最薄弱的组件应该非常容易。您应该首先消除看起来好象是最严重的风险,而不是看起来最容易减轻的风险。一旦一些其它组件很明显是更大的风险时,您就应该将精力集中到别的地方。

当然,可以永远使用这一策略,因为安全性从来就不是一个保证。您需要某些停止点。根据您在软件工程过程中定义的任何量度,在所有组件都似乎在可接受的风险阈值以内时,您应该停下来。





回页首


社会工程:常见薄弱环节

有时软件并非是系统中最薄弱的环节;有时周围基础结构是系统的最薄弱环节。例如,请考虑 社会工程,因为这是攻击者使用社会工作环节来闯入系统的时机。通常,服务中心将接到一个来自听起来挺诚挚的用户的电话,该用户会说服服务专业人员给出本不该泄露的密码,或一些其它应该保密的信息。通常很容易发动这种攻击,因为客户服务代表通常并不喜欢处于紧张之中。如果他们正在和一些好象真的为不能进入其帐户而发怒的人打交道,通常,他们不想询问对远程用户进行认证的问题来使情况恶化。

即使他们确实向电话那边的人询问一些认证那个人的问题,他们将问些什么呢?出生日期?社会保障号?母亲的娘家姓?如果您明白您的目标,那么很容易获得所有这些信息。这是一个常见的问题,却令人难以置信地难以解决。

一种好的策略是尽可能地限制技术支持的能力。例如,您可能选择禁止更改密码;如果忘了密码,那么就必须创建另一个帐户。当然,这个特殊的示例通常不是一种好的解决方案,因为它给用户带来了巨大的不便。

以下详细阐述的方案是一个更好的示例。在部署系统之前,拟定了一系列问题(比如说,不少于 400 个问题)。这些问题应该非常一般,以致于任何一个人都应该能够回答这些问题。然而,任何单一问题的正确答案对于不是回答者的任何人都很难猜出。用户创建帐户时,我们从列表中选出 20 个问题,要求用户回答六个他可以作答并且在两年以后重新问起时最有可能给出相同答案的问题。下面是一些可能的样本问题:

  • 截止 2000 年 1 月,您已参加了多少次政治选举(总统选举或其它选举)?
  • 给出您和他长得最象的名人的名字。
  • 您高中时代最尴尬的一件事是什么?
  • 您同最重要的男朋友或女朋友的交往中最大的遗憾是什么?
  • 谁的死是对您来说最重要,人还是动物?

当有人忘记他们的密码,并给技术支持打电话时,技术支持只能把他们引到 Web 页面。Web 页面从六个问题中向用户给出三个问题,用户必须答对两个。如果用户答对两个,那么我们就执行下列操作:

  • 向他们给出一份 10 个问题的列表,并让他们再回答三个问题。
  • 让他们设置新密码。

我们或许只能让任何一个人以这种方式进行次数有限(比如,三次)的认证。

这一方案的结果是用户在忘记他们的密码时仍然可以完成他们需要完成的事,但技术支持使用户免遭来自社会工程方面的攻击。





回页首


下一次

下一部分中,我们将讨论关于安全软件开发的原则二和三:“纵深防御”和“保护故障”。



参考资料



作者简介

Author photo

Gary McGraw 是 Cigital(前身为 Reliable Software Technologies)负责企业技术的副总裁,该公司位于美国弗吉尼亚州杜勒斯(Dulles)。他从事咨询服务和研究工作,帮助决定技术研究和开发方向。McGraw 在 Cigital 从一个研究科学家做起,从事软件工程和计算机安全性方面的研究。他拥有印第安那大学认知科学和计算机科学双博士学位,弗吉尼亚大学的哲学学士学位。他为技术刊物撰写了 40 余篇经同行审查的文章,担任过主要的电子贸易供应商(包括 Visa 和 Federal Reserve)的顾问职务,并在空军研究实验室、DARPA、国家科学基金会以及 NIST 的高级技术项目赞助下担任首席调研员。可以通过 gem@cigital.com和他联系。


Author photo

John Viega 是一名高级副研究员,Software Security Group 的共同创始人,并担任 Cigital 的资深顾问。他是 DARPA 赞助的开发标准编程语言安全性扩展的首席调研员。John 已撰写了 30 余篇涉及软件安全性和测试领域的技术性文章。他负责在主要网络和电子贸易产品中查找一些众所周知的安全性弱点,包括最近对 Netscape 安全性的攻破。他还是开放源码软件社区的重要成员,编写过 Mailman、即 GNU Mailing List Manager 以及最近发布的 ITS4(一种在 C 和 C++ 代码中查找安全性弱点的工具)。Viega 拥有弗吉尼亚大学的计算机科学硕士学位。可以通过 viega@cigital.com和他联系。




对本文的评价

太差! (1)
需提高 (2)
一般;尚可 (3)
好文章 (4)
真棒!(5)

建议?







回页首


IBM 公司保留在 developerWorks 网站上发表的内容的著作权。未经IBM公司或原始作者的书面明确许可,请勿转载。如果您希望转载,请通过 提交转载请求表单 联系我们的编辑团队。
    关于 IBM 隐私条约 联系 IBM 使用条款