セキュリティチーム向け ITDR automation のベストプラクティス

身元（Identity）ベースの攻撃は、数分で進行します。The Verizon 2025 Data Breach Investigations Report によると、侵害の60%には人的要素が関わっており、多くは侵害された認証情報と Active Directory へのアクセス経路を通じて進行します。

運用上のギャップは、検知であることはほとんどありません。認証情報への攻撃が始まると、アラートは数秒以内に発報されます。ギャップは「対応」です。というのも、その信号は、アナリストがそれを開くまで、何時間もの間トリアージキューに滞留するからです。

それを実行することができる速度よりも速くアラートを生成するプログラムは、フォレンジック（証拠保全）ツールです。 Identity Threat Detection and Response （ITDR）では、高い信頼度の検知閾値を満たした時点で、チケットの割り当てを待たずに実行される自動応答が必要です。

このガイドでは、効果的な ITDR プログラムの中核となる構成要素、オートメーションのための 7 つの実装ベストプラクティス、そして検知のみから自動応答へ移行する際にチームが直面する課題を扱います。

ITDR の自動化とは？

ITDR の自動化とは、高い信頼度の検知しきい値が満たされた瞬間に、アカウント無効化、プロトコル層のブロック、資格情報のリセットなどのアイデンティティ脅威対応アクションを、人の介入なしで実行する実践です。

ITDR は Active Directory と Microsoft Entra ID を監視し、アイデンティティに基づく攻撃の前兆となり、その攻撃を構成するシグナルを検出します。たとえば、認証の異常、特権アカウントの悪用、Kerberos チケットの悪用、そして資格情報の窃取を示すレプリケーション要求などです。

自動化とは、これらのシグナルを人のキューに回すのではなく、機械のスピードで即座にアクションを起こすことです。自動化がないと、ITDR はセキュリティチームがトリアージできるよりも速いペースでアラートを生成してしまいます。

The ReliaQuest 2025 Annual Threat Report によると、2024年には攻撃者が最短27分で横方向への移動（ラテラルムーブメント）を達成しました。

アラートの処理に数時間かかる手動のトリアージキューは、防御ではありません。単なるフォレンジックの記録です。自動化は、検知が発火した瞬間に事前定義された対応アクションを実行することで、そのギャップを埋めます。

自動化 ITDR プログラムの中核となる構成要素

完全な自動化 ITDR プログラムは、4 つの構成要素に支えられています。それぞれが次の要素を可能にします。検知シグナルが自動化レスポンスに受け渡されます。自動化レスポンスは正確なポスチャ基準値に依存します。そして、Security Information and Event Management (SIEM) と Security Orchestration, Automation, and Response (SOAR) の連携により、検知が発火したときにエスカレーション ワークフローが実行されます。

1. 自動化レスポンスにつながるリアルタイム検知

自動化レスポンスは、それをトリガーする検知の信頼性にのみ左右されます。検知レイヤーは認証イベントを監視し、

既知の攻撃手法に一致するパターンを対象に、Active Directory の複製トラフィック、Kerberos チケット要求、グループ メンバーシップの変更、および特権アカウントのアクティビティを監視します。

検知では、構造化され、信頼性の高いシグナルを生成する必要があります。これにより、すべてのイベントに対して人の確認を都度求めることなく、レスポンスの playbook がそのまま実行できる状態にします。

2. 自動化されたレスポンスとプロトコル層でのブロック

レスポンスの自動化は、検知のしきい値が満たされた場合に、事前に定義されたアクションを実行します。侵害されたアカウントの無効化、特定の Active Directory プロトコル操作のブロック、SOAR の playbook の起動、または再認証の強制などです。

プロトコル層でのブロックはさらに踏み込み、悪意のあるリクエストが完了する前に AD 通信レイヤーで攻撃を傍受（インターセプト）して止めます。

この機能により、すべての応答が人の判断を待つ検知・アラート型の導入と、成熟した自動化 Identity Threat Detection & Response (ITDR) プログラムを区別できます。

3. 自動化の前提条件としての Identity posture management

