GCP でのライブ ネットワーク フォレンジックの実施方法
Google Cloud Japan Team
※この投稿は米国時間 2021 年 8 月 19 日に、Google Cloud blog に投稿されたものの抄訳です。
フォレンジック（犯罪の科学捜査）とは、科学を刑法や民法に応用することです。これは、犯罪現場での証拠収集と処理のための実証済みのアプローチです。フォレンジック プロセスの重要なステップは、証拠を汚染したり手を加えたりすることなく現場を隔離することです。隔離ステップは、それ以上の汚染や有力な証拠の改ざんを防ぎます。デジタル イベントの調査にも同じ哲学が適用できます。
この投稿では、フォレンジック ツールへのアクセスを維持しつつ感染した VM を隔離するための方法、戦術、およびアーキテクチャ設計について紹介します。目標は、他のアセットを保護しながらデータや証拠を収集できるような方法でアクセスを許可することです。キャプチャしたトラフィックの解析に使用できるネットワーク用のフォレンジック ツールは数多くあります。この投稿では、これらのツールを紹介するのではなく、最も効率的で安全な方法でライブ トラフィックをキャプチャするために GCP を構成する方法を紹介します。トラフィックをキャプチャした後、お客様はお好きなツールを使って分析を行うことができます。これらのツールや必要なエージェントの詳細については、こちらをご覧ください。Google およびその他企業が開発しているオープンソースのツールの詳細については、こちらをご覧ください。
クラウド セキュリティの分野では、VM が侵害の兆候を示した場合、最も一般的な初期対応は、スナップショットを取り、インスタンスをシャットダウンし、イメージ スナップショットを隔離された環境に移すことです。この方法は、「デッド分析」と呼ばれています。しかし、インスタンスをシャットダウンすると、バッファや RAM 内の重要な情報が失われる可能性があるため、調査やデジタル フォレンジックの重要なステップの妨げとなります。
もう 1 つのフォレンジック手法は、VM を稼働させたまま、VM から直接証拠を収集する「ライブ分析」です。ライブ フォレンジックは、RAM のイメージングを可能にし、ほとんどのハードドライブやソフトウェアの暗号化をバイパスし、異常なトラフィックの原因を特定します。アクティブなネットワーク侵入に対処する際に非常に有効です。このプロセスは通常、フォレンジック アナリストが行います。例えば、マルウェアがメモリ上にしか存在しない可能性が高い場合、ライブ フォレンジックがマルウェアをキャプチャして分析する唯一の方法であることもあります。この方法では、ディスクやメモリの証拠に加えて、フォレンジック分析により、侵害された VM ネットワーク インターフェースを介して送信されたデータからライブネットワークをキャプチャすることもできます。ライブ ネットワークを収集することの利点は、特にネットワークへの侵入や攻撃が行われているときに、リアルタイムでトラフィックの流れを再現し、視覚化できることです。
クラウドでは、インシデントが発生したことが明らかになった時点で、他の VM を感染から守るために、VM を隔離する必要があります。Google の Cloud Forensics 101 セッションでは、クラウド フォレンジックのためのプロセスや収集する必要のあるログなどの成果物について説明します。
イメージが侵害されると起こること
ここでは、インフラストラクチャの VM の 1 つが侵害され、GCP のCloud Security and Command Center、Chronicle backstory、またはお客様の SIEM などのプロダクトからアラームが出ていると仮定します。
インシデント対応計画は、準備（攻撃前のアクション）、検知（攻撃中のアクション）、対応（攻撃後のアクション）の 3 つの段階で構成されています。検知段階では、Computer Security Incident Response Team（CSIRT）または脅威アナリストが、ライブ取得分析が必要かどうかを判断します。ライブ フォレンジックが必要な場合、例えば、VM の RAM を取得することが不可欠な場合、最初の行動の 1 つは、VM を世界の他の地域から隔離して封じ込め、調査のためにフォレンジック VPC を VM に接続することです。フォレンジック VPC は、フォレンジック GCP プロジェクトに設置されており、SANS Investigative Forensics Toolkit（SIFT）、Sleuth Kit、Autopsy、Encase、FTK など、VM から証拠を収集するデジタル フォレンジック ツールが含まれています。これらのツールは、すでにインストール済み、構成済み、テスト済みで、すぐに使用可能です。また、フォレンジック プロジェクトでは、ディスクやメモリのイメージなどの証拠をフォレンジック レビューのために保存、保護します。
この投稿では 2 つのシナリオを取り上げます。1 つ目のシナリオは、イメージを隔離し、フォレンジック VPC をイメージに接続してライブ取得を行うものです。
2 つ目のシナリオでは、ライブ ネットワーク デジタル フォレンジックのために、隔離されたイメージからライブ トラフィックもキャプチャします。感染した VM からライブ トラフィックをキャプチャするために、GCP の Packet Mirroring サービスを活用して、VM に出入りするすべてのトラフィックを複製し、フォレンジック VPC に送信して分析します。IDS 用 Palo Alto VM-Series、ExtraHop Reveal（x）、CheckPoint CloudGuard、Arkime （旧 Moloch）、Corelight などのネットワーク フォレンジック分析ツールがフォレンジック VPC にインストールされ、構成され、デプロイできる状態になっており、これらのツールを使用して複製されたネットワーク トラフィックを分析することになります。
感染した VM の他のリソースからの隔離とフォレンジック VPC の接続
インシデント対応計画の準備段階の一環として、CSIRT は Google Cloud フォレンジック プロジェクトを作成しました。フォレンジック プロジェクトは必要なときだけ使われるので、Terraform のようなツールを使ってプロジェクトとそのリソースの作成を自動化するのが適切です。このプロジェクトへのアクセスは、CSIRT のようなインシデント対応やフォレンジックに対応する個人やグループにのみ許可することが重要です。図 1 に示すように、右側のフォレンジック プロジェクトには、独自の VPC、オーバーラップしないサブネット、VM イメージが含まれており、フォレンジック ツールがあらかじめインストールされ、構成されています。内部のロードバランサとインスタンス グループも構成されているので、この投稿で後述するように、これらのリソースを使用してライブ トラフィックをキャプチャします。
マルウェアの拡散やデータの引き出しなどのネットワーク活動を阻止するために、VPC のファイアウォール ルールで VM を隔離します。GCP VPC ファイアウォールは、常にルールを実行する分散型ファイアウォールで、インスタンスをその構成やオペレーティング システムに関係なく保護します。言い換えれば、侵害された VM は、そのポリシーが最小権限の原則に従っている場合、ファイアウォールの適用を無効にできません。ルールは、ネットワーク内のすべてのインスタンス、対象となるネットワーク タグ、サービス アカウントに適用できます。
上の図のステップ 1 は、フォレンジック サブネットの CIDR 以外の CIDR からの上り（内向き）トラフィックと下り（外向き）トラフィックを拒否するファイアウォール ルールによって、感染した VM がネットワークの他の部分から隔離されている様子を示しています。感染した VM は、例えば「<image-name>_InfectedVM」のように、固有のネットワーク タグでタグ付けされ、ネットワーク タグに対してファイアウォールのルールが適用されます。これにより、感染した VM がプロジェクトやインターネットから隔離される一方で、ステップ 2 で構成する VPC ピアリングによる VM へのアクセスが可能になります。VPC ファイアウォールのルールについてはこちらをご覧ください。
ステップ 2 では、フォレンジック プロジェクトの VPC が本番環境プロジェクトの VPC とピアリングされます。VPC ピアリングが確立されると、VPC 間でルートが交換されます。デフォルトでは、VPC ピアリングはすべてのサブネット ルートを交換しますが、必要に応じてカスタムルートをフィルタリングすることもできます。この時点で、フォレンジック プロジェクトの VM は、感染した VM と通信し、事前にインストール / 構成済みのフォレンジック ツールを使用して、ライブ フォレンジック分析ジョブを開始できます。
共有 VPC は、ホスト プロジェクト内の共通の VPC に、サービス プロジェクトと呼ばれる複数のプロジェクトのリソースを接続することができるネットワーク構成です。異なるプロジェクトの VPC 同士が、ホストされたプロジェクトのネットワークを介して安全に通信できるとともに、ネットワーク管理を一元化できます。図 2 は共有 VPC のトポロジを示していますが、ステップ 2 では VPC ピアリングを使用するのではなく、フォレンジック プロジェクトがホスト プロジェクトに単純にアタッチされています。アタッチメント後、共有 VPC はフォレンジック ツールが感染した VM と通信できるようにします。
Google Traffic Mirroring によるライブ ネットワーク トラフィックのキャプチャ
アクティブなネットワーク侵入時など、ライブ ネットワーク フォレンジックが必要な場合は、受信トラフィックおよび送信トラフィックを複製してキャプチャする必要があります。VPC フローログはネットワーキング メタデータのテレメトリをキャプチャしますが、これだけではライブ ネットワーク フォレンジック分析には不十分です。GCP Packet Mirroring は、VPC 内の指定されたインスタンスのトラフィックをクローンし、指定された内部ロードバランサに転送します。ロードバランサはミラーリングされたトラフィックを収集し、接続されたインスタンス グループに送信します。Packet Mirroring は、指定されたサブネット、ネットワーク タグ、またはインスタンス名からのすべてのトラフィックをキャプチャします。
図 3 は、ピアリングされた VPC デプロイメントで調査のためにすべてのトラフィックをキャプチャしながら、侵害された VM が世界の他の地域と通信（C&C とのビーコン通信など）できるようにする手順を示しています。
図 4 は共有 VPC デプロイメントで調査のためにすべてのトラフィックをキャプチャしながら、侵害された VM が世界の他の地域と通信できるようにする手順を示しています。
フォレンジックのプロジェクト内部のロードバランサと、パケット キャプチャや分析ツールを含むインスタンス グループの VM を使用します。なお、本番環境用ネットワークとフォレンジック用ネットワークは同じリージョンにある必要があります。Packet Mirroring の詳しい構成方法はこちらのページで紹介しています。
共有 VPC を使用している場合は、共有 VPC 向け Packet Mirroring 構成を参照し、構成の詳細をご確認ください。図 4 は、共有 VPC トポロジにおける Packet Mirroring の流れを示したものです。
インシデントが発生した場合に、セットアップとフォレンジック ツールチェーン全体を迅速にデプロイできるように、プロセスを自動化し、定期的にテストすることをおすすめします。初期調査の結果、コマンド＆コントロール [C&C] サーバーなどの疑わしい送信先が特定された場合、C&C サーバーの IP アドレスからのトラフィックのみをミラーリングするポリシー フィルタを設定して Packet Mirroring ポリシーを調整できます。
クラウド サービスを利用する企業は、インシデント管理計画を策定する必要があります。また、この計画には、必要に応じてライブ取得を利用するという選択肢も含めます。フォレンジック取得のための設計と準備を行うことで、企業は適切な VM に自動的にデプロイして接続できるインフラストラクチャを構築できます。この記事で紹介されているアーキテクチャは、インシデント対応チームがインシデントを解決する間、フォレンジック処理のために重要な証拠を収集し、保存するプロセスに役立ちます。
-セキュリティ＆コンプライアンス カスタマー エンジニアリング Assaf Namer
