Microsoft Defender for Endpoint の誤検知・検出漏れ対応で重要なのは、すぐに除外設定を増やすことではありません。まず検出ソースを特定し、アラートを分類し、必要な修復アクションを戻し、最後に「許可インジケーター」「ウイルス対策の除外」「Microsoft への分析提出」を使い分けることが基本です。
公式ドキュメント「Address false positives/negatives in Microsoft Defender for Endpoint」は、Microsoft Defender for Endpoint Plan 1 / Plan 2 を対象に、誤検知と検出漏れをどう扱うべきかを整理した管理者向けの実務ガイドです。対象OSは Windows とされています。 (Microsoft Learn)
この記事では、Microsoft Defender の誤検知・検出漏れ対応について、管理者が確認すべき影響範囲、設定変更の考え方、移行期限の有無、運用で失敗しやすいポイントを実務目線で整理します。
Microsoft Defender の誤検知・検出漏れ対応で確認すべき結論
今回のポイントは、Microsoft Defender for Endpoint の検出結果を「正しい・誤り」だけで処理しないことです。
誤検知とは、実際には脅威ではないファイルやプロセスなどが悪意あるものとして検出される状態です。検出漏れはその逆で、実際には悪意があるものが脅威として検出されない状態を指します。Microsoft は、こうした誤検知・検出漏れは Defender for Endpoint を含む脅威保護ソリューション全般で起こり得るものとして説明しています。 (Microsoft Learn)
管理者がまず押さえるべき結論は、次の4つです。
| 確認項目 | 実務上の意味 |
|---|---|
| 影響範囲 | Microsoft Defender for Endpoint Plan 1 / Plan 2 の Windows 環境が主な対象 |
| すぐにやること | アラートの検出ソースを確認し、真陽性・誤検知・無害な真陽性を分類する |
| 設定変更の考え方 | 除外を安易に増やさず、許可インジケーター・抑制ルール・Microsoft への提出を使い分ける |
| 移行期限 | このドキュメント単体では、特定日までの移行作業や強制変更は示されていない。運用手順の見直しが中心 |
特に重要なのは、誤検知が出たからといって自動調査と修復、EDR、PUA保護、クラウド保護をまとめて弱めないことです。公式情報では、自動調査と修復は完全自動化を推奨し、誤検知がある場合は機能をオフにするのではなく、許可インジケーターで例外を定義する考え方が示されています。 (Microsoft Learn)
まず理解したい「誤検知」と「検出漏れ」の違い
Microsoft Defender の運用では、「誤検知」と「検出漏れ」を同じトラブルとして扱うと対応を誤ります。
誤検知は、業務で使っている正規アプリ、社内開発ツール、スクリプト、業務用URLなどがブロックされるケースです。たとえば、自社開発の .exe ファイルが EDR や Microsoft Defender ウイルス対策によって悪意あるファイルとして扱われ、複数端末で隔離されるようなケースが該当します。
一方、検出漏れは、本来ブロックされるべきマルウェア、悪意あるスクリプト、不審なURL、攻撃者のツールなどが見逃されるケースです。こちらは業務停止よりも侵害拡大のリスクが大きく、Microsoft への分析提出や検出ルールの見直しを優先すべき場面です。
| 種類 | 起きていること | 優先すべき対応 |
|---|---|---|
| 誤検知 | 正常なファイルやプロセスが脅威として扱われる | 検出ソース確認、アラート分類、必要に応じた抑制・許可インジケーター・分析提出 |
| 検出漏れ | 悪意あるものが検出されない | ファイルやハッシュの分析提出、検出ルール・設定・保護レベルの見直し |
| 正しいが重要度が低い検出 | 実際には検出は正しいが、SOCで毎回対応する価値が低い | 真陽性として分類し、抑制ルールやSIEM側のノイズ削減を検討 |
現場でよくある失敗は、「業務影響が出たので除外する」という判断を最初にしてしまうことです。除外は保護レベルを下げるため、原因が EDR なのか、ウイルス対策なのか、カスタムインジケーターなのか、SmartScreen なのかを切り分けてから使うべきです。
最初に確認すべきは検出ソース
誤検知が疑われる場合、Microsoft は最初のステップとして検出ソースを特定することを推奨しています。代表的な検出ソースには、EDR、Microsoft Defender ウイルス対策、カスタム脅威インテリジェンス、SmartScreen などがあります。 (Microsoft Learn)
| 検出ソース | 典型的な状況 | 主な対応 |
|---|---|---|
| EDR | Defender for Endpoint の EDR アラートとして検出される | Microsoft への誤検知提出、EDR除外、アラート調整 |
| Microsoft Defender ウイルス対策 | アクティブモードのウイルス対策がブロックする | Microsoft への提出、ファイルハッシュの許可インジケーター、ウイルス対策除外 |
| カスタムTI | 管理者が設定したファイルハッシュ、IP、URL、証明書のインジケーターが原因 | カスタムインジケーターの管理・見直し |
| SmartScreen | サイトやネットワーク保護に関する検出 | SmartScreen やネットワーク保護検出の報告 |
CustomEnterpriseBlock | 自動調査と修復、カスタム検出、EDR in block mode、Live Response、PUA保護などが関係する可能性 | 機能ごとの原因確認、許可インジケーターや除外の検討 |
特に CustomEnterpriseBlock が表示される場合は注意が必要です。これは単一機能だけを示すとは限らず、自動調査と修復、Advanced Hunting 由来のカスタム検出ルール、EDR in block mode、Live Response、PUA保護など複数の機能が関係する可能性があります。 (Microsoft Learn)
グローバル環境では、地域ごとに異なるSOCやIT部門が個別に除外設定を追加しがちです。検出ソースを記録せずに例外を増やすと、後から「なぜ許可したのか」「どの国・どの端末群に影響するのか」が追跡できなくなります。最低限、検出ソース、対象ファイルやURL、影響端末、業務影響、承認者、期限をチケットに残す運用が必要です。
アラートは「誤検知」「真陽性」「無害な真陽性」に分類する
Microsoft Defender for Endpoint の誤検知対応では、アラートを抑制する前に分類することが重要です。Microsoft Defender ポータルでは、アラートを True positive、Informational, expected activity、False positive などに分類できます。分類は Defender for Endpoint の学習にも役立ち、長期的には誤検知や検出漏れの削減につながると説明されています。 (Microsoft Learn)
実務では、次のように判断すると迷いにくくなります。
| アラートの状態 | 判断基準 | 管理者の対応 |
|---|---|---|
| 真陽性 | 不審な挙動、侵害の痕跡、未知の実行ファイル、攻撃チェーンとの関連がある | 担当者を割り当て、調査を継続する |
| 誤検知 | 正規ファイル・正規プロセス・正規URLであることを確認できる | False positive に分類し、必要に応じて抑制、許可インジケーター作成、Microsoft へ分析提出 |
| 正しいが無害 | 検出自体は正しいが、想定済みの管理操作やテストである | True positive として分類し、必要に応じて抑制 |
| 判断不能 | 署名、ハッシュ、配布元、端末タイムライン、ユーザー操作の確認が不足している | いきなり除外せず、追加調査やサンプル提出を行う |
重要なのは、「うるさいアラートだから誤検知」という判断をしないことです。たとえば、管理ツールやリモート操作ツールは正規利用も攻撃利用もあり得ます。端末タイムライン、実行ユーザー、親プロセス、通信先、配布経路を確認し、業務上の正当性を確認してから分類します。
また、SIEMを使っている組織では、Defenderポータル側だけで抑制してもSIEM側に同じノイズが残る場合があります。公式情報でも、SIEMを利用している場合はSIEM側にも抑制ルールを定義するよう注意が示されています。 (Microsoft Learn)
修復アクションは Action Center で必ず確認する
誤検知が発生した場合、アラートの分類だけでは不十分です。ファイルが隔離された、プロセスが停止された、サービスが停止されたなど、すでに修復アクションが実行されている可能性があるためです。
公式情報では、自動調査や Microsoft Defender ウイルス対策によって、ファイルの検疫、レジストリキーの削除、プロセスの強制終了、サービス停止、ドライバーの無効化、スケジュールされたタスクの削除などが実行される場合があると説明されています。さらに、Live Response で実行されたアクションは元に戻せない点も明記されています。 (Microsoft Learn)
管理者は、Microsoft Defender ポータルの Actions & submissions > Action center から履歴を確認し、必要に応じて次の対応を行います。
| 確認する項目 | 見るべきポイント |
|---|---|
| Action type | Quarantine file、Stop service、Kill process など何が行われたか |
| 対象端末 | 単一端末か、複数拠点・複数国の端末に広がっているか |
| 対象ファイル | ハッシュ、パス、署名、配布元が業務上正当か |
| Undo の可否 | Action Center で元に戻せるか |
| 再発可能性 | 同じファイルが再配布・再実行された場合に再度ブロックされるか |
検疫ファイルは Action Center から復元できる場合があります。複数デバイスに同じファイルが隔離されている場合は、該当ファイルの複数インスタンスに対して取り消し操作を適用できる手順も示されています。 (Microsoft Learn)
ただし、復元は「クリーンと判断できた場合」に限るべきです。業務影響が大きいからといって調査前に復元すると、実際のマルウェアを再配置するリスクがあります。復元前には、少なくとも署名、ハッシュ、配布経路、実行元ユーザー、端末タイムライン、他のセキュリティ製品の判定を確認します。
除外設定は最後の手段として扱う
Microsoft Defender の誤検知対応で最も危険なのは、除外設定を短絡的に増やすことです。公式情報では、除外を定義すると保護レベルが低下すること、除外されたエンティティは検出されても修復アクションの対象外になることが説明されています。 (Microsoft Learn)
除外を検討する前に、次の順序で判断します。
| 優先順位 | 対応 | 使う場面 |
|---|---|---|
| 1 | アラート分類 | 誤検知か、正しい検出かを記録したい場合 |
| 2 | Microsoft への分析提出 | Defender側の判定改善が必要な場合 |
| 3 | アラート抑制 | 検出は残したいが、SOCキューのノイズを減らしたい場合 |
| 4 | 許可インジケーター | 特定のファイル、URL、IP、証明書を Defender for Endpoint 全体で扱いたい場合 |
| 5 | Microsoft Defender ウイルス対策の除外 | ウイルス対策機能に限定して、ファイル、フォルダー、拡張子、プロセス由来の誤検知に対応する場合 |
Microsoft Defender ウイルス対策の除外は、他の Defender for Endpoint 機能全体に適用されるわけではありません。ファイルを広く除外したい場合は、Defender for Endpoint のカスタムインジケーターと Microsoft Defender ウイルス対策の除外を使い分ける必要があります。 (Microsoft Learn)
現場での判断基準はシンプルです。特定の正規ファイルや証明書を Defender for Endpoint の保護・自動調査の文脈で扱うなら、まず許可インジケーターを検討します。ウイルス対策スキャンやリアルタイム保護だけで問題が起きている場合は、ウイルス対策除外を検討します。
許可インジケーターで対応できる対象と前提条件
Defender for Endpoint の許可インジケーターは、ファイル、IPアドレス、URL、ドメイン、アプリケーション証明書に対して作成できます。許可インジケーターは、次世代の保護と自動調査・修復に適用されると説明されています。 (Microsoft Learn)
| 対象 | 使う例 | 主な前提条件 |
|---|---|---|
| ファイル | 社内開発の .exe、業務アプリの .dll | クラウドベースの保護、対応クライアント、対応OS、ブロックまたは許可機能 |
| IP / URL / ドメイン | 業務システムのURL、社内利用SaaS、正規APIエンドポイント | ネットワーク保護のブロックモード、対応クライアント、カスタムネットワークインジケーター |
| アプリケーション証明書 | 社内開発アプリの署名証明書 | クラウドベースの保護、対応OS、最新の保護定義、.CER または .PEM |
ファイルの許可インジケーターでは、Microsoft Defender ウイルス対策のクラウドベース保護、マルウェア対策クライアント 4.18.1901.x 以降、Windows 10 バージョン 1703 以降または Windows 11、Windows Server 2016 以降などの要件が示されています。IP、URL、ドメインの許可インジケーターでは、ネットワーク保護がブロックモードで有効であること、マルウェア対策クライアント 4.18.1906.x 以降、Windows 10 バージョン 1709 以降または Windows 11 が要件として示されています。 (Microsoft Learn)
また、1テナントあたりのインジケーター数には 15,000 個の制限があるため、グローバル企業では命名規則と棚卸しが欠かせません。 (Microsoft Learn)
おすすめの運用ルールは、インジケーターごとに次の情報を必ず残すことです。
| 管理項目 | 記録例 |
|---|---|
| 申請理由 | 社内会計アプリの更新ファイルが誤検知されたため |
| 対象 | SHA-256 ハッシュ、URL、証明書、ドメインなど |
| 影響範囲 | APAC全拠点、開発部門のみ、本番端末のみ |
| 有効期限 | 30日、90日、次回アプリ更新まで |
| 承認者 | SOC責任者、システムオーナー、情報セキュリティ責任者 |
| 見直し条件 | ベンダー修正版リリース、Microsoft判定変更、アプリ廃止 |
期限のない許可インジケーターは、将来の攻撃面になります。社内アプリが更新されてハッシュが変わった後も古いハッシュを許可し続けると、不要な例外が蓄積します。
Microsoft Defender ウイルス対策の除外は Intune 管理が基本
Microsoft は、Microsoft Defender ウイルス対策の除外について、一般的には定義する必要はなく、必要な場合も慎重に設定し、定期的に見直すべきだと説明しています。また、除外の定義や編集には Microsoft Intune の利用が推奨されていますが、グループポリシーなど他の方法も使用できます。 (Microsoft Learn)
Intune で扱う主な除外は次の3種類です。
| 除外の種類 | 内容 | 注意点 | |
|---|---|---|---|
| Excluded Extensions | lib | obj のように拡張子を指定 | パスに関係なく該当拡張子へ広く適用されるため、影響範囲が大きい | |
| Excluded Paths | C:\Example | C:\Example1 のようにパスを指定 | フォルダー単位の除外は攻撃者に悪用されやすいため、範囲を最小化する | |
| Excluded Processes | 特定プロセスが開いたファイルを除外 | 実際のプロセスそのものを除外する設定ではない点に注意 |
「プロセス除外」という言葉は誤解されやすいポイントです。公式情報では、Excluded Processes は特定プロセスによって開かれたファイルの除外であり、実際のプロセス自体を除外するものではないと説明されています。プロセス自体を除外したい場合は、ファイルやフォルダーの除外を使う必要があります。 (Microsoft Learn)
実務では、除外設定を本番全体へ一気に展開せず、まず限定グループで検証します。特にグローバル展開では、タイムゾーンの違いで業務時間中に検出抑止が効き始める可能性があります。変更ウィンドウ、ロールバック手順、検証端末、監視条件を事前に決めておくべきです。
Microsoft への分析提出を運用に組み込む
誤検知や検出漏れは、社内の除外設定だけで解決しようとすると限界があります。Microsoft への分析提出を行うことで、判定の見直しや脅威保護機能の改善につながる可能性があります。
公式情報では、ファイル、ファイルレス検出、ハッシュを Microsoft に提出できると説明されています。ハッシュの提出では最大100個まで送信でき、IOCのソース情報が必要です。ファイルレス検出では MpSupportFiles.cab を作成して提出する手順が示されています。 (Microsoft Learn)
| 提出対象 | 使う場面 | 事前に集める情報 |
|---|---|---|
| ファイル | 正規ファイルが誤検知された、または不審ファイルが検出漏れした | ファイル本体、ハッシュ、検出名、端末情報、業務影響 |
| ハッシュ | 複数ファイルや既知サンプルをまとめて調査したい | 最大100件のハッシュ、IOCソース |
| ファイルレス検出 | 挙動ベース検出でファイルがない | MpSupportFiles.cab、端末情報、検出時刻、再現手順 |
ファイルレス検出の調査では、C:\ProgramData\Microsoft\Windows Defender\Support\MpSupportFiles.cab を生成して提出する流れが示されています。 (Microsoft Learn)
提出運用で大切なのは、SOCのチケットと Microsoft への提出履歴を紐づけることです。提出後の判定が変わった場合、どの抑制ルールや許可インジケーターを解除すべきか追跡できなければ、例外設定が残り続けます。
保護設定の見直しで確認すべき3つのポイント
誤検知が多い場合、個別の除外だけでなく、脅威保護設定全体も見直します。公式情報では、クラウドによる保護、PUA保護、自動調査と修復の設定を確認対象として挙げています。 (Microsoft Learn)
クラウドによる保護
Microsoft Defender ウイルス対策のクラウドによる保護は、既定では「未構成」と説明されていますが、Microsoft は有効化を推奨しています。設定変更には Intune やグループポリシーなどを使用できます。 (Microsoft Learn)
検出漏れが懸念される環境では、クラウド保護が無効または未構成のままになっていないか確認します。特に、オンプレミス中心の古い端末管理から Intune 管理へ移行した組織では、ポリシーの適用漏れが起きやすいポイントです。
PUA保護
PUAは、デバイスの動作を遅くしたり、予期しない広告を表示したり、意図しないソフトウェアを導入したりする可能性があるアプリのカテゴリです。Microsoft は、組織で使うアプリによっては PUA 保護設定が誤検知につながる場合があり、必要に応じて監査モードや一部デバイスへの適用を検討できると説明しています。 (Microsoft Learn)
業務アプリ、フリーウェア、開発ツール、リモート管理ツールを多用する組織では、PUA保護を全社に一律適用する前に、代表的な端末グループで検証したほうが安全です。
自動調査と修復
自動調査と修復、いわゆる AIR は、アラートを調査し、侵害を解決するための処理を実行する機能です。Microsoft は、誤検知が原因で AIR をオフにするのではなく、許可インジケーターで例外を定義し、適切な処理が自動実行される状態を維持することを推奨しています。 (Microsoft Learn)
これは運用上かなり重要です。誤検知対応のために AIR を止めると、SOCの手作業が増え、実際の侵害対応が遅れる可能性があります。必要なのは自動化を止めることではなく、自動化が誤った対象に作用しないよう例外設計を整えることです。
管理者向けチェックリスト
Microsoft Defender の誤検知・検出漏れ対応を見直す場合は、次の順序で確認すると実務に落とし込みやすくなります。
| チェック項目 | 確認内容 | 優先度 |
|---|---|---|
| 対象範囲 | Defender for Endpoint Plan 1 / Plan 2 の Windows 端末が対象か | 高 |
| 検出ソース | EDR、ウイルス対策、カスタムTI、SmartScreen、PUA、AIR のどれが関係しているか | 高 |
| アラート分類 | False positive、True positive、Informational / expected activity を正しく分類しているか | 高 |
| 修復アクション | Action Center で隔離・停止・削除などの履歴を確認しているか | 高 |
| 抑制ルール | DefenderポータルとSIEMの両方でノイズ対策が整合しているか | 中 |
| 許可インジケーター | 対象、理由、期限、承認者、見直し条件を記録しているか | 高 |
| ウイルス対策除外 | 拡張子・パス・プロセスの除外範囲が過剰でないか | 高 |
| Microsoft への提出 | 誤検知・検出漏れのサンプルやハッシュを提出する手順があるか | 中 |
| 保護設定 | クラウド保護、PUA保護、AIR の設定を確認しているか | 高 |
| 棚卸し | 古いインジケーターや除外が残っていないか定期確認しているか | 高 |
グローバル企業では、このチェックリストを地域ごとに分けるだけでなく、テナント共通の基準として管理することが重要です。国や拠点ごとに独自判断で除外を増やすと、セキュリティ水準がばらつき、監査時に説明できない例外が増えます。
移行期限と設定変更の考え方
今回の公式ドキュメントは、特定日までに設定変更を完了しなければならない移行告知というより、誤検知・検出漏れを適切に扱うための運用ガイドとして読むべき内容です。少なくとも指定ドキュメントの本文からは、この項目単体に対する明確な移行期限や強制的な切り替え日は確認できません。
ただし、期限がないから後回しでよいわけではありません。次のような状態に該当する組織は、早めに運用を見直すべきです。
| 状態 | 放置した場合のリスク |
|---|---|
| 誤検知が出るたびに除外を追加している | 攻撃者に悪用される例外が蓄積する |
| アラート分類をしていない | Defender の学習やSOCの分析品質が上がらない |
| SIEMとDefenderポータルの抑制がずれている | ノイズ削減が不完全になり、重要アラートを見落とす |
| Action Center の確認が運用に入っていない | 隔離や停止による業務影響を見逃す |
| Microsoft への提出手順がない | 同じ誤検知や検出漏れが繰り返される可能性がある |
| AIR を誤検知対策として無効化している | 実際の侵害対応が遅れる可能性がある |
設定変更を行う場合は、「全社一括」ではなく、検証グループ、限定展開、本番展開、棚卸しの順に進めます。特に許可インジケーターや除外設定は、追加時よりも削除時のルールを先に決めておくことが重要です。
実務で失敗しやすいポイント
Microsoft Defender の誤検知・検出漏れ対応では、機能そのものよりも運用ミスが問題になりやすいです。
誤検知を「業務影響」だけで判断する
業務影響が大きい検出でも、実際には正しい検出である可能性があります。たとえば、管理者が使うスクリプトやリモート管理ツールが、攻撃者にも使われる手法と似た動きをする場合です。
判断には、ファイルの署名、ハッシュ、親プロセス、通信先、実行ユーザー、配布元、発生端末の広がりを確認します。
除外範囲が広すぎる
C:\Tools や C:\Temp のような広いパスを除外すると、攻撃者がそこへファイルを置いた場合に保護が効きにくくなります。除外するなら、特定ファイル、特定ハッシュ、特定証明書など、できるだけ範囲を狭くします。
期限のない例外を作る
「一時対応」のはずの許可インジケーターや除外が数年残るのはよくある問題です。例外には必ず期限または見直し条件を設定し、定期的に棚卸しします。
Defender と SIEM の抑制ルールが一致していない
Defender側で抑制しても、SIEM側で同じイベントがチケット化され続けることがあります。逆に、SIEM側だけで抑制すると、Defenderポータル上ではノイズが残ります。SOCの作業キューをどこで見ているかに合わせて、抑制ルールを整合させます。
自動化を止めてしまう
誤検知が起きたからといって AIR を無効化すると、実際の脅威に対する初動対応が弱くなります。Microsoft の推奨どおり、自動化を止めるのではなく、許可インジケーターや適切な抑制で例外を管理するほうが現実的です。 (Microsoft Learn)
まず実施すべき次のアクション
Microsoft Defender for Endpoint の誤検知・検出漏れ対応は、個別のトラブル対応ではなく、SOC運用と端末管理の品質を左右する重要なプロセスです。
まずは、直近30日から90日のアラートを確認し、誤検知として処理したもの、抑制したもの、除外したもの、Microsoft に提出したものを棚卸ししてください。そのうえで、検出ソースの記録、アラート分類、Action Center の確認、許可インジケーターの期限管理、SIEM抑制ルールの整合性を運用手順に組み込みます。
特にグローバル環境では、拠点ごとの個別判断を減らし、テナント共通のルールで例外を管理することが重要です。誤検知を減らすことだけを目的にするのではなく、検出精度を維持しながら業務影響を最小化する。この考え方が、Microsoft Defender を安全に運用するための中心になります。
コメント