Defender for Endpointの誤検知対応は、「Submit → IoC許可 → ASR監査 → 最後に除外」の順番を守ることが、セキュリティを下げずに業務を回す鍵です。除外設定はリスクをそのまま外すため、必ず限定スコープ・期限付き・棚卸しのセットで運用します。中小企業のひとり情シスでも、本稿のフレームを使えば誤検知に振り回されることなく、Defenderの保護機能を最大化できます。
誤検知は「除外して終わり」ではない
Microsoft Defender for Endpoint（MDE）は、振る舞い検知・機械学習・クラウド配信保護を組み合わせた強力なEDR/EPPですが、業務アプリ・社内開発ツール・自動化スクリプトを誤検知することがあります。誤検知に対して「とりあえず除外」を増やすと、除外がそのまま攻撃者の通り道になる典型的なアンチパターンに陥ります。本稿では、安全な範囲で誤検知を抑制する手順を解説します。
(1) ベンダーへの誤検知Submit → (2) カスタムインジケーター（IoC）で許可 → (3) ASRルールの監査モード調整 → (4) どうしても解消しない場合のみ除外設定。パス除外は最終手段です。
Step 1：アラートのトリアージ
Microsoft Defenderポータル → インシデントとアラート → 該当アラートを開く。確認項目は次のとおり。
- カテゴリ：Malware／LOLBin／Suspicious Activity／Initial Access など
- 検知エンジン：AntivirusEngine／BehavioralEngine／CloudDelivered／ASRなど
- プロセスツリー：親プロセス・コマンドライン・署名情報
- 影響範囲：何台で発生しているか（1台のみ ≠ 全社）
- 署名状態：実行ファイルのデジタル署名と発行元
署名済み・社内ビルド・かつ業務上正当な動作であれば誤検知の可能性が高い。逆に署名なし・%TEMP%以下・難読化PowerShellは正規の検知である可能性が高い。
セキュリティ対策は導入して終わりではなく、日々の運用と検知後の初動が成果を分けます。情シス365では Defender／Intune の運用も含めて、必要な時間数に応じた月額制（月12万円〜）でご支援しています。
情シス365（セキュリティ運用） を見る →Step 2：誤検知をMicrosoftにSubmit
「アクション」→「誤検知の送信」から、ファイルとアラートIDをMicrosoftに送信します。Microsoftはクラウドの判定を24〜72時間以内に再評価し、定義側で改善されるとすべてのテナントで一括解消されます。社内回避策（除外）を入れる前に、必ずSubmitを実施するのが定石。
Submit先：Microsoft Security Intelligence Submission（テナント外でも可）
Step 3：カスタムインジケーター（IoC）で許可登録
Submit後すぐに業務復旧したい場合、カスタムインジケーターでファイルハッシュ単位の許可リストを作るのが安全です。
登録手順
- Defender XDR → 設定 → エンドポイント → ルール → インジケーター
- 「ファイルハッシュ」タブで ＋追加
- SHA256ハッシュを入力（PowerShellの
Get-FileHashで取得） - アクションを「許可」、対象スコープを該当部署のデバイスグループに限定
- 有効期限を設定（無期限は推奨せず、3〜6ヶ月で見直し）
ファイルハッシュは更新で変わります。マイナーアップデートのたびに再登録が必要。署名証明書による許可のほうが運用負荷は低いですが、攻撃者が同じ証明書で署名したマルウェアにも許可が広がるリスクがあります。
IoCで制御できる種別
| 種別 | 用途 | 注意点 |
|---|---|---|
| ファイルハッシュ（SHA256） | 特定バイナリの許可／ブロック | 更新で変わる |
| IPアドレス | 通信先制御 | Network Protectionが必要 |
| URL／ドメイン | 業務SaaSの誤検知解消、不審サイトブロック | SmartScreen連動 |
| 証明書 | 署名済みアプリの許可 | 影響範囲が広い |
Step 4：ASRルールの監査モード調整
Attack Surface Reduction（ASR）ルールは強力ですが、業務マクロ・正規スクリプト・既存業務アプリを誤ブロックすることがあります。導入時の鉄則は「ブロックモードでいきなり有効化しない」。
監査モードでの計測
- Intune／Defender XDR でASRルールを監査に設定
- 2〜4週間運用し、Defender XDR → レポート → デバイスのASRルールレポートでブロック想定件数を確認
- 誤ブロック相当のイベントを抽出（カスタムKQL）し、業務影響を評価
- 必要ならASRルール除外（ファイル／フォルダ／プロセス）を最小範囲で追加
- ブロック想定が業務に影響しなくなったらブロックへ昇格
頻出するASRルールと誤検知の典型
| ASRルール | 典型的な誤検知 | 対処 |
|---|---|---|
| Officeアプリの子プロセス起動ブロック | 業務マクロからのcmd.exe呼び出し | マクロを廃止／リファクタが原則 |
| 難読化スクリプト実行ブロック | Pack済みのレガシーVBScript | 非難読化版に書き直し |
| WMIでの永続化ブロック | 運用監視ツールのWMIサブスクリプション | 除外プロセス指定 |
| USBから実行された未署名／信頼されてないプロセス | 業務USB配布の社内ツール | 署名するか、配布をUSB以外に変更 |
Step 5：パス／プロセス除外（最終手段）
IoC・ASRチューニングで解決できない場合のみ、Antivirus除外を設定します。除外設定は「最小限・限定スコープ・期限付き」が原則。
除外の安全な作り方
- パス除外：
C:\や%ProgramFiles%全体を除外しない。具体的なサブフォルダまで絞る - 拡張子除外：
.exe全体除外は厳禁。業務固有の拡張子に限定 - プロセス除外：プロセスからのアクセスを除外。ファイル自体は監視継続
- 適用範囲：Intuneのデバイスグループで該当部署のみ
- 有効期限：3ヶ月でレビュー（カレンダーリマインダー設置）
「C:\Users 配下を全除外」「powershell.exe プロセス除外」「.tmp 拡張子除外」は、ランサムウェアの代表的な配置・実行手段です。運用負荷を下げたいだけの除外追加は、攻撃者の利便性を上げることを忘れずに。
Advanced HuntingでKQLによる調査
誤検知が連続する場合、KQLで全社的なパターンを把握すると判断しやすくなります。
運用：誤検知レポートの社内ワークフロー
- ユーザーからの誤検知申告はTeamsフォームで受付（業務アプリ名／実行パス／日時）
- 申告から4営業時間以内に一次トリアージ
- 除外設定の追加は2名承認を必須化
- 四半期ごとに除外設定の棚卸し。期限切れは自動削除
- SOC／MSSP連携時は除外内容を都度共有
よくある質問
誤検知が出たらまず何をすべきですか？
いきなり除外を入れないことです。まずアラートのカテゴリ、検知エンジン（AntivirusEngine／BehavioralEngine／CloudDelivered／ASR）、プロセスツリーを確認してトリアージし、そのうえで「アクション」→「誤検知の送信」からファイルとアラートIDをMicrosoftへSubmitします。
Microsoftへの誤検知報告はどう処理されますか？
Microsoftはクラウドの判定を24〜72時間以内に再評価します。定義側で改善されればすべてのテナントで一括解消されるため、社内の回避策（除外）を入れる前に必ずSubmitすることが推奨されます。
すぐ業務復旧したい場合はどうしますか？
カスタムインジケーター（IoC）でファイルハッシュ単位の許可リストを作るのが安全です。Defender XDR → 設定 → エンドポイント → ルール → インジケーターから「ファイルハッシュ」タブで、PowerShellのGet-FileHashで取得したSHA256を登録します。
ASRルールはどう有効化すべきですか？
ブロックモードでいきなり有効化しないことが鉄則です。Intune／Defender XDRで監査モードに設定して2〜4週間運用し、ASRルールレポートでブロック想定件数を確認します。誤ブロック相当のイベントをカスタムKQLで抽出し、業務影響を評価してからブロックへ移行します。
まとめ
Defender for Endpointの誤検知対応は、「Submit → IoC許可 → ASR監査 → 最後に除外」の順番を守ることが、セキュリティを下げずに業務を回す鍵です。除外設定はリスクをそのまま外すため、必ず限定スコープ・期限付き・棚卸しのセットで運用します。中小企業のひとり情シスでも、本稿のフレームを使えば誤検知に振り回されることなく、Defenderの保護機能を最大化できます。