「EDRは入っているのに、なぜ止められなかったのか？」
最近の大手企業のインシデントを見ると、技術の問題だけでなく“運用の仕組み”の弱さが被害の決定打になっているケースが目立ちます。
この記事では、EDRのモデル限界論から一歩離れ、人の判断に依存した運用設計の課題を整理し、実効性を高めるためのアプローチを提案します。
■ まず結論：ボトルネックは「検知の後」にある
EDRや各種センサーは“それなりに”検知しています。
にもかかわらず被害が出るのは、検知後の一連の運用（トリアージ→判断→封じ込め→復旧）が遅い／ムラがある／責任が拡散しているから。
要するに、“判断と実行”が人間任せになっているのが根本原因です。
■ よくある運用の落とし穴（実例ベース）
1) アラート疲れ（Alert Fatigue）
• 毎日数百〜数千件の検知。重大度の基準が曖昧で、重要アラートが埋もれる。
• 「誰がいつまでに対応するか」が決まっておらずMTTD/MTTRが伸びる。
2) トリアージと封じ込めの分業断絶
• SOCが検知し、CSIRTが判断し、現場ITが隔離…と手順が分断。
• その間に攻撃が横展開。“分かったけど止められない”状態に。
3) 例外運用の常態化
• 重要システムだからとEDR除外ルールが積み上がる。棚卸しされず“穴だらけ”に。
• 影響度が読めず、思い切った隔離判断が心理的にできない。
4) 資産・権限の可視化不足
• 台帳と実機が合わない。退職者アカウントやシャドーITが温床に。
• 横展開の範囲が把握できず、封じ込めの射程が曖昧。
5) 手作業運用に依存
• SIEM/EDRは入っているがSOARが未活用、自動隔離・自動遮断の連携がない。
• 夜間・祝日は判断者が不在で初動が翌朝になる。
6) テーブルトップ訓練不足
• 机上訓練やプレイブックが古い。「誰がスイッチを押すのか」が決まっていない。
• ベンダ・委託先との連絡網・優先順位が試されていない。
■ 何を変えればよいか：運用設計の“要点”
1 重大度と対応SLAを数値化
― MTTD/MTTR、封じ込めまでの分単位SLA、エスカレーションの“タイムボックス”を明文化。
2 自動化を前提に設計
― 事前合意した条件で自動隔離・自動遮断を許可（例外は年次棚卸し）。
3 プレイブックは“押すべきボタン”まで
― 具体的コマンド／API／切替手順を記載。権限委譲を明文化。
4 例外運用のガバナンス
― 期限付き例外＋レビュー。“永続例外”は禁止。
5 可視化の継続運用
― 資産・権限・ネットワークの継続インベントリ。検知と封じ込めのカバレッジを可視化。
6 夜間・無人時間の設計
― 人を起こさない前提で動く自動防御＋オンコール最小化。
■ まとめ：強いのはツールではなく“運用が回る仕組み”
EDRの優劣議論に陥るより、人の判断に依存しすぎない運用設計にこそ投資すべきです。
ホワイトディフェンダーはそのための“自動化とガバナンス”の土台。
「気づいたけど止められない」から、「気づいた瞬間に止まっている」へ。
■ 人依存を減らす「ホワイトディフェンダー」
WhiteDefenderは、“すぐに・簡単に”始められ、管理者不要でランサムウェア対策を実現します。
クラウドベースで提供されているため、初期導入もスムーズに行えます。
自社でサーバーを構築したり、複雑な設定を施したりする必要はなく、最小限の工数で本格的な防御体制を整えることが可能です。
IT人材が不足している環境でも、安心して運用を始められます。
まずは小さな一歩から。
“守れる体制”を気軽に始めてみることが、大きなリスクから会社を守る第一歩になります。