Information Security Fundamentals and Practices 資訊安全概論與實務 潘天佑博士 主編 版權聲明：本教學投影片僅供教師授課講解使用，投影片內之圖片、文字及其相關內容， 未經著作權人許可，不得以任何形式或方法轉載使用。

第四篇 第15章 緊急應變計畫

世事難料 汐止東科大火 延燒 43小時 損失逾60億 【2001-05-14／聯合報】台北縣汐止東方科學園區大樓發 生國內單一建物延燒最久火災。自前天凌晨四時起失火， 至昨天夜裡十時許熄滅，延燒四十三小時。消防人員雖數 度控制火勢，火苗仍隨著通風管線在大樓內流竄，產險業 者初步估計，共有包括東帝士、宏碁集團等五十三家廠商 受災，損失超過六十億元，實際損失則有待廠商提報及鑑 定；人員部分有二名消防隊員受輕傷。 一手創建東方科學園區的東帝士集團前總裁陳由豪，昨天 趕到現場了解災情，他難掩不敢置信神情，何以合乎防災 規定興建的大樓，會燒得這麼嚴重？宏碁集團董事長施振 榮夫婦也趕到現場，大火雖波及集團許多子公司，但未燒 到D棟宏碁電腦、宏碁科技及集團總部。數位聯合公司 (Seednet) 雖未遭大火直接波及，但因機房斷電，造成代 管近一百三十家網站無法撥接。

災難造成的影響 直接的財產損失：火災或地震等天災常在一夕間破壞建築物與不動產 價值，未充分保險的企業會面臨巨大財務壓力。未妥善備份、備援的 資訊資產也是無法恢復的直接損失。 客戶失去信心：設想一家專業的網路資料中心 (IDC) 被火災燒毀，即使 事後獲得保險理賠，也可能因失去客戶而倒閉。 災害復原成本過大：就算災難後沒有立即的財務缺口，企業未必能支 付持續的復原與重建的成本。 失去關鍵技術或生產能力：資訊資產被毀，可能會失去智慧財產。若 組織只備份「結果」卻沒有「過程」，會造成技術無法複製。 失去主要領導人或技術擁有者：人員傷亡也可能造成企業無法彌補的 傷害，有些企業規定主要經理人不可搭乘同一交通工具。

緊急應變計畫與風險管理 風險管理要識別威脅與弱點，並建置適當的防禦手段來避免事件的發 生或降低它造成的衝擊。 其次，風險管理要識別殘餘風險，讓緊急應變計畫來處理。 緊急應變計畫與風險管理的關係，平時就應做好風險管理與安全防禦 控制，同時準備並演練緊急應變計畫。一旦緊急事件發生，就按照應 變計畫度過難關。 緊急應變計畫 安全防禦控制 風險管理 執行緊急應變計畫 緊急事件

NIST 800-34 的七個步驟 建立緊急應變政策 進行業務衝擊分析 識別預防控制 訂定復原策略 建立緊急應變計畫 訓練、測試、演練 尋找相關條文與需求 核准政策 宣導政策 進行業務衝擊分析 識別主要資訊資源 識別衝擊與承受度 訂定復原的順序 識別預防控制 建置控制 維護控制 訂定復原策略 識別方法 將方法整合進系統架構 建立緊急應變計畫 支援訊息 通知與啟動階段 復原階段 重建階段 訓練、測試、演練 建立測試的目標 設定成功的標準 記錄經驗 整合進計畫 訓練員工 計畫的維護 檢討及更新計畫 協調內、外部組織 控制文件的分發 控制文件的變更

建立緊急應變政策 為了讓全體員工有清楚的認知，建立緊急應變政策 (contingency planning policy statement )是第一步。 高階主管必須支持緊急應變方案，最適合的層級是組 織的資訊長 (Chief Information Officer, CIO)。 緊急應變政策的主要成分應包括： 角色與責任 緊急應變計畫的範圍 所需要的資源 所需要的訓練 演練與測試的時間表 計畫維護的時間表 備份的頻率與媒體備份的存放 建立緊急應變政策 進行業務衝擊分析 識別預防控制 訂定復原策略 建立緊急應變計畫 訓練、測試、演練 計畫的維護

緊急應變政策範例 ABC 單位資訊技術緊急應變政策：

進行業務衝擊分析 建立緊急應變政策 進行業務衝擊分析 識別預防控制 訂定復原策略 建立緊急應變計畫 訓練、測試、演練 計畫的維護 業務衝擊分析 (business impact analysis, BIA) 類似風險 管理中的風險評鑑，它是緊急應變程序的主要環節。 緊急應變協調人 (Contingency Planning Coordinator) 藉 由 BIA 釐清系統的需求、程序、與相互依存性，再以 此決定緊急應變的需求與先後順序，包括： 識別主要資訊資源：有點像風險評鑑裡清查資訊資產，目 的是確定保護的目標。BIA所識別的資訊資源是比較重要 的項目，中斷服務會造成業務重大衝擊。 識別衝擊與承受度：風險管理以防禦措施降低事件發生的 機率與衝擊，但仍留有殘餘風險。例如再多防火措施不可 能根絕火災。BIA識別這種衝擊，並了解組織的承受度。 訂定復原的順序：依據衝擊與承受度的分析來決定哪些設 備或元件需要優先復原。

識別預防控制 (I) 建立緊急應變政策 進行業務衝擊分析 識別預防控制 訂定復原策略 建立緊急應變計畫 訓練、測試、演練 計畫的維護 緊急事件發生後的應變與復原固然重要，但更應採 取事先的預防控制手段來避免事故或降低衝擊。相 較於資訊安全的風險防禦措施，緊急應變計畫裡的 預防控制更針對緊急的、摧毀性的事件。 預防控制可以做的很多，應依據組織的 BIA 做規劃。 以下是 NIST SP800-34 建議的一些項目，可做參考。 適當的裝置不斷電系統 (UPS) 提供短時間的備援電力。 準備汽油或柴油發電機提供長時間的備援電力。 冷氣系統要比需要的更多、更強，以容忍偶發的故障。 充分的滅火設備。 裝置火焰及煙幕感應器。 後頁續

識別預防控制 (II) 在電腦機房的天花板及地板裝置滲水、淹水感應器。 電腦設備上可以覆蓋塑膠布或上油帆布以防護屋頂漏 水造成的損失。 備份磁帶、磁碟等媒體以及重要紙本記錄應置於抗熱、 防水的容器中。 應有緊急總開關可以關閉系統。 備份磁帶、磁碟等媒體、重要紙本記錄、以及系統文 件應做異地存放。 建置技術性的安全控制，例如加密金鑰管理與存取控 制等。 經常且有紀律的備份。

訂定復原策略 建立緊急應變政策 進行業務衝擊分析 識別預防控制 訂定復原策略 建立緊急應變計畫 訓練、測試、演練 計畫的維護 復原策略 (recovery strategies) 讓資訊服務在災後能快 速、有效的恢復。訂定復原策略 應多考慮各種選擇， 包括成本、允許的中斷時間、安全、與企業需求等。 復原策略應該針對 BIA 所分析的潛在衝擊，同時要在 設計階段就整合進系統架構中。 有很多的復原方法可供選擇，會在後面幾頁詳細討論。 這些方法包括： 與提供熱備援、暖備援、及冷備援廠商簽約，建立異地 復原的能力。 使用 RAID、UPS、與故障復原 (failover) 等科技來提升系 統之可復原性。 與設備供應商簽定長期服務合約，在災難時可以得到最 好的支援。

異地備援 冷備援 (cold sites)：具備足夠的基礎設施，如機房、水、電、及辦公 室空間；但是沒有軟硬體設備或電話、傳真等辦公設備。受災害衝 擊的單位進駐後才重新建立系統，需要數周的時間復原資訊服務。 暖備援 (warm sites)：有部分資訊與辦公室設備；平時這個地點及設 備可能做為它用，當緊急應變計畫啟動，受災害衝擊的單位進駐後， 會在現有設備上重建系統，需要幾天到數周的時間復原資訊服務。 熱備援 (hot sites)：隨時軟硬體及人員準備妥當，一旦緊急應變計畫 啟動，可在幾小時內復原資訊服務。 全備援 (mirrored sites)：平時就與主機房完全同步備援，系統完全相 同且資訊即時備份。一旦主機房服務中斷，備援系統立即啟動。

建立緊急應變計畫 建立緊急應變政策 進行業務衝擊分析 識別預防控制 訂定復原策略 建立緊急應變計畫 訓練、測試、演練 計畫的維護 通知與啟動階段 (notification/ activation phase)：當災 難發生時應按程序通知上級和相關人員；經過損失評 估後若有必要，就可以依照程序啟動緊急應變計畫。 復原階段 (recovery phase)：災難發生後，短期的重點 是如何快速地復原資訊服務；這一階段說明復原活動 的順序與標準作業程序。例如一家在台北的公司因淹 水導致機房被毀，復原階段指導如何在二十四小時內 啟動位於桃園的備援設備。 重建階段 (reconstitution phase)：災難結束後就要重建 原地點，當系統重裝或修復並通過測試後，就可以停 止備援系統並結束緊急應變計畫。以上述的例子，重 建階段指導該公司如何在大水退去後重建台北主機房。

事件通知 有的事件發生前會有預報 (例如颱風)，有的沒有 (例如盜匪侵入)。事 件通知程序要因應以上兩種狀況，並且明文載入緊急應變計畫中。 程序書應清楚說明在上班時間及下班或例假日如何通知應變人員。 快速、有效的事件通知是應變的前提。有時候還來得及阻止災害發生， 例如颱風夜漲大水，一家公司立刻堆起沙包，而另一家等到天亮才處 理，兩者的損失將不可同日而語。即使來不及阻止災害發生，快速通 知與反應也有助於復原速度。 「通知樹 (call tree)」是一種常用的事件通知方法。由一個人打電話通 知所有人會花太長時間，所以事先將大家結成樹狀組織，接到通知的 人負責再通知另外幾個人，可以縮短通知時間。 通知的訊息應包括：災害的種類、是否有人員傷亡、資產損失、已採 取的措施、以及對後續行動的指示。

復原階段 復原階段在緊急應變計畫被啟動後開始，這時組織已完成損失評估、 通知相關人員、並已動員各應變小組。 復原活動主要在建立暫時的資訊處理能力，修復受損系統，並在原址 或異地復原資訊服務能力。 復原程序應該逐步的描述每個系統元件的復原順序。例如災害之後若 要復原一個區域網路，應該從最重要的伺服器先恢復，最後才處理不 重要的元件像是印表機。 計劃書要說明什麼狀況需要做異地復原，並且詳細規劃流程。同時要 組成特別小組負責運送設備、資料與重要紀錄。 緊急應變計劃被使用於重大事故或緊急狀態，因此標準作業程序書需 要逐步的清楚描述。不應假設任何人在慌亂中還會有冷靜的判斷力或 足夠的推敲思考時間。

計畫啟動 災難發生以後應優先通知損失評估小組 (Damage Assessment Team)，在評估完系統 所受的衝擊之後，再將結果及應採取的措 施通知相關部門及個人。 若損失符合一個或多個啟動條件 (activation criteria)，緊急應變協調人或資訊長就該啟 動緊急應變計畫。組織可依據以下狀況來 訂定啟動條件，並記載於緊急應變計畫文 件中。 人員傷亡以及設施的損失程度。 系統遭受損失的程度。 遭受損失的系統對組織運作的重要性。 預計服務中斷的時間長度。

重建階段 重建階段是從緊急狀態回復正常狀態，把營運從備援系統轉移回主系 統。這個階段應詳細描述以下操作程序： 確定恢復正常的基礎建設，如水、電、通訊、環境控制等。 重建主系統的軟、硬體。 建立對外的網路連結。 測試系統運作，確定完全正常。 將緊急應變系統上的資料上載到重建的系統上。 關閉緊急應變系統。 結束緊急應變狀態。 清除或處理緊急應變地點的敏感資訊。 人員回到原先的工作場所。

訓練、測試、演練 所有員工都應該熟悉緊急應變計畫，參與應變編組的 人更要接受訓練了解相關程序。 建立緊急應變政策 進行業務衝擊分析 識別預防控制 訂定復原策略 建立緊急應變計畫 訓練、測試、演練 計畫的維護 所有員工都應該熟悉緊急應變計畫，參與應變編組的 人更要接受訓練了解相關程序。 緊急應變計畫必須接受測試，可讓計劃不周延之處浮 現。組織也要經過實境演練才能評估負責災難復原的 員工是否能快速、有效地執行計畫。 要有一個測試計畫來測試緊急應變計畫，下面的領域 應該包括在測試裡： 從備份媒體中將系統復原到不同的平台。 各個應變小組間的協調。 組織內部與外部的連絡。 測試系統在不同設備上的效能。 重建正常的運作。 測試災害通知程序。

計畫的維護 沒人知道災難何時發生，因此緊急應變計畫應該隨時 保持完整可用，並正確反映組織的現況與需求。 建立緊急應變政策 進行業務衝擊分析 識別預防控制 訂定復原策略 建立緊急應變計畫 訓練、測試、演練 計畫的維護 沒人知道災難何時發生，因此緊急應變計畫應該隨時 保持完整可用，並正確反映組織的現況與需求。 為了因應業務需求，資訊系統經常升級或更新。當系 統做重大變更時，就必須檢討並更新緊急應變計畫； 否則至少一年檢討一次。 有些資訊則需要隨時更新，像是緊急連絡人資料。 緊急應變連絡人負責變更緊急應變計畫，每項變更都 應做成變更記錄，並通知相關部門與成員。 有些變更需求較為明顯，例如公司全面導入ERP，自 然要為這個新系統更新緊急應變計畫。但有些變更需 求要重做業務衝擊分析 (BIA) 才會被發現；例如選擇 網路交易的客戶逐年增加，網路斷線造成的業務衝擊 已經超過當初的評估，所以需要變更計畫。