# プロセス
<a name="process"></a>

 インシデント対応のプロセスを熟考し、明確に定義することは、インシデント対応プログラムを成功させ、拡張性を持たせるための鍵となります。セキュリティイベントが発生した場合、明確な手順とワークフローがあれば、タイムリーに対応できます。既にインシデント対応プロセスがある場合もあります。現在の状態にかかわらず、インシデント対応プロセスを定期的に更新、反復、テストすることが重要です。

# インシデント対応計画を作成してテストする
<a name="develop-and-test-incident-response-plan"></a>

 インシデント対応のために最初に作成する文書は、*インシデント対応計画*です。インシデント対応計画は、インシデント対応プログラムと戦略の基礎となるように設計されています。インシデント対応計画は、通常は以下のセクションを含む概要文書です。
+ **インシデント対応チームの概要** – インシデント対応チームの目標と機能の概要が記されている 
+ **役割と責任** – インシデントに対応する利害関係者が一覧表示され、インシデント発生時のそれぞれの役割が詳しく記されている 
+ **コミュニケーションプラン** – 連絡先とインシデント発生時の連絡方法が記されている 

   インシデント関連の通信のバックアップ方法としては、帯域外通信を確保することがベストプラクティスです。安全な帯域外通信チャネルを提供するアプリケーションの例は [AWS Wickr](https://aws.amazon.com/wickr/) です。
+ **インシデント対応の各段階と取るべき措置** – インシデント対応の各段階 (検出、分析、根絶、封じ込め、復旧など) を一覧にし、各段階で取るべき措置を大まかに記している
+ **インシデントの深刻度と優先順位の決定** – インシデントの深刻度の分類方法、インシデントの優先付け方法、深刻度の定義がエスカレーション手順にどう影響するか、を詳しく説明している

 これらのセクションは、さまざまな規模や業界の企業で共通していますが、各組織のインシデント対応計画は異なります。組織に最適なインシデント対応計画を立てる必要があります。

# アーキテクチャ図の文書化と一元化
<a name="document-and-centralize-architecture-diagrams"></a>

 セキュリティイベントに迅速かつ正確に対応するには、システムとネットワークがどのように設計されているかを理解する必要があります。これらの内部パターンを理解することは、インシデント対応だけでなく、そのパターンがベストプラクティスに従って設計されているというアプリケーション間の一貫性を検証する上でも重要です。また、この文書が最新であり、新しいアーキテクチャパターンに従って定期的に更新されていることを確認する必要があります。次のような項目を詳述する文書と内部リポジトリを作成する必要があります。
+ **AWS アカウント構造** - 以下を把握しておく必要があります。
  +  AWS アカウントはいくつ存在するか?
  +  それらの AWS アカウントはどのように整理されているか?
  +  AWS アカウントのビジネスオーナーは誰か?
  +  サービスコントロールポリシー (SCP) を使用しているか？ 使用している場合、SCP を使用してどのような組織的なガードレールが実装されているか?
  +  使用できるリージョンとサービスを制限しているか?
  +  ビジネスユニットと環境 (dev/test/prod) にどのような違いがあるか?
+ **AWS サービスパターン** 
  +  どの AWS サービスを使用しているか?
  +  最も広く使用されている AWS サービスは何か?
+ **アーキテクチャパターン** 
  +  どのクラウドアーキテクチャを使用しているか?
+ **AWS 認証パターン** 
  +  デベロッパーは通常、AWS をどのように認証しているか?
  +  IAM ロールまたはユーザー (またはその両方) を使用しているか? AWS の認証は ID プロバイダー (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>

 プレイブックには、起こりうるセキュリティインシデントを適切に調査して対応するために、セキュリティアナリストが実行すべき技術的な手順を記載する必要があります。

 プレイブックに記載すべき項目には次のようなものがあります。
+  **プレイブックの概要** – このプレイブックがどのようなリスクやインシデントシナリオに対応しているか。このプレイブックの目的は何か。
+  **前提条件** – このインシデントシナリオには、どのようなログおよび検出メカニズムが必要か。どのような通知が想定されるか。
+ **ステークホルダー情報** – 関係者とその連絡先情報。各利害関係者の責任は何か。
+ **対応ステップ** – インシデント対応の各フェーズで、どのような戦術的措置を講じるべきか。アナリストはどのようなクエリを実行すべきか。望ましい結果を得るためにどのようなコードを実行すべきか。
  + **検知** – インシデントはどのように検出されるか。
  + **分析** – 影響範囲はどのように特定されるか。
  + **封じ込め** – 影響範囲を限定するために、インシデントをどのように隔離するか。
  + **根絶** – どのようにして脅威を環境から取り除くか。
  + **復旧** – 影響を受けたシステムやリソースをどのようにして本番環境に戻すか。
+ **期待される結果** – クエリとコードが実行された後、プレイブックで想定される結果はどのようなものか。

 各プレイブックの情報の一貫性を検証するには、プレイブックテンプレートを作成して他のセキュリティプレイブックで使用すると便利です。ステークホルダー情報など、以前にリストアップした項目の一部は、複数のプレイブック間で共有できます。この場合、その情報を一元化した文書を作成し、プレイブックで参照してから、そのプレイブックで明示的な違いを列挙することができます。これにより、すべてのプレイブックで同じ情報を逐一更新する必要がなくなります。テンプレートを作成し、プレイブックで共通の情報または共有されている情報を特定することで、プレイブックの作成を簡素化し、スピードアップできます。最後に、プレイブックは時間の経過に伴って進化する可能性があります。ステップの一貫性を確認しておくことは、自動化の要件となります。

# サンプルプレイブック
<a name="sample-playbooks"></a>

 いくつかのサンプルプレイブックを付録 B の「[プレイブックリソース](appendix-b-incident-response-resources.md#playbook-resources)」に用意しています。ここでの例は、どのようなプレイブックを作成するか、どのような内容をプレイブックに含めるかの手引きとして使用できます。とはいえ、重要なのはビジネスに最も関連のあるリスクを組み込んだプレイブックを作成することです。プレイブック内のステップとワークフローに、あなたの会社のテクノロジーとプロセスが含まれていることを確認する必要があります。

# 定期的にシミュレーションを実行する
<a name="run-regular-simulations"></a>

 組織は時間の経過に伴って成長し、進化しますが、それは脅威の状況も同様です。このため、インシデント対応機能を継続的に見直すことが重要です。この評価を行う方法の 1 つとして、シミュレーションがあります。シミュレーションでは、脅威アクターの戦術、手法、手順 (TTP) を模倣するように設計された現実のセキュリティイベントシナリオを使用します。これにより、組織は実際に発生する可能性のある模擬サイバーイベントに対応することで、インシデント対応能力を訓練し、評価できます。

 シミュレーションには、次のようなさまざまな利点があります。
+  サイバー脅威への準備状況を検証し、インシデント対応者の信頼度を高めます。
+  ツールとワークフローの精度と効率性をテストします。
+  インシデント対応計画に沿うように、コミュニケーションとエスカレーションの方法を改良します。
+  あまり一般的でないベクトルに対応する機会を提供します。

# シミュレーションのタイプ
<a name="types-of-simulations"></a>

 シミュレーションには主に 3 つのタイプがあります。
+  **机上演習** – 机上でのシミュレーションは、インシデントに対応するさまざまな利害関係者が参加して役割や責任を実践し、確立されたコミュニケーションツールやプレイブックを活用する、完全にディスカッションベースのセッションです。演習は、通常はバーチャル会場、実際の施設、またはそれらの組み合わせが可能で、丸 1 日かけて進行します。ディスカッションベースのため、机上演習ではプロセス、人材、コラボレーションに焦点を当てます。テクノロジーは議論に不可欠ですが、インシデント対応ツールやスクリプトを実際に使用することは、一般的に机上演習には含まれません。
+  **パープルチーム演習** – パープルチーム演習は、インシデント対応者 (*ブルーチーム*) と模擬の脅威アクター (*レッドチーム*) のコラボレーションレベルを高めるものです。ブルーチームはセキュリティオペレーションセンター (SOC) のメンバーで構成されますが、実際のサイバーイベントに関与する他の利害関係者が参加することもあります。レッドチームは通常、攻撃的なセキュリティのトレーニングを受けたペンテストチームまたは主な利害関係者で構成されています。レッドチームは、シナリオが正確で実現可能なものになるように、演習のファシリテーターと協力して作業します。パープルチーム演習では、インシデント対応の取り組みを支援する検出メカニズム、ツール、標準運用手順 (SOP) に重点が置かれます。
+ **レッドチーム演習** – レッドチーム演習では、攻撃側 (*レッドチーム*) は、あらかじめ決められた範囲から、ある目的または一連の目的を達成するためのシミュレーションを行います。防御側 (*ブルーチーム*) は、演習の範囲と期間について必ずしも知っているとは限らないため、実際のインシデントにどのように対応するか、より現実的に評価できます。レッドチーム演習では侵入テストになる可能性があります。そのため慎重に行い、コントロールを実施して、演習によって環境に実害を与えないことを確認してください。

**注記**  
AWS では、お客様は、パープルチーム演習またはレッドチーム演習を行う前に、[ペネトレーションテストのウェブサイト](https://aws.amazon.com/security/penetration-testing/)で利用可能なペネトレーションテストのポリシーを確認する必要があります。

 表 1 は、これらのタイプのシミュレーションの主な違いをまとめたものです。定義は一般に緩やかな定義と見なされ、組織のニーズに合わせてカスタマイズできることに注意してください。

*表 1 – シミュレーションのタイプ*


|   |  机上演習  |  パープルチーム演習  |  レッドチーム演習  | 
| --- | --- | --- | --- | 
|  まとめ |  1 つの特定のセキュリティインシデントシナリオに焦点を当てた、紙ベースの演習。概要または技術的な内容とすることができ、紙の資料を使用して実行されます。 |  机上演習と比較してより現実的なタイプです。パープルチーム演習の間、ファシリテーターは参加者と協力して演習のエンゲージメントを高め、必要に応じてトレーニングを提供します。 |  一般的に、より高度なタイプのシミュレーションです。通常は隠密性が高く、参加者が演習のすべての詳細を把握しない場合があります。 | 
|  必要なリソース |  必要な技術リソースは限定的  |  さまざまなステークホルダーが必要、高度な技術リソースが必要  |  さまざまなステークホルダーが必要、高度な技術リソースが必要  | 
|  複雑さ |  低  |  中  |  高  | 

 定期的にサイバーシミュレーションを実施することを検討してください。演習は、タイプごとにそれぞれのメリットを参加者と組織全体にもたらします。それほど複雑ではないタイプのシミュレーション (机上演習など) から始めて、より複雑なシミュレーションタイプ (レッドチーム演習) に進むこともできます。セキュリティの成熟度、リソース、目標とする成果に基づいてシミュレーションタイプを選択する必要があります。お客様によっては、複雑さやコスト面から、レッドチーム演習を選択しない場合があります。

# 演習ライフサイクル
<a name="exercise-lifecycle"></a>

 選択したシミュレーションタイプにかかわらず、シミュレーションは通常、以下のような手順に従います。

1.  **演習の中核要素の定義** – シミュレーションのシナリオと目的を定義します。いずれも、リーダーの承認が必要です。

1. **主な利害関係者の特定** – 少なくとも、演習には演習のファシリテーターと参加者が必要です。シナリオによっては、追加で法務、コミュニケーション、経営幹部などの利害関係者が関与する場合があります。

1. **シナリオの構築とテスト** – 特定の要素が実現不可能な場合は、シナリオの構築中に再定義が必要なこともあります。このステージのアウトプットとして、シナリオの最終版が完成することが期待されます。

1. **シミュレーションの進行** – シミュレーションのタイプによって、使用する進行内容 (紙ベースのシナリオと技術的に高度なシミュレーションシナリオの比較) が決まります。ファシリテーターは、演習進行の戦略を目的に合わせて調整し、最大の効果が得られるように、できるだけすべての参加者に演習に参加してもらう必要があります。

1. **アフターアクションレビュー (AAR) の作成** – うまくいった部分、改善の余地がある部分、潜在的なギャップを特定します。AAR では、シミュレーションの有効性だけでなく、シミュレートされたイベントに対するチームの反応も測定して、今後のシミュレーションの進捗を経時的に追跡できるようにする必要があります。