# 分析
分析

 ログ、クエリ機能、脅威インテリジェンスは、分析フェーズで必要とされるサポートコンポーネントの一部です。検出に使用されるログと同じものが分析にも多数使用され、クエリツールのオンボーディングと設定が必要になります。

# アラートの影響の検証、範囲の特定、評価を行う
アラートの影響の検証、範囲の特定、評価を行う

 分析フェーズでは、アラートの検証、範囲の定義、考えられる侵害の影響評価を目的として、包括的なログ分析が実行されます。
+  アラートの*検証*は、分析フェーズのエントリポイントです。インシデント対応者は、さまざまな情報源のログエントリを調べ、影響を受けるワークロードの所有者と直接やり取りします。
+  次のステップは*範囲の特定*です。関係者が誤検出の可能性が低いと判断した後に、関連するすべてのリソースのインベントリが作成され、アラートの重要度が調整されます。
+  最後に、*インパクト分析*で、実際のビジネスの中断について詳しく調べます。

影響を受けるワークロードのコンポーネントが特定されると、範囲の特定結果を関連するワークロードの目標復旧時点 (RPO) と目標復旧時間 (RTO) と相関させ、アラートの重要度を調整して、リソースの割り当てと次に発生するすべてのアクティビティが開始されます。すべてのインシデントが、ビジネスプロセスをサポートするワークロードの運用を直接的に中断するわけではありません。機密データの開示、知的財産の盗難、またはリソースのハイジャック (暗号通貨マイニングなど) といったインシデントは、ビジネスプロセスをすぐに停止または弱体化させることはできませんが、後で被害が生じる可能性があります。

# セキュリティログと検出結果を強化する
セキュリティログと検出結果を強化する

## 脅威インテリジェンスと組織の背景情報による強化
脅威インテリジェンスと組織の背景情報による強化

 分析の過程で、アラートのコンテキスト化を高めるため、対象の観察結果を強化する必要があります。「準備」セクションで説明したように、サイバー脅威インテリジェンスの統合と活用は、セキュリティに関する検出結果をより詳細に理解するのに役立ちます。脅威インテリジェンスサービスは、パブリック IP アドレス、ドメイン名、およびファイルハッシュに評価を割り当て、オーナーシップを帰属させるために使用されます。これらのツールには有料サービスと無料サービスがあります。

 ログクエリツールとして Amazon Athena を採用しているお客様は、AWS Glue ジョブを利用して脅威インテリジェンス情報をテーブルとして読み込むことができます。脅威インテリジェンステーブルを SQL クエリで使用して、IP アドレスやドメイン名などのログ要素を関連付けることで、分析対象のデータの詳細なビューを提供できます。

 AWS は脅威インテリジェンスをお客様に直接提供しませんが、Amazon GuardDuty などのサービスは脅威インテリジェンスを活用して強化や検出結果の生成を行います。独自の脅威インテリジェンスに基づいて、カスタム脅威リストを GuardDuty にアップロードすることもできます。

