第七章 - 回應意外事件

本頁索引

儘量降低安全性意外事件的次數和嚴重性
定義意外事件回應計劃
個案研究 – Northwind Traders 意外事件處理
摘要

  您的 IT 部門對於處理安全性意外事件的事前準備如何?許多組織只知道在遭受攻擊之後要如何回應安全性意外事件。但此時意外事件所導致的成本損失,可能已經遠遠超過它所應得。您最好將適當的意外事件回應,整合在整體的安全性原則和風險降低策略當中。

  回應安全性意外事件,能明確地看到直接的好處。其對財務也有間接的助益。比方說,如果您證明貴公司在正常情況下,能夠快速有效的處理攻擊行動,也許可以獲得保險公司所提供的折扣。或者,如果您是服務供應商,那麼提出一份正式的意外回應計劃,也許會幫助您贏得生意,因為這表示您有認真準備資訊安全性防護的處理。

儘量降低安全性意外事件的次數和嚴重性

  預防總是勝於治療,而安全性也不例外。無論在哪裡,您都得把預防安全性意外事件發生視為第一優先。不過,不怕一萬只怕萬一,如果真的發生安全性意外事件,也一定要把影響降到最低。下面是幾項嚴謹的安全措施,可以將安全性意外事件的次數和影響降到最低。其中包括:

  • **確實建立以及強制執行所有的原則和程序。**有許多安全性意外事件都是因為 IT 工作人員沒有遵守或了解變更管理程序,或是設定安全性裝置 (例如防火牆和驗證系統) 不當,而不慎發生。您必須徹底測試原則和程序,以確保它實用、清楚,而且達到適當等級的安全性。  
  • 取得安全性原則和意外事件處理的管理支援。  
  • 定期監視和分析網路流量和系統效能。  
  • **定期檢查所有的記錄和記錄機制。**其中包括作業系統事件記錄、應用程式專屬記錄,以及入侵偵測系統記錄。  
  • **定期審查環境受到攻擊的可能性。**這些動作必須由一位具有特殊證明的安全性專家來執行。  
  • 定期檢查伺服器,確保它們都有安裝所有最新版的補強。  
  • **針對 IT 人員和一般使用者,建立安全性訓練程式。**不管哪一個系統,最大的弱點都是天真無邪的使用者 — ILOVEYOU 病毒就非常有效地直攻這個弱點。  
  • **公佈安全性橫幅訊息,提醒使用者他們有哪些責任和限制;**同時也附帶警告訊息,警告他們可能會遭到哪些違規起訴。如果沒有這類橫幅訊息,可能很難 (或者根本不可能) 起訴犯人。您最好尋求法律建議,確保安全性橫幅訊息中的文字是否合乎法律規定。  
  • 要開發、實作和強制執行原則,必須具備複雜的密碼。  
  • **驗證備份和還原程序。**您必須知道要在哪裡維護備份,誰具有這些備份的存取權,同時還要確實掌握資料還原和系統復原的程序。記住,一定要定期做選擇性的資料還原,來驗證備份和媒體。  
  • **建立「電腦安全性意外回應小組」(CSIRT,Computer Security Incident Response Team)。**這是由一群負責處理任何安全性意外事件的人員所組成。CSIRT 的成員責任必須明確定義,不得遺漏回應當中的任何領域 (本文後面還會更詳細地介紹有關召集 CSIRT 的細節)。  
  • **訓練 CSIRT 的資訊安全性成員,讓他們妥善使用和置放重要的安全性工具。**您最好在膝上型電腦預先設定這些工具,以確保在安裝和設定工具來回應意外事件時,不浪費任何時間。這些系統和相關工具在不用時,都必須加以適當的保護。  
  • **集合所有相關的通訊資訊。**凡是組織當中需要通知的人 (包括 CSIRT 的成員,負責支援所有系統的人以及負責媒體關係的人),都得記下他們的姓名和電話號碼。同時,還要取得您 ISP 和當地及國家執法機關的詳細資料。最好在意外事件發生之前,先聯絡當地的執法機關。這將對您確實了解傳報告意外事件和收集證據的程序十分有助益。  
  • **將所有緊急系統資訊集中置於一個離線位置,例如實體筆記型電腦或離線電腦。**這些緊急資訊包括系統密碼、IP 位址、路由器設定資訊、防火牆規則設定清單、憑證授權金鑰副本、聯絡人姓名和電話號碼以及提升程序等等。這些資訊必須嚴加保護,而且能夠隨時使用。要保護這些資訊並且讓這些資訊能夠隨時使用其中一個方法,就是在專用安全性膝上型電腦上將這些資訊加密,並放在安全的儲藏地點,並且限制只讓經過授權的個人 (如 CSIRT 領導人和主要資訊辦事員或主要技術辦事員) 存取。

