Stories

Detail Return Return

讀紅藍攻防：技術與策略28事件調查與災難恢復 - Stories Detail

1. 確定問題範圍

1.1. 兩種場景

  • 1.1.1. 在組織內部

  • 1.1.2. 在混合環境中

1.2. 並非每個事件都是與安全相關的事件

  • 1.2.1. 有些症狀可能會導致你最初認為正在處理與安全相關的問題，但隨着更多問題的提出及更多數據的收集，你可能會逐漸意識到該問題並非與安全真正相關

1.3. 在開始調查之前確定問題的範圍至關重要

  • 1.3.1. 案例的初步分類對調查能否成功起着重要作用

  • 1.3.2. 在初始分類期間，確定問題的頻率也很重要

1.4. IT、運營和安全必須完全協調一致，以避免派發誤報任務，從而導致利用安全資源執行基於支持的任務

1.5. 如果問題當前沒有發生，你可能需要配置環境以便在用户能夠重現問題時收集數據

1.6. 確保記錄所有步驟，併為最終用户提供準確的行動計劃

1.7. 關鍵工件

  • 1.7.1. 更多的數據並不一定意味着更好的調查，主要是因為你仍然需要在某些情況下執行數據關聯，同時過多的數據可能會導致調查偏離問題的根本原因

  • 1.7.2. 當為設備分佈在世界各地的全球性組織處理調查任務時，確保瞭解要調查系統的所在時區非常重要

    • 1.7.2.1. 對於員工在辦公室外工作時使用的設備（如筆記本電腦和平板電腦）來説，這一點更為重要

  • 1.7.3. 當惡意程序出現在其中時，它還會創建服務

    • 1.7.3.1. 查看註冊表項HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services也很重要

    • 1.7.3.2. 運行msinfo32實用程序

1.8. 在處理實時調查時，還要確保使用Wireshark收集網絡痕跡，如有必要，請使用Sysinterals中的ProcDump工具創建受害進程的轉儲

1.9. 調查受損系統的過程可能因系統運行位置的不同而有所不同

2. 調查內部失陷系統

2.1. 使用VirusTotal在線驗證

2.2. Mimikatz

  • 2.2.1. 被廣泛用於憑據盜竊攻擊

2.3. 使用PsExec工具來啓動具有提升（系統）權限的命令提示符(cmd.exe)

2.4. ProcDump工具通常被攻擊者用來轉儲lsass.exe進程中的憑據

3. 調查混合雲中的失陷系統

3.1. PowerShell base64編碼的字符串

  • 3.1.1. MITRE ATT&CK T1059.001記錄的技術

3.2. 在默認路徑之外執行了SVCHOST的新實例

  • 3.2.1. 威脅行為者使用這種技術來逃避檢測

  • 3.2.2. 威脅者已經對計算機進行了一些本地偵察，禁用了Windows防火牆，並創建了一個新的進程

3.3. 使用Windows中的註冊表命令以建立持久性

3.4. 可以利用Windows中的reg工具來修改註冊表，查詢註冊表，並在註冊表中搜索不安全的憑據

3.5. 集成Microsoft Defender for Cloud與SIEM以進行調查

  • 3.5.1. Microsoft Defender for Cloud提供的數據非常豐富，但它沒有考慮其他數據源，例如防火牆等內部設備

    • 3.5.1.1. 這是需要將威脅檢測雲解決方案集成到內部SIEM的關鍵原因之一

3.6. 如果正在使用Splunk作為SIEM，並且想要開始從Microsoft Defender for Cloud獲取數據，為Splunk提供的Microsoft Graph Security API附加組件

4. 主動調查（威脅獵殺）

4.1. 許多組織已經在通過威脅獵殺進行主動威脅檢測

4.2. 主要目標是（甚至在系統觸發潛在告警之前）識別攻擊指示器(Indications of Attack，IoA)和攻陷指示器(Indications of Compromise，IoC)

  • 4.2.1. 使組織能夠積極主動地走在前面

  • 4.2.2. 威脅獵人(threat hunter)通常會利用SIEM平台中的數據來查詢失陷的證據

4.3. 每個查詢都是為一組特定的數據源定製的，並映射到MITRE ATT&CK框架

5. 經驗教訓

5.1. 每次事件接近尾聲時，你不僅應該記錄在調查期間完成的每個步驟，還應該確保確定了需要檢查的調查的關鍵方面，如果它們工作得不是很好，則需要改進或修復

5.2. 吸取的經驗教訓對於流程的持續改進和避免再次犯同樣的錯誤至關重要

