本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 流程
<a name="process"></a>

 開發完整且明確定義的事件回應程序，是成功且可擴展事件回應計畫的關鍵。發生安全事件時，明確的步驟和工作流程將協助您及時回應。您可能已經有現有的事件回應程序。無論您目前的狀態為何，都必須定期更新、重複執行和測試事件回應程序。

# 制定和測試事件回應計劃
<a name="develop-and-test-incident-response-plan"></a>

 要為事件回應開發的第一個文件是*事件回應計劃*。事件回應計畫應是您事件回應計畫和策略的基礎。事件回應計畫是高階文件，通常包含下列各節：
+ **事件回應團隊概觀** – 概述事件回應團隊的目標和職能 
+ **角色和責任** – 列出事件回應利益相關者，並在事件發生時詳細說明其角色 
+ **通訊計劃 – **詳細說明聯絡資訊，以及在事件發生期間的通訊方式 

   最佳實務是讓out-of-band通訊做為事件通訊的備份。提供安全out-of-band通訊管道的應用程式範例為 [AWS Wickr](https://aws.amazon.com/wickr/)。
+ **事件回應的階段和要採取的動作** – 列舉事件回應的階段 – 例如偵測、分析、根除、包含和復原 – 包括在這些階段內要採取的高階動作
+ **事件嚴重性和優先順序定義** – 詳細說明如何分類事件嚴重性、如何排定事件優先順序，以及嚴重性定義如何影響呈報程序

 儘管不同規模和產業的公司都會有這些章節，但每個組織的事件回應計畫都是獨一無二的。您需要建置最適合您組織的事件回應計劃。

# 記錄和集中架構圖
<a name="document-and-centralize-architecture-diagrams"></a>

 若要快速準確地回應安全事件，您需要了解系統和網路的架構方式。根據最佳實務，了解這些內部模式不僅對於事件回應很重要，也對於驗證架構模式之應用程式之間的一致性也很重要。您也應該確認本文件是最新的，並根據新的架構模式定期更新。您應該開發詳細說明項目的文件和內部儲存庫，例如：
+ **AWS 帳戶結構** - 您需要知道：
  +  您有多少 AWS 帳戶？ 
  +  這些 AWS 帳戶如何組織？ 
  +  誰是 AWS 帳戶的商業擁有者？ 
  +  您是否使用服務控制政策 SCPs)？ 若是如此，使用 SCPs 實作了哪些組織護欄？ 
  +  您是否限制可使用的區域和服務？ 
  +  業務單位和環境之間有什麼差異 (dev/test/prod)？ 
+ **AWS 服務模式** 
  +  您使用哪些 AWS 服務？ 
  +  什麼是最廣泛使用的 AWS 服務？ 
+ **架構模式** 
  +  您使用哪些雲端架構？ 
+ **AWS 身分驗證模式** 
  +  您的開發人員通常如何進行身分驗證 AWS？ 
  +  您是否使用 IAM 角色或使用者 （或兩者）？ 您的身分驗證是否 AWS 連接到身分提供者 (IdP)？ 
  +  如何將 IAM 角色或使用者映射至員工或系統？ 
  +  當有人不再獲得授權時，如何撤銷存取權？ 
+ **AWS 授權模式** 
  +  您的開發人員使用哪些 IAM 政策？ 
  +  您是否使用資源型政策？ 
+ **記錄和監控** 
  +  您使用哪些記錄來源，以及它們存放在哪裡？ 
  +  您是否彙總 AWS CloudTrail 日誌？ 如果是這樣，它們會存放在哪裡？ 
  +  如何查詢 CloudTrail 日誌？ 
  +  您是否已啟用 Amazon GuardDuty？ 
  +  如何存取 GuardDuty 調查結果 （例如主控台、票證系統、SIEM)？ 
  +  問題清單或事件是否彙總在 SIEM 中？ 
  +  票證是否會自動建立？ 
  +  有哪些工具可用來分析調查的日誌？ 
+ **網路拓撲** 
  +  您網路上的裝置、端點和連線在實體或邏輯上如何排列？ 
  +  您的網路如何與 連線 AWS？ 
  +  如何在環境之間篩選網路流量？ 
+ **外部基礎設施** 
  +  如何部署面向外部的應用程式？ 
  +  哪些 AWS 資源可公開存取？ 
  +  哪些 AWS 帳戶包含面向外部的基礎設施？ 
  +  有哪些 DDoS 或外部篩選？ 

 記錄內部技術圖表和程序可簡化事件回應分析師的任務，協助他們快速取得機構知識來回應安全事件。完整的內部技術程序文件不僅簡化了安全調查，還調整了程序的合理化和評估。