召集核心電腦安全性意外事件回應小組

CSIRT 是處理您環境當中電腦安全性意外事件的中心。其責任包括:

  • 監視系統,看看有沒有遭到安全性破壞。
  • 作為中央通訊點,同時負責接收安全性意外事件報告,以及將意外事件的重要資訊傳達給適當的單位。
  • 記錄安全性意外事件並加以分類。
  • 提高公司內部的安全性警覺,防止公司發生安全性意外事件。
  • 透過弱點稽核和穿透測試等程序,支援系統和網路審核。
  • 追蹤新的弱點以及攻擊者使用的攻擊策略。
  • 追蹤新的軟體補強。
  • 分析和開發新技術,將安全性弱點和風險降到最低。
  • 提供安全性諮詢服務。
  • 不斷更新目前的系統和程序。

  理想的 CSIRT 成員資格和結構,是根據貴公司的類型和您的風險管理策略而定,不過,CSIRT 通常就是貴公司的安全性小組全員,或者其中一部份。核心小組是由負責協調任何意外事件回應的安全性專業人員所組成。CSIRT 的成員數目,通常是根據貴公司的大小和複雜程度而定。但一定要足夠隨時應付所有的小組責任才行。

CSIRT 小組領導人

  CSIRT 必須要有一個負責活動的人。CSIRT 小組領導人通常就是負責 CSIRT 活動,以及協調活動審查的人。這一點可能會改變未來處理意外事件的原則和程序。

CSIRT 意外事件領導人

  在意外事件當中,必須有一個人負責協調回應。CSIRT 意外事件領導人具有特定意外事件或一組相關意外事件的所有權。所有與該事件相關的通訊,都是透過意外事件領導人加以協調,而且在與那些 CSIRT 以外的人對話時,他必須代表整個 CSIRT。「意外事件領導人」會根據意外事件的性質而有所不同,而且通常不兼「CSIRT 小組領導人」。

CSIRT 副成員

  與核心 CSIRT 小組一樣,您必須讓一些特定的人負責處理特定意外事件的回應。副成員是來自貴公司中不同的部門,具備安全性意外事件影響所及領域的專業知識,但不直接與核心 CSIRT 打交道。副成員可能直接參與意外事件,也可能是一個入口,負責委派責任給部門當中更適當的人。下表所列,是一些建議的副成員及其角色。

資料表 7.1:CSIRT 副成員

副成員 角色說明
IT 聯絡人 主要負責協調 CSIRT 意外事件領導人和 IT 群組其他人之間的通訊。這個人也許沒有特定的專業技術可以回應意外事件,但他們主要負責在 IP 群組當中尋找適當的人選,來處理特定的安全性事件。
法律代表  通常是公司內部的法律人員,非常熟悉既有的意外事件回應政策。法律代表可以判斷如何在意外事件當中,以最小的法律責任和最大的能力來起訴犯人。在意外事件發生時,法律代表必須負責監視和回應原則,確保公司在採取整肅或圍堵作業時,不必背負風險。他們必須考慮下面兩者的法律含意:關閉系統,但可能因此違反與客戶之間的服務等級合約或成員資格合約;或者不關閉受害系統,但必須擔負受害系統攻擊所導致的損壞。任何與執法機關以外,或外部調查機構的通訊,也必須與法律代表協調。
通訊人員 通常是公共關係部門的成員,負責保護和提升公司形象。他們不一定要直接面對媒體和客戶,不過他們要負責技巧的傳達訊息 (而訊息的內容和方針,通常由管理階層負責)。所有的媒體的詢問,都是直接由通訊人員處理。
管理人員 管理階層的範圍遍及部門到整個公司之間。適當的管理人員將根據影響力、位置、嚴重性以及意外事件的類型而不同。如果您有管理階層的聯絡人,就可以很快的找到最適合某些特定環境的人選。管理人員負責核准和指導安全性原則。同時也負責決定意外事件對於公司的總影響力 (包括財務和其他方面)。管理人員會指示通訊人員,哪些資訊應該透露給媒體,並且決定法律代表與執法機關之間的互動程度。

CSIRT 如何回應意外事件

在意外事件當中,CSIRT 會協調來自核心 CSIRT 的回應,並且與 CSIRT 的副成員通訊。下表所列的,是這些人在意外回應程序當中所擔負的責任。 資料表 7.2:CSIRT 在意外事件回應程序當中所擔負的責任

活動 角色



  CSIRT 意外事件領導人 IT 聯絡人 法律代表 通訊人員 管理人員
最初評定 擁有者 指示
最初回應 擁有者 執行 最新的 最新的 最新的
收集法庭證據 執行 指示 擁有者
執行暫時修正 擁有者 執行 最新的 最新的 指示
傳送通訊 顧問 指示 指示 執行 擁有者
詢問當地執法機關     更新者 最新的 執行 最新的 擁有者
執行永久修正   擁有者 執行 最新的 最新的 最新的
判定業務上所受到的財務影響   更新者 最新的 指示 最新的 擁有者
### 定義意外事件回應計劃   IT 環境的所有成員都應該知道,在意外事件發生時該採取哪些動作。在回應意外事件時大部份的行動是由 CSIRT 負責執行,而所有等級的 IT 人員要知道如何在內部報告意外事件。至於一般使用者則要直接向 IT 人員報告可疑活動,或者透過服務台 (而不是直接向 CSIRT) 報告。 意外事件回應計劃必須由所有的小組成員仔細審查,而且方便所有的 IT 人員存取。這是為了確保意外發生時,能採取正確的程序。 意外事件回應計劃應該包含下列幾個步驟: - 進行最初評定 - 傳達意外事件 - 制損毀/降低風險 - 確定受害的類型和嚴重性 - 保護證據 - 通知外部代理人 - 將系統復原 - 編譯和組織意外事件文件 - 評定意外事件的損失和成本 - 審查回應和更新原則 **請注意:工作輔助 4:「意外事件回應快速參考卡」可在意外事件發生時作為檢查清單,以確保所有的階段都有妥善執行。**   這些步驟並沒有絕對的先後順序。而是在整個意外事件過程當中都會發生。比方說,文件記錄一定是從意外事件開始就持續進行到事件結束為止,而通訊作業也是盤據整個意外事件的過程。 其他步驟則是彼此互動。比方說,在進行最初評定時,就大約知道攻擊行動的一般性質了。您必須利用這項資訊來抑制損毀,並且儘快將風險降到最低。如果動作夠快的話,就可以節省時間和金錢,並且挽救公司的信譽。但是,如果沒有更進一步的了解受害的類型和嚴重性,就無法有效抑制損毀並降低風險。過度熱心的回應,其損害甚至會比最初的攻擊更加嚴重。這兩個步驟彼此互動進行,就可以在快速和有效行動之間取得平衡。 **請注意:您一定要在意外事件發生之前,先徹底測試意外事件的回應程序。如果沒有經過徹底的測試,就無法確定您的措施是否能夠有效回應意外事件。** **進行最初評定**   您可以從許多活動看出貴公司可能會遭到攻擊。比方說,執行合法系統維護的網路系統管理員,與啟動某種攻擊的人看起來很類似。而設定不良的系統,也可能會讓入侵偵測系統出現許多假象,很難辨認哪些才是真正的意外事件。 **在進行最初評定時,最好能夠:** - 採取幾個最初的步驟,判斷您所面對的是真正的意外事件還是假象。 - 大致了解攻擊的類型和嚴重性。了解這一點之後,就可以傳達它進行更進一步的研究,並且開始抑制損害和降低風險。 - 徹底記錄您的動作。這些記錄會在稍後記錄意外事件 (不管是真還是假) 時用上。 **請注意:在儘量避免假象發生的同時,針對假象採取行動總比無法針對真正的意外事件採取行動來得好些。因此,最初評定要儘量簡單,但又能避免明顯的假象發生。** **傳達意外**   一旦您開始懷疑有安全性意外發生時,就應該迅速將破壞訊息傳達給核心 CSIRT 的其他人。意外事件領導人連同小組其他成員,也應該迅速找出核心 CSIRT 以外有哪些人需要聯絡。這是為了能夠妥善控制和協調意外事件,儘量將損壞降到最低。您要知道,損壞分為許多種,而且,被報紙以頭條新聞報導安全性保護遭到破壞,後果可能遠比許多系統入侵來得嚴重。因此,為了避免攻擊者接獲密報,在妥善控制之前,只有那些參與意外事件回應的人才會收到通知。根據這個原則,您的小組會在稍後判斷需要將意外事件通知哪些人。其範圍從特定的個人,到整個公司和外部客戶都有可能。 **抑制損壞和降低風險** 如果迅速採取行動,降低實際和潛在的攻擊破壞,還是有大事化小的可能。RFC 2196 針對抑制您的環境損害,定義了一系列的優先順序。真正的回應將視貴公司和所面臨攻擊的本質而定。但是,下面這些優先順序仍可做為一個起跑點。 1. **保護性命與人身安全。**這一點當然是第一優先。 2. **保護經過分類和 (或) 有安全顧慮的資料。**在規劃意外事件回應時,最好能夠清楚定義哪些資料是經過分類的資料,哪些資料是有安全顧慮的資料,這能夠讓您為保護資料所做的回應排出優先順序。 3. **保護其他資料,其中包括才專屬、技術和管理方面的資料。**環境當中的其他資料也可能很有價值。您應該先從最有價值的資料保護起,行有餘力再保護其他用途稍低的資料。 4. **保護硬體和軟體來對抗攻擊。**其中包括保護系統檔案,不讓它們遺失或被變更,以及保護硬體降低實際損失 系統損壞可能會導致成本極高的停擺。 5. **儘量避免運算資源 (包括處理程序) 的中斷。**雖然在大部份的環境下存留時間相當重要,但是在受到攻擊時讓系統保持在啟動狀態,很可能會在日後導致更大的問題。因此,儘量降低運算資源的中斷次數,通常是擺在後面。 下面是幾種在您環境下抑制損毀和降低風險的方法。您至少要: - **儘量避免讓攻擊者知道您已經注意到他的活動。**不過這一點不太容易,因為有些必要的回應難免會透露一些警訊給攻擊者。比方說,如果 CSIRT 召開緊急會議 ,或者要求立即更改所有密碼,那麼攻擊者就知道您已經警覺到意外事件了。 - **比較讓受害和相關的系統離線與繼續作業的風險,哪一種方式的成本較高。**在大部份的情況下,應該採取立即讓系統離線的做法。但是,有的服務合約卻要求即使有發生進一步危險的可能,系統還是要保持在啟動狀態下。在這種情況下,您可以選擇保持部分系統連線,以便在繼續受到攻擊期間收集其他證據。 有時候,意外事件的損壞程度和範圍,已經逼得您不得不採取行動,即使接受服務等級合約所指定的懲罰也在所不惜。不管是哪一種情況,您在意外事件發生時所採取的動作都要經過事先討論,而且在回應計劃當中提及,這樣,一旦發生攻擊時才能立即行動。 - **判斷攻擊者所用的存取點,並執行方法來防止進一步的存取。**這些措施包括:停用數據機,在路由器或防火牆加上存取控制項目,或者增加實際安全性措施。 - **考慮以新硬碟重建全新的系統 (最好取出現有的硬碟放在儲存體當中,如果決定要起訴攻擊者時,那麼這些都可以作為證據)。**一旦遭到攻擊之後,一定要更改所有的本機密碼。最好連同環境當中其他部分的系統管理和服務帳戶密碼也一併更改。 **確定受害的嚴重性**   如果要有效復原,必須判斷系統受害的嚴重性。這是為了判斷如何進一步的抑制和降低風險,如何復原,如何快速地將意外事件傳達給誰,以及是否要尋求法律賠償。 您最好採取下列行動: - 判斷攻擊的性質 (這可能與最初評定時所建議的不一樣)。 - 判斷原始的攻擊點。 - 判斷攻擊的意圖。攻擊行為是隨機攻擊,還是為了取得特定資訊而針對貴公司下手? - 找出受害的系統。 - 找出已被存取的檔案,判斷那些檔案的敏感度。 在執行這些動作時,您就可以找出適合您環境的回應。好的意外事件回應計劃,要寫明特定的執行程序,在您進一步了解攻擊行動時執行。通常,攻擊症狀的性質就會決定執行計劃所定義的程序順序。時間就是金錢,越省時的程序,一定是排在耗時的程序前面。您可以利用下列方式,判斷受害的嚴重性: - 聯絡回應小組的其他成員,告知您的發現,請他們驗證您的結果,判斷他們是否知道相關行動或其他可能的攻擊行動,然後指出意外事件是不是假象。有時候,在最初評定判斷為真正的意外事件,後來都證實只是假象一樁。 - 判斷是否有未經授權的硬體已經連上網路;或者是否有任何跡象顯示,有透過破壞實體安全性控制來進行未經授權的存取。 - 檢查主要群組 (網域系統管理員和系統管理員等),看看有沒有未經授權的項目。 - 搜尋安全性評定或開發軟體。在收集證據時,常常會在受害的系統當中找到破解公用程式。 - 尋找目前執行中 (或者利用啟動資料夾或登錄項目設定要執行),但未經授權的處理序或應用程式。 - 在系統記錄中搜尋漏洞或遺失。 - 審閱入侵偵測系統記錄,看看有沒有入侵的跡象,哪些系統已經受害,攻擊方式,攻擊的時間和長度,以及可能招致的整體損失。 - 檢查其他記錄檔案,看看有沒有不尋常的連線,安全性稽核失敗,不尋常的安全性稽核成功,嘗試登入失敗,登入預設帳戶的意圖,非工作時間的活動,檔案、目錄和共用許可權的變更,以及提高或變更的使用者權限。 - 將系統和先前的檔案/系統整合檢查進行比較。這是為了找出檔案系統和登錄的新增、刪除、修改以及許可權和控制權的修改。如果您正確找出受害的部份以及需要復原的區域,那麼在回應意外事件時,可以節省不少時間。 - 搜尋為日後擷取/修改方便而移走或隱藏的敏感資料 (例如,信用卡號碼和員工或客戶資料)。系統也可能需要加以檢查,看看有沒有非商業的資料,如色情圖片 (除非您所經營的正是色情圖片行業)、非法軟體盜版以及電子郵件或其他可以協助調查的記錄。如果有藉著調查為名目來搜尋系統,而違反隱私權或其他法律的可能性,最好先聯絡法律部門再繼續行動。 - 將可疑系統的效能,核對它們的基準效能層級,看看是否吻合。當然前提是比較基準必須已經建立而且妥善更新。有關建立效能基準的詳細資訊,請參閱《Windows 2000 Professional Resource Kit 》(Microsoft Press, ISBN:1-57231-808-2} 第 27 章〈Overview of Performance Monitoring〉。 在判斷哪些系統已經受害以及如何受害時,通常會將您的系統與該系統在受害之前記錄的比較基準互相比較。假設最近的系統快照足以用來比較,但如果前一個快照是來自一個已經受到攻擊的系統,那就很難了判定了。 **請注意:像 EventCombMT、DumpEL 和 Microsoft Operations Manager 這類工具,都可以幫助您判斷系統受到攻擊的程度。協力廠商的入侵偵測系統,可以事先發出攻擊警告,其他工具也會顯示系統上檔案變更的情況。有關這些工具的詳細資訊,請參閱第 6 章〈稽核與入侵偵測〉。** **保護證據**   有時候,如果環境已經受到蓄意攻擊,您可能得採取法律行動來對付這些惡徒。不過在行動之前,必須收集足以對付他們的證據。您一定要儘快在採取任何會影響原始媒體資料完整性的行動之前,將受害的系統做備份。您得找一個熟悉電腦法律知識的人,以從未使用的全新媒體,為整個系統至少製作兩份完全一樣的備份。至少要有一個備份是儲存在寫一讀多的媒體,如 CD-R 或 DVD-R。這個備份只能在起訴罪犯時使用,而且在使用之前,都必須受到嚴密的保護。另一份備份則可以用在資料復原。這些備份只能用在法律用途,因此必須嚴密保護。您也得記錄備份的相關資訊,例如由誰備份系統,什麼時候備份,如何保護這些備份,以及誰有權存取它們。   備份一旦執行之後,就要取出原始硬碟機,將它們放在真正安全的地方。這些硬碟機在起訴時,可以作為法庭證據。新的硬碟機則用來還原系統。   有時候,保留資料的好處,不一定比得上延遲回應和系統復原所付出的成本。您應該將保留資料的成本和好處,與更快速復原每一個事件的成本和好處做個比較。   對於超大型的系統而言,要把所有受害的系統巨細靡遺的備份,似乎不太方便。這時候,您應該備份所有的記錄,並選擇系統中受害的部份加以備份。   可能的話,也將系統狀態一併備份起來。您可能得等上幾個月甚至幾年的時間才能起訴,因此一定要儘量收集意外事件的詳細資訊,以備日後之需。   起訴網路罪犯最困難的部份,通常是以提交證據相關之專屬裁判法所能接受的方式,來收集證據。因此,法庭程序最重要的構成要素,就是完整而詳細地記錄如何處理系統,由誰處理,以及何時處理,來示範可靠的證據。請在文件的每一頁簽名,並且標示日期。   一旦具有經過驗證的現用備份,就可以把受到感染的系統清掃一番,重新建立它們。這能讓您快速的備份和執行。而提供重要、完美的起訴證據,完全要仰賴此備份。另外,除了法庭備份之外,您還要另外準備一個備份來還原資料。 **通知外部機構**   待控制意外事件,且保留起訴所需的資料之後,就可以通知適當的外部單位了。這些外部機構可包括當地和國家的執法機構,外部安全性機構,以及病毒專家等。外部機構可以提供技術協助,提供更快速的解決方案,以及提供從類似意外事件取材的資訊,幫助您從意外事件完全復原,並且防止日後再犯。   對於某些工業和破壞類型來說,可能會需要特別通知客戶和 (或) 一般大眾,尤其如果客戶也是直接的受害者。 如果意外事件導致財務受到影響,可能必須將事件上報執法機構。   如果是更高層的公司和意外事件,可能還會牽涉到大眾媒體。因安全性意外吸引媒體注意並非好事但又無法避免,遇到這種情況時,最好由公司積極主動的傳達意外事件。意外事件回應程序至少要清楚定義,誰有權向媒體代表發言。一般說來這都是貴公司公共關係小組的人。他們在面對媒體時最好不要否認意外事件發生,因為這麼做只會更加傷害自己的信譽,倒不如主動承認和積極回應來得妥當。但這不表示不管事件的性質或嚴重程度如何都要一一通知媒體。您還是要把每一個事件當作一個個案加以分析,再尋求適的當的媒體回應。 **將系統復原** 系統復原的方式,通常是根據安全性破壞的範圍而定。您必須判斷自己是否能夠將現有的系統幾乎原封不動地還原到原始狀態,或者是否有必要完全重建系統。   當然,還原資料的前提是,您必須擁有乾淨的備份 — 也就是說,在事件發生之前所做的備份。您可以利用檔案整合軟體找出第一個損壞的地方。如果軟體警告您檔案被更動,那麼就表示您在該警示訊息之前剛做的備份是好的備份,最好保留下來在重建受害系統時使用。   有時候,當您發生意外事件時,資料已經被它損毀好幾個月了。因此在意外事件回應程序當中,一定要判斷意外事件的經歷時間 (您可以用檔案/系統整合軟體和入侵偵測系統加以協助)。有時候,最新或甚至好幾個備份,都不足以回溯到乾淨狀態,因此最好能夠定期將資料備份保存在離線位置。 **編譯和組織意外事件文件**   CSIRT 在面對任何意外事件時,最好能夠徹底記錄所有的程序。其中包括說明破壞行為,以及詳細記錄每一個採取的行動 (誰採取這個行動,何時採取,以及背後的原因)。在回應程序當中,所有存取和涉及的人都必須全數記錄。而且要按時間順序加以組織,檢查它是否完整,再由管理人員和法律代表簽名和審閱。同時,您也必須嚴密保護在保護證據階段所收集的證據。最好每一個階段都能保持兩個人同時在場,而且這兩個人都可以在每一個步驟登出。這是為了減少證據不被承認的可能性,同時也減少證據在事後被修改的可能性。   請記住,罪犯很有可能是貴公司內的任何一名員工、臨時人員、簽約員工或其他內部人員。如果沒有詳細徹底的記錄,要指證一名內奸可沒那麼簡單。同時,適當的文件記錄也可以幫助您起訴罪犯。 **計算意外事件的損失和成本** 在判斷貴公司的損失時,要考慮直接和間接兩種成本。其中包括: - 由於敏感資訊或公司專屬資訊曝光而失去競爭力,所導致的損失。 - 法律成本 - 分析破壞情形、重新安裝軟體以及將資料復原所需要的勞力成本 - 與系統停擺有關的成本 (例如,員工停產、業績下跌、換掉軟體、硬體和其他財產) - 因修復和更新受損或無法運作之實際安全性設備 (鎖、牆、籠等) 所產生的成本 - 其他後續損失,如信譽受傷或者失去客戶信任等 **審閱回應和更新原則**   待記錄階段和復原階段完成之後,接下來就是徹底審閱處理程序了。您可以和小組討論,一共順利完成了哪些步驟,以及犯了哪些錯誤。然後找出程序中需要修改的地方,以備日後面對意外事件時,能夠更完善的處理。 ### 個案研究 – Northwind Traders 意外事件處理   為了清楚說明如何在不同的意外事件回應階段處理攻擊行動,我們設計了一個個案研究,示範 Northwind Traders CSIRT 小組對於感染 Code Red II 病毒所做的回應。雖然這是虛構的個案,但其中所採取的對策,卻密切反映了真實公司在面對攻擊時的情形。 資料表 7.3:Northwind Traders 個案研究
意外回應步驟 採取的行動
進行最初評定 Samantha Smith 是一個待機傳呼的 CSIRT 成員,她收到一則呼叫簡訊,記錄了 Northwind Traders 入侵偵測系統所記錄的事件。系統指出 Web 伺服器 WEB2 上有疑似 Code Red II 的意外事件發生。她在 WEB2 的 IIS 記錄檔中尋找簽名字串,並且檢查 c:\inetpub\scripts 是否有 root.exe 存在。調查結果強烈顯示這不是假象。
傳達意外事件 Samantha 以電話通知 CSIRT 其他人,告知她自己的最初發現,並且同意持續追蹤新的進展。
抑制損毀和降低風險 Northwind Traders 的意外事件回應原則提到,要驗證是否有病毒存在,必須將該系統從網路移除。於是 Samantha 移除了網路線。還好,WEB2 只是一組負載平衡伺服器的一部份,因此客戶不會因為斷線而停擺。
確定受害的嚴重性 Samantha 掃描了其他伺服器的記錄檔,判斷該病毒是否已經蔓延。結果發現還沒有。
傳達意外事件 Samantha 以電子郵件將這些發現傳達給 CSIRT 的其他成員,並且直接聯絡 CSIRT 領導人。
CSIRT 領導人指派 Mike Danseglio (資訊安全性經理) 為意外事件領導人。Mike 與核心 CSIRT 互相協調所有的活動和通訊。
同時通知技術總監和待機傳呼的資訊技術小組,Web 伺服器已經與網路斷線,必須等到病毒清除之後,才會再次連線。Mike 也通知執行管理人員、通訊人員和法律代表。法律代表則通知 Mike,雖然不可能提出控訴,但還是希望依照程序來收集證據。
抑制損毀和降低風險 另一個 CSIRT 成員 Robert Brown 則執行 Hfnetchk,看看其他伺服器是否都有 Code Red II 的補強程式。他發現有兩個伺服器還沒有更新,於是立即套用補強程式。
確定受害的嚴重性 Robert 更進一步的掃描其他所有 IIS 伺服器的記錄檔,看看還有沒有 Code Red II 存在。
保護證據 每一個徵兆都指出,WEB2 已抑制了損毀。由於損毀情形已被妥善抑制,而法律代表也指示要收集證據,因此 Mike 決定在對系統進行干預性的分析之前 (這些動作可能會干擾或破壞證據),先收集證據。其他小組成員則繼續監視其他 Web 伺服器和記錄,看看有沒有可疑的活動。
一個受過收集法庭證據訓練的 CSIRT 成員,建立了兩個受害系統的快照。其中一個快照被小心保存,以供日後法庭審查時使用。另一個快照則在復原程序當中,與事件發生前所製作的乾淨、安全備份一起使用。法庭備份是自從未用過的單次寫入媒體所製作,它依照安全性原則被審慎記錄,而且與伺服器的硬碟一起密封,受到安全的保護。
確定攻擊行動的類型和嚴重性 含有許多法庭工具的公司安全性工具箱膝上型電腦,是用來審閱復原備份,看看有沒有其他地方受害。登錄項目和資料夾則是用來審閱,看看在啟動時執行軟體 (如 profile/startup 目錄,以及 Run 和 RunOnce 登錄機碼) 的區域,有沒有其他傷害。 使用者和群組帳戶也要與使用者權限和安全原則一併審閱,看看有沒有做過任何修改。
通知外部機構 Northwind Traders 參與了許多大型的美國政府專案,因此 Mike 將意外事件報告給 FBI 的「國家基礎建設保護中心」(National Infrastructure Protection Center)。.
由於客戶資訊或系統存取都沒有受到連累,因此並沒有通知客戶。
將系統復原 雖然有工具可以從 WEB2 清除 Code Red II,但還是需要推舉 CSIRT 和 WEB2 支援小組,將作業系統重新安裝在新的媒體。將來自原始分配的作業系統重新安裝在新媒體,是為了取得未經任何駭客染指或檔案損毀的乾淨系統。
Windows 2000 重新安裝之後,再依照指南前一章所指定的指示進行,即可增加系統的安全性保護。
接著找出未經感染的備份,然後小心謹慎地還原資料。如果只有受害備份具有這些資料,則將它還原到另一個離線系統,然後在清潔過後,重新併入 WEB2,這時候它就沒有危險了。
接著由 CSIRT 小組針對記錄所有在程序當中發現資訊的系統,完整的審查該系統的弱點評定。
然後將WEB2 重新連線,並且密切監視。
編譯和組織意外事件記錄 Mike 和 CSIRT 研究受害的原因,判斷是因為系統最近重新安裝時,沒有套用補強程式之故。這一點與已經妥善且明確定義的原則不符。這個事件是在下列三個地方爆發:支援小組成員沒有重新套用補強程式,資訊安全性部門沒有即時稽核套用的補強程式,以及配置管理群組沒有指出需要套用補強程式,並且請資訊安全性部門一起檢查系統,再繼續運作。其實只要執行了上述任何一個程序,都可以防止這項意外事件發生。
小組決定執行新的程序,以防止同樣的事件再次發生。接著在資訊安全性部門將任何系統連線或重新連線到內部網路之前,要由變更管理部門、Web 伺服器支援部門以及資訊安全性部門合力完成一份檢查清單。這個檢查清單程序必須在資訊安全性部門重新配置防火牆,讓內部人員來回存取這個系統之前完成。稽核部門也要定期審查這些檢查清單是否精確且完善。
Mike 和 CSIRT 編譯所有的文件,看看到底完成了哪些意外事件專屬作業,每一個作業在什麼時候執行,以及由誰執行。這些資訊會傳給財務代表,讓他們根據「通用帳戶原則」,來計算電腦損失的成本。CSIRT 小組領導人要確定管理人員了解該事件的總成本,事件為什麼發生,以及打算如何防止它再度發生。管理人員則一定要查看有沒有未依照程序,以及未將資源 (如 CSIRT) 妥善就位的事項。
整體的意外事件記錄,從中獲取的教訓,以及遵守及未遵守的原則,都會由適當的小組成員加以審查。
有關尋法律途徑的記錄和程序,則由法律代表、 CSIRT 小組領導人、意外事件領導人以及執行管理人員加以審查。

摘要

本指南多半在討論如何將受到攻擊時的風險降到最低。但是,處理安全性最好的方法是儘量降低受到攻擊的機會,然後再假設您會受到攻擊。這個程序的其中一部份,是小心稽核攻擊行動,這一點我們已在第 6 章加以討論。另一個同樣重要的部份,是如果真的受到攻擊,要如何妥善做出明確定義 (事前充分排練) 的回應。

相關主題

《Hacking Exposed Windows 2000》,作者:Joel Scambray 和 Stuart McClure (McGraw-Hill Professional Publishing, ISBN:0072192623} 美國電腦安全研究協會 (Computer Security Institute,www.gocsi.com) — 發表一篇年度學術研究,題名〈Computer Crime and Security Survey〉

其他資訊

回到頁首