クラウドインシデント対応

クラウドインシデント対応とは

クラウドインシデント対応は、クラウド環境でサイバーセキュリティインシデントが発生した場合に従うプロセスです。インシデント対応のクラウドの側面は、基本的に一般的なインシデント対応フェーズ（準備、検知と分析、封じ込め、根絶、復旧、インシデント後/事後分析）に従いますが、（AWS、Azure、GCP、Oracle Cloudなどで動作する）クラウドプラットフォームの間で重要な違いがあります。専門の対応チームとツールは、明確で決定的な回答や回復に必要な意思決定のサポートを得るうえで、違いを生み出します。

クラウドインシデント対応と従来のエンドポイントインシデント対応との違い

1. サーバーへの物理的なアクセスがない

データセンターとネットワークの運用とパッチ適用の管理（PaaSの場合）やソフトウェアの作成と保守（SaaSの場合）をクラウドサービスプロバイダーに任せるのと引き換えに、インシデント対応担当者が頻繁に必要とするものを犠牲にすることになります。例えば、コンソールに接続するためのサーバーへの物理的なアクセス、ハードドライブのフォレンジックイメージのキャプチャ、特別な診断ユーティリティのインストールなどです。

ほとんどの場合、クラウド環境では、アウトオブバンドメモリーダンプの取得、物理コンソールへのログオン、クラウドプロバイダーからのハードドライブ実物の受け取りなどはできません。それで問題ありません。お客様は、論理ストレージのスナップショットの作成、クラウドプロバイダーから提供されるログの収集と分析など、クラウドプロバイダーのアクセスパラメーター内で作業する必要があります。

2. クラウドライフサイクルの加速

現代のクラウド環境では、コンテナ、サービスとしての機能、ハイパーバイザー、および仮想マシンが混在し、マイクロサービスを実行するワークロードが組織の変動する需要に応じて起動/停止します。このような技術の動的な組み合わせにより、クラウドインシデント対応は、従来のエンドポイントでのイメージキャプチャやログ収集といったインシデント対応とは大きく異なる環境になります。

適切な計画と社内コミュニケーションがなければ、フォレンジックアーティファクトが失われる可能性が高くなります。クラウドワークロードが「不良」と判断されると、クラウドワークロードを健全に保つための自動化されたプロセスによって、または脆弱性やエクスプロイトに対処するためにプラットフォームの新しいバージョンを迅速にリリースする運用チームによって、通常はコスト削減のために破棄されます。どこに目を向けるべきかを知らず、ログ収集や関連スナップショットの保持を計画していなかった場合は、潜在的な侵害の封じ込めや、そこからの回復のために組織が必要とする情報が不足していることに気付くでしょう。

3. 当たり前のように行われる「不正」な操作

新しいクラウド環境は、クレジットカードを使用できるどのビジネスユニットでも確立でき、多くの場合、中央の情報セキュリティ組織に知られていません。セキュリティ組織は、通常、クラウド内のいくつかの中核的な重要な操作については把握しています。攻撃者がよく標的にするのは、組織の意識から外れたクラウド環境コンポーネントです。例えば、最近または過去に買収された子会社、廃止が予定されているシステムやアプリケーション、セキュリティ計画の後半のフェーズでセキュリティコントロールのアップグレードを受ける予定だったが時期を逸したコンポーネントなどです。これらの意識されていない操作は、組織のミッションの中核とは見なされないかもしれませんが、侵害につながる可能性があります。その侵害によって生じる莫大なコストは、侵害が発生する前に割り当てられていた時間や予算を大幅に上回る可能性があります。

4. アイデンティティは新しい境界

ファイアウォールを使用するネットワークで境界が定義される従来のデータセンターとは異なり、クラウド環境ではアイデンティティが真の境界となっています。そのため、クラウドデータ侵害に直面したときの封じ込めと修復の戦略は大幅に変わります。許可されたすべてのユーザーが特定のネットワークからアクセスしていると想定することは、もはや不可能であり、不正なIPアドレスをブロックすることも、もはや現実的ではありません。

ユーザーアカウントが多要素認証の要件を欠いている場合や、ワークステーション、ソース管理システム、CICDホストなどから盗まれることが多いAPIキーを攻撃者が発見した場合、攻撃者はインターネット上のどこからでも損害を与えることができます。また、攻撃者はActive Directory (AD) とAzure Active Directory (AAD) の間で同期されたアカウントも標的にします。このため、オンプレミスの侵害は容易にクラウドの侵害にもつながる可能性があります。

5. 深刻化する熟練スタッフの不足

クラウドに関して豊富な経験を持つ技術スタッフが不足しているのと同様に、クラウドセキュリティエンジニアリングの経験を持つ人材の確保と維持はさらに難しく、クラウドセキュリティインシデント対応の経験を持つ人材はそれ以上に不足しています。使用しているクラウドプラットフォームの数だけ、この課題は増えていきます。

クラウドのログソースの概要

エンドポイントでの従来のインシデント対応とクラウドインシデント対応の最大の違いの1つは、ログソースです。ログは侵害調査において常に重要です。しかし、クラウド環境でログがない場合、何が正常で許可されているのかという「グランドトゥルース」を把握することは困難です。

イベントログは、フォレンジック調査の際に、脅威アクターが実行した悪意のあるアクションをつなぎ合わせて全貌を捉えるのに役立ちます。これは、その脅威アクターの封じ込めと排除に役立ちます。ただし、クラウドのログソースはエンドポイントのログソースと一致しないため、異なる収集ツールと手法が必要となります。多くの場合、クラウドのログはデフォルトで無効になっているか、意図的に無効にされており、適切なツールがないと取得が困難になることがあります。

これらのクラウドサービスや、クラウドサービスを利用して構築されたツールを理解しておかないと、専任のクラウドインシデント対応スペシャリストを持たないインシデント対応企業は、効率的かつ効果的な調査に必要なデータの収集に苦労することになります。

SaaSの場合、すべてのユーザーの認証ログ（サインインログ）と対象となる一連の操作に加え、注目すべきすべてのユーザーの一連の操作を常に収集します。インフラストラクチャ (PaaS) の場合、クラウドサービスプレーンログ、関連するデータプレーンログ、VPC/VNetフローログ、および関連する特殊ログ（サービスとしての機能呼び出しログ、ロードバランサーやCDNのログなど）を収集します。

どちらのタイプの調査でも、関連する場合（特に、より直接的な証拠ソースが不足している場合）はパフォーマンスメトリックデータを収集し、貴重なコンテキストについてはクラウドの脅威検知アラートを収集します。設定のスナップショット自体はログソースではありませんが、ログに記録されたイベントを解釈する際に役立ちます。

さらに、これらのログを取得した後でも、ログエントリ（またはその欠如）の解釈は必ずしも簡単ではありません。経験豊富なクラウド調査担当者は、さまざまなクラウド環境（AWS、Azure、GCP）に存在するログ証跡と、それらからデータを迅速かつ効率的に収集して解釈する方法を知っています。ログ分析は、クラウド侵害調査の重要な部分です。

組織は、ビジネスプロセスモダナイズのために新しいデジタルな操作性を提供する速度と、クラウドプラットフォームにおけるイベントログのセキュリティニーズとコストの間でバランスを取ろうとします。この際に、クラウド環境でのログ記録を最小限に抑えるか、完全に無効にするという誘惑に駆られます。これは、クラウドのデータ侵害に直面した場合に問題となります。

アクティブなクラウド脅威の封じ込め

エンドポイントデバイス上の侵害とは異なり、クラウドデータ侵害の場合は、侵害されたマシンのプラグを抜いてネットワークから切断するだけでは済みません。また、クラウドデータ侵害はクラウド環境全体に迅速に転移する可能性があることを念頭に置き、クラウド環境ではエンドポイント侵害よりも封じ込めがかなり困難であることを理解してください。

クラウドインフラストラクチャにおけるインシデントを封じ込めるには、攻撃者によって侵害または追加されたすべてのセキュリティプリンシパルを特定する必要があります。これには、ユーザー、侵害されたロール（フェデレーションセッションや侵害されたアイデンティティストアを介したものなど）、およびサービスアカウントが含まれます。多くの場合、クラウドプロバイダーは1つのセキュリティプリンシパルに対して複数の認証情報ソースをサポートしています。そのため、攻撃者は、そのアカウントの本来の許可された目的を妨害することなくユーザーまたはサービスアカウントになりすますことができます。これが、検知の妨げになります。

この例としては、単一のユーザーに対するパスワード以外の複数のAPIキー、単一のサービスアカウントに対する複数の認証情報ソース、単一のユーザーに対する複数の多要素認証デバイスなどがあります。これらすべてを注意深く追跡し、攻撃者が永続化を再確立しようとする試みを検知する適切な監視を確保しながら、これらを排除する必要があります。

封じ込めの範囲はそれだけではありません。クラウドプラットフォームの自動化と展開のフレームワーク、およびセキュリティプリンシパルとして機能するあらゆるユーザー定義コード（サービスとしての機能、コンテナ、ホストなど）は、攻撃者が環境内の永続性を再確立するために使用する可能性があります。

ネットワークのバックドアとしては、不正なVPCピアリングポイントやネットワークセキュリティグループルールの単純な変更などがあります。これらによって、リソースが攻撃者の継続的な制御にさらされる可能性があります。過剰なアウトバウンド権限を持つクラウドベースのインフラストラクチャには、信頼されたクラウドプロバイダーに属するすべてのIP範囲へのアクセスを許可するなどのポリシーがあります。攻撃者はこれを悪用して、そのクラウドプロバイダーへの承認されたトラフィックに紛れ込む可能性があります。完全な封じ込めとその後の排除を確実にするには、設定されたアクセスにおいて可能性のある、すべてのピボットポイント、永続化メカニズム、および外れ値を包括的にレビューする必要があります。

CSPM（クラウドセキュリティポスチャ管理）ソリューションは、侵害が発生する前の重要な防御策です。CSPMは侵害のリスクを招く設定ミスの痕跡 (IOM) の特定に役立ち、言うまでもなくそれらのIOMを修復することで実際に侵害を防ぐことができます。しかし、CSPMは、多くの場合、侵害封じ込めの重要な部分でもあります。CSPMは（エンドポイントセキュリティソリューションとの組み合わせで）エンドポイントとクラウドの間のインターフェースにおけるアクティブな侵害の特定に役立つことに加え、攻撃者がクラウド環境への侵害を試みる際に使用する設定ミスを排除します。

言い換えれば、可視性と封じ込めの取り組みを進めている間に、組織は侵害により浮き彫りになった既存の設定ミス、および攻撃者によって導入された新しい設定ミスを修復することができます。クラウドプラットフォームの運用においてCSPMコンソールへのアクセスを同僚と共有して進捗状況を確認できるようにすることで、クラウド環境を保護するための道程を大幅に短縮できます。

クラウドストライクのクラウド向けインシデント対応サービス

クラウドデータ侵害に対するインシデント対応には、オンプレミス攻撃に対する従来のインシデント対応とは異なるスキル、経験、ツールのセットが必要です。AWS、Azure/O365、GCPなどのクラウドサービスプロバイダープラットフォームに対応した適切なツールを備えた専任のクラウドインシデント対応スペシャリストがいなければ、重要な回答を得るまでに時間がかかり、対応と復旧の遅れにつながります。効果的に対応するための必要なスキルがない組織は、アクティブな脅威を封じ込めてネットワークから排除することに苦労し、しばしば重要な証拠を失い、攻撃中に何が起きたのか、どのデータが侵害された可能性があるのかを正確に把握できません。

クラウドストライクのクラウドインシデント対応スペシャリストの専任チームが調査するクラウドデータ侵害の多くは、クラウドセキュリティの設定ミスに原因があります。クラウドストライクでは、クラウドデータ侵害の影響に対処するのではなく、侵害が発生する前にクラウドセキュリティポスチャを強化することを組織にお勧めしています。

クラウドデータ侵害が発生した場合は、クラウドインシデント対応担当者と調査員の専門チームを擁するインシデント対応企業に依頼する必要があります。エンドポイント侵害に対する従来のインシデント対応サービスを提供している企業は、クラウド侵害への対応に関しては効果的ではありません。

クラウドストライクには、AWS、Azure/O365、GCPのクラウド環境に関する知識を持つクラウドインシデント対応スペシャリストの専任チームがあります。クラウドストライクは、フォレンジック調査を加速し、脅威アクターによって実行された悪意のあるアクションを可視化する独自のクラウドデータコレクターツールのスイートを構築しました。

クラウドストライクは、クラウドインシデント対応のリーダーであることに誇りを持っており、無秩序なものになり得たイベントに、制御、安定性、秩序をもたらします。クラウドデータ侵害に迅速かつ効果的に対応するために、クラウドストライクがどう貢献できるかをご確認ください。