第 3 章 - 瞭解安全性風險管理準則

發行項
12/06/2019

本頁索引

安全性風險管理與安全性架構實踐
 安全性風險管理架構
 安全性風險管理準則
 安全性風險追蹤、規劃、排程與報告
 安全性風險補救措施開發
 安全性補救措施測試
 擷取安全性知識
 摘要

本章描述現今通行運用 Microsoft 方案架構 (MSF) 與 Microsoft 作業架構 (MOF) 且已經過驗證的安全性分析方法。MSF 為專案生命週期的規劃、建立、穩定及部署階段提供指引，在企業架構和基礎結構部署等方面有所著墨。MOF 則對如何開發或改善資訊科技 (IT) 作業的管理系統提供建議。如需有關 MSF 或 MOF 的詳細資料，請參閱本章結尾的＜其他資訊＞一節。

本章定義三大主要指導處理程序：按照安全性專案生命週期中所發生的風險管理活動，討論安全性風險管理準則 (SRMD) 與安全性風險架構。

公司可以利用這三大主要處理程序，定義保障及維持安全性所需的作業。下面從較高層次觀點定義這些主要處理程序。

評定

此階段涵蓋從公司的環境收集相關資訊，以進行安全性評定。必須擷取足夠資料，才能有效地分析環境的目前狀態，然後判斷如何保護公司資訊資產，以避開潛在的威脅。除了安全性評定之外，稍後也要建立在實作處理期間執行的「安全性行動計劃」
開發與實作

此階段著重於執行「安全性行動計劃」，以實作評定中所建議的環境變更。除了「安全性行動計劃」以外，也要發展「安全性風險應變計劃」。
作業

此階段涵蓋視需要針對環境進行修改及更新，以保障環境安全。在作業程序期間實施滲透測試與意外回應策略，有助於鞏固公司中安全性專案的實作目標。而在作業程序中實施稽核與監視活動，則能保障基礎結構的完整與安全。

安全性風險管理與安全性架構實踐

在執行安全性計劃期間，專案生命週期會持續進行兩種類型的風險管理活動。第一種是管理專案本身固有的風險，第二種是管理與安全性元件相關的風險。專案風險只在專案生命週期間進行評定，而安全性風險則必須在解決方案或系統的整個生命週期間進行評定。「MSF 風險管理準則」可以同時做為專案與安全性評定的風險管理基礎。安全性風險管理的慣用範例會在本手冊第 4 章＜套用安全性風險管理準則＞中進一步說明討論。

本解決方案手冊定義了從 MSF 風險管理準則 (RMD) 衍生而來的安全性風險管理準則 (SRMD)。為了劃分兩種活動的界線，在專案風險中提的是 RMD，而 SRMD 則是指安全性風險評定活動。RMD 是用於開發 SRMD 的主要工具。

RMD 和 SRMD 兩種處理程序都主張採取事前防範手法、持續不斷的風險評定，以及在整個環境的專案與操作中整合決策。

電腦系統安全性必須以事前防範且持續不斷的方式進行，以確保資訊資產的安全性，並監控新的威脅與弱點。無論何時在公司的科技基礎結構中加入新功能，永遠必須考量資訊安全性。除此之外，某些商業處理流程與程序可能必須修改，才能在修正過的環境中操作，並且為這些新的資訊資產提供保護。

安全性風險管理準則的九個步驟如下：

評定

資產評定與評估
識別安全性風險
分析安全性風險並訂定優先順序
安全性風險追蹤、規劃與排程

開發與實作
安全性補救措施開發
安全性補救措施測試
擷取安全性知識

操作
重新評定新增的和已變更資產與安全性風險
鞏固並部署新增的或已變更的反制措施

這些步驟在 SRMD 內的具體表現為如下三大主要階段：評定、實作與操作。

評定

下列各節會將公司的評定工作納入安全性分析的起始基礎。資產評定與驗證是準備進行安全性分析的第一步，因為必須知道自己的起始基礎，才能評估往後發展的風險。安全性分析過程是一組策略，目標在於使您能夠決定環境中值得保障安全的資產，以及保障這些資產安全的順序。

資產評定與評估

資產評定是與各單位有關的資訊價值，以及為開發此資訊所付出的努力；評估則是為維護資產所付出的成本、資產遺失或損毀時所造成的損失，以及另一方搶先取得此項資訊，其利益優勢如何。資產的價值可以反映資產實際受損時可識別的所有代價。

安全性風險識別

安全性風險識別可以讓專案小組成員進行腦力激盪，揭露潛在的安全性風險。資訊是根據威脅、弱點、利用與反制措施等所收集的。

安全性風險分析

安全性風險分析是用於分析潛在攻擊、工具、方法，以及可能剝削利用弱點的技術。安全性風險分析是一種可以識別風險並且評定可能發生的潛在損壞的方法，以調整安全性的防護。

安全性風險分析有三大目標：識別風險、量化潛在的威脅衝擊，並且提供風險衝擊與反制成本之間的經濟平衡。所收集的資訊可以評估風險層面，讓小組能夠做出專業的明智決策，依此盡最大努力對安全性風險進行矯正補救。

然後根據此分析訂定安全性風險的優先順序，使公司能夠投入資源處理最重大的安全性議題。

風險分析有助於整合安全性計劃目標與公司的商業目標和需求。商業與安全性目標越相符一致，公司就越能同時完全實現這兩項目標。

此分析也有助公司為安全性計劃及構成計劃的安全性要素擬定適當的預算。一旦知道公司資產的價值，並了解可能暴露的潛在威脅之後，就可以做出明智的決策，決定保護這些資產所要支出的成本。

安全性風險追蹤、規劃與排程

安全性風險追蹤、規劃與排程採用安全性風險分析中的資訊，運用此資訊制訂涵蓋所有安全性風險的緩和及應變策略與計劃。安全性風險排程嘗試為建置安全性專案階段期間所建構的各種補救策略定義排程。將這項排程納入安全性計劃的核准方式的考量中，並且加入資訊架構以及必須實作的每日標準作業程序中。

開發與實作

在評定程序中執行的工作可以讓您適當地進行反制措施的開發與實作。評定程序的成果提供了一個方法，讓您能夠輕鬆地轉換為實作有效的反制部署與安全性學習策略。

安全性風險補救措施開發

安全性風險開發採用「評定」階段所建立的計劃，建立涵蓋組態管理、修補程式管理、系統監視與稽核，以及操作原則與程序的新安全性策略。隨著各種反制措施的開發，確保慎密地追蹤並報告這項開發的進度更顯得非常重要。

安全性風險補救措施測試

在開發補救策略和相關的系統管理變更，以及決定原則及程序的效力之後，進行安全性風險補救措施測試。測試程序可以讓小組考慮變更生產環境的部署方式。在測試程序中，反制措施是以安全性風險控制程度的效力為標準進行評估。

安全性風險學習

安全性風險學習可以將小組保障資產、記錄弱點以及發現剝削利用等相關知識的擷取過程形式化。隨著 IT 部門學習發展，也必須擷取並且重新部署新的安全性資訊，以便持續保持維護公司資產安全性反制措施效力的最佳狀態。除此之外，還需要透過訓練或安全性講習公告，在企業團體中推行安全性教育。

    注意這些步驟的目的是做為邏輯指引，不需要依序遵循地用於處理任何安全性風險。隨著對於特定資訊資產的安全性議題、威脅與弱點的逐漸體驗與了解，安全性小組會依照識別、分析與規劃步驟的循環進行。

公司必須界定正式的風險管理流程，定義如何啟動及評估安全性反制措施，以及應該在何種狀況下，展開個別或群組安全性風險步驟之間的轉換程序。

操作

強固而一致的操作週期為安全性小組，提供了實現可靠且可預期結果的機制。藉由在安全性專案中及早執行評定程序，小組可以取得更多如何在整個企業中重新評定新增的或已變更資產的相關知識。針對新增的和已變更資產，鞏固並部署新增的或已變更的反制措施，就會成為公司每日例行作業的一部分。

重新評定新增的和已變更資產與安全性風險

這些處理程序不僅是變更管理的程序，也是執行安全性設定管理的程序。因此也會在完成新反制措施及製訂安全性原則之後，發佈管理制度。

鞏固並部署新增的或已變更的反制措施

在「操作」階段中，這些處理程序是由系統管理、安全性管理與網路管理小組所管理。服務監視、服務控制與工作排程是操作階段中的額外處理程序，安全性管理員會在其中執行新的改良反制措施。

安全服務台、意外狀況管理與問題管理學習

在支援階段中，IT 公司內的操作群組會透過安全服務台及控制意外與問題逐步擴大管理，以強固的安全性管理支援安全的環境。

服務層次、財務與可用性管理

MSF 與 MOF 已通過驗證的最佳實例，可以協助您開發、部署及維護強固的安全性管理計劃。成功地利用這些經過證實的最佳實例，可以在建立環境時，提供資源的完整性、機密性與可用性。

安全性管理經由在服務層次中的強固管理、財務管理、服務社群管理、可用性管理、容量管理與戰力管理各方面，達到最佳化。

回到頁首

安全性風險管理架構

概觀

此架構運用 MSF 處理序模型，並且為建置並部署 IT 安全性解決方案，提供高層次的活動順序。此架構並未規定一系列的特定程序，而是以足夠彈性容納範圍廣泛的 IT 處理程序。處理序模型適用於從專案起始到實際部署的完整解決方案生命週期。

圖 3.1 安全性架構處理序模型階段里程碑

MSF 處理序模型可以用於開發軟體應用程式，以及部署基礎結構技術。處理序模型遵循經過設計的反覆週期，以便透過短暫的開發週期與解決方案的逐漸增加，容納一再變更的專案需求。這是因為有不間斷的風險管理與測試週期，才可能達到。

並且在每個處理序模型的里程碑中，提出並回答或討論與專案有關的許多關鍵問題，例如：小組是否一致同意專案的範圍？小組是否已有足夠計劃可以繼續進行？小組是否已建置當初計劃要建置的各項？解決方案是否適當地為公司的客戶與合作夥伴而運作？下面扼要討論與上圖相關的六個安全性專案主要處理程序。

專案定義起始階段

專案的起始階段會處理安全性專案成功的最基本需求之一：將專案小組與安全性計劃加以統一。小組的起始處理程序會持續改進修正，直到整個起始階段結束為止。所有小組成員都必須清楚地了解在安全性解決方案中所要完成的目標願景，以及有關安全性的業務需求。此階段著重於與安全性管理有關的任何企業問題或機會。而與安全性管理有關的所有單位均必須在這些處理程序期間界定目標、進行假設並受其限制。
安全性評定與分析

