本节书摘来自异步社区《网络安全体系结构》一书中的第2章，第2.3节，作者【美】Sean Convery，更多章节内容可以访问云栖社区“异步社区”公众号查看
2.3 安全系统的开发与运行概述
网络安全体系结构
现在你已经对安全策略的概念，以及实施这些规则的方式有了基本的了解，在这一节中，我们会把这些知识放到安全系统的开发与运行的环境进行讨论。首先，我们可以看到对这个过程的概括。图2-1所示的是此过程及其各步骤之间相互关系的概述。
业务需求和风险分析是安全策略的主要来源。全部安全策略都是由三类不同的文档构成的。
策略—是安全策略的基本要素，一般不是某种特定的技术，而是一些与网络运行有关的更加宏观的因素。
指导方针—组织机构的最佳做法。
标准—是一套针对某项技术或财产的最基本的操作准则。
注意 虽然在本节后面将对策略、指导方针和标准进行详细的讨论，但要注意所有这些文档的共同语境都是安全策略，总体策略涵盖的每种文档都称为策略，这是很重要的。
总体安全策略要与业内的最佳做法相结合，以建立实际的安全系统。然后，将这个安全系统渗透到安全运行的过程中，这个过程应由意外事件响应、系统监控、系统维护和依从度检查构成。最后，再将安全运行反馈到安全系统和最初的策略中，这样就形成了一个生命周期，它可以确保安全策略和安全系统不断进行更新。
本章其余的部分将对上述示意图进行详细的阐释。首先将讨论安全策略的主要驱动因素。其次讨论如何指定出一个不仅考虑到核心驱动力，而且还考虑到技术基础的安全策略。然后讨论如何将安全策略转化成有效、安全的网络设计方案。最后讨论如何通过安全系统的有效运行来改进安全策略和安全系统。
2.3.1 安全系统的开发
让我们从一个组织机构如何按部就班地指定安全系统开始说起。这个过程包括3个主要步骤。
1．检验安全策略的驱动力。
2．制定安全策略。
3．设计安全系统。
下面几节将概述上述步骤，重点放在此过程中每一点所需作出的主要决定上。
1．第1步：检验安全策略的驱动力
首先检验安全策略的两大驱动力：业务需求和风险分析。在制定任何安全策略之前，必须对业务需求和风险进行分析，这样才能确保制定出来的策略足以满足组织机构的需要。没有坚实的驱动力作为基础，安全策略所解决的问题有可能压根就不存在，甚至，以此制定出来的策略还有可能会对组织机构的日常功能产生损害。
下一节将重点从使策略可以完全满足组织机构需要的角度对这两大驱动力进行讨论。
业务需求
如图2-1所示，业务需求是组织机构安全策略开发过程中两大驱动力之一。第1章有一节的标题为“必须首先考虑业务的优先级”，在那一节中，我们已经对这一问题进行了概述。业务需求对安全策略的影响可分为两个主要类别：
业务目标；
成本分析∕效益分析。
业务目标：首先必须了解这一组织机构的目标。在为电子商务零售商设计安全网络而对该公司的职能进行调研时，你的脑中应该闪现出与要部署的系统相关的内容。例如，由于财务交易的敏感性，所有这些交易信息必须跨越私有网络的作法或许适合联邦银行的网络系统，但这种做法对于在线零售商而言，在某种程度上就是灭顶之灾。很难想像当用户用浏览器浏览Amazon.com的在线目录时，发现自己必须与Amazon建立一条专线线路连接才能购买上面的产品。当然，这是一个极端的例子，但其反例也同样不大可能—联邦银行也不可能利用公共的Internet网络来处理金融事务。因此，这里的关键在于透彻地了解业务目标，无论网络在总体业务中充当什么角色，都要确保那些目标可以得到满足。
了解业务需求还可以发现安全策略的核心组成部分，以及那些可有可无的组成部分。例如，一家需要想要确保其果酱炸面圈能够准时送达的炸面圈小店很可能不需要制定加密策略或远程访问策略。但是，我们在前文中提到的联邦银行则必须考虑这些策略及其他策略。通过将业务需求转化成策略方针，组织机构可以了解到它们的安全策略必须在多大程度上为其网络提供保护。如果策略与网络的业务需求很接近，那么所采用的途径就是正确的。
提示 如果您与安全策略开发团队的其他人员在开展上述工作时遇到了困难，不妨先将信息资产划分为3类：低价值、中等价值和高价值。低价值目标是指一旦网络遭到入侵或无法提供服务时，几乎不会对组织机构产生任何负面影响的那一部分资产。对于中等价值资产和高价值资产，也可以采取相同的方式将它们分别替换为中等负面影响和严重负面影响。
作为一名安全系统设计人员，你在了解业务需求时主要扮演一个信息接收者的作用。安全系统设计人员必须对目标拥有有足够的了解，才能指定出可靠的安全决策。这应该不止是高级管理层的备忘录。安全系统设计人员必须真正了解组织机构的目标，以作出有效的安全选择。
成本/效益分析：安全系统设计人员必须了解与安全事件相关的成本。第3章将会对各类安全事件进行详细的讨论。就本章的内容而言，可以将安全意外事件分为两个主要类别：
安全入侵—攻击者获得或篡改了数据；
网络不可用—攻击导致网络所提供的一项或多项服务不可用。
1988年纽约时报网站受到攻击就是一个安全入侵的例子。攻击者能够修改服务器上的数据，而且有可能破坏已归档的新闻。读者可以通过下面的URL，来了解更多有关NYT攻击的详细信息：http://www.cnn.com/TECH/computing/9809/13/nyt.hacked/。
从红色代码（Code Red）和尼姆达（Nimda）蠕虫，到分布式拒绝服务（DDoS）攻击和SYN泛洪攻击，这些攻击方式都可以导致网络不可用。
鉴于本书全部内容都是围绕确定和评估安全事件的成本展开的，因此本节的篇幅不必过长。在开始评估成本之前甚至有必要对信息资产，及其可能将要受到的威胁进行了解。本章的下一主题—风险分析—就于此密切相关。设计者必须从全局的高度决定如何衡量成本。定量法依赖于尽可能精确地回答成本问题。定量法对于成本核算是有帮助的，但是这种方法需要进行太多书面工作，而所提供的价值与付出的努力相比却很小，尤其是对规模非常大的组织机构而言。
另一方法则要主观得多。该方法依赖于组织机构内的专家提供的信息。请专家们倾其所能就特定安全事件对运行的影响进行评估。此方法的缺点在于，与定量研究相比，精确度有可能低很多，但其优点是相对直观。要记住，评估意外事件的成本不但必须考虑基本成本，而且还必须考虑这个意外事件发生的几率。无论选用哪种方法，成本∕效益分析都应该是一个协作的过程，以确保价值准确，也可以了解到自己面临的威胁。
一旦了解安全事件的成本之后，还必须考虑到缓解威胁的成本。设计人员要确保不仅考虑到资金方面的成本，而且还要考虑到维护所有安全措施的支持成本。对于安全设备来说尤其如此，其设备成本往往是总拥有成本（Total Cost of Ownership，TCO）的一小部分。
在得出事件成本和处理成本之后就可以进行真正的成本∕效益分析了，这种分析的作用是搞清楚资源应该如何进行合理的分配。
提示 仔细研究上述低、中等和高价值资产的定义可以帮助读者迅速取得工作进展。若要对资产进行有效的评估，必须在资产价值之外再建立一个与其相关的属性：相关风险。我们可以将相关风险分为低风险、中等风险和高风险。低风险意味着由于其性质（其位置、及其所采取的安全措施）或其对于攻击者的价值，系统受到成功攻击的可能性很低或不存在。对中等风险资产和高风险资产的成功损害的可能性相应较高。影响系统风险级别还有一个原因，即保存有这些资产的系统被曝光出安全漏洞与弱点的相关几率。
例如，假设您正在运营JelliesOfTheWorld.com，这是一个著名的电子商务站点，它的目的是让世界各地的不同美食爱好者都能买到果酱。您每天果酱的平均销售额为2400美元，或大约每小时销售价值100美元的果酱。根据您的判断，DDoS攻击每年会使自己站点的可用性受到一次损害，而每次这样的攻击平均会持续8个小时。在不考虑大局的情况下情况下，您可能会得出这样的结论：如果每年自己为了防止DDoS攻击所支出的费用多于800美元，那就会带来经济损失，让自己得不偿失。
不幸的是，事情并不那么简单。您还必须考虑DDoS攻击对用户所造成的影响。JamIndustryNews.com（果酱产业新闻）会在头版刊登文章，对您站点的安全性发出质疑吗？如果这样，我们假设10%的客户投奔了您的主要竞争对手JamIndustryNews.com。那么你每天就会因此再损失240美元，一年共计损失87600美元。虽然一次持续8小时的DDoS攻击可能不会导致客户离你而去的这种情况，但您内部销售数据库服务器的受损，以及客户信用卡数据的泄密却会导致这种情况。Egghead.com受到类似攻击就导致了这样的后果（请参见http://zdnet.com.com/2100-11-527001.html以了解更多细节）。清理成本是另一种“隐性”成本，也应该考虑在内，还有一种需要考虑的成本，即攻击者利用你被入侵的站点去攻击其他站点所造成的成本。
成本∕效益分析也可以用来判断一家组织机构是否有必要部署一项新的技术，这种方法可以权衡安全风险与新技术可以带来的回报，进而得出相应的结论。对无线LAN（wireless LAN，WLAN）和IP电话通讯之类的新兴技术就有必要进行这种评估，因为人们之所以会推动这些新技术就是看中了它们有可能会提高生产力。第11章将从技术层面会对这一概念进行详细的讨论。
风险分析
传统的风险分析是指一种对组织机构的潜在风险进行评估以证明对策合理性的分析方式。对于本书而言，我们将传统风险分析定义为成本∕效益分析，如上节所述。这种传统的风险分析在安全策略的开发过程中是必要的组成部分，因为这种分析将重点放在一些特定的方面。不幸的是，传统的风险分析往往会忽略许多类型的威胁，因为这种分析方式的重点在于攻击的结果或目标。
例如，对于传统的风险分析，攻击者窃取客户信息可能会被认为是一种风险，若要降低这种风险，就必须保障客户数据库的安全。我们可以将此类分析称为“自底向上”的风险分析：即从攻击者的目标开始分析，然后确定必要的对策。
对于安全系统设计人员，以“自顶向下”的方式进行风险分析往往更有意思。这种风险分析始于“我最薄弱的部分在哪儿？”这类自问自答，这会引出“攻击者如何才能发现我的弱点，并利用这些弱点来达到目的呢？”之类的问题。在安全系统就绪之前或之后均可进行这类的风险分析。
在先前保护客户数据库的例子中，自顶向下的风险分析方式将最终考虑到与用户PC相连的调制解调器不安全的可能性。攻击者利用不安全的调制解调器可以在连接的某些部分做好准备，以便发起ARP欺骗攻击（将在第3章阐释），以窃取数据库的认证信息。此后，攻击者就可以通过“安全的”数据库的认证，并窃取服务器中的信息。
注意 读者如需了解有关自顶向下风险分析的详细信息，可以访问http://www.cert.org/ archive/pdf/01tn001.pdf并查看计算机紧急应变小组（Computer Emergency Response Team，CERT）标题为“Attack Modeling for Information Security and Survivability”的文档。
还有一种方法可以找到网络的弱点，那就是观察最近的攻击工具是如何对网络构成影响的。在一开始，先不要考虑攻击者的目标，只需查看这些工具在网络不同部分运行时能够发挥什么作用。这种方式往往可以发现一些平时为你所忽略的东西，使得自顶向下的分析得以应用到实践当中而不是停留在理论层面。下列网站可以找到一些攻击者们可以搞到手的工具：
http://www.packetstormsecurity.org
提示 公正的视角往往能够揭示出安全系统中需要加以注意的问题。因此，在可以负担这种费用的情况下，不妨对网络进行进行外部审计。
为了让安全策略发挥作用，这两种风险分析都是必要的。如果没有自底向上的分析，那么你制定的安全策略就很难防范最新的攻击工具和攻击手段。同样，如果没有自顶向下的分析方式，那么你在制定策略时难免就会“一叶障目”，因为通过这种方式制定出来的策略只会对信息资产提供保护，而忽略掉安全系统遭受攻击的这种可能性。在检验自顶向下风险分析结果时，不妨执行自底向上的风险分析（如前面“成本∕效益分析”一节所述），这可以在某种程度上暗示你哪些信息是令攻击者垂涎的关键资料。
取得成功的步骤
安全系统设计人员在评估组织机构业务需求、分析与网络相关的风险过程中扮演着至关重要的角色。由于业务需求与风险分析息息相关，它们共同决定了安全策略的优先级，因此设计人员对安全策略的选取必须握有发言权。在此阶段，有若干事项可以使设计人员在实际的系统设计中更为轻松：
确保业务需求可以精确地反映出网络的用途，以及策略中最重要的部分；
参与讨论各类威胁出现的频率，以及组织机构需要支付的花销；
通过自底向上和自顶向下两种方式来执行风险分析。
2．第2步：开发安全策略
既然组织机构已经了解了业务需求，也进行了风险分析，下一步就该制定实际的安全策略了。这一步既是最关键的，也是最易于出错的。说这一步是最重要的，是因为策略制定不当犹如手握一份不靠谱的地图：虽然最终也有可能会达到目的地，但走弯路在所难免。说这一步是最易于出错的，是因为安全策略的制定恰如登山，是一项艰苦卓绝的工作，每当业务需求和网络风险发生变化时，这项工作就要经年累月地不断重复。因此，设计者应该将策略视为一系列的任务，其中每项任务都有确定的起点与终点。
成功制定安全策略最容易的方法是将制定出300页材料那一类的想法抛在脑后。对于安全策略，数量总会越来越多。制定一系列比较小的文档可以使得安全策略更为灵活，而且在遇到业务需求和大范围技术变化时也更方便进行修改。在下一节中，我们将重点讨论一些不容回避的重要安全策略。
关键安全策略
应该考虑对其制定安全策略的关键领域包括：
用于限定可接受使用的策略；
用于限制与远程网络连接的策略；
用于概述组织机构所拥有的各种信息敏感级别的策略；
用于保护网络用户隐私和所有客户数据的策略；
用于限定在与网络相连之前各设备必须达到的安全基准的策略。
本节将对这些策略类型进行详细的阐述。
设计师必须要判断出哪些关键策略可以帮助自己有效地开展工作。首先，要制定可接受的使用策略（Acceptable Use Policy，AUP）。这种策略的作用是限定用户访问网络的规则。这应该不仅包括内部和外部网络访问的指导方针，而且还要包括允许传输的流量。附录C中有关于这类策略及其他策略的例子。
其次，制定用于限制与远程网络连接的策略（无论是公共网络还是私有网络）。某些组织机构将它们分为若干不同的策略。这些策略应该包括与自己网络相连的那些远程工作人员、合作伙伴和客户的安全通信要求（如信任程度、机密性和认证等方面的考量因素），以及控制它们访问Internet的方式。
第三，制定处理自己网络内各类数据的大体方式。组织机构内的信息具有不同级别的敏感度；比如，与企业行将与其他公司合并的信息相比，公司排球队日程表的敏感度就要低得多。这个策略旨在阐明哪种敏感度级别的通信必须进行加密或认证，以及可以采取哪些加密方法。除了企业用户的流量之外，此策略还与安全设计之间有直接的关系，因为这项策略还应该说清在管理自己网络的命令和控制信道时，都有哪些安全要求。
第四，了解组织机构对其用户和客户的私密性策略。这项策略的目的是定义保护客户数据的需求（比如如何保护一个电子商务站点，或者如何保护一家医院的信息）。此外，某些公司的策略规定，所有网络资源的使用都要受监控。不过，一所大学制定这个策略的可能性就不太大。作为设计人员，必须了解自己组织机构的策略，这样才能保证网络中所部署的安全架构是符合自己的机构策略的。还有一种方式可以进一步强化网络的安全性，那就是一旦有人违反了公司公布的安全策略，就要让其为此承担责任。
最后，要搞清楚哪些措施可以保护网络中不同部分的安全。换句话说，必须在将服务器、路由器、交换机和终端系统连接到网络之前，对它们有所了解。
为了协助组织机构制定上述各种策略，可以根据文档的信息类型，以不同的方式对文档进行分类。如本书所述，安全策略属于下列3种类型的文档之一。
策略—策略是整个安全策略的基本要素，一般不是某种特定的技术，而是一些与网络运行有关的更加宏观的因素。策略的作用是定义整个安全策略符合标准的最低要求。策略的例子包括AUP或远程访问策略。
标准—标准用于规定一套针对某种技术或某项财产的最基本的操作准则。其他策略或指导方针往往会参考标准定义的准则。如果在不同的文档中都有某一套推荐标准，比较好的做法是通过直接引用这个标准来对它们进行描述，比如路由器强化标准、密码标准，或针对UNIX服务器与网络相连之前的安全设置方法。根据很多大型组织机构所采用的标准，主机软件镜像可以在许多情况下自动与终端系统标准保持一致。
指导方针—指导方针用于规定组织机构的最佳做法。指导方针用于概述你真正更愿意让自己的组织机构沿用，但并不严格要求采用的方法。指导方针中比较适合描述那些由于时间不足和任务量太大，导致有些规则无法应用的情形。指导方针的例子包括非武装区服务器的放置，或联网的设备中推荐使用的安全特性。
不要太在意这些文档的名称；涵盖整个策略所有必要的方面才是最重要的。比如说，指导方针不一定要单独起草文档，有时可以将指导方针融入到策略或标准之中。例如，你可能在路由器强化文档中规定了一些最低要求，同时也在这个文档中说明了在人们有能力的情况下，推荐他们采取什么行动。在这种情况下，这些推荐的做法就成了路由器强化标准中的指导方针。
附录C中包含了某个公司安全策略中的3个示例文档：一个可接受的使用策略、一个密码策略和一个防病毒策略。从这些文档中可以体会到这种文档语言和内容的风格。切记要让文档尽可能简单明了，这样才能方便日后进行理解和修订。
安全策略团队
如前所述，网络或安全团队不应该在安全策略的开发过程中孤军奋战。SAGE目录《A Guide to Developing Computing Policy Documents》（由Barbara L. Diiker编辑）建议包括下列主要成员：
一位资深的管理员；
一位能够实施策略的管理团队成员；
一位法务部门的成员；
一位用户团体代表；
一位文字功底优秀的员工。
在制定安全策略时，我会对上述列表进行一点细微的改动：将“资源管理员”分为两个岗位：一位网络操作人员和一位安全操作人员。如果指定策略这项工作还与另一个组织机构有关，那么也应该吸收一位来自该方的代表。我还建议吸收多名用户团体代表，此外，除了法务人员，还要吸收人力资源部门的代表。在策略制定完毕后，必须由管理层批准，因为管理层是负责实现和推行这些策略的。
安全与访问
是否还记得电影侏罗纪公园 中Ian Malcolm说“生命自会找到出路”时的字幕？他指的是即使通过基因技术把恐龙全都变成雌性，它们还是会进行繁殖。在设计安全策略时，设计人员不妨以同样的方式看待用户团体：“用户自会找到出路”。这主要是指如果限制过于严格或保护得过于严密，用户团体都会找到绕过这些策略的方法。
下面一个例子值得深思：我最近为阿姆斯特丹的一家公司做了一次安全设计的评估。这家公司的管理层坚信Internet的风险太大，因此决定禁止所有人访问Internet。这项策略让我感到震惊，因为这件事发生在2002年，而不是常常应用这类策略的20世纪90年代。稍作询问之后，我发现他们所有的信息技术（IT）人员都在使用安全性欠佳的模拟线路进行“测试”。实际上，这是有特权的人（IT人员）绕过Internet访问限制策略，在网上冲浪的方法。请仔细想想这对这个网络的安全性意味着什么。假设这家公司为了减少网络带来的威胁，提升公司的安全性，而禁止整个公司访问Internet。那么这家公司的确可以因此避免大多数蠕虫、电子邮件特洛伊木马（Trojan horse）等带来的危害。先别忙着高兴，我们再来研究一下这些采用点到点协议（Point-to-Point Protocol，PPP）与Internet服务提供商（ISP）建立的IT模拟连接。由于这些连接是在没有任何安全措施的情况下直接与Internet相连的，而IT人员又很可能同时与Internet及其内部网络建立连接，因此这些IT用户就有可能因为自己暴露在了全新的“后门（back door）”攻击之下，而导致整个安全系统遭到破坏。虽然每个组织机构所遇到的威胁各不相同，但是在这种情况下，与建立一条受到足够保护的Internet连接让普通员工使用相比，我敢说这家公司的实际安全效果更差。
这种比较对于新型的技术同样适用：由于WLAN风险性比较高，就禁止大家使用WLAN访问网络，这样只会降低网络的安全性，因为总有些用户会在不进行任何安全防护的情况下私下部署WLAN。与一概封杀WLAN访问相比，通过安全最佳做法让企业的WLAN置于IT部门的管理之下显然更加安全（WLAN安全将在第11章中进行论述）。记住，用户自会找到出路。
最终评估
作为安全系统设计人员，必须要保证这些通过需求制定出来的安全策略既全面而又可行，尤其要注意这些策略中依赖网络自动实施的那些部分。一定要能够让这些要求得到满足，在无法满足的情况下，要考虑对策略进行修改，让它们变得更为实际。还要尽可能确保所有的策略都不会涉及到具体的技术。这样，当网络引入了不同的功能之后，实施这些策略的技术也可以随之修改。最后，策略越简短（在合理范围内），其推行、实现和修改也就越容易。
3．第3步：设计安全系统
在网络投入运行之前，按策略文档设计安全系统是最后一步。如果策略是明确的，那么安全系统的设计就应该非常直观。如本章前文所述，这一章我们只对整个流程进行概述。在第12章中，我们还会将对其进行更加详细的阐述。
为了说清楚如何将策略转换为实施，我们以路由器强化标准为例。在本质上，这项工作其实就是在全网的所有路由器上配置专门的命令。但是，一旦我们的标准出现变化，它所带来的各种衍生变化就会让配置工作变得非常复杂。比如，有些标准中也许就没有对下列问题提供回答。
在部署了冗余的设计环境中，这些标准有什么需要注意的吗？
在高负荷环境中，这些标准对性能有何影响？需要因此升级设备吗？
除了标准规定的内容之外，对于连接到Internet的路由器，我们还需要执行其他设置吗？
即使是最精心设计的安全系统恐怕都无力回答这些问题。设计师有一种常见的误区，他们往往觉得安全系统中唯一可以添加进去的东西就是策略。安全策略的确很关键，但你也不应该成为安全策略的奴隶。还有一种有必要添加到安全系统中的东西，它就是“最佳做法”。
最佳做法是Internet集体智慧的结晶，利用这些最佳做法就能保证安全策略得到了最有效的利用。忽略最佳做法，你就只得自己重新积累这些智慧，而且在积累过程中多番遭遇挫折。最简单的例子是：你能只用详细的蓝图建成一座房子吗？你可以尽力去尝试，但恐怕不会特别成功。蓝图中并没有指定在地基上建造第一层楼的最佳方法，只是说明了必须完成的工作。同样，安全策略所注重的往往是需求，而不是手段。
在很多地方都能找到推荐的最佳做法：
书籍；
新闻组；
同侪/同事；
RFC；
网站（SysAdmin、Audit、Network、Security Institute [SANS]、CERT、North American Network Operators’ Group [NANOG]）。
如需对自己的环境应用最佳做法，只需遵循这些步骤。
第1步：本书中应该涵盖了如何将你的策略转换为安全系统的所有知识，这些知识言之有物而又上手简单。如果这里描述的最佳做法的确可行，而且还不与你的策略或组织机构使用网络的方式相违背，那就请按照这种做法来实施。否则，跳到第2步。
第2步：如果本书所描述的最佳做法在你的网络中并不可行，那就请在网络或其他书籍中查找更多有关这方面的知识。找到另一个更具实际意义的推荐标准了吗？如果找到了，那就采用该推荐标准。否则，执行第3步。
第3步：判断出最佳做法的哪一部分与你的策略相冲突。把这个问题带回策略设计团队中进行讨论。找到不能实施这一最佳做法的原因。
第4步：为自己的组织机构量身定制一份最佳做法。一定要弄清楚它所涉及的方方面面（这是最佳实践如此命名的原因之一）。
在安全策略中，通常无法直接找到有关最佳做法的信息的主要原因是，最佳做法会导致策略中包含了太多具体的技术。硬件和软件的所有版本都会对安全策略的实现方式产生轻微的影响，从而引起某些最佳做法发生变化。每当发生这种情况时都要对策略进行修改可不是好的设计方案。能达到这种详细程度的文档一般是标准或指导方针文档。即使这样，这些文档也往往不会含有所有具体的技术。
比如说，如果在策略中规定WLAN访问应该处于有线等效保密（Wired Equivalent Privacy，WEP）的保护之下，那么你会让人感到有些可笑，因为WEP已被证实不安全。正确的做法是，在策略中规定要通过机密性、完整性和认证措施对WLAN访问进行保护，并向读者提出你可以接受的加密标准。于是，在阅读策略的要求之后，这个读者就可以根据可接受的加密标准，并且重新审视那些其一贯认为在你的网络中可以安全使用的协议。此后，如果某个加密方案出现问题，那就只需更改一个可接受的加密标准，所有引用该标准的文档也就会随之得到更新。
2.3.2 安全系统运作的生命周期
安全系统的运作是指网络中发生安全事件时，安全系统对其进行复查、适应和响应的过程。安全事件的范围很广，从由于3次键入密码有误导致账户被封，到工资管理系统遭到入侵，所有类似的事件都可以称为安全事件。安全运行主要有3个方面，如图2-1所示。
系统监控与维护；
依从度检查；
意外事件响应。
本节将对这些主题进行概述，并阐释安全运作对安全策略或安全系统本身的作用。有关安全运作最佳做法的讨论超出了本书的范围。修改策略的目的是为了解决所有在整个系统中发现的缺陷，修改策略有助于解决系统未来有可能遇到的问题。根据图2-1，还可以看到在某些情况下，安全生命周期这个阶段（及安全系统运作阶段）的结果可以直接反馈到安全系统中，比如，若策略无误，但实施不当，就会产生这种反馈。
1．系统监控与维护
很多网络连接并不需要进行太多的监控，或者只需在特殊情况下进行监控。但大多数以安全为目的而部署的系统往往需要时常关照一下。虽然在小型网络的内部不对路由选择表进行监控这种做法完全合理，但只将IDS打开就期待它产生奇迹般的效果恐怕就不太可能—除非你所谓的奇迹就是为数据中心添加了一个价值30000美元的发热元件。
在安全系统中，应该将一些登录技术、自动分析技术和人类智能技术结合起来使用，以处理大多安全事件，这一点是至关重要的。但这种处理机制会引起安全系统或基本策略的变化。试想：你是一位大型高校网络的安全管理人员。在几周的时间内，你发现招生办公室中财务服务器的登录失败的次数大幅增多。在进一步调查之后，你发现登录失败来自网络其他部分的两台受到了入侵的系统。最终你发现它们遭到入侵的原因在于，运行在其中的域名系统（DNS）软件Berkeley Internet Name Domain（BIND）版本过期了。由于这个事件，你现在可能要执行几项任务。
重建这个遭到了入侵的系统，根据自己为系统设置的维护策略来重新培训相关操作人员。
追溯最初被入侵系统所受攻击的来源。
对财务服务器进行审计，以确保其没有受到未经授权的更改。
要考虑修改与访问财务服务器有关的安全策略，让网上的任何人都可以尝试登录这台服务器的决策有失明智。
在上述例子中，读者不难看出对于一些有问题的安全策略进行修改的时机，即有些修改工作往往是系统监控工作的最后一步。
注意 科技的进步日新月异。目前，很多系统声称自己可以将安全事件数据关联到另一个系统，并向操作人员就如何修改安全系统提供建议。如果这类系统的自动化程度和精确度能够得到提升，那么组织机构就可以考虑置入这些系统，因为它们可以削减对系统监控这项工作的投入，前提是组织机构在部署了这个系统后需要监控的数据类型不会发生变化。实际上，许多组织机构将来都会利用这类系统来扩展自己能够分析的信息范围，进而提高安全性，同时减少人力资源的投入。不过无论何时，各组织机构都要确保自己配备了充足的人手，这样不仅是为了确保安全事件数据能够得到检控，同时也是为了保证有人会对它们作出响应。如果你认为对这些数据进行过滤鲜有乐趣可言，那并不是你的问题。整个行业都面临着这个问题。第16章将进一步探讨这个主题。
系统维护是指确保系统能够可以随时修复最新安全漏洞的过程。可以说，与系统监控相比，系统维护的实现工作更加容易。系统维护的主要步骤如下。
第1步：确定有必要进行哪些修复，以及进行修复的频率。
第2步：在将其应用到当前系统之前对修复进行测试。
第3步：实施对当前系统进行的修复。
2．依从度检查
依从度检查往往是安全运行生命周期中最为有趣和最为实用的工作。主要原因在于，依从度检查可以让策略、标准和指导方针接受真正现实世界中的残酷考验。执行依从度检查是为了确保下列两件事情：
安全系统可以有效地满足安全策略的要求；
安全策略足以排除环境中出现的威胁。
这是两项独立但相互关联的任务。第一项任务很简单。在本章前面“实施安全策略的考虑事项”一节中已经从安全策略的角度对这一点进行过讨论。在这里，除了执行检查的是技术而不是人员之外，其他的过程和方法基本相同。你制定的策略是规定所有内部Web服务器只能在公司内部进行访问吗？好极了！在安全生命周期的依从度检查阶段，可以通过内部扫描、主机审计等技术来检查策略的落实情况。这些审计技术及执行这些技术的时间安排都是由组织机构决定的。每季度检查一次往往是比较合理的时间间隔。
对于安全操作团队来说，第二项任务往往比较有趣，但也会令人无地自容。这与前面详细讨论过的风险分析过程非常相似。安全操作团队必须尽力确保安全系统是最新版本的，而且已经修补了所有攻击者能够利用的最新漏洞。若要达到此要求，安全团队必须时刻留意攻击者的动向。即使资源有限，在SecurityFocus.com网站上订阅vuln-dev和BugTraq也不是什么难事。进一步说，定期浏览Insecure.org和PacketStormSecurity.org，然后估计一下这些网站所列出的攻击工具会对自己的环境产生怎样的危害。还需要定期在自己的网络中运行弱点扫描软件，如Nessus（http://www.nessus.org）。
警告 在当前网络中运行攻击工具（即使是那些想必没有负面影响的工具）时要非常谨慎。倘若使用不当，即使是端口扫描之类的简单工具也可以导致意外的后果。在运行中的网络上进行“检验”之前要在实验室中进行全面的测试。此外，AUP必须始终规定员工们不得在网络上使用任何攻击工具—永远禁止使用。
除了公司所采取的内部行动，定期请外部机构对自己环境的安全性进行评估也是非常有益的。一定要选择那些能够提供实际数据的机构，而不是那些“用纸宰人”的公司。外部评估的知情人越少越好。实际上，由网络部门之外的人所安排的评估最为有效。这样，包括本书读者在内的任何人都不会知道攻击是真实的还是模拟的。
无论内部检查还是外部检查的目的都是为了找到安全策略的漏洞，也就是找到那些你认为已经可以高枕无忧，但安全策略的漏洞却仍让虎视眈眈者有机可乘的地方。如果你的安全策略是在针对边界网关协议（Border Gateway Protocol，BGP）的新型工具开发出来之前制定的。那么既然市面上出现了这种新型工具，你就必须重新考虑BGP部署方案及其所有的相关事宜。因此，你就要修改安全策略所涉及的路由选择安全标准文档，要求不但要对每条BGP消息进行MD5认证，而且还要对入站和出站路由选择分布列表进行MD5认证。第6章中有更多关于路由选择安全方面的知识。
3．意外事件响应
安全运行生命周期的意外事件响应是一种大家都想尽可能避免的措施。虽然谁也无法保证自己的系统100%安全，但必须对意外事件作出响应常常意味着策略、安全系统、运行团队或基本的设想出了问题。实际上，安全意外事件可能发生得相当频繁，所以准备好可靠的方法来应对这些事件是很重要的。虽然下面所列的因素远不够全面，但读者可以从下列因素中可以了解到一些能够导致出现意外事件的状况。
安全系统未能抵御某种攻击，于是发生了这种攻击。
在业务需求中未能指出需要保护的关键系统，于是该系统受损。
新型攻击（往往称为零日攻击）命中了你的组织机构，而当前的安全系统未能阻止。
所指定的用户信任度有误，因此某个内部人员在未对其设防的情况下发起了攻击。
一台符合强化标准的主机遭到了外部组织机构的入侵。
如何执行意外事件响应不在本书的范围之内。司法诉讼往往涉及采证，因此要看这家机构是否有决心为了获得证据发起诉讼而停止系统运营，因此组织机构必须对整个问题有一个全盘的考虑。本章基本上将重点放在对意外事件作出响应所产生的结果对于整个网络的影响。
来看一个例子：1999年，很少有人考虑到网站会受到大规模拒绝服务（DoS）攻击。当时盛行的观点是，只要自己的带宽高于攻击者就不会出现太大问题。2000年2月，由于大规模DDoS攻击，这一观点随着用户无法访问Amazon、eBay、Yahoo！和其他公司而得到了改变。此次攻击不但对于所有受到泛洪攻击的组织机构是一次意外事件，对于发起泛洪攻击的傀儡系统同样也是一次意外事件。各组织机构不得不提出对策，以应对DDoS攻击，并将其整合到自己现有的安全系统中。
提示 安全技术人员只要时常更新自己的收件箱列表并且经常查看安全技术网站，就可以了解我所说的“免费意外事件”。免费的意思是这些意外事件并没有降临到你的头上，但你可以像真的发生了意外事件那样从这些信息中受益。就像我们在前面介绍的那样，由于看到那些遭受了攻击的公司所发生的事情，所有业务与网络息息相关的公司对DoS的态度全都发生了变化。
如第1章所述，安全系统的优劣在于其应对未知攻击的能力。也就是说，无论安全性有多高，在职业生涯中的某个时刻（通常会遇到数次），你还是不得不面对一些意外事件。作为安全系统设计人员，诀窍就是了解意外事件会带来哪些负面影响，以及如何有针对性地修改自己的设计，以在将来更好地处理这类事件。
如图2-1所示，安全运行阶段的变化会对安全系统及其下层的策略构成影响，而且往往会同时对它们构成影响。一般来说，在立刻对系统作出修改的同时也对策略进行修改往往对新的安全环境更为有利。作为安全系统设计人员，切忌只对系统进行修改而不修改安全策略，否则安全系统就会日渐背离你制定的安全策略。
