ISC2- CC-Domain 2 -BC/DR/IR

國雖大,好戰必亡;天下雖安,忘戰必危 — 司馬法

本文的重點有:

• BCP(Business Continuity Plan) —
  總體計劃，包括許多子計劃。這是制定長期策略(long-term strategic)業務面的"計劃、政策和程序"的流程，以便在破壞性事件發生後能繼續運作。
• DRP(Disaster Recovery Plan) —
  聚焦於IT 系統。我們如何在災難場景中足夠快地恢復。DRP 具有Mitigation, Preparation, Response and Recovery的生命週期。
• IR(Incident Management) —
  如何監控和偵測系統上的安全事件(Event)，以及我們如何對這些事故(Incident)做出反應。更多的IR資訊介紹，可參閱CISM的IR介紹。

BCP(Business Continuity Plan)"重要"

它適用於整個組織，以及所有可能受到影響的事物，而不僅僅是 IT。 我們首先列出了一系列災難場景以及組織在任何特定場景下必須採取的恢復正常運作的步驟。 BCP 通常包含

• COOP（Continuity of Operations Plan）
• Crisis Communications Plan
• Critical Infrastructure Protection Plan
• Cyber Incident Response Plan
• DRP（Disaster Recovery Plan)）
• ISCP（Information System Contingency Plan）
• OEP)Occupant Emergency Plan)

如果關鍵供應商關閉、工廠發生火災、下暴雨而員工無法上班等。這些事件發生我們會做哪些處理。它們是提前寫好的計畫的，並不斷改進，這是一個迭代過程(iterative process)。 我們根據關鍵員工(也就是大老闆)以及有時外部 BCP 顧問的意見來撰寫 BCP。

C-Level需要參與並致力於 BCP/DRP 流程，因為只有他們才能給出資源。他們至少需要參與計劃的啟動和最終批准。

C-Level對計劃負責，他們擁有計劃，並且由於他們最終承擔責任(理想世界，現實世界不是)，因此他們必須表現出應有的due-care(謹慎) 與due-diligence(盡職調查)。 組織需要自上而下(top-down)的 IT 安全（CC考試假設我們有這一點）。 在嚴重災難中，C-Level或法務/公關部門的人員應該與媒體溝通。 大多數業務單位通常認為自己是最重要的領域(看公司哪個單位最賺錢)，因此他們的系統和設施應該得到優先考慮，C-Level最終承擔責任，而大老闆顯然對優先事項、實施和計劃本身擁有最終決定權。

相關子計畫("重要")

COOP (Continuity of Operations Plan):
如何在災難中持續運營，如何讓員工前往備用地點，即使產能減少長達 30 天，我們也需要採取哪些操運作措施來確保我們正常運作。

Crisis Communications Plan:
這是CMP(Crisis Management Plant) 的子計畫。災難期間我們如何進行內部和外部溝通。誰被允許與媒體交談？ 誰可以在內部與誰溝通甚麼？通常市場上有這一類的公關公司可以幫忙處理。

Cyber Incident Response Plan:
如何應對網路事件(Cyber event)可以是 DRP 的一部分，也可以不是。 這可能是 DDOS、蠕蟲、病毒…

OEP (Occupant Emergency Plan):
在災難事件中我們如何保護我們的設施、員工和環境。 這可能是火災、颱風、洪水、犯罪攻擊、恐怖主義等等。重點關注安全和撤離(safety and evacuation)，詳細說明我們如何疏散、演習頻率以及人員應接受的訓練。在ISC2的觀念中"人命"最重要，其次是財產。

BRP (Business Recovery Plan):
列出了從災難事件中恢復到正常業務運作所需採取的步驟。這可能是將運作從DR Site切換回（已修復的）Primary site。

Continuity of Support Plan:
聚焦於對特定 IT 系統和應用程式的支援(例如企業的ERP)。也稱為 IT 應急計劃，強調對IT 而非一般性業務支援。

CMP (The Crisis Management Plan):
在發生緊急情況或破壞性事件時，使我們能夠在一堆C-Level之間進行有效協調。 詳細說明管理層必須採取哪些步驟來確保在災難發生時立即保護人員生命和財產的安全。