自動化された応答には、発動のための信頼できるベースラインが必要です。Identity posture management は、過剰な特権を持つアカウント、古い（有効期限切れの）特権アクセス、弱い Kerberos 設定、そして Active Directory の誤設定を継続的に特定することで、このベースラインを提供します。

きれいな姿勢（ポスチャ）ベースラインがないと、検知ルールは同じシグネチャに一致する良性の誤設定と、実際の攻撃を区別できません。その結果、自動化された応答は誤作動するか、無効のままとなります。

4. 自動エスカレーションのための SIEM と SOAR の統合

SIEM の統合により、クロス環境のコンテキスト付きのアイデンティティアラートを提供します。SOAR の統合により、その後のエスカレーションと対応のワークフローが自動化されます。

攻撃タイプ、影響を受けたアカウント、タイムライン、信頼スコアといった情報を含む構造化アラートをエクスポートする ITDR プラットフォームは、そのまま SOAR のプレイブックに投入されます。これにより、検知と対応の間にある手作業のトリアージ手順が不要になります。

生のログだけをエクスポートするプラットフォームでは、エスカレーションの各ステップごとに人手による解釈が必要になり、オートメーションの目的が失われてしまいます。

セキュリティチーム向け ITDR オートメーションのベストプラクティス

これら 7 つの実践により、検知が自動化された対応を引き起こす ITDR プログラムを構築できます。順番に進めてください。先行する各実践が、後続の実践が依存する土台を作ります。

1. 自動検出を設定する前に、アイデンティティの攻撃対象領域をマッピングする

検出ルールを1つも設定する前に、Active Directory と Microsoft Entra ID 全体で、すべての特権アカウント、サービスアカウント、管理者グループ、委任（デリゲーション）パスを洗い出してください。

このインベントリなしで調整した検出の閾値は誤検知（ファルスポジティブ）が高くなり、結果として自動応答の有効化がリスク過大になってしまいます。

分析担当者は信頼できないシグナルに対して自動化を展開することをためらい、プログラムは検出のみのモードにいつまでも留まります。攻撃対象領域（アタック・サーフェス）のマップが、検出シグナルを、人の確認なしで行動に移せるほど信頼できるものにします。

2. 自動応答を有効化する前に、高信頼（高シグナル）の検出ルールを設定する

シグネチャが明確で、誤検知（false-positive）率がほぼゼロの Active Directory の攻撃パターンから始めましょう： Kerberoasting, DCSync、pass-the-hash、そしてゴールデンチケット（golden ticket）の作成。

それぞれがプロトコル層で異なる指紋（fingerprint）を持ちます。たとえば、Kerberoasting では RC4 のダウングレードを伴う Service Principal Name（SPN）の列挙があり、DCSync ではドメインコントローラーではないアカウントからの不正な Active Directory レプリケーションがあります。

まずは信頼度の高いルールを優先的に展開し、異常なログイン時刻や不自然なグループメンバーシップの照会といった、信頼度の低い振る舞いベースのルールに広げる前に、それらが確実に動作することを確認してください。

調整（チューニング）されていない行動ベースのルールに基づいて自動応答を有効にすると、アラート疲労（alert fatigue）が起き、ほとんどのプログラムが手動トリアージ（manual triage）モードのままになります。

3. 各攻撃カテゴリごとに自動化された対応プレイブック（playbooks）を作成する

信号が高い（高優先度の）検知ルールごとに、最初のアラートが発報する前に自動応答を定義してください。Kerberoasting の playbook は、イベントを SIEM に記録し、影響を受けたアカウントを資格情報のリセット対象としてフラグ付けすべきです。

検知が信頼度のしきい値を満たした場合、同じ playbook は人の確認を待たずにアカウントを無効化するか、プロトコル操作をブロックします。

ルールごとに2つのしきい値を定義します。自動アクションを実行するための信頼度レベルと、人のレビューキューへルーティングするレベルです。まずは慎重に設定し、チームが検知の精度（検知の信頼性）を確認できたら、しきい値を厳格にしていきます。

検知チームとレスポンスチームの双方がレビューした共有 runbook に、playbook のすべての判断を文書化してください。

4. プロトコル層のブロッキングを導入して、攻撃の封じ込めを自動化する

