How Google Does It: 高品質でスケーラブルな最先端の脅威検出

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

Google のセキュリティ運用がどのようになされているか、興味を持ったことはありますか？新シリーズ「How Google Does It」では、Google のスペシャリストが、セキュリティに関する喫緊のトピック、課題、懸念事項に対する Google のアプローチについて詳しく紹介し、インサイト、所見、重要なヒントを共有します。今回は、Google の最先端の脅威検出とその対応アプローチの核心と原則について、Tim Nguyen が解説します。

Google の脅威検出 / 対応チームは、Google および Alphabet のシステムとネットワーク全体で悪意のあるアクティビティを監視しています。このチームは、世界最大の Linux フリート、ほぼすべての種類のオペレーティングシステム、Google Cloud のインフラストラクチャとサービス、そして 18 万人を超える従業員を保護する責任を負っています。

このチームでは、複数のコードエンジンを組み合わせた検出エンジンを活用し、ログを分析し、インテリジェンスを適用して、実用的なシグナルに変換しています。これらのプロセスは、大規模なログのパイプラインをクラウド データ ウェアハウスにストリーミングすることから始まります。これにより、ログのデータセット全体に対して、何か月も遡って迅速にクエリを実行できます。

さらに調査が必要なシグナルが見つかった場合は、トリアージのキューにルーティングされ、検出チームのメンバーが必要に応じて審査、エスカレーション、修復を行います。新たなセキュリティ侵害インジケーターが見つかった場合に（多くの場合、新しいインテリジェンス、シグナルの改善、より広範なカバレッジを通じて明らかになりますが）、そうした新しいインジケーターが過去のすべてのシグナルとデバイスに影響するかどうかを自動的に確認する機能もあります。

こうした取り組みは、困難な戦いのように思われるかもしれません。組織全体にわたり実施しようとする場合はなおさらです。そのため Google では、同じ情報の受け取りや処理に要する時間を最小限に抑え、可能な限り効率的に重要な意思決定を行えるようにしたいと考えています。

Google では、検出 / 対応チームがサービスレベル目標（SLO）に従って迅速に脅威を検知し、対応することで、滞留時間（攻撃者が検出される前にネットワーク上で活動している時間）を可能な限り短縮しています。

では、Google の広大な環境全体にまで検出機能と対応能力を拡大しながら、この迅速な対応目標をどのように達成しているのでしょうか。以下に、脅威検出の成功の秘訣を紹介します。

1. 可能な限り、自動化する

セキュリティ侵害インジケーター（IoC）が存在するかどうかを調査するよう依頼された場合は、あらゆるものを調査する必要があります。つまり、自社所有のすべてのワークステーション、オペレーティング システム、本番環境サーバー、仮想マシンなどに加えて、Google のプロダクトやサービスを支えるすべてのリソースが調査対象となります。この作業はまさに「トイル」です。環境が大規模なうえ、非常に多くの種類の IoC が存在するため、手作業では対応できません。

Google のモットーは、収集を減らし、できるだけ直接分析することです。人間は微妙なニュアンスを理解し、判断を下し、あいまいな情報を処理することに特に優れているという考えに基づき、コンテキストの構築を可能な限り増強し、チームが正しい判断を下すための時間を増やすせるように努めています。

Google では、イベントの分析や調査のために人間が同じ手順を何度も繰り返すのではなく、マシンを使用してそのほとんどを自動化しています。マシンのテレメトリ、ユーザー情報、プロセス実行の大部分を自動的に取得できることが理想です。

イベントの約 97% は自動化された「ハンティング」によって生成され、リスクスコアと調査対象の詳細とともに人間に提示されます。これにより、意思決定に必要なすべてのコンテキスト情報を最初から入手できるため、はるかに短い時間でイベントをトリアージできます。また、自動化によって誤った調査経路が排除され、人間が追跡すべき方向性が示されるため、真陽性の判断にも役立ちます。

自動化によるもう一つの大きなメリットは、イベント調査の費用を削減できることです。ロジックの一部を自動的に複製し、情報を収集し、チームに提示できるため、作業のスピードアップと、解決までの時間短縮が可能になります。これにより、個々のイベントを処理するチケットあたりの費用を大幅に削減しながら、同時に処理できるイベントの数を増やすことができました。

当然ながら、自動化には生成 AI も広く活用されています。たとえば、大規模な言語モデルによって生成された下書きにより、エンジニアがエグゼクティブ サマリーを執筆する時間を 53% 削減しながら、事実の正確性や執筆のベスト プラクティスへの準拠という点もほぼクリアした高品質なコンテンツの作成を実現しました。

イベントを調査するために、独自のログソースを追加したり、追加情報を収集したりする必要がある場合もあります。専門性の高い作業を人間が手作業で行う余地を残しておくことは重要ですが、全体的な目標は、確実に価値を付加し、より大きな成果を上げることにあります。言い換えれば、反復的な作業に労力やエネルギーを無駄にしないということです。

2. コラボレーションによって検出を強化する

重要でありながら見落とされがちな真実として、検出 / 対応チームは単独では能力を発揮できないということがあります。脅威の検出を成功させるには、さまざまな部署、チーム、関係者との緊密かつ継続的なコラボレーションが必要です。