5.3. 針對用户憑據的攻擊是一個日益嚴重的威脅，並且解決方案不是基於銀彈產品

  • 5.3.1. 它是任務的聚合

  • 5.3.2. 減少管理級別賬户的數量並取消本地計算機中的管理賬户

    • 5.3.2.1. 普通用户不應該作為自己工作站的管理員

  • 5.3.3. 儘可能多地使用多因素身份驗證

  • 5.3.4. 調整安全策略以限制登錄權限

  • 5.3.5. 計劃定期重置Kerberos TGT(KRBTGT)賬户

    • 5.3.5.1. 此賬户用於執行黃金票據攻擊

5.4. 藍隊應該創建一份全面的報告，記錄所學到的經驗教訓以及如何利用這些經驗教訓來改進防禦控制

6. 恢復過程

6.1. 一個組織不能完全依賴於它可以保護自己免受其面臨的每一次攻擊和所有風險的假設

  • 6.1.1. 組織面臨着廣泛的潛在災難，因此不可能針對所有災難都採取完善的保護措施

  • 6.1.2. IT基礎設施災難的成因可以是自然的，也可以是人為的

6.2. 自然災害是由環境危害或自然行為引起的災害，包括暴風雪、火災、颶風、火山噴發、地震、洪水、雷擊，甚至還有從天而降的小行星撞擊地面

6.3. 人為災難是指由人類用户或外部人類行為者的行為引起的災難，包括火災、網絡戰、核爆炸、黑客攻擊、電涌和事故等

6.4. 當一個組織遭受這些打擊時，其應對災難的準備程度將決定該組織的生存能力和恢復速度

7. 災難恢復計劃

7.1. 災難恢復計劃(Disaster Recovery Plan，DRP)是一套記錄在案的流程和程序，用於在災難事件發生時恢復IT基礎設施

7.2. 由於對IT的依賴，組織必須擁有全面且良好制定的災難恢復計劃

  • 7.2.1. 組織不可能避免所有的災難，因此所能做的最好的事情就是提前計劃當災難不可避免地發生時將如何恢復

7.3. 目標是在IT運營部分或全部停止時，對威脅到業務運營連續性的即時或特定緊急情況做出反應

7.4. 好處

  • 7.4.1. 組織有安全感

    • 7.4.1.1. 恢復計劃確保了它在災難面前繼續發揮作用的能力

  • 7.4.2. 組織減少了恢復過程中的延遲

    • 7.4.2.1. 如果沒有完善的計劃，災難恢復過程很難以協調一致的方式完成，從而導致不必要的延遲

  • 7.4.3. 備用系統的可靠性得以保證

    • 7.4.3.1. 災難恢復計劃的一部分是使用備用系統恢復業務運營

    • 7.4.3.2. 計劃確保這些系統始終做好準備，隨時準備在災難期間接手

  • 7.4.4. 為所有業務運營提供標準測試計劃

  • 7.4.5. 最大限度地減少災難期間做出決定所需的時間

  • 7.4.6. 減輕組織在災難期間可能產生的法律責任

8. 災難恢復計劃流程

8.1. 強調了在確定面臨的風險、要恢復的關鍵資源的優先順序以及最合適的恢復策略方面需要做的工作，還討論了系統保持在線時的現場恢復

8.2. 組建災難恢復小組

  • 8.2.1. 災難恢復小組是受命協助組織執行所有災難恢復操作的團隊，該小組應該包羅萬象，包括來自所有部門的成員和一些最高管理層的代表

  • 8.2.2. 團隊將是確定恢復計劃範圍的關鍵，這些恢復計劃涉及他們在各自部門執行的業務

  • 8.2.3. 小組還將監督計劃的成功制定和實施

  • 8.2.4. 激活是指災難恢復計劃中包含的操作被啓動和執行

    • 8.2.4.1. 擁有一個明確的激活過程將使災難恢復計劃更具主動性

    • 8.2.4.2. 激活所有者可以是CISO、CIO或任何在災難恢復計劃中定義的角色

8.3. 執行風險評估

  • 8.3.1. 災難恢復小組應進行風險評估，並確定可能影響組織運營的自然和人為風險，尤其是與IT基礎設施相關的風險

  • 8.3.2. 所選的部門工作人員應分析其職能領域的所有潛在風險，並確定與這些風險相關的潛在後果

  • 8.3.3. 災難恢復小組還應通過列出敏感文件和服務器面臨的威脅以及這些威脅可能產生的影響來評估它們的安全性

