安全设计十大原则.docx

安全设计十大原则.docx

《安全设计十大原则.docx》由会员分享，可在线阅读，更多相关《安全设计十大原则.docx（9页珍藏版）》请在冰豆网上搜索。

安全设计十大原则

CISSP（CertifiedInformationSystemsSecurityProfessional）相关资料有统计：

通过合适的十大设计原则可以避免90%的问题。

1、简单易懂

越复杂越容易出错。

越复杂，越难审查得透彻，也越难测试得比较全面，从而使得一些安全缺陷遗留在系统中。

随着系统复杂度的增加，系统的安全风险也在变高。

减少冗余、提高组件重用度。

经验构筑了保证，特别当那些经验是成功的经验时。

瓶颈是至系统的一个狭窄接口，您通过它强制所有流量通过该接口，因此您可以方便地进行控制。

您应该避免在系统中分布安全性代码，因为这会使维护更加困难。

另外，如果强制您的所有用户通过几条小通道，则监控用户行为会简便得多。

这与只有几个入口的体育馆是同一个道理；如果入口有很多，检票就困难多了。

为了达到相同的效果，您需要多得多的员工。

可用性与安全：

1）用户不会阅读文档。

如果用户需要做任何特别的事情才能获取您所提供的全部安全性好处，那么用户未必接受那些好处。

因此，您应该在缺省情况下提供安全性。

用户应该不需要了解关于安全性的任何事情以及不需要做一些特别的事情就能安全地使用您的产品。

当然，安全性是一个相对的术语；您必须作出一些关于用户安全性需求的决定。

考虑缺省情况下关闭了加密的企业应用程序服务器。

通常，您可以使用管理工具上某处的某些菜单选项来打开它。

即使系统管理员不再考虑安全性，那个人也可能认为“缺省情况下他们必定打开了加密。

”我们已经看见了许多服务器并未这样做。

2）与用户交谈以弄清其安全性需求。

正如Nielson喜欢说的那样，副总裁不是用户。

您不应该假设您知道这条信息；直接转至源头。

尝试为用户提供比他们想象所需的安全性更多的安全性。

3）认识到用户未必总是正确的。

大部分用户不是博识的。

他们可能不理解安全性问题，因此您仍应该尝试预见他们的需要。

这是个好主意，但在安全性方面可能出错。

如果您对他们需要作出的评估多于他们所需要的安全性，则使用您的（实际上，尝试提供比您想象他们所需的安全性更多的安全性）。

如果他们提供的更多，则干脆相信他们。

例如，考虑一个诸如Web门户网站的系统，您提供的一种服务是股票报价。

您的用户可能从不认为有好的理由来保护那些资料。

毕竟股票报价是用于公共消费的。

但有一个好的理由―一个攻击者可能篡改用户得到的报价。

然后用户可能根据伪造信息来确定股票买卖，结果倾家荡产。

您确实不必加密数据―您可以使用消息认证码（MAC）―但大多数用户未必预见到这一风险。

4）用户是懒惰的。

他们是如此懒惰，以至于实际上即使当您抛出用大的鲜红字母显示的“警告”对话框时，他们也不愿停下来考虑安全性。

对于用户来说，对话框是一种讨厌的东西，它阻止他们完成想做的事。

例如，许多移动式代码系统（例如，那些当使用InternetExplorer浏览Web时运行ActiveX控件的系统）将显示一个对话框，告诉您代码是谁编写的，并询问您是否确实想信任那个人。

您认为实际上有人阅读这些东西吗？

没有。

用户只是想通过阻力最少的途径马上运行代码，而不考虑后果。

2、最小特权

最小特权原则规定：

只授予执行操作所必需的最少访问权，并且对于该访问权只准许使用所需的最少时间。

当您给出了对系统某些部分的访问权时，一般会出现滥用与那个访问权相关的特权的风险。

例如，我们假设您出去度假并把您家的钥匙给了您的朋友，好让他来喂养您的宠物、收集邮件等等。

尽管您可能信任那位朋友，但总是存在这样的可能：

您的朋友未经您同意就在您的房子里开派对或发生其它您不喜欢的事情。

不管您是否信任您的朋友，一般不必冒险给予其必要的访问权以外的权利。

例如，如果您没养宠物，只需要一位朋友偶尔收取您的邮件，那么您应当只给他邮箱钥匙。

即使您的朋友可能找到滥用那个特权的好方法，但至少您不必担心出现其它滥用的可能性。