舊版的NIST 800–34( Contingency Planning Guide for Federal Information Systems)將這些步驟作為建立 BCP/DRP 的框架(這類似於專案管理)。

1. Project Initiation:
   啟動專案，確定利害關係人，獲得大老闆批准並正式確定專案結構。
2. Scope the Project:
   準確地決定要做什麼和不做什麼。
3. BIA(Business Impact Analysis):
   識別關鍵系統和組件並確定其優先順序。
4. Identify Preventive Control:
   確定目前可以部署的和可能的預防控制措施。
5. Recovery Strategy:
   怎樣才能有效回復呢？ 我們有什麼選擇？ DR site、系統復原、雲端…
6. Plan Design and Development:
   制定具體的災難復原計畫、程序、指南和工具。
7. Implementation, Training, and Testing:
   測試計劃以找出差距，並訓練員工以便能夠按照計劃採取行動。
8. BCP/DRP Maintenance:
   這是一個迭代過程。 組織發展、加入系統、設施或技術，威脅情況不斷變化，必須不斷改進和調整我們的 BCP 和 DRP。

災難的類別

自然的(Natural):
任何由自然引起的事情，這可能是地震、洪水、暴雨、颱風……它們可能具有很大的破壞性，但比其他類型的威脅可能發生率較小。不同地區的自然災害威脅不同，在我們所處的區域做了風險分析。對於一個地點，我們可以建造具有抗震能力的建築物和資料中心(DC的分級)，而在另一個地點則可以建造具有抗洪能力的建築物和資料中心。

人為的(Human):
任何由人類造成的事情，都可能是有意或無意的。無意的可能是員工在工作時在電腦上使用個人USB 並傳播惡意軟體，就像攻擊者所做的一樣糟糕，但員工只是無知，懶惰或認為這並不重要。有意的可能是惡意軟體、恐怖主義、DOS 攻擊、駭客行動主義、網路釣魚等等。

最難以防禦的就是內部有權限的員工做出無意或有意行動，這會造成錯誤與遺漏(Errors and Omissions)。他們無意損害公司，但他們可能會因犯錯或不遵循適當的安全協議而無意中這樣做。 這可能是打字錯誤，例如沒鎖門就出去抽煙，或是把一盒備份磁帶留在不安全的地方。 它們通常會產生較小的影響，但如果我們遇到被認為非常常見或具有潛在破壞性的問題這稱為humman error。我們可以建立控制措施來減緩它們。 我們可以對打字錯誤進行雙重檢查(這很麻煩，但我們可以使用Teramind來減少此類電腦操作風險)，在未上鎖的門打開 10 秒後發出警報，或對備份磁帶的運輸進行非常清晰的程序和控制。

環境的(Environmental):
我們環境中的任何情況都可能是斷電/超載、硬體故障、供應商問題…

BCP計劃需要不斷更新； 這是一個迭代過程("重要")。計劃應至少每 12 個月審查和更新一次。如果發生了以下事件也必須要更新:

• 更改了系統的主要元件（新的備份解決方案、新的IP 方案…）
• 遭遇了一場災難，計畫有許多缺陷
• 一堆C-Level跑光了，需要新老闆支持這個計畫

DRP — Disaster Recovery Plan(聚焦於IT)

DRP應至少回答以下三個基本問題：

1. 目標和目的是什麼？(objective and purpose)
2. 如果發生任何中斷，誰將負責？(R&R)
3. 當災難發生時，這些人會做什麼（程序是甚麼）？

DRP的生命週期("重要")

• Mitigation:
  減少災難的影響和可能性
• Preparation:
  為回應制定計劃、程序和工具

在Recovery Process中，必須考量可能影響我們的許多因素，如果供應商、承包商或基礎設施也受到影響，就需要考量有哪些選項。我們也許能夠在 12 小時內啟動並運行我們的資料中心，但如果我們沒有對外服務，哪這可能並不重要。

模擬測試(Simulated Tests"重要")能驗證DRP計畫的有效性，方式有幾種:

• DRP review:
  DRP團隊成員會快速檢視計劃，尋找計劃中明顯的遺漏、差距或缺失部分。
• Read-Through (Checklist):
  管理者和職能部門仔細檢查計劃並檢查回復流程所需的組件清單。
