検出を正しく行うには何が必要で、なぜこれほど長い間間違っていたのでしょうか。
検出は元々、ログデータのリアルタイムルールを使用して構築されていました。2010 年代半ば、ユーザーおよびエンティティ行動分析 (UEBA) 製品では、主にユーザー、場合によってはリソースに焦点を当てた、外れ値を特定するための高度なベースラインとグルーピング手法が導入されました。多くの成熟したSOCチームにとって、これらのルールと異常の要素は、依然として検出アーキテクチャの柱となっています。
ただし、この方法には次の 3 つの重大なギャップがあります。
- 結果を構成(構成)データと関連付けることはできません
- 独自のクラウドセマンティクスを考慮していない
- コンテキスト評価は手動の検出後フェーズに任せるため、インシデント全体ではなく個別の検出にノイズが多くなります。
構成情報の組み込み
どちらの従来のアプローチにも欠けている要素の1つは、イベントデータと履歴データを構成データと相関させる機能です。このパズルのピースは、誤検知が過剰に発生しないようにし、アラートの影響を適切に評価するために不可欠です。現在、ほとんどのチームは、検出後にトリアージと分析の段階でのみこのデータを組み込んでいます。多くの場合、この情報は手動で取得する必要があり、解析が困難です。設定分析を検出ロジック自体に移すことで、検出の精度が高まり、チームが最も効率的に業務を行えるようになります。この構成データには以下が含まれます。
- 爆風半径評価: このユーザーは侵害されている可能性がありますが、どのようなリソースにアクセスできるのでしょうか。これは簡単ではありません。AWS などの一部の環境では、これを評価するには、どのロールが他にどのようなロールを引き受けることができるか、各ロールがどのリソースにアクセスできるかについて、一連のアイデンティティ分析が必要です。このような詳細な分析を行わないと、ID が実際にどのようなアクセス権を持っているかが誤検出されてしまう可能性があります。
- 適切な重大度評価: この EC2 インスタンスは異常動作しています。 そして 添付されたインスタンスプロファイルには管理者権限があり、これは非常に危険です。
- 偽陽性認識: 効果的な権限分析を行うと、このユーザーに突然非常に寛容なロールが付与されたことがわかりますが、機密アセットには付与されたロールよりも優先されるリソースポリシーがあるため、実際には問題なく、アラートを生成するべきではありません。
設定データを検出自体に組み込む試みがなされています。多くの製品が、ユーザーまたはエンティティフレームワーク、タグ、HR統合などの機能を提供して、このデータのさまざまな側面を検出できるようにしています。しかし、このような統合と更新を維持し、モデル内の幅広い構成データを網羅するには、非常に時間がかかり、困難であるため、多くのチームが構成分析を検出後の段階に移行することに頼ってきました。
クラウドとSaaS向けに構築
UEBA は、内部脅威のユースケースに端を発しています。これは主に ID を特定し、その典型的なアクティビティ/パターンをモデル化するために構築されました。このアプローチが実を結ぶにつれ、多くの企業が一部のリソース (多くの場合、個々の仮想マシン (VM) またはインスタンス) をモデル化するようになりました。しかし、多くの人が着手している IaaS 環境や SaaS 環境への移行に伴い、UEBA の概念を大きく変える必要があります。クラウドリソースはしばしば、一時的なものであるため、スケーリング要件が異なり、ベースラインと異常検出への新しいアプローチが必要になります。Kubernetes のワークロードやポッド、GitHub のリポジトリやアクションから Google ドキュメントまで、さまざまな IaaS と SaaS リソースにはすべて、まったく異なるモデリングが必要です。従来のアイデンティティでさえ、それほど単純ではありません。たとえば、AWS での役割は、人間と機械が混在して引き受けられる場合があり、モデリングがはるかに複雑になります。AWS のケースでは、アラートが発信元の ID ではなく、使用されたロールのみに起因する場合もあります。その結果、従来の UEBA のツールや機能では、クラウドやマルチクラウド環境で活動する現代の組織のニーズには及ばないことがよくあります。
検出はインシデントではない
検出ツールの役割は、疑わしいアクティビティのヒントを提供するだけでなく、アラートが環境の全体像に当てはまるようにすることです。例としては、重複するアラートを自動でグループ化したり、組織再編、合併、新しいツールの導入などのイベント時にビジネスコンテキストを組み込んだりすることが挙げられます。このようなコンテキストに対応する検出ツールの機能は、アナリストの利便性を高め、 調査の完全性これにより、ノイズの多い個々の検出が大幅に削減され、十分に文書化されたインシデントに変換されるためです。非常に高度なツールは、多くの場合、セキュリティ情報およびイベント管理 (SIEM)、セキュリティオーケストレーション、自動化、対応 (SOAR)、またはその他のシステムに負担をかけ、これらの手順の一部を実行するための第2レベルの関連づけ、集約、分析を行うため、システムのメンテナンスが煩雑で手作業になります。
Exaforceの効果的な検出とは、現代のクラウドとSaaSを中心とする企業向けに構築された、ルール、異常、構成データのバランスのとれた3つの要素です。ここでは、私たちのアプローチが伝統からどのように逸脱しているか、そしてなぜそれが重要なのかをご紹介します。