安全性管理的評定與分析程序是在 MSF 方法規劃階段內進行的。這些程序包括了公司評定、資產評估、威脅識別、弱點評定與安全性風險評定。這些程序共同結合為成功反制部署所含的規劃。
安全性補救措施開發

取自安全性評定與分析階段的資訊輸入可以建立安全性補救措施開發的工具。在這些處理程序中，開發人員會不斷地進行反制措施的開發、測試與驗證，以矯正專案稍早階段所識別的風險。這些安全性補救措施開發處理程序是由開發小組測試並且以品質準則進行評估的單元。
安全性補救措施測試與資源功能測試

安全性補救措施測試與資源功能測試處理程序包含了比較難以預期的結果。無法從功能測試預見的結果會在鞏固階段,由測試處理程序加以標示及管理。雖然建置階段是建立在已知的計劃與規格上，但所發現的錯誤數目與嚴重性卻永遠無法預知。Microsoft 是使用錯誤交集與零錯誤重覆技術，在此階段測量解決方案的品質狀態，並且預計發行日期。
安全性原則與反制措施部署

安全性原則與反制措施部署處理程序會在 MSF 方法的整個部署階段中持續地進行，而且持續至 MOF 處理週期之中。這種反制措施部署的處理程序會將反制類型與安全性原則構成兩種類型：核心與網站，及其各自的安全性元件。特定的核心安全性元件是位於中央或與整個安全性解決方案有關的重要位置；特定的網站元件則是位於個別位置上，可以讓使用者存取並使用安全性解決方案。
部署完成

安全性風險管理知識是在接近部署完成里程碑時所擷取的處理程序。擷取接近部署時所學到的教訓可以將解決方案移入操作階段，並且將已完成的專案移入 MOF 處理週期。

如需有關安全性專案處理程序的進一步詳細資料，請參閱《Microsoft Solution for Security Services Guide》。

建立安全性計劃小組

在 MSF 處理序模型的評定程序中，能夠保障環境安全的關鍵步驟，也就是建立安全性計劃。此安全性計劃可以決定公司內整個安全性的目標、範圍、原則、優先順序、標準與策略。安全性計劃的成員是公司的資深高階主管。因此「安全性管理群組」是由中階經理與實作及管理安全性計劃原則的報告小組所組成。

安全性計劃應該使用由上至下的方法進行開發，也就是說，起始、支援與方向都必須出自上層管理人員，然後向下經過中階管理，最後是所有員工。然而，支援可能是安全性管理中由上至下、由下至上，或由中至外的各種構想開發與支持的結合。現今許多公司是以由下至上的方法進行開發及支援，而 IT 部門則是在沒有適當管理支援與方向的情況下，開發安全性計劃。這樣可能會導致安全性計劃與公司的較大商業目標不相符。

資深管理階層必須在公司內，指派進度所需的角色與責任，以開始建立安全性計劃。資深管理階層的參與可以讓計劃保持強固，並隨著業務與技術環境的變化而成長發展。在安全性計劃內建立角色可以確認公司視安全性為是企業整體的一部分，而不僅僅是單純的關切而已。

除了安全性計劃以外，管理階層中必須建立安全性管理群組。安全性管理群組可以直接監視安全性計劃的主要各層面。公司中的安全性計劃通常會發展成安全性原則，而安全性管理群組則可以強制執行並監控安全性設定。

視公司、其安全性需求及環境規模大小而定，安全性管理可以由個人或群組所組成，並以集中或分散的方式進行運作。

評定

處理序模型所描述的威脅評定安全性架構是設計用於協助安全性專業人員發展策略，以保護公司 IT 基礎結構中資料的可用性、完整性與機密性。資訊資源管理員、電腦安全性主管以及系統管理員可能會對此架構有興趣，尤其對嘗試建立電腦安全性原則的人員更具特殊價值。因為此架構提供系統化的方法進行這項重要的工作，而且最後預防措施也包含了在發生損毀的情況下建立應變計劃。

機密性

公司的 IT 基礎結構可能包含必須保護且未經授權不可洩露的資訊。範例包括了特定時效的資訊傳播，例如產量報告、個人資料或企業專屬的資訊。機密性可以確保在資料處理的各樞紐環節，提供必要的機密層級，防範資料洩露給未授權的人。資料存放於系統與網路中的裝置上時，必須在傳輸與到達目的地時，維持一致的機密性層級。

完整性

IT 基礎結構中所包含的資料必須加以保護，防止未經授權、非預期的、或無意中的修改。範例包括統計調查資訊、經濟指標、或財務交易系統。只要能確保資訊與系統的精確度與可靠性，並防止未授權的資料修改，就能維持資料的完整性。

可用性

IT 基礎結構不僅包含資訊，同時也必須適時提供服務，以符合任務需求或避免重大損失。範例包括能夠保障安全、維持壽命及一致性網路連接的重要系統。可用性確保已授權的個人能夠適時、可靠地存取資料與資源。

安全性管理員必須決定要投入多少時間、金錢與精力，才能開發適當的安全性原則與控制。公司應該分析本身的特定需求，然後決定資源、排程、需求與限制。電腦系統、環境與組織政策各不相同，會使制定策略保障公司電腦群組的安全變得非常困難。

雖然安全性策略可以為公司省下寶貴的時間，並隨時提醒所需完成的事項，但安全性絕不是一勞就能永逸的活動，而是環境中系統生命週期整體的一部分。本章中所描述的活動大體而言是需要定期更新或視需要加以修正。當組態或其他條件大幅改變時，或是當公司規定與政策必須更改時，才會進行更新或修正。這是一項不斷反覆且永無休止的處理過程，應該定期加以修訂及測試。

組織整體性評定

建立一套有效的安全性原則與控制必須運用策略，以判斷電腦系統及目前保護系統的安全性原則與控制中所存在的弱點。檢視時應該要記下環境中原則不足的部分，同時檢查現有的原則記錄。除了檢視原則之外，公司的法律部門也必須確定所有的安全性原則均與公司的法律政策相符。電腦安全性原則的目前狀況可以透過下列清單進行判斷：

實體電腦的安全性原則，例如實際的存取控制
網路安全性原則 (例如，電子郵件與網際網路原則)
資料安全性原則 (存取控制與完整性控制)
應變措施以及損毀修復計劃與測試
電腦安全性講習與訓練
電腦安全性管理與協調原則

其他包含機密資訊的原則記錄，包括：

電腦基本輸入/輸出系統 (BIOS) 密碼
路由器設定密碼
存取控制記錄
其他裝置管理密碼

威脅分析

建立一份威脅清單 (大多數的公司都能找出數項威脅)，可以協助安全性管理員識別各種可用於攻擊的弱點。由於維護安全性的方法、工具和技術會不斷地推陳出新，所以安全性管理員必須隨時吸收、更新這方面的知識。

威脅分析處理程序在圖 3.1 的規劃階段中扼要概述，以供判斷可預期的攻擊，然後開發防堵這些攻擊的各種方法。但由於無法針對所有的攻擊做準備，因此必須對公司所預期的最可能攻擊做好準備。如此可以防止攻擊或將攻擊機率減到最小，總比攻擊發生之後再修復損毀好得多。

為了將攻擊減到最低，必須了解導致系統風險的各種威脅，並且運用因應的技術彌補安全性控制之不足與現有安全性原則的弱點。了解攻擊的這三大要素，雖然不能預測攻擊的時間或地點位置，但有助於預測攻擊發生的情形。預測攻擊其實就是預測攻擊的可能性，需視對攻擊各方面的了解而定。攻擊的各方面可以用下列等式表示：

威脅動機 + 剝削利用的方法 + 資產弱點 = 攻擊

惡意的攻擊者可能會使用各種不同的方法發動相同的攻擊。因此，安全性策略必須就各種類型的威脅發動者所運用的各種方法量身訂製。

弱點評定

評定公司的安全性需求必須包含判斷與已知威脅相關的弱點。這項評定必須辨認公司所有的資產類型以及所受到的損壞程度。

判定來自攻擊的可能損壞

在環境中對資產可能造成的損壞，從輕微的電腦小故障到大規模的資料損失都包含在內。對系統造成的損壞將視攻擊的類型而定。可能的話，可以使用測試或實驗室環境，釐清不同攻擊類型的損毀後果。如此可以安全人員精確地評定實際的損壞。但並不是所有的攻擊都會導致相同類型或數量的損壞。可能執行的測試包括：

在實驗室系統上進行電子郵件病毒的模擬性攻擊，接著再進行分析，判斷所造成的損壞及所需的可能修復程序。
進行測試，以判斷員工是否可能受到特定目標的社交工程攻擊，嘗試從毫不起疑的員工取得其使用者名稱和密碼。
資料中心遭遇重大損毀的練習或模擬。測量生產時間的損失與復原所耗費的時間。
惡意病毒攻擊的模擬。測量復原一部電腦所需的時間。可以將這項時間因素乘以系統中受影響的電腦數目，以確定當機時間或生產力的損失。

在此處理程序中加入意外回應小組也是個好主意，因為小組比個人更容易發現已發生的所有不同類型損壞。意外回應小組負責管理安全性意外事件的優先順序與逐步提升的路徑，以解決意外事件。

判斷攻擊可能會剝削利用的弱點與漏洞

如果能夠找出特定攻擊可能會剝削利用的弱點，就可以修改目前的安全性原則與控制，或是實作新的政策，將弱點減到最少。判斷攻擊、威脅與方法的類型，可以更容易地發現現有的弱點。透過執行滲透測試，就可以證實這些弱點。

安全性風險規劃與排程

對於每種剝削利用的方法，公司的安全性計劃中應該包含事前防範與事後反應的策略。

事前防範 (或攻擊發生前) 策略是一套步驟，可以協助將現有的安全性原則弱點減到最少，並且開發應變計劃。判斷攻擊可能對系統造成的損壞，以及攻擊期間被利用的漏洞與弱點，可以協助開發事前防範策略。

事後反應策略 (或攻擊發生後) 策略可以協助安全人員評定由攻擊造成的損壞、修復損壞或實行在事前防範策略中所開發的應變計劃、記錄經驗並從中學習，同時也讓業務功能儘早回復正常運轉。

事前防範策略