• Walk/Talk-through (Tabletop or Structured Walkthrough):
  一群管理人員和主要人員坐下來討論回復流程(紙上談兵)。 通常會暴露出可能阻礙回復的差距、遺漏或技術錯誤。
• Simulation Test (Walkthrough Drill):
  與演練(全部做一次)類似（但有所不同，不要混淆）。團隊模擬災難，團隊以 DRP 中的部分回應。一部分的實際實作。

另外就是實際測試(Physical Tests "重要")了，但也不是百分百(Partial Interruption)。中斷單一應用程式並將其故障轉移到我們的輔助設施(secondary facilities)，通常是在下班時間做的。

看完了Mitigation與Preparation，接下來是Response/Recovery。

• Response:
  我們如何按照程序(Procedure)在災難中做出回應。如何回應以及反應速度對於災難復原至關重要。評估收到告警或發現的事故是否嚴重並可能成為災難(Incident to disaster)，評估(Assessment)是一個迭代過程。隨著團隊的參與，我們了解的越多就可以更好地評估災難。我們通知適當的人員來幫助處理事故（通常是call tree或自動呼叫），通知我們計劃中的C-Level，如果計劃有指示，則與任何其他適當的人員進行溝通。
• Recovery:
  重建基本功能並恢復全面運作。使用計劃進行評估。此時，所有主要利害關係人都應該參與其中，我們對災難有更清晰的了解，並採取適當的步驟進行回復。 這可能是DR Site、系統重建、流量重定向…

BIA (Business Impact Analysis)"重要"

識別關鍵和非關鍵系統、職能和活動。關鍵是指中斷被認為是不可接受的，可接受性也基於回復成本。法律有規定的也可能被視為關鍵。 對於每個關鍵（範圍內）系統、功能或活動，通常會分配兩個值：

• RPO (Recovery Point Objective):
  無法復原的可接受的資料量。復原點目標必須確保不超過每個系統、功能或活動的最大可容忍資料遺失。如果我們每天只備份一次，我們最多接受一天的資料遺失。
• RTO (Recovery Time Objective):
  恢復系統（硬體）的時間長度。恢復時間目標必須確保不超過每個系統、功能或活動的 MTD(Maximum Tolerable Downtime)。

上面是最常談論到的主要關鍵指標。以下還有其他的參考指標:

• MTD (Maximum Tolerable Downtime) ≥ RTO + WRT:
  重建系統並將其配置為重新插安排進入生產環境的時間必須小於或等於我們的 MTD。這也是在組織受到嚴重影響之前，系統可能無法運作的總時間。其他框架可能會使用其他MTD 術語，但為了考試，請了解並使用MTD。另外還有MAD (Maximum Allowable Downtime)、 MTO (Maximum Tolerable Outage)、MAO (Maximum Acceptable Outage)、 MTPoD (Maximum Tolerable Period of Disruption)。
• WRT (Work Recovery Time):
  配置恢復的系統(軟體)需要多少時間。
• MTBF (Mean Time Between Failures):
  新的或修復的系統或組件在發生故障之前平均可以運行多長時間，這可以幫助規劃備料，並讓我們了解硬體發生故障的頻率。
• MTTR (Mean Time to Repair):
  回復發生故障的系統需要多長時間。
• MOR (Minimum Operating Requirements):
  主要系統正常運作的最低環境和網路要求有時也可以滿足DR Site的最低系統要求。我們可能不需要1:1規格的系統來回復業務運作。

回復的策略(Recovery Strategies)"重要"

根據我們的 MTD(Maximum Tolerable Downtime)，可以確定處理災難的方法以及為減輕災難或從中恢復而採取的保障措施。

1. Redundant Site(也是Minimum Operating Requirements):
   與我們的生產完全相同的站點(1:1)，接收資料的即時副本。電力、HAVC、高架地板、發電機等。 如果我們的Primary site 發生故障，Redundant Site將自動將所有流量 fail over到Redundant Site。Redundant Site應該在地理位置上較遠，並且有工作人員在場。 這是最貴的回復選項，終端用戶永遠不會注意到有fail over。
