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