事前防範策略是一套事先定義的步驟，必須在攻擊發生之前執行，以防止攻擊的發生。這套步驟包括查看攻擊對電腦系統可能造成的影響或損壞，以及攻擊所剝削利用的弱點 (步驟 1 和 2)。在這些評定中取得的知識有助於實作可以控制攻擊或將攻擊減到最低的安全性原則。下面列出事前防範策略的四個步驟：

判斷攻擊可能造成的損壞。
判斷攻擊所剝削利用的弱點與漏洞。
將前面兩個步驟中定義的特定攻擊所利用的弱點與漏洞減到最少。
判斷要實作的適當反制層次。

遵循這些步驟，分析各攻擊類型可能會產生的附帶好處是：所出現的模式會顯示不同攻擊的重疊因素。這個模式可能有助於判斷對企業造成最大風險的弱點與所在。

注意 必須在損失資料的代價與實作安全性控制的成本之間取得平衡。權衡這些風險與成本的輕重也是系統風險分析的一部分。

事後反應策略

在為攻擊所準備的事前防範策略失敗時，就必須實作事後反應策略。事後反應策略會定義在攻擊期間或之後必須採取的步驟。它可以協助識別所造成的損壞與攻擊所利用的弱點。事後反應策略也會判斷發生攻擊的原因、修復攻擊造成損壞的方法，以及實作應變計劃的方式。

將事前防範與事後反應策略配合運作，以開發安全性原則與控制，使攻擊程度與所造成的損壞減到最低。意外回應小組應該在攻擊期間或之後納入所採取的步驟中，以協助評定、記錄，並從意外事件中學習。

事後反應策略中包含下列三個步驟：

限制損壞。

包含在攻擊期間所遭受的損壞，可以限制更進一步的損壞情形。例如，如果環境中遭受病毒侵害，即立刻中斷伺服器與網路的連線，甚至必須在查出有多少伺服器受影響之前切斷連線，儘可能地限制損壞。這項作業必須迅速地執行。
評定損壞。

判定攻擊所造成的損壞。這項作業應該儘可能地迅速完成，以便讓公司的作業能儘快地重新運作。如果無法及時評定損壞，就應該執行應變計劃，以便使公司的作業與生產力繼續運轉。
判斷造成損壞的原因。

若要判定造成損壞的原因，必須了解攻擊所對準的資源目標，以及為取得存取權或中斷服務所利用的弱點。檢視系統記錄、稽核記錄與稽核追蹤。這些檢視通常有助於發現攻擊源自系統何處，以及有何其他資源受到影響。
修復損壞。

請務必儘快地修復損壞，回復正常公司作業及任何因攻擊而損失的資料。公司的損毀修復計劃與程序必須包含還原策略，以及意外回應小組，以處理還原與修復程序，並提供修復處理程序指引。在此處理程序中執行應變程序，以限制損壞更進一步擴大並且加以隔離。

應變計劃。

應變計劃是另外開發的替代方案計劃，以應付萬一攻擊滲透系統而損壞資料或其他資產，導致正常公司作業中斷或是生產力減緩。如果系統無法及時還原，即必須執行應變計劃。最終目標是要維持可用性、完整性、機密性以及資料的可用性，所以應變計劃就等於是「B 計劃」。

必須建立應變計劃，以對付各類型的攻擊與威脅。各計劃應該包含在遭受攻擊時必須採取的一套步驟。應變計劃應該持續地具備：

說明執行任務的人員、時間與位置，以便讓公司維持運轉。
定期地排練，讓員工隨時掌握目前應變步驟的最新資訊。
包含了備份伺服器的還原資訊。
必須更新防毒軟體、Service Pack 與 Hotfix。
包含將生產伺服器移到另一個位置的程序。如果有可用的經費，則應該在策略性應變位置上收集生產伺服器複寫。
包括目前安全性原則與應變計劃的事後剖析檢討。

下列各點概述在開發應變計劃時，應該進行的各項評估工作：

評估公司的安全性原則與控制，以便利用任何機會，將弱點減到最少。此評估作業應該包含目前的緊急計劃與程序，並整合納入應變計劃中。
評估目前的緊急回應程序及其對公司作業的影響。
開發計劃完備的攻擊回應，並整合到應變計劃中，記下能適當限制損壞的程度，並且將對資料處理作業的影響減到最低。
評估備份程序，其中包括最新的文件記錄與損毀修復測試，以評定其合宜性，並納入應變計劃中的評估結果。
評估損毀修復計劃，判斷所需步驟是否適當，以提供暫時或長期作業環境。損毀修復計劃應該包含測試公司所需的安全性程度，以便讓安全人員判斷是否能繼續保障整個復原處理程序、暫時作業的安全，並且可以移回公司原有的處理網站或移到新網站上。
制訂詳細的文件記錄，概要敘述所需的各種發現，以實施上述工作。此文件記錄應該列出：
- 使用者測試應變計劃的情節演練細節。
- 相依條件對應變計劃的影響細節，例如從公司外部取得協助與重要資源等。
- 修復作業中所看到的優先順序清單，及用於建立的目的。
- 提升路徑的細節，以便在執行應變計劃時，將任何可能從中衍生的議題清楚地提升回報交給最有效率的 IT 或公司作業人員。

實作

請小心！不要執行太嚴苛的控制，因為資訊可用性可能會因而變成問題。必須謹慎地在安全性控制與資訊存取之間取得平衡。

模擬攻擊測試

安全性策略的最後一項因素 - 測試與檢視測試結果，是在適當安置事後反應與事前防範策略之後執行。在測試或實驗室系統上執行模擬攻擊，可以評估產生各種弱點的位置，然後調整公司的安全性原則，依此進行控制。

這些測試不應該在實際生產系統上執行，因為後果可能很慘。但是，由於預算的限制，缺乏實驗室與測試電腦可能無法進行模擬攻擊。為了確保測試所需的必要經費，必須讓管理階層了解風險與攻擊所導致的後果，以及為保護系統所必須採取的的安全措施，以保護系統，包括了測試程序。可能的話，所有攻擊情節演練都應該實際進行測試並加以記錄，以決定需要實作的最佳可能安全性原則與控制。

某些攻擊 (例如自然天災) 便無法加以測試，但是模擬狀況會很有幫助。例如，可以在伺服器室模擬火災演習，造成其中所有的伺服器完全受損。這項損毀情節演練可能有助於測試系統管理員與安全人員的反應能力，並且可以確定公司再度運轉所耗費的時間。

根據測試的結果調整安全性原則與控制，是不斷反覆進行的處理程序。這項程序是永不停止的，必須定期評估與修訂，以便實作改進部分。

操作

清楚定義的提升路徑與問題管理是「意外回應」計劃的主要成份。在安全性專案中及早一致地執行「意外回應」計劃，小組可以更有效地在整個企業中解決問題。記錄結果並從安全性專案中學習，對隨著新專案推進發展的每一個人而言都有幫助。從作業程序中得到的各種教訓，會使下一個安全性專案的評定、開發與實作工作更容易。

意外事件回應

如果公司要完整地實作安全性計劃最佳實務練習，就必須要建立意外回應小組。事前防範措施必須包含意外回應小組，以確保系統安全，其中包括：

開發意外事件處理指引。
準備逐步提升的路徑和程序，交給執法機關，調查電腦犯罪情形。
識別軟體工具，以回應意外事件。
研究開發其他的電腦安全性工具。
進行訓練與警覺性活動。
進行病毒研究。
進行系統攻擊研究。

這些努力都能為公司提供有用的知識，在意外事件發生期間或之前解決問題。

安全性管理員必須負責公司所需的監視及管理安全性稽核的工作。安全性管理員應該擅長這方面工作的個人或小組，才能負責實作安全網域的安全性原則。在安全性管理員與意外回應小組完成所有事前防範功能之後，管理員應該將處理意外事件的責任轉交給意外回應小組。

但這並不表示安全性管理員不再是小組的一份子，而是表示安全性管理員可能無法隨時待命，所以意外回應小組必須能夠自行處理意外事件。小組將負責回應意外事件，並且也必須參與分析任何有關電腦或網路安全性的不尋常事件。

文件記錄與學習

攻擊發生之後立即記錄是很重要的步驟。文件記錄應該包含已知攻擊的所有方面，包括攻擊造成的損壞 (硬體、軟體、資料損失和生產力損失等)、在攻擊所利用的弱點和漏洞、損失的生產時間、修復損壞所採取的處理程序，以及修復所花費的成本。文件記錄有助於修正事前防範策略，以防止將來再遭受攻擊，並將損壞程度降到最低。

實作應變計劃

如果已有應變計劃，則可以節省時間，並讓公司作業保持運作順暢；如果尚無應變計劃，則可以根據先前步驟的文件記錄，發展適當的應變計劃。

檢視結果並執行模擬

攻擊或防堵攻擊之後，檢視公司中系統方面與事前防範策略相關的結果。檢視應包括生產力損失、資料或硬體損失，以及攻擊後回復所耗費的時間等各方面的詳細資料。同時，應該在測試環境中執行模擬，且環境必須與生產環境類似，以達到最佳效果。

檢視並調整原則效用

如果已經有防堵已發生攻擊的原則時，則必須加以檢視，檢測其效用；如果沒有，則必須擬定新原則，以預防將來發生攻擊或將攻擊減到最少。

當現有原則的效用並不合標準時，就應該根據標準加以調整。更新原則必須與相關管理人員、安全性管理員、IT 系統管理員與意外回應小組進行協調。所有原則都應該遵守公司的一般規則與指引。例如，公司的標準工作時間可能是從上午八點到下午六點，更新或建立安全性原則時，可以指定使用者只能在這段時間之內登入系統。

回到頁首

安全性風險管理準則

下列各節描述現今通行運用 MSF 與 MOF 且已經驗證的安全性分析方法。MSF 為專案生命週期的規劃、建立、鞏固及部署階段提供指引，在企業架構和基礎結構部署等方面有所著墨。MOF 則對如何開發或改善資訊科技 (IT) 作業的管理系統提供建議。安全性風險管理準則 (SRMD) 將在此詳細請明，提供可套用在您環境中的學習經驗。SRMD 是詳細的處理程序，可用於判斷對特定公司影響最大的威脅和弱點。

識別安全性風險

安全性風險識別是評定公司安全性的第一步。若要有效管理安全性風險，就必須清楚指明，讓專案小組能夠形成共識，繼續分析結果，並建立行動計劃解決風險。雖然安全性風險的範圍限於專案小組設法保障的技術，但小組的著重目標必須很廣泛，以因應所有的安全性風險來源，包含技術、處理程序、環境與人員。

