適切な検出：脅威検出には、ルールや異常検知だけでは不十分です

検出を適切に行うには何が必要で、なぜ私たちはこれほど長い間、それを正しく実現できなかったのでしょうか。

検出はもともと、ログデータに対してリアルタイムでルールを適用する形で構築されてきました。2010年代半ばには、User and Entity Behavior Analytics（UEBA）製品が、高度なベースライン化とグルーピングの手法を導入し、主にユーザー、場合によってはリソースに着目して外れ値を特定するようになりました。成熟したSOCチームの多くにとって、ルールと異常検知は今なお検出アーキテクチャの中核です。

しかし、このアプローチには3つの重大なギャップがあります。

1. It検出結果を構成データと相関できない
2. クラウド特有のセマンティクスを考慮できない
3. コンテキスト評価を手動の検出後フェーズに委ねてしまうため、インシデント全体ではなく、ノイズの多い個別検出に終わってしまう

構成情報の取り込み

従来のどちらの手法にも欠けている要素の1つが、イベントデータや履歴データを構成データと相関させる能力です。これは、過剰な誤検知を防ぎ、アラートの影響を適切に評価するうえで不可欠です。現在、多くのチームはこのデータを検出後、つまりトリアージや分析の段階で初めて取り込んでいます。しかも、その情報は手動で取得しなければならないことが多く、解釈も容易ではありません。構成分析を検出ロジック自体に組み込むことで、検出精度を高め、チームの運用効率を最大化できます。この構成データには、たとえば次のようなものがあります。

• 影響範囲の評価： このユーザーは侵害されている可能性があるとして、実際にどのリソースへアクセスできるのか。これは簡単ではありません。たとえばAWSのような環境では、どのロールがどのロールを引き受けられるのか、さらに各ロールがどのリソースにアクセスできるのかまで含めた、完全なアイデンティティ分析のチェーンが必要になります。この分析が不十分だと、そのアイデンティティが実際に持つアクセス権を誤って評価し、誤検知につながる可能性があります。
• 適切な重大度評価： このEC2インスタンスは異常な挙動を示しており、関連付けられたインスタンスプロファイルに管理者権限がある場合、リスクはさらに高くなる可能性があります。
• 誤検知の判定： 有効権限分析により、このユーザーに非常に広範な権限を持つロールが突然付与されたことがわかったとしても、機密アセット側にそのロールの権限を上書きするリソースポリシーがある場合、実際には問題がなく、アラートを生成すべきではありません。

検出そのものに構成データを取り込もうとする試みはこれまでもありました。多くの製品が、ユーザーまたはエンティティのフレームワーク、タグ、HR連携などの機能を通じて、こうしたデータの一部を検出ロジックに取り込もうとしています。しかし、これらの連携や更新を維持し、幅広い構成データをモデルに反映し続けることは、非常に時間と手間がかかります。そのため、多くのチームは構成分析を検出後のフェーズへ回さざるを得ませんでした。

クラウドおよびSaaS向けに設計

UEBAは、もともとインサイダー脅威のユースケースを起点に発展してきました。主にアイデンティティを対象とし、その通常のアクティビティや行動パターンをモデル化するために構築されたものです。このアプローチの有効性が示されるにつれ、一部のリソース、たとえば個別の仮想マシン（VM）やインスタンスもモデル化の対象に含める製品が増えていきました。

しかし、多くの組織がIaaSやSaaS環境へ移行する現在、UEBAの考え方そのものを大きく見直す必要があります。クラウドリソースは一時的に生成・破棄されることが多く、スケーリング要件も従来とは異なるため、ベースライン化や異常検知にも新しいアプローチが求められます。KubernetesのワークロードやPod、GitHubのリポジトリやActions、Googleドキュメントに至るまで、IaaSとSaaSの多様なリソースはそれぞれ異なるモデリングを必要とします。

従来型のアイデンティティでさえ単純ではありません。たとえばAWSのロールは、人間とマシンの双方によって引き受けられる場合があり、そのモデリングははるかに複雑です。場合によっては、アラートを発生元のアイデンティティではなく、使用されたロールにしかひも付けられないこともあります。その結果、従来のUEBAツールや機能では、クラウドおよびマルチクラウド環境で運用する現代の組織のニーズを十分に満たせないことが少なくありません。

検出はインシデントではない