8.4. 確定流程和操作優先順序

  • 8.4.1. 災難恢復計劃中每個部門的代表確定其在發生災難時必須優先考慮的關鍵需求

  • 8.4.2. 大多數組織不會擁有足夠的資源來應對災害期間出現的所有需求

  • 8.4.3. 在制定災難恢復計劃時，需要確定優先級的關鍵領域包括功能操作、信息流、使用的計算機系統的可訪問性和可用性、敏感數據以及現有策略

  • 8.4.4. 要確定最重要的優先級，小組需要確定每個部門在沒有關鍵系統的情況下可以運行的最長時間

  • 8.4.5. 關鍵系統被定義為支持組織中發生的不同操作所需的系統

  • 8.4.6. 業務影響分析(Business Impact Analysis，BIA)

    • 8.4.6.1. 用於確定最大可容忍停機時間(Maximum Tolerable Downtime，MTD)，MTD用於計算恢復點目標(Recovery Point Objective，RPO)或RPO（最後一個可恢復的備份）和恢復時間目標（Recovery Time Objective，RTO，即災難事件和恢復之間的時間）​

  • 8.4.7. 確定優先順序的常用方法是列出每個部門的關鍵需求，確定為滿足這些需求需要進行的關鍵流程，然後確定基本流程和操作並對其進行排序

  • 8.4.8. 優先級：必要、重要和非必要

8.5. 確定恢復策略

  • 8.5.1. 需要制定恢復戰略，以涵蓋組織的所有方面，包括硬件、軟件、數據庫、通信通道、客户服務和最終用户系統

  • 8.5.2. 可能會與第三方（如供應商）達成書面協議，以便在發生災難時提供恢復替代方案，包括將本地存儲和備份與雲存儲相結合，以減輕硬盤驅動器故障的影響

  • 8.5.3. 組織應審查此類協議、其覆蓋期限以及條款和條件

8.6. 收集數據

  • 8.6.1. 為便於災難恢復小組完成完整的災難恢復流程，應收集並記錄有關組織的信息

  • 8.6.2. 在適用的情況下，企業還應該考慮可能伴隨着這些數據的合規性要求

8.7. 創建災難恢復計劃

  • 8.7.1. 如果執行正確，前面的步驟將為災難恢復小組提供足夠的信息，以制定全面而實用的完善災難恢復計劃

  • 8.7.2. 響應程序應以通俗易懂的方式進行全面解釋，它應該有一個循序漸進的佈局，並涵蓋響應小組和其他用户在災難來襲時需要做的所有事情

  • 8.7.3. 計劃還應規定自己的審查和更新程序

8.8. 測試計劃

  • 8.8.1. 計劃的適用性和可靠性永遠不應聽天由命，因為它可能決定一個組織在重大災難發生後的連續性

  • 8.8.2. 應該對其進行徹底測試，以確定其可能包含的任何挑戰或錯誤

  • 8.8.3. 測試將為災難恢復小組和用户提供執行必要檢查並充分了解響應計劃的平台

    • 8.8.3.1. 可以進行的一些測試包括模擬、檢查表測試、完全中斷測試和並行測試

  • 8.8.4. 必須證明整個組織所依賴的災難恢復計劃對最終用户和災難恢復小組都是實用且有效的

  • 8.8.5. 不僅測試是重要的，而且根據所處理的數據，它也可能是一個監管要求

8.9. 獲得批准

  • 8.9.1. 計劃經測試確定可靠、實用、全面以後，報最高管理層批准

  • 8.9.2. 最高管理層必須批准恢復計劃

    • 8.9.2.1. 保證計劃與組織的政策、程序和其他應急計劃一致

      8.9.2.1.1. 一個組織可能有多個業務應急計劃，這些計劃都應該精簡

    • 8.9.2.2. 計劃可以安排在年度審查的時間段內

      8.9.2.2.1. 最高管理層將對計劃進行自己的評估以確定其充分性

      8.9.2.2.2. 整個組織都有足夠的恢復計劃

      8.9.2.2.3. 最高管理層還必須評估計劃與組織目標的兼容性

8.10. 維護計劃

  • 8.10.1. IT威脅環境可能會在很短的時間內發生很大變化

  • 8.10.2. 一個好的災難恢復計劃必須經常更新

  • 8.10.3. 災難恢復計劃應該根據需要而不是嚴格的時間表進行更新

  • 8.10.4. 災難恢復過程的最後一步應該是建立更新時間表，該時間表還應規定在需要時進行更新

9. 挑戰

9.1. 缺乏最高管理層的批准

  • 9.1.1. 災難恢復計劃被認為僅僅是對可能永遠不會發生的假事件的演練

  • 9.1.2. 最高管理層可能不會優先制定這樣的計劃，也可能不會批准似乎有點昂貴的雄心勃勃的計劃

9.2. 災難恢復小組提出的恢復時間目標(Recovery Time Objective，RTO)不完整

  • 9.2.1. RTO是組織可接受的最長停機時間的關鍵決定因素，最大可容忍的停機時間(Maximum Tolerable Downtime，MTD)用於確定RTO

9.3. IT基礎設施在嘗試應對其面臨的威脅時會動態變化

信息安全
Favorites

Add a new Comments

Some HTML is okay.