アイデンティティ脅威検知および対応（ITDR）市場のベンダーは、自社が幅広いカバレッジ、高精度な検知、シームレスなインテグレーション、そして迅速な対応を提供していると説明するでしょう。マーケティング上の訴求内容は、どのベンダーも非常によく似ています。
しかし、ITDRツールを評価する際に重要なのは、表面的な訴求内容ではなく、そのプラットフォームが実際に何を実現できるのか、そしてさらに重要なこととして、何ができないのかを理解することです。ベンダーの主張と、導入後にセキュリティチームが実際に把握する現実とのギャップこそが、多くのITDR評価が失敗する原因となっています。
本ガイドでは、特に重要な評価基準、各項目についてベンダーが一般的にどのような説明を行うのか、そして導入を決定する前に何を検証すべきかを解説します。まずは、アイデンティティ脅威検知および対応が対象とする領域や、このカテゴリが存在する理由についての基礎的な概要をご確認ください。
ITDRの評価が他のセキュリティツールの選定と異なる理由
多くのセキュリティツールの評価は、機能に重点を置いて行われます。一方で、ITDRの評価では、検知ロジックの品質や運用への適合性といった、より評価が難しい要素に注目する必要があります。
ITDR市場では、表面的に見ると機能面での差はそれほど大きくありません。多くのプラットフォームは主要なアイデンティティプロバイダーからデータを取り込み、ビヘイビアベースの検知を提供し、何らかのレスポンス連携機能を備えています。しかし、実際に差が現れるのは、検知ロジックが実際の攻撃パターンに対してどれほど効果的に機能するか、ツールがどの程度の運用負荷を生み出すか、そしてSOCチームの実際の運用プロセスにどれだけ適合するかという点です。その差は、場合によっては非常に大きなものになります。
以下の評価項目は、こうした違いを明らかにするために設計されています。
アイデンティティカバレッジの広さ
ベンダーの説明：「Active Directory、Okta、Azure AD、Google Workspaceなど、主要なアイデンティティプロバイダーをすべてサポートしています。」
確認すべきポイント：カバレッジに関する主張は、データ取り込みの観点ではほぼ正しい場合がほとんどです。しかし、本当に重要なのは、特定のアイデンティティプロバイダーからログを取得できるかどうかではなく、その環境向けに設計された専用の検知ロジックを備えているかどうかです。Oktaのログを取り込めることと、Okta特有の攻撃パターンに最適化されたビヘイビアベースの検知を提供できることは、まったく異なる能力です。
自社で運用している各アイデンティティ環境について、ベンダーに検知ルールや検知ライブラリの内容を具体的に説明してもらいましょう。Active Directoryには強力な対応をしていても、SaaSアイデンティティプロバイダーに対しては汎用的な異常検知しか提供していないプラットフォームでは、ハイブリッド環境において重大な検知ギャップが生じる可能性があります。
また、マシンアイデンティティへの対応範囲も明確に確認してください。サービスアカウント、APIキー、OAuthトークン、クラウドプロバイダーの認証情報は、人間のアイデンティティ監視を主目的として設計されたプラットフォームでは十分に保護されていないことが少なくありません。多くのベンダーは、マシンアイデンティティを独自の脅威モデルを持つ検知対象としてではなく、単なる対応項目のひとつとして扱っています。
検知の深さと精度
ベンダーの説明：「当社のビヘイビアAIは、すべてのアイデンティティイベントにおける異常なアクティビティを検知します。」
確認すべきポイント：ビヘイビアベースの異常検知は、もはや差別化要素ではなく、標準的に備わっているべき機能です。重要なのは、異常が検知された後に何が起こるかです。アラートには、対象アイデンティティの過去のアクセスパターン、ピアグループとの比較、関連する権限情報、不審なアクティビティに至るまでのイベントシーケンスが含まれているでしょうか。それとも、リスクスコア付きの生のイベントだけが表示され、調査はアナリストに委ねられるのでしょうか。
アラート数が多い一方でコンテキスト情報が乏しいプラットフォームは、本来解決すべきアラート疲れをむしろ引き起こします。導入を決定する前に、自社環境のデータを使用したPoC（概念実証）を実施し、週あたりのアラート件数と、アナリストがアラートを真陽性と判断するまでに要する平均時間を測定してください。これらの指標は、どのような機能一覧よりも検知品質を正確に示します。
優れたアイデンティティ脅威検知および対応ソリューションは、単に異常を検知するだけではなく、その異常の背景や文脈まで示します。「通常とは異なるログインを検知しました」というアラートだけでは、追加の調査が必要です。一方で、「このアカウントはインフラプロバイダーのIPアドレスからログインし、これまで一度もアクセスしたことのない3つの機密リソースに直ちにアクセスしました。また、その8時間前にパスワードリセットが実施されています」というアラートであれば、状況をはるかに明確に把握できます。
クロス環境相関分析
ベンダーの説明：「当社のプラットフォームは、お客様の環境全体にわたるアイデンティティシグナルを相関分析します。」
確認すべきポイント：クロス環境相関分析は技術的な実現難易度が高く、その能力が実際以上に語られていることも少なくありません。ベンダーには、具体的な攻撃シナリオを用いて説明してもらいましょう。例えば、攻撃者がアイデンティティプロバイダー経由で認証を行い、その後サービスアカウントの認証情報を使用してクラウド管理コンソールへアクセスし、さらに侵害されたアカウントがこれまで利用したことのないSaaSアプリケーションへアクセスするといったケースです。その際、プラットフォームはこれら一連のアクティビティを単一の関連付けられた調査として可視化できるでしょうか。それとも、チームが手動で関連付けなければならない3つの独立したアラートとして出力されるのでしょうか。
この違いは、実際の運用において非常に重要です。深刻な侵害インシデントの大半を占める多段階のアイデンティティ攻撃では、複数のシステムに痕跡が残されます。しかし、それぞれの痕跡を個別に見ると正常なアクティビティに見えることが少なくありません。各環境を独立した検知領域として扱うプラットフォームでは、攻撃を可視化するために必要な相関パターンを見逃してしまいます。
また、テレメトリデータの欠損にどのように対応するのかも確認してください。実際の環境では、すべてのシステムで完全なログ取得設定が行われているとは限りません。相関分析に必要なデータが不足している場合にプラットフォームがどのように動作するかを確認することで、その設計思想を深く理解できます。
レスポンス連携
ベンダーの説明：「当社は既存のアイデンティティプロバイダー、EDR、クラウドツールと連携し、自動化されたレスポンスを実現します。」
確認すべきポイント：インテグレーションの深さには大きな差があります。限定的なレベルのインテグレーションでは、アラート発生時にWebhookを送信するだけであり、その後の対応はすべてチームが手動で実施しなければなりません。一方、より高度なインテグレーションを備えたプラットフォームでは、調査コンソールを離れることなく、アイデンティティプロバイダーとの連携を通じて、セッションの無効化、アカウントの停止、追加のMFA認証要求（ステップアップ認証）、アクセスレビューのワークフローなどを直接実行できます。
ベンダーには、自社環境で特に重要となるレスポンスアクションを実演してもらいましょう。多くの組織にとって重要なのは、アイデンティティプロバイダー上でのセッション無効化、自動解除ワークフローを伴うアカウントロック、そして調査コンテキストを含めたチケット管理システムへのチケット作成です。これらの処理を実行するためにプラットフォームを離れる必要がある場合や、ツール外で手動作業が必要な場合は、その分の運用負荷も評価に含めるべきです。
アイデンティティ関連の脅威では、レスポンスの遅延は他の多くの攻撃カテゴリ以上に重要です。攻撃者は、最初のアイデンティティ侵害に成功すると、永続化を確立するために迅速に行動します。手動操作が3回必要で、さらに2つの管理コンソールを切り替えなければならないレスポンスワークフローは、封じ込めまでの時間を数分単位で遅らせます。アイデンティティ侵害のインシデントでは、その数分が重大な意味を持ちます。
マシンアイデンティティのサポート
ベンダーの説明：「当社はサービスアカウントや非人間アイデンティティをサポートしています。」
確認すべきポイント：マシンアイデンティティは、多くのITDRプラットフォームにおいて、マーケティング上の説明と実際の機能との間に最も大きな隔たりが存在する領域です。「サービスアカウントをサポートしている」という説明は、多くの場合、人間のアカウント向けに構築されたビヘイビアベースラインにサービスアカウントのアクティビティを含めているだけであり、その結果、検知精度が低下します。マシンアイデンティティの振る舞いは、人間のアイデンティティとは本質的に異なります。
優れたマシンアイデンティティ対応とは、サービスアカウント、APIキー、OAuthトークン、クラウド認証情報向けに専用のビヘイビアモデルを備え、それぞれのアイデンティティが実際にどのように悪用されるかを踏まえて最適化された検知ロジックを提供していることを意味します。具体的には、サービスアカウントによる異常なAPIコールシーケンスの検知、想定外のIPアドレス帯から利用されているOAuthトークンの特定、そして本来の利用範囲外の環境で使用されているクラウド認証情報の検出などが含まれます。
ベンダーには、マシンアイデンティティ専用のビヘイビアモデルを提供しているかどうかを明確に確認してください。その回答から、プラットフォームが非人間アイデンティティを脅威対象領域としてどの程度重視しているかを判断できます。
調査支援
ベンダーの説明：「当社の統合調査ビューにより、アナリストは必要な情報をすべて単一のコンソールで確認できます。」
確認すべきポイント：「統合」という言葉は、セキュリティ製品のマーケティングにおいて最も乱用されている表現のひとつです。ベンダーには、用意されたデモではなく、自社が指定した実際の調査シナリオを使って説明してもらいましょう。そして、アナリストが必要なコンテキスト情報を収集するために、何回プラットフォームを離れなければならないかを確認してください。例えば、ログデータを確認するためにSIEMへ移動し、アカウント履歴を確認するためにアイデンティティプロバイダーの管理コンソールを開き、さらにIPアドレスのコンテキスト情報を取得するために別の脅威インテリジェンスツールを使用しなければならないのであれば、そのコンソールは実際には統合されているとは言えません。
優れたITDR製品は、不審なアカウントに関する完全なアイデンティティコンテキスト（アクセス履歴、関連デバイス、ピアグループの行動、権限情報、および複数環境にまたがる相関イベントなど）を、アナリストが手動で情報を組み立てることなく提供します。日々の運用において、平凡なプラットフォームと優れたプラットフォームとの差が最も明確に表れるのが調査体験です。
また、調査ドキュメントの管理方法についても評価してください。アラートからチケットへのワークフロー、調査タイムライン、エスカレーション時の証跡パッケージ化などは、大量のアラート対応に追われるチームにとって非常に重要な運用要素です。
ベンダー評価時の質問
これらの質問は、RFP（提案依頼書）やPoC（概念実証）の評価プロセスで活用してください。標準的なデモでは表面化しにくい機能上・運用上の課題を明らかにすることを目的としています。
- 当社が利用している［特定のアイデンティティ環境］向けの検知ライブラリについて説明してください。この環境専用に設計された検知ルールはいくつありますか。また、どの程度の頻度で更新されていますか。
- 当社環境における多段階攻撃の調査事例を見せてください。デモ用データセットではなく、当社のデータを使用してください。アイデンティティプロバイダー、クラウドIAM、SaaSアプリケーションにまたがるイベントを、プラットフォームはどのように単一のタイムラインへ関連付けるのでしょうか。
- 類似する顧客環境において、監視対象アイデンティティ1,000件あたりの週間平均アラート件数はどの程度ですか。また、そのうち真陽性として検証されたアラートの割合は何パーセントですか。
- マシンアイデンティティにはどのように対応していますか。人間のアカウントと同じビヘイビアモデルを適用していますか。それとも、サービスアカウントやAPI認証情報向けに専用の検知ロジックを提供していますか。
- アカウント乗っ取りが確認された場合のレスポンスワークフローを実演してください。アラート発生から、侵害されたセッションの無効化、アカウントのロック、調査記録の作成までに必要なすべての手順を説明してください。また、そのうちどの手順でプラットフォームを離れる必要があるかも示してください。
- テレメトリデータが不完全な場合はどうなりますか。例えば、当社のOktaログに欠損がある場合、相関分析の精度にどのような影響がありますか。また、プラットフォームは検知結果の信頼度をどのように提示しますか。
- 誤検知の削減にはどのように対応していますか。どのようなチューニング機能があり、誰がチューニングを実施し、新規導入後に安定したアラート件数へ到達するまでにどの程度の期間を想定していますか。
- ［当社のITSMツール］とのインテグレーションでは、実際に何が行われますか。具体的には、調査コンテキストを含むチケットを自動作成するのでしょうか。それともWebhookを送信するだけで、ドキュメント作成は手動で行う必要がありますか。
評価時によくある失敗
主要なアイデンティティ脅威検知・レスポンス（ITDR）ソリューションを評価するセキュリティチームは、しばしば同じ過ちを繰り返します。最も影響が大きいのは、運用への適合性ではなく、機能の充実度だけで評価してしまうことです。豊富な機能を備えていても、アラート対応に追われる状況下でチームが十分に活用できないプラットフォームは、アナリストの実際の業務に適したシンプルなプラットフォームよりも劣る場合があります。
2つ目によくある失敗は、自社環境ではなくデモデータを用いてPoC（概念実証）を実施することです。アイデンティティのビヘイビアベースラインは、組織固有のアクセスパターンに基づいて構築されます。ベンダーが用意したデータセットでは優れた結果を示すプラットフォームであっても、実際のテレメトリデータに対しては期待どおりの成果を出せない場合があります。特に、サービスアカウントの利用パターンが特殊であったり、認証情報の共有が行われていたり、一部システムでログ取得が不完全だったりする環境では、その傾向が顕著になります。
評価は、自社のデータ、自社の環境、そして実際の脅威モデルに関連する攻撃シナリオに基づいて実施してください。
効果的なITDRプラットフォームに期待すべきこと
優れたアイデンティティ脅威検知・レスポンス（ITDR）ソリューションには、厳密な評価を行うことで明らかになる共通の運用特性があります。具体的には、アナリストが実際に処理可能なアラート件数、調査に要する時間を増やすのではなく短縮する調査コンテキスト、対応手順を増やすのではなく封じ込めまでの時間を短縮するインテグレーション、そして非人間アカウントを独立した検知対象領域として扱うマシンアイデンティティ対応です。
上記の評価基準は、プラットフォームがこうした特性を実際に備えているかどうかを明らかにするためのものです。単にそう主張しているかどうかを確認するためのものではありません。機能チェックリストや洗練されたデモだけを基準にITDRソリューションを選定すると、本番環境で期待どおりの成果を発揮できない高価なツールを導入してしまうことになりかねません。
特定のプラットフォームの評価段階にあり、これらの基準が実際の環境でどのように適用されるかを確認したい場合は、デモをリクエストし、自社の環境や脅威モデルに基づいて検証してください。
よくある質問（FAQ）
ITDRとIAMの違いは何ですか？
アイデンティティおよびアクセス管理（IAM）は、「誰が何にアクセスできるか」を管理する仕組みです。アクセス権限の制御、認証ポリシーの適用、ユーザーアカウントのライフサイクル管理などを担います。一方、アイデンティティ脅威検知・レスポンス（ITDR）はIAMの後段で機能し、アクセスが許可された後のアクティビティを監視して、アカウント侵害、不正利用、悪用を検知します。IAMは不正なアクセスを防止するための仕組みであり、ITDRは正規のアクセス手段が悪用されている状況を検知するための仕組みです。
組織に専用のITDRソリューションが必要かどうかは、どのように判断できますか？
最も明確な判断基準は、アイデンティティベースの攻撃パターンに対する検知・レスポンスの対応範囲が十分に確保されているかどうかです。具体的には、認証情報の窃取、アカウント乗っ取り、IAM設定ミスを悪用した権限昇格、サービスアカウントを経由したラテラルムーブメント、MFAの回避といった脅威への対応が含まれます。現在のセキュリティスタックでこれらの攻撃シナリオを確実に検知・対応できない場合、専用のITDR機能は実際のセキュリティギャップを補完します。特に、多数のSaaSを利用している組織、クラウドネイティブなインフラを運用している組織、またはハイブリッドなアイデンティティ環境を持つ組織では、こうしたリスクへの曝露が大きくなる傾向があります。
SIEMはITDRツールに置き換えられますか？
いいえ。SIEMは、さまざまなソースから収集したログデータを集約し、相関分析を行います。一方、ITDRソリューションは、アイデンティティデータに特化した専用の検知ロジックを適用し、アイデンティティ関連の脅威を検出・対応します。ITDRはSIEMと併用でき、強化されたアイデンティティアラートをSIEMへ提供したり、SIEMからより広範なコンテキスト情報を取得したりできます。一部のセキュリティプラットフォームでは両方の機能を統合して提供していますが、両者は互いに置き換えるものではなく、それぞれ異なる役割を担っています。
ITDRソリューションで最も重要な評価項目は何ですか？
最も重要かつ差別化要因となることが多いのは、クロス環境相関分析の能力です。また、この能力はマーケティング資料や一般的なデモだけでは正確に評価することが最も難しい要素でもあります。複数の環境にまたがるアイデンティティシグナルを関連付け、一貫した調査タイムラインとして可視化できるプラットフォームは、各データソースを個別に扱うプラットフォームと比べて大幅に優れた成果を発揮します。特に、複数のアイデンティティ境界をまたいで展開される多段階攻撃に対しては、その差が顕著に表れます。