検出ツールの役割は、単に不審なアクティビティの兆候を示すことではありません。アラートを環境全体の文脈の中で適切に位置付けることも求められます。たとえば、重複アラートの自動グルーピングや、組織再編、合併、新しいツール導入といったイベント時にビジネスコンテキストを取り込むことなどが挙げられます。

こうしたコンテキストに対応できることは、アナリストの対応速度と調査の網羅性を高めるうえで重要です。ノイズの多い個別検出を大幅に減らし、それらを十分に文書化されたインシデントへと変換できるからです。

一方で、特定機能に特化しすぎたツールでは、SIEM、SOAR、あるいはその他のシステム側に、二次的な相関分析、集約、分析を担わせることになりがちです。その結果、こうしたシステムの保守は煩雑になり、手作業にも依存しやすくなります。

エクサフォースでは、現代のクラウドおよびSaaS中心の企業に特化して設計された、ルール、異常検知、構成データのバランスの取れた3要素こそが、効果的な検出の要件だと考えています。以下では、私たちのアプローチが従来とどう異なり、それがなぜ重要なのかをご紹介します。

セマンティックデータモデル

高品質なデータの確保

私たちの検出アプローチは、エクサフォースの3つのモデルアーキテクチャ、すなわちセマンティックデータ、ビヘイビアモデル、ノレッジモデルから始まります。それぞれが異なるコンテキストレイヤーを追加します。

私たちはさまざまなソースからイベントデータと構成データを取り込み、それらを構造化されたイベントとリソースに変換します。イベントはセッションに整理され、場所、Autonomous System Number（ASN）、継続時間といったセッションレベルの視点やコンテキストシグナルが付加されます。さらにセッション同士を連結することで、発生元のアイデンティティ、ロールの引き受け、ロール間の行動、アクションのシーケンスを捉え、誰が何をしたのかをより完全に分析できるようにします。こうして、後続の検出評価に向けたデータを整備します。

リソースも同様に処理されます。構成を取得し、リソースタイプを解析し、リソースをエンリッチし、関係グラフを構築します。さらにエクサフォースは、構成変更を時系列で収集するため、見過ごされがちな微細かつ重要な変更も検出できます。同時に、各構成変更の影響を評価できるため、実質的に完全な影響範囲分析を行うことが可能になります。リソースの中でも重要なサブセットであるアイデンティティには、たとえば次のような追加のエンリッチメントが施されます。

• 人間かマシンかの分類： エクサフォースのモデルは、アイデンティティ種別、行動パターン、ロール引き受けパターンを分析し、アイデンティティを人間またはマシンとして分類します。この分類は動的であり、複雑なシナリオにも対応できます。たとえば、人間が新しいアイデンティティを作成した後、それがマシンアイデンティティによって実行されるスクリプトで使われる場合や、人間とマシンの両方で共有されるロールなどです。アイデンティティの人間／マシン分類が変化すれば、そのエンリッチやモデル化の方法もそれに応じて変わります。
• 有効権限分析： 推移的なロール引き受け能力を踏まえて、ユーザーが実際に持つ権限の全体像を解釈し、そこにリソースポリシー情報を重ね合わせます。
  • アイデンティティチェーン： どのロールが使われたかだけでなく、実際にこのアクションを実行したのはどのアイデンティティかを特定します。
  • 到達可能リソース分析： このアイデンティティが、どのリソースに対して、どのアクションを、どのレベルの権限で実行できるかを把握します。
• サードパーティのアイデンティティ／アクセス： サードパーティのアイデンティティを特定し、その行動と権限をより注意深く監視します。

ここでいうリソースは汎用的な概念です。AWS EC2インスタンス、Kubernetes Jobs、GitHubリポジトリ、Oktaロールなど、さまざまなものが含まれます。構成データを最初からこうしてモデル化することで、より完全な検出が可能となり、第1の柱である構成データ活用の基盤が築かれます。

ビヘイビアモデル

エクサフォースでは、異常となり得るあらゆる次元を「シグナル」と呼びます。たとえば、通常とは異なる場所からのアクセスや、まれなサービス利用などです。シグナルには弱いものも強いものもありますが、どちらも重要です。検出は、同じイベントまたはセッション内で発生したシグナルをグルーピングすることで生成されます。これは、中程度の信頼度を持つ異常の集合を表します。これらのシグナルと検出が、このソリューションにおけるルールと異常検知の柱を構成します。

