# 準備
為因應事件做好準備，對於須及時並有效回應的事件來說至關重要。準備工作橫跨三個領域：
+ **人員**：讓員工做好因應安全事件的準備，其中包括找出事件回應的相關利害關係人，並進行事件回應和雲端技術的培訓。
+ **流程**：備妥處理安全事件的流程，其中包括記錄架構、制定完整的事件回應計畫，以及製作程序手冊以便一致回應安全事件。
+ **技術**：備妥因應安全事件的技術，其中包括設定存取權、彙總和監控必要的日誌、實作有效的提醒機制，以及開發回應和調查功能。
這三個領域對於有效回應事件來說同樣重要。缺少任一個領域，事件回應計畫便不完整或無法發揮效用。您需要讓人員、流程和技術三者緊密整合，才能做好因應事件的準備。
**Topics**
+ [SEC10-BP01 識別關鍵人員和外部資源](sec_incident_response_identify_personnel.md)
+ [SEC10-BP02 制定事件管理計畫](sec_incident_response_develop_management_plans.md)
+ [SEC10-BP03 準備鑑識功能](sec_incident_response_prepare_forensic.md)
+ [SEC10-BP04 開發和測試安全事件回應程序手冊](sec_incident_response_playbooks.md)
+ [SEC10-BP05 預先佈建存取權](sec_incident_response_pre_provision_access.md)
+ [SEC10-BP06 預先部署工具](sec_incident_response_pre_deploy_tools.md)
+ [SEC10-BP07 執行模擬](sec_incident_response_run_game_days.md)
# SEC10-BP01 識別關鍵人員和外部資源
識別可以協助您的組織回應事件的內部和外部人員、資源及法律義務。
**預期成果：**您備有一份關鍵人員名單，包含其聯絡資訊，以及他們在回應安全事件時扮演的角色。您可定期審查並更新此資訊，以在內部和外部工具中反映人員變更。您在記錄此資訊時考量所有第三方服務供應商和廠商，包括安全合作夥伴、雲端供應商，以及軟體即服務 (SaaS) 應用程式。在安全事件期間，人員會負起適當層級的責任、得知適當的關聯內容，並擁有適當的存取權能夠做出回應和進行復原。
**常見的反模式：**
+ 回應安全事件時，未隨時備妥包含聯絡資訊、角色和職責的最新關鍵人員名單。
+ 假設每個人都了解回應事件和從事件復原時的人員、相依關係、基礎設施和解決方案。
+ 沒有能夠呈現主要基礎設施或應用程式設計的文件或知識儲存庫。
+ 未制定適當的新員工上任流程，導致他們無法有效地參與安全事件回應工作，例如進行事件模擬。
+ 在安全事件期間，當關鍵人員暫時聯絡不到或無法回應時，沒有向上呈報的管道。
**建立此最佳實務的優勢：**此實務可減少發生事件時，花在識別正確人員和其角色的權責劃分和回應時間。隨時備妥一份最新的關鍵人員及其角色的名單，您就能找到正確的人員進行權責劃分並從事件中復原，藉此在發生事件時盡量減少時間浪費。
**未建立此最佳實務時的風險暴露等級：**高
## 實作指引
**識別組織中的關鍵人員：**隨時備妥組織內應對特定事件所需的人員聯絡名單。發生人員變動 (例如組織變動、晉升和團隊變動) 時，定期審查並更新此資訊。這對於事件管理者、事件回應者和通訊負責人等關鍵角色尤其重要。
+ **事件管理者：**事件管理者在事件回應期間具有整體授權。
+ **事件回應者：**事件回應者負責調查和補救活動。這些人員可能根據事件類型而有所不同，但通常是負責受影響應用程式的開發人員和營運團隊。
+ **通訊負責人：**通訊負責人負責內部和外部溝通，特別是與公家機關、監管機構和客戶之間的溝通。
+ **上線程序：**定期培訓新進員工，並讓他們上線操作，讓他們具備必要的技能和知識，以有效地為事件回應工作做出貢獻。將模擬和實作練習納入以當成上線程序的一部分，以催促他們做好準備
+ **主題專家 (SME)：**如果是分散式和自主團隊，我們建議您組成 SME 團隊來負責關鍵任務工作負載。他們負責提供對事件所涉及關鍵工作負載的操作和資料分類的深入洞悉。
資料表格式範例：
```
| Role | Name | Contact Information | Responsibilities |
1 | ——– | ——- | ——- | ——- |
2 | Incident Manager | Jane Doe| jane.doe@example.com | Overall authority during response |
3 | Incident Responder | John Smith | john.smith@example.com | Investigation and remediation |
4 | Communications Lead | Emily Johnson | emily.johnson@example.com | Internal and external communications |
5 | Communications Lead | Michael Brown | michael.brown@example.com | Insights on critical workloads |
```
請考慮使用 [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) 功能來擷取主要聯絡人、定義回應計畫、自動排定待命時間表，以及制定向上呈報計畫。自動排定待命時間表並輪替所有人員，藉此將工作負載的責任分散給其負責人。這樣有助於建立良好的實務，例如，發出相關的指標和日誌，以及定義對工作負載至關重要的警示閾值。
**識別外部合作夥伴：**企業使用由獨立軟體開發廠商 (ISV)、合作夥伴和子承包商建置的工具，為其客戶打造出獨特的解決方案。邀集上述多方的關鍵人員參與，他們可以協助回應事件並從中復原。我們建議您註冊適當層級的 支援，以便透過支援案例迅速與 AWS 主題專家取得聯繫。請考慮針對工作負載的所有關鍵解決方案提供者做出類似的安排。有些安全事件會促使公開上市公司通知相關的公家機關和監管機構有關事件的情形和影響。維護並更新相關部門和負責人的聯絡資訊。
## 實作步驟
1. 設定事件管理解決方案。
1. 考慮在您的安全工具帳戶中部署 Incident Manager。
1. 在事件管理解決方案中定義聯絡人。
1. 針對每個聯絡人至少定義兩種類型的聯絡管道 (例如 SMS、電話或電子郵件)，以確保在發生事件時能夠與他們取得聯繫。
1. 定義回應計畫。
1. 識別發生事件時最合適參與的聯絡人。定義符合要參與之人員角色 (而非個別聯絡人) 的向上呈報計畫。考慮納入可負責通知外部實體的聯絡人，即使他們並未直接參與事件解決工作。
## 資源
**相關的最佳實務：**
+ [OPS02-BP03 已為營運活動識別負責其效能的擁有者](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_ops_model_def_activity_owners.html)
**相關文件：**
+ [AWS 安全事件回應指南](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)
**相關範例：**
+ [AWS 客戶程序手冊架構](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [準備和回應 AWS 環境中的安全事件](https://youtu.be/8uiO0Z5meCs)
**相關工具：**
+ [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html)
**相關影片：**
+ [Amazon 在開發期間採取的安全方法](https:/www.youtube.com/watch?v=NeR7FhHqDGQ)
# SEC10-BP02 制定事件管理計畫
為事件回應制定的第一份文件是事件回應計畫。事件回應計畫應是您事件回應計畫和策略的基礎。
**建立此最佳實務的優勢：**開發全面且明確定義的事件回應程序，是成功且可擴展的事件回應計畫的關鍵。當安全事件發生時，明確的步驟和工作流程可協助您及時因應。您可能已具備現有的事件回應程序。無論您目前的狀態為何，都必須定期更新、重複執行和測試事件回應程序。
**未建立此最佳實務時的曝險等級：**高
## 實作指引
事件管理計畫對於回應、減輕安全事件所造成潛在影響並從中復原而言至關重要。事件管理計畫是結構清晰的程序，可及時識別、修復和回應安全事件。
雲端有許多在內部部署環境中所見的相同營運角色和需求。您在建立事件管理計畫時，必須將與業務成果及合規要求最相符的回應及復原策略納入考量。例如，若您在 AWS 中操作的工作負載符合美國的 FedRAMP，那麼請遵循《[NIST SP 800-61 電腦安全處理指南](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf)》中的建議。同樣的，當您操作儲存個人身分識別資訊 (PII) 的工作負載時，請考慮如何保護和回應與資料落地和使用相關的問題。
為 AWS 中的工作負載建置事件管理計畫時，請從 [AWS 共同責任模式](https://aws.amazon.com/compliance/shared-responsibility-model/)開始，以便建置事件回應的深度防禦方法。在此模型中，AWS 會管理雲端的安全，但維護雲端的安全是您的責任。此表示您保有控制權，並對您選擇實作的安全控制項負責。[AWS 安全事件回應指南](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)詳細說明在建置以雲端為中心的事件管理計畫時的重要概念和基礎指引。
有效的事件管理計畫必須經過持續的反覆測試，以與您的雲端維運目標保持同步。在您建立和制定事件管理計畫時，請考慮使用以下詳述的實作計畫。
### 實作步驟
1. 定義您組織內處理安全事件的角色和責任。這應涉及各部門的代表，包括：
+ 人力資源 (HR)
+ 執行團隊
+ 法務部門
+ 應用程式擁有者和開發人員 (主題專家或 SME)
1. 明確概述事件進行期間誰應負責、當責、受諮詢和被告知 (RACI)。建立 RACI 圖表以促進快速直接的溝通，並明確概述事件不同階段的領導。
1. 在事件期間讓應用程式擁有者和開發人員 (SME) 參與，因為他們可以提供有價值的資訊和內容，有助於衡量影響範圍。與這些 SME 建立關係，並在實際事件發生之前與他們演練事件回應情境。
1. 讓受信任的合作夥伴或外部專家參與調查或回應程序，因為他們可以提供額外的專業知識和觀點。
1. 讓您的事件管理計畫和角色符合任何管理組織的當地法規或合規要求。
1. 定期練習和測試您的事件回應計畫，並納入所有定義的角色和責任。這有助於簡化程序，並確認您對於安全事件能有協調且有效的回應。
1. 定期審查和更新角色、責任和 RACI 圖表，或隨著您的組織結構或需求進行變更。
**了解 AWS 回應團隊和支援**
+ **AWS 支援**
+ [支援](https://aws.amazon.com/premiumsupport/) 提供各種方案，可支援您運用各種工具與專業知識，協助您的 AWS 解決方案獲得成功並正常運作。如果您需要技術支援和更多資源以協助規劃、部署和最佳化 AWS 環境，您可以選取最符合您 AWS 使用案例的支援計畫。
+ 考慮以 AWS 管理主控台 中的[支援中心](https://console.aws.amazon.com/support) (需要登入) 作為中心聯絡窗口，以取得影響 AWS 資源的問題所需的支援。對 支援 的存取由 AWS Identity and Access Management 控制。如需有關取得 支援 功能存取權的詳細資訊，請參閱 [支援 入門](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html#accessing-support)。
+ **AWS 客戶事件回應團隊 (CIRT)**
+ AWS 客戶事件回應團隊 (CIRT) 是一個專門的全天候全球 AWS 團隊，在客戶端的有效安全事件期間為客戶提供支援 - [AWS 共同責任模式](https://aws.amazon.com/compliance/shared-responsibility-model/)。
+ 當 AWS CIRT 支援您時，他們會為 AWS 上的有效安全事件提供分類和復原方面的協助。他們可透過使用 AWS 服務日誌協助進行根本原因分析，並為您提供復原的建議。他們也可提供安全建議和最佳實務，以協助您避免事後發生安全事件。
+ AWS 客戶可以透過 [支援 案例](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html)洽詢 AWS CIRT。
+ [https://aws.amazon.com/security-incident-response/](https://aws.amazon.com/security-incident-response/)
+ AWS 安全事件應變 在 re:Invent 2024 發布，是一項託管安全事件回應服務，結合了現代分類技術和人機迴圈。此服務會擷取所有 GuardDuty 調查結果，以及傳送至 AWS Security Hub CSPM 進行分類的任何第三方調查結果，僅在需要調查的調查結果時提醒客戶。此服務也提供入口網站，在客戶注意到安全事件時提交反應性案例，並從 AWS 的進階事件回應團隊取得支援。
+ **DDoS 回應支援**
+ AWS 提供 [AWS Shield](https://aws.amazon.com/shield/)，其中包含受管的分散式拒絕服務 (DDoS) 保護服務，可為執行於 AWS 的 Web 應用程式提供保護。Shield 提供一律開啟的偵測和自動內嵌緩解措施，可將應用程式停機時間和延遲降至最低，讓您無需聯絡 支援 即可享有 DDoS 保護。Shield 有兩個層級：AWS Shield Standard 和 AWS Shield Advanced。若要了解這兩個層級的差異，請參閱 [Shield 功能文件](https://aws.amazon.com/shield/features/)。
+ **AWS Managed Services (AMS)**
+ [AWS Managed Services (AMS)](https://aws.amazon.com/managed-services/) 可讓您持續管理 AWS 基礎設施，讓您專注在自己的應用程式上。透過實作維護基礎設施的最佳實務，AMS 有助於降低營運開銷和風險。AMS 可自動化常見的活動，例如，變更請求、監控、修補程式管理、安全性和備份服務，而且提供佈建、執行和支援基礎設施的完整生命週期服務。
+ AMS 負責部署安全偵測控制套件，並提供全年無休的第一線提醒應變措施。提醒啟動時，AMS 會依照一組標準的自動化和手動程序手冊來驗證回應的一致性。這些程序手冊會在上線期間與 AMS 客戶共享，讓他們能夠透過 AMS 來制定和協調應變措施。
**制定事件回應計畫**
事件回應計畫應是您事件回應計畫和策略的基礎。事件回應計畫應納入正式文件中。事件回應計畫通常包含下列章節：
+ **事件回應團隊概觀：**概述事件回應團隊的目標和職能。
+ **角色和責任：**列出事件回應利害關係人，並詳細說明他們在事件發生時的角色。
+ **通訊計畫：**詳細說明聯絡資訊，以及您在事件期間要如何進行通訊。
+ **備份通訊方式：**最佳實務是將頻外通訊作為事件通訊的備用方法。舉例來說，AWS Wickr 就是提供安全頻外通訊通道的應用程式。
+ **事件回應的階段和應採取的行動：**列舉事件回應的階段 (例如偵測、分析、消除、抑制及復原)，包括要在這些階段中採取的高階動作。
+ **事件嚴重性和優先順序定義：**詳細說明如何分類事件的嚴重性、如何排定事件的優先順序，以及嚴重性定義對於呈報程序有何影響。
儘管不同規模和產業的公司都會有這些章節，但每個組織的事件回應計畫都是獨一無二的。您必須建立最適合貴組織的事件回應計畫。
## 資源
**相關的最佳實務：**
+ [ SEC04 偵測](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html)
**相關文件：**
+ [AWS 安全事件回應指南](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+ [ NIST：電腦安全事件處理指南](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf)
# SEC10-BP03 準備鑑識功能
在安全事件發生之前，將開發鑑識功能納入考量，以協助安全事件調查。
**未建立此最佳實務時的曝險等級：**中
傳統內部部署鑑識的概念適用於 AWS。如需開始在 AWS 雲端 中建置鑑識功能的重要資訊，請參閱 [AWS 雲端 中的鑑識調查環境策略](https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud/)。
設定鑑識的環境和 AWS 帳戶 結構後，請定義在四個階段有效執行合理鑑識方法所需的技術：
+ **收集：**收集相關 AWS 日誌，例如 AWS CloudTrail、AWS Config、VPC 流程日誌和主機層級日誌。收集受影響 AWS 資源的快照、備份和記憶體傾印 (如果有的話)。
+ **檢查：**檢查透過擷取和評估相關資訊所收集的資料。
+ **分析：**分析收集的資料，以了解事件並從中得出結論。
+ **報告：**呈現分析階段所產生的資訊。
## 實作步驟
**準備鑑識環境**
[AWS Organizations](https://aws.amazon.com/organizations/) 可協助您隨著 AWS 資源的成長和擴展，集中管理和控管 AWS 環境。AWS 組織會合併 AWS 帳戶，以便您可以將其當作一個單位進行管理。您可以使用組織單位 (OU) 將帳戶群組在一起，以單一單位的形式進行管理。
如需事件回應，建議您建立可支援事件回應功能的 AWS 帳戶 結構，其中包括*安全性 OU* 和*鑑識 OU*。在安全性 OU 中，您應該擁有下列項目的帳戶：
+ **日誌存檔：**使用有限的許可彙總日誌存檔 AWS 帳戶 中的日誌。
+ **安全性工具：**將安全性服務集中在安全工具 AWS 帳戶 中。此帳戶會以安全性服務的委派系統管理員身分運作。
在鑑識 OU 中，您可以選擇為營運所在的每個區域實作一或多個鑑識帳戶，具體視哪個區域最適合您業務和營運模式而定。如果您為每個區域建立鑑識帳戶，則可以防止該區域以外的 AWS 資源建立，並降低將資源複製到非預期區域的風險。例如，如果您只在美國東部 (維吉尼亞北部) 區域 (`us-east-1`) 和美國西部 (奧勒岡) (`us-west-2`) 進行營運，則鑑識 OU 中會有兩個帳戶：一個用於 `us-east-1`，另一個用於 `us-west-2`。
您可以為多個區域建立鑑識 AWS 帳戶。您在將 AWS 資源複製到該帳戶時應小心，以確認是否符合資料主權要求。佈建新帳戶需要一些時間，因此必須在事件之前建立和檢測鑑識帳戶，以便回應者能夠有效地使用這些帳戶進行回應。
下圖顯示範例帳戶結構，包括具有每個區域鑑識帳戶的鑑識 OU：
![\[流程圖顯示事件回應的每個區域帳戶結構，分為安全性和鑑識 OU。\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/security-pillar/images/region-account-structure.png)
**擷取備份和快照**
設定重要系統和資料庫的備份，對於從安全事件中復原和鑑識用途非常重要。備份就緒後，您可以將系統還原到先前的安全狀態。您可以在 AWS 上拍攝各種資源的快照。快照可為您提供那些資源的時間點備份。有許多 AWS 服務，可以在備份和復原方面為您提供支援。如需有關這些備份和復原之服務和方法的詳細資訊，請參閱[備份和復原方案指引](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/services.html)和[使用備份從安全事件中復原](https://aws.amazon.com/blogs/security/use-backups-to-recover-from-security-incidents/)。
尤其是當涉及勒索軟體等情況時，務必確保備份是否有充足的保護。如需有關保護備份的指引，請參閱[在 AWS 中保護備份的 10 大安全最佳實務](https://aws.amazon.com/blogs/security/top-10-security-best-practices-for-securing-backups-in-aws/)。除了確保備份的安全之外，您還應該定期測試備份和還原程序，以確認您現有的技術和程序是否如預期般運作。
**自動化鑑識**
在安全事件期間，事件回應團隊必須能夠快速收集和分析證據，同時維持事件周圍期間的準確性 (例如擷取與特定事件或資源相關的日誌，或收集 Amazon EC2 執行個體的記憶體傾印)。事件回應團隊手動收集相關證據既具挑戰性又耗時，尤其是範圍遍及大量執行個體和帳戶時。此外，手動收集可能容易出現人為錯誤。基於這些原因，您應盡可能開發和實作鑑識的自動化。
AWS 為鑑識提供許多自動化資源，內容列於以下的資源區段。這些資源是我們已開發和客戶已實作的鑑識模式範例。雖然這些範例在一開始可能是有用的參考架構，但請根據環境、需求、工具和鑑識程序，考慮是否加以修改或建立新的鑑識自動化模式。
## 資源
**相關文件：**
+ [AWS 安全事件回應指南 - 開發鑑識功能](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/develop-forensics-capabilities.html)
+ [AWS 安全事件回應指南 - 鑑識資源](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-b-incident-response-resources.html#forensic-resources)
+ [AWS 雲端 中的鑑識調查環境策略](https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud/)
+ [如何在 AWS 中自動化鑑識磁碟收集](https://aws.amazon.com/blogs/security/how-to-automate-forensic-disk-collection-in-aws/)
+ [AWS 方案指引 - 自動化事件回應和鑑識](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/automate-incident-response-and-forensics.html)
**相關影片：**
+ [ 自動化事件回應和鑑識](https://www.youtube.com/watch?v=f_EcwmmXkXk)
**相關範例：**
+ [ 自動化事件回應和鑑識架構](https://github.com/awslabs/aws-automated-incident-response-and-forensics)
+ [ Amazon EC2 的自動化鑑識協調器](https://docs.aws.amazon.com/solutions/latest/automated-forensics-orchestrator-for-amazon-ec2/welcome.html)
# SEC10-BP04 開發和測試安全事件回應程序手冊
準備事件回應流程的關鍵部分是制定程序手冊。事件回應程序手冊提供方案指引，以及安全事件發生時應遵循的步驟。提供清晰的結構和步驟簡化了回應的複雜度並減少人為錯誤的可能性。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
應針對事件案例建立程序手冊，例如：
+ **預期事件**：應針對您預期的事件建立程序手冊。這包括拒絕服務 (DoS)、勒索軟體和憑證入侵等威脅。
+ **已知安全調查結果或提醒**：應針對已知安全調查結果和提醒 (例如 Amazon GuardDuty 調查結果) 建立執行手冊。當您收到 GuardDuty 調查結果時，手冊應提供明確的步驟，以避免處理不當或忽略提醒。如需更多修復相關資訊和指引，請參閱[修復 GuardDuty 發現的安全問題](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_remediate.html)。
程序手冊應包含安全分析師應完成的技術步驟，以便充分調查和應對潛在的安全事件。
AWS 的客戶事件回應團隊 (CIRT) 已發布[包含事件回應操作手冊的 GitHub 儲存庫](https://github.com/aws-samples/aws-customer-playbook-framework/tree/main/docs)，依威脅情境、類型和資源整理。這些操作手冊可以調整到符合您現有的事件回應程序，或可當成開發新程序的基礎。
### 實作步驟
要納入程序手冊的項目包括：
+ **程序手冊概觀**：這份程序手冊可處理哪些風險或事件？ 程序手冊的目標是什麼？
+ **先決條件**：此事件案例需要哪些日誌、偵測機制和自動化工具？ 預期的通知是什麼？
+ **溝通和向上呈報資訊**：誰參與其中，其聯絡資訊為何？ 每個利害關係人的責任是什麼？
+ **回應步驟**：在事件回應的各個階段，應採取哪些戰術步驟？ 分析師應該執行哪些查詢？ 應該執行哪些程式碼以達到預期的成果？
+ **偵測**：事件的偵測方式為何？
+ **分析**：判斷影響範圍的方式為何？
+ **包含：**隔離事件以限制範圍的方式為何？
+ **根除**：將威脅從環境中移除的方式為何？
+ **復原**：受影響的系統或資源重新投入生產環境的方式為何？
+ **預期成果**：執行查詢和程式碼後，程序手冊的預期結果是什麼？
## 資源
**相關 Well-Architected 的最佳實務：**
+ [SEC10-BP02 - 制定事件管理計畫](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_develop_management_plans.html)
**相關文件：**
+ [事件回應程序手冊的架構](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [制定您自己的事件回應程序手冊](https://github.com/aws-samples/aws-incident-response-playbooks-workshop)
+ [事件回應程序手冊範例](https://github.com/aws-samples/aws-incident-response-playbooks)
+ [使用 Jupyter 程序手冊和 CloudTrail Lake 建置 AWS 事件回應執行手冊](https://catalog.workshops.aws/incident-response-jupyter/en-US)
# SEC10-BP05 預先佈建存取權
確認事件回應者具有在 AWS 中預先佈建的正確存取權限，以縮短調查直至復原所需的時間。
**常見的反模式：**
+ 使用事件回應的根帳戶。
+ 更改現有的帳戶。
+ 當提供即時權限提升時直接操控 IAM 許可。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
AWS 建議盡可能降低或避免對長期憑證的依賴，而是採用暫時憑證和*即時*權限提升機制。長期憑證容易發生安全性風險並會增加營運負擔。對於大多數管理任務，以及事件回應任務，我們建議您實作[聯合身分](https://aws.amazon.com/identity/federation/)以及[適用於管理存取權的暫時權限提升](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/)。在此模型中，使用者會請求提升至較高層級的權限 (例如事件回應角色)；如果使用者符合提升的資格，則會將請求傳送至核准者。如果請求獲得核准，使用者就會收到一組暫時 [AWS 憑證](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html)，使用者可使用此憑證來完成其任務。在這些憑證過期後，使用者就必須提交新的提升權限請求。
我們建議在大多數事件回應情境中，使用暫時權限提升。正確的做法是使用 [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) 和[工作階段政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)來界定存取權的範圍。
當發生聯合身分不可用的情況，例如：
+ 與遭盜用身分提供者 (IdP) 相關的中斷。
+ 設定錯誤或人為錯誤會導致聯合存取管理系統遭到破壞。
+ 分散式拒絕服務 (DDoS) 事件或使系統無法使用之類的惡意活動。
在上述案例中，應會有已設定的*緊急*存取權，可協助調查和及時修復事件。我們建議您使用[具有適當許可的使用者](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)，來執行任務和存取 AWS 資源。僅將根憑證用於[需要根使用者存取權的任務](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html)。若要確認事件回應者是否具有 AWS 和其他相關系統的正確存取權，我們建議預先佈建專屬帳戶。此類帳戶需要提升的存取權，且必須受到嚴格的控制和監控。必須以執行必要任務所需的最低權限來建置這些帳戶，而存取權層級應以事件管理計畫中建立的程序手冊為基礎。
使用專用和專屬的使用者及角色作為最佳實務。透過新增 IAM 政策而暫時提升權限的使用者和角色存取權，會同時使得使用者在事件發生期間的存取權不明確，又有無法將提升的權限撤銷的風險。
您必須盡可能移除相依性，來確認可在各種可能的失敗情境下獲得存取權。為了做到這一點，建立程序手冊來確認事件回應使用者的建立身分是專屬安全帳戶中的使用者，且不會透過任何現有的聯合或單一登入 (SSO) 解決方案來管理事件回應使用者。每個個別回應者必須具備其專屬的指定帳戶。帳戶組態必須強制執行[強式密碼政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)和多重要素驗證 (MFA)。如果事件回應程序手冊僅需要 AWS 管理主控台 的存取權，使用者就不應設定存取金鑰，且應明確禁止使用者建立存取金鑰。您可以使用 IAM 政策或服務控制政策 (SCP) 進行設定，如 [AWS Organizations SCP](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) 的 AWS 安全最佳實務中所述。除了在其他帳戶中擔任事件回應角色的能力外，使用者不應具備任何權限。
在事件期間，必須將存取權授予其他內部或外部人員，來協助調查、修復和復原活動。在此案例中，使用先前提到的程序手冊機制，而且必須制定程序，以確認在事件完成後，立即將任何其他存取權撤回。
若要確認事件回應角色的使用是否受到適當的監控和稽核，則必須確保未在人員之間共用為此目的建立的 IAM 帳戶，且除非[特定任務所需](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html)，否則不得使用 AWS 帳戶根使用者。如果需要根使用者 (例如，特定帳戶的 IAM 存取權不可用時)，請使用獨立的程序，其中有可用的程序手冊，來確認根使用者登入憑證和 MFA 字符是否可用。
若要為事件回應角色設定 IAM 政策，請考慮使用 [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) 來根據 AWS CloudTrail 日誌產生政策。若要這麼做，請向管理員授予在非生產帳戶上事件回應角色的存取權，並透過程序手冊加以執行。完成後，您就可以建立政策來僅允許所採取的動作。接著就可以將此政策套用至所有帳戶中的所有事件回應角色。您可能希望為每個程序手冊建立個別 IAM 政策，來讓管理和稽核作業更輕鬆。範例程序手冊可能包含勒索軟體、資料洩漏、生產存取權遺失和其他情境的回應計畫。
使用事件回應帳戶來擔任[在其他 AWS 帳戶 中專屬事件回應 IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)。必須將這些角色設定為僅供安全帳戶中的使用者擔任，而信任關係必須要求呼叫主體使用 MFA 進行驗證。這些角色必須使用嚴格控制範圍的 IAM 政策來控制存取權。確保所有對這些角色的 `AssumeRole` 請求都記錄在 CloudTrail 中並據以發出提醒，而使用這些角色採取的任何動作都會記錄下來。
強烈建議必須清楚地命名 IAM 帳戶和 IAM 角色，因此您可以輕鬆地在 CloudTrail 日誌中找到這些帳戶和角色。這類範例便是將 IAM 帳戶命名為 `-BREAK-GLASS` 以及將 IAM 角色命名為 `BREAK-GLASS-ROLE`。
[CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) 會用來在 AWS 帳戶中記錄 API 活動，且應用來[設定對事件回應角色使用情形的提醒](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/)。請參閱部落格貼文，其中會說明使用根金鑰如何設定提醒。您可以修改說明，以設定與事件回應 IAM 角色相關的 `AssumeRole` 事件的 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 指標篩選條件至篩選條件：
```
{ $.eventName = "AssumeRole" && $.requestParameters.roleArn = "" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }
```
由於事件回應角色可能具備很高的存取權限，因此必須將這些提醒傳送給多個群組，並據此快速採取行動。
在事件期間，回應者可能需要存取未受 IAM 直接保護的系統。其中可能包含 Amazon Elastic Compute Cloud 執行個體、Amazon Relational Database Service 資料庫或軟體即服務 (SaaS) 平台。強烈建議使用此方法，而不是使用 SSH 或 RDP 等原生協定，[AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) 會用於對 Amazon EC2 執行個體的所有管理存取權。您可以使用安全且受稽核的 IAM 來控制此存取權。您也可以使用 [AWS Systems Manager Run Command 文件](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)來自動化部分程序手冊，如此可減少使用者錯誤並縮短復原時間。如需資料庫和第三方工具的存取權，我們建議將存取憑證儲存在 AWS Secrets Manager 中，並將存取權授予事件回應者角色。
最後，應將事件回應 IAM 使用者帳戶的管理作業新增至[加入者、異動者和離職者程序](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html)中，並定期審查和測試此管理作業，以確認僅允許預期的存取。
## 資源
**相關文件：**
+ [管理對 AWS 環境的暫時提升存取權](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/)
+ [AWS 安全事件回應指南](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+ [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/)
+ [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html)
+ [設定 IAM 使用者的帳戶密碼政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)
+ [使用 AWS 中的多重要素驗證 (MFA)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html)
+ [ 使用 MFA 設定跨帳戶存取權](https://aws.amazon.com/blogs/security/how-do-i-protect-cross-account-access-using-mfa-2/)
+ [ 使用 IAM Access Analyzer 來產生 IAM 政策](https://aws.amazon.com/blogs/security/use-iam-access-analyzer-to-generate-iam-policies-based-on-access-activity-found-in-your-organization-trail/)
+ [多帳戶環境中 AWS Organizations 服務控制政策的最佳實務](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/)
+ [ 如何在使用 AWS 帳戶的根存取金鑰時接收通知](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/)
+ [ 使用 IAM 受管政策來建立精細的工作階段許可](https://aws.amazon.com/blogs/security/create-fine-grained-session-permissions-using-iam-managed-policies/)
+ [緊急存取](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/break-glass-access.html)
**相關影片：**
+ [ 將 AWS 中的事件回應和鑑識自動化](https://www.youtube.com/watch?v=f_EcwmmXkXk)
+ [執行手冊、事件報告和事件回應的 DIY 指南](https://youtu.be/E1NaYN_fJUo)
+ [ 準備和回應 AWS 環境中的安全事件](https://www.youtube.com/watch?v=8uiO0Z5meCs)
# SEC10-BP06 預先部署工具
確認安全人員具有預先部署的適當工具，以縮短調查直至復原的時間。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
若要自動化安全回應和操作功能，您可以使用 AWS 提供的完整 API 和工具集。您可以將身分管理、網路安全、資料保護和監控功能完全自動化，並使用現有的熱門軟體開發方法遞送這些功能。建置安全自動化時，您的系統可以監控、審核和啟動回應，而不是讓人員監控您的安全地位並手動回應事件。
如果您的事件回應團隊持續以相同方式回應提醒，可能會形成提醒疲勞的風險。隨著時間的推移，團隊可能會變得對收到提醒不敏感，而且在處理一般情況時可能會犯錯，或是錯過不尋常的提醒。自動化使用能夠處理重複和一般提醒的功能，讓人員處理敏感和獨特的事件，有助於避免發生提醒疲倦的情形。整合異常偵測系統 (例如 Amazon GuardDuty、AWS CloudTrail Insights 和 Amazon CloudWatch 異常檢測) 可以減輕常見閾值型提醒的負擔。
您可以透過程式設計方式將程序中的步驟自動化，以改善手動程序。定義事件的補救模式之後，您可以將該模式分解為可行的邏輯，並撰寫程式碼來執行該邏輯。回應人員接著可以執行該程式碼來修復問題。隨著時間的推移，您可以將越來越多的步驟自動化，最終自動處理整個類別的常見事件。
在安全調查期間，您需要能夠審核相關日誌以記錄和了解該事件的完整範圍和時間表。產生提醒也需要日誌，以指出特定關注的動作已發生。選擇、啟用、儲存和設定查詢與擷取機制和設定提醒至關重要。此外，提供搜尋日誌資料之工具的有效方法是 [Amazon Detective](https://aws.amazon.com/detective/)。
AWS 擁有 200 多種雲端服務和數千種功能。我們建議您審核可支援並簡化事件回應策略的服務。
除了日誌記錄之外，您還應該開發和實作[標記策略](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)。標記可以協助提供與 AWS 資源用途有關的上下文。標記也可用於自動化。
### 實作步驟
**選取並設定日誌以進行分析和提醒**
請參閱下列有關設定事件回應日誌記錄的文件：
+ [ 安全事件回應的日誌記錄策略](https://aws.amazon.com/blogs/security/logging-strategies-for-security-incident-response/)
+ [SEC04-BP01 設定服務和應用程式日誌記錄](sec_detect_investigate_events_app_service_logging.md)
**啟用安全服務以支援偵測和回應**
AWS 提供偵測、預防性和回應式功能，而其他服務可用於建立自訂安全性解決方案的架構。如需安全事件回應最相關的服務清單，請參閱[雲端功能定義](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-a-cloud-capability-definitions.html)和[安全事件回應首頁](https://aws.amazon.com/security-incident-response/)。
**制定和實作標記策略**
取得有關業務使用案例和圍繞 AWS 資源的相關內部利害關係人的上下文資訊可能很困難。執行此操作的一種方法是使用標籤的形式，此形式會將中繼資料指派給 AWS 資源，並包含使用者定義的鍵值組。您可以建立標籤，依目的、擁有者、環境、處理的資料類型以及您選擇的其他條件來分類資源。
擁有一致的標記策略可讓您快速識別和辨別與 AWS 資源有關的情境資訊，從而加快回應時間並盡可能減少用在組織情境的時間。標籤也可以作為啟動回應自動化的機制。如需有關標記內容的詳細資訊，請參閱[標記您的 AWS 資源](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)。您需要先定義要在整個組織中實作的標籤。之後，您將實作並強制執行此標記策略。如需有關實作和強制執行的詳細資訊，請參閱[使用 AWS 標籤政策和服務控制政策 (SCP) 實作 AWS 資源標記策略](https://aws.amazon.com/blogs/mt/implement-aws-resource-tagging-strategy-using-aws-tag-policies-and-service-control-policies-scps/)。
## 資源
**相關 Well-Architected 的最佳實務：**
+ [SEC04-BP01 設定服務和應用程式日誌記錄](sec_detect_investigate_events_app_service_logging.md)
+ [SEC04-BP02 在標準化的位置擷取日誌、調查結果和指標](sec_detect_investigate_events_logs.md)
**相關文件：**
+ [ 安全事件回應的日誌記錄策略](https://aws.amazon.com/blogs/security/logging-strategies-for-security-incident-response/)
+ [ 事件回應雲端功能定義](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-a-cloud-capability-definitions.html)
**相關範例：**
+ [ 使用 Amazon GuardDuty 和 Amazon Detective 進行威脅偵測與回應](https://catalog.workshops.aws/guardduty/en-US)
+ [ Security Hub 研討會](https://catalog.workshops.aws/security)
+ [ 使用 Amazon Inspector 管理漏洞](https://catalog.workshops.aws/inspector/en-US)
# SEC10-BP07 執行模擬
在組織隨著時間成長和發展時，威脅態勢也會跟著演變，因此持續審查事件回應能力是很重要的。執行模擬 (也稱為比賽日) 是可用於執行此評估的一種方法。模擬會使用真實世界的安全事件案例，這些案例旨在模擬威脅參與者的策略、技術和程序 (TTP)，並且讓組織可藉由回應這些可能發生在現實中的模擬網路事件，來運用和評估其事件回應能力。
**建立此最佳實務的優勢：**模擬具有多種優勢：
+ 驗證網路整備程度和培養事件回應人員的信心。
+ 測試工具和工作流程的正確性及效率。
+ 根據您的事件回應計畫，精進溝通和呈報方法。
+ 提供回應罕見媒介的機會。
**未建立此最佳實務時的曝險等級：**中
## 實作指引
主要的模擬類型有三種：
+ **桌上模擬演練：**桌上模擬方法是基於討論的會議，涉及各種事件回應利害關係人的角色和責任練習，並使用已建立的溝通工具和程序手冊。模擬演練促進通常可在虛擬場地、實體場地或兩者的組合於一整天內完成。桌上模擬演練以討論為主軸，因此側重於程序、人員和協作。技術在討論中是不可或缺的一部分，但事件回應工具或指令碼的實際使用通常不是桌上模擬演練的一部分。
+ **紫隊模擬演練：**紫隊模擬演練提高了事件回應人員 (藍隊) 和模擬威脅參與者 (紅隊) 之間的協作層級。藍隊由安全營運中心 (SOC) 的成員組成，但也可以包含在實際網路事件期間涉入的其他利害關係人。紅隊由滲透測試團隊或受過攻擊性安全培訓的主要利害關係人組成。紅隊在設計場景時會與模擬演練協調員合作，使場景精確且可行。在紫隊模擬演練期間，主要重點是偵測機制、工具和支援事件回應工作的標準操作程序 (SOP)。
+ **紅隊模擬演練：**在紅隊模擬演練期間，攻方 (紅隊) 會進行模擬，以在預定範圍內達到某個目標或一組目標。守方 (藍隊) 不一定知道模擬演練的範圍和持續時間，這對他們應對實際事件的能力可呈現出更真實的評估。由於紅隊模擬演練可能是侵入性測試，請謹慎行事並施加控制，以確認該模擬演練不會對您的環境造成實際傷害。
考慮定期推行網路模擬。每種模擬演練類型都可以為參與者和整個組織提供特有的好處，因此您可以選擇從較不複雜的模擬類型 (例如桌上模擬演練) 開始著手，然後再進入更複雜的模擬類型 (紅隊模擬演練)。您應根據自身的安全成熟度、資源和所需的結果來選取模擬類型。由於複雜性和成本較高，有些客戶可能不會選擇執行紅隊模擬演練。
## 實作步驟
無論您選擇的模擬類型為何，模擬通常會執行下列實作步驟：
1. **定義核心演練元素：**定義模擬情境與模擬的目標。這兩者都應獲得領導階層的允許。
1. **識別關鍵利害關係人：**模擬演練至少需要模擬演練協調員和參與者。根據情境，可能會涉及法律、通訊或主管領導階層等其他利害關係人。
1. **建置和測試情境：**如果特定元素不可行，則可能需要在情境建置期間加以重新定義。預計最終的情境會成為此階段的輸出。
1. **促進模擬：**模擬的類型將決定使用的促進形式 (編撰的場景對比於高度技術性的模擬場景)。協調員應使其促進策略與模擬演練目標相對應，他們應盡可能吸引所有模擬演練參與者，以提供最大的效益。
1. **撰寫事後報告 (AAR)：**識別進展順利的領域、可以改進的領域，以及潛在的差距。AAR 應衡量模擬的有效性以及團隊對於模擬事件的應變能力，以便在未來的模擬追蹤進展幅度。
## 資源
**相關文件：**
+ [AWS 事件回應指南](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
**相關影片：**
+ [AWS GameDay - Security Edition](https://www.youtube.com/watch?v=XnfDWID_OQs)
+ [執行有效的安全事件回應模擬](https://www.youtube.com/watch?v=63EdzHT25_A)