2. Hot Site:
   與Redundant Site類似，但只能跑主要應用程式和系統，通常位於較低規格的系統上。通常仍然是一個較小但完整的資料中心，配備冗餘 UPS、HVAC、ISP、發電機等。 可能必須手動對流量進行fail over，但完整的切換可能需要一個小時或更短的時間。 資料的near-time or real-time副本。
3. Warm Site:
   與Hot site類似，但不具有near-time / real-time資料，通常透過備份進行回復。較小但完整的資料中心，具有冗餘 UPS、HVAC、ISP、發電機等。 手動對流量進行fail over，完整的切換和回復可能需要 4–24 小時以上。
4. Cold Site:
   一個較小但完整的資料中心，配備冗餘 UPS、HVAC、ISP、發電機等。Cold Site沒有硬體或備份，它們需要取得、配置系統以及載入和配置應用程式。 這是最便宜、但也是回復時間最長的選項，可能需要數週以上。
5. Reciprocal Agreement Site:
   您的公司與另一個公司簽訂了合約，在發生災難事件時，他們將在其資料中心為您提供空間，反之亦然。 這可以是承諾的空間或一些機架，其硬體完全與那裡的網路隔離。
6. Subscription/Cloud Site:
   付錢給廠商，讓他們在一定的小時數 (SLA) 內啟動並運行我們的生產環境的最小或完整副本。 廠商已經用我們的應用程式完全建立了系統並接收資料備份，如果資料中心掛掉，我們會聯繫他們，他們會啟動系統並應用最新的備份。 多快和多少取決於我們的計劃以及我們想要為此類保險支付多少費用。
7. Mobile Site:
   基本上是一個帶輪子的資料中心，通常是一個貨櫃或拖車，可以透過卡車移動到任何地方。擁有HVAC、滅火、實體安全、（發電機）…完整資料中心所需的一切。有些是獨立的發電機和衛星網路。

一旦我們經歷了中斷並從中斷中恢回復，或者完成了failover test，我們就會有lessons learned。

哪什麼是Lessons Learned?(理想的)

這個階段經常被忽視，我們解決了問題，實施了新的控制和保障措施。 我們可以從lessons learned中學到很多東西，不僅是特定的事故，還有我們處理這些問題的能力，哪些有效，哪些無效。發生了什麼和沒有發生什麼並不重要，重要的是我們下次如何改進。我們不是指責，目的是改進。下次再發生此類事故時，我們作為一個組織如何成長並變得更好？ 雖然我們可能已經修復了這個漏洞，但可能還有數百個新漏洞我們還一無所知。

在吸取教訓後，我們(資安團隊)會向C-Level提交一份報告，根據我們的調查結果，我們只能提出建議，他們最終負責（並承擔責任）。 通常在重大事故發生後，組織會轉向自上而下的方法，並更多地聽取 IT 安全的意見(因為出大包了)。

Lessons learned的結果和變化將回饋到我們 BCP 和 DRP 的準備(preparation)和改進(improvement)。我們只在其他對策(countermeasures)失效時才會使用 BCP/DRP。 這使得計劃變得更加重要。 當我們制定和維護計劃時，我們希望避免一些常見的陷阱：

• 缺乏C-Level的支持
• 範圍太窄
• 沒有保持 BCP/DRP 計劃最新，或沒有適當的版本控制

計劃需要不斷更新，這是一個迭代的過程。 計劃應至少每 12 個月審查和更新一次。 當我們更新計劃時，舊副本將被銷毀，並分發當前版本。

Incident Management(事故管理)

IR通常涉及監控和偵測系統上的安全事件，以及如何對這些事件(events)做出回應。 IR是管理和保護電腦資產、網路和資訊系統的管理功能(administrative function)。 主要目的是對事件和電腦入侵有一個易於理解和可預測的回應。 IR需要有非常清晰的流程和回應，團隊接受過相關訓練，知道事件發生時該怎麼做。 事故是非常緊張的情況，重要的是員工確切地知道該怎麼做，他們持續接受訓練並了解程序。

IR的類別(categories)

自然的/人為的/環境的，其定義於災難的類別相同。

事故管理(Incident Management)"重要"

Event:
狀態的可觀察變化，這既不是正面也不是負面的，這只是某些東西發生了變化。

Alert:
如果發生特定事件則觸發告警。 例如流量使用率超過 75%，或記憶體使用率達到 90% 或更高，持續時間超過 3分鐘。