セマンティックモデルは、ビヘイビアモデルでデータをモデル化できるようにする前処理の役割を担います。たとえばイベントをセッション化することで、個別アクションのベースラインだけでなく、イベントの組み合わせやイベントパターンのベースライン化も可能になります。同様に、ベースラインは対象オブジェクトに応じて最適化されます。たとえば、人間とマシンは前述のセマンティックデータモデルで識別され、それぞれ異なる方法でモデル化されます。マシンは予測可能なパターンに従う傾向がありますが、人間の行動ははるかに多様です。エンジニアと自動化スクリプトの両方で共有されるロールのような共有アイデンティティも、こうした違いを踏まえてモデル化されます。

私たちは、次のような幅広いシグナルを、単独でも組み合わせでもモデル化します。

• アクション、およびアクションパターン
• サービス
• 時間
• 継続時間
• ロケーションおよびASN、ソース間比較を含む
• リソース

以下は、複数のシグナルを組み合わせたエクサフォースのFindingの例です。この例では、Operation AnomalyとService Usage Anomalyの両方が確認されました。ユーザーMallamは通常、このGetSecretValueアクションを実行せず、AWS US East 2リージョンでアクションを実行することもほとんどありません。そのため、エクサフォースは検出を発報しました。

この多次元アプローチは非常に重要です。単一の弱いシグナルだけでは十分でないことがほとんどですが、複数の弱いシグナルが組み合わさることで、十分な根拠になることはよくあります。サポート対象の幅広いリソースとログソース全体に対して、このようにルールと異常検知を適用することが、検出トリオのうち2つの柱を成しています。

ノレッジモデル

検出の目的は、侵害の可能性を示すシグナルを見逃さないよう、網羅性を確保することです。しかし、網羅性を追求するとノイズも増えます。そこでノレッジモデルが重要になります。

セマンティックデータモデルが処理を行い、シグナルが発火し、それらが検出としてグルーピングされた後、エクサフォースはトリアージパイプラインを実行します。このパイプラインでは、検出にコンテキストを付与し、組織固有のビジネスコンテキストを追加することで、中程度の信頼度の検出を高信頼のFindingへと変換します。このトリアージプロセスは、エクサフォースのアラートにもサードパーティのアラートにも同様に適用され、さらにコンテキストを補強することで、アナリストが本当に注目すべきアラートだけを浮き彫りにします。この分析では、状況に応じて相反する要因を比較衡量し、検出フェーズの最後で実施されます。たとえば、ユーザーが広範な権限を持っているという事実と、実行されたアクションの重大度をあわせて評価する、といったことが含まれます。

リソース／アイデンティティの構成データと、ルールおよび異常検知の出力を突き合わせて評価するのが、このノレッジモデルです。さらに、類似Findingに関する追加コンテキスト、ユーザーが提供するビジネスコンテキスト、ユーザーやマネージャーによる確認結果なども加味されます。

類似Findingが特定されます。すでにクローズ済みであれば、その解決内容をこのFindingの評価材料として利用します。まだオープンまたは進行中であれば、モデルがそれらをグルーピングします。グルーピング後は、それぞれの関係性や分析の関連度合いを明示するために、重複、グループ化、連鎖のいずれかに分類されます。

ビジネスコンテキストルールにより、ユーザーは自由記述形式でモデルに情報を入力できます。たとえば、「これらのリソースは非常に重要である」「当社はこのVPNを使用している」といった環境情報、「ユーザーA・B・Cは経営幹部であり、より注意深く監視すべきだ」といったユーザー情報、あるいは「当社は医療企業であり、以下の拠点を持ち、これらの拠点間を移動するチームが多い」といった企業全体の状況などです。この自由記述入力により、個々のアラートを手動でミュートまたは抑制しなくても、重要なコンテキストをエクサボットに反映させることができます。

エクサボットは、必要に応じてエンドユーザーやマネージャーに確認を求めるスキルも備えています。エクサボットがユーザー確認やマネージャー確認が有効だと判断した場合、その本人にSlackまたはTeamsでメッセージを送り、その回答を判断材料として活用できます。

エクサボットはこれらの情報を整理してノレッジモデルのエージェントに渡し、各要素を評価して「誤検知」または「調査が必要」を判定します。こうして、基本的な検出はコンテキスト豊富なインシデントへと変換されます。これらの分析は、アラートがオープン中または進行中である限り継続的に実行されるため、環境が変化しても推奨される評価は常に最新に保たれます。なお、このデータを事前に準備し、構造化し、要約しておくことで、分析を行うAIエージェントの精度を高め、ハルシネーションを最小化できます。

