サイバーフォレンジック - AWS 規範ガイダンス
セキュリティインシデント対応におけるフォレンジックフォレンジックアカウントAmazon GuardDutyAWS Security HubAmazon EventBridgeAWS Step FunctionsAWS LambdaAWS KMS

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

サイバーフォレンジック

簡単な調査を行い、 AWS セキュリティリファレンスアーキテクチャ (AWS SRA) の未来に影響を与えます。 https://amazonmr.au1.qualtrics.com/jfe/form/SV_e3XI1t37KMHU2ua

AWS SRA の文脈では、米国国立標準技術研究所 (NIST) が提供するフォレンジックの定義として、「情報の完全性を保ち、データの厳格な管理過程を維持しながら、データの識別、収集、検査、分析に科学を応用すること」(出典: NIST 特別刊行物 800-86 — インシデント対応にフォレンジック手法を統合するためのガイド) というものです。

セキュリティインシデント対応におけるフォレンジック

このセクションのインシデントレスポンス (IR) ガイダンスは、フォレンジックと、さまざまなサービスやソリューションが IR プロセスをどのように改善できるかを念頭に置いてのみ提供されています。

AWS セキュリティインシデント対応ガイドには、AWS カスタマーインシデントレスポンスチーム (AWS CIRT) の経験に基づいて、AWS クラウドのセキュリティインシデントに対応するためのベストプラクティスが記載されています。AWS CIRT からのその他のガイダンスについては、「AWS CIRT のワークショップ」と 「AWS CIRT のレッスン」を参照してください。

米国国立標準技術研究所サイバーセキュリティフレームワーク (NIST CSF) では、IR ライフサイクルにおける準備、検出と分析、封じ込め、根絶、回復、インシデント後の活動という 4 つのステップを定義しています。これらのステップは順次実施できます。ただし、サイクルの次のステップに進んだ後に一部のステップを繰り返す必要があるため、そのシーケンスは周期的であることが多いです。例えば、封じ込めて根絶した後は、再び分析して、敵を環境から排除できたことを確認する必要があります。

この分析、封じ込め、根絶、分析への繰り返しのサイクルにより、新しい侵害の指標 (IoCs) が検出されるたびに、より多くの情報を収集できます。 IoCs これらは、さまざまな観点から役立ちます。攻撃者が環境を危険にさらすために取った措置のストーリーを伝えてくれます。また、適切なインシデント発生後のレビューを実施することで、防御と検出を強化して、将来的にインシデントを防止したり、敵の行動をより早く検出したりして、インシデントの影響を軽減することができます。

この IR プロセスはフォレンジックの主な目的ではありませんが、ツール、手法、ベストプラクティスの多くは IR と共有されています (特に分析ステップ)。例えば、インシデントが検出されると、フォレンジック収集プロセスでは証拠を収集します。次に、証拠の調査と分析が の抽出に役立ちます IoCs。最終的には、フォレンジックレポートが IR 後の活動に役立ちます。

対応を迅速化し、IR 関係者の負担を軽減するために、フォレンジックプロセスを可能な限り自動化することをお勧めします。さらに、フォレンジック収集プロセスが終了し、汚染を防ぐために証拠が安全に保管されたら、さらに自動分析を追加することもできます。詳細については、AWS 規範ガイダンスのウェブサイトの「インシデント対応とフォレンジックの自動化」パターンを参照してください。

設計上の考慮事項

セキュリティ IR への備えを強化するには:

  • 調査やインシデント対応で必要となる可能性があるログを有効にし、安全に保存します。

  • 既知のシナリオに合わせてクエリを事前に作成し、ログを自動的に検索する方法を提供します。Amazon Detective の使用を検討してください。

  • シミュレーションを実行して IR ツールを準備してください。

  • バックアップとリカバリのプロセスを定期的にテストして、成功することを確認してください。

  • Amazon の検出 GuardDuty 結果に基づく AWS に関連する一般的な潜在的なイベントから始めて、シナリオベースのプレイブックを使用します。独自のプレイブックを作成する方法については、「AWS セキュリティインシデント対応ガイド」の「Playbook resources」セクションを参照してください。

フォレンジックアカウント

免責事項

以下の AWS フォレンジックアカウントの説明は、組織が法律顧問からの指導と併せて独自のフォレンジック能力を開発するための出発点としてのみ使用してください。

このガイダンスが犯罪の発見や捜査に適していることや、本ガイダンスの適用によって収集されたデータやフォレンジック証拠が法廷で使用できるかどうかについて、当社はいかなる主張もしません。ここで説明するベストプラクティスが自分のユースケースに適しているかどうかは、お客様自身で評価してください。

以下の図表は、フォレンジック専用アカウントで設定されている セキュリティサービスを示しています。わかりやすく説明すると、この図表にある Security Tooling アカウントでは、フォレンジックアカウントで検出または通知を行うために使用される AWS サービスを示しています。

AWS のフォレンジックアカウント

フォレンジックアカウントは、セキュリティ OU 内の独立した専用の Security Tooling アカウントです。フォレンジックアカウントの目的は、組織のフォレンジックチームがフォレンジックプロセスのすべてのフェーズ (収集、検査、分析、報告) を実施できるように、標準的で事前設定された繰り返し可能なクリーンルームを提供することです。さらに、対象とするリソースの隔離と隔離のプロセスもこのアカウントに含まれています。

フォレンジックプロセス全体を別のアカウントにまとめることで、収集、保存されたフォレンジックデータに追加のアクセス制御を適用できます。以下の理由により、フォレンジックアカウントと Security Tooling アカウントを分けることをお勧めします。

  • フォレンジック担当者とセキュリティ担当者は別のチームに所属していたり、権限が異なる場合があります。

  • Security Tooling アカウントには、S3 バケットの Amazon S3 パブリックアクセスブロックを有効にするなど、AWS コントロールプレーンでのセキュリティイベントへの対応に重点を置いた自動化機能がある場合があります。一方、フォレンジックアカウントには、オペレーティングシステム (OS) や EC2 インスタンス内のアプリケーション固有のデータなど、顧客が責任を負う可能性のある AWS データプレーンのアーティファクトも含まれています。

  • 組織や規制の要件によっては、追加のアクセス制限やリーガルホールドを実装する必要がある場合があります。

  • フォレンジック分析プロセスでは、AWS の利用規約に従い、安全な環境でマルウェアなどの悪意のあるコードを分析する必要がある場合があります。

フォレンジックアカウントには、フォレンジック収集プロセスにおける人的介入を最小限に抑えながら、大規模な証拠収集を促進するための自動化機能を含める必要があります。追跡と報告のメカニズムを簡素化するために、リソースの対応と隔離の自動化もこのアカウントに含まれます。

このセクションで説明するフォレンジック機能は、組織がその機能を積極的に使用していない場合でも、利用可能なすべての AWS リージョンにデプロイする必要があります。特定の AWS リージョンを使用する予定がない場合は、サービスコントロールポリシー (SCP) を適用して AWS リソースのプロビジョニングを制限する必要があります。さらに、フォレンジックアーティファクトの調査と保管を同じリージョン内で行うことで、データレジデンシーや所有権に関する規制環境の変化に伴う問題を回避できます。

このガイダンスでは、前述のように Log Archive アカウントを使用して、フォレンジックアカウントで実行する API を含め、AWS API を介して環境で実行されたアクションを記録します。このようなログがあると、アーティファクトの取り扱いミスや改ざんの申し立てを防ぐのに役立ちます。有効にする詳細のレベルに応じて (AWS CloudTrail ドキュメントの「管理イベントのログ記録」と「データイベントのログ記録」を参照）、ログには、アーティファクトの収集に使用されたアカウント、アーティファクトが収集された時刻、およびデータの収集に実行されたステップに関する情報を含めることができます。アーティファクトを Amazon S3 に保存することで、高度なアクセスコントロールを使用したり、オブジェクトにアクセスしたユーザーに関する情報を記録したりすることもできます。アクションの詳細なログがあれば、他のユーザーは必要に応じて後でプロセスを繰り返すことができます (対象のリソースがまだ使用可能であることを前提としています)。

設計上の考慮事項

  • 自動化は、重要なエビデンスの収集を加速化してスケールするのに役立つため、同時に発生するインシデントが多い場合に役立ちます。ただし、これらの利点を慎重に検討する必要があります。例えば、誤検出インシデントが発生した場合、完全に自動化されたフォレンジック対応は、対象範囲内の AWS ワークロードによってサポートされているビジネスプロセスに悪影響を与える可能性があります。詳細については、以下のセクションの AWS GuardDuty、AWS Security Hub、および AWS Step Functions の設計上の考慮事項を参照してください。

  • 組織のフォレンジック担当者とセキュリティ担当者が同じチームに所属していて、チームのどのメンバーでもすべての機能を実行できる場合でも、Security Tooling アカウントとフォレンジックアカウントを分けることをお勧めします。機能を別々のアカウントに分割すると、最小特権がさらに確保され、継続的なセキュリティイベント分析による汚染を防ぎ、収集されたアーティファクトの整合性を強化するのに役立ちます。

  • 職務の分離、最小特権、制限的なガードレールをさらに強調したい場合は、このアカウントをホストするために別のフォレンジック OU を作成することができます。

  • 組織が不変のインフラストラクチャリソースを使用している場合、セキュリティインシデントが検出される前にリソースが自動的に削除されると (例えば、スケールダウンイベント中)、フォレンジック的に価値のある情報が失われる可能性があります。これを回避するには、そのようなリソースごとにフォレンジック収集プロセスを実行することを検討してください。収集されるデータ量を減らすには、環境、ワークロードのビジネス上の重要度、処理されるデータの種類などの要素を考慮する必要があります。

  • Amazon を使用してクリーンワークステーション WorkSpaces をスピンアップすることを検討してください。これにより、調査中の利害関係者の行動を分けることができます。

Amazon GuardDuty

Amazon GuardDuty は、AWS アカウントとワークロードを保護するために、悪意のあるアクティビティや不正な動作を継続的にモニタリングする検出サービスです。AWS SRA の一般的なガイダンスについては、「Security Tooling アカウント」セクションの「Amazon GuardDuty」を参照してください。

GuardDuty 検出結果を使用して、侵害された可能性のある EC2 インスタンスのディスクイメージとメモリイメージをキャプチャするフォレンジックワークフローを開始できます。これにより、人間とのやり取りが減り、フォレンジックデータ収集の速度が大幅に向上します。Amazon GuardDuty と統合して EventBridge 、新しい GuardDuty 検出結果 への応答を自動化できます。

GuardDuty 検出結果タイプのリストが増加しています。どの検出結果タイプ (Amazon EC2、Amazon EKS、マルウェア保護など) がフォレンジックワークフローを開始するのかを検討する必要があります。

封じ込めとフォレンジックデータ収集プロセスと GuardDuty 検出結果の統合を完全に自動化して、ディスクとメモリのアーティファクトの調査をキャプチャし、EC2 インスタンスを隔離できます。例えば、セキュリティグループからすべてのイングレスルールとエグレスルールが削除された場合、ネットワーク ACL を適用して既存の接続を中断し、IAM ポリシーをアタッチしてすべてのリクエストを拒否できます。

設計上の考慮事項

  • AWS のサービスによって、お客様の責任分担は異なる場合があります。例えば、EC2 インスタンス上の変動データのキャプチャはインスタンス自体でのみ可能であり、フォレンジック証拠として使用できる貴重なデータが含まれている場合があります。逆に、Amazon S3 の検出結果への応答と調査には、主に CloudTrail データまたは Amazon S3 アクセスログが含まれます。レスポンスの自動化は、お客様の責任分担、一般的なプロセスフロー、キャプチャされたアーティファクトのうちセキュリティを確保する必要があるものに応じて、Security Tooling アカウントとフォレンジックアカウントの両方で整理する必要があります。

  • EC2 インスタンスを隔離する前に、ビジネス全体への影響と重要性を比較検討してください。自動化を使用して EC2 インスタンスを封じ込める前に、適切な利害関係者と協議するプロセスを確立することを検討してください。

AWS Security Hub

AWS Security Hub では、AWS のセキュリティ状態を包括的に把握し、セキュリティ業界標準およびベストプラクティスに照らして環境をチェックするのに役立ちます。Security Hub は、AWS の統合サービス、サポートされるサードパーティ製品、およびお客様が使用する可能性のあるその他のカスタムセキュリティ製品からセキュリティデータを収集します。セキュリティの傾向を継続的にモニタリング・分析し、特に優先度の高いセキュリティ問題を特定するのに役立ちます。AWS SRA の一般的なガイダンスについては、「Security Tooling アカウント」セクションの「AWS Security Hub」を参照してください。

Security Hub は、セキュリティ体制のモニタリングに加えて、Amazon との統合をサポートし EventBridge 、特定の検出結果の修復を自動化します。例えば、AWS Lambda 関数や AWS Step Functions ワークフローを実行するようにプログラムできるカスタムアクションを定義して、フォレンジックプロセスを実装できます。

Security Hub のカスタムアクションは、権限のあるセキュリティアナリストやリソースが封じ込めとフォレンジックの自動化を実装するための標準化されたメカニズムを提供します。これにより、フォレンジック証拠の封じ込めとキャプチャにおける人的介入が減ります。自動プロセスに手動チェックポイントを追加して、フォレンジックコレクションが実際に必要かどうかを確認できます。

設計上の考慮事項

  • Security Hub は、AWS パートナーソリューションを含む多くのサービスと統合できます。組織が使用している探偵的なセキュリティ制御が十分に調整されておらず、誤検出アラートが発生することがある場合、フォレンジック収集プロセスを完全に自動化すると、そのプロセスが不必要に実行されてしまいます。

Amazon EventBridge

Amazon EventBridge は、アプリケーションをさまざまなソースのデータに簡単に接続できるサーバーレスイベントバスサービスです。セキュリティオートメーションによく使用されます。AWS SRA の一般的なガイダンスについては、「Security Tooling アカウント」セクションの「Amazon EventBridge」を参照してください。

例えば、 を Step Functions でフォレンジックワークフローを開始するメカニズム EventBridge として使用して、 などのセキュリティモニタリングツールからの検出に基づいてディスクイメージとメモリイメージをキャプチャできます GuardDuty。または、より手動で使用することもできます。 EventBridge は でタグ変更イベントを検出し CloudTrail、Step Functions でフォレンジックワークフローを開始する可能性があります。

AWS Step Functions

AWS Step Functions は、AWS Lambda 関数と他のサービスを組み合わせてビジネスクリティカルなアプリケーションを構築できるサーバーレスオーケストレーションサービスです。Step Functions のグラフィカルコンソールでは、アプリケーションのワークフローを一連のイベント駆動型ステップとして確認できます。Step Functions はステートマシンとタスクに基づいています。Step Functions では、ワークフローをステートマシンと呼びます。ステートマシンは、一連のイベント駆動型ステップです。ワークフローの各ステップは状態です。タスク状態は、Lambda などの別の AWS サービスが実行する作業単位を表します。タスクステートは、あらゆる AWS サービスまたは API を呼び出すことができます。Step Functions の組み込みコントロールを使用して、ワークフロー内の各ステップの状態を調べて、アプリケーションが期待どおりに実行されていることを確認します。ユースケースによっては、タスクを実行するため、Step Functions で、Lambda など、 のサービスを呼び出すことができます。また、手動による介入が必要なアプリケーション用に実行時間が長い自動化されたワークフローを作成することもできます。

Step Functions は、AWS ログで検証できる事前定義済みのステップの繰り返しと自動化をサポートしているため、フォレンジックプロセスでの使用に最適です。これにより、人間の関与を排除し、フォレンジックプロセスにおけるミスを防ぐことができます。

設計上の考慮事項

  • GuardDuty または Security Hub が侵害を示している場合は、Step Functions ワークフローを手動または自動的に開始して、セキュリティデータをキャプチャして分析できます。自動化により、人的介入を最小限に、またはまったく行わずに済むため、多くのリソースに影響する重大なセキュリティイベントが発生した場合でも、チームの規模を迅速に拡大できます。

  • 完全に自動化されたワークフローを制限するには、自動化フローに手順を組み込んで手動による介入を加えることができます。例えば、権限を持つセキュリティアナリストまたはチームメンバーに、生成されたセキュリティ検出結果を確認し、フォレンジック証拠の収集を開始するか、影響を受けるリソースを隔離して封じ込めるか、あるいはその両方を決定するよう求めることができます。

  • セキュリティツール ( GuardDuty や Security Hub など) から作成されたアクティブな検出結果なしでフォレンジック調査を開始する場合は、フォレンジック Step Functions ワークフローを呼び出すための追加の統合を実装する必要があります。これは、特定の CloudTrail イベント (タグ変更イベントなど) を検索する EventBridge ルールを作成するか、セキュリティアナリストまたはチームメンバーがコンソールから直接フォレンジック Step Functions ワークフローを開始できるようにすることで実行できます。また、Step Functions を使用して組織のチケットシステムと統合することで、実用的なチケットを作成することもできます。

AWS Lambda

AWS Lambda を使用すると、サーバーをプロビジョニングまたは管理しなくてもコードを実行できます。支払いは、使用したコンピューティング時間に対する料金のみになります。コードが実行されていないときに料金は発生しません。Lambda は可用性の高いコンピューティングインフラストラクチャでコードを実行し、コンピューティングリソースに関するすべての管理を行います。これには、サーバーおよびオペレーティングシステムのメンテナンス、容量のプロビジョニングおよび自動スケーリング、さらにログ記録などが含まれます。Lambda がサポートするいずれかの言語ランタイムでコードを指定し、コードを Lambda 関数に整理します。Lambda サービスは、必要な場合にのみ関数を実行し、自動的にスケーリングします。

フォレンジック調査では、Lambda 関数を使用すると、Lambda コードで定義されている反復可能で自動化された定義済みのステップにより、一定の結果を得ることができます。Lambda 関数を実行すると、適切なプロセスが実装されたことを確認するのに役立つログが作成されます。

設計上の考慮事項

  • Lambda 関数のタイムアウトは 15 分ですが、関連する証拠を収集するための包括的なフォレンジックプロセスにはさらに時間がかかる場合があります。このため、Step Functions ワークフローに統合されている Lambda 関数を使用してフォレンジックプロセスを調整することをお勧めします。このワークフローでは、Lambda 関数を正しい順序で作成でき、各 Lambda 関数は個別の収集ステップを実装します。

  • フォレンジック Lambda 関数を Step Functions ワークフローにまとめることで、フォレンジック収集手順の一部を平行して実行し、収集をスピードアップできます。例えば、複数のボリュームが対象範囲内にある場合は、ディスクイメージの作成に関する情報をより速く収集できます。

AWS KMS

AWS Key Management Service (AWS KMS) を使用すると、暗号化キーの作成と管理を容易にし、AWS のサービスとアプリケーション内での幅広い範囲に渡ってそれらの使用を管理できます。AWS SRA の一般的なガイダンスについては、「Security Tooling アカウント」セクションの「AWS KMS」を参照してください。

フォレンジックプロセスの一環として、ビジネスへの影響を最小限に抑えるため、データの収集と調査は隔離された環境で行う必要があります。このプロセスではデータのセキュリティと整合性が損なわれることはありません。そのため、侵害された可能性のあるアカウントとフォレンジックアカウント間で、スナップショットやディスクボリュームなどの暗号化されたリソースを共有できるようにするプロセスを導入する必要があります。これを実現するには、関連する AWS KMS リソースポリシーが、暗号化されたデータの読み取りと、フォレンジックアカウントの AWS KMS キーによるデータの再暗号化によるデータの保護をサポートしていることを確認する必要があります。

設計上の考慮事項

  • 組織の KMS キーポリシーでは、フォレンジックの権限を持つ IAM プリンシパルがキーを使用してソースアカウントのデータを復号し、フォレンジックアカウントで再暗号化することを許可する必要があります。Infrastructure as Code (IaC) を使用して、組織のすべてのキーを AWS KMS で一元管理することで、承認された IAM プリンシパルのみが適切かつ最小特権でアクセスできるようにします。これらの権限は、フォレンジック調査中に収集される可能性のある AWS 上のリソースの暗号化に使用できるすべての KMS キーに存在する必要があります。セキュリティイベントの後に KMS キーポリシーを更新すると、使用中の KMS キーのリソースポリシーの更新がビジネスに影響を与える可能性があります。さらに、権限の問題により、セキュリティイベントの全体的な平均応答時間 (MTTR) が長くなる可能性があります。