Alert-and-wait は検知を通知システムに変換します。Protocol-layer blocking は検知を能動的な防御に変換します。これは、悪意のある Active Directory リクエストが完了する前にこれをインターセプトします。複製データを取得する前に DCSync の試行を停止し、さらにプロトコル層で golden ticket signature に対する Kerberos チケット要求をブロックします。

信頼度が最も高い検知ルールから先に、ブロックポリシーを設定します。監査モードでテストして、施行（エンフォースメント）が有効になる前に、正当な管理者のワークフローが誤ったブロックを引き起こさないことを確認してください。これは、ITDR プログラムを検知から施行（エンフォースメント）へ移行するためのステップです。

5. ITDR を SIEM および SOAR と統合して、エスカレーションのワークフローを自動化する

ITDR プラットフォームを設定して、SOAR playbooks が依存する 4 つのフィールドを含む構造化アラートを SIEM にエクスポートできるようにします：

1. 攻撃タイプ。
2. 影響を受けたアカウント。
3. イベントのタイムライン。
4. 検出の信頼度スコア。

アラートのフィールドを MITRE ATT&CK の技術 ID にマッピングし、手動の分類なしでプレイブックが正しい対応ワークフローにルーティングされるようにします。

生ログイベントではなく、これらの構造化されたシグナルをトリガーにする SOAR プレイブックを構築してください。複数シグナルの組み合わせは、まず人のキューへ振り分けることなく、自動的にエスカレーションして対応するべきです。

アイデンティティのアラートに、不審なアウトバウンド接続と privilege escalation が同じ 15 分間のウィンドウ内で組み合わさるケースは、代表的な（canonical）例です。

6. 自動検知の信頼性を保つために、アイデンティティのセキュリティ態勢（ポスチャ）の基準値を維持する

展開時にアイデンティティのセキュリティ態勢（ポスチャ）の基準評価を実施し、その後、ドリフト（逸脱）を検知するための継続モニタリングを設定します。ドリフトには以下が含まれます：

• サービスアカウントに新しい SPN が設定された。
• 文書化された変更ウィンドウ（documented change window）外で、ユーザーが Domain Admins に追加された。
• チケットなしで再有効化された古い管理者アカウント。

ドリフトは誤検知（false positive）を生み、分析担当者が自動応答への信頼を失う原因となり、プログラムを再び手動のトリアージへ押し戻します。

ベースラインが変わるたびに、検知ルールを見直して更新してください。新しいサービスアカウント、変更された委任パス、特権グループのメンバー構成の再編はいずれもルールの再調整が必要です。そうすることで、自動化が稼働中の環境を反映する条件に対して継続的に発火し続けます。

7. 定期的な検知から応答（detection-to-response）テストで自動応答の性能を測定する

四半期ごとのシミュレーション演習を計画します。ステージング環境に対して Kerberoasting ツールを実行し、次の3点を測定してください。検知が発火するかどうか、自動応答が設計どおりに実行されるかどうか、そして各ステップにかかる時間はどれくらいか。次の3つの遅延（latency）指標を追跡します：

1. 検知遅延：攻撃の開始からアラートが出るまでの時間。
2. 自動化遅延：アラートから自動アクションが実行されるまでの時間。
3. 残存する手作業の遅延：人の介入がまだ必要な手順に費やす時間。

これらの数値は、実際のプログラム性能を定義します。数秒でアラートを出す一方で、応答を人のキューで90分間保留しているプログラムは、不完全な自動化チェーンを実行しています。そのギャップを可視化するのがシミュレーション演習です。

よくある ITDR 自動化の課題

セキュリティチームが常に「検知のみ」の状態から抜け出せない理由は、主に3つの課題です。それぞれが別の理由で、自動化された対応への移行を止めてしまいます。

アラートの疲労により、チームが自動化された対応を信頼できなくなります

デフォルトの検知ルールが信頼度の低いアラートを大量に生成すると、チームは自動化アクションを発動させるほど、そのシグナルを信頼できないため、自動化への踏み出しをためらいます。

精度の低いルールは、ほとんどのイベントが誤検知であるようなアラートのキューを生み出し、アナリストに「そのプラットフォームを信じない」学習を促してしまいます。自動化はオフのままになり、すべての対応は手動のエスカレーションへ回され、その結果プログラムは運用上の目的を失います。