# 開發事件回應手冊
<a name="develop-incident-response-playbooks"></a>

 準備事件回應流程的關鍵部分是制定程序手冊。事件回應程序手冊提供一系列方案指引和安全事件發生時應遵循的步驟。提供清晰的結構和步驟簡化了回應的複雜度並減少人為錯誤的可能性。

# 為 建立手冊的內容
<a name="what-to-create-playbooks-for"></a>

 應針對事件案例建立程序手冊，例如：
+  **預期事件** – 應為您預期的事件建立手冊。這包括拒絕服務 (DoS)、勒索軟體和憑證入侵等威脅。
+ ** 已知的安全性問題清單或提醒** – 應為已知的安全性問題清單和提醒建立手冊，例如 GuardDuty 問題清單。您可能會收到 GuardDuty 調查結果並思考：「現在該怎麼辦？」 若要防止錯誤處理 GuardDuty 調查結果或忽略調查結果，請為每個潛在的 GuardDuty 調查結果建立手冊。如需部分修復詳細資料和指引，請參閱 [GuardDuty 文件](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_remediate.html)。值得注意的是，在預設情況下 GuardDuty 是未啟用的狀態，並且會產生費用。如需 GuardDuty 的詳細資訊，請參閱附錄 A：雲端功能定義 - [可見性和提醒](visibility-and-alerting.md)。

# 手冊中要包含的內容
<a name="what-to-include-in-playbooks"></a>

 程序手冊應包含安全分析師應完成的技術步驟，以便充分調查和應對潛在的安全事件。

 要納入程序手冊的項目包括：
+  **手冊概觀** – 此手冊處理哪些風險或事件案例？ 程序手冊的目標是什麼？
+  **先決條件** – 此事件案例需要哪些日誌和偵測機制？ 預期的通知是什麼？ 
+ ** 利害關係人資訊** – 涉及的人員及其聯絡資訊為何？ 每個利害關係人的責任是什麼？ 
+ ** 回應步驟** – 在事件回應的各階段中，應採取哪些策略步驟？ 分析師應該執行哪些查詢？ 應該執行哪些程式碼以達到預期的成果？ 
  + ** Detect **– 如何偵測事件？ 
  + ** 分析** – 如何判斷影響範圍？ 
  + ** 包含** – 如何隔離事件以限制範圍？ 
  + ** 消除** – 如何從環境中移除威脅？ 
  + ** 復原** – 如何將受影響的系統或資源帶回生產環境？ 
+ ** 預期結果** – 執行查詢和程式碼之後，手冊的預期結果是什麼？ 

 若要驗證每個程序手冊中一致的資訊，建立程序手冊範本以在其他安全程序手冊中使用會很有幫助。某些先前列出的項目，例如利益相關者資訊，可以在多個手冊之間共用。如果是這種情況，您可以為該資訊建立集中式文件，並在手冊中參考它，然後列舉手冊中的明確差異。這將讓您不必更新所有個別手冊中的相同資訊。透過建立範本並識別手冊中的常見或共用資訊，您可以簡化和加速手冊開發。最後，您的手冊可能會隨著時間演進；一旦您確認步驟一致，就會形成自動化的需求。