次のいくつかのセクションでは、Exaforceがデータ取り込みとモデリングへのAIを活用した新しいアプローチにより、現在のソリューションにおけるこれらの制限をどのように克服するかを探ります。Exaforceは、ログ、構成、IDデータを統合されたセマンティックレイヤーに融合し、その上に行動ベースラインと知識主導の推論を重ねることで、散在するシグナルを正確で忠実度の高いアラートに変換し、孤立した異常ではなく攻撃チェーン全体を明らかにします。
セマンティックデータモデル
品質データの確保
検出への私たちのアプローチは、Exaforceの3つのモデルアーキテクチャ、セマンティックデータ、行動モデル、知識モデルから始まります。それぞれが異なるコンテクストレイヤーを追加します。
さまざまなソースからイベントと構成データを取り込み、構造化されたイベントとリソースに変換します。イベントはセッションごとに整理され、場所、自律システム番号 (ASN)、期間などの状況や状況に応じたシグナルがセッションレベルで追加されます。また、セッションを連鎖させて、発信元のアイデンティティ、役割の引き受け方、役割間の行動、アクションシーケンスを把握することで、誰が何をしたのかをより詳細に分析できます。これにより、今後の検出評価に向けたデータの準備が整います。
リソースも同様の扱いを受けます。コンフィグをキャプチャし、リソースタイプを解析し、リソースを充実させ、リレーションシップグラフを作成します。また、Exaforce は設定の変更を時系列で収集するので、そうでなければ気付かれないような微妙ではあるが重要な変更を検出できます。また、各構成変更の影響を評価できるため、爆風半径の全面的な分析を効果的に実施できます。リソースの主要なサブセットであるアイデンティティには、たとえば次のような機能が追加されています。
- 人間と機械の分類: Exaforceのモデルは、アイデンティティタイプ、行動パターン、および役割引き受けパターンを分析して、アイデンティティを人間または機械として分類します。この分類は動的であるため、複雑なシナリオ (たとえば、人間が新しい ID を作成した後に、マシン ID によって実行されるスクリプトで使用される場合や、人間 ID とマシン ID の両方が共有する役割など) を考慮に入れることができます。アイデンティティーの人間と機械の分類が変わると、そのエンリッチメントやモデル化の方法も変わります。
- 効果的な権限分析: 推移的なロール引き受け機能に基づいてユーザーが持っている権限の全範囲を解釈し、リソースポリシー情報と重ね合わせます。
- アイデンティティーチェーン: どのロールが使用されたかだけでなく、どのアイデンティティが実際にこのアクションを実行したか
- 到達可能なリソース分析: この ID がアクセスできるリソース、アクション、アクセスレベル
- サードパーティ ID /アクセス: 第三者の身元を特定し、その行動と権限をより注意深く監視してください。
私たちのコンテキストにおけるリソースは一般的な構成です。AWS EC2 インスタンス、Kubernetes ジョブ、GitHub リポジトリから Okta ロールまで、どのようなものでもかまいません。このように構成を最初からモデル化することで、より完全な検出が可能になり、最初の柱である構成の基礎が築かれます。
行動モデル
Exaforceでは、異常な場所やまれなサービスの使用状況など、異常である可能性のあるすべてのディメンションをシグナルと呼びます。シグナルは弱い場合も強い場合もありますが、どちらも重要です。検出は、同じイベントまたはセッションで発生するシグナル (中程度の再現度の異常の集まりを表す) をグループ化することによって生成されます。これらのシグナルと検出は、ソリューションのルールとアノマリーの柱となります。
セマンティックモデルは、行動モデルでモデル化されるようにデータを設定します。たとえば、イベントをセッション化することで、個々のアクションのベースライン化にとどまらず、イベントとイベントパターンの組み合わせのベースライン化を進めることができます。同様に、ベースラインは対象となるオブジェクトに合わせてカスタマイズされます。たとえば、人間と機械 (前述のセマンティックデータモデルで識別される) は異なる方法でモデル化されます。機械は予測可能なパターンに従う傾向がありますが、人間ははるかに折衷的です。エンジニアと自動化スクリプトの両方が使用する役割など、共通のアイデンティティは、この微妙な違いを念頭に置いてモデル化されています。
当社では、次のようなさまざまな信号を単独で、または組み合わせてモデル化します。
- アクション (およびアクションパターン)
- サービス
- 時間
- 所要時間
- ロケーションと ASN (ソース間の比較を含む)
- 資源
これは、複数の信号を使用したExaforceの結果の例です。この例では、操作異常とサービス使用異常の両方が見られました。このユーザー Mallam は通常、この GetSecretValue アクションを実行しません。また、AWS 米国東部 2 リージョンでは通常アクションを実行しません。このことがきっかけで、Exaforce は検出を実行しました。


