Information Security Fundamentals and Practices 資訊安全概論與實務

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

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

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

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

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

6. NIST 800-34 的七個步驟

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

8. 緊急應變政策範例 • ABC 單位資訊技術緊急應變政策： • 所有 ABC 轄下組織都必須為主要應用或一般支援系統建立緊急應變計畫，以符合當重要資訊營運中斷超過七十二小時之需求。緊急應變協調人須將這種能力的執行程序寫成正式的緊急應變計畫，並且每年檢討，若有需要應由緊急應變協調人更新之。這些程序必須包括每晚執行完整備份，並送到指定的異地場所。這個計畫應指派責任給特定的員工或職位的人，來復原或持續重要的資訊功能。應取得並且維持必須的資源以確保程序可行。負責目標系統的員工必須接受訓練，以執行緊急應變程序。必須每年針對這個計畫、復原能力、與員工進行測試，來識別各項能力的弱點。

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

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

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

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

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

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

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

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

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

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

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

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