不久前，IT 部门与某个 ASP 达成了一项协议，帮助它们引进新的银行解决方案。除了取钱和存钱外，客户应该可通过 Internet 执行所有的银行交易。而实际建立的解决方案甚至更加完善。因为要执行第一个解决方案，就必须访问所有客户帐户，同时将本地办公室连接到 ASP 以便对涉及客户帐户的信息进行检索和修改，似乎也是合乎逻辑的。
最后的网络设置如下所示。
如果您的浏览器不支持内嵌框，请单击此处在单独的页中查看。
在 ASP 和银行企业之间有一个未来一年的服务级别协议 (SLA)。该 SLA 中包括所涉及的“服务管理”问题（事件管理、更改管理、容量管理、可用性管理、应急规划和安全管理）。针对所有这些问题都规定了服务级别、报告时间以及 ASP 和银行双方的义务。
SLA 中的安全部分
在 SLA 的安全部分，银行和 ASP 就安全策略是什么以及在识别出安全事件时需要采取什么步骤，达成了一致的协议。并一起确定了一个沟通规划，以确保将以正确的方式通知所涉及到的每一个人。关于用什么工具来保护银行安全，还规定了一些技术问题。
攻击
某个星期一的早晨，本地办公室的一名职工发现获取帐户信息需要很长时间。因为知道星期一早晨总是出现与 IT 相关的问题，所以该职工没有太注意。他继续做其它的工作。过了一些时候，他听到同事们说他们在检索信息中也遇到了同样的问题。他们请教办公室里的 IT 高手，希望找到解决的办法。当 IT 高手报告说他的所有尝试都已失败时，已经到中午了。此时，与帮助台取得了联系。帮助台询问了一些必要的问题并记录下这个电话。双方都一致认为该事件的影响似乎很小（因为还可以检索到帐户信息），因此该事件只是被确定为低优先级。这就是说没人会马上着手开始解决该事件。
一个小时后，从任何本地办公室都无法检索帐户信息。测试还表明，客户无法通过 Internet 访问其帐户。到银行客户的界面实际上是被关闭了。由于在本地办公室中没有处理这种情况的紧急步骤，因此这意味着无法对客户提供服务。
银行马上与 ASP 取得联系，每个银行和 ASP 专家都投入到解决系统中断的工作中。一个小时之内，专家们找到了中断的原因：一种病毒进入了内部的 ASP 应用程序。该病毒生成了很多的数据包，充斥了整个网络，从而导致性能的下降。最后，ASP 的网络由于溢出而瘫痪。ASP 花了两个多小时来恢复帐户系统并使它重新运行。该银行由于这次事故损失了数百万美元。
错在哪里？
尽管该银行与 ASP 之间有一个 SLA，但是攻击者达到了让 ASP 的网络死机的目的，实际上使银行的运营瘫痪。
攻击的检测：由于星期一早晨发生了许多事件，所有的 ASP 管理员都忙于解决“重要的”问题而没有警惕警告系统。并且由于该银行组织中的用户习惯了这些现象，他们没有报告该事件，也许认为其它人已经报告。所以，没人意识到攻击正在进行的事实。
