SIEMは、IPアドレス「203.0.113.42」からUTC 14:32:07に「eventType: user.session.start」というイベントが発生したことは把握しています。しかし、そのログ1行だけでは、そのユーザーが組織のエンジニアリング本部長であること、6つのSaaSアプリケーションで管理者権限を持っていること、さらにそのうち2つでは強力なMFAが設定されていないことまでは把握できません。また、そのIPアドレスが組織でこれまで確認されたことのないVPNプロバイダーのものであること、そのユーザーが1時間前にはニューヨークにいたこと、これからアクセスしようとしているS3バケットに本番データベースのバックアップが保存されていることも、このログだけでは把握できません。
SIEMが捉えるのは、1行のログです。セキュリティアナリストに必要なのは、その背後にある一連の状況を把握することです。
ツールが取り込む情報と、チームが脅威を判断し、対応するために必要なコンテキストとの間にはギャップがあります。このギャップによって、最新の脅威を検知できず、見逃す可能性があります。本記事では、なぜこのギャップが生じるのか、ログだけを基盤としたSIEMワークフローにはどのような構造的な問題があるのか、そして、そのギャップを解消するために何が必要なのかを解説します。
根本的な問題：コンテキストを把握できないこと
ここで問題としているのは、パフォーマンスやコスト、クエリ言語の制約ではありません。SIEMが、ログに記録されたエンティティが何を表しているのかを把握できているかどうかです。
SIEMが取り込むのは、発生したイベントをタイムスタンプとともに記録したログです。しかし、そのイベントに関わるユーザー、デバイス、APIエンドポイント、コードリポジトリ、クラウドストレージバケット、SaaSアプリケーション、Driveファイル、サービスアカウント、OAuthトークンには、それぞれの属性や相互関係、過去の履歴、セキュリティ態勢といった重要な情報があります。イベントのログを取り込むだけでは、こうしたセキュリティ上重要なコンテキストをすべて把握することはできません。
SIEMは、イベントに情報を付加してエンリッチしたり、アイデンティティを相互に関連付けたり、通常の行動パターンを学習してベースラインを構築することができます。問題は、こうしたコンテキストの一貫性と最新性を維持し、複数の脅威検知で再利用できる状態にするために、チームがどれだけの作業を行う必要があるかという点です。
一般的な企業環境に存在するエンティティと、それらの関係性を見てみましょう。
- アイデンティティ：従業員、業務委託者、サービスアカウント、APIキー、OAuthアプリ
- デバイス：ノートPC、サーバー、コンテナ、Kubernetesノード、モバイル端末、およびモバイルデバイス管理（MDM）の登録情報やアイデンティティプロバイダー（IdP）の設定から把握した、どのデバイスをどのユーザーが所有しているかという対応関係
- APIエンドポイント：自社サービスが公開している数百の社内・外部向けAPI
- コードリポジトリ：組織のソースコード、アクセス権を持つユーザー、変更内容
- クラウドリソース：S3バケット、Identity and Access Management（IAM）ロール、コンピューティングインスタンス、データベース
- SaaSリソース：Google Driveのファイル、Slackチャンネル、Jiraプロジェクト、Oktaアプリケーション
- ネットワークコンテキスト：ファイアウォールゾーン、プロキシポリシー、DNSドメイン
これらにはそれぞれ、設定、権限、他のエンティティとの関係性、過去の行動履歴があります。また、それぞれのエンティティだけでなく、それらの関係性も同様に重要です。MDMの記録から「デバイスXがユーザーYの所有するデバイスである」と把握できれば、ユーザーYが受信したフィッシングメールと、その3分後にデバイスXで確認されたマルウェアを関連付けることができます。こうしたユーザーとデバイスの対応関係が把握できていなければ、これらのイベントは別々のログストリームに記録され、互いに関連のないイベントとして認識されてしまいます。
SIEMが「ユーザーXがリソースYにアクセスした」というログを受信しても、そのログ1行だけでは、ユーザーXが管理者なのかインターンなのか、リソースYに個人を特定できる情報（PII）が含まれているのか、それともマーケティング資料なのか、ユーザーXが過去にリソースYへアクセスしたことがあるのか、また、ユーザーXのデバイス上でEDRエージェントが正常に稼働しているのかまでは把握できません。
こうした関連性が把握できていないと、必要なコンテキストを把握できなくなります。そして、それこそが、SIEMだけでは完結せず、チームによる追加の調査が必要になる根本的な原因の一つです。
コンテキストを把握できないことによる影響
1. すべてのアラートにコンテキストが必要
SIEMが「通常とは異なる場所からのログイン」というアラートを発生させた場合、アナリストは詳細を調査するために、まず別の5つのツールを開いて確認することがあります。このユーザーは誰なのか。どのような役割を担っているのか。管理者権限を持っているのか。MFAは設定されているのか。どのデバイスを使用しているのか。そのデバイスはセキュリティポリシーに準拠しているのか。ログイン後にどのような操作を行ったのか。
ログインイベントだけでは、これらすべてを判断するために必要な情報は得られません。こうしたコンテキストがなければ、SIEMは何が起きたかを把握できても、それがセキュリティ上重要かどうかまでは判断できません。管理者が通常とは異なる国からログインする場合と、インターンが同じことをする場合とでは、セキュリティ上の意味合いが大きく異なります。しかし、ユーザーの役割を考慮しないルールでは、どちらの場合も同じ重大度で同じアラートが発生する可能性があります。
アナリストは、アラートが発生するたびに複数のツールを横断して、不足しているコンテキストを手作業で収集・整理します。こうした作業が繰り返し発生する背景には、構造的な原因があります。脅威を検知するツールに、その脅威を評価するために必要な情報が不足しているということです。
2. アイデンティティ情報の分散
組織内の1人のユーザーが、以下のように複数のアイデンティティを持っている場合があります。
- Okta上の「
jane@acme.com」アカウント - GitHub上の「
jane.doe」アカウント - Slack上の「
U08ABCDEF」ユーザーID - AWSのロールセッションにおける「
arn:aws:sts::123456789012:assumed-role/JaneDev/jane」 - CrowdStrike上のデバイスユーザー
アイデンティティ解決が行われていない場合、SIEMはこれらを互いに関連のない識別子として扱います。JaneのOktaセッションが侵害され、攻撃者がJaneのAWS認証情報を使用してS3からデータを窃取した場合、SIEMはOktaとAWSという2つのデータソース間の関連性を見逃す可能性があります。これらを関連付けるには、Okta上のアイデンティティとAWSロールセッションを紐付ける必要があります。システムの組み合わせごとに手動で相関ルールを作成・管理してこの紐付けを行っている場合、新しいデータソースが追加されるたびに、管理すべきマッピングも増えていきます。
このようにシステム間を個別に紐付ける方法では、規模の拡大に対応することが困難です。20を超えるSaaSアプリケーション、複数のクラウドプロバイダー、数千台のデバイスに導入されたEDRを利用する組織では、アイデンティティのマッピングを維持・管理するだけでも、相当な作業が必要になります。
3. 人による操作とアプリによる操作の区別が曖昧になる
SIEMが「JaneがGoogle Driveから500個のファイルを削除した」ことを示すイベントを取り込んだ場合、その操作がJane本人によるものなのか、OAuthアクセス権を持つサードパーティ製のバックアップアプリがJaneに代わって実行したものなのかを区別できないまま、Janeによる操作として記録される可能性があります。
ユーザーが大量のファイルを削除している場合は、インサイダー脅威の可能性があります。一方、バックアップツールが想定されたスケジュールに従って同じ処理を実行しているのであれば、通常の動作である可能性があります。実際に操作を実行したアプリを特定する手掛かりがログに含まれている場合でも、その情報が記録される場所は統一されていません。たとえば、Google Workspaceではイベントパラメーター内のクライアントID、CloudTrailではアイデンティティやセッションに関するフィールド、Microsoft 365では異なる形式のレコード内のアプリケーションIDとして記録されることがあります。使用されるフィールドは、データソースやイベントタイプによって異なります。正規化されていない場合、こうした手掛かりとなる情報はデータソースごとに異なる場所に記録されたままになります。正確なフィールドパスが分かっていれば参照できますが、チームが検知ルールの作成に使用する共通スキーマには含まれません。
また、クライアントIDだけでは、それが何を示す識別子なのか判断できません。そのクライアントIDに意味を持たせるのは、アプリの設定情報です。具体的には、どのスコープが付与されているのか、管理者がテナント全体に対して同意したのか、それとも個々のユーザーが同意したのか、さらにアプリの発行元が検証済みかどうかといった情報です。これらはアプリの設定状態を示す情報です。SIEMがこうした設定情報を取り込み、関連付けていなければ、脅威検知に活用することはできません。
その結果、ユーザーのアイデンティティだけを基準に検知ルールが作成され、アプリの通常の動作を誤検知する一方で、侵害されたトークンを使用してユーザー名義で実行される攻撃を見逃す可能性があります。
4. リソースの実態を把握できない
SIEMが「arn:aws:s3:::customer-vault-2023/export.dat」に対するCloudTrailのGetObjectイベントを取り込んでも、そのイベントだけでは、オブジェクトに本番環境の顧客データが含まれているのか、それとも一般公開されているマーケティング資料なのかまでは把握できません。同様に、SIEMがGoogle Workspaceのファイル共有イベントを取り込んでも、そのイベントだけでは、ファイルに組織の財務予測が含まれているのか、それともランチメニューなのかまでは把握できません。
リソースの機密性、所有者、アクセス権限を判断するには、アクセスイベントだけでは得られないコンテキストが必要です。SIEMがこうしたリソースの状態を取得し、モデル化していなければ、その情報を脅威検知に活用することはできません。そのため、そのリソースがセキュリティ上重要かどうかを判断する作業は、アナリストが行わなければいけません。
5. APIエンドポイントが単なるURLとして扱われる
組織のアプリケーションでは、数百ものAPIエンドポイントが公開されています。その中には、認証を処理するもの、機密データを返すもの、内部からのアクセスに限定されているものがあります。生のログでは、SIEMは「/api/v2/users/550e8400-e29b-41d4-a716-446655440000/documents/export」のようなURLを認識します。エンドポイントディスカバリーが行われていなければ、このURLと「/api/v2/users/a1b2c3d4-ef56-7890-abcd-1234567890ef/documents/export」が、同じAPIエンドポイントを指していることを認識できません。また、ベースラインがなければ、そのエンドポイントが通常1分あたり10件のリクエストを受信すること、想定されるクエリパラメーターが「format」と「limit」であること、あるいは、そのエンドポイントでこれまで確認されたことのないパラメーターがリクエストに含まれていることも把握できません。
APIエンドポイントには、それぞれ固有のスキーマと通常のトラフィックパターンがあります。通常のトラフィックパターンからの逸脱を検知するには、エンドポイントごとにベースラインを構築する必要があります。URLをテキストフィールドとしてインデックス化するだけでは、こうしたモデルを構築することはできません。
6. ベンダーごとのデータ形式の違いが運用上の課題に
ログインイベントは、サービスごとに異なる形式で記録されます。Oktaでは「user.session.start」、Google Workspaceではログイン成功を示す「login_success」、Slackでは「user_login」、GitHubのセキュリティログでは「user.login」として記録されます。Microsoft Entra IDではサインインレコードが提供される一方、AWS CloudTrailではコンソールへのサインインが「ConsoleLogin」として記録されます。
これらのデータソースでは、JSONの構造、フィールド名、ネスト構造、さらにログインの成功・失敗を示す情報の定義がそれぞれ異なります。SIEMでは、こうしたデータを共通スキーマに正規化できます。正規化が行われていない、または不完全な場合、「不審なログイン」を検知するには、データソースごとに異なる検知ロジックが必要となり、ベンダーのスキーマ変更に合わせて継続的にメンテナンスする必要があります。
問題は、データ形式の違いだけではありません。共通のセマンティックモデルでは、誰が、どのサービスに、どの方式で認証を行い、その結果がどうだったのかといった、各イベントの意味を保持する必要があります。こうしたモデルによって、異なる操作を同じものとして扱うことなく、ベンダーが異なっても同じ検知ロジックを適用できるようになります。
7. 静的なルールは時間とともに有効性が低下する
静的なSIEMルールには、たとえば「10分以内にログイン失敗が5回を超えた場合にアラートを発生させる」「許可リストに含まれていない国からログインがあった場合にアラートを発生させる」といったものがあります。こうしたしきい値や条件は、その四半期に通常と見なされていた状況をもとに、担当者が一度設定したものです。
しかし、通常とされるアクティビティは変化します。企業が新しい国に拠点を開設することもあれば、チームが数百件ものAPIコールを生成するCI/CDツールを導入することもあります。また、ユーザーの役割が変われば、アクセスパターンも変化します。一方、ルールはこうした変化には追従しません。その結果、新たに通常となったアクティビティに対してアラートが頻発するか、逆に、しきい値が実際のアクティビティより高いままとなり、アラートがまったく発生しないこともあります。
SIEMでは、さらに高度な分析も可能です。行動分析のほか、カスタムベースラインを構築するための機能も用意されています。サマリーインデックスを作成し、直近の一定期間を対象にstreamstatsを実行したり、異常検知ジョブを設定したりできます。ただし、カスタム検知用のベースラインを構築するだけでも、相応の作業が必要になることがあります。対象となるエンティティや時間枠を決め、コールドスタートに対応し、状態を保存して最新の状態に保つ必要があります。さらに、そのベースラインが対象エンティティの共有モデルではなく、ベースラインを構築したクエリに紐付いている場合、別の検知を構築する際にも同じ作業が必要になります。
リスクは、一部の重要な検知にしか個別のベースラインが構築されず、それ以外の検知では、何年も前に設定されたしきい値がそのまま使われ続けることです。
こうした負担も、根本原因は同じです。エンティティの共有モデルがないため、フィールドの値だけを単独でベースライン化することになります。そのベースラインには、ユーザーの役割が先月変わったことや、そのアカウントがサービスプリンシパルであり、決まったスケジュールで動作することが想定されているといったコンテキストが含まれていません。
8. アラート疲れには構造的な原因がある
セキュリティチームは、大量のアラートに追われています。一般的には、「ルールが多すぎる」「しきい値が過敏に設定されている」といったことが原因として挙げられます。しかし、構造的な原因の1つは、検知エンジンが、そのアラートが重要かどうかを判断するためのコンテキストを持っていないことです。
検知エンジンが、そのユーザーが新規ユーザーで、まだベースラインが確立されていないことを把握していれば、そのベースラインに依存する検知を、十分なデータが蓄積されるまで保留できます。そのユーザーがすでに調査中であることを把握していれば、重複するシグナルを抑制できます。また、アクセス先のリソースが一般公開されているマーケティング用バケットであることを把握していれば、そのアクセスの優先度を、本番データベースへのアクセスより低く設定できます。
こうした優先順位付けの判断には、個々のイベントだけでは得られないコンテキストが必要です。こうしたコンテキストがなければ、アナリスト自身がコンテキストエンジンとなり、アラートを1件ずつ、何時間にもわたって、シグナルとノイズを手作業で切り分けることになります。
この問題を解決するために必要なこと
ルールを増やすだけでは、このギャップを解消することはできません。SIEMは、ログを取り込み、インデックス化し、検索するために構築されています。検知でコンテキストを一貫して利用できるようにするには、単にルックアップを追加するだけでは不十分です。
設定情報と学習済みの状態の取得。Janeが管理者であることを把握するには、IdPからJaneの役割に関する情報を取得する必要があります。あるバケットがPIIを含むものとして分類されていることを把握するには、AWSからその分類タグを取得する必要があります。あるAPIエンドポイントが通常3つのパラメータを受け取ることを把握するには、一定期間にわたってそのトラフィックを観測する必要があります。検知には、イベントだけでなく、こうした設定情報と学習済みの状態も必要です。
ノレッジグラフの構築。従業員はそれぞれ部署に所属しています。各部署には、クラウドアカウントへのアクセス権があります。それらのアカウントには、PIIを含むものとしてタグ付けされたストレージバケットがあります。こうした関係性を表すグラフがあれば、Janeによるそのバケットへのアクセスが通常のものなのか、それとも警戒すべきものなのかを判断するのに役立ちます。イベントをインデックス化するだけでは、こうした関係性を確立することはできません。
イベントをセマンティックモデルに正規化する。ベンダー固有のイベントを、その意味を表現するモデルに変換します。具体的には、誰が、何を、何に対して、どこから行い、その結果どうなったのかを表現します。この変換により、ベンダーが異なっても同じ検知ロジックを適用できるようになり、人、リソース、アクションという観点からイベントを分析できるようになります。
行動ベースラインの学習。ユーザー、デバイス、APIエンドポイントごとの特性に適応するモデルを構築します。複数のデータソースにまたがるベースラインを構築するには、共通のアイデンティティが必要です。どのイベントがそのユーザーに紐付くのかを把握できなければ、複数のシステムにまたがるユーザーごとのASNベースラインを構築することはできません。
調査結果を検知にフィードバックする。アナリストがアラートを誤検知と判断した場合や、ユーザーを高リスクと判定した場合、そのコンテキストをその後のイベントの評価方法に反映し、手動でルールを更新する必要がないようにします。
AI Agentの問題：Garbage In, Hallucinations Out
SIEMにAI Agentを追加するというアプローチには、魅力的な売り文句があります。「AIにアラートを調査させれば、アナリストが調査する必要はありません」というものです。しかし、その調査の品質は、AI Agentがアクセスできるデータに左右されます。AI Agentが生のログにしかアクセスできないのであれば、アナリストと同じコンテキストのギャップを抱えることになります。
AI Agentが「通常とは異なる場所からのログイン」アラートを1行のログだけで調査すると、ユーザーの役割、アクセス権、リソースの機密性、行動履歴といった情報が不足しています。こうした情報による裏付けがなければ、AI Agentは情報の不足を、もっともらしい推論で補ってしまう可能性があります。その推論が実際の状況を反映しているとは限りません。実際には、そのユーザーはNew York以外の場所から一度もログインしたことがないにもかかわらず、「このユーザーは複数の場所からログインしたことがあるため、このアラートは問題のない可能性が高い」と回答するかもしれません。その回答は、もっともらしく確信に満ちて聞こえます。しかし、実際には推測にすぎません。
ノレッジグラフにアクセスできるAI Agentは、より多くの根拠となる情報をもとに調査できます。ノレッジグラフに必要なデータが含まれていれば、AI Agentは、ユーザーのアイデンティティ、管理者権限の有無、MFAの設定状況、過去のログイン元の都市やASNを確認できます。さらに、同じセッションでアクセスされたリソースを特定し、それらの機密性を示すタグを確認するとともに、ユーザーのデバイスでEDRエージェントが正常に稼働しているかどうかを確認できます。また、在籍情報から、そのユーザーが在籍中なのか、最近退職または契約終了となったのかを確認できます。
AI Agentは、構造化された企業内の情報をもとに推論し、具体的なアイデンティティ、関係性、設定状態に基づいて、調査結果を裏付けることができます。こうしたコンテキストがあることで、アナリストはAI Agentの結論を評価する際に、その根拠となる情報を確認できます。
同じことはAgentic AIを活用したワークフローにも当てはまります。これは、複数のステップをつなぎ合わせて自動で調査を行うプレイブックです。コンテキストが収集・関連付けされていない場合、「ユーザーの役割を確認する」には、IdPへの別途問い合わせが必要になります。「リソースが機密性の高いものかを確認する」には、その分類情報を照会する必要があり、「このユーザーによる他のアクティビティを確認する」には、データソース固有の識別子を使って、複数のデータソースにクエリを実行する必要があります。各ステップで、追加のインテグレーション作業が必要になります。必要なデータがすでに収集、正規化、関連付けされていれば、ノレッジグラフでは、共有された関係性を通じて、こうした情報を照会できるようになります。
セキュリティ運用でAIから真の価値を引き出せるのは、AIがログだけでなく、実際の状況にもアクセスできる組織です。
次回の内容
これは単なる理論上の話ではありません。次回の投稿では、エクサフォースが生のログを目的に応じて設計されたセマンティックモデルへ変換し、検知に必要なコンテキストを付加する方法について詳しく解説します。
「ログを収集する」ことと「脅威を理解する」ことの違いは、まず、そのログが何を示しているのかを把握することから始まります。
次回：パート2 — 生のログからセマンティックインテリジェンスへ
