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

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

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

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

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

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

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

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

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

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

　　原则 2：纵深防御

　　纵深防御背后的思想是：使用多重防御策略来管理风险，以便在一层防御不够时，在理想情况下，另一层防御将会阻止完全的破坏。即便是在安全性社区以外，这一原则也是众所周知的；例如，这是编程语言设计的着名原则：

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

　　让我们回到为银行提供安全性的示例。为什么典型的银行比典型的便利店更安全？因为有许多冗余的安全性措施保护银行 ― 措施越多，它就越安全。单单安全摄像机通常就足以成为一种威慑。但如果攻击者并不在乎这些摄像机，那么安全保卫就将在那儿实际保护银行。两名安全保卫甚至将提供更多的保护。但如果两名保卫都被蒙面匪徒枪杀，那么至少还有一层防弹玻璃以及电子门锁来保护银行出纳员。如果强盗碰巧砸开了这些门或者猜出了 PIN，起码强盗将只能容易抢劫现金出纳机，因为我们有保险库来保护余下部分。理想情况下，保险库由几个锁保护，没有两个很少同时在银行的人在场是不能被打开的。至于现金出纳机，可以为其装备使钞票留下印记的喷色装置。

　　当然，配备所有这些安全性措施并不能确保银行永远不会遭到成功的抢劫。即便在具备这么多安全性的银行，也确实会发生银行抢劫。然而，很清楚，所有这些防御措施加起来会形成一个比任何单一防御措施有效得多的安全性系统。

　　这好象同先前的原则有些矛盾，因为我们实质上是在说：多重防御比最坚固的环节还要坚固。然而，这并不矛盾；“保护最薄弱环节”的原则适用于组件具有不重叠的安全性功能的时候。但当涉及到冗余的安全性措施时，所提供的整体保护比任意单个组件提供的保护要强得多，确实是可能的。

　　一个好的现实示例是保护在企业系统不同服务器组件间传递的数据，其中纵深防御会非常有用，但却很少应用。大部分公司建立企业级的防火墙来阻止入侵者侵入。然后这些公司假定防火墙已经足够，并且让其应用程序服务器不受阻碍地同数据库“交谈”。如果数据非常重要，那么如果攻击者设法穿透了防火墙会发生什么呢？如果对数据也进行了加密，那么攻击者在不破解加密，或者（更可能是）侵入存储未加密形式的数据的服务器之一的情况下，将不能获取数据。如果我们正好在应用程序周围建立另一道防火墙，我们就能够保护我们免遭穿透了企业防火墙的人攻击。那么他们就不得不在应用程序网络显式输出的一些服务中寻找缺陷；我们要紧紧掌握那些信息。

　　原则 3：保护故障

　　任何十分复杂的系统都会有故障方式。这是很难避免的。可以避免的是同故障有关的安全性问题。问题是：许多系统以各种形式出现故障时，它们都归结为不安全行为。在这样的系统中，攻击者只需造成恰当类型的故障，或者等待恰当类型的故障发生。

　　我们听说过的最好的现实示例是将现实世界同电子世界连接起来的示例 ― 信用卡认证。诸如 Visa 和 MasterCard 这样的大型信用卡公司在认证技术上花费巨资以防止信用卡欺诈。最明显地，无论您什么时候去商店购物，供应商都会在连接到信用卡公司的设备上刷您的卡。信用卡公司检查以确定该卡是否属被盗。更令人惊讶的是，信用卡公司在您最近购物的环境下分析您的购物请求，并将该模式同您消费习惯的总体趋势进行比较。如果其引擎察觉到任何十分值得怀疑的情况，它就会拒绝这笔交易。

　　从安全性观点来看，这一方案给人的印象十分深刻 ― 直到您注意到某些事情出错时所发生的情况。如果信用卡的磁条被去磁会怎样呢？供应商会不得不说：“抱歉，因为磁条破了，您的卡无效。”吗？不。信用卡公司还向供应商提供了创建您卡的标记的手工机器，供应商可以将其送给信用卡公司以便结帐。如果您有一张偷来的卡，那么可能根本不会进行认证。店主甚至可能不会向您要您的 ID。

　　在手工系统中一直有某些安全性所示，但现在没了。在计算机网络出现以前，可能会要您的 ID 以确保该卡同您的驾驶证相匹配。另外需要注意的是，如果您的号码出现在当地定期更新的坏卡列表之内，那么该卡将被没收。而且供应商还将可能核查您的签名。电子系统一投入使用，这些技术实际上就再也不是必需的了。如果电子系统出现故障，那么在极少见的情况下，会重新使用这些技术。然而，实际不会使用这些技术。信用卡公司觉得：故障是信用卡系统中十分少见的情形，以致于不要求供应商在发生故障时记住复杂的过程。

　　系统出现故障时，系统的行为没有通常的行为安全。遗憾的是，系统故障很容易引起。例如，很容易通过将偷来的信用卡在一块大的磁铁上扫一下来毁坏其磁条。这么做，只要小偷将卡用于小额购买（大额购买经常要求更好的验证），他们就或多或少地生出了任意数目的金钱。从小偷的角度看，这一方案的优点是：故障很少会导致他们被抓获。有人可以长期用这种方法使用同一张卡，几乎没有什么风险。

　　为什么信用卡公司使用这种愚蠢落后的方案呢？答案是：这些公司善于风险管理。只要他们能够不停地大把赚钱，他们就可以承受相当大数量的欺诈。他们也知道阻止这种欺诈的成本是不值得的，因为实际发生的欺诈的数目相对较低。（包括成本和公关问题在内的许多因素影响这一决定。）

　　大量的其它例子出现在数字世界。经常因为需要支持不安全的旧版软件而出现问题。例如，比方说，您软件的原始版本十分“天真”，完全没有使用加密。现在您想修正这一问题，但您已建立了广大的用户基础。此外，您已部署了许多或许在长时间内都不会升级的服务器。更新更聪明的客户机和服务器需要同未使用新协议更新的较旧的客户机进行互操作。您希望强迫老用户升级，但您尚未为此做准备。没有指望老用户会占用户基础中如此大的一部分，以致于无论如何这将真的很麻烦。怎么办呢？让客户机和服务器检查它从对方收到的第一条消息，然后从中确定发生了什么事情。如果我们在同一段旧的软件“交谈”，那么我们就不执行加密。