不久前，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 和銀行在這種情況下的任務是什么。