如果您不必要地给出了房门钥匙，那么所有一切都可能发生。

同样，如果您在度假时确实雇佣了一位房子看管人，那么您不可能在没有度假时还让他保留您的钥匙。

如果您这样做了，那么您使自己陷入额外的风险之中。

只要当您的房门钥匙不受您的控制，就存在钥匙被复制的风险。

如果有一把钥匙不受您的控制，而且您不在家，那么就存在有人使用钥匙进入您房子的风险。

当有人拿了您的钥匙，而您又没有留意他们，那么任何这样的一段时间都会构成一个时间漏洞，在此段时间内您就很容易受到攻击。

为了将您的风险降到最低，您要使这段易受攻击的时间漏洞尽可能的短。

现实生活中的另一个好的示例是美国政府的忠诚调查系统―“需要知道”政策。

即使您有权查看任何机密文档，您仍不能看到您知道其存在的任何机密文档。

如果可以的话，就很容易滥用该忠诚调查级别。

实际上，人们只被允许访问与那些交给他们的任务相关的文档。

UNIX系统中出现过一些违反最小特权原则的最著名情况。

例如，在UNIX系统上，您一般需要root特权才能在小于1024的端口号上运行服务。

所以，要在端口25（传统的SMTP端口）上运行邮件服务器，程序需要root用户的特权。

不过，一旦程序在端口25上运行了，就没有强制性要求再对它使用root特权了。

具有安全性意识的程序会放弃root特权并让操作系统知道它不应再需要那些特权（至少在程序下一次运行之前）。

某些电子邮件服务器中存在的一个大问题是它们在获取邮件端口之后没有放弃它们的root权限（Sendmail是个经典示例）。

因此，如果有人找到某种方法来欺骗这样一个邮件服务器去完成某些恶意任务时，它会成功。

例如，如果一位怀有恶意的攻击者要在Sendmail中找到合适的栈溢出（请参阅参考资料），则那个溢出可以用来欺骗程序去运行任意代码。

因为Sendmail在root权限之下运行，所以攻击者进行的任何有效尝试都会成功。

另一种常见情况是：

一位程序员可能希望访问某种数据对象，但只需要从该对象上进行读。

不过，不管出于什么原因，通常该程序员实际需要的不仅是必需的特权。

通常，该程序员是在试图使编程更容易一些。

例如，他可能在想，“有一天，我可能需要写这个对象，而我又讨厌回过头来更改这个请求。

”

3、故障安全化

任何十分复杂的系统都会有故障方式。

这是很难避免的。

可以避免的是同故障有关的安全性问题。

问题是：

许多系统以各种形式出现故障时，它们都归结为不安全行为。

在这样的系统中，攻击者只需造成恰当类型的故障，或者等待恰当类型的故障发生。

我们听说过的最好的现实示例是将现实世界同电子世界连接起来的示例―信用卡认证。

诸如Visa和MasterCard这样的大型信用卡公司在认证技术上花费巨资以防止信用卡欺诈。

最明显地，无论您什么时候去商店购物，供应商都会在连接到信用卡公司的设备上刷您的卡。

信用卡公司检查以确定该卡是否属被盗。

更令人惊讶的是，信用卡公司在您最近购物的环境下分析您的购物请求，并将该模式同您消费习惯的总体趋势进行比较。

如果其引擎察觉到任何十分值得怀疑的情况，它就会拒绝这笔交易。

系统出现故障时，系统的行为没有通常的行为安全。

遗憾的是，系统故障很容易引起。

例如，很容易通过将偷来的信用卡在一块大的磁铁上扫一下来毁坏其磁条。

这么做，只要小偷将卡用于小额购买（大额购买经常要求更好的验证），他们就或多或少地生出了任意数目的金钱。

从小偷的角度看，这一方案的优点是：

故障很少会导致他们被抓获。

有人可以长期用这种方法使用同一张卡，几乎没有什么风险。

为什么信用卡公司使用这种愚蠢落后的方案呢？

答案是：

这些公司善于风险管理。

只要他们能够不停地大把赚钱，他们就可以承受相当大数量的欺诈。

他们也知道阻止这种欺诈的成本是不值得的，因为实际发生的欺诈的数目相对较低。

（包括成本和公关问题在内的许多因素影响这一决定。

）

确保如果系统出现故障，那么它将以安全方式失败，例如，自动关闭。

由于故障引起DoS攻击

安全与可用性：