## 自動化による強化
自動化による強化

 自動化は AWS クラウドのガバナンスに欠かせません。これは、インシデント対応ライフサイクルのさまざまなフェーズで使用できます。

 検出フェーズでは、ルールベースの自動化により、ログ内の脅威モデルから目的のパターンが照合され、通知の送信などの適切なアクションが実行されます。分析フェーズでは、検出メカニズムを活用して、イベントのコンテキスト化のためにログをクエリして検察結果を強化できるエンジンにアラート本文を転送できます。

 アラート本文は、その基本的な形式において、*リソース*と* ID *で構成されます。例えば、アラート本文の ID またはリソースがアラートの発生時に実行した AWS API アクティビティを CloudTrail にクエリする自動化を実装すると、特定された API アクティビティの `eventSource`、`SourceIPAddress`、`eventName`、および `userAgent` などの追加のインサイトを提供できます。これらのクエリを自動的に実行することで、対応者は優先順位付けの時間を節約し、より多くのコンテキストを取得して、より適切な情報に基づいた意思決定を行うことができます。

 自動化を使用してセキュリティの検出結果を強化し、分析を簡素化する方法の例については、ブログ記事「[How to enrich AWS Security Hub findings with account metadata](https://aws.amazon.com/blogs/security/how-to-enrich-aws-security-hub-findings-with-account-metadata/)」を参照してください。

# フォレンジック証拠の収集と分析を行う
フォレンジック証拠の収集と分析を行う

 フォレンジックとは、本書の「[準備](preparation.md)」セクションで説明されているように、インシデント対応中にアーティファクトを収集して分析するプロセスです。AWS では、ネットワークトラフィックのパケットキャプチャ、オペレーティングシステムのメモリダンプなどのインフラストラクチャドメインリソース、および AWS CloudTrail ログなどのサービスドメインリソースに適用されます。

 フォレンジックプロセスには、次の基本的な特性があります。
+  **一貫性** — 文書化された手順から逸脱することなく正確に従います。
+  **再現可能** – 同じアーティファクトに対して処理を繰り返すと、まったく同じ結果が生成されます。
+  **慣習的** – 公開され、広く採用されています。

 インシデント対応中に収集されたアーティファクトの管理の連鎖を維持することが重要です。アーティファクトを読み取り専用リポジトリに保存するだけでなく、この収集を自動化し、記録を自動生成させると便利です。整合性を維持するために、分析は収集されたアーティファクトの正確なレプリカに対してのみ実行する必要があります。

# 関連するアーティファクトを収集する
関連するアーティファクトを収集する

 これらの特性を念頭に置き、関連するアラートおよびインパクトと範囲の評価に基づいて、さらなる調査と分析に関連するデータを収集する必要があります。サービス/コントロールプレーンログ (CloudTrail、Amazon S3 データイベント、VPC フローログ)、データ (Amazon S3 メタデータとオブジェクト)、およびリソース (データベース、Amazon EC2 インスタンス) など、調査に関連する可能性のあるさまざまなタイプとデータソースがあります。

 サービス/コントロールプレーンログは、ローカル分析用に収集することも、ネイティブ AWS サービス (該当する場合) を使用して直接クエリすることもできます。データ (メタデータを含む) を直接クエリして関連情報を取得したり、ソースオブジェクトを取得したりできます。例えば、AWS CLI を使用して Amazon S3 バケットとオブジェクトメタデータを取得し、ソースオブジェクトを直接取得します。リソースは、リソースタイプおよび目的の分析方法と一致する方法で収集する必要があります。例えば、データベースを実行しているシステムのコピー/スナップショットを作成したり、データベース自体のコピー/スナップショットを作成したり、調査に関連するデータベースから特定のデータとログをクエリおよび抽出したりすることで、データベースを収集できます。

 Amazon EC2 インスタンスの場合、分析と調査のために大量のデータを取得および保存するため、収集する必要があるデータセットと、実行する必要がある収集順序が決まっています。

 具体的には、レスポンスが Amazon EC2 インスタンスから大量のデータを取得して保持する順序は次のとおりです。

1.  **インスタンスメタデータの取得** – 調査およびデータクエリに関連するインスタンスメタデータを取得します (インスタンス ID、タイプ、IP アドレス、VPC/サブネット ID、リージョン、Amazon マシンイメージ (AMI) ID、アタッチされたセキュリティグループ、起動時間)。

1.  **インスタンス保護とタグの有効化** – 終了保護、シャットダウン動作を停止に設定 (終了するように設定されている場合)、アタッチされた EBS ボリュームの終了時の削除属性の無効化、および視覚的な表示と対応の自動化での使用の両方に適切なタグの適用 (例えば、名前 `Status` と値 `Quarantine` を持つタグを適用すると、データのフォレンジック取得が実行され、インスタンスが分離される) などのインスタンス保護を有効にします。

1. **ディスクの取得 (EBS スナップショット)** – アタッチされた EBS ボリュームの EBS スナップショットを取得します。各スナップショットには、(スナップショットを作成した瞬間からの) データを新しい EBS ボリュームに復元するために必要な情報が含まれます。インスタンスストアボリュームを使用している場合は、ライブレスポンス/アーティファクト収集を実行するための手順を参照してください。

1. **メモリの取得** – EBS スナップショットは Amazon EBS ボリュームに書き込まれたデータのみをキャプチャするため、アプリケーションまたは OS によってメモリに保存またはキャッシュされたデータは除外される可能性があります。システムから利用可能なデータを取得するためには、適切なサードパーティーのオープンソースまたは市販のツールを使用してシステムメモリのイメージを取得する必要があります。

1. **(オプション) ライブレスポンス/アーティファクト収集の実行** – ディスクまたはメモリを別途取得できない場合、または有効なビジネス上の理由または運用上の理由がある場合にのみ、システムのライブレスポンスを通じてターゲットデータ収集 (ディスク/メモリ/ログ) を実行します。これを行うと、重要なシステムデータとアーティファクトが変更されます。

1. **インスタンスの使用停止** – Auto Scaling グループからインスタンスをデタッチし、ロードバランサーからインスタンスを登録解除し、構築済みのインスタンスプロファイルを最小限のアクセス許可またはアクセス許可なしによって調整または適用します。

1. **インスタンスの分離または封じ込め** – インスタンスとの現在の接続を終了し、将来の接続を防止することで、インスタンスが環境内の他のシステムやリソースから効果的に分離されていることを確認します。詳細については、本書の「[封じ込み](containment.md)」セクションを参照してください。

1. **対応者の選択** – 状況と目標に基づいて、次のいずれかを選択します。
   +  システムを使用停止してシャットダウンします (推奨)。

      利用可能な証拠を取得したら、システムをシャットダウンして、インスタンスによる環境への将来的な影響に対抗する最も効果的な緩和策を検証します。
   +  モニタリング用に実装された分離環境内で、インスタンスの実行を継続します。

      標準アプローチとしては推奨されませんが、インスタンスの継続的な観察に値する状況であれば (例えば、インスタンスの包括的な調査と分析を実行するために追加のデータや指標が必要な場合など)、インスタンスをシャットダウンし、その AMI を作成し、インスタンスをフォレンジック専用アカウント内のサンドボックス環境で再起動することを検討してください。サンドボックス環境は完全に分離されるように事前に実装されており、インスタンスのほぼ継続的なモニタリングを容易にするように設定されています (例: VPC フローログまたは VPC トラフィックミラーリング)。

**注記**  
 利用可能な揮発性 (および価値ある) データをキャプチャするには、ライブレスポンスアクティビティやシステムの分離またはシャットダウンの前にメモリをキャプチャすることが重要です。

# 説明文を作成する
説明文を作成する

 分析と調査中に、実行したアクション、実施した分析、特定された情報を文書化して、後続のフェーズ、および最終的には最終レポートで使用します。これらの説明文は簡潔かつ正確でなければならず、インシデントを効果的に理解し、正確なタイムラインを維持するための関連情報が含まれていることを確認する必要があります。コアインシデント対応チーム以外の人々を関与させる場合にも役立ちます。以下がその例です。

****  
 *2022 年 3 月 15 日に、機密データの公開を避けたければ暗号通貨で支払えと要求する身代金要求書が営業マーケティング部門宛に届きました。SOC は、営業マーケティング部門に属する Amazon RDS データベースが 2022 年 2 月 20 日にパブリックアクセス可能だったと判断しました。SOC が RDS アクセスログをクエリした結果、ウェブ開発者の 1 人である *Major Mary* に属する認証情報 `mm03434` により、IP アドレス 198.51.100.23 が 2022 年 2 月 20 日に使用されたと判断しました。SOC は VPC フローログにクエリを実行し、同日 (タイムスタンプ 2022-02-20T15:50\$100Z) に同じ IP アドレスに約 256MB のデータが送信されたと判断しました。SOC は、オープンソースの脅威インテリジェンスを通じて、認証情報がパブリックリポジトリ `https[:]//example[.]com/majormary/rds-utils` でプレーンテキストで利用可能な状況だと判断しました。*