腦力激盪是識別安全性風險的方式之一，網際網路上還有許多其他有關安全性議題的資訊來源。公司也可能會有既存的弱點評定或滲透測試，可以檢視審察漸漸浮現的安全性風險。

目標

安全性風險識別步驟的目標是，讓小組建立一份公司資產處於易受攻擊位置的已知安全性風險清單。這份清單必須儘可能地涵蓋有關企業架構各方面的綜合安全性風險，包括，技術、業務、人員與策略。

風險管理是識別風險、分析風險，然後建立計劃加以管理的處理程序。安全性風險是定義為預期的損失，其造成原因或衝擊為：由於系統本身的弱點而預期產生的威脅，以及威脅發動者相關方面的強大實力與決心。

資訊輸入

安全性風險識別步驟的資訊輸入，包括了收集可用的威脅知識、建立目前利用漏洞的方法與技術清單，以及分析可能被利用而危害公司資產的系統與原則弱點。威脅則包括了資訊與系統的任何外來潛在危險。弱點包括軟體、硬體、或程序上的漏洞，只要會成為攻擊的威脅點就是漏洞。這些風險通常是由企業環境中不同觀點所造成的，其中包括業務運作、應用程式、資料與基礎結構架構。

小組的經驗、公司目前的安全性計劃方法的原則、程序、準則、範本，以及技術基礎結構目前狀況的相關資訊，都能協助判斷本步驟的資訊輸入。

安全性小組可以透過資產或以工具進行弱點分析或滲透測試的結果，取得資訊輸入。大家腦力激盪，集思廣義支援工作階段，甚至進行正式的安全性研討會，收集小組與股東對安全性議題的看法觀念，將能有效地取得資訊輸入。

風險識別活動

在安全性風險識別步驟中，小組必須清楚地表達公司所面臨的風險，以建立明確的陳述或安全性議題清單。這將有助於組織一系列安全性小組研討會或腦力激盪工作會議，以識別與新情勢有關的風險。

由於技術與環境迅速變遷，千萬不要將安全性風險識別視為能一勞永逸的行動，處理程序必須在公司作業運轉週期中，不斷地定期重複進行。

結構化方法

使用結構化方法處理安全性風險管理是很重要的，因為這樣才能讓所有小組成員使用一致的機制處理安全性議題。在此步驟中將威脅分類是很有用的法，如此可以提供一致且能重現、可量測的方法。

威脅分類

威脅分類 (也稱為類別或系統分類) 為安全性小組提供多種功能用途。在風險識別期間，分類可以幫助刺激思考有關不同領域中發生的安全性風險。在腦力激盪工作會議期間，分類也提供了便利的方法，可以將類似的威脅組成群組，以便在大量威脅下工作的複雜性加以簡化。威脅分類也為小組提供共通的用語，以便用於監視並報告整個專案的風險狀態。

安全性風險陳述

安全性風險陳述是以自然語言敘述公司目前安全性狀態與潛在未實際發生之安全性後果間的因果關係。

安全性風險陳述的前半段稱為「條件」，描述現存狀態或小組認為可能導致傷害的潛在威脅。風險陳述的後半段則稱為「後果」，描述有關資產機密性、完整性和可用性方面不願意發生的損失。

兩項陳述是以「則」或「可能會導致」等詞加以連結，意味著不確定 (換句話說，就是小於 100%) 或因果關係。

下面介紹本手冊所使用的風險陳述：

如果「威脅發動者」使用工具、技術或方法，剝削利用「弱點」，則對「資產」所造成的損失 (機密性、完整性或可用性) 可能會帶來衝擊。

安全性風險陳述可以透過風險分析加以撰寫。風險分析有兩大種方法：定性與量化。不管是定性或量化的方法，兩者都無法凌駕超越彼此，而是提供將風險識別活動結構化的寶貴工具。定性方法建立於量化過程中所收集的資訊上。

圖 3.2 安全性條件與後果風險陳述

下列步驟詳述上圖程序中的每個部分：

定義每個威脅的條件與後果風險陳述。

如果威脅發動者發動威脅並且利用弱點，攻擊就會造成風險。攻擊會減低機密性、完整性或可用性，以損壞資產。因此，攻擊會導致公司發生損失的危機。但是，這些危機可以透過反制措施加以保護。
指定威脅機率 (TP) (0% 最低 - 100% 最高)。威脅機率是潛在威脅發動者侵入環境的機率。
指定臨界因子 (CF) (0% 最低 - 100% 最高)。臨界因子是威脅可能利用漏洞侵入資產的程度。
將作用力分級 (E) (1 最低 - 10 最高)。作用力代表攻擊者利用漏洞所需的技能。
決定風險因子 (RF)。這是臨界因子除以作用力。
使用 (TP x RF) 等式判斷威脅發生率。
將弱點因子分級 (VF) (1 最低 - 10 最高)。判斷弱點對資產所產生的風險有多大。
決定資產優先順序 (AP) (1 最低 - 10 最高)。根據下列準則，決定公司每個資產的優先順序。資產評估是非常複雜棘手的過程，可能要耗費許多時間才能完成。如需更多有關資產評估的資訊，請參閱本章結尾有關此主題的參考資料。決定公司資產的優先順序非常地重要，以此判斷在有限的可用預算下能夠保障多少資產。

為了協助您規劃一份排定優先順序的資產清單，必須依照公司的環境，探究有關每個資產的下列問題的答案：
- 資產對公司的價值為何？
- 維護或保護資產的代價是多少？
- 資產為公司帶來多少利益？
- 資產在競爭下有多少價值？
- 重建或修復資產的代價是多少？
- 取得或開發資產的代價是多少？
使用等式 (VF x AP) 判斷影響因子 (IF)。
使用等式 (威脅發生率 x 影響因子除以 1,000)，判斷顯露度因子 (EF)。顯露度因子是以百分比表示，以便在 3.2 表下的步驟中繼續計算單一預期損失 (SLE)。

分成前後兩半程序規劃產生安全性風險陳述的優點是，可以將資產的可能後果與目前在公司內所觀察到已存在 (也許能夠加以控制) 的狀況相互聯結。其他替代性處理方法是小組只需要專注於識別安全性風險條件，如此在建立安全性風險管理計劃策略時，小組可能必須在後來的安全性風險分析過程中，追溯探究風險條件。

注意安全性風險陳述並非純然是「如果…則…」陳述式；而是探索可能發生但並未實際發生之風險後果的事實陳述。

如果以假設性的「如果…則…」陳述權衡替代方案，然後再用決策樹制定計劃，可能會很有幫助。然而，安全性風險識別階段的目標就是要儘可能地辨識出所有的安全性風險。如此，請將如何分析與管理風險的行動推延到稍後的程序中再進行。

所建立的安全性風險陳述必須包含條件狀況與後果。小組若要進行完善的安全性風險分析，必須審查安全性議題狀況的相似性與自然分類，然後追溯探究每個狀況之間的關係，尋找共通的肇因根源。一旦知道發生狀況的根本原因之後，從原因往下追溯關係也是非常重要的。這樣可以檢視對公司外部資產所產生的影響，更能夠掌握與安全性威脅相關的整體損失或錯失的機會。

在安全性風險識別期間，同一種狀況而有多樣化後果也是常有的事。反之亦然，可能會有幾種不同狀況，全都產生相同的後果。有時候在公司某一部分找出的安全性風險後果，可能會成為產生另一項後果的風險條件狀況。這些條件狀況都應該記錄下來，以便在安全性風險分析與規劃期間做出適當的決策，並且思考安全性風險之間的相依性與關係。

視公司中安全性風險之間的關係而定，降低某種風險可能會降低一整組的相依風險，因而改變公司的整體風險概況。在安全性風險識別階段期間及早記下這些關係，所提供的有用資訊，可以用於制定彈性、全面化的安全性風險規劃，並且有效地審查資源，以解決根本或後階段的肇事原因。對於最重大的安全性風險而言，必須將識別步驟時掌握這類額外資訊的好處，與快速完成後續分析並訂定優先順序，加以衡量，然後在規劃階段重新審查相依性與根本原因。

評估公司中資產的價值

判定資產的現金價值是風險管理的重要步驟。商業管理員經常依靠資產的價值做為指引，決定要花多少金錢保障資產安全。許多公司製作一份資產價值清單，做為損毀修復計劃的一部分。使用下列步驟 8 中詳述的評估模型，協助公司如何訂定資產的優先順序。

若要適當地評做資產，請計算下列三大主要因素：

資產對公司的整體價值。直接以財務觀點計算或估計資產的價值。例如，如果設有電子商務網站，一般是每週 7 天，每天 24 小時的營運時間，每小時從客戶訂單平均產生 $2,000 收益，就可以很有把握地表示，該網站每年銷售營收價值是 $17,520,000。
損失資產對財務產生的立即衝擊。如果上述同一網站有 6 個小時無法使用，則可以計算出每年顯露度是 .000685%。將顯露度百分比乘以資產的年值，就可以預計因此情況而遭受的直接損失是 $12,000。
損失資產對公司造成的間接衝擊。在此範例中，公司估計必須花 $10,000 廣告費，才能抵消因為這次意外事件所造成的負面宣傳效果。除此之外，公司也估計每年 1% 銷售額中損失 .01%，也就是 $17,520。額外廣告費加上每年銷售收益損失，可以預測因此情況而遭受的間接總損失是 $27,520。

表 3.1 資產評估範例

資產	價值	顯露度因子	直接衝擊	間接衝擊
電子商務網站	每年 $17,520,000	每年 6 小時或 .000685 小時	$12,000	$27,520

同時，您也必須考慮競爭對手的資產價值。例如，競爭對手能夠在貴網站當機時，使用先前從貴網站取得的客戶資訊，如此，可能就會被競爭對手搶去業務因而損失數百萬收益。

有許多方法與等式可以用於進行量化的風險分析，也有許多不同的變數會穿插在處理程序中。但是，下列的額外步驟接續上述步驟 10 進行，可以圓滿達成量化安全性風險分析：

判斷單一預期損失 (SLE)。這是發生單一風險所損失的總收益。SLE 是指定給單一事件以元為單位的計數，代表發生特定威脅時，公司可能會損失的數目。計算 SLE 的方式是：將資產價值 (AV) 乘以顯露度因子 (EF)。SLE 類似於定性風險分析。