この多次元のアプローチは非常に重要です。単一の弱い信号で十分なことはめったにありませんが、複数の弱い信号が一緒になって十分な場合がよくあります。サポートされている幅広いリソースとログソースにわたるこのルールと異常の検出アプローチは、検出トリオの 2 つの柱となっています。
ナレッジモデル
検出の目標は、潜在的な侵害の兆候を見逃さないように完全にすることです。しかし、完全性があると、ノイズが発生する可能性があります。そこで、当社のナレッジモデルの出番です。
セマンティックデータモデルが実行されてシグナルが送信され、検出にグループ化されると、Exaforceはトリアージパイプラインを実行します。このパイプラインでは、検出をコンテキスト化し、組織固有のビジネスコンテキストを追加して、中程度の忠実度の検出結果を高忠実度の検出結果に変換します。このトリアージ・プロセスは、Exaforceとサード・パーティのアラートに対して同様に実行され、コンテキストをさらに拡張して、アナリストの注意に値するアラートのみが表示されるようにするのに役立ちます。この分析には、矛盾する要因を状況に応じて比較検討することが含まれ、検出段階の最後に行われます。たとえば、ユーザーに幅広い権限があるという事実と、実行されたアクションの重大度を比較検討することが含まれる場合があります。
このナレッジ・モデルでは、リソース/アイデンティティ構成データと、ルールおよび異常出力の比較が行われます。さらに、類似の調査結果に関する追加のコンテキスト、ユーザーから提供されたビジネスコンテキスト、ユーザー/マネージャーの検証応答などによって補足されます。
- 同様の調査結果が確認されています。クローズドの場合、その解像度がモデルへの入力として使用され、この知見が評価されます。まだ解決していない場合や処理中の場合は、モデルがグループ化します。いったんグループ化されると、関連する分析の関係とレベルが特定されるように、調査結果は重複、グループ化、または連鎖のいずれかに分類されます。
- ビジネスコンテキストルールにより、ユーザーは自由形式のデータをモデルに入力できます。これには、環境に関するコンテキストが含まれる場合があります。たとえば、これらのリソースは非常に重要であるか、このVPNを使用する場合はユーザーに関する情報が含まれる場合があります。ユーザーA、B、Cはすべて経営陣チームの一員であり、注意深く監視する必要があります。または会社に関する一般的な状況(たとえば、私たちは次の場所にオフィスを構える医療会社で、多くの場合、これらのサイト間を行き来するチームがあります)。この自由形式の入力により、初心者ユーザーは個々のアラートを手動で消音または抑制しなくても、重要なコンテキストについてExabotsに影響を与えたり、通知したりできます。
- Exabotsには、エンドユーザーからの検証を求めることができるスキルもあります。Exabot がユーザー検証やマネージャー検証が役に立つと判断した場合、その個人に Slack/Teams メッセージを送り、その回答を判断に影響力として利用することができます。
エクサボットはこの一連の情報を収集してナレッジモデルエージェントに渡し、これらの各要素を評価し、「誤検知」または「調査が必要」の判断を下します。これにより、基本的な検出がコンテキスト豊富なインシデントに変換されます。これらの分析はすべて、アラートが開いている間や進行中も継続的に実行されるため、環境が変化しても、推奨評価は最新の状態に保たれます。このデータを準備、構造化、要約することで、分析を実行する AI エージェントが最も正確になり、幻覚を最小限に抑えることができることに注意してください。
検出結果をユーザーに提示する前に初期知識モデルを実行すると、Exaforce による検出の忠実度が非常に高くなります。
例
ここにいるユーザーは、チューリッヒとマトランの2か所で次々と目撃されました。このセッションの途中での素早い位置切り替えは異常でしたが、位置自体は実際にはユーザーの以前の行動と一致しており、他の会社の従業員とも一致していました。実行されたアクションも、このユーザーの過去の行動と一致していました。そのため、トリアージエージェントは、異常なアクションを他の要因と照らし合わせて重み付けし、これを誤検知と判断することができました。トリアージ・エージェントは、企業固有のビジネスコンテキスト (この例では、チューリッヒのオフィスを指します) も備えていることにお気づきでしょう。(ビジネスコンテキストとトリアージについては、次回のブログで詳しく説明します!)