单点故障，例如认证授权模块出现故障会影响所有人的使用。

在设计时，需要考虑系统的可用性需求，设计一定的冗余度。

当一个组件出现故障时，可以无缝切换到备用组件。

4、保护最薄弱环节

安全性社区中最常见的比喻之一是：

安全性是根链条；系统的安全程度只与最脆弱的环节一样。

结论是系统最薄弱部分就是最易受攻击影响的部分。

攻击者往往设法攻击最易攻击的环节，这对于您来说可能并不奇怪。

如果他们无论因为什么原因将您的系统作为攻击目标，那么他们将沿阻力最小的路线采取行动。

这意味着他们将试图攻击系统中看起来最薄弱的部分，而不是看起来坚固的部分。

即便他们在您系统各部分上花费相同的精力，他们也更可能在系统最需要改进的部分中发现问题。

这一直觉是广泛适用的。

银行里的钱通常比便利店里的钱多，但是它们哪一个更易遭到抢劫呢？

当然是便利店。

为什么？

因为银行往往有更强大的安全性防范措施；便利店则是一个容易得多的目标。

这一原则显然也适用于软件世界，但大多数人并没有给予任何重视。

特别地，密码术不太会是系统最薄弱的部分。

即使使用具有512位RSA密钥和40位RC4密钥的SSL-1，这种被认为是难以置信的薄弱的密码术，攻击者仍有可能找到容易得多的方法进入。

的确，它是可攻破的，但是攻破它仍然需要大量的计算工作。

如果攻击者想访问通过网络传输的数据，那么他们可能将其中一个端点作为目标，试图找到诸如缓冲区溢出之类的缺陷，然后在数据加密之前或在数据解密之后查看数据。

如果存在可利用的缓冲区溢出，那么世界上所有的密码术都帮不了您。

如果执行一个好的风险分析，则标识出您觉得是系统最薄弱的组件应该非常容易。

您应该首先消除看起来好象是最严重的风险，而不是看起来最容易减轻的风险。

一旦一些其它组件很明显是更大的风险时，您就应该将精力集中到别的地方。

当然，可以永远使用这一策略，因为安全性从来就不是一个保证。

您需要某些停止点。

根据您在软件工程过程中定义的任何量度，在所有组件都似乎在可接受的风险阈值以内时，您应该停下来。

5、提供纵深防御

纵深防御背后的思想是：

使用多重防御策略来管理风险，以便在一层防御不够时，在理想情况下，另一层防御将会阻止完全的破坏。

即便是在安全领域以外，这一原则也是众所周知的；例如，这是编程语言设计的著名原则：

纵深防御：

采取一系列防御，以便在一层防御不能抓住错误时，另一层防御将可能抓住它。

（摘自BruceMacLennan的PrinciplesofProgrammingLanguages。

参阅参考资料。

）

为什么典型的银行比典型的便利店更安全？

因为有许多冗余的安全性措施保护银行―措施越多，它就越安全。

单单安全摄像机通常就足以成为一种威慑。

但如果攻击者并不在乎这些摄像机，那么安全保卫就将在那儿实际保护银行。

两名安全保卫甚至将提供更多的保护。

但如果两名保卫都被蒙面匪徒枪杀，那么至少还有一层防弹玻璃以及电子门锁来保护银行出纳员。

如果强盗碰巧砸开了这些门或者猜出了PIN，起码强盗将只能容易抢劫现金出纳机，因为我们有保险库来保护余下部分。

理想情况下，保险库由几个锁保护，没有两个很少同时在银行的人在场是不能被打开的。

至于现金出纳机，可以为其装备使钞票留下印记的喷色装置。

DMZ（DeMilitarizedZone）非军事区

大部分公司建立企业级的防火墙来阻止入侵者侵入。

然后这些公司假定防火墙已经足够，并且让其应用程序服务器不受阻碍地同数据库“交谈”。

如果数据非常重要，那么如果攻击者设法穿透了防火墙会发生什么呢？

如果对数据也进行了加密，那么攻击者在不破解加密，或者（更可能是）侵入存储未加密形式的数据的服务器之一的情况下，将不能获取数据。

如果我们正好在应用程序周围建立另一道防火墙，我们就能够保护我们免遭穿透了企业防火墙的人攻击。

那么他们就不得不在应用程序网络显式输出的一些服务中寻找缺陷；我们要紧紧掌握那些信息。

2011年轰动全国的各大网站