使用等式 (AV x EF) 判斷 SLE。

顯露度因子代表實際發生的威脅使特定資產造成的損失百分比。如果 Web 伺服陣列 (Web farm) 具有資產價值 $150,000，而一場火災造成的損失估計達其價值的 25%，在此情況下 SLE 為 $37,500。這個數字是以步驟 3 的 ALE 等式衍算出的。
判斷每年發生率 (ARO)。ARO 是一年中可以合理地預期風險發生的次數。若要估計 ARO，請擷取過去的經驗，並參考風險管理專家的意見，並且請教安全性與企業顧問。ARO 類似於定性風險分析的機率。ARO 是從 0% (從不) 延伸到 100% (一直)。

例如，同一公司的 Web 伺服陣列因失火而造成 $37,500 的損壞，而火災發生機率，也就是 ARO，其 ARO 值是 0.1 (表示每年發生一次)，在此情況下，ALE 值為 $3,750 ($37,500 x 0.1 = $3,750)。
判斷每年損失預期 (ALE)。如果不採取任何降低風險的措施，ALE 就代表公司每年將損失的總金額。計算此值的方式是：SLE 乘以 ARO。ALE 類似於定性風險分析的相對等級。使用等式 (ARO x SLE) 判斷 ALE。

公司可以根據 ALE 為建立控制或保全編列預算，以防止這類損壞 (本範例中是每年 $3,750 以下的損失)，並提供適當程度的保護。將風險的真正機率量化、以金錢衡量威脅可能造成的損壞程度是很重要的，這樣才能知道要花多少費用以防護潛在的威脅後果。
使用下列等式，估計反制或保護的成本：

(反制前的 ALE) - (反制後的 ALE) - (每年的反制成本) = 公司的保全價值 (VSC)

例如，攻擊者打垮 Web 伺服器威脅的 ALE 是 $12,000，在實作所建議的保護之後，ALE 的價值估計為 $3,000。每年的維護與保護作業的成本是 $650，因此保護的價值是每年 $8,350，可以用下列等式表示： ($12,000 - $3,000 - $650 = $8,350)。

量化風險分析的輸入項目可以提供清楚定義的目標和結果。下列簡短清單說明一般從先前步驟之結果得來的項目：

指定資產的金錢價值。
重大威脅的綜合清單。
各項威脅的發生機率。
在 12 個月期間每個威脅對公司造成的潛在損失。
建議的保護、反制與採取的行動。

輸出成果

安全性風險識別活動的最少輸出成果是清楚、不含糊、一致同意的風險陳述，透過安全性小組面臨並記錄下來做為安全性議題清單。表格式的安全性議題清單是「安全性風險」管理程序下一階段 - 分析 - 的主要資訊輸入。

安全性風險識別步驟經常會產生大量有用的其他資訊，其中包括識別根本原因、後階段影響、受影響的各個單位、擁有者等等。

保留安全性風險陳述與根本原因，以及安全性小組所開發的後階段影響資訊等記錄，是很正確的作法。如果公司有界定清楚的分類法，在使用安全性風險資訊建立或使用安全性知識庫時，依威脅將安全性風險分類的其他資訊也可能會有幫助。

安全性小組在風險識別過程中，可能要記錄的其他資訊包括：

限制條件
情況
假設
促成因素
安全性風險之間的相依性
相關議題
公司資產擁有者
小組的考量

分析安全性風險並訂定優先順序

安全性風險分析與優先順序是安全性評定程序中的第二大步驟。安全性風險分析包含了將安全性風險資料 (威脅、剝削利用與弱點) 轉換為制定決策助力的形式。訂定安全性風險優先順序可以確保安全性小組成員優先處理最重要的安全性風險。

在此步驟期間，安全性小組會審查安全性議題清單中，在安全性風險識別步驟期間產生的項目，訂定其優先順序，建構成「安全性行動計劃」。

在「安全性行動計劃」中，公司織的安全性小組可以利用安全性議題清單，進行規劃並投入資源，執行以管理環境議題為目標的特定策略。

小組也可以在有安全性議題時，因行動的優先順序太低而指定將其剔除在清單之外。由於此安全性實作階段逐漸接近完成的尾聲，而隨著公司環境改變，安全性風險識別與安全性風險分析必須不斷地重複進行，以確認「安全性行動計劃」的效力。此時可能會出現新的安全性風險，不再是相當高優先順序的舊安全性風險可加以移除、忽略或撤銷。

目標

安全性風險分析步驟的主要目標在於訂定「安全性行動計劃」中各安全性議題的優先順序，以決定哪些議題確實必須投入公司的資源才能降低風險。

輸入資訊

在風險分析過程期間，小組會運用本身的經驗，以及從其他相關安全性風險陳述來源取得的資訊。請參考公司的安全性原則與程序、業界知識安全性資料庫、弱點分析、安全性模擬，以及個別資產擁有者，以取得如何將原始安全性風險陳述轉變為有優先順序的主要風險清單之相關資訊。

安全性風險分析活動

目前已有許多定性與量化技術，可以在「安全性行動計劃」中訂定優先順序。安全性風險分析的簡易技術之一是：使用由兩大公認風險元件衍生而達成共識的小組估計值：機率與衝擊。這兩項估計值可以相乘，計算出單一衡量標準，稱為風險顯露度值。

安全性風險機率

安全性風險機率是安全性風險陳述中確實會發生風險條件所描述狀況的機率測量標準。風險陳述可能會包含公司在時間或金錢以外的因素，例如在下列風險陳述所描述的狀況：

如果「威脅發動者」使用「工具、技術或方法」剝削利用「弱點」...

剝削利用弱點的威脅是風險陳述的部分條件。就特定類型的威脅而言，不一定是剝削利用或已知弱點，尤其是自然災難帶來的威脅。

使用數值表示風險機率是理想的風險分級法。如果安全性風險機率不大於零，則威脅不會構成安全性議題；如果機率是 100%，則確定會有安全性風險，而且可能是已知議題。

機率是出名地難以估計及應用，雖然業界或企業風險資料庫根據大量專案範例提供已知機率估計，可能會有幫助。但是由於專案小組可能是透過自然語言詞彙，以言詞表達描述經驗，將這些語彙對應轉成如下表所述的數值機率範圍，可能會很有幫助。

表 3.2 風險機率

範圍	計算值	表示法	分數
1% 到 14%	7%	極不可能	1
15% 到 28%	21%	很低	2
28% 到 42%	35%	不可能	3
43% 到 57%	50%	一半左右的可能性	4
58% 到 72%	65%	可能	5
73% 到 86%	79%	極有可能	6
87% 到 99%	93%	幾乎確定	7

用於計算的機率值代表範圍的中間點。在這些對應表的協助下，量化機率的替代方法劃分出機率範圍，或是將小組一致同意的自然語言表示法對應為分數。用分數代表安全性風險時，所有安全性風險都必須使用相同的分數值，才能有效地使用於訂定優先順序的處理程序中。

不論量化不確定性所用的技術為何，小組也需要發展衍生風險機率單一值的方法，以表示有關各項風險的一致看法。

安全性風險衝擊

風險衝擊是估計由於對資產不利影響所造成損失的嚴重性，或是因資產失去機密性、完整性或可用性而導致損失的嚴重性。應該是直接的安全性後果測量標準，如安全性風險陳述後半所定義：

則對「資產」所造成的損失 (機密性、完整性或可用性) 可能會導致衝擊。

損失可能是以財務觀點而衡量，也可能是對資產的主觀測量標準範圍。如果所有安全性風險衝擊都是以財務觀點表達，使用財務價值量化損失或機會成本嚴重性的優點是：投資公司的贊助者很熟悉這些說法。財務衝擊可能是作業與支援的長期成本、失去市場佔有率、額外工作的短期成本，或是機會成本。

在其他狀況下，從 1 到 5 或從 1 到 10 的主觀判定標準會更適合用於測量安全性風險衝擊。運用主觀判定標準的情況範例之一是：無法迅速判斷資產的適當淨值。只要「安全性行動計劃」中的所有安全性風險都使用相同的測量單位，通常光是訂定技術的優先順序就已足夠。

表 3.3 資產損失分數制範例

分數	金錢損失
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 - $1 千萬
7	$1 千萬 - $1 億
8	$1 億 - $10 億
9	$10 億 - $100 億
10	超過 $100 億

這種估計衝擊的分數制在公司之間各有不同的意義，應該要反映公司的價值與原則。例如，$10,000 金錢損失對一個小組或公司是可以忍受的，卻可能是另一個小組或公司所無法接受的。以人為高數值 (如 100) 給災難性衝擊打分數，可以確保即使是極低機率的風險也會在風險清單中名列榜首，然後一直保持在最高位置。

安全性風險顯露度值

風險顯露度值可以測量資產的整體安全性風險，並且結合了表示實際損失機率的資訊與以單一估計數值表示潛在損失嚴重性的資訊。安全性小組就可以利用風險顯露度嚴重性，為安全性議題分級。在最簡單形式的量化風險分析中，風險顯露度是以風險機率乘以衝擊而計算的。

當用分數量化機率與衝擊時，有時比較便利的作法是：建立矩陣，考慮分數可能有的組合，並指定為低、中和高風險類別。使用三級的機率分數：其中 1 是低，而 3 是高，加上三級衝擊分數：其中 1 是低，而 3 是高，結果可以用表格形式表示，其中各儲存格都是風險顯露度的可能值。在這種安排下，很容易依遞增分數的對角線帶之內位置而定，將風險分類為低、中和高。

表 3.4 風險分數矩陣

機率衝擊	低 = 1	中 = 2	高 = 3
高 = 3	3	6	9
中 = 2	2	4	6
低 = 1	1	2	3
顯露度範圍：低 =1 - 2；中 =3 - 4；高 = 6 - 9

這種表格形式的優點是，可以利用顏色將安全性風險層次包含在贊助者和股東狀態報告之內 (紅色代表右上角高風險帶，綠色代表左下角的低風險，然後黃色代表沿對角線的中級風險)。容易了解且清楚界定的用語可以提升這些值的溝通能力，因為「高風險」比「高顯露度」更容易了解。

其他量化技術

由於安全性風險分析的目標是訂定安全性風險優先順序、推動「安全性行動計劃」，以及推動製定有關投入資源進行安全性管理的決策，所以安全性小組必須選擇方法，以訂定適合專案、小組與股東的風險優先順序。