Google では、手動であれ自動であれ、すべての脅威ハンティングは脅威モデリングから始まります。追跡対象を正確に理解しなければ、優れた検出結果を得ることは不可能です。そのため、Google では、常にプロジェクトの責任者と話し合うことから始めて、システムの仕組みを正確にモデル化し、構築する検出機能の明確なイメージを把握するようにしています。

どのような種類の脅威を検出したいのかを理解できたら、既存のログを検証し、取り組みをサポートするすべてのテレメトリ データが揃っているかどうかを確認します。不足しているものがあれば、チーム間で協力して追加のログを発行します。これまでの経験から、ほとんどの場合、インシデントの事後検証中に攻撃者のアクションをより明確にする追加調査が必要になります。ログを改善し、調査すべき適切な情報を明らかにし、攻撃に対して効果的に対応するためのプロセスは、継続的に共同で行われます。

3. アセット インベントリを作成する

かつては、アセットのインベントリや履歴が一切ない状態でインシデント対応を行う必要がありました。特定の時点でホストが存在していたかどうか、いつ作成され、いつシャットダウンされたか、攻撃者に侵害されたかどうかなどについて、環境内のアセットを一切参照することなく把握しようとすることを想像してみてください。アセットの全体像を把握していない場合、インフラストラクチャへの格好のエントリー ポイントが生まれる可能性があります。

アセット インベントリは、インフラストラクチャ全体を保護するうえで不可欠であり、脅威を検出して対応する際の重要な課題を解決するヒントになります。クラウド環境では、あらゆるものを自動的にインベントリ管理し、アセットの作成履歴を長期間保持して、インフラストラクチャをプログラムでクエリできるという点において非常に大きなメリットを得られます。

4. 検出ルールを作成して、トリアージする

Google では、検出ルールを作成している人が、シグナルにも対応しています。これは、非常にシンプルなルールに基づいています。つまり、アラートを担当していない人は、アラートが午前 3 時に発報されても気にかけないということです。

脅威検出を担う組織では、検出ルールを作成するチームとアラートをトリアージするチームを分けることが一般的ですが、この方法は多くの不必要な緊張を生み出す原因となる可能性があります。セキュリティ アラートにはノイズがつきものであり、検出ルールをどれほど工夫したとしても、トリアージ チームには膨大な量のアラートがいずれ押し寄せることになります。

トリアージにおけるアラートの影響が理解されていなければ、検出を改善しようとする意欲は低下します。チームのアラート疲れは、燃え尽き症候群、フラストレーション、鈍感化をもたらす可能性があり、重大な問題を見逃すことにつながる非常に現実的な問題です。Google では、検出ルールを作成するチームが、そのトリアージも担当することで、検出の品質に対するアカウンタビリティが強まり、アラートが制御不能になることを防止できると考えています。

5. セキュリティ エンジニアリングはソフトウェア エンジニアリングである

ソフトウェア エンジニアリングは、現在、あらゆるセキュリティ分野の中核を担っています。クラウドの運用、および、そのクラウドを保護する検出インフラストラクチャの運用には、日々コードを書くことが必要です。Google での日々のワークフローの大部分は、分析とロジックの自動化に関するコーディングです。これにより、作業がトリアージされ、チームの他のメンバーでも行えるようになります。

そのため、Google のセキュリティ エンジニアは全員、コードを読み書きできることが必須です。

Google での日々のワークフローの大部分は、分析とロジックに関するコーディングです。これにより、作業をトリアージし、チームの他のメンバーでも行えるようになります。セキュリティ エンジニアには、脅威モデリング、ログ取得、データ モデリング、シグナル開発、分析の自動化、トリアージ、インシデント対応など、幅広い責任を担うことが求められています。他の企業では、これらのタスクを、2 つ、3 つ、あるいは 4 つの役割で分担しているかもしれません。

チームのエンジニアリング スキルが高まることで、自動化をさらに進められるようになり、最終的には、必要な作業だけれども恒久的な価値をもたらさない反復的なトイルを削減することにも役立ちました。このアプローチには、コードのドキュメント化、進捗状況のモニタリングや追跡、ストレステスト、検出の検証、分析と対応の品質を議論するための週次レビューなど、ソフトウェア エンジニアリングのベスト プラクティスの多くを採用することも含まれています。

理想的な世界では、ツールを購入し、数回ボタンを押すだけで検出を実行できるかもしれませんが、実際には、検出とはコードそのものです。検出のエンジニアリング プラクティスを取り入れることで、検出とシグナルの品質を改善できるだけでなく、検出と対応を組織全体にスケールアウトすることが可能になります。

この記事には、Cloud Security Podcast のエピソード「Modern Threat Detection at Google（Google における最先端の脅威検出）」と「How We Scale Detection and Response at Google: Automation, Metrics, Toil（Google における検出と対応のスケーリング: 自動化、指標、トイル）」から得られたインサイトが含まれています。これらのエピソードもぜひご参照ください。

-CISO オフィス、セキュリティ アドバイザー Anton Chuvakin

-Google、検出および対応担当ディレクター Tim Nguyen