ハイブリッドな ID のカバレッジ・ギャップは、自動検知に盲点を生みます

多くの組織では、オンプレミスの Active Directory と Microsoft Entra ID の両方で ID を運用しています。オンプレミスの AD 検知が強力である一方、Entra ID のカバレッジが限定的な ITDR プラットフォームでは、ハイブリッドな攻撃経路が自動化の対応範囲の外に取り残されます。

クラウドとオンプレミスの ID 間で足場を切り替える攻撃者は、自動化ルールを1つも発火させずにそのカバレッジ・ギャップを横断でき、部分的なカバレッジが本当はそうでないのに信頼できる境界のように見えてしまいます。

検知と対応の間にある組織的な分断が、自動化の展開を妨げます

多くのセキュリティ プログラムでは、ITDR ツールを管理するチームとインシデント対応を実行するチームが別になっています。

この組織上のギャップは、チームが自動化プレイブックを一度も展開できない最も一般的な理由です。対応チームは、設定していない検知シグナルを信頼できず、検知チームは応答アクションを承認できないためです。

これを埋めるには、共有されたランブック、合意済みの信頼度（コンフィデンス）しきい値、そして自動化アクションが本番稼働する前に行う共同のサインオフ（承認）プロセスが必要です。

Netwrix は ITDR の自動化をどのように支援するか

Netwrix ITDR は、オンプレミスの Active Directory と Entra ID にまたがる、検知から対応までの全プロセスをカバーします。単一のソリューションで、振る舞い検知、プロトコル層でのブロッキング、継続的なアイデンティティのセキュリティ態勢管理を組み合わせ、チームが攻撃を特定したときとそれを止めるときのギャップを埋めます。

検知側では、Netwrix ITDR が認証パターン、Active Directory の複製要求、Kerberos チケットの挙動、そして特権アカウントの活動を監視し、通常の管理者の振る舞いと攻撃パターンを見分けるための行動ベースラインを構築します。

攻撃者がこれらの基準値を超えると、プラットフォームは攻撃タイプ、影響を受けるアカウント、イベントのタイムライン、信頼度スコアを含む構造化アラートを生成します。これは、自動的なエスカレーションと対応のために SOAR playbooks が必要とする正確な信号形式です。

対応面では、Netwrix ITDR は Windows および Active Directory のプロトコルスタックの最下層に統合され、悪意あるリクエストが完了する前にそれを遮断します。

ドメインコントローラーではないアカウントからの DCSync リクエスト、規模を伴う Kerberoasting の SPN 列挙、または pass-the-hash による認証の試行は、プロトコル層でブロック動作をトリガーし、人の承認を必要とせずに自動で実行されます。

このソリューションはまた、identity posture を Active Directory と Entra ID 全体で継続的にスコアリングし、誤検知の検出シグナルにつながり、さらに自動応答の信頼性を低下させてしまうような誤設定、過剰な権限、基準値のドリフトを可視化します。

攻撃スピードに合わせて応答する自動化 ITDR プログラムを構築する

アイデンティティに基づく攻撃に最も迅速に対応できる組織は、自動化によって検知から対応までのギャップを解消している組織です。検知から90分後に人間のアナリストへ届く Kerberoasting のアラートは、フォレンジック（事後調査）プログラムです。Active ITDR は検知が発火した瞬間に攻撃を止めます。

自動化には土台が必要です。つまり、クリーンなアイデンティティの状態（identity posture）のベースライン、既知の環境に対して調整された高い確度の検知ルール、そして合意された確度の閾値を備えた事前に作成された対応プレイブックです。このガイドの7つの実践は、それぞれの要素をその土台として構築していきます。

Netwrix ITDR はセキュリティチームにフルスタックを提供します。攻撃をマッピングする振る舞いベースの検知、攻撃を止めるプロトコル層でのブロッキング、そしてベースラインをクリーンに保つアイデンティティの状態（identity posture）管理です。

デモを依頼 Netwrix が Active Directory と Entra ID の両方で ITDR を自動化する方法をご覧ください。