# 範例手冊
<a name="sample-playbooks"></a>

 您可以在 的附錄 B 中找到許多範例手冊[手冊資源](appendix-b-incident-response-resources.md#playbook-resources)。此處的範例可用來引導您了解要建立哪些手冊，以及手冊中要包含哪些內容。不過，請務必製作手冊，其中包含與您業務最相關的風險。您需要驗證手冊中的步驟和工作流程是否包含您的技術和程序。

# 執行定期模擬
<a name="run-regular-simulations"></a>

 組織隨著時間的推移而成長和發展，威脅態勢也是如此。因此，持續檢閱您的事件回應功能非常重要。模擬是一種可用來執行此評估的方法。模擬會使用真實世界的安全事件案例，這些案例旨在模擬威脅參與者的策略、技術和程序 (TTP)，並且讓組織可藉由回應這些可能發生在現實中的模擬網路事件，來運用和評估其事件回應能力。

 模擬有許多好處，包括：
+  驗證網路整備程度和培養事件回應人員的信心。
+  測試工具和工作流程的正確性及效率。
+  根據您的事件回應計畫，精進溝通和呈報方法。
+  提供回應罕見媒介的機會。

# 模擬的類型
<a name="types-of-simulations"></a>

 主要的模擬類型有三種：
+  **桌上練習** – 模擬的桌上方法嚴格是一種以討論為基礎的工作階段，涉及各種事件回應利益相關者來練習角色和責任，並使用已建立的通訊工具和程序手冊。練習促進通常可以在虛擬場地、實體場地或組合的全天內完成。由於以討論為基礎的本質，桌面練習著重於程序、人員和協同合作。技術是討論不可或缺的一部分；不過，實際使用事件回應工具或指令碼通常不屬於桌面練習的一部分。
+  **紫色團隊練習** – 紫色團隊練習可提高事件回應者 (*藍隊*) 與模擬威脅執行者 (*紅隊*) 之間的協同合作程度。藍色團隊通常由安全營運中心 (SOC) 的成員組成，但也可以包括在實際網路事件期間涉及的其他利益相關者。紅隊通常由滲透測試團隊或關鍵利益相關者組成，他們受過令人反感的安全性訓練。紅隊演練在設計案例時與練習主持人合作，讓案例準確且可行。在紫色團隊練習期間，主要重點是偵測機制、工具和支援事件回應工作的標準操作程序 (SOPs)。
+ ** 紅隊演練** – 在紅隊演練期間，違規 (*紅隊*) 會執行模擬，以從預先確定的範圍實現特定目標或一組目標。防禦者 (*藍隊*) 不一定知道練習的範圍和持續時間，這可以更真實地評估他們將如何回應實際事件。由於 Red Team 練習可能是侵入性測試，因此您應該謹慎並實作控制，以確認練習不會對您的環境造成實際傷害。

**注意**  
AWS 要求客戶在進行紫色團隊或紅隊演練之前，檢閱滲透測試網站上提供的[滲透測試](https://aws.amazon.com/security/penetration-testing/)政策。

 表 1 摘要說明這些模擬類型的一些主要差異。請務必注意，定義通常被視為鬆散定義，並且可以自訂以符合組織的需求。

* 表 1 – 模擬的類型*


|   |  桌上練習  |  紫色團隊練習  |  紅隊演練  | 
| --- | --- | --- | --- | 
|  摘要  |  專注於一個特定安全事件案例的紙張驅動練習。這些可以是高階或技術，並由一系列的紙質注入驅動。 |  與桌面練習相比，更逼真的產品。在紫色團隊練習期間，主持人與參與者協作，以提高練習參與度，並在必要時提供培訓。 |  一般而言， 是更進階的模擬產品。通常隱蔽程度很高，參與者可能不知道練習的所有詳細資訊。 | 
|  所需的資源  |  所需的技術資源有限  |  所需的各種利益相關者和所需的高階技術資源  |  所需的各種利益相關者和所需的高階技術資源  | 
|  複雜性  |  低  |  中  |  高  | 

 考慮定期推行網路模擬。每個練習類型都可以為參與者和整個組織提供獨特的好處，因此您可以選擇從較不複雜的模擬類型 （例如桌面練習） 開始，並進入較複雜的模擬類型 （紅隊演練）。您應根據自身的安全成熟度、資源和所需的結果來選取模擬類型。由於複雜性和成本，某些客戶可能不會選擇執行紅隊演練。

# 練習生命週期
<a name="exercise-lifecycle"></a>

 無論您選擇的模擬類型為何，模擬通常遵循下列步驟：

1.  **定義核心練習元素** – 定義模擬案例和模擬的目標。這兩者都應獲得領導階層的允許。

1. ** 識別關鍵利益相關者** – 至少，一項練習需要練習主持人和參與者。根據情境，可能會涉及法律、通訊或主管領導階層等其他利害關係人。

1. ** 建置和測試案例** – 如果特定元素不可行，可能需要重新定義案例，因為它正在建置中。預計最終的情境會成為此階段的輸出。

1. ** 促進模擬** – 模擬的類型決定了所使用的促進方式 （與高度技術、模擬案例相比，以紙張為基礎的情況）。協調員應使其促進策略與模擬演練目標相對應，他們應盡可能吸引所有模擬演練參與者，以提供最大的效益。

1. ** 制定行動後報告 (AAR)** – 識別表現良好的領域、可以使用改善的領域，以及潛在的差距。AAR 應衡量模擬的有效性以及團隊對於模擬事件的應變能力，以便在未來的模擬追蹤進展幅度。