1. 現場恢復
1.1. 傳統的恢復機制意味着必須使受影響的系統脱機，安裝一些備份文件，然後將系統重新聯機
1.2. 涉及一個乾淨的系統，該系統具有正確的配置和未損壞的備份文件，並且會被安裝在故障系統上
- 1.2.1. 最終結果是移除故障系統及其文件，並由新系統接管
1.3. 在仍然在線的系統上使用數據恢復工具
- 1.3.1. 恢復工具可能會對所有現有配置執行一次更新，將它們更改為正確的配置
2. 應急計劃
2.1. 組織需要保護其網絡和IT基礎設施不受全面故障的影響
2.2. 應急計劃是制定臨時措施的過程，以便從故障中快速恢復，同時限制故障造成的損害程度
- 2.2.1. 計劃過程包括確定IT基礎設施面臨的風險，然後提出補救策略，以顯著降低風險的影響
2.3. 無論一個組織的預防措施多麼全面，都不可能消除所有風險
2.4. 理解應急計劃與其他業務連續性計劃之間的集成
2.5. 認真制定應急計劃，並注意選擇的恢復策略以及恢復時間目標
2.6. 制定應急計劃，重點放在演練、培訓和更新任務上
2.7. 應急計劃必須針對的IT平台
-
2.7.1. 工作站、筆記本電腦和智能手機
-
2.7.2. 服務器
-
2.7.3. 網站
-
2.7.4. 內部網
-
2.7.5. 廣域網
-
2.7.6. 分佈式系統
-
2.7.7. 服務器機房或公司
3. IT應急計劃流程
3.1. IT應急計劃可幫助組織為未來的不幸事件做好準備，以確保能夠及時有效地應對這些事件
- 3.1.1. 未來的不幸事件可能由硬件故障、網絡犯罪、自然災害和前所未有的人為錯誤引起
3.2. 步驟
-
3.2.1. 開發應急計劃策略
-
3.2.1.1. 一個好的應急計劃必須建立在明確的政策基礎上，該政策定義了組織的應急目標並確定了負責應急計劃的員工
-
3.2.1.2. 所有高級員工必須支持應急計劃
-
3.2.1.3. 關鍵要素
3.2.1.3.1. 應急計劃的涵蓋範圍
3.2.1.3.2. 所需資源
3.2.1.3.3. 組織用户的培訓需求
3.2.1.3.4. 測試、演練和維護計劃
3.2.1.3.5. 備份計劃及其存儲位置
3.2.1.3.6. 應急計劃中人員角色和職責的定義
-
-
3.2.2. 進行業務影響分析
-
3.2.2.1. Business Impact Analysis，BIA
-
3.2.2.2. 將幫助應急計劃協調人輕鬆描述組織的系統需求及其相互依賴關係
-
3.2.2.3. 將幫助他們在制定應急計劃時確定組織的應急要求和優先事項
-
3.2.2.4. 主要目的是將不同的系統及其提供的關鍵服務關聯起來
-
3.2.2.5. 步驟
3.2.2.5.1. 確定關鍵IT資源
3.2.2.5.1.1. 儘管IT基礎設施有時可能很複雜，並且有許多組件，但只有少數組件是關鍵的
3.2.2.5.1.2. IT基礎設施是支持核心業務流程（例如薪資處理、事務處理或電子商務商店結賬）的資源
3.2.2.5.1.3. 關鍵資源是服務器、網絡和通信通道
3.2.2.5.1.4. 不同的企業可能有自己獨特的關鍵資源
3.2.2.5.2. 確定中斷影響
3.2.2.5.2.1. 對於每種確定的關鍵資源，企業應確定其允許的停機時間
3.2.2.5.2.2. 允許的最大停機時間是資源不可用的時間段，且在此期間業務不會受到重大影響
3.2.2.5.2.3. 不同的組織將根據其核心業務流程而具有不同的最大允許停機時間
3.2.2.5.2.4. 最佳停機時間估計應通過平衡中斷成本和恢復IT資源的成本來獲得
3.2.2.5.3. 制定恢復優先級
3.2.2.5.3.1. 確定首先恢復資源的優先順序
3.2.2.5.3.2. 最關鍵的資源，如通信通道和網絡，幾乎總是第一優先級
-
-
3.2.3. 確定預防性控制
-
3.2.3.1. 組織將掌握有關其系統及其恢復要求的重要信息
-
3.2.3.2. 可以用來檢測、阻止或減少中斷對系統的影響
-
3.2.3.3. 有時為可能發生的所有類型的中斷制定預防措施的成本可能會很高
-
3.2.3.4. 從防止電力中斷到防止火災，有非常廣泛可用的預防性控制措施
-
-
3.2.4. 制定恢復策略
-
3.2.4.1. 恢復戰略是用於在中斷髮生後快速有效地恢復IT基礎設施的策略
-
3.2.4.2. 恢復方法
3.2.4.2.1. 備份
3.2.4.2.1.1. 應定期備份系統中的數據
3.2.4.2.1.2. 備份間隔應該足夠短以捕獲最新的數據
3.2.4.2.1.3. 在災難導致系統和其中的數據丟失的情況下，組織可以輕鬆恢復數據—可以重新安裝系統，然後加載最新的備份
3.2.4.2.1.4. 雲備份在成本、可靠性、可用性和容量大小方面具有優勢
3.2.4.2.1.5. 雲備份始終在線，因此它們比外部存儲設備上的備份更可靠、更方便
3.2.4.2.1.6. 雲計算的兩個主要缺點在於隱私和安全
3.2.4.2.2. 備選站點
3.2.4.2.2.1. 應急計劃應提供在替代設施中繼續業務運營的選項
3.2.4.2.2.2. 類型
-
3.2.4.2.2.2.1. 組織擁有的站點
3.2.4.2.2.2.2. 通過與內部或外部實體達成協議而獲得的站點
3.2.4.2.2.2.3. 通過租賃獲得的商業站點
> 3.2.4.2.2.3. 分類
3.2.4.2.2.3.1. 冷站
3.2.4.2.2.3.1.1. 指那些擁有所有足夠的支持資源來執行IT運營的站點
3.2.4.2.2.3.1.2. 該組織必須安裝必要的IT設備和電信服務來重建IT基礎設施
3.2.4.2.2.3.2. 温站
3.2.4.2.2.3.2.1. 指部分設備和維護已達到可以繼續提供已遷移的IT系統的狀態
3.2.4.2.2.3.2.2. 需要一些準備工作才能完全運營
3.2.4.2.2.3.3. 熱站
3.2.4.2.2.3.3.1. 有足夠的設備和人員可以在主站點遭受災難時繼續進行IT運營
3.2.4.2.2.3.4. 移動站
3.2.4.2.2.3.4.1. 可移動的辦公空間，配有託管IT系統所需的所有IT設備
3.2.4.2.2.3.4.2. 主要站點的精確複製
3.2.4.2.2.3.5. 鏡像站
3.2.4.2.2.3.5.1. 冗餘設施，具有與主站點相同的IT系統和數據，並且可以在主站點面臨災難時無縫地繼續運營
> 3.2.4.2.3. 更換設備
> 3.2.4.2.3.1. 一旦發生破壞性災難，從而損壞了關鍵硬件和軟件，組織將不得不安排更換這些硬件和軟件
> 3.2.4.2.3.2. 供應商協議，通知供應商在災難中進行必要的更
> 3.2.4.2.3.3. 設備清單，即組織預先購買關鍵IT設備的更換件並安全地存儲它們
3.2.4.2.3.3.1. 替換設備可以用於主站點的替換，也可以安裝在備用站點以重新建立IT服務
> 3.2.4.2.3.4. 組織還可以選擇使用現有的兼容設備來替換損壞的設備
3.2.4.2.3.4.1. 包括從備用站點借用設備
> 3.2.4.2.4. 計劃測試、培訓和演練
> 3.2.4.2.4.1. 一旦制定了應急計劃，就需要對其進行測試，以確定其可能存在的缺陷以及評估員工在災難發生時執行計劃的情況
> 3.2.4.2.4.2. 必須側重於從備份和備用站點恢復的速度、恢復人員之間的協作、備用站點上恢復的系統的性能以及恢復正常運營的難易程度
> 3.2.4.2.4.3. 測試應在最壞的情況下進行，並應通過課堂演練或功能演練進行
> 3.2.4.2.4.4. 功能演練要求更高，需要模仿災難，並實際教導員工如何應對
> 3.2.4.2.4.5. 把理論培訓作為實踐培訓的補充，並強化員工在演練中學到的知識
> 3.2.4.2.4.6. 至少應該每年進行一次培訓
-
3.2.5. 維護計劃
-
3.2.5.1. 維護計劃是IT應急計劃過程中的最後一步
-
3.2.5.2. 應急計劃需要保持適當的狀態，以便能夠滿足組織當前的風險、需求、組織結構和政策要求
-
3.2.5.3. 計劃需要定期審查並在必要時更新，更新應記錄在案
-
3.2.5.4. 應至少每年進行一次審查，並應在短時間內實施所有注意到的更改
-
4. 風險管理工具
4.1. 自動化可確保風險管理過程的效率和可靠性
4.2. RiskNAV
-
4.2.1. 由MITRE公司開發，是為幫助組織管理其IT風險而開發的高級工具
-
4.2.2. 該工具允許對風險數據進行協作收集、分析、優先排序、監控和可視化
-
4.2.3. 三個維度：優先級、可能性和緩解狀態
-
4.2.4. 詳細信息
-
4.2.4.1. 風險ID/描述：風險的唯一標識和描述
-
4.2.4.2. 風險狀態：風險是否處於活躍狀態
-
4.2.4.3. 風險名稱：風險的名稱
-
4.2.4.4. 風險類別：受風險影響的系統
-
4.2.4.5. 風險顏色：用於顯示風險的顏色
-
4.2.4.6. 風險優先級：風險的優先級是高、中還是低
-
4.2.4.7. 緩解狀態：風險是否已緩解
-
4.2.4.8. 影響日期：風險何時發生
-
4.2.4.9. 指定管理者：負責管理風險的人員
-
-
4.2.5. 該工具就會自動計算每個風險的總得分
4.3. IT and Cyber Risk Management應用程序
-
4.3.1. 由Metric System開發的工具，用於幫助組織採用業務驅動的方法進行風險管理
-
4.3.2. 與其他風險管理解決方案相比，此工具的優勢在於它提供了一個可以查看IT資產、威脅和漏洞的集中點