Incident:
系統或網路上發生的多種負面事件(Multiple adverse events)通常是人為造成的。

Problem:
對於不明原因的事故，將遵循類似的步驟來應對事故。 更多的時間將花費在根本原因分析(RCA-root cause analysis)上，我們需要知道發生了什麼，以便可以防止它再次發生。

Inconvenience (Non-disasters):
非中斷性故障、硬碟故障、cluster中的 1 台伺服器掛掉…

Emergency (Crisis):
緊急事件，可能造成生命或財產損失。

Disaster(災難):
整個設施將在 24 小時或更長時間內無法使用。 如果在地理位置上具有多樣性和冗餘性，就可以大大減緩這種情況。

Catastrophe(毀滅性):
整個設施完全的被摧毀。

參考資料:
NIST 800–61 IR lifecycle

CIRT (Cyber Incident Response Team):

• Senior management
• Incident manager
• Technical leads and teams
• IT Security
• PR, HR, and legal
• Auditors IT/financial

Incident Management 步驟

1. Preparation:
應對事件所採取的所有步驟。 制定政策、程序，訓練員工，採購偵測軟硬體，為incidence response team提供回應事故所需的工具。 對團隊的培訓練越多，他們處理回應的能力就越好，恢復的速度就越快，對犯​​罪現場的保護就越好（如果有的話），事故的影響就越小。

2. Detection:
對事件(Events)進行分析以確定它們是否可能是安全事件。 如果在系統內部和周圍沒有強大的偵測能力，很可能直到問題發生很久之後才意識到問題。 越早偵測到事件，就能越早回應，IDS可以幫助我們偵測，IPS可以幫助我們偵測和防止進一步的危害。IDS和IPS可以幫助我們在單一網段上偵測和防止，我們還需要一些東西(SIEM/SOAR)可以將整個網路的所有資訊關聯起來。

3. Response:
回應階段是incident response team開始與受影響的系統互動並嘗試防止事故造成進一步損害的階段。 這可以是使系統脫離網路、隔離流量、關閉電源，或按照計劃要求隔離系統以最大程度地減少事故影響的範圍和嚴重程度。 我們需要知道如何回應、何時嚴格遵守政策和程序、何時不遵守，這是我們讓資深員工處理此階段的原因。 我們盡可能接近事故發生時開始進行系統的bit level copy，以確保它們真實地反映了事故。 IT Security的存在是為了幫助企業，也許C-Level並不希望為了遏制或分析事故而干擾公司的業務，要不要做是C-Level的決定。我們(資安人員)阻止其蔓延，但僅此而已，只是遏制了該事故。

4. Mitigation:
了解事故的原因，以便系統能夠​​在recovery階段得到可靠的清理並恢復到運作狀態。 組織通常會刪除一個或多個系統上最明顯的入侵跡象，但會錯過攻擊中安裝的後門和其他惡意軟體。 明顯的標誌常常被發現，而實際的有效負載卻隱藏在其中。 如果偵測到或假設存在這種情況，我們通常只是從頭開始重建系統，並從已知良好的備份中回復application，而不是整個system。 為了確保備份良好，我們需要進行RCA(root cause analysis)，通常需要入侵的時間表，以及它是什麼時候開始的？ 如果它來自已知漏洞，我們會修補。 如果這是新發現的漏洞，我們會在再次將新建系統對外服務之前對其進行緩解(如加IPS/WAF/SASE…)。 如果可以了解有關攻擊的任何其他資訊，我們可以將其加入到我們的安全姿態(Security posture)中。 完全根除後，我們就開始recovery階段。