有些公司是因使用加權的多重屬性技術，衡量小組要在分級流程中考慮的其他元件內因素而獲益，這些因素包括所要求的時限、獲得潛在機會的強度、機率估計的可靠性，以及實體或資訊資產評估。

在努力執行安全性風險分析與在「安全性行動計劃」中做出不正確或 (對股東) 無可辯解的優先順序選擇之間取得平衡，依此二者之間的協調而定，選取正確的安全性風險分析方法或結合一組方法。應該著手進行安全性風險分析，以支援推動決策的優先順序作業，絕對不要變成只為分析而分析。

為訂定安全性風險優先順序所作量化或半量化方法的結果應該在企業指導準則、原則與程序、資料及技術基礎結構的背景前提下，進行評估。半量化方法是從某種定性化標準開始，讓公司能夠討論出量化安全性標準。

輸出成果

安全性風險分析為小組提供了一份有優先順序的安全性行動清單，做為安全性風險規劃活動的指引。詳細的安全性風險資訊包括：狀況、背景環境、根本原因，以及用於訂定優先順序 (機率、衝擊、顯露度) 的測量標準，經常會依各項風險記錄在風險陳述表中，該表會在本章下文中詳細說明。

安全性風險主要清單

做為行動計劃建立依據的重要安全性風險清單是在「安全性行動計劃」中加以定義。「安全性行動計劃」會找出導致安全性風險的狀況、潛在不利影響 (後果)，以及用於為風險分級的準則或資訊，如機率、衝擊與顯露度。以兩項因素 (機率與衝擊) 做為評估方法的風險主要清單範例如下所示。

表 3.5 風險主要清單與優先順序訂定範例

優先順序	狀況	後果	機率	衝擊	顯露度
1	病毒侵犯電子商務網站	花六小時重新建立伺服器	80%	3	2.4
2	新的程式語言沒有編碼標準	產品可能有更多的安全性弱點	45%	2	0.9
3	無書面規格	未實作某些產品安全性功能	30%	2	0.6

顯露度的計算法是機率 x 衝擊。低衝擊 = 1、中衝擊 = 2 與高衝擊 = 3。

安全性風險主要清單匯集了所有安全性風險評定資訊。這是一份有效文件，構成持續進行的安全性風險管理流程的基礎，應該在整個 IT 生命週期中保持最新狀況資訊，包括評估、規劃、部署與操作等階段。

安全性風險主要清單是支援事前防範或事後反應風險管理活動的基礎文件。可以提供下列準則，讓小組制訂決策：

訂定所付出努力的優先順序。
識別重要的行動。
強調相依性。

用於計算風險所產生顯露度的方法應該仔細記錄在風險管理計劃中，而且必須更加小心，以確保計算能夠精確地記錄小組的用意，權衡比較不同因素的重要性。

若要識別資產的威脅，請執行風險分析。為所識別出的每一項威脅，建立風險陳述。風險陳述結合了有關威脅與發生威脅時所帶來的衝擊資訊。

表 3.6 安全性風險主要清單內容

項目	用途	狀態
安全性風險陳述	清楚地描述風險。	必要項目
機率	威脅發生的量化機率。	必要項目
衝擊	損失的量化嚴重性或機會成本的量值。	必要項目
分級準則	單一重要性測量標準。	必要項目
優先順序 (等級)	優先順序行動。	必要項目
擁有者	確定完全遵照風險行動計劃執行。	必要項目
緩和計劃	描述預防措施。	必要項目
應變計劃與觸發事件	描述矯正措施。	必要項目
根本原因	指引有效的干預計劃。	必要項目
後階段影響	確定適當衝擊預估。	選用項目
背景環境	記錄背景資訊，以記錄小組要讓風險浮現的用意。	選用項目
實作的時間	記錄風險控制在一定時間內實作的重要性。	選用項目

風險陳述表格

分析各項安全性風險時，或是在與特定威脅、剝削利用或弱點相關的安全性規劃活動期間，在稱為安全性風險陳述表格的文件檢視中，檢視與安全性風險有關的所有資訊是很便利的作法。如需有關安全性專案處理程序的進一步詳細資料，請參閱《Microsoft Solution for Security Services Guide》。

一般而言，安全性風險陳述清單中的欄位是取自在識別與評定階段期間建立的安全性風險主要清單，可以用安全性風險管理程序期間小組所需的其他資訊擴大補充。如果風險要指定給安全性小組進行後續追蹤行動，則將安全性風險陳述視為與風險主要清單不同的文件可能會比較容易。開發風險陳述表格時，小組應該考慮的資訊包括：

表 3.7 風險陳述表格

項目	用途
安全性風險識別項	小組所用名稱，僅做為識別風險，以供報告及追蹤之用。
安全性風險來源	安全性風險源起之根本領域的大略分類。用於識別應該尋找安全性風險反覆出現的根本原因領域。
安全性風險條件 (威脅/剝削利用)	描述可能導致損失之現有狀況的用語。這個構成了安全性風險陳述的前半部。
風險後果 (弱點/對資產的衝擊)	描述在風險產生後果時所造成損失的用語。這個構成了安全性風險陳述的後半部。
安全性風險機率	大於零而小於 100% 的機率，代表風險狀況確實會發生而導致損失的機率。
資產衝擊分類	風險可能會產生之衝擊類型的大略分類。
資產顯露度	風險的整體威脅，平衡實際損失與潛在損失量值之間的機率。小組可以使用風險顯露度，進行風險評量分級。顯露度是以風險機率與衝擊相乘而計算的。
風險背景環境	包含其他背景資訊的段落，有助於釐清安全性風險條件。
相關的安全性風險	小組用於追蹤互相依存的風險之風險識別項清單。

首要安全性風險清單

安全性風險分析會衡量各個安全性風險的威脅，以協助安全性小組決定哪些議題值得採取行動。由於管理安全性與相關規劃要耗費其他活動以外的時間和精力，安全性小組所執行的一定是保護最珍貴資產的絕對必要行動。

監視安全性風險的簡單而有效技術之一是，建立重大安全性議題的首要風險清單。然後就可以將首要安全性風險清單向外發佈給所有股東，用在其他安全性可能會受影響的進行中 IT 專案。

公司必須根據幾項因素 (包括時間、資源與資產)，決定首要安全性風險清單中的項目。選取必須管理的幾項重大安全性風險之後，必須分配小組資源以此為基礎，發展計劃。

為安全性風險分級之後，小組應該著重於安全性風險管理策略，以及如何將安全性行動計劃納入整體安全性評定計劃中。

撤銷安全性風險

安全性風險可以撤銷或列為閒置，以便讓小組集中處理其他需要更多事前防範積極管理的議題。將安全性風險列為閒置，代表評定小組已決定在此特定時間不值得費力氣追蹤特定威脅。撤銷安全性風險是在安全性風險分析期間做成決定。

有些安全性風險被撤銷是因為其威脅機率實際上是零，而由於是屬於極不可能的情況，發生機率也會一直維持為零。其他安全性風險被撤銷的原因是，對資產所造成的衝擊在門檻以下，不值得耗費精力規劃事前防範緩和措施或事後應變策略。在這些情形下，遭受這些安全性風險所帶來的潛在後果反而更符合經濟效益。

即使因為顯露度很低而要撤銷位於此資產衝擊門檻之上的安全性風險，也不見得一定是明智之舉，除非安全性小組很有把握機率在所有可預見情況下都會維持低機率 (因而顯露度也低)。切記！撤銷安全性風險與解決風險意義並不相同。已撤銷的安全性風險可能會在某些狀況下重新出現，安全性小組可能會選擇重新將其列為有效風險，而重新展開安全性風險評定活動。

回到頁首

安全性風險追蹤、規劃、排程與報告

追蹤已在「安全性行動計劃」加以識別的安全性風險，然後實作計劃、排程與報告處理程序，以降低減緩衝擊是程序中的下一步驟。小組會根據先前步驟中識別的優先順序，修正技術基礎結構，並實作新的安全性程序與處理程序，在意外事件發生之前改變情勢。

當有風險存在而無法在事前加以管理時，就必須製作反應計劃，在觸發事件後加以執行。建立計劃之後，就規劃建議修正的實作排程。最後，指定小組成員討論處理各種補救措施。

排程包含了將安全性行動計劃實作成評定專案排程所需進行的整合工作，方法是將工作指定給不同的個人，然後不斷追蹤每個人的狀態。

報告作業包含重新定義由於專案和處理程序已改變範圍或定義而有變化的風險。這類報告作業也稱為風險變化管理。報告作業也包含關閉專案內名列首要管理風險的安全性風險。下表以圖表說明整個步驟。

表 3.3 風險追蹤、規劃、排程與報告作業

目標

安全性風險規劃與排程步驟的主要目標是，在安全性風險分析期間，為控制已識別的首要安全性風險發展詳細的行動計劃，然後以標準專案管理程序加以整合，確定行動確實完成。

輸入資訊

安全性風險規劃應該密切地整合在標準專案規劃程序與基礎結構中。請務必注意，安全性評定專案本身就有相關聯的風險，但這些風險與實際的安全性風險本身不同。安全性行動計劃的實作會為專案整體帶來風險，必須使用「MSF 風險管理準則」的方法加以管理。實作「安全性行動計劃」的專案風險通常包含時間、金錢和資源。

輸入安全性風險計劃程序中的資訊不僅包括安全性風險主要清單、首要安全性風險清單，與取自安全性知識庫的資訊，也包括安全性行動計劃與安全性實作排程。

規劃活動

發展計劃以降低資產顯露度時，必須：

著重於高顯露度安全性風險。
解決威脅條件 (威脅、剝削利用) 以降低機率。
找出安全性議題的根本原因，而不是尋找症狀。
解決資產後果 (弱點和資產) 以降低資產衝擊。
判斷安全性議題的根本原因，然後找出由於相同原因而可能會影響相同或其他資產的類似情況。
請注意安全性風險之間威脅、剝削利用與弱點的相依性與互動性。

有幾種規劃方法可以減低不同專案風險狀況，舉例如下：

對於小組能夠控制的專案風險而言，請運用所需的小組資源，以降低威脅狀況的機率。這是事前防範安全性風險管理方法。
對於在小組控制能力範圍之外的專案風險而言，請尋找可以避開的解決方法，或是將安全性風險轉移 (提升) 到有權干預的個人身上。
對於專案風險在小組控制能力範圍之外，而且也無法轉移或進行事前防範管理，小組就應該開發計劃，以降低會對資產造成的衝擊或損失。這是事後反應安全性風險管理方法。

