■はじめに
「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の優劣を議論するよりも先に、
人の判断に依存しすぎない運用設計に、どれだけ投資できているか
が問われるフェーズに入っています。
・ツールは“目”と“手段”を提供してくれる
・しかし、「気づいたあとにどう動くか」は設計しなければ変わらない
「気づいたけれど止められない」運用から、
「気づいた瞬間に止まっている」運用へ。
その差を生むのは、ツールそのものではなく、運用が回る仕組みです。