クラウドでのインシデント対応は、準備さえしておけば簡単です

ビジネスがすでにクラウドに移行している場合は、AWS と Microsoft 365 が提供する柔軟性と拡張性により、さらなるメリットが得られます。クラウドでのインシデント対応は、オンプレミスでのインシデント対応よりもはるかに簡単です。

しかし、問題があります。インシデント対応を実行するために必要なツールはすべて、お気に入りのクラウド プロバイダーと SaaS 製品内に存在するため、災害イベントに備えるために初期設定が必要になります。

集中ログ

クラウド内のデフォルトのログ ダッシュボードは、インシデント対応調査用に構築されていません。そのため、GCP Chronicle や Azure Sentinel などの SIEM ソリューションはすべての主要なクラウド プラットフォームに存在します。これらのソリューションは、ネイティブ機能を強化し、それらの機能が有効になっている場合に、クラウドでのインシデント対応を簡素化します。

クラウドの組み込みイベントを活用するには、まずすべてのログを一元管理することから始めます。

一般的に、次の 2 種類の操作を記録できます。

「読み取り」操作では、クラウド コンピューティング環境とそのコンポーネントに関する情報が変更なしで公開されます。

書き込み操作では、新しいアカウントの作成、新しいユーザーの追加、サービスのデプロイなど、環境に変更が加えられます。

クラウド コンピューティング アカウントを変更する「書き込み」操作をログに記録することは、検出にとって重要です。しかし、これはインシデント調査には不十分です。徹底したインシデント対応には、「読み取り」イベントと「書き込み」イベントの両方を含む、脅威アクターが実行したすべてのアクションを確認する機能が必要です。

完全に集中化されたログ記録を設定することは、それを維持することと同様に重要です。これには、データの健全性と範囲を確認する必要があります。

コストを削減するために、集中ログ ソリューションではログ記録が制限されることがよくあります。同時に、一部の従業員が退職すると制限に関する知識が失われるため、クライアント チームは完全なログ セットを保有していると想定する可能性があります。企業がコスト関連の問題に直面している場合は、フィルタリングされたログをコールド ストレージに保存し、必要に応じて集中ログ ソリューションに取り込めるようにする手順を実装することをお勧めします。

クラウドコンピューティングプロバイダーに頼ることはできない

ほぼすべてのクラウド コンピューティング プロバイダーでは、デフォルトのログ ポータルを使用して、特定の期間からの操作をユーザーがダウンロードできるようにしています。しかし、調査の結果、これらのクラウド コンピューティング プロバイダーのポータルは継続的に更新されているものの、ダウンロードの整合性には長い間制限があることが判明しました。ダウンロード後、ログは分析のために何らかの方法で処理する必要があり、アクティブなイベントに応答する場合は大きな障害となる可能性があります。

さらに、ほとんどのクラウド コンピューティング ログ ポータルでは、すべてのクライアントに対するログ サービスの全体的な可用性を保護するために、オンデマンド ダウンロードに制限が課せられています。かなり大規模なクラウド環境がある場合、これは大きな問題になる可能性があります。

最良の場合でも、集中管理されたログがないと 1 時間遅れることになり、企業の対応に重大な影響を及ぼす可能性があります。このため、すべてのクラウド サービスでは集中ログ記録が依然として必要です。

デフォルトのログ記録だけでは不十分

通常、サイバー インシデントによる影響が最も大きいのは、企業がクラウド アカウント上で使用しているサービスです。残念ながら、これらのサービスのうち、ログ記録がデフォルトで有効になっているものはほとんどありません。

クラウドで使用されるサービスのログ記録にも特別な考慮を払う必要があります。これには簡単な構成の定義が必要になる場合があり、時間がかかることがあります。ただし、これらのサービスでログを設定しないと、コストが高くなる可能性があります。

ログが有効になっていないため、AWS S3 バケットが誤って公開されているシナリオを考えてみましょう。規制当局がデータにアクセスした企業に問い合わせても、証拠がないため回答できない可能性がある。これにより、企業は多額の罰金やさらなる結果に直面する可能性があります。

資産のタグ付けとマッピング

オンプレミスのインシデント対応で最も難しい部分の 1 つは、資産を追跡することです。これにより、対応者がどのコンピュータを最初に保護または調査するかを優先順位付けする作業が妨げられることがよくあります。

クラウドでは、環境のマッピングもオンプレミス ネットワークよりもはるかに簡単に、どこからでも実行できます。証拠収集も簡素化されます。サードパーティのツールではなくクラウドネイティブ ツールを使用すると、データを取得するためにデータ センターに行くことなく、自宅やオフィスで証拠をキャプチャできます。ただし、調査チームがコンテキストを理解できるように適切にラベル付けされていない場合、これらのスナップショットはほとんど価値がありません。

少なくとも、クラウド コンピューティング リソースには、コスト センター、所有者、関連サービス、およびサービスに関するこのクラウド コンピューティング リソースの役割をタグ付けする必要があります。この情報がないと、アセットの周囲のシーンを取得しようとすると時間が無駄になります。

たとえば、適切にラベル付けされていないボリューム スナップショットは、調査に必要な証拠を提供することはほとんどありません。単一のボリューム スナップショットの調査がすぐにすべてのボリューム スナップショットのレビューになり、再び時間の無駄になる可能性があります。

レスポンダーアカウントを作成する

組織に必要なログがすべて揃っている場合でも、セキュリティ チームがそれらにアクセスできない場合があります。したがって、インシデントが発生する前に、クラウド コンピューティング環境用の対応者アカウントを作成する必要があります。サードパーティの保証やサポートのためにログを外部ベンダーと共有する必要がある場合、これらのアカウントは重要になります。

間接アクセスまたは読み取り専用アクセスにより、これらの応答者アカウントはログとログ ダッシュボードにアクセスし、調査を開始できます。これらのアカウントでは環境に変更を加えることができないため、脅威アクターを直接修復するにはクラウド管理者に連絡する必要があります。企業のセキュリティ チームが、クラウド環境でのポリシーの変更と資格情報のリセットによる直接的な影響を理解している場合は、レスポンダー アカウントへの直接アクセスが合理的である可能性があります。

クラウドコンピューティングを活用する

従来のインシデント対応は、オペレーティング システムがセキュリティを考慮して設計されていなかった 10 年以上前に誕生しました。このため、捜査官はシステムに不注意で残された証拠に頼らざるを得なくなります。

クラウド コンピューティング ソリューションでは、調査を待つベースラインのデータが存在します。たとえば、AWS の侵害を調査する際、調査はほぼ完全にログに依存していました。通常の状況では、データ侵害がどのように発生したかを調べるためにデジタル ファイルを解析するデジタル フォレンジックは実行されません。これは、脅威の攻撃者は、他のユーザーと同様に、クラウド コンピューティング環境で実行できる操作が制限されているためです。ほぼすべての操作がログに記録されます。したがって、この調査は比較的完全で簡単に解析できるデータ ソースに依存しています。

クラウド インシデント対応とオンプレミス インシデント対応を比較します。オンプレミス インシデント対応では、証拠が不完全で形式がさまざまであるため、数日または数週間かかる特定の解析作業が必要になります。

企業がサイバー攻撃を受けることは避けられませんが、インシデント対応を通じて準備しておくことで、コストを上回る時間とリソースを節約できます。これらの手順を踏まなかった場合の損害は、あらゆる事件よりも長く続く可能性があります。