5. Reporting
從偵測(detection)開始在整個過程中進行回報，並在偵測到惡意活動時立即開始回報。 回報有兩個重點領：技術和非技術。 事故處理團隊在開始事故處理流程時回報事故的技術細節，如果是嚴重事故他們也會通知管理層。程序和政策將概述何時需要通知和參與哪個層級的管理層，但通常會會被忘記直到處理完畢，並且可以是RPE（(Resume Producing Event）。如果需要，管理層還將涉及其他部門，這可以是法律部門、公關部門或政策/程序中已確定的任何部門。

6. Recovery:
將系統恢復到正常運作狀態，而系統何時準備好重新進銀運由負責系統的業務部門決定。 我們通常密切監視經過"重建或清理"的系統，而攻擊者可能會留下後門，或者沒有刪除所有受感染的區域(not total delete)。 通常，系統會在非尖峰時段重新進入營運，以最大程度地減少仍然受到感染的系統的影響，或者可以將它們引入受控的沙箱(sandbox)環境中以查看感染是否持續存在。

7. Remediation:
修復(remediation)發生在緩解(mitigation)階段，受影響系統上的漏洞得到緩解。 緩解後繼續進行修復並且範圍要擴大，因為這可以修補具有相同漏洞的所有系統或更改組織的身份驗證方式。

8. Lessons Learned("重要"):
我們在前面有解釋到。Lessons Learned的結果和變化將納入第一步的準備(preparation)工作中。

關於災難分類的其他事故

電力問題(環境的):
我們地區常停電嗎？ 我們是否有適當的UPS和發電機來長期維持資料中心？ 我們需要 兩組的UPS 和發電機，它們都能提供穩定且乾淨的電力。 這些應該始終存在於資料中心中，但是我們的其他建築物呢？ 電力突波可能會損壞硬體。

熱(環境的)：
許多資料中心的溫度都太低，過去幾十年的研究顯示這是不必要的。 常見溫度範圍為 68–77 °F (20–25 °C) — 允許範圍為 59–90 °F (15–32 °C)。 讓資料中心保持過冷不僅會浪費錢，還會增加濕度。

壓力(環境的):
保持正壓可防止外部污染物進入。

濕度((Environmental):
濕度應保持在 40% 至 60% rH（相對濕度）之間。 低濕度會產生靜電，高濕度會腐蝕金屬（電子產品）。

戰爭、恐怖主義與破壞(人為的):
現今的世界仍有大量的傳統衝突和戰爭，但在網路的面紗後面正在發生更多的事情，出於各種原因、國家、宗教和更多原因進行駭客攻擊。 如果你想入侵某個國家或地區或只是破壞該地區的穩定，那麼削弱該地區的基礎設施是有意義的。 這可能是出於戰爭、貿易、影響力或許多其他原因，一切都是如此相互關聯，我們可以關閉世界各地的水、電或電源。 目標並不總是明顯的目標，醫院、航空旅行、航運、生產……都是潛在的。

在面對戰爭、恐怖主義這一類的威脅，NIST提出了Cybersecurity Framework框架，有興趣的人可以閱讀本部落格"NIST Cybersecurity Framework 介紹"一文及其系列文章。

出於經濟動機的攻擊者(人為的)：
我們看到越來越多的出於經濟動機的攻擊，他們的技術可能很高，也可能不太熟練。 技術水準較低的攻擊可能是普通的網路釣魚攻擊、社交工程或網路釣魚，這些通常只要目標量夠大，但只有極少數需要付出一些代價才能使其值得攻擊。 需要更多駭客技能的可能是竊取持卡人資料、身分盜竊、假冒反惡意(anti-malware)軟體工具或企業間諜活動等。 勒索軟體是出於經濟動機的攻擊的一種子類型，它會對系統進行加密，直到支付贖金為止，如果不支付贖金，系統將無法使用，如果支付贖金，攻擊者可能會發送有關如何恢復系統的指令。 攻擊者只是想要錢，他們並不關心錢從那裏來。

缺人(人為的/自然的/環境的):
在我們的 BCP 中，我們還必須確保人員冗餘以及如何處理人員短缺的情況。如果只剩50%的人員，公司會受到多大的影響。大流行病(COVID-19)也會影響人員的短缺。組織應按職位而不是姓名來識別主要員工，並準備好應對潛在的流行病。

再來是罷工:

• 員工大規模拒絕上班導致停工。
• 通常是為了回應員工的不滿。
• 我們需要減少多少勞動力才能繼續運作？

員工出差:

• 當我們的員工出差時，需要確保他們和我們的資料的安全。
• 這可能意味著避開某些位置，限制他們攜帶的硬體以及他們可以從遠端位置存取的內容。
• 如果他們需要筆腦/智慧手機，我們會使用加密、裝置監控、VPN(先進一點的用SASE) 和所有其他適當的措施。