トリアージの後、Exaforceとサードパーティの両方の調査結果を集約された攻撃チェーンにグループ化します。これにより、アナリストは切り離されたイベントだけでなく、全体像を把握できます。
エクサフォース・イン・アクション:GitHub のサンプル
Exaforceのアプローチを実際に見てみましょう。
GitHub は重要なデータソースです。これには、企業の知的財産などの機密データが含まれており、次のような秘密が添付されている場合もあります。 CI/CD アクションの実行に対する許容度が高い。しかし、見過ごされがちです。
Exaforceはログと設定データを取り込んでアクティビティ情報を収集し、サプライチェーン攻撃に関連するリスクと脅威を特定します。たとえば、次のような用途があります。 パーソナルアクセストークン (PAT) は、CI/CD や開発者のワークフローで一般的に使用される認証情報です。GitHub ログには、初期設定でハッシュ化された PAT と基本的なアトリビューションが表示されます。エクサフォースはさらに進化しています。この例では、セマンティックデータモデルが
- ログと設定データを取り込み、セッション化してリポジトリ、ワークロード、アクション、トークンなどのリソースを理解します。
- 設定データから取得したトークンのスコープ情報でトークン・リソースを充実させ、アクセスと権限を把握します。これには、設定情報から得られるトークンのスコープ情報と、ログにハッシュされたトークンを含むランタイムデータを関連付けることが含まれます。
- cron ジョブ、アドホックスクリプト、およびユーザー主導型アクションに使用されるトークンを過去の使用状況に基づいて分類します
行動モデルは、単にアクションをユーザーに帰属させるだけでなく、トークン自体に合わせたベースラインを構築し、異常が見つかった場合はシグナルを生成します。PAT ベースのベースラインにより、さまざまな独自の検出と保護が可能になります。自動化とアドホック使用を組み合わせて、ユーザーが複数の PAT を同時に使用することがあります。PAT ごとにベースラインを区別することで、両方が同時に使用されている場合に誤検出が発生するのを防ぐことができます。
ここでは、6 種類の異常 (シグナル) を特定しました。最も重要なのは、新しい ASN から新しいリポジトリにアクセスしていることです。

ナレッジ・モデルは、これらの異常をPATの範囲と比較し、アラートの重大度を判断しました。

従来の検出ピラーは、物体の検出には強力でしたが、コンテキストが不足していたため、全体像を描くのに十分な詳細情報がないと、ノイズの多いアラートが生成されました。 エクサフォース 強固な基礎、つまり IaaS と SaaS の未加工データを豊富なコンテキストエンティティに構造化するセマンティックデータモデルから始めることで、忠実度の高い調査結果が得られます。
アクション、ID、セッションなどのさまざまなシグナルを監視して、実際のアラートにつながるわずかな逸脱も検出します。当社の特注モデリングにより、GitHub や Google Workspace などの見過ごされがちなシステムを含め、IaaS 環境と SaaS 環境の両方を幅広くカバーできます。
シグナルはまとまりのある次元横断的な知見にまとめられ、当社のトリアージ・エージェントは相反する異常を比較検討して、本当に重要なものだけを明らかにします。
その結果は? 包括的なカバレッジ、よりスマートなトリアージ、および誤検出の大幅な減少。

































