Asp的安全管理（9）

  
   
案例研究：遭受攻击

引言

一个很大的虚构银行企业分了好多个部门，其中两个分别为外部银行业务部门和内部支持部门。所有本地办公室都属于外部银行业务部门。所有的支持活动（例如市场、销售和 IT）都属于内部支持部门。为了使该企业赢利，这两个部门需要在工作中紧密合作。



不久前，IT 部门与某个 ASP 达成了一项协议，帮助它们引进新的银行解决方案。除了取钱和存钱外，客户应该可通过 Internet 执行所有的银行交易。而实际建立的解决方案甚至更加完善。因为要执行第一个解决方案，就必须访问所有客户帐户，同时将本地办公室连接到 ASP 以便对涉及客户帐户的信息进行检索和修改，似乎也是合乎逻辑的。



最后的网络设置如下所示。





如果您的浏览器不支持内嵌框，请单击此处在单独的页中查看。



在 ASP 和银行企业之间有一个未来一年的服务级别协议 (SLA)。该 SLA 中包括所涉及的“服务管理”问题（事件管理、更改管理、容量管理、可用性管理、应急规划和安全管理）。针对所有这些问题都规定了服务级别、报告时间以及 ASP 和银行双方的义务。



SLA 中的安全部分

在 SLA 的安全部分，银行和 ASP 就安全策略是什么以及在识别出安全事件时需要采取什么步骤，达成了一致的协议。并一起确定了一个沟通规划，以确保将以正确的方式通知所涉及到的每一个人。关于用什么工具来保护银行安全，还规定了一些技术问题。



攻击

某个星期一的早晨，本地办公室的一名职工发现获取帐户信息需要很长时间。因为知道星期一早晨总是出现与 IT 相关的问题，所以该职工没有太注意。他继续做其它的工作。过了一些时候，他听到同事们说他们在检索信息中也遇到了同样的问题。他们请教办公室里的 IT 高手，希望找到解决的办法。当 IT 高手报告说他的所有尝试都已失败时，已经到中午了。此时，与帮助台取得了联系。帮助台询问了一些必要的问题并记录下这个电话。双方都一致认为该事件的影响似乎很小（因为还可以检索到帐户信息），因此该事件只是被确定为低优先级。这就是说没人会马上着手开始解决该事件。



一个小时后，从任何本地办公室都无法检索帐户信息。测试还表明，客户无法通过 Internet 访问其帐户。到银行客户的界面实际上是被关闭了。由于在本地办公室中没有处理这种情况的紧急步骤，因此这意味着无法对客户提供服务。



银行马上与 ASP 取得联系，每个银行和 ASP 专家都投入到解决系统中断的工作中。一个小时之内，专家们找到了中断的原因：一种病毒进入了内部的 ASP 应用程序。该病毒生成了很多的数据包，充斥了整个网络，从而导致性能的下降。最后，ASP 的网络由于溢出而瘫痪。ASP 花了两个多小时来恢复帐户系统并使它重新运行。该银行由于这次事故损失了数百万美元。



错在哪里？

尽管该银行与 ASP 之间有一个 SLA，但是攻击者达到了让 ASP 的网络死机的目的，实际上使银行的运营瘫痪。



攻击的检测：由于星期一早晨发生了许多事件，所有的 ASP 管理员都忙于解决“重要的”问题而没有警惕警告系统。并且由于该银行组织中的用户习惯了这些现象，他们没有报告该事件，也许认为其它人已经报告。所以，没人意识到攻击正在进行的事实。



事件管理：ASP 的事件员工和本地办公室的职工都认为该事件的影响不大（还可以检索帐户信息）。记录该事件时，事件管理人员没有从 CMDB 得到启示，意识到该事件涉及到 CI（配置项目），它是该银行核心业务的一部分。对该事件的分类不正确。



应急规划：ASP 和银行受到系统中断的影响。也就是说两个组织的正常运作都被破坏。但是，本地办公室没有处理这些情况的紧急步骤。ASP 也没有执行紧急解决方案。



服务级别管理：由于系统中断，服务级别没有达到，这意味着是 ASP 要受到处罚。起草 SLA 时，ASP 没有考虑到可能的攻击以及这对商定的服务级别有什么影响。因为这种情况，该银行转向了另一个提供商。



如何改进？

ASP 需要改进他们向本地办公室和 Internet 客户提供的服务。由于星期一早晨经常出现有关 ASP 解决方案的事件，因此在这天中出现的任何事故都没有得到认真的对待。



ASP 需要提早在检测安全攻击的工具中安装更多的检测工具。对于网络性能超出正常情况的下降，必须立即进行分析。



银行和 ASP 的职工需要意识到事件的重要性，因此他们要及时将每次 IT 服务的不正常情况通报给 ASP 的帮助台。



ASP 的帮助台需要最新的“配置管理数据库”的支持，在该数据库中每个 CI 都标有一个可能的安全分类。这样，当关于某个 CI 的电话打来时，帮助台的员工将明白对该电话的处理必须遵照事件管理的安全步骤。



与所有涉及到的各方（银行、本地办公室和 Internet 客户）的沟通是幸免于这类攻击的至关重要的因素。从技术上解决攻击是一方面，从公众的观念上来解决要难得多。公众可能会记住该银行是“由于某种病毒而停止服务的公司”。应当建立良好的沟通规划以抵御这种损失。



需要采取安全措施来避免这样的攻击发生，或者至少在服务级别还没有陷于危险的早期阶段截断攻击的发展。可以选择如下措施：



让（职业的）黑客对安全措施进行测试，看它是否可以经受住各种各样的攻击

使用入侵检测盒

实施对性能的被动监视

对传入的数据包或邮件进行病毒或其它攻击的测试

起草 SLA 时若不考虑被攻击时应采取的措施，表明对现实很不了解。Gartner Group 的 J. Pescatore 在 2000 年 2 月做出了以下策略规划设想：“到 2003 年，百分之三十的 ASP 客户将经历 ASP 方面的安全事件，其结果是导致对敏感数据的损害（概率为 0.7）。” ASP 必须与客户讨论在这种情况下应该如何去做。他们需要明白可以达到什么样的服务级别，同时明白将会出现攻击。他们必须知道可采取什么对策使攻击之后的损失更小。这样做的时候，需要确定 ASP 和银行在这种情况下的任务是什么。      
   
      
   

……