瞭解安全性風險管理法則
Overview
發佈日期: 2004 年 10 月 15 日 | 更新日期: 2006 年 3 月 15 日
本頁內容
本單元內容
目標
適用於
如何使用本單元
簡介
安全性風險管理與安全性架構作法
安全性風險管理架構
安全性風險管理法則
安全性風險追蹤、規劃、排程及報告
安全性風險補救發展
安全性補救測試
吸取安全性知識
總結
其他資訊
本單元內容
本單元概述已證實之風險分析及管理的方法。它利用 Microsoft® Solutions Framework (MSF) 及 Microsoft Operations Framework (MOF)，提供在您組織中建立安全性管理原則的指引及建議。藉由正確地對風險加以識別、分類及量化，您可以採取最合適及最合乎成本效益的行動，來確保您環境的安全。您也可以將安全性原則及程序的開發整合到資訊技術 (IT) 基礎結構的開發生命週期。
目標
透過此單元即可：
對您的環境風險進行識別及量化。
對您的組織資產價值進行識別及量化。
使用這些量化的值，識別出保護環境所需最合適且最合乎成本效益的活動。
定義及管理正式的安全性風險管理原則。
將安全性風險管理整合到您的 IT 基礎結構生命週期。
透過反覆的風險管理週期，定義可發展出您組織之風險管理專門知識的程序。
適用於
本單元適用於下列產品及技術：
- 所有 IT 基礎結構
如何使用本單元
使用本單元，提供您適合組織正式安全性風險管理原則的開發與整合的指引。
若要充分瞭解本單元：
閱讀本單元之前的單元＜定義 Windows 2000 安全性前景＞。當中會介紹本單元中所使用的術語，並提供安全性問題的概觀。
閱讀本單元之後，請參閱本單元最後一節＜其他資訊＞所列的資源，以取得特定問題的相關指引。
簡介
本單元利用現今運用 Microsoft Solutions Framework (MSF) 及 Microsoft Operations Framework (MOF) 中的安全性分析方法中已證實的作法。有關在企業架構及基礎結構部署範疇中規劃、建立、穩定及部署專案生命週期的階段，MSF 提供一些指引。MOF 提供如何針對資訊技術 (IT) 作業開發或增進管理系統的相關建議。有關 MSF 或 MOF 的明細，請參閱本單元結尾之＜其他資訊＞一節。
本單元定義了三個主要的指引程序： 從安全性專案生命週期中所發生的風險管理活動來看，是指「安全性風險管理法則 (SRMD)」及「安全性風險架構」。
組織可以利用三種主要的程序，來定義保護其安全所需進行的作業，以及保持安全的方式。下列定義了這些高層級的主要程序。
評估 此階段涉及到從公司的環境中收集一些相關的資訊，以執行安全性評估。必須獲得足夠的資料，才能有效地分析目前的環境狀況，然後再判斷組織的資訊資產對於可能的威脅所受到的保護程度。除了安全性評估之外，之後還會建立「安全性行動計劃」，以便在實作過程中執行。
開發與實作 此階段著重在執行「安全性行動計劃」，以實作對評估中所定義環境而建議的變更。除了「安全性行動計劃」之外，還開發了「安全性風險緊急應變計劃」。
運作 此階段涉及到針對環境進行一些修改及更新，以符合讓環境保持安全的需求。在運作過程中會執行滲入測試及意外事件回應策略，如此可以協助加強組織安全性專案實作的目標。在運作過程當中也會執行稽核及監視活動，讓基礎結構未受到損害並且受到保護。
安全性風險管理與安全性架構作法
在安全性計劃執行期間，有兩種風險管理活動會在專案生命週期中進行。第一種會管理沿自專案本身的風險，而第二種會管理與安全性元件相關的風險。專案風險只會在專案生命週期中評估，而安全性風險必須在整個解決方案或系統的生命週期中評估。「MSF 風險管理法則」可當作管理專案及安全性評估風險的基礎。安全性風險管理的指示性範例會進一步在本指南的＜套用安全性風險管理法則＞中說明。
在本解決方案指引中，會定義「安全性風險管理法則」，其是從「MSF風險管理法則」衍生。為了明顯區隔這兩種活動，在專案風險內容中會說明 RMD，而 SRMD 則是指安全性風險評估活動。RMD 會被當成開發 SRMD 的主要工具來使用。
RMD 及 SRMD 兩種程序在整個專案及環境運作中都提倡主動的方式、持續性的風險評估以及與決策的整合。
電腦系統安全性應主動且持續地進行，以確保資訊資產的安全性，以及監視新的威脅及弱點。每當您將新的功能加到您組織的技術基礎結構中時，一定要考慮到資訊的安全性。此外，有一些商業處理及程序可能也需加以更改，以便在修改過的環境中運作，並對這些新的資訊資產提供保護。
「安全性風險管理法則」中的九個步驟是：
評估
資產評估及估價
識別安全性風險
安全性風險之分析與優先處理順序
安全性風險追蹤、規劃及排程
開發與實作
安全性補救開發
安全性補救測試
獲取安全性知識
運作
重新評估全新和變更的資產與安全性風險
穩定及部署全新和變更的因應對策
這些步驟在 SRMD 當中具體呈現為下列三個主要階段： 評估、實作及運作。
評估
以下各節將組織評估作業合併成安全性分析開始的基礎。資產評估及驗證是朝向安全性分析的首要步驟，因為必須先瞭解您開始著手的項目，才能評估接著而來的風險。此安全性分析程序是一組策略，目的是讓您判斷哪些資產在您的環境中值得受到保護，以及您要對其進行安全性保護的優先順序。
資產評估及估價
資產評估是在與相關實體有關資訊上所估的價值，以及要花什麼樣的心力來發展此資訊。而估價則是在於需花多少成本來維護資產、在資產流失或遭破壞時代價為何，以及當他人取得此項資訊時會得到什麼好處。資產的價值應反映出，當資產受到實際的損害時，可能導致的所有可識別出來的損失。
安全性風險識別
安全性風險識別可以讓專案小組成員對可能發生的安全性風險進行腦力激盪及討論。收集有關威脅、削弱點、利用及因應對策的資訊。
安全性風險分析
安全性風險分析是用來分析可能用於利用潛在削弱點的潛在攻擊、工具、方法及技術。安全性風險分析是識別風險及評估可能的損害而促使安全性預防的調整。
安全性風險分析有三個主要的目標： 識別風險、將潛在威脅的影響量化，以及風險的影響與因應對策成本之間提供經濟平衡。所收集的資訊是用來評估風險的層級，以便讓小組針對哪些安全性風險應多加補救，做出明智的決策。
此項分析接著會用來排列安全性風險的優先順序，讓您的組織可以將資源用來解決最重要的安全性問題。
風險分析可以協助將安全性計劃目標與公司的商業目標及需求整合在一起。您的商業與安全性目標愈緊密地整合，您的組織在完全實現這兩個目標上就會愈成功。
此項分析也可以協助您的公司草擬出適合的安全性計劃預算，以及構成該計劃的安全性元件。一旦您知道貴公司的資產有多少價值，而且您也瞭解它們可能蒙受的威脅之後，就可以對保護那些資產要花多少錢作出明智的決定。
安全性風險追蹤、規劃及排程
安全性風險追蹤、規劃及排程會採用從安全性風險分析取得的資訊，並將它用來制定防治及預防緊急狀況的策略及達到這些策略的計劃。安全性風險排程則會試著針對安全性專案建立階段時所建構的各種補救策略，定義時程表。此時程表對於安全性計劃核准的方式，與如何併入資訊架構，以及必須實作的標準日常運作程序列入考量。
開發與實作
您在評估過程中執行的工作，可以讓您實作適當的因應對策發展及實作。評估過程的結果，提供簡單的轉變，以實作有效的因應對策部署及安全性學習策略。
安全性風險補救發展
安全性風險補救發展是採用「評估」階段建立的計劃，並利用它們來建立有關設定管理、修補程式管理、系統監視與稽核，以及操作原則與程序的新安全性策略的過程。隨著各種不同因應對策的發展，確保對此進度進行徹底的追蹤及報告是十分重要的。
安全性風險補救測試
安全性風險補救測試會在已進行補救策略發展及相關系統管理變更，並在撰寫出判斷其效益的原則與程序之後進行。測試程序可讓小組考量如何將這些變更部署到生產環境中。在測試過程中，會針對控制安全性風險的程度，進行效益因應對策的評估。
安全性風險學習
安全性風險學習將擷取有關小組如何保護資產的知識，以及記錄已探查到的弱點與削弱點的過程加以形式化。在 IT 部門學習的同時，必須獲取及重新部署新的安全性資訊，才能持續最佳化保護公司資產之安全性因應對策的效率。此外，還必須透過訓練或安全性感測佈告欄，為商業社群舉行安全性教育。
**注意：**這些步驟只是提供邏輯性的指導，並不需要逐字逐句加以遵循以專注在特定的安全性風險。安全性小組在針對其特定資訊資產的安全性問題、威脅及弱點發展出經驗前，會經常需要重複這些識別、分析和規劃的步驟。
您的組織必須定義一個正式的風險管理程序，以闡明如何開始及評估安全性因應對策，以及在什麼樣的情況下應該針對個別或一組安全性風險採取哪些轉換步驟。
運作
穩固而一致的運作週期可提供您的安全性小組一個能產生可靠且可預測結果的機制。藉由在安全性專案的早期執行評估程序，小組可以更加瞭解如何重新評估您整個企業中全新及變更的資產。針對全新及變更的資產，執行穩定及部署新因應對策或變更的因應對策，於是成為貴公司日常操作的一部份。
重新評估全新及變更的資產與安全性風險
雖然這些程序是必要的變更管理程序，但這也是執行安全性設定管理的所在。這可在完成新的因應對策及安全性原則時，導致成版本管理。
穩定及部署全新或變更的因應對策
在運作階段中，這些程序是由系統管理、安全性管理及網路管理小組所管理。服務監視、服務控制及工作排程是運作階段中的一些額外程序，而在運作階段中，安全性系統管理員會執行全新及改善過的因應對策。
安全性服務台、意外事件管理，以及問題管理學習
在支援階段中，IT 組織中的運作小組可透過安全性服務台及控制的意外事件和問題提升管理當中的健全安全性管理，來支援安全的環境。
服務等級、財務及可用性管理
MSF 及 MOF 是一些經證實的作法，專為協助您發展、部署及維護強大的安全性管理計劃而設計。若能順利地利用這些經證實的作法，則可以建立能提供資源之完整性、機密性與可用性的環境。
安全性管理是透過對服務等級管理、財務管理、服務社群管理、可用性管理、容量管理，以及人力管理進行妥善管理而最佳化。
安全性風險管理架構
概觀
此架構並非制定一套特定的程序，相反地它有足夠的彈性可以接受廣泛的 IT 程序。此架構並非制定一套特定的程序，相反地它有足夠的彈性可以接受廣泛的 IT 程序。此程序模型包含從專案開始到當前部署之解決方案的生命週期。
.jpg)
[圖 1] 按階段劃分的安全性架構程序模型里程碑
MSF 可以用來開發軟體應用程式及部署基礎結構的技術。此程序模型遵循的重複性週期，是設計用來透過簡短的開發週期及遞增的解決方案版本，以因應專案需求變化。而持續不斷的風險管理及測試週期使這成為可能。
許多有關專案的關鍵問題都在程序模型當中的每個里程碑提出、解答或討論過，例如：小組是否同意專案範圍？ 小組是否已計劃周全來進行？ 小組是否已建立其討論要建立的事項？ 對於您組織的客戶及合作夥伴，解決方案是否可以正常地運作？ 下列與上圖有關之安全性專案的六個主要程序將在此進行簡要的討論。
開始專案定義
專案的初始階段將提出成功安全性專案其中一個最基本的需要：統一專案小組及安全性計劃。小組的初始程序會持續到初始階段最後的精簡部份。所有小組成員都必須對他們在安全性解決方案想要達成什麼目標，以及有關安全性的商業需求有清楚的觀察。此階段著重在識別出安全性管理相關的商業問題或機會。所有涉及安全性管理的人都必須在這些程序期間定出目標、前提及限制。安全性評估及分析
安全性管理的評估及分析是在 MSF 方法之規劃階段中所進行的程序。這些程序包括組織評估、資產價值評定、威脅識別、弱點評估及安全性風險評估。它們也一起構成了與成功的因應對策部署密切關聯的規劃。從安全性評估及分析階段所採納的意見，創造出了一套安全性補救開發的方法。在這些程序中，開發人員會不斷地在因應對策的開發、測試及驗證過程中努力，以矯正在專案早期階段中識別到的風險。這些安全性補救開發程序已經過開發小組的整體測試，而且也比對品質標準進行過評估。
安全性補救測試及資源功能測試
安全性補救測試及資源功能測試程序包含比較不能預測的結果。功能性測試中無法預知的結果會在穩定階段中由各個測試程序進行標示及管理。雖然建立階段是建構在已知的計劃及規格上，不過會發現到的錯誤數目及嚴重性總是不得而知。Microsoft 採用了錯誤交集 (Bug Convergence) 及零錯誤彈回 (Zero Bug Bounce) 的技術來測量解決方案的品質狀況，以及預測此階段中的發行日期。安全性原則及因應對策部署
安全性原則及因應對策部署程序會在整個 MSF 方法部署階段中持續進行，同時會不斷地延續到 MOF 程序週期中。此因應對策部署程序會將因應對策類型及安全性原則組織成兩種類型，即核心與站台，以及其相關的安全性元件。核心特有的安全性元件是位在與整個安全性解決方案密切關聯的中央或主要位置。站台特有的元件則位在可以讓使用者存取及使用安全性解決方案的個別位置。部署完成
安全性風險管理知識是在接近部署完成里程碑時擷取到的程序。捕獲在接近部署時所學得的教訓，可將解決方案向前推進至運作狀態，並將完成的專案交到 MOF 程序週期。
有關安全性專案程序的進一步明細，請參閱《Microsoft Solution for Security Services》(英文) 的指引。
建立您的安全性計劃小組
在 MSF 程序模型的評估過程中，有一項保護您的環境的重要步驟，那就是建立安全性計劃。此安全性計劃一章的目的是要針對您組織中的整個安全性判定出其目標、範圍、原則、優先順序、標準及策略。安全性計劃的成員是公司中資深主管。而「安全性管理小組」則是由中間階級的管理者及其報告小組 (實作及管理由安全性計劃所支配的原則) 組成。
安全性計劃應採用一種由上到下的方式來開發，意思是說相關的初始、支援及指導都必須由上層管理階層開始，往下運作到中層管理，最後再包括所有的職員。然而支援方面可能是由上到下、由下到上或由中到外等組合來發展及支持安全性管理中的想法。今天許多的公司都採用由下到上的開發及支援方式，由 IT 部門開發出一套安全性計劃，而沒有適當的管理支援與指導。這可能會導致安全性計劃變得無法與您組織中更大的商業目標相互配合。
資深的管理應透過指定組織中讓計劃順利開始所需的各個角色及職責來開始建立安全性計劃。資深管理的投入可以讓計劃保持健全並隨著商業及技術環境的變遷演進。在安全性計劃中建立角色可以證實，組織會將安全性視為其事業凝聚的一部份，而不只是個關心的議題而已。
除了安全性計劃之外，管理部門還必須建立一個安全性管理小組。此安全性管理小組直接負責監視安全性計劃各個層面的絕大部份。組織中的安全性計劃通常會發展出一些安全性原則，而由安全性管理小組施行及監視安全性設定。
根據組織、其安全性需求及環境規模而定，安全性管理部門可由一個人或一群以集中或分散方式工作的人所組成。
評估
程序模型中所述之威脅評估其安全性架構設計的目的是，為了協助安全性專業人員發展出一套策略來保護組織 IT 基礎結構中資料的可用性、完整性及機密性。它對資訊資源管理者、電腦安全性高階人員及系統管理員可能很重要，而對試著建立電腦安全性原則的人可能有特別的價值。此架構為這項重要的工作提供了有系統的方式，而且也包括了設立在發生災害時的緊急應變計劃，作最後的防備。
機密性
組織的 IT 基礎結構可能包括一些需要受到保護以防未授權洩漏的資訊。這類的例子包括資訊的定時散佈，如農作物收成報告、個人資訊或獨佔事業資訊等。機密性可以確保在各資料處理的交接點，確保提供必要保密層級的能力，並防止未授權的洩漏行為。當資料存在網路中的系統及裝置中、在網路中傳送，以及當它到達其目的地時，都應保持一致的機密性層級。
完整性
IT 基礎結構包括必須受到保護的資訊，以防未經授權、突發或無意的修改行為。這類的例子包括戶口調查資訊、經濟指標，或財務交易系統等。當資訊及系統的正確性及可靠性得到保障，以及資料的未授權修改獲得抑制時，便可以維護其完整性。
可用性
IT 基礎結構包括的資訊，或提供的服務，都必須適時提供來滿足任務的需求，或避免實際上的損失。這類的例子包括最需要安全、維生，以及一致的網路連線能力的系統。可用性能確保經過授權的個人資料和資源的可靠性及適時存取。
安全性系統管理員必須確定要花多少時間、金錢及努力，才能發展出合適的安全性原則與控制。您的組織應分析其特定的需要，然後再確定其資源、排程需求及限制。電腦系統、環境及組織原則各不相同，使得組織中的電腦保全小組在制定策略上倍感困難。
雖然安全性策略可以為您的組織節省寶貴的時間，並提供需完成事項的重要提醒，但是安全性並不是一次性的活動。它是您的環境整個系統生命週期的整合部份。本單元中所述的活動通常都需要定期的更新或適當的修訂。當設定或其他條件有重大的變更，或組織的規定及原則需要變更時，便會進行這類的變更。這是一個持續不斷的重複過程，而且應該定期進行修訂及測試。
組織的評估
建立一套有效的安全性及原則與控制需要採取一項策略，來判斷在您電腦系統中及防衛它們之現行安全性原則及控制中存在的弱點。您必須注意審查環境中缺少原則的區域，同時還要檢查存在的原則文件。除了檢討原則之外，組織的法律小組還應確定所有的安全性原則都遵照公司的法律原則。您目前的電腦安全性原則狀況可透過審查下列清單來判斷：
電腦安全性原則，如實體存取控制
資料安全性原則 (存取控制及完整性控制)
緊急應變事件及災害重建計劃與測試
電腦安全性認知及訓練
電腦安全性管理及協調原則
其他包含機密資訊的原則文件，包括：
電腦基本輸入/輸出系統 (BIOS) 密碼
路由器設定密碼
存取控制文件
其他裝置管理密碼
威脅分析
建立一份威脅清單，大部份的組織可以識別出好幾份清單，可以協助您的安全性系統管理員識別出可能被攻擊所利用的削弱點。系統管理員持續不斷地更新他們對這個領域的知識是很重要的，因為經常會設計出新的方法、工具及技術來圍攻安全性法則的。
威脅分析程序概述於 [圖 1] 中的規劃階段，以判斷出可預期的攻擊，接著再發展出一些防禦這些攻擊的方法。要針對所有攻擊做好準備是不可能的；因此應該針對組織最可能受到的攻擊作好防範準備。預防或減少攻擊一向比在遭到攻擊後才修復損失來得有利。
為了減少攻擊，瞭解各種引起系統危機的威脅、可能用來危害安全性控制的相對技術，以及存在於安全性原則中的弱點是必要的。若無法預測到攻擊發生的確切時間或位置，瞭解這三種攻擊的要素，可以協助您預測攻擊的發生。預測攻擊是攸關預測其可能性，而發生的可能性是根據對其各方面的瞭解而定。各種不同層面的攻擊可以用以下的等式來表示：
威脅的動機 + 利用的方法 + 資產的弱點 = 攻擊
惡意的攻擊者可能會採用不同的方式來發起相同的攻擊。因此，必須針對各種威脅者可能利用的各種方式，自訂安全性策略。
弱點評估
評估組織的安全性需求必須包括判斷它與已知威脅有關的弱點。此項評估需要知道組織所擁有的資產類型，以及可能對其造成何種損害。
判斷攻擊可能造成的損害
對您環境中的資產可能造成的損害，範圍可能包括從電腦的小故障到嚴重的資料流失不等。對系統所造成的損害將依照攻擊的種類而有所不同。可能的話，請利用測試或實驗室環境來釐清不同種類的攻擊所造成的損害。如此將可以讓安全人員正確地評估實際的損害。並非所有的攻擊都會造成同一種類或等量的損害。可以執行的測試包括：
在實驗室系統上進行電子郵件病毒攻擊的模擬，之後再利用分析來判斷所造成的損害，以及所需的潛在復原程序。
透過企圖從信任的員工中獲取使用者名稱及密碼的測試，來判斷員工是否易受到社交工程的攻擊。
資料中心災難的演練或模擬。測量生產時間的損失及復原所花費的時間。
惡意病毒攻擊的模擬。測量復原一部電腦所需的時間。接著可將此時間因素與系統內受病毒感染的電腦數量相乘，以得出停機或產能損失的數量。
此程序最好也請意外事件回應小組一起參與，因為一整個小組比一個人更可能偵察到發生的各種損害類型。意外事件回應小組可控制安全性事件的優先處理順序，以及解決它們擴大的途徑。
判斷攻擊可能利用的弱點或缺失
要是能夠觀察到特定攻擊所利用的弱點，就可以更改現行或實作新的安全性原則及控制，將弱點減到最少。判斷出攻擊、威脅及方法的種類，可更容易發現現有的弱點。藉由執行滲透測試可以證明這一點。
安全性風險計劃及排程
對於每一種利用的方式，組織的安全性計劃都應包括主動式及反應式策略。
主動式或預先攻擊的策略是協助將現有的安全性原則弱點減到最少，並發展出緊急應變計劃的步驟。判斷攻擊對於系統會造成的損害，以及攻擊時所利用的缺失與弱點，可以協助您發展出主動式的策略。
反應式策略或後置攻擊策略，可以協助安全性人員評估攻擊所造成的損害、修復損失或實作主動式策略中所發展出來的緊急應變計劃、記錄經驗並從中學習，以及取得商業功能的後援並儘速地執行。
主動式策略
主動式策略是應該在攻擊發生之前就採取的預先定義步驟，以防止遭受攻擊。這些步驟包括：注意攻擊可能會如何影響或破壞您的電腦，以及它所利用的弱點 (步驟 1 及 2)。在這些評估當中所獲得的知識，可以協助您實作能夠控制或減少攻擊的安全性原則。以下是主動式策略的四個步驟：
判斷攻擊會造成的損害。
判斷攻擊將利用的弱點與缺失。
將針對前兩個步驟所定義的這個特定攻擊，所判斷出的弱點與缺失減到最小。
判斷適當的因應對策層級進行實作。
照著這些步驟來分析各種攻擊，可產生邊際效益：某種模式會開始出現，指出不同攻擊相互重疊的因素。此模式有助於判斷出對企業呈現出最大風險的弱點部份。
**注意：**平衡遺失資料的成本損失與實作安全性控制的成本也是必要的。斟酌這些風險及成本是系統風險分析的一部份。
反應式策略
當針對攻擊採取的主動式策略失敗時，則會實作反應式策略。反應式策略定義了在攻擊期間或之後必須採取的步驟。它可協助識別出所造成的損害，以及攻擊中所利用的弱點。反應式策略也可以判斷攻擊發生的原因、如何修復因攻擊所造成的損害，以及如何實作緊急應變計劃。
反應式策略及主動式策略可以搭配運用，以發展出安全性原則及控制，進而讓攻擊及其造成的損害減到最小。意外事件回應小組應參與執行攻擊期間或之後所採取的步驟，以協助評估、記錄事件並從中學習。
反應式策略包括下列三個步驟：
限制損害。
包含攻擊期間所造成的損害，可以限制進一步損害的數量。例如：若您的環境中感染到病毒，您會試著儘快中斷伺服器與網路的連線，以限制損害繼續發生，即使在您得知有多少部伺服器可能受到影響之前也會如此。此一動作應儘速進行。評估損害。
判斷攻擊期間所造成的損害。此一動作應儘快進行，這樣還原組織的營運才可能儘快開始。若無法及時評估損害，則應實施緊急應變計劃，這樣正常的營運及生產才能繼續。判斷損害的原因。
為了判斷損害的原因，有必要瞭解攻擊是瞄準何種資源，以及利用哪些弱點來取得存取權或破壞服務。查閱系統日誌、稽核日誌及審核記錄。這些查閱的動作通常可以協助您觀察到攻擊是從系統的什麼地方開始，以及有哪些其他的資源受到影響。修復損害。
儘快修復損害以恢復正常營運，以及還原攻擊時所造成的資料損失，是重要事宜。組織的災害重建計劃及程序應包含還原策略。意外事件回應小組也應該能處理還原及復原程序，並提供復原程序的相關指引。在此程序期間，會執行緊急應變程序來限制損害的進一步擴大。
緊急應變計劃
緊急應變計劃是預防攻擊滲透到您的系統並破壞資料及其他資產，進而對正常營運造成干擾或降低產能時，所發展出來的替代計劃。如果系統無法及時還原，則會遵照緊急應變計劃來執行。最後，本目標是為了保持資料的可用性、完整性及機密性，也就是說，您的緊急應變計劃就等於是「B 計劃」。
緊急應變計劃應加以建立，以解決每一種攻擊及威脅的問題。每一個計劃都應包括萬一有攻擊時可以採用的一套步驟。繄急應變計劃應持續地：
提出誰必須做什麼、何時進行以及在何處執行的問題，使組織可以持續運作。
定期演練，讓所有人員隨時瞭解最新的緊急事件預防步驟。
包含來自備份伺服器的還原資訊。
隨著更新病毒軟體、Service Pack 及 Hotfix。
包含將生產伺服器移到另一個位置的程序。若有資金時，應在策略性緊急事件預防地點中收集生產伺服器複寫。
包括現行安全性原則及緊急應變計劃的事後檢討。
下列各點概述各種不同的評估工作，在發展您的緊急應變計劃時應該進行：
評估組織的安全性原則及控制，以利用任何機會使弱點減到最小。此項評估應該提出組織的現行緊急應變計劃及程序，以及其整合到緊急應變計劃的問題。
評估現行的緊急回應程序及它們對營運的影響。
發展出對攻擊的計劃性回應，並將它們整合到緊急應變計劃，注意它們足夠限制損害的程度，以及將攻擊對資料處理作業的影響減到最少。
評估備份程序，包括最新的說明文件及災害重建測試以評估其適用性，並將評估所得的結果併入緊急應變計劃中。
評估災害重建計劃，以判斷它們伴隨的步驟是否合適於提供暫時或長期的作業環境。災害重建計劃應包括測試組織所需的安全性層級，如此一來安全人員才能判斷他們是否可以繼續在整個復原過程中執行安全性、暫時的作業，以及移回組織原來的處理站台或回到新站台的動作。
草擬一份條列執行上述工作所需各種工具的詳細文件。此文件應列示：
測試緊急應變計劃之使用者案例的相關明細。
相依關係，例如從組織及必要資源之外獲得的協助，會對緊急應變計劃造成影響的相關明細。
在復原作業中觀察到優先處理順序的清單，以及用來建立它們的基本理論。
提升途徑的相關明細，如此在緊急應變計劃執行時，任何可能因它引起的問題可以清楚提升到最有效率的 IT 或營運人員。
實作
小心不要實作過於嚴刻的控制程序，因為資訊的可用性可能會因而變成問題。安全性控制及資訊的存取之間必須要謹慎地權衡。
模擬攻擊測試
安全性策略最後一個要素，即測試與檢閱測試結果，會在反應式及主動式策略實行之後才執行。在測試或實驗室系統中執行模擬攻擊，能夠評估各種弱點存在的位置，因而可以調整組織的安全性原則及控制。
這些測試不應在現行的生產系統上執行，因為後果可能會很慘重。但是，若因預算的限制而沒有實驗室及測試用的電腦，可能排除模擬攻擊。為了確實保有測試用的必要資金，讓管理部門知道攻擊的風險及後果，以及可能需要採取以保護系統的安全性措施，包括測試程序是很重要的。可能的話，應實際測試和記錄所有的攻擊案例，以判斷最有可能實作的安全性原則及控制。
雖然模擬會有所幫助，然而某些攻擊，例如：天然災害，還是無法測試。例如：火災可以在伺服器室進行模擬，致使當中所有的伺服器受到損壞而無法運作。這類災害案例對於測試系統管理員及安全性人員的反應力，以及對於確定多久能讓組織恢復運作，十分有幫助。
根據測試結果來調整安全性原則及控制是一項重複的程序。此程序會持續不斷，而且應定期進行評估及修訂，如此改善的工作才能落實。
運作
清楚定義的提升途徑及問題管理是「意外事件回應」計劃的必要元素。藉由不斷地在安全性專案的初期中執行「意外事件回應」計劃，小組在解決整個企業中的問題上具有更大的效率。記錄結果以及從您的安全性專案中學習，對每位進行新專案的人員都有利。收集在操作程序中學到的一類教訓，可使評估、發展及實作下一個安全性專案的工作更加容易完成
意外事件回應
如果您的組織希望徹底實作安全性計劃最佳作法，需要建立意外事件回應小組。意外事件回應小組應該主動參與各項工作，以確保系統的安全性，其中包括：
發展出處置意外事件的指導方針。
針對電腦犯罪準備提升法律執行的途徑及程序。
識別出回應意外事件及活動的軟體工具。
研究與開發其他的電腦安全性工具。
舉行訓練和認知活動。
執行病毒的相關研究。
進行系統攻擊研究。
這些努力將可提供知識給組織用來解決意外事件發生之前及期間的問題。
安全性系統管理員應處於在需要時監視及管理組織的安全性稽核的立場。安全性系統管理員應是權威代表，可以是一個人或一群人，負責實施安全性網域的安全性原則。在安全性系統管理員及意外事件回應小組完成這些主動式職務之後，系統管理員應將處理意外事件的責任轉交給意外事件回應小組。
但這不表示安全性系統管理員不用再繼續參與小組的工作。安全性系統管理員可能不一定隨時有空，因此意外事件回應小組應該能夠自行處理意外事件。小組將負責回應意外事件，也應參與分析任何可能涉及電腦或網路安全性的異常事件。
記錄與學習
在攻擊發生時，將其記錄下來是很重要的事。記錄資料應涵蓋已知的各個攻擊面，包括攻擊造成的損害：硬體、軟體、資料流失、產能損失等，攻擊時所利用的弱點與缺失、生產時間的損失量、修復損害所採取的程序以及修復所花的努力。記錄資料可協助修改主動式的策略，以防範進一步的攻擊並將損害減到最低。
實作緊急應變計劃
若已經有緊急應變計劃，則可予以實作，以節省時間並讓營運順利進行。若沒有緊急應變計劃，則需根據前面步驟中的記錄內容來研發出適當的計劃。
檢閱結果及執行模擬
在攻擊之後或在抵抗攻擊之後，應檢閱與系統及組織主動式策略相關的結果。檢閱的內容應包括，產能耗損、資料或硬體損失，以及從攻擊恢復所花的時間等詳細資料。您應該在測試環境中執行模擬作業，這應與生產環境類似以獲得最佳結果。
檢閱及調整原則效益
若有現行原則可防禦所發生的攻擊，則應該加以檢閱並檢查其效益。若沒有原則，則必須草擬新的原則以降低或防範未來的攻擊。
若現有原則的效益未達到標準，則應予以調整。原則的更新必須由相關管理人員、安全性系統管理員、IT 系統管理員及意外事件回應小組來協調。所有的原則都應符合組織的一般規則與指導方針。例如，組織的一般上班時間可能是從上午 8 點到下午 6 點。則可以更新或建立安全性原則，指定使用者只能在這個時段登入系統。
安全性風險管理法則
下列各節利用了現今運用 MSF 及 MOF 所採用的安全性分析方法中已經過證實的作法。MSF 提供了在企業架構及基礎結構部署範疇中規劃、建立、穩定及部署專案生命週期的階段方面的指引。MOF 提供如何針對資訊技術 (IT) 作業開發或增進管理系統的相關建議。「安全性風險管理法則」已在此詳細加以定義，提供您可以運用到您環境的知識。SRMD 是一套詳盡的程序，有助於判斷哪些威脅及弱點最有可能影響特定的組織。
識別安全性風險
安全性風險識別是評估組織安全性的第一個步驟。為了有效地管理安全性風險，必須清楚地加以說明，這樣專案小組才會有共識，進而往後繼續分析後果，以及建立解決風險問題的行動計劃。雖然安全性風險的範圍侷限在專案小組試著保護的技術，但是小組的焦點應該擴展到足以解決所有的安全性風險來源，包括：技術、程序、環境和人員。
腦力激盪是識別安全性風險的一種方法，而網際網路上有許多關於安全性問題的資訊來源。組織可能也有現存的弱點評估或滲透測試，可以針對攻擊表面安全性風險來加以檢閱。
目標
安全性風險識別步驟的目標是，讓小組建立使組織資產陷於易受攻擊處境的已知安全性風險清單。此清單應儘可能完整，涵蓋到企業架構的所有視界，包括技術、商業、人員及策略。
風險管理是識別風險、分析風險及建立管理風險計劃的程序。安全性風險被定義為是依據系統弱點及對相關威脅者之抵抗和判斷而造成的預期威脅所導致或影響的預期損失。
建議事項
對安全性風險識別的建議事項包括，收集現有的威脅知識、建立目前利用削弱點的方式及技術清單，以及分析有可能被利用來危害組織資產的系統和原則弱點。這些威脅包括任何對資訊及系統的外在可能危險。而弱點則是提供威脅攻擊點的軟體、硬體或程序缺失。這些風險通常是源自不同的企業環境視界，包括商業作法、應用程式、資料及基礎結構的架構。
您小組的經驗，以及組織在技術基礎結構現行的狀況上以原則、程序、指引、範本及資訊等形式對安全性規劃的現行對策，將可協助判斷此步驟的建議事項。
安全性小組可能會利用從資產本身，或從用來執行弱點分析或滲透測試之工具得到的結果中所獲得的資訊。為收集小組和主策者對於安全性問題的觀點而進行的集體自由討論、簡化的討論會，甚至是正式的安全性研討會，都證實有益於獲得建議。
風險識別活動
在安全性風險識別步驟中，小組會透過清楚地闡述組織所面臨的風險，來尋求建立安全性問題的明確聲明或清單。安排一系列的安全性小組研討會或自由討論會議，對於識別與新環境有關的風險十分有幫助。
由於技術及環境急速的變化，不將安全性風險識別視為是一次性活動是很重要的，此一過程應在組織的運作生命週期中定期重複進行。
結構化的途徑
對安全性風險管理使用結構化的途徑是必要的，因為它可以讓所有的小組成員採用一致的機制來看待安全性問題。在此步驟當中使用威脅分類有助於提供一致、可再產生及可測量的方式。
威脅分類
威脅分類 (也稱作類別或分類法) 為安全性小組提供很多目的。在風險識別期間，它們可以用來刺激對各種不同區域中所引起安全性風險的思考。在集體自由討論會中，分類也可以透過提供簡便的方式將相似的威脅歸納在一起而減低處理大量威脅的複雜性。威脅分類的採用也可以為小組提供共同的術語，以便用來監視及報告整個專案的風險狀況。
安全性風險陳述
安全性風險陳述是組織現有安全性狀況與未來可能、未實現安全性結果之間的因果關係的自然語言表達。
安全性風險陳述的第一個部份稱為「情況」，它提供現有狀況或小組覺得可能造成一些傷害之潛在威脅的說明。風險陳述的第二個部份稱為「結果」，它說明資產之機密性、完整性及可用性不想要有的損失。
這兩項陳述是由像「那麼」或「可能會造成」的字詞連結，它們暗示著不確定即小於百分之百或因果的關係。
以下介紹用於本指南中的風險陳述：
如果威脅者 運用工具、技巧或方式來利用弱點，那麼對資產機密性、完整性或可用性的損失可能會造成衝擊。**
安全性風險陳述是經由風險分析發展出來的。有兩種不同的風險分析方式： 定質性及定量性。定質性與定量性方法不相上下，它們各自提供重要的工具來建構您的風險識別活動。定量法是根據定量程序中收集的資訊而建立的。
.jpg)
[圖 2] 安全性情況與結果風險陳述
下列各步驟詳述上圖程序的每一部份：
為每一個威脅定義情況及結果風險陳述。
若威脅者帶來威脅及運用弱點，那麼攻擊就會導致風險。攻擊可能會透過降低機密性、完整性或可用性來破壞資產。因此，攻擊會造成公司損失的曝光。但是，這些曝光度可以由防範措施反向測量。指定威脅可能性 (TP)，0% 最低 – 100% 最高。威脅可能性是可能的威脅者進入您環境的可能性。
指定危急性因素 (CF)，1 最低 – 10 最高。危急性因素是資產中可能遭威脅利用的程度。
評定努力 (E)，1 最低 – 10 最高。努力代表攻擊利用削弱點所需的技能。
判斷風險因素 (Risk Factor，RF)。這是危急性因素除以努力得到的數字。
使用等式 (TP × RF) 來判斷威脅頻繁程度。
評定弱點因素 (VF)，1 最低 – 10 最高。決定對資產的弱點會有多大的風險。
判斷資產優先順序 (AP)，1 最低 – 10 最高。根據下列準則判斷每個公司資產的資產優先等級。資產的價值評定是複雜的過程，可能需要花時間才能漸趨完美。有關資產價值評定的詳細資訊，請參閱本單元最後有關這個主題的參考資料。排定組織資產的優先順序，對於判斷以可用的預算能保護多少資產是很重要的。
為了協助您有系統地整理優先的資產清單，請依據您的組織內的環境，探究下列有關每項資產問題的解答：
公司的資產價值為何？
資產需要花多少錢來維護或保護？
資產為公司帶來多少利潤？
資產值多少競爭價值？
資產要花多少錢來重建或復原？
資產花了多少錢取得或開發？
使用等式 (VF × AP) 來判斷影響因素 (IF)。
使用等式 (威脅頻繁程度 × 影響因素，並除以 1,000) 來判斷曝光度因素 (EF)。曝光度因素是以百分比表示，以便在 [表 2] 下繼續的步驟中計算單一損失預期量 (Single Loss Expectancy，SLE)。
產生安全性風險陳述的兩個部份公式化程序，具有將資產可能的結果與組織中目前存在可觀察到以及可能可控制的情況相結合的優點。小組在識別安全性風險情況方面唯一關注的替代方法，可能需要小組在安全性風險管理計劃建立時，稍後於安全性風險分析程序中重新追蹤風險情況。
**注意：**安全性風險陳述不只是純粹的 "If-Then" 陳述而已；事實上，它們是探究風險可能造成卻未察覺結果的事實陳述。
考量假設性的 "If-Then" 陳述，並利用決策樹來斟酌使用替代方法及制定計劃，可能很有幫助。然而，您在安全性風險識別階段中的目標，純粹是要儘量找出安全性風險。要如何分析及管理它們則是延到此程序的稍後階段。
您建立的安全性風險陳述必須包含情況及結果。作為完全安全性風險分析的一部份，小組成員應尋找安全性問題情況的相似性及自然分類，然後再重新追蹤每一個的關係，以找出一般的根本主因。從情況的主因往下重新追蹤彼此的關係，也是很重要的。它會檢查對組織之外的資產所造成的影響，進而對於與安全性威脅相關的所有損失或失去的機會，獲得更好的評估。
在安全性風險識別期間，如果相同的情況擁有多個與其相關的結果是不太尋常的。但是，反過來倒有可能是真的 — 可能有許多情況全都產生相同結果。有時在組織某一部份中識別到的安全性風險結果，可能會成為另一個風險情況。這些情況應該要記錄下來，這樣在安全性風險分析及規劃期間才能作出適當的決策，以便考量安全性風險之間的相依性和關係。
根據組織的安全性風險關係而定，減少風險的錯誤，可能會促成整個相依風險群組的風險跟著降低，因而改變組織的整體風險概廓。在安全性風險識別階段的初期記錄這些關係，可提供有用的資訊，幫助引導有效的安全性風險計劃，也就是在分析資源時具有彈性、廣泛而且有效，可提出主因或下游原因。對於最重要的安全性風險，在識別步驟中擷取這些額外資訊的好處，應針對後續的分析及優先處理間的快速進展取得平衡，然後再於計劃階段重新檢查相依性和主因。
評定組織資產的價值
評定資產的金錢價值是風險管理重要的一部份。企業經理人通常有賴資產的價值來引導他們判斷應花多少金錢與時間來保護資產。有許多組織會將資產價值清單當作其災害重建計劃的一部份來維護。使用以下的價值判斷模型，可以幫助組織判斷如何排定資產的優先順序，如定量分析的步驟 8 中所詳述。
若要適當地為資產指定值，可計算以下三個主要的因素：
組織的整體資產價值。以直接的金融關係計算或評估資產的價值。例如：若您有一個電子商務網站，一般運作時間為一週七天，每天 24 小時，而它從客戶的訂單中可以產生平均每小時 $2,000 美元的收益，則您可以有信心地表示，這個網站在銷售歲收上每年的產值會有 $17,520,000 美元。
資產損失的直接財務影響。若相同的網站有六個小時不能運作，所計算的曝光度為一年 .000685 百分點。將這個曝光度百分點乘以每年的資產價值，您可以預測在此情況下直接可歸因的損失會是 $12,000 美元。
資產損失的間接事業影響。在此例中，公司預估宣傳抵制此類意外事件的負面形象費要花 $10,000 美元。此外，公司也預估每年銷售量一個百分點有 .01 的損失，或 $17,520 美元。透過結合額外的宣傳費用及每年銷售歲收的損失，您可以預測在此案例中間接總損失會是 $27,520 美元。
[表 1]：資產價值評定範例 (以美元計)
| 資產 | 價值 | 曝光因素 | 直接影響 | 間接影響 |
|---|---|---|---|---|
| 電子商務網站 | 每年 $17,520,000 美元 | 每年六個小時或 .000685 | $12,000 | $27,520 |
| 範圍 | 計算值 | 表示式 | 分數 |
|---|---|---|---|
| 1% 到 14% | 7% | 極不可能 | 1 |
| 15% 到 28% | 21% | 低 | 2 |
| 28% 到 42% | 35% | 不可能 | 3 |
| 43% 到 57% | 50% | 50 – 50 | 4 |
| 58% 到 72% | 65% | 可能 | 5 |
| 73% 到 86% | 79% | 高度可能 | 6 |
| 87% 到 99% | 93% | 幾乎確定 | 7 |
| 分數 | 金錢損失 |
|---|---|
| 1 | $100 以下 |
| 2 | $100 – $1,000 |
| 3 | $1,000 – $10,000 |
| 4 | $10,000 – $100,000 |
| 5 | $100,000 – $1,000,000 |
| 6 | $1,000,000 – $10,000,000 |
| 7 | $10,000,000 – $100,000,000 |
| 8 | $100,000,000 – $1,000,000,000 |
| 9 | $10 億 – $100 億 |
| 10 | $100 億以上 |
| 可能性影響 | 低 = 1 | 中 = 2 | 高 = 3 |
|---|---|---|---|
| 高 = 3 | 3 | 6 | 9 |
| 中 = 2 | 2 | 4 | 6 |
| 低 = 1 | 1 | 2 | 3 |
| 曝光度範圍： 低 =1 – 2; 中 =3 – 4; 高 = 6 – 9 |
| 優先順序 | 情況 | 結果 | 可能性 | 影響 | 曝光度 |
|---|---|---|---|---|---|
| 1 | 病毒感染電子商務網站 | 六小時重建伺服器。 | 80% | 3 | 2.4 |
| 2 | 新程式設計語言沒有編碼標準 | 出貨時可能帶有更多的安全性弱點。 | 45% | 2 | 0.9 |
| 3 | 沒有書面規格 | 有些產品安全性功能未實作 | 30% | 2 | 0.6 |
| 項目 | 目的 | 狀態 |
|---|---|---|
| 安全性風險陳述 | 清楚闡述風險。 | 必要 |
| 可能性 | 量化威脅出現的可能性。 | 必要 |
| 影響 | 量化損失的嚴重性或大量的機會成本。 | 必要 |
| 分級基準 | 重要性的單一測量。 | 必要 |
| 優先順序 (排列) | 排列行動的優先順序。 | 必要 |
| 擁有者 | 確定完全照著風險行動計劃執行。 | 必要 |
| 減少錯誤的計劃 | 說明預防措施。 | 必要 |
| 緊急應變計劃及觸發器 | 說明更正措施。 | 必要 |
| 主因 | 指引有效的介入計劃。 | 必要 |
| 下游效果 | 確定合適的影響評估。 | 選擇性的 |
| 環境 | 記錄背景資訊以捕捉小組在表面風險中的意向。 | 選擇性的 |
| 實作時間 | 捕捉在某些時間範圍內實作風險控制的重要性。 | 選擇性的 |
| 項目 | 目的 |
|---|---|
| 安全性風險識別元 | 小組為了報告及追蹤目的用來專門識別風險的名稱。 |
| 安全性風險來源 | 安全性風險所源自基本區域的廣泛分類。用來識別應尋找安全性風險重複出現的主因所在。 |
| 安全性風險情況 (威脅/削弱點) | 說明可能造成損失現有情況的詞語。這構成安全性風險陳述的第一個部份。 |
| 風險結果 (弱點/對資產的影響) | 說明當風險產生結果時會發生損失的詞語。這構成安全性風險陳述的第二個部份。 |
| 安全性風險可能性 | 大於零而小於百分之一百的可能性，代表風險情況實際上會發生而導致損失之可能性。 |
| 資產影響分類 | 風險可能產生影響種類的廣泛分類。 |
| 資產曝光度 | 整個風險的威脅，平衡實際損失的可能性與大量可能的損失。小組可使用風險曝光度來分等和分級風險。曝光度透過將風險可能性和影響相乘算出。 |
| 風險環境 | 包含可協助釐清安全性風險情況之額外背景資訊的段落。 |
| 相關的安全性風險 | 小組用來追蹤相互依存風險的風險識別元清單。 |