# オペレーション
インシデント対応の実施では、オペレーションが中核となります。ここで、セキュリティインシデントへの対応と修復が行われます。オペレーションには、検出、分析、封じ込み、根絶、復旧 の 5 つのフェーズが含まれます。**********これらのフェーズと目標の説明を表 3 に記載しています。
*表 3 – オペレーションフェーズ*
| [Phase] (フェーズ) | 目標 |
| --- | --- |
| 検出 | 潜在的なセキュリティイベントを特定します。 |
| 分析 | セキュリティイベントがインシデントかどうかを判断し、インシデントの範囲を評価します。 |
| 封じ込め | セキュリティイベントの範囲を最小限に抑え、制限します。 |
| 根絶 | セキュリティイベントに関連する不正なリソースやアーティファクトを削除します。セキュリティインシデントの原因となった緩和策を実装します。 |
| 復旧 | システムを既知の安全な状態に復元し、これらのシステムを監視して脅威が再発しないことを確認します。 |
これらのフェーズは、効果的かつ堅牢な方法で対応するために、セキュリティインシデントに対応して運用する際の指針となるはずです。実際に実行するアクションは、インシデントによって異なります。例えば、ランサムウェアが関係するインシデントは、パブリック Amazon S3 バケットに関連するインシデントとは異なる対応手順を踏む必要があります。さらに、これらのフェーズは必ずしも連続して発生するわけではありません。封じ込みおよび根絶後は、分析に戻って対策が効果的だったかどうかを把握する必要があるかもしれません。
# 検出
アラートは、検出フェーズの主要コンポーネントです。対象の AWS アカウントの脅威アクティビティに基づいて、インシデント対応プロセスの開始通知を生成します。
精度の高いアラートの生成は難しく、インシデントが発生したか、進行中か、または将来発生するかを常に確実に判断できるわけではありません。いくつかの理由を次に示します。
+ 検出メカニズムは、ベースラインからの逸脱、既知のパターン、内部または外部エンティティからの通知に基づいています。
+ それぞれがセキュリティインシデントの*手段*と*アクター*であるテクノロジーと人員の予測不可能な性質が原因で、ベースラインは時間の経過に伴って変化します。不正なパターンは、脅威アクターの新しいまたは変更された*戦術*、*技術*、*手順* (TTP) を通じて発生します。
+ 人員、テクノロジー、プロセスへの変更は、インシデント対応プロセスにすぐには組み込まれません。調査の進行中に発見されるものもあります。
# アラートのソース
アラートを定義するには、次のソースの使用を検討してください。
+ **検出結果** – [Amazon GuardDuty](https://aws.amazon.com/guardduty/)、[AWS Security Hub CSPM](https://aws.amazon.com/security-hub/)、[Amazon Macie](https://aws.amazon.com/macie/)、[Amazon Inspector](https://aws.amazon.com/inspector/)、[AWS Config](https://aws.amazon.com/config/)、[IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)、[Network Access Analyzer](https://docs.aws.amazon.com/vpc/latest/network-access-analyzer/what-is-vaa.html) などの AWS サービスでは、アラートの作成に使用できる検出結果が生成されます。
+ **ログ** – Amazon S3 バケットと CloudWatch ロググループに保存されている AWS サービス、インフラストラクチャ、アプリケーションログを解析し、相関させることでアラートを生成できます。
+ **請求アクティビティ** – 請求アクティビティの突然の変更は、セキュリティイベントを示している可能性があります。これは「[AWS の予想請求額をモニターリングする請求アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/monitor_estimated_charges_with_cloudwatch.html)」ドキュメントに従ってモニタリングします。
+ **サイバー脅威インテリジェンス** – サードパーティーのサイバー脅威インテリジェンスフィードをサブスクライブする場合、その情報を他のログおよびモニタリングツールと関連付けて、イベントの潜在的な指標を特定できます。
+ **パートナーツール** – AWS Partner Network (APN) のパートナーは、セキュリティ目標の達成に役立つ最上位の製品を提供しています。インシデント対応では、エンドポイントの検出と対応 (EDR) または SIEM を使用するパートナー製品は、インシデント対応目標をサポートします。詳細については、「[Security Partner Solutions](https://aws.amazon.com/security/partner-solutions/)」と「[Security Solutions in the AWS Marketplace](https://aws.amazon.com/marketplace/solutions/security)」を参照してください。
+ **AWS の信頼と安全** – 不正または悪意のあるアクティビティを特定した場合、サポート からお客様に連絡することがあります。
+ **1 回限りの問い合わせ** – お客様、開発者、または組織内の他のスタッフが異常に気付く可能性があるため、セキュリティチームへの連絡方法を周知させ、適切に公開することが重要です。一般的な選択肢には、チケットシステム、連絡先メールアドレス、ウェブフォームなどがあります。一般ユーザーと連携する組織の場合、一般向けのセキュリティに関する問い合わせ手段が必要になる場合もあります。
調査中に使用できるクラウド機能の詳細については、本書の「[付録 A: クラウド機能の定義](appendix-a-cloud-capability-definitions.md)」を参照してください。
# セキュリティコントロールエンジニアリングの一環としての検出
検出メカニズムは、セキュリティコントロールの開発に欠かせないものです。*ディレクティブ*コントロールと*予防的*コントロールを定義したら、関連する*検出*コントロールと*対応*コントロールを構築する必要があります。例えば、ある組織が AWS アカウントのルートユーザーに関連するディレクティブコントロールを確立したとします。このコントロールは、具体的な、明確に定義されたアクティビティにのみ使用する必要があります。これを、AWS 組織のサービスコントロールポリシー (SCP) を使用して実装された予防的コントロールに関連付けます。ルートユーザーのアクティビティが予想ベースラインを超えた場合、EventBridge ルールと SNS トピックを使用して実装された検出コントロールが、セキュリティオペレーションセンター (SOC) に警告します。対応コントロールが、SOC に適切なプレイブックを選択させ、分析を実行させ、インシデントの解決まで作業に当たらせます。
セキュリティコントロールは、AWS で実行されているワークロードの脅威モデリングによって定義するのが最も適切です。検出コントロールの重要度は、特定のワークロードに対するビジネスインパクト分析 (BIA) を確認して設定されます。検出コントロールによって生成されたアラートは、そのままの状態で処理されるものではなく、初期の重要度に基づいて分析中に調整されます。アラートの初期の重要度は優先順位付けに役立ちますが、実際の重要度はアラートが発生した文脈によって決まります。例えば、ある組織が、ワークロードの一部である EC2 インスタンスに使用される検出コントロールのコンポーネントとして Amazon GuardDuty を使用しているとします。検出結果 `Impact:EC2/SuspiciousDomainRequest.Reputation` が生成され、ワークロード内のリストされた Amazon EC2 インスタンスが悪意が疑われるドメイン名をクエリしていることが通知されました。このアラートはデフォルトでは重要度が低く設定されていましたが、分析フェーズが進むにつれて、不正なアクターによって数百もの `p4d.24xlarge` タイプの EC2 インスタンスがデプロイされ、組織の運用コストが大幅に増加していることが判明しました。この時点で、インシデント対応チームは、このアラートの重要度を*高*に調整し、緊急性を高め、さらなるアクションを迅速に行うことを決定します。GuardDuty の検出結果の重要度は変更できないことに注意してください。
# 検出コントロールの実装
検出コントロールは、特定のイベントに対してアラートをどのように利用するかを決定するのに役立つため、検出コントロールの実装方法を理解することが重要です。技術上、検出コントロールには主に 2 つの実装方法があります。
+ **動作検出**は、一般的に機械学習 (ML) または人工知能 (AI) と呼ばれる数学モデルに依存します。検出は推論によって行われるため、アラートは必ずしも実際のイベントを反映しているとは限りません。
+ **ルールベースの検出**は決定論的で、お客様はアラートの対象となるアクティビティの正確で確実なパラメータを設定できます。
侵入検知システム (IDS) などの検出システムの最新の実装には、通常、両方のメカニズムが使用されます。以下に、GuardDuty を使用したルールベースの検出と動作検出の例を示します。
+ 検出結果 `Exfiltration:IAMUser/AnomalousBehavior` が生成されると、「アカウント内で異常な API リクエストが観察されました」という通知が表示されます。さらに詳しく見ると、「ML モデルはアカウント内のすべての API リクエストを評価し、攻撃者が使用する手法に関連付けられる異常なイベントを識別しました」と表示されます。これは、この検出結果が動作的な性質であることを示しています。
+ 検出結果 `Impact:S3/MaliciousIPCaller` について、GuardDuty は CloudTrail の Amazon S3 サービスからの API コールを分析し、`SourceIPAddress`のログ要素を、脅威インテリジェンスフィードを含むパブリック IP アドレスのテーブルと比較しています。エントリに直接一致するものが見つかると、検出結果が生成されます。
脅威モデル内のすべてのアクティビティに対してルールベースのアラートを実装することができない場合もあるため、動作アラートとルールベースのアラートの両方を実装することをお勧めします。
# 人員ベースの検出
これまではテクノロジーベースの検出について説明してきました。もう 1 つの重要な検出の情報源は、お客様の組織内外の人々です。*内部の人間*は従業員または請負業者として定義でき、*外部の人間*はセキュリティ研究者、法執行機関、ニュース、ソーシャルメディアなどのエンティティです。
テクノロジーベースの検出は体系的に設定できますが、人員ベースの検出には、メール、チケット、郵便、ニュース投稿、電話、対面でのやり取りなど、さまざまな形式があります。テクノロジーベースの検出の通知はほぼリアルタイムで配信されることが予想されますが、人員ベースの検出の場合、時間軸についての期待はされません。セキュリティへの多層防御アプローチでは、セキュリティ文化が人員ベースの検出メカニズムを組み込み、それを促進して強化することが不可欠です。
# 概要
検出では、ルールベースと動作主導のアラートを組み合わせることが重要です。さらに、社内外のスタッフがセキュリティ上の問題に関するチケットを送信できるメカニズムを用意する必要があります。人はセキュリティイベントの最も価値ある情報源の 1 つとなる可能性があるため、懸念をエスカレーションするプロセスを設けることが重要です。検出コントロールの構築を開始するには、環境の脅威モデルを使用する必要があります。脅威モデルは、環境に最も関連性の高い脅威に基づいてアラートを作成することに役立ちます。最後に、MITRE ATT&CK などのフレームワークを使用して、脅威アクターの戦術、技術、手順 (TTP) を理解できます。MITRE ATT&CK フレームワークは、さまざまな検出メカニズム間の共通言語として使用するのに役立ちます。
# 分析
ログ、クエリ機能、脅威インテリジェンスは、分析フェーズで必要とされるサポートコンポーネントの一部です。検出に使用されるログと同じものが分析にも多数使用され、クエリツールのオンボーディングと設定が必要になります。
# アラートの影響の検証、範囲の特定、評価を行う
分析フェーズでは、アラートの検証、範囲の定義、考えられる侵害の影響評価を目的として、包括的なログ分析が実行されます。
+ アラートの*検証*は、分析フェーズのエントリポイントです。インシデント対応者は、さまざまな情報源のログエントリを調べ、影響を受けるワークロードの所有者と直接やり取りします。
+ 次のステップは*範囲の特定*です。関係者が誤検出の可能性が低いと判断した後に、関連するすべてのリソースのインベントリが作成され、アラートの重要度が調整されます。
+ 最後に、*インパクト分析*で、実際のビジネスの中断について詳しく調べます。
影響を受けるワークロードのコンポーネントが特定されると、範囲の特定結果を関連するワークロードの目標復旧時点 (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` でプレーンテキストで利用可能な状況だと判断しました。*
# 封じ込み
インシデント対応に関連する封じ込めの定義の 1 つは、セキュリティイベントの処理中に、セキュリティイベントの範囲を最小限に抑え、環境内での不正使用の影響を封じ込める戦略を処理または実装することです。
封じ込め戦略は多くの要因に依存し、封じ込め戦術の適用、タイミング、目的に関して、組織ごとに異なるものになる可能性があります。「[NIST SP 800-61 コンピュータセキュリティインシデント処理ガイド](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final)」では、適切な封じ込め戦略を決定するためのいくつかの基準について概説しています。これには、以下が含まれます。
+ リソースへの潜在的な損害および盗難
+ 証拠保全の必要性
+ サービスの可用性 (ネットワーク接続、外部の関係者に提供されるサービス)
+ 戦略の実装に必要な時間とリソース
+ 戦略の有効性 (部分的または完全な封じ込め)
+ ソリューションの期間 (4 時間で削除する緊急回避策、2 週間で削除する一時的な回避策、永続的な解決策)
ただし、AWS のサービスについては、基本的な封じ込めステップを次の 3 つのカテゴリに絞り込むことができます。
+ **ソースの封じ込め** — フィルタリングとルーティングを使用して、特定のソースからのアクセスを防止します。
+ **手法とアクセス権の封じ込め** – アクセス権を削除して、影響を受けるリソースへの不正アクセスを防止します。
+ **送信先の封じ込め** — フィルタリングとルーティングを使用して、ターゲットリソースへのアクセスを防止します。
# ソースの封じ込め
ソースの封じ込めとは、特定のソース IP アドレスまたはネットワーク範囲からリソースにアクセスされることを防ぐために、環境内でフィルタリングまたはルーティングを使用および適用することです。AWS サービスを使用したソースの封じ込めの例を以下に示します。
+ **セキュリティグループ** – 分離セキュリティグループを作成して Amazon EC2 インスタンスに適用するか、既存のセキュリティグループからルールを削除すると、Amazon EC2 インスタンスまたは AWS リソースへの不正なトラフィックを封じ込めることができます。セキュリティグループを変更しても、既存の追跡対象の接続はシャットダウンされないことに注意してください。実際は将来のトラフィックのみが新しいセキュリティグループによってブロックされます (追跡対象の接続と追跡対象でない接続の詳細については、[このインシデント対応プレイブック](https://github.com/aws-samples/aws-customer-playbook-framework/blob/main/docs/Ransom_Response_EC2_Linux.md)と「[セキュリティグループの接続の追跡](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)」を参照してください)。
+ **ポリシー** – Amazon S3 バケットポリシーは、IP アドレス、ネットワーク範囲、または VPC エンドポイントからのトラフィックをブロックまたは許可するように設定できます。ポリシーにより、疑わしいアドレスと Amazon S3 バケットへのアクセスをブロックすることができます。バケットポリシーの詳細については、「[Adding a bucket policy using the Amazon S3 console](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html)」を参照してください。
+ **AWS WAF** – ウェブアクセスコントロールリスト (ウェブ ACL) は、リソースが応答するウェブリクエストをきめ細かく制御するために AWS WAF で設定できます。AWS WAF で設定された IP セットに IP アドレスまたはネットワーク範囲を追加し、ブロックなどの一致条件を IP セットに適用できます。これにより、発信元トラフィックの IP アドレスまたはネットワーク範囲が IP セットルールで設定されたものと一致する場合、リソースへのウェブリクエストがブロックされます。
ソースの封じ込めの例を次の図に示します。インシデント対応アナリストが Amazon EC2 インスタンスのセキュリティグループを変更して、新しい接続を特定の IP アドレスのみに制限します。セキュリティグループの箇条書きで説明したように、セキュリティグループを変更しても、既存の追跡対象の接続はシャットダウンされません。
![\[ソース封じ込めの例を示す図\]](http://docs.aws.amazon.com/ja_jp/security-ir/latest/userguide/images/source-containment-example.png)
**注記**
セキュリティグループとネットワーク ACL では、Amazon Route 53 へのトラフィックはフィルタリングされません。EC2 インスタンスを封じ込める場合、外部ホストとの通信を防ぐには、DNS 通信も明示的にブロックしてください。
# 手法とアクセス権の封じ込め
リソースへのアクセス権を持つ役割と IAM プリンシパルを制限することで、リソースの不正使用を防止します。これには、リソースにアクセスできる IAM プリンシパルのアクセス許可の制限や、一時的なセキュリティ認証情報の取り消しも含まれます。AWS サービスを使用した手法とアクセス権の封じ込めの例を以下に示します。
+ **アクセス許可の制限** – IAM プリンシパルに割り当てられたアクセス許可は、[最小特権の原則](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)に従う必要があります。ただし、セキュリティイベントの発生中に、特定の IAM プリンシパルからターゲットリソースへのアクセスをさらに制限することが必要になる場合があります。この場合、封じ込め対象の IAM プリンシパルからアクセス許可を削除することで、リソースへのアクセスを制限できます。これは IAM サービスで行われ、AWS マネジメントコンソール、AWS CLI または AWS SDK を使用して適用できます。
+ **キーの取り消し** – IAM アクセスキーは、IAM プリンシパルがリソースにアクセスまたは管理するために使用されます。これらは、AWS CLI または AWS API へのプログラムによるリクエストに署名し、プレフィックス *AKIA* で始まる長期的な静的認証情報です (詳細については、「[IAM 識別子](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html)」の「*一意の ID プレフィックスを理解する*」セクションを参照してください)。IAM アクセスキーが侵害された IAM プリンシパルのアクセス権を封じ込めるには、アクセスキーを非アクティブ化または削除できます。次の点に留意することが重要です。
+ アクセスキーを非アクティブ化した後、再アクティブ化できます。
+ アクセスキーは一度削除すると復元できません。
+ IAM プリンシパルは、いつでも最大 2 つのアクセスキーを持つことができます。
+ アクセスキーを使用するユーザーまたはアプリケーションは、キーが非アクティブ化または削除されるとアクセス権を失います。
+ **一時的なセキュリティ認証情報の取り消し** – 一時的なセキュリティ認証情報は、AWS リソースへのアクセスを制御するために組織で使用でき、プレフィックス *ASIA* で始まります (詳細については、「[IAM 識別子](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html)」の「*一意の ID プレフィックスを理解する*」セクションを参照してください)。一時的な認証情報は通常、IAM ロールによって使用され、有効期間があるため、ローテーションを行ったり明示的に取り消したりする必要はありません。一時的なセキュリティ認証情報の有効期限が切れる前に、一時的なセキュリティ認証情報が関与するセキュリティイベントが発生した場合は、既存の一時的なセキュリティ認証情報の有効なアクセス許可を変更する必要がある場合があります。これは、[AWS マネジメントコンソール内の IAM サービスを使用して](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html)完了できます。一時的なセキュリティ認証情報は、(IAM ロールではなく) IAM ユーザーにも発行できますが、本書の執筆時点では、AWS マネジメントコンソール内の IAM ユーザーの一時的なセキュリティ認証情報を取り消すオプションはありません。権限のないユーザーが一時的なセキュリティ認証情報を作成し、ユーザーの IAM アクセスキーが侵害されたセキュリティイベントでは、次の 2 つの方法を使用して一時的なセキュリティ認証情報を取り消すことができます。
+ セキュリティトークンの発行時間に基づいてアクセス権を禁止するインラインポリシーを IAM ユーザーにアタッチします (詳細については、「[一時的なセキュリティ認証情報のアクセス権限を無効にする](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_disable-perms.html)」の「*特定の時間より前に発行した一時的なセキュリティ認証情報のアクセスを拒否する*」セクションを参照してください)。
+ 侵害されたアクセスキーを所有する IAM ユーザーを削除します。必要に応じてユーザーを再作成します。
+ **AWS WAF** - 権限のないユーザーが使用する特定の手法には、SQL インジェクションやクロスサイトスクリプティング (XSS) を含むリクエストなど、一般的な悪意のあるトラフィックパターンが含まれます。 AWS WAF は、AWS WAF 組み込みルールステートメントを使用して、これらの手法を使用するトラフィックを照合して拒否するように設定できます。
手法とアクセス権の封じ込めの例を次の図に示します。インシデント対応者がアクセスキーをローテーションするか、IAM ポリシーを削除して、IAM ユーザーが Amazon S3 バケットにアクセスできないようにします。
![\[手法とアクセス権の封じ込めの例を示す図\]](http://docs.aws.amazon.com/ja_jp/security-ir/latest/userguide/images/technique-and-access-containment.png)
# 送信先の封じ込め
送信先の封じ込めは、ターゲットのホストまたはリソースへのアクセスを防ぐために、環境内でフィルタリングまたはルーティングを行うことです。場合によっては、送信先の封じ込めは、正当なリソースが可用性を保つためレプリケートされていることを確認するために回復力の形式を取る場合もありまれます。そのため、分離と封じ込めのためにリソースをこうした形式の回復力からデタッチする必要があります。AWS サービスを使用した送信先の封じ込めの例は次のとおりです。
+ **ネットワーク ACL** – AWS リソースが含まれるサブネットで設定されたネットワーク ACL には、拒否ルールを追加できます。これらの拒否ルールは、特定の AWS リソースへのアクセスを防ぐために適用できます。ただし、ネットワークアクセスコントロールリスト (ネットワーク ACL) を適用すると、承認なしでアクセスされるリソースだけでなく、サブネット上のすべてのリソースに影響します。ネットワーク ACL 内にリストされているルールはトップダウン順序で処理されるため、既存のネットワーク ACL の最初のルールは、ターゲットリソースとサブネットへの不正なトラフィックを拒否するように設定する必要があります。または、インバウンドトラフィックとアウトバウンドトラフィックの両方に対して単一の拒否ルールを使用するまったく新しいネットワーク ACL を作成し、ターゲットリソースを含むサブネットに関連付けることで、新しいネットワーク ACL を使用したサブネットへのアクセスを防ぐこともできます。
+ **シャットダウン** — リソースを完全にシャットダウンすると、不正使用の影響を封じ込める効果があります。リソースをシャットダウンすると、ビジネスで必要な正当なアクセスが妨げられ、揮発性のフォレンジックデータの取得も妨げられます。そのため、これは目的を持って決定する必要があり、組織のセキュリティポリシーに照らして判断する必要があります。
+ **分離 VPC** – 分離 VPC を使用すると、正当なトラフィック (インターネットや外部マネジメントコンソールへのアクセスを必要とするウイルス対策 (AV) や EDR ソリューションなど) へのアクセス権を提供しながら、リソースを効果的に封じ込めることができます。分離 VPC は、セキュリティイベントに先立って、有効な IP アドレスとポートを許可するように事前設定できます。セキュリティイベントが発生するとターゲットリソースはすぐにこの分離 VPC に移動してリソースを封じ込めると同時に、インシデント対応の後続フェーズでターゲットリソースが正当なトラフィックを送受信できるようにします。分離 VPC を使用する上で重要な点は、EC2 インスタンスなどのリソースを使用する前に新しい分離 VPC でシャットダウンおよび再起動する必要があることです。既存の EC2 インスタンスを別の VPC または別のアベイラビリティーゾーンに移動することはできません。これを行うには、「[How do I move my Amazon EC2 instance to another subnet, Availability Zone, or VPC?](https://aws.amazon.com/premiumsupport/knowledge-center/move-ec2-instance/)」で説明されているステップに従います。
+ 送信先の封じ込め手順の一部として、**Auto Scaling グループとロードバランサー** – Auto Scaling グループとロードバランサーにアタッチされた AWS リソースをデタッチおよび登録解除する必要があります。AWS リソースのデタッチと登録解除は、AWS マネジメントコンソール、AWS CLI、および AWS SDK を使用して実行できます。
送信先の封じ込めの例を次の図で示します。インシデント対応アナリストは、不正なホストからのネットワーク接続リクエストをブロックするために、ネットワーク ACL をサブネットに追加します。
![\[送信先の封じ込めの例を示す図\]](http://docs.aws.amazon.com/ja_jp/security-ir/latest/userguide/images/destination-containment.png)
# 概要
封じ込めはインシデント対応プロセスのステップの 1 つであり、手動または自動で行うことができます。封じ込め戦略全体を組織のセキュリティポリシーとビジネスニーズに一致させ、根絶と復旧の前に、悪影響が可能な限り効率的に軽減されていることを確認する必要があります。
# 根絶
根絶とは、セキュリティインシデント対応に関して、アカウントを既知の安全な状態に戻すために、疑わしいリソースや不正なリソースを排除することです。根絶戦略は、組織のビジネス要件に依存する複数の要因によって異なります。
「[NIST SP 800-61 コンピュータセキュリティインシデント処理ガイド](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final)」には、次に示すような根絶のためのいくつかのステップが記載されています。
1. 悪用されたすべての脆弱性を特定して軽減します。
1. マルウェア、不適切なマテリアル、その他のコンポーネントを削除します。
1. 影響を受けるホストがさらに検出された場合 (新しいマルウェアへの感染など)、検出と分析の手順を繰り返して、影響を受ける他のすべてのホストを特定し、インシデントを封じ込めて根絶します。
AWS リソースの場合、CloudWatch Logs や Amazon GuardDuty などの利用可能なログや自動ツールを通じて検出および分析されたイベントを通じて、この手順をさらに洗練させることができます。これらのイベントは、環境を既知の安全な状態に適切に復元するためにどのような修復を実行するかを判断する基礎となります。
根絶の最初のステップは、AWS アカウント内で影響を受けたリソースを特定することです。これは、使用可能なログデータソース、リソース、自動ツールの分析によって実現されます。
+ アカウントの IAM ID によって実行された不正なアクションを特定します。
+ アカウントへの不正なアクセスまたは変更を特定します。
+ 不正なリソースまたは IAM ユーザーの作成を特定します。
+ 不正な変更が行われたシステムまたはリソースを特定します。
リソースのリストを特定したら、それぞれを評価して、リソースが削除または復元された場合のビジネスへの影響を判断する必要があります。例えば、ウェブサーバーがビジネスアプリケーションをホストしていて、それを削除するとダウンタイムが発生する場合は、影響を受けるサーバーを削除する前に、検証済みの安全なバックアップからリソースを復旧するか、クリーンな AMI からシステムを再起動することを検討する必要があります。
ビジネスへの影響分析を終了したら、ログ分析のイベントを使用して、アカウントに移動し、次のような適切な修復を実行する必要があります。
+ キーのローテーションまたは削除 - このステップでは、アクターがアカウント内でアクティビティを実行し続けることができないようにします。
+ 不正な疑いのある IAM ユーザ認証情報をローテーションします。
+ 認識されないリソースまたは許可されていないリソースを削除します。
**重要**
調査のためにリソースを保持する必要がある場合は、それらのリソースのバックアップを取ることを検討してください。例えば、規制、コンプライアンス、または法的理由で Amazon EC2 インスタンスを保持する必要がある場合は、インスタンスを削除する前に [Amazon EBS スナップショットを作成](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html)します。
+ マルウェアの感染については、AWS Partnerまたは他のベンダーに連絡する必要がある場合があります。AWS は、マルウェアの分析や削除のためのネイティブツールを提供していません。ただし、Amazon EBS に GuardDuty Malware モジュールを使用している場合は、提供された検出結果に対する推奨事項が利用できる場合があります。
特定した影響を受けるリソースを根絶したら、AWS でアカウントのセキュリティレビューを実行することをお勧めします。これは、AWS Config ルールを使用する、Prowler や ScoutSuite などのオープンソースソリューションを使用する、または他のベンダーを通じて行うことができます。また、残余リスクを評価するために、パブリック (インターネット) 向けリソースに対して脆弱性スキャンを実行することも検討する必要があります。
根絶はインシデント対応プロセスのステップの 1 つであり、インシデントと影響を受けるリソースに応じて手動または自動で行うことができます。戦略全体を組織のセキュリティポリシーとビジネスニーズに一致させ、不適切なリソースや設定を削除した場合に悪影響が軽減されることを確認する必要があります。
# 復旧
復旧とは、システムを既知の安全な状態に復元し、復元前にバックアップが安全であるかまたはインシデントの影響を受けていないことを検証し、復元後にシステムが適切に動作していることを検証し、セキュリティイベントに関連する脆弱性に対処するプロセスです。
復旧の順序は、組織の要件によって異なります。復旧プロセスの一環として、ビジネスへの影響分析を実行して、少なくとも以下を決定する必要があります。
+ ビジネスまたは依存関係の優先順位
+ 復元プラン
+ 認証と認可
「NIST SP 800-61 コンピュータセキュリティインシデント処理ガイド」には、次に示すような、システムを復旧するためのいくつかのステップが記載されています。
+ クリーンバックアップからシステムを復元します。
+ バックアップがシステムへの復元前に評価されていることを確認し、感染がないことを確認し、セキュリティイベントの再発を防止します。
バックアップは、ディザスタリカバリテストの一環として定期的に評価して、バックアップメカニズムが適切に動作していること、データの整合性が復旧ポイントの目的を満たしていることを確認する必要があります。
+ 可能であれば、根本原因分析の一環として特定された最初のイベントのタイムスタンプより前のバックアップを使用します。
+ 自動化を使用した信頼できるソースからの再デプロイなど、システムをゼロから再構築します (場合によっては新しい AWS アカウントで)。
+ 侵害されたファイルをクリーンバージョンに置き換えます。
これを行う際には、細心の注意が必要です。復旧するファイルの安全性が既知であり、インシデントの影響を受けていないことを確認する必要があります。
+ パッチをインストールします。
+ パスワードを変更します。
+ 悪用された可能性のある IAM プリンシパルのパスワードが含まれます。
+ 可能であれば、最小特権戦略の一環として、IAM プリンシパルとフェデレーションのロールを使用することをお勧めします。
+ ネットワーク境界のセキュリティを強化します (ファイアウォールルールセット、境界ルーターのアクセスコントロールリスト)。
リソースを復旧したら、学んだ教訓を取り入れてインシデント対応ポリシー、手順、ガイドを更新することが重要です。
要約すると、既知の安全な運用への復帰を容易にする復旧プロセスを実装することが欠かせません。復旧には時間がかかる場合があり、封じ込め戦略と密接に連携してビジネスへの影響と再感染のリスクのバランスを取ることが必要です。復旧手順には、リソースとサービス、IAM プリンシパルを復元し、アカウントのセキュリティレビューを実行して残余リスクを評価する手順を含める必要があります。
# 結論
各運用フェーズには、固有の目標、手法、方法論、戦略があります。表 4 は、これらのフェーズと、このセクションで説明する手法と方法論の一部をまとめたものです。
* 表 4 – 運用フェーズ: 目標、手法、方法論*
| [Phase] (フェーズ) | 目標 | 手法と方法論 |
| --- | --- | --- |
| 検出 | 潜在的なセキュリティイベントを特定します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/security-ir/latest/userguide/operations-conclusion.html) |
| 分析 | セキュリティイベントがインシデントかどうかを判断し、インシデントの範囲を評価します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/security-ir/latest/userguide/operations-conclusion.html) |
| 封じ込め | セキュリティイベントの影響を最小限に抑え、制限します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/security-ir/latest/userguide/operations-conclusion.html) |
| 根絶 | セキュリティイベントに関連する不正なリソースやアーティファクトを削除します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/security-ir/latest/userguide/operations-conclusion.html) |
| 復旧 | システムを既知の安全な状態に復元し、これらのシステムを監視して脅威が再発しないことを確認します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/security-ir/latest/userguide/operations-conclusion.html) |