検出をユーザーに提示する前に初期のノレッジモデルを実行することで、エクサフォースの検出は非常に高い信頼度を実現します。

例

この例では、あるユーザーが短時間のうちにZurichとMatranという2つの場所からアクセスしていました。このセッション途中での急なロケーション切り替えは異常でしたが、各ロケーション自体はそのユーザーの過去の行動と一致しており、他の社員の行動とも整合していました。実行されたアクションも、このユーザーの過去の行動と一致していました。そのため、トリアージエージェントは、この異常な挙動を他の要因とあわせて評価し、誤検知と判断できました。なお、このトリアージエージェントには企業固有のビジネスコンテキストも与えられており、この例ではZurichオフィスに関する情報が参照されています。（ビジネスコンテキストとトリアージについては、次回のブログで詳しく紹介します！）

トリアージ後、エクサフォースは自社アラートとサードパーティのアラートの両方を、集約された攻撃チェーンとしてグルーピングします。これにより、アナリストは分断されたイベントではなく、全体像を把握できます。

エクサフォースの実例：GitHubの例

では、エクサフォースのアプローチが実際にどう機能するのかを見てみましょう。

GitHubは重要なデータソースです。企業の知的財産のような機密データを含み、さらにCI/CDアクションを強力に実行できる高権限のシークレットが関連付けられている場合もあります。しかし、見過ごされがちな領域でもあります。

エクサフォースはログと構成データを取り込み、アクティビティ情報を収集するとともに、サプライチェーン攻撃に関連するリスクや脅威を特定します。たとえば、CI/CDや開発者ワークフローで一般的に使用される認証情報であるPersonal Access Token（PAT）の利用が挙げられます。GitHubのログは、標準ではハッシュ化されたPATと基本的な属性情報しか提供しません。エクサフォースはさらに先へ進みます。この例では、セマンティックデータモデルが次のことを行います。

• ログと構成データを取り込み、それらをセッション化して、リポジトリ、ワークロード、アクション、トークンなどのリソースを把握する
• 構成データから取得したトークンのスコープ情報でトークンリソースをエンリッチし、アクセス権と権限を把握する。これには、構成情報内のトークンスコープと、ログ内のハッシュ化トークンを含む実行時データを相関させることが含まれる
• cronジョブ、アドホックスクリプト、ユーザー起点の操作に使われるトークンを、過去の利用状況に基づいて分類する

そのうえでビヘイビアモデルは、単にアクションをユーザーへ帰属させるだけでなく、トークン自体に対する個別のベースラインも構築し、異常が検出された場合にはシグナルを生成します。PAT単位のベースラインを持つことで、さまざまな固有の検出や保護が可能になります。ユーザーが複数のPATを、自動化用途とアドホック用途で同時に使っている場合もあります。PATごとにベースラインを分けることで、両者が同時利用されていても誤検知を防げます。

この例では、6種類の異常、つまりシグナルが特定されました。特に重要だったのは、新しいASNから新しいリポジトリへアクセスしていた点です。

ノレッジモデルは、これらの異常をPATのスコープと照らし合わせ、アラートの重大度を判断しました。

従来の検出の柱は、「何かを見つける」という点では有効でしたが、コンテキストが不足していたため、全体像を把握するのに十分な情報を伴わないノイズの多いアラートを生みがちでした。エクサフォースは、IaaSやSaaSの生のデータを、エンリッチされたコンテキスト付きエンティティへと構造化するセマンティックデータモデルという強固な基盤から始めることで、高信頼のFindingを実現します。

私たちは、アクション、アイデンティティ、セッションなどにまたがる幅広いシグナルを監視し、最終的に実際のアラートへとつながる小さな逸脱も捉えます。独自のモデリングにより、GitHubやGoogle Workspaceのような見落とされがちなシステムを含め、IaaS環境とSaaS環境の両方を幅広くカバーできます。

シグナルは一貫性のある、複数次元にまたがるFindingへと集約され、トリアージエージェントが相反する異常を比較衡量して、本当に重要なものだけを抽出します。

その結果は何か。包括的なカバレッジ、より高度なトリアージ、そして誤検知の大幅な削減です。