# インシデントへの対応
成熟した予防的、発見的統制が実装されていても、組織はセキュリティインシデントの潜在的な影響に対応し、影響を緩和するメカニズムを実装する必要があります。準備することで、インシデントの際にチームが効果的に動作し、問題を切り分け、封じ込め、フォレンジックを実行し、運用を既知の正常な状態に復元する能力に強く影響します。セキュリティインシデントが起こる前にツールとアクセス権を整備し、ゲームデー (実践訓練) を通じてインシデント対応を定期的に実施しておけば、ビジネスの中断を最小限に抑えながら復旧することができます。
**Topics**
+ [AWS におけるインシデント対応の諸側面](aspects-of-aws-incident-response.md)
+ [クラウドレスポンスの設計目標](design-goals-of-cloud-response.md)
+ [準備](preparation.md)
+ [オペレーション](operations.md)
+ [インシデント後のアクティビティ](post-incident-activity.md)
# AWS におけるインシデント対応の諸側面
組織内のすべての AWS ユーザーは、セキュリティインシデント対応プロセスの基本を理解している必要があり、セキュリティ担当者はセキュリティ問題への対応方法を理解している必要があります。教育、トレーニング、経験は、クラウドインシデント対応プログラムを成功させるために不可欠であり、起こり得るセキュリティインシデントに対処する前に十分な余裕を持って実施するのが理想的です。クラウドでのインシデント対応プログラムの成功基盤は、準備、オペレーション、インシデント後アクティビティです。
これらの各側面を理解するには、以下の説明を参考にしてください。
+ **準備**: 検出制御を有効にし、必要なツールやクラウドサービスへの適切なアクセスを検証することで、インシデント対応チームが AWS 内のインシデントを検出して対応できるように準備します。さらに、信頼性の高い一貫した応答を検証するために、手動と自動の両方で必要なプレイブックを準備します。
+ **オペレーション**: NIST のインシデント対応フェーズ (検出、分析、封じ込め、根絶、復旧) に従って、セキュリティイベントと潜在的なインシデントに対処します。
+ **インシデント後アクティビティ:** セキュリティイベントとシミュレーションの結果を反復することで、対応の有効性を改善し、対応と調査から得られる価値を高め、リスクをさらに軽減します。インシデントから学び、改善活動に対する強いオーナーシップを持つ必要があります。
下図は、前述の NIST のインシデント対応ライフサイクルに沿った、これらの側面のフローを示しています。ここでの業務には、検出と分析に加えて、封じ込め、根絶、復旧が含まれています。
![\[AWS におけるインシデント対応業務のサイクルを示す図。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/security-pillar/images/aws-incident-response.png)
# クラウドレスポンスの設計目標
「[NIST SP 800-61 コンピュータセキュリティインシデント処理ガイド](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final)」などで定義されてインシデント対応の一般的なプロセスとメカニズムは変わりませんが、クラウド環境でのセキュリティインシデントへの対応に関連する以下の特定の設計目標を評価することをお勧めします。
+ **対応目標の確立:** ステークホルダー、法律顧問、組織のリーダーと協力してインシデント対応の目標を決定します。共通の目標には、問題の封じ込めと緩和、影響を受けたリソースの復旧、フォレンジック用のデータの保全、既知の安全な運用への復帰、そして最終的にはインシデントからの学習などがあります。
+ **クラウドを使用して応答する:** イベントとデータが発生するクラウド内に応答パターンを実装します。
+ **持っているものと必要なものを知る:** ログ、リソース、スナップショット、その他の証拠は、対応専用の一元化されたクラウドアカウントにコピーして保存します。管理ポリシーを適用するタグ、メタデータ、メカニズムを使用します。使用しているサービスを把握し、それらのサービスを調査するための要件を特定する必要があります。環境を把握しやすくするために、タグ付けを使用することもできます。
+ **再デプロイメカニズムを使用する:** セキュリティの異常が設定ミスに起因する場合は、適切な設定でリソースを再デプロイして差異を取り除くだけで解決できる場合があります。セキュリティ侵害の可能性が見つかった場合は、根本原因に対する適切で検証済みの緩和策が再デプロイに含まれていることを確認します。
+ **可能な場合は自動化する:** 問題が発生したり、インシデントが繰り返されたりした場合は、一般的なイベントをプログラムで優先順位付けして対応するメカニズムを構築します。自動化が不十分で、特殊かつ複雑、または機密性の高いインシデントには、人手で対応します。
+ **スケーラブルなソリューションを選択する:** 組織のアプローチのスケーラビリティがクラウドコンピューティングと適合しているように努めます。環境全体にスケールできる検出および対応のメカニズムを実装して、検出から対応までの時間を効果的に短縮します。
+ **プロセスを学び、改善する:** プロセス、ツール、人員におけるギャップを積極的に特定し、それらを修正する計画を実施します。シミュレーションは、ギャップを見つけてプロセスを改善する安全な方法です。
これらの設計目標は、インシデント対応と脅威検知の両方を実施する能力について、アーキテクチャの実装を確認することを促すものです。クラウドの実装を計画するときは、インシデントへの対応を検討します。フォレンジックに基づいた対応方法論を使用するのが理想的です。これは、場合によっては、このような対応タスク用に複数の組織、アカウント、ツールを特別に設定することを意味します。これらのツールと機能は、デプロイパイプラインによってインシデント対応担当者が利用できるようにする必要があります。リスクを大きくする可能性があるため、静的な状態のままにしないでください。
# 準備
インシデントへの準備は、タイムリーかつ効果的なインシデント対応にとって重要です。準備は次の 3 つの分野にわたって行われます。
+ **人員**: セキュリティインシデントに備えて人員を準備するには、インシデント対応に関連するステークホルダーを特定し、インシデント対応とクラウド技術に関するトレーニングを行う必要があります。
+ **プロセス**: セキュリティインシデントに備えてプロセスを準備するには、アーキテクチャの文書化、徹底的なインシデント対応計画の策定、セキュリティイベントへの一貫した対応のためのプレイブックの作成が必要です。
+ **テクノロジー**: セキュリティインシデントに備えてテクノロジーを準備するには、アクセスの設定、必要なログの集約と監視、効果的なアラートメカニズムの実装、対応と調査機能の開発が必要です。
これらの各分野は、効果的なインシデント対応にとって等しく重要です。3 つすべてが揃わなければ、インシデント対応プログラムは完全でも効果的でもありません。インシデントに備えるには、人員、プロセス、テクノロジーを緊密に連携して準備する必要があります。
**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 (Software-as-a-Service) アプリケーションなど、サードパーティーのサービスプロバイダーやベンダーをすべて考慮します。セキュリティイベントの発生時は、適切な責任とアクセス権を持つ担当者が状況を適切に理解して、対応と復旧にあたることができます。
**一般的なアンチパターン:**
+ 主要担当者の連絡先と、セキュリティイベントへの対応時の役割や責任について最新情報をまとめたリストが用意されていない。
+ イベントへの対応や復旧の際に、担当者、依存関係、インフラストラクチャ、ソリューションについて全員がわかっているものだと想定している。
+ 主要なインフラストラクチャやアプリケーションの設計を記載したドキュメントまたはナレッジリポジトリがない。
+ セキュリティイベント発生時の効果的な対応方法を新しい人員に指導する適切なオンボーディングプロセス (イベントシミュレーションの実施など) が用意されていない。
+ 主要担当者が一時的に不在の場合や、セキュリティイベントの発生時に対応できない場合に備えたエスカレーションパスが用意されていない。
**このベストプラクティスを活用するメリット:** このベストプラクティスを活用することで、イベント発生時に適切な担当者とその役割とを特定するのにかかる、トリアージと対応の時間を短縮することができます。主要担当者とその役割の最新リストが用意してあれば、適切な担当者をイベントのトリアージと復旧に投入でき、イベント発生時の時間の無駄使いを極力抑えることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
**組織内の主要な担当者を特定する:** インシデント対応に必要な、組織内の担当者の連絡先一覧を保存します。この情報を定期的に見直し、組織編成の変更、昇進、チームの変更など、人員配置に変更があった場合は適宜更新してください。インシデント管理者、インシデント対応者、コミュニケーションリーダーなどの主要な役割については特に重要です。
+ **インシデント管理者:** インシデント管理者は、イベント対応時のすべての権限を有します。
+ **インシデント対応者:** インシデント対応者はインシデントの調査および修正を担当する人です。これらの人員はイベントの種類によって異なりますが、通常は、影響を受けたアプリケーションを担当する開発者や運用チームです。
+ **コミュニケーションリーダー:** コミュニケーションリーダーは、組織内外とのコミュニケーション、特に公的機関、規制当局、顧客とのコミュニケーションを担当します。
+ **オンボーディングプロセス:** インシデント対応活動に効果的に貢献するために必要なスキルと知識を新入社員に身につけさせるために、定期的にトレーニングとオンボーディングを実施します。オンボーディングプロセスの一環としてシミュレーションと実践演習を取り入れて準備を整える
+ **対象分野のエキスパート (SME)**: 分散型の自律的なチームの場合は、ミッションクリティカルなワークロードに 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. インシデントの発生時に連絡が取れるように、連絡先ごとに少なくとも 2 種類の連絡チャネル (SMS、電話、E メールなど) を定義します。
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 customer playbook framework](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [Prepare for and respond to security incidents in your AWS environment](https://youtu.be/8uiO0Z5meCs)
**関連ツール:**
+ [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html)
**関連動画:**
+ [Amazon's approach to security during development](https:/www.youtube.com/watch?v=NeR7FhHqDGQ)
# SEC10-BP02 インシデント管理計画を作成する
インシデント対応のために最初に作成する文書は、インシデント対応計画です。インシデント対応計画は、インシデント対応プログラムと戦略の基礎となるように設計されています。
**このベストプラクティスを活用するメリット:** インシデント対応のプロセスを熟考し、明確に定義することは、インシデント対応プログラムを成功させ、拡張性を持たせるための鍵となります。セキュリティイベントが発生した場合、明確な手順とワークフローがあれば、タイムリーに対応できます。既にインシデント対応プロセスがある場合もあります。現在の状態にかかわらず、インシデント対応プロセスを定期的に更新、反復、テストすることが重要です。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
インシデント管理計画は、セキュリティインシデントの潜在的な影響への対応、復旧、軽減に不可欠です。インシデント管理計画は、セキュリティインシデントをタイムリーに特定し、修復、対応するための体系的なプロセスです。
クラウドには、オンプレミス環境と同じオペレーション上のロールと要件があります。インシデント管理計画を作成する際は、ビジネス成果とコンプライアンス要件と最も合致する対応および復旧戦略を組み込むことが重要です。例えば、米国で FedRAMP に準拠している AWS のワークロードを運用する場合は、[NIST SP 800-61 Computer Security Handling Guide](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 との関係を構築し、実際のインシデントが発生する前に、SME とインシデント対応シナリオの演習を行ってください。
1. 信頼できるパートナーや外部の専門家を調査や対応プロセスに参加させることにより、さらなる専門知識や視点を得ることができます。
1. インシデント管理の計画とロールを、組織を管理する現地の規制やコンプライアンス要件に合わせます。
1. インシデント対応計画を定期的に練習してテストし、定義されたすべての役割と責任を含めます。これにより、プロセスを合理化し、セキュリティインシデントへの対応が調整され、効率的な対応が行われていることを確認できます。
1. ロール、責任、RACI チャートを定期的に、または組織構造や要件の変化に応じて見直して更新します。
**AWS 対応チームとサポートを理解する**
+ **AWS サポート**
+ [サポート](https://aws.amazon.com/premiumsupport/) は、AWS ソリューションの成功とオペレーションの正常性をサポートするツールと専門知識にアクセスできる一連のプランを用意しています。AWS 環境の計画、導入、最適化に役立つテクニカルサポートや、より多くのリソースが必要な場合は、AWS ユースケースに最適なサポートプランを選択できます。
+ AWS リソースに影響する問題に関してサポートを得るための連絡窓口として、AWS マネジメントコンソール (サインインが必要) の[サポートセンター](https://console.aws.amazon.com/support) を検討します。サポートへのアクセスは AWS Identity and Access Management によって制御されます。サポートの機能を利用する方法については、「[Getting started with サポート](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html#accessing-support)」を参照してください。
+ **AWS カスタマーインシデント対応チーム (CIRT)**
+ AWS カスタマーインシデント対応チーム (CIRT) は、[AWS 責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)の顧客側のセキュリティイベントが発生したときに顧客にサポートを提供する、24 時間対応の専門のグローバル AWS チームです。
+ AWS CIRT がお客様をサポートすると、AWS で発生しているセキュリティイベントの優先順位付けと復旧を支援します。AWS サービスログを使用して根本原因の分析を支援し、復旧のための推奨事項を提示します。また、将来のセキュリティイベントを回避するのに役立つセキュリティに関する推奨事項やベストプラクティスを提供することもできます。
+ AWS のお客様は、[サポート case](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/)
+ re:Invent 2024 で発表された AWS Security Incident Response は、最新のトリアージテクノロジーとヒューマンインザループの両方を使用するマネージドセキュリティインシデント対応サービスです。このサービスは、すべての GuardDuty の検出結果と、トリアージのために AWS Security Hub CSPM に送信されたサードパーティーの検出結果を取り込み、調査が必要な検出結果についてのみ顧客に警告します。また、このサービスは、顧客がセキュリティイベントの発生時に事後対応ケースを送信し、AWS の高度なインシデント対応チームからサポートを受けるためのポータルも提供します。
+ **DDoS 対応のサポート**
+ AWS が提供する [AWS Shield](https://aws.amazon.com/shield/) は、AWS で実行中のウェブアプリケーションを保護する、分散型サービス拒否攻撃 (DDoS) のマネージド型防御サービスです。Shield を使用すれば、常時検出と自動インライン緩和の機能により、アプリケーションのダウンタイムとレイテンシーを最小限に抑えることができ、DDoS 防御に サポートを使う必要がなくなります。Shield は、AWS Shield Standard と AWS Shield Advanced の 2 種類に分かれています。両者の違いに関する詳細は、「[AWS 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 は、一連のセキュリティ検出コントロールの展開に責任を持ち、24 時間 365 日、第一線でアラートに対応します。アラートが発生すると、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: Computer Security Incident Handling Guide](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf)
# SEC10-BP03 フォレンジック機能を備える:
セキュリティインシデントが発生する前に、セキュリティイベントの調査を支援するフォレンジック機能の整備を検討します。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
AWS には、従来のオンプレミスフォレンジックの概念が適用されます。AWS クラウドでフォレンジック機能の構築を開始するための重要な情報については、「[Forensic investigation environment strategies in the AWS クラウド](https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud/)」を参照してください。
フォレンジックのための環境と AWS アカウント構造が整ったら、次の 4 つのフェーズにわたってフォレンジックに適した方法論を効果的に実行するために必要なテクノロジーを定義します。
+ **収集:** AWS CloudTrail、AWS Config、VPC フローログ、ホストレベルのログなどの関連 AWS ログを収集します。可能であれば、影響を受けた AWS リソースのスナップショット、バックアップ、メモリダンプを収集します。
+ **調査:** 関連する情報を抽出して評価することにより、収集されたデータを検証します。
+ **分析:** 収集したデータを分析してインシデントを解明し、そこから結論を導き出します。
+ **レポート:** 分析フェーズから得られた情報を報告します。
## 実装手順
**フォレンジック環境を準備する**
[AWS Organizations](https://aws.amazon.com/organizations/) では、AWS リソースの拡大とスケールに合わせて、AWS 環境を一元的に管理および運用できます。AWS 組織を利用することで、AWS アカウントを統合して 1 つのユニットとして管理できるようになります。組織単位 (OU) を使用すると、アカウントをまとめてグループ化し、単一の単位として管理できます。
インシデント対応には、セキュリティ OU および フォレンジック OU を含むインシデント対応の機能をサポートする AWS アカウント構造があると便利です。セキュリティ OU 内には、次のアカウントが必要です。
+ **ログアーカイブ:** 限られたアクセス許可を持つログアーカイブ用の AWS アカウントにログを集約します。
+ **セキュリティツール:** セキュリティサービスをセキュリティツール用の AWS アカウントに一元化します。このアカウントは、セキュリティサービスの委任管理者として機能します。
フォレンジック OU 内では、お客様のビジネスモデルと運用モデルに最適なフォレンジックアカウントに応じて、フォレンジック用に 1 つのアカウントを実装するか、事業を展開するリージョンごとにアカウントを実装できます。リージョンごとにフォレンジックアカウントを作成すると、そのリージョン外での AWS リソースの作成をブロックし、リソースが意図しないリージョンにコピーされるリスクを低減できます。例えば、米国東部 (バージニア北部) リージョン (`us-east-1`) および 米国西部 (オレゴン) (`us-west-2`) のみで運用する場合、フォレンジック OU には 2 つのアカウントがあります。1 つは `us-east-1` 用で、もう 1 つは `us-west-2` 用です。
複数のリージョンのフォレンジック AWS アカウントを作成できます。そのアカウントに AWS リソースをコピーする場合は、データ主権に関する要件に準拠しているか注意する必要があります。新しいアカウントのプロビジョニングには時間がかかるため、インシデントのかなり前にフォレンジックアカウントを作成して実装し、対応担当者が効果的に対応できるように準備しておくことが重要です。
次の図は、リージョンごとのフォレンジックアカウントを持つフォレンジック OU を含むアカウント構造の例を示しています。
![\[インシデント対応のためのリージョンごとのアカウント構造を示したフロー図。セキュリティおよびフォレンジック OU に分かれています。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/security-pillar/images/region-account-structure.png)
**バックアップとスナップショットをキャプチャする**
主要なシステムとデータベースのバックアップをセットアップすることは、セキュリティインシデントからの回復とフォレンジックのために重要です。バックアップを作成しておけば、システムを以前の安全な状態に復元できます。AWS では、さまざまなリソースのスナップショットを作成できます。スナップショットでは、こうしたリソースのポイントインタイムバックアップを作成できます。バックアップや復旧をサポートできる AWS のサービスは数多くあります。これらのサービス、バックアップと復旧のアプローチの詳細については、[バックアップと復旧についての規範ガイダンス](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/services.html)および「[Use backups to recover from security incidents](https://aws.amazon.com/blogs/security/use-backups-to-recover-from-security-incidents/)」を参照してください。
特にランサムウェアのような状況では、バックアップをしっかりと保護することが重要です。バックアップの保護に関するガイダンスについては、「[Top 10 security best practices for securing backups in AWS](https://aws.amazon.com/blogs/security/top-10-security-best-practices-for-securing-backups-in-aws/)」を参照してください。バックアップの保護に加えて、バックアップと復元のプロセスを定期的にテストして、導入しているテクノロジーとプロセスが想定どおりに機能することを確認する必要があります。
**フォレンジックを自動化する**
セキュリティイベント中、インシデント対応チームは、イベント前後の期間の証拠を、正確性を維持しながら迅速に収集して分析できなければなりません (特定のイベントやリソースに関連するログのキャプチャ、Amazon EC2 インスタンスのメモリダンプの収集など)。インシデント対応チームにとって、関連する証拠を手作業で収集することは困難であり、時間もかかります。多数のインスタンスやアカウントが対象となる場合は特にそうです。さらに、手作業による収集では人為的ミスが起こりやすくなります。このような理由から、フォレンジックの自動化を可能な限り開発し、実装する必要があります。
AWS には、フォレンジック用の自動化リソースが多数用意されており、これらのリソースは以下のリソースセクションに一覧表示されています。これらのリソースは、当社が開発し、お客様が実装したフォレンジックパターンの例です。手始めに参考にするリファレンスアーキテクチャとしては有効かもしれませんが、環境、要件、ツール、フォレンジックプロセスに基に変更するか、新しいフォレンジック自動化パターンを作成することを検討してください。
## リソース
**関連ドキュメント:**
+ [AWS Security Incident Response Guide - Develop Forensics Capabilities ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/develop-forensics-capabilities.html)
+ [AWS Security Incident Response Guide - Forensics Resources ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-b-incident-response-resources.html#forensic-resources)
+ [Forensic investigation environment strategies in the AWS クラウド](https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud/)
+ [How to automate forensic disk collection in AWS](https://aws.amazon.com/blogs/security/how-to-automate-forensic-disk-collection-in-aws/)
+ [AWS 規範ガイダンス - Automate incident response and forensics](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/automate-incident-response-and-forensics.html)
**関連動画:**
+ [Automating Incident Response and Forensics](https://www.youtube.com/watch?v=f_EcwmmXkXk)
**関連する例:**
+ [Automated Incident Response and Forensics Framework](https://github.com/awslabs/aws-automated-incident-response-and-forensics)
+ [Automated Forensics Orchestrator for 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 Customer Incident Response Team (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)
**関連ドキュメント:**
+ [Framework for Incident Response Playbooks](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [Develop your own Incident Response Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks-workshop)
+ [Incident Response Playbook Samples](https://github.com/aws-samples/aws-incident-response-playbooks)
+ [Building an AWS incident response runbook using Jupyter playbooks and CloudTrail Lake](https://catalog.workshops.aws/incident-response-jupyter/en-US)
# SEC10-BP05 アクセスを事前プロビジョニングする
インシデント対応者が AWS に事前プロビジョニングされた正しいアクセス権を持っていることを検証しておき、調査から復旧までに必要な時間を短縮します。
**一般的なアンチパターン:**
+ ルートアカウントをインシデント対応に使用する
+ 既存のアカウントに変更を加える
+ ジャストインタイムの権限昇格を提供する際に IAM アクセス許可を直接操作する
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
AWS は、可能であれば長期的な認証情報への依存を削減または排除し、一時的な認証情報とジャストインタイムの権限昇格メカニズムを優先することを推奨します。長期的な認証情報は、セキュリティリスクにさらされやすく、オペレーションのオーバーヘッドを増大させます。ほとんどの管理タスクと、インシデント対応タスクについては、[管理アクセスの一時的な昇格](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/)と併せて [ID フェデレーション](https://aws.amazon.com/identity/federation/)を実装することをお勧めします。このモデルでは、ユーザーはより高いレベルの権限 (インシデント対応ロールなど) への昇格をリクエストします。ユーザーに昇格の資格がある場合、リクエストは承認者に送信されます。リクエストが承認された場合、ユーザーは、一時的な [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)を使用してアクセスのスコープを定義することです。
ID フェデレーションを使用できないケースがあります。例えば次のケースです。
+ 侵害を受けた ID プロバイダー (IdP) に関連する停止状態
+ 設定ミスや人的エラーに起因する、フェデレーションアクセス管理システムの障害
+ 分散型サービス拒否 (DDoS) イベントやシステムがレンダリング不可となるなどの悪意あるアクティビティ
上記のケースでは、緊急 break glass アクセス設定により、インシデントの調査とタイムリーな修復を許可する必要があります。[適切な許可を持つユーザー、グループ、ロール](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 Security Best Practices for [AWS Organizations SCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)」に記載されています。ユーザーは、他のアカウントのインシデント対応ロールを引き受ける以外の権限を持つべきではありません。
インシデント対応中、調査、修復、または復旧アクティビティをサポートするためのアクセス権を社内または社外の他の個人に付与する必要が生じる可能性があります。この場合、前述のプレイブックメカニズムを使用します。また、インシデント完結後直ちに追加のアクセス権を取り消すためのプロセスが必要です。
インシデント対応ロールの使用が適切に監視および監査されていることを検証するには、この目的のために作成された 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/)ために使用する必要があります。ルートキーを使用する際のアラートの設定に関するブログ記事を参照してください。インストラクションに変更を加えて、[Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) メトリクスフィルターをインシデント対応 IAM ロールに関連する `AssumeRole` イベントに対して設定できます。
```
{ $.eventName = "AssumeRole" && $.requestParameters.roleArn = "" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" }
```
インシデント対応ロールは高いレベルのアクセス権を持っている可能性があるため、これらのアラートは幅広いグループに送信され、すみやかに対応が取られることが重要です。
インシデント対応中、対応者は、IAM によって直接保護されていないシステムへのアクセスが必要となる可能性があります。これには Amazon Elastic Compute Cloud インスタンス、Amazon Relational Database Service データベース、Software-as-a-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 Systems Manager Run Command ドキュメント](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)を使用してプレイブックの一部を自動化することも可能です。それにより、ユーザーのエラーを減らし、復旧にかかる時間を短縮できます。データベースとサードパーティーツールへのアクセスでは、アクセス認証情報を AWS Secrets Manager に保管し、インシデント対応者ロールにアクセス権を付与することをお勧めします。
最後に、インシデント対応 IAM ユーザーアカウントの管理は、[Joiners、Movers、および Leavers プロセス](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html)に追加し、定期的にテストして、意図されたアクセスのみが許可されていることを検証する必要があります。
## リソース
**関連ドキュメント:**
+ [Managing temporary elevated access to your AWS environment](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/)
+ [Best Practices for AWS Organizations Service Control Policies in a Multi-Account Environment](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/)
+ [How to Receive Notifications When Your AWS Account’s Root Access Keys Are Used](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/)
+ [Create fine-grained session permissions using IAM managed policies](https://aws.amazon.com/blogs/security/create-fine-grained-session-permissions-using-iam-managed-policies/)
+ [Break glass access](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/break-glass-access.html)
**関連動画:**
+ [Automating Incident Response and Forensics in AWS](https://www.youtube.com/watch?v=f_EcwmmXkXk)
+ [DIY guide to runbooks, incident reports, and incident response](https://youtu.be/E1NaYN_fJUo)
+ [Prepare for and respond to security incidents in your AWS environment](https://www.youtube.com/watch?v=8uiO0Z5meCs)
# SEC10-BP06 ツールを事前デプロイする
復旧までの調査時間を短縮できるように、セキュリティ担当者は適切なツールを事前にデプロイしておきます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
セキュリティ対応と運用機能を自動化するために、AWS の包括的な API とツールセットを使用できます。ID 管理、ネットワークセキュリティ、データ保護、モニタリング機能を完全に自動化し、既に導入されている一般的なソフトウェア開発方法を使用して提供できます。セキュリティオートメーションを構築すれば、担当者がセキュリティ上の位置づけを監視し、イベントに手動で応答する代わりに、システムが監視、レビューを行い応答を開始できます。
インシデント対応チームが同じ方法でアラートに対応し続けると、アラート疲れになるリスクがあります。時間の経過とともに、チームはアラートに対する感度が鈍くなり、通常の状況の処理で間違いを犯したり、異常なアラートを見逃したりする可能性があります。自動化を利用すれば、繰り返し発生する通常のアラートを処理する機能を使用してアラート疲れを回避し、機密性の高いインシデントや独自のインシデントの処理を人間に任せることができます。Amazon GuardDuty、AWS CloudTrail Insights、および Amazon CloudWatch Anomaly Detection などの異常の検出システムを統合することで、よくあるしきい値ベースのアラートの負担を減らすことができます。
プロセス内のステップをプログラムで自動化すれば、手動プロセスを改善できます。イベントに対する修復パターンを定義したら、そのパターンを実行可能なロジックに分解して、そのロジックを実行するコードを記述できます。その後、対応者は、そのコードを実行して問題を修正します。時間の経過とともに、より多くのステップを自動化し、最終的には一般的なインシデントのクラス全体を自動的に処理できるようになります。
セキュリティ調査中、インシデントの全容とタイムラインを記録して理解するために、関連ログを確認できる必要があります。ログはまた、関心のある特定のアクションが発生したことを示すアラート生成にも必須です。クエリと取得のメカニズムとアラートを選択、有効化、保存、セットアップし、アラート発行を設定することが非常に重要となります。さらに、ログデータを検索するツールとして、[Amazon Detective](https://aws.amazon.com/detective/) が有効です。
AWS では、200 を超えるクラウドサービスと数千の機能を提供しています。インシデント対応戦略をサポートし、簡素化できるサービスを確認することをお勧めします。
ログ記録に加えて、[タグ付け戦略](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)を策定して実装する必要があります。タグ付けを行うことで、AWS リソースの目的についての背景情報を付け加えることができます。タグ付けは自動化にも使用できます。
### 実装手順
**分析とアラート発行のためのログを選択して設定する**
インシデント対応のログ記録の設定については、次のドキュメントを参照してください。
+ [Logging strategies for security incident response](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)」および「[Security Incident Response のホームページ](https://aws.amazon.com/security-incident-response/)」を参照してください。
**タグ付け戦略を策定し、実装する**
AWS リソースを取り巻くビジネスユースケースやかかわりのある内部関係者についての背景情報の入手は難しい場合があります。これを達成する方法の 1 つとして、タグを使用して、ユーザー定義のキーと値で構成されるメタデータを AWS リソースに割り当てる方法があります。タグを作成して、目的、所有者、環境、処理されるデータの種類など、任意の基準でリソースを分類できます。
一貫したタグ付け戦略があると、AWS リソースに関する背景情報をすばやく特定、識別できるため、応答時間を短縮し、組織の背景情報の把握に費やす時間を最小限に抑えることができます。タグは、対応の自動化を開始するためのメカニズムとしても機能します。タグ付けする対象の詳細については、「[Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)」を参照してください。まず、組織全体に導入するタグを定義する必要があります。その後、このタグ付け戦略を導入し、適用します。導入と適用の詳細については、「[Implement AWS resource tagging strategy using AWS Tag Policies and Service Control Policies (SCPs)](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)
**関連ドキュメント:**
+ [Logging strategies for security incident response](https://aws.amazon.com/blogs/security/logging-strategies-for-security-incident-response/)
+ [Incident response cloud capability definitions](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 Workshop](https://catalog.workshops.aws/security)
+ [Vulnerability Management with Amazon Inspector](https://catalog.workshops.aws/inspector/en-US)
# SEC10-BP07 シミュレーション行う
組織が成長し進化するにつれて、脅威の状況も変化するため、インシデント対応能力を継続的に見直すことが重要になります。この評価を行う方法の 1 つとして、シミュレーション (ゲームデーとも呼ばれる) の実施があります。シミュレーションでは、脅威アクターの戦術、手法、手順 (TTP) を模倣するように設計された現実のセキュリティイベントシナリオを使用します。これにより、組織は実際に発生する可能性のある模擬サイバーイベントに対応することで、インシデント対応能力を訓練し、評価できます。
**このベストプラクティスを活用するメリット:** シミュレーションにはさまざまな利点があります。
+ サイバー脅威への準備状況を検証し、インシデント対応者の信頼度を高めます。
+ ツールとワークフローの精度と効率性をテストします。
+ インシデント対応計画に沿うように、コミュニケーションとエスカレーションの方法を改良します。
+ あまり一般的でないベクトルに対応する機会を提供します。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
シミュレーションには主に 3 つのタイプがあります。
+ **机上演習:** 机上でのシミュレーションは、インシデントに対応するさまざまな利害関係者が参加して役割や責任を実践し、確立されたコミュニケーションツールやプレイブックを活用するディスカッションベースのセッションです。演習は、通常はバーチャル会場、実際の施設、またはそれらの組み合わせが可能で、丸 1 日かけて進行します。ディスカッションベースのため、机上演習ではプロセス、人材、コラボレーションに焦点を当てます。テクノロジーは議論に不可欠ですが、インシデント対応ツールやスクリプトを実際に使用することは、一般的に机上演習には含まれません。
+ **パープルチーム演習:** パープルチーム演習は、インシデント対応者 (ブルーチーム) と模擬の脅威アクター (レッドチーム) のコラボレーションレベルを高めるものです。ブルーチームはセキュリティオペレーションセンター (SOC) のメンバーで構成されますが、実際のサイバーイベントに関与する他の利害関係者が参加することもあります。レッドチームは、攻撃的なセキュリティのトレーニングを受けたペンテストチームまたは主な利害関係者で構成されています。レッドチームは、シナリオが正確で実現可能なものになるように、演習のファシリテーターと協力して作業します。パープルチーム演習では、インシデント対応の取り組みを支援する検出メカニズム、ツール、標準運用手順 (SOP) に重点が置かれます。
+ **レッドチーム演習:** レッドチーム演習では、攻撃側 (レッドチーム) は、あらかじめ決められた範囲から、ある目的または一連の目的を達成するためのシミュレーションを行います。防御側 (ブルーチーム) は、演習の範囲と期間について必ずしも知識を持っているとは限らないため、実際のインシデントにどのように対応するか、より現実的に評価できます。レッドチーム演習では侵入テストになる可能性があります。そのため慎重に行い、コントロールを実施して、演習によって環境に実害を与えないことを確認してください。
定期的にサイバーシミュレーションを実施することを検討してください。演習は、タイプごとにそれぞれのメリットを参加者と組織全体にもたらします。それほど複雑ではないタイプのシミュレーション (机上演習など) から始めて、より複雑なシミュレーションタイプ (レッドチーム演習) に進むこともできます。セキュリティの成熟度、リソース、目標とする成果に基づいてシミュレーションタイプを選択する必要があります。お客様によっては、複雑さやコスト面から、レッドチーム演習を選択しない場合があります。
## 実装手順
選択したシミュレーションタイプにかかわらず、シミュレーションは通常、以下のような実施手順に従います。
1. **演習の中核要素の定義:** シミュレーションのシナリオと目的を定義します。いずれも、リーダーの承認が必要です。
1. **主な利害関係者の特定:** 少なくとも、演習には演習のファシリテーターと参加者が必要です。シナリオによっては、追加で法務、コミュニケーション、経営幹部などの利害関係者が関与する場合があります。
1. **シナリオの構築とテスト:** 特定の要素が実現不可能な場合は、シナリオの構築中に再定義が必要なこともあります。このステージのアウトプットとして、シナリオの最終版が完成することが期待されます。
1. **シミュレーションの進行:** シミュレーションのタイプによって、使用する進行内容 (紙ベースのシナリオと技術的に高度なシミュレーションシナリオの比較) が決まります。ファシリテーターは、演習進行の戦略を目的に合わせて調整し、最大の効果が得られるように、できるだけすべての参加者に演習に参加してもらう必要があります。
1. **アフターアクションレビュー (AAR) の作成:** うまくいった部分、改善の余地がある部分、潜在的なギャップを特定します。AAR では、シミュレーションの有効性だけでなく、シミュレートされたイベントに対するチームの反応も測定して、今後のシミュレーションの進捗を経時的に追跡できるようにする必要があります。
## リソース
**関連ドキュメント:**
+ [AWS Incident Response Guide](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)
# オペレーション
インシデント対応の実施では、オペレーションが中核となります。ここで、セキュリティインシデントへの対応と修復が行われます。オペレーションには、検出、分析、封じ込み、根絶、復旧 の 5 つのフェーズが含まれます。これらのフェーズと目標の説明は、次の表にあります。
| **[Phase]** (フェーズ) | **目標** |
| --- | --- |
| 検出 | 潜在的なセキュリティイベントを特定します。 |
| 分析 | セキュリティイベントがインシデントかどうかを判断し、インシデントの範囲を評価します。 |
| 封じ込み | セキュリティイベントの範囲を最小限に抑え、制限します。 |
| 根絶 | セキュリティイベントに関連する不正なリソースやアーティファクトを削除します。セキュリティインシデントの原因となった緩和策を実装します。 |
| 復旧 | システムを既知の安全な状態に復元し、これらのシステムを監視して脅威が再発しないことを確認します。 |
これらのフェーズは、効果的かつ堅牢な方法で対応するために、セキュリティインシデントに対応して運用する際の指針となるはずです。実際に実行するアクションは、インシデントによって異なります。例えば、ランサムウェアが関係するインシデントは、パブリック Amazon S3 バケットに関連するインシデントとは異なる対応手順を踏む必要があります。さらに、これらのフェーズは必ずしも連続して発生するわけではありません。封じ込みおよび根絶後は、分析に戻って対策が効果的だったかどうかを把握する必要があるかもしれません。
人員、プロセス、テクノロジーを綿密に準備することが、業務を効果的に行う鍵となります。したがって、[準備](preparation.md)セクションのベストプラクティスに従って、アクティブなセキュリティイベントに効果的に対応できるようにします。
詳細については、「AWS セキュリティインシデント対応ガイド」の「[オペレーション](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/operations.html)」セクションを参照してください。
# インシデント後のアクティビティ
脅威の状況は絶えず変化しているため、環境を効果的に保護するためには、組織の能力も同様に動的なものにすることが重要です。継続的な改善の鍵は、インシデントとシミュレーションの結果を反復することで、想定されるセキュリティインシデントを効果的に検出、対応、調査する能力を向上させることです。これにより、想定される脆弱性や、対応までの時間を短縮し、安全なオペレーションに復帰することができます。以下のメカニズムは、組織がどのような状況でも効果的に対応するための最新の能力と知識を十分に備えていることを確認するのに役立ちます。
**Topics**
+ [SEC10-BP08 インシデントから学ぶためのフレームワークを確立する](sec_incident_response_establish_incident_framework.md)
# SEC10-BP08 インシデントから学ぶためのフレームワークを確立する
教訓フレームワークと根本原因分析プロセスを導入することは、インシデント対応能力の向上だけでなく、インシデントの再発防止にも役立ちます。各インシデントから学ぶことで、同じ失敗、露出、設定ミスの繰り返しを防ぐことができ、セキュリティ体制が強化されるだけでなく、予防できたはずの状況に無駄にする時間を最小限に抑えることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
以下の点を大まかに確立して達成する教訓フレームワークを実装することが重要です。
+ 事後検証会を実施するタイミング
+ 事後検証会を通して行うこと
+ 事後検証会の実施方法
+ そのプロセスに関わる人物、またかかわり方
+ 改善の余地がある領域の特定方法
+ 改善事項を効果的に追跡、実装する方法
フレームワークは、個人に焦点を当てたり非難したりするのではなく、ツールやプロセスの改善に焦点を当てるべきです。
### 実装手順
前述の大局的な成果とは別に、プロセスから最大の価値 (実行可能な改善につながる情報) を引き出すためには、適切な質問を行うことが重要です。教訓についての議論を進めるうえで役立つ質問には次のようなものがあります。
+ どのようなインシデントでしたか。
+ インシデントが最初に特定されたのはいつでしたか。
+ どのようにして特定されましたか。
+ どのシステムからアクティビティについてのアラートが発行されましたか。
+ どのようなシステム、サービス、データが関与しましたか。
+ 具体的に何が起きましたか。
+ 何がうまくいきましたか。
+ 何がうまくいきませんでしたか。
+ インシデントに対応できなかった、またはスケールに失敗したのはどのプロセスまたは手順ですか。
+ 次の領域で改善できることは何でしょうか。
+ **People**
+ 連絡する必要があった担当者に実際に連絡がつきましたか。また、連絡先リストの情報は最新のものでしたか。
+ インシデントに効果的に対応して調査するために必要なトレーニングや能力を欠いていましたか。
+ 適切なリソースは用意されていましたか。
+ **プロセス**
+ 対応はプロセスと手順に従って進められましたか。
+ この (タイプの) インシデントについて、プロセスと手順が文書化され、利用可能になっていましたか。
+ 必要なプロセスや手順が欠けていましたか。
+ 対応担当者は、問題に対応するために必要な情報にタイムリーにアクセスできましたか。
+ **テクノロジー**
+ 既存のアラートシステムは、アクティビティを効果的に特定してアラートを出しましたか。
+ どうすれば検出までの時間を 50% 短縮できたでしょうか。
+ この (タイプの) インシデントに備えて、既存のアラートを改善する、または新しいアラートを作成する必要がありますか。
+ 既存のツールでインシデントを効果的に調査 (検索/分析) できましたか。
+ この (タイプの) インシデントをより早く特定するにはどうすればよいでしょうか。
+ この (タイプの) インシデントの再発を防ぐにはどうすればよいでしょうか。
+ 改善計画の所有者は誰ですか。また、その実施状況をどのように検証しますか。
+ 追加のモニタリング、予防的統制やプロセスを導入し、テストするまでのスケジュールはどのようになっていますか。
このリストはすべてを網羅しているわけではありませんが、インシデントから最も効果的に学び、セキュリティ体制の継続的な改善に向けて、組織とビジネスのニーズを見極め、その分析方法を特定するための出発点として活用いただくことを目的としています。最も重要なのは、事後検証会を標準的なインシデント対応プロセスと文書化の一部として取り入れ、想定されるものとして関係者全員にも定着させることです。
## リソース
**関連ドキュメント:**
+ [AWS Security Incident Response Guide - Establish a framework for learning from incidents](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/establish-framework-for-learning.html)
+ [NCSC CAF guidance - Lessons learned](https://www.ncsc.gov.uk/collection/caf/caf-principles-and-guidance/d-2-lessons-learned)