クラウドにおける脅威の検出についての考え方

※この投稿は米国時間 2022 年 7 月 13 日に、Google Cloud blog に投稿されたものの抄訳です。

ご自身の組織がオンプレミスからハイブリッド クラウドもしくは純粋なクラウドに移行するにあたり、脅威の検出についての考え方も同時に進化させる必要があります。多くのクラウド環境にまたがる脅威に直面している場合は特にです。デジタル トランスフォーメーションの安全性を高めるためには、パブリック クラウド コンピューティングにおける脅威検知を検討する新しい基礎的なフレームワークが必要です。

こうした用語は時代とともに意味が変化していくため、まず「脅威の検出」と「検出と対応」の二つを定義します。バランスの取れたセキュリティ戦略は、「予防」、「検出」、「対応」というセキュリティの 3 つの要素をすべてカバーします。「予防」は改善することはできますが、完璧にすることはできません。どれだけ予防に努めても、防御を突破してくる脅威には常に警戒する必要があります。悪意のあるアクティビティを発見、確認し、自動でそれに対応したりセキュリティ チームに報告したりすることが、「検出と対応」に相当します。

重要な変化は、従来の環境からクラウドへの移行に影響を与え、次の 3 つの主要分野に影響を及ぼします。

• 脅威の状況

• IT 環境

• 検出方法

まず第一に、脅威の状況は変化するものです。つまり、新しい脅威は次々生まれ、古い脅威は消え去り、多くの脅威の重要性は変わり続けるということです。組織の環境における脅威の評価を行ってから、環境全体をパブリック クラウドに移行する場合、リフト＆シフト アプローチを取っていたとしても、脅威の評価はかなり違ったものになります。MITRE ATT&CK クラウドは、脅威となるアクティビティがパブリック クラウド コンピューティングに及ぼす影響を理解するのに役立ちます。

第二に、自社を取り巻く技術環境全体も変化していきます。これは、防御側として遭遇するシステムやアプリケーションの種類だけでなく、技術や運用プラクティスにも当てはまります。基本的に、脅威を検出する必要がある領域としてのクラウドは異なります。これは、脅威にさらされているアセットと検出を行う技術に適用されます。従来の「ブルーチーム」にとって、クラウドは時に課題しかない異質な風景に映ることがあります。実際には、クラウドは検出にとって多くの新しい機会をもたらすものです。ここでのメインテーマは変化です。変化には常に良い面と悪い面があるものです。

つまるところ、クラウドとはこういうことです。

• 通常、多くのリージョンやデータセンターに分散されて実行される。

• 多くの場合、変更不可である。更新するよりも、置き換えられるシステムを利用する。

• エフェメラルである。タスク用に作成され、その後削除されるワークロードを使用することが多い。

• API ドリブンである。統合型 API により行われる。

• ID レイヤが中心である。ほとんどの場合、ネットワーク境界だけでなく、ID を使用してワークロードを分離する。

• 自動スケーリングが可能。 ワークロードの増加に応じて拡張できる。

• プロバイダと共有される。

分散型、不変型、エフェメラル型のクラウドのプロパティの組み合わせを DIE triad と呼ぶこともあります。これらはすべて、クラウド環境における検出に影響します。

第三に、テレメトリー ソースと検出方法もまた変化します。先ほど述べたことと関連していると思われるかもしれませんが、必ずしもそうとは限りません。いくつかのクラウド サービスにとって（SaaS は特に）、EDR といったエージェントを使った人気のアプローチは機能しません。しかし、テレメトリーの新しい豊富なソースなら利用できるかもしれません。Cloud Audit Logs は、その好例です。

同様に、境界上でトラフィックのスニッフィングを行える、さらには境界を持つことができるという期待も、完全に正しいとは限りません。暗号化が広範に普及することでレイヤ 7 のトラフィックの解析を妨げ、公開 API は、境界線が何たるかというルールを書き換えてしまいます。最終的に、検出ソースと検出方法も本質的にクラウド プロバイダと共有され、あるものはクラウド サービス プロバイダの管理下に、あるものはクラウドユーザの管理下に置かれます。

このことから、クラウド上の脅威を検知できる、あるいは検知すべき領域がわかります。

ここで、クラウドの脅威検出のシナリオをいくつか見てみましょう。

クラウド セキュリティにおける ID の役割に、誰もが注目しています。当然ながら、脅威の検出においても非常に重要です。「パブリック クラウドにおいては、IAM のたった 1 つのミスからデータ侵害が起こる」という言い古された言葉を繰り返すつもりはありませんが、クラウド セキュリティのミスが大きな損失につながることは間違いありません。こうしたことから組織を守るため、Google Cloud は、すべての IAM 付与権限を自動的かつリアルタイムに解析し、追加された部外者（たとえ間接的であっても）を検出するサービスを提供しています。

エージェントを使って、仮想マシン（VM）などのコンピューティング インスタンスの内部の脅威を検出することは、すでに過去の遺物となっているようです。結局のところ、VM もサーバーの一つにすぎません。しかしながら、クラウドにより新しい扉が開かれた分野もあります。たとえば、VM Threat Detection を使えば、セキュリティ チームはすべてのコンピューティング フリートに対して完全にエージェントレスの YARA ルールを実行できます。

最後に、BigQuery のようなプロダクトに対しては、新しいデータ引き出しの検出方法が必要とされています。Security Command Center プレミアムは、データを違う Google Cloud 組織にコピーする BigQuery のクエリとバックアップを検出します。

当然、クラウドにおいても変わらないものもあります。たとえば、内部脅威や外部脅威といった幅広い脅威のカテゴリー、攻撃の大まかな段階のようなサイバー エクスプロイト チェーンのステップ、そして MITRE ATT&CK の戦術などはほとんど変更がありません。また、広範な検知のユースケースも変わらないでしょう。

これは、防御側にとってどのような意味をもたらすのでしょう。

• クラウドに移行すると、脅威や IT もかなり変化します。

• つまり、オンプレミスの検出技術とアプローチは、今後の開発の基盤として機能しなくなるということです。

• また、従来のオンプレミス検出ツールや脅威検出コンテンツをただ単にコピーしていても十分ではありません。

• むしろ、Google Cloud へ移行することで、クラウドのテクノロジーとプロセスが生み出す新たな機会により、継続的な目標である機密性、整合性、可用性の実現方法を改革する絶好の機会と言えます。

次のステップ:

• 次のポッドキャストを聞く: 「脅威モデルとクラウド セキュリティ」（エピソード 12）

• 次のポッドキャストを聞く: 「クラウドにおけるよい検出と対応とは？Expel MDR からの分析情報」（エピソード 72）

• 次のポッドキャストを聞く: 「クラウドの脅威とその観察方法」（エピソード 69）また、関連するブログを読む: 「今日のクラウドの脅威についての考察」

• クラウド検出をテストする方法を確認する

• SCC と Chronicle のクラウド脅威に関する調査のガイダンスを読む