安全性行動計劃

安全性行動計劃有六種主要方法，專案小組在制定安全性風險行動計劃時，應該考量與此處扼要列出之各項相關的問題。下面更詳細地說明各種方法。

研究。安全性小組對這項安全性風險的了解是否足夠？是否需要更進一步研究威脅、剝削利用、弱點或資產，以便更正確地判斷這些要素的特性，再決定所要採取的行動？
接受。除了制定應變計劃之外，是否願意接受風險而不做任何事前防範措施？如果資產的 ALE 值小於資產值，而且對企業的衝擊也很低，就可以考慮接受風險。如果安全性風險確實發生，公司能否承受後果？
規避。有任何方法可以消除風險來源或資產對風險的顯露度，規避風險發生嗎？這是對風險的極端反應，只有在風險的衝擊超過從資產所獲取的利益時才能進行。公司能否變更實作專案的範圍，規避風險發生？
轉移。是否可以將風險的部分責任轉嫁給另一方，以轉移風險，例如轉嫁給保險或管理服務公司？轉移風險已經逐漸成為保障安全性的重要策略。公司是否能將安全性風險轉移給另一個群體、小組、個人或外部組織，以規避安全性風險？
緩和措施。是否能以事前防範方法改變資產對風險的顯露度，或是改變公司對該資產的依賴，以緩和風險的衝擊？如果 ALE 小於資產的價值，而且可以事先做預防措施，也可以考慮風險緩和策略。緩和措施是主要的風險管理策略。是否可以採取行動，以降低安全性風險的威脅機率或資產衝擊？
應變計劃。是否可以透過事先規劃的意外回應，降低衝擊？適當地建構應變計劃可以在風險變成問題或事故時減低衝擊。發生安全性意外事件之後，可以使用觸發事件適當地執行應變計劃。

研究

安全性專案中大多的風險都是與不完整資訊而產生的不確定性有關。與缺乏知識有關的安全性風險經常都可以在開始處理之前，藉由深入了解相關威脅、剝削利用、弱點或資產本身，而有效地加以解決或管理。

例如，小組可能會選擇執行弱點評定，或進行安全性演練，以便深入了解環境或是小組對安全性被攻破的反應技能，再完成安全性實作計劃。如果小組決定進行研究，則「安全性行動計劃」應該包括適當的研究計劃書，其中應納入要測試的領域和需要回答的議題，包括人力配置與任何必要配備。

接受

有些安全性風險，尤其是與自然災害相關的威脅，根本就不可能以有效預防策略或矯正措施加以干預防止。因此，安全性小組可能會乾脆選擇接受安全性議題。但還是應該發展減輕衝擊的事前防範措施或事後應變計劃。持續不斷地投入監視安全性風險，必須有適當資源，也必須建立追蹤測量標準。

注意接受不代表採取撒手不管的策略。公司的「安全性行動計劃」應該包含所記錄的理由說明，解釋小組為何選擇接受風險。

規避

安全性風險可以識別為：最簡單的控管方法就是改變評定的範圍。以這種方式改變評定的範圍，完全「消除」安全性風險，稱為規避防止技巧。在這種情況下，「安全性行動計劃」應該包含做此決定的理由說明記錄，而安全性實作計劃應該使用所需的任何設計變更或範圍改變處理程序加以更新。

轉移

有時安全性風險可以轉移給公司之外的另一公司進行管理。轉移的安全性風險範例包括：

保險。
利用更專業的外部顧問。
外包服務。

轉移安全性風險並不表示已消除風險。一般來說，轉移策略會產生新的安全性風險，而仍需要事前防範管理，但轉移風險可以將威脅降低到更能接受的程度。例如，將 IT 基礎結構外包可能會將安全性風險轉移到安全性小組之外，但在公司設法要保護的資產機密性上，卻可能會引進新的安全性風險。

緩和措施

安全性風險緩和措施必須採取事前防範行動，或是防止安全性風險發生，或是將衝擊或後果降低到可以接受的程度。以事前防範緩和風險的方式管理安全性風險與規避的方法不同，因為緩和著重於防止，並將威脅盡量減到最低的可接受範圍，而安全性風險規避則是改變評定的範圍，以防止發生涉及不可接受風險的活動。

安全性風險緩和的主要目標是：降低威脅發生的機率。例如，使用嚴格的密碼原則會降低外部使用者解開密碼，取得薪資發放制度的機率。

應變計劃

安全性風險應變計劃包含建立一個或多個意外回應計劃，以便在防止攻擊的努力失敗之後啟用。為所有安全性風險建立應變計劃是很好的作法，包括有緩和計劃的風險在內。理由很簡單，不管公司所發展的事前防範安全性計劃有多周密，已知的威脅、剝削利用或弱點還是可能存在，而對資產造成傷害。

安全性應變計劃要包含發生威脅時必須採取的行動，並且必須著重於後果以及如何將資產衝擊降到最低。小組應該建立意外回應計劃與企業回復計劃，以確保能夠在攻擊期間與之後，迅速有效地做出反應。

您可以根據可能遭遇的威脅、剝削利用或弱點類型，建立應變計劃的觸發值。為了安全起見，觸發器通常是事件。也就是說，必須要有方法可以擷取該事件，並通知適當的回應小組，及時展開應變計劃。

應變計劃觸發器有兩種：

時間點觸發器。時間點觸發器是根據日期建立的，一般是必須採取行動的最晚日期。日期訂定的根據可能是公司或法律方針原則所規定必須採取安全措施的時間。
臨界值觸發器。 臨界值觸發器利用可衡量或計數的事物。例如，由入侵偵測系統所擷取的稽核事件可能會值得檢查，可能會啟動應變計劃。

安全性小組務必與公司中其他團隊在應變計劃觸發器及相關標準上達成共識，才不會延誤執行應變計劃。

排程活動

安全性風險管理與控制活動的排程作業與 MSF 一般排程專案活動所建議的標準方法並無不同。安全性小組一定要了解安全性補救措施或控制活動是安全性風險評定與管理預期的一部分。

輸出成果

製作「安全性行動計劃」所得的輸出成果必須包括，事前防範與事後反應安全性管理計劃，使用的是上文所論述的六種方法：研究、接受、規避、轉移、緩和或發展應變計劃。實作這些安全性計劃的特定工作應該整合於標準安全性實作排程之中。如果技術環境有任何變動，都應該記錄在基本規格中。

「安全性行動計劃」與排程應該能解釋在投入的資源與範圍中進行調整，而做出一組安全性行動項目，指定要由安全性小組成員完成的各項工作。安全性風險主要清單應該更新，以反映包含在事前防範 (緩和) 與事後應變計劃中的其他資訊。將安全性風險管理計劃摘要總結成安全性風險行動表格的單一文件檢視是很便利的作法。

更新安全性實作排程與安全性實作計劃

安全性實作計劃必須同時包含事前防範與事後反應計劃。更新安全性實作計劃時，請考慮下列各項因素：

風險條件狀況，包括風險發生的機率與衝擊

狀況改變，例如發生風險的機率提高，或風險的財務衝擊降低，需要小組更新風險管理計劃。
緩和嘗試的效力

小組可能會發現某些緩和嘗試沒有效力。這種現象經常發生在實作技術原則以後，與業務處理程序相衝突。員工有時會繞彎規避破壞技術原則，以達到業務目標。
應變計劃與觸發器的效力

經過一段時間，風險管理計劃中所識別的安全性風險就會發生。發生安全性意外事件之後，判斷應變計劃的效力如何，以及啟動反應的觸發器是否有效。

小組應該在下列三段時間內監視安全性風險：

即時。使用諸如入侵偵測之類的軟體，持續不斷地監視電腦與網路裝置，根據風險狀況事先做成決策。
定期。定期評估風險，如兩個月或四個月評估一次。
臨時。在未排程的間隔中評估風險。臨時監視經常是在回應安全性重大意外事件或網路變動時執行。

回到頁首

安全性風險補救措施開發

發展反制措施與作業程序是公司必不可少的安全性策略。安全性風險可以透過技術強化處理，或是發展包含整個公司的原則，做事前防範管理。

作業系統、應用程式或資料庫的預設安裝程序經常都將安全性設定訂得較為鬆散，以簡化 IT 系統管理員或軟體開發人員的作業。為這些技術進行生產部署之前，部署中的技術必須成為「強化程序」的一部分。有關強化成員伺服器與特定伺服器角色的詳細資料，請參閱本手冊第 6 章＜強化基礎 Windows 2000 Server＞與第 7 章＜強化特定伺服器角色＞。

伺服器強化程序可能會包含移除預設的安全性設定及不必要的軟體元件。IT 人員也應該了解已知技術弱點的目前最新狀況，以及目前利用安裝最新版軟體與安全性 Hotfix 的剝削。

安全性策略發展處理也包含追蹤與報告尚未實際發生之安全性風險的系統、原則與程序開發作業。以協助確保技術基礎結構中的防範措施運作正常，同時也能驗證任何新原則和程序是否有效。

其中也應該設置報告系統，以擷取需要立即因應處理的可疑事件或潛在威脅。除了自動化安全性風險追蹤系統以外，也可以使用手動處理程序。追蹤安全性風險可以讓專案小組調整計劃，以便納入新的安全性風險。

追蹤是風險行動計劃的監視功能。追蹤是有效實作安全性行動計劃的必要條件。追蹤可以確定防範措施或應變計劃是否在專案有限資源之內及時完成。在風險追蹤期間，小組執行的主要活動是監視風險測量標準，並確定事件已確實觸發，讓計劃中的風險行動發揮作用。

目標

補救措施開發處理的目標是：記錄必要的結構變更，同時展開任何新處理程序或變更。

輸入資訊

安全性風險補救措施開發程序的主要資訊輸入是安全性風險計劃，其中包含特定安全性緩和措施，以及公司安全性風險之特定威脅、剝削利用與弱點的應變計劃。補救措施開發也需要開發系統與處理程序，以監視可能執行的應變計劃之識別觸發器。

開發活動

安全性風險補救措施程序中的開發活動類似於一般基礎結構開發專案中的開發活動。例如，開發系統修補程式的變更管理方法。基礎結構的設計變更必須記錄在功能規格中，可能必須修改原則與程序，以納入新的安全性需求。在此程序中，如果已經安裝執行新系統，提供監視與稽核功能，則系統的設計與管理也都必須清楚指明。

可能指定時間點觸發標準並持續追蹤的專案制度範例，舉例如下：

應用程式、服務或作業系統未解決的公開安全性公告。
基礎結構工程師每週記錄的平均加班時間。
每週需求版本或變更管理要求的數目。

風險狀態報告也應該在此階段開發。風險報告應該在兩個層面上操作：小組本身及對外部專案委員會報告。

對安全性小組而言，定期的狀態報告應該考慮到適用於各項風險的下列四種可能風險管理情況：

風險已解決，完成風險行動計劃。所有已解決的風險都應該記錄為結束，並封存在「安全性行動計劃」中。
風險行動與風險管理計劃協調一致並按排程執行。
有些風險行動會與風險管理計劃不同，此時應定義並實作矯正措施。
一個或多個風險的條件狀況已大幅改變，因此應該重新規劃制定風險行動計劃。

在對外部專案委員會及其他專案股東報告時，小組應該報告首要風險，然後再摘要總結風險管理行動的狀態。顯示先前的風險等級，以及每個風險列入首要風險清單中的次數，也都很有用。

當專案小組採取行動管理風險時，專案的風險顯露度總計應該會開始接近可接受的程度。

輸出成果

補救措施階段的輸出成果是必須在下列各處更新的任何安全性變更規格：

功能規格
操作原則與程序
已更新的安全性實作計劃
已更新的安全性實作排程

回到頁首

安全性補救措施測試

安全性補救措施測試步驟的設計是要確保安全性計劃的效力確實經過測試。專案小組應該積極執行與事前防範及事後反應策略 (反制與程序) 相關的測試活動，以判定「安全性行動計劃」的效力。

若要測量新開發反制措施、原則與程序的效力，應該檢查當初設計處理的每一項風險，然後為各風險測試相關的策略，包括威脅、剝削利用、弱點與公司中的資產。

可能也需要根據安全性風險補救措施測試，修正安全性行動計劃，以改善對安全性觸發事件的效力、有效性與回應能力。

然後再將從執行安全性測試計劃學習得來的結果與教訓納入測試記錄中，成為公司安全性知識庫的一部分。在測試期間儘可能多擷取資訊非常地重要，以判斷這些計劃的功效。

目標

安全性補救措施測試程序的目標是：測試專案小組為首要安全性風險所建立各種安全性計劃的效力。安全性行動計劃應該評估及測試下列各項目：

應變與緩和計劃效力。
與應變計劃觸發器或事件相關的安全性標準。
技術反制措施。這項作業可能會包含次要的弱點評定，判斷是否已正確實作。

輸入資訊

安全性風險控制程序的輸入資訊是安全性行動表格，其中詳細列出專案小組成員實際要執行的活動，以協助解決各項安全性議題。測試結果必須記錄事前防範與事後反應計劃的效力，以判斷計劃是否符合公司對安全性的需求。

測試活動

安全性補救措施測試應該測量所開發各項反制措施與意外事件計劃的效力。切記！務必持續不斷地進行安全性風險補救措施測試，以偵測是否會因為新的反制措施而出現任何新的二次安全性風險。

輸出成果

從安全性補救措施測試步驟可以得到的輸出成果是：記錄文件或「議題資料庫」，有助於記錄進度，向完成公司的安全性行動計劃實作邁進。另一項對測試小組有幫助的作業是：概述運作良好的安全性策略、無法運作的策略，以及新建立原則與程序的效力。

回到頁首

擷取安全性知識

應該擷取在安全性評定與實作處理程序中得來的知識，以供將來使用。這是安全性風險評定程序的第六個也是最後階段，在此處要加入策略性、企業或公司對安全性風險管理活動的觀點。

其中最重要的就是：擷取在安全性評定期間發展的反制措施、原則與程序，以供將來的專案小組重複使用。當公司將來再著手從事 IT 開發案時，那些專案可以利用由評定取得的知識經驗，確保所實作新解決方案的安全。

從安全性風險評定學到的知識經驗必須能夠及時地記錄下來，以提供最新的資訊。擷取安全性知識經驗時，應著重於三大主要目標上：

擷取所學到的教訓，尤其是關於安全性風險識別與成功的緩和策略，以使其他小組從中獲益，進而貢獻給安全性知識庫。
提升操作就緒的效力，按照公司執行意外回應計劃，以及在其他領域重複使用的能力而討論。
從小組擷取意見回饋，以改善安全性風險評定程序。

擷取安全性風險學習經驗

安全性風險分類是功能強大的工具，確保從先前經驗學到的教訓可供將來執行安全性風險評定的小組使用。下面是使用下列風險分類，所記錄學習教訓的三大方面：

新風險。如果小組遭遇到先前未曾識別的為安全性風險議題，應該檢視是否有任何跡象 (威脅、剝削、弱點或其他識別項) 可能會預測有安全性風險。現在的安全性風險清單可能必須進行更新，以便在將來協助識別安全性風險狀況。另外，小組也可能已經識別出新安全性風險，應該列入現有的安全性知識庫中。
成功的緩和策略。同時擷取成功與失敗的緩和安全性風險策略經驗。使用標準的安全性風險分類，提供一個意義的方式可以將相關風險進行分組，使小組能夠輕易找到過去已使用的安全性風險管理策略詳細資料。
成功的應變策略。如果應變計劃成功地保護一種資產的特定類型弱點，則在保護其他資產上也可能很有用。

管理安全性風險學習

使用安全性風險管理技巧的公司經常發現，必須建立結構化方法，才能管理安全性風險。若要順利建立，必須符合下列三個條件：

與安全性小組的人員分攤責任，授予特定安全性風險分類領域的擁有權並准予變更。有關誰該授予擁有權的決定是與資產類型與資產分類有關。
在安全性風險分類與全面對抗複雜度及使用性的需要之間取得平衡。有時為各種專案類型建立不同的風險類別可以大幅地改善使用性。
維持安全性知識庫，以說明安全性風險分類、定義、測試、監視效力準則與測量標準，擷取新安全性措施的使用者與操作經驗。

特定環境的安全性風險分類

安全性風險識別可以透過為特定解決方案實作開發風險分類而加以改進。例如，在應用程式開發專案中，可能有該專案的特定安全性風險分類，相對地，也有基礎結構部署專案的安全性風險分類。隨著在安全性背景環境中取得更多經驗，安全性原則與程序可以訂得更明確，而與成功的緩和策略產生關聯。

安全性知識庫

安全性知識庫是用於封存教訓的正式或非正式機制，以便在將來協助進行安全性風險評定。沒有任何形式的知識庫，公司可能會很難採用事前防範方法，進行安全性管理。

如果此知識庫中記錄了一組已知威脅、剝削利用和弱點，由於有已進行過的研究，如此可以更容易開發緩和計劃，加以應付。安全性知識庫與安全性風險管理資料庫不同，後者是用於儲存並追蹤各項安全性風險項目、計劃與狀態。

開發安全性風險的知識管理作業

安全性風險知識庫是持續改進安全性風險管理作業的重要驅動力。

一開始公司的安全性專案和處理小組很可能沒有知識庫。所以小組每次進行安全性風險評定時，都必須從頭開始。在此環境中，安全性風險管理的方法通常是在遭受攻擊或某些事件觸發專案之後，才會事後反應。在此情況下，公司的目標是：轉換到次高層次的當前安全性風險管理作業。

過了一段時間以後，公司已開發出非正式的安全性知識庫，利用較有經驗的成員所得到的學習經驗，而這些成員不是很熟悉安全性議題，就是對該主題的人員、處理程序與技術方面有專長。這些通常都是透過建立安全性委員會而達成的。這種方法促成積極的安全性風險評定管理作業，可能會透過引進安全性原則而形成事前防範管理。

到達知識庫的第一層開發階段是透過更有結構的方法，進行安全性風險識別。有了正式擷取與索引安全性議題的方法之後，公司更有能力進行事前防範管理，做為開始識別安全性風險的根本導因。

最後，公司擁有詳細完整的記錄，不但包含了可能成為安全性風險的識別項，以及可採用的策略，進而管理安全性風險及其成功率。在這種形式的知識庫下，安全性風險處理程序的安全性識別與規劃步驟能夠以多個小組的共同經驗為基礎，公司可以開始讓安全性風險管理的成本最佳化。

考慮如何實作公司的安全性風險知識庫時，請參考下面的經驗之談：

安全性風險知識庫的價值會隨著工作 (例如，集中注意其他衝擊安全性的專案或持續性操作程序) 不斷重複而提升。
公司執行類似安全性的檢視時，複雜度較低的知識庫比較容易維護。
安全性風險管理不應該排除小組思考安全性風險的需要，而成為完全自動化的處理程序。即使情勢一再重複，企業環境、攻擊的技巧與技術也都是一直在改變。安全性小組必須根據環境中的人員、程序與技術，評定適當的安全性風險管理策略。

回到頁首

摘要

本章說明從 MSF 與 MOF 規劃制定的安全性風險分析方法與處理衍生而來之已證實而通行的作業。內容中詳細說明 SRMD 中所用的程序，以決定保護公司資產的成本。最後，提供組成安全性小組的建議步驟，以建立並執行分析行動計劃，防止對公司環境的攻擊，並在事後反應處理。

其他資訊

如需有關 MSF 的資訊，請參閱：https://www.microsoft.com/technet/itsolutions/techguide/msf/default.mspx。

如需有關 MOF 的資訊，請參閱：https://www.microsoft.com/technet/itsolutions/techguide/mof/default.mspx。

如需有關電腦犯罪的資訊，請參閱：https://www.gocsi.com/press/20020407.html。

如需有關威脅評定的資訊，請參閱：《Threat Assessment of Malicious Code and Human Threats》作者是 Lawrence E. Bassham & W. Timothy Polk：National Institute of Standards and Technology Computer Security Division，網址是：https://csrc.nist.gov/。

如需有關資訊安全性最佳實務練習的資訊，請參閱：https://www.iso-17799.com/。

如需有關駭客攻擊的資訊，請參閱：https://www.hackingexposed.com/。

如需 Microsoft TechNet 上有關安全性威脅的資訊，請參閱：https://www.microsoft.com/technet/security/bestprac/bpent/sec1/secthret.mspx。

如需有關「國家標準和科技機構」(National Institute of Standards and Technology) 資產評估的資訊，請參閱：https://csrc.nist.gov/asset/。

回到頁首