EDR-проект, который провалился, обычно провалился не из-за плохого продукта. Большинство внедрений, которые не дали результата, объединяет одно: решение развернули, но не выстроили процесс вокруг него.
Эта статья — разбор ошибок, которые инженеры и архитекторы ИБ совершают на практике при внедрении EDR. Не теория, а паттерны из реальных проектов.
Неполный охват инфраструктуры
Самая распространенная и самая опасная ошибка — установить агенты на «главных» хостах, оставив серые зоны.
Типичные пробелы:
- устаревшие ОС, которые не поддерживает агент (Windows XP, legacy-Linux)
- серверы под управлением специализированного ПО, куда «боятся» ставить агент
- подсети OT/ICS, изолированные от корпоративной сети
- временные серверы и виртуальные машины разработчиков
- хосты на нестандартных платформах (встроенный Linux, ARM-архитектура)
Атакующие находят непокрытые сегменты быстро. Серая зона всегда становится точкой входа или прыжковым хостом.
Решение: до развертывания составьте полный реестр хостов по типам ОС и ролям. Для хостов без поддержки агента определите компенсирующие меры — мониторинг сети, изоляция сегмента, агентлесс-наблюдение через гипервизор.
Режим «только мониторинг» без плана перехода к блокировке
EDR запускают в режиме аудита (мониторинг без блокировки) — это правильно для начального периода. Проблема начинается, когда этот период затягивается на месяцы или годы.
В режиме аудита EDR детектирует угрозы, но не блокирует. Аналитик получает алерт, пока атакующий продолжает действовать.
Установите конкретные критерии перехода к блокировке:
- уровень ложных срабатываний ниже заранее определенного порога
- покрытие критических хостов агентами выше согласованного процента
- процедуры обработки алертов отработаны командой
Переход к блокировке не обязан быть одновременным для всей инфраструктуры: начните с серверных сегментов, затем рабочие станции, затем специфические группы.
Слишком широкие или полностью отсутствующие исключения
Две противоположные ошибки, которые возникают одновременно в разных командах.
Первая — слишком широкие исключения. Команда привычно добавляет в whitelist целые директории (C:\Program Files\SAP\, /opt/oracle/) — и EDR слепнет в критических путях.
Вторая — полное отсутствие исключений. EDR генерирует сотни ложных срабатываний на легитимные инструменты администрирования (psexec, wmic, mshta в корпоративных скриптах), аналитики устают и перестают доверять системе.
Правильный подход: исключения точечные — по хешу файла или имени процесса, а не по директории. Каждое исключение документируется и пересматривается при обновлениях ПО.
Изолированный EDR без интеграции с SIEM
EDR, изолированный от остальной инфраструктуры ИБ, работает как дорогой антивирус.
Ценность EDR вырастает при интеграции с SIEM: события из EDR участвуют в корреляционных правилах, инцидент получает контекст из сети и AD, аналитик видит полную картину из одного интерфейса.
Не откладывайте интеграцию на «второй этап» — стройте ее параллельно с развертыванием агентов. Без SIEM-интеграции аналитики вручную строят картину атаки, переключаясь между несколькими консолями.
Нет процесса реагирования на алерты
EDR генерирует алерты. Кто их читает? В какое время? По какому критерию эскалирует? Что происходит с хостом во время расследования?
Без ответов на эти вопросы EDR становится источником шума, который команда научается игнорировать.
Перед запуском в продакшн зафиксируйте:
- кто дежурит и в какие часы
- playbook обработки алерта по уровням критичности (low / medium / high / critical)
- процедуру изоляции хоста и согласования с бизнес-владельцем
- порог эскалации на L2/L3 и во внешние структуры
Простой playbook в Confluence лучше, чем «все знают, что делать».
Недооценка объема хранилища телеметрии
Телеметрия EDR — это большие данные. Полноценный агент на активном хосте генерирует от нескольких сотен мегабайт до нескольких гигабайт в день. Умножьте на число хостов и горизонт хранения — 90 дней для расследования инцидентов это минимум по большинству методологий форензики.
Инфраструктуру хранения планируют заранее, а не после того, как диски закончились на третьей неделе работы. Оцените объем с запасом, учитывая пиковые нагрузки — бухгалтерский период, массовое сканирование, крупные инциденты.
Если консоль EDR облачная — уточните стоимость хранилища и политику удаления данных у вендора до подписания договора.
Пропуск обучения аналитиков
EDR — не «включил и забыл». Инструмент требует от аналитика понимания MITRE ATT&CK, умения читать цепочки вызовов процессов, навыков forensic-расследования.
Команды, которые не прошли обучение, делают одно из двух: закрывают алерты «не критично» без расследования — либо тратят на каждый алерт вдвое больше времени, чем нужно.
Обучение эффективнее всего на реальных сценариях: с симуляцией атак и разбором forensic-артефактов на практике. Теоретический курс без стенда дает знания, но не навык.
Отсутствие регулярных проверок покрытия и политик
EDR — не разовое внедрение. Инфраструктура меняется: появляются новые хосты, обновляются ОС, команда разработки разворачивает новые серверы. Если реестр агентов не синхронизировать с реальным состоянием инфраструктуры, покрытие незаметно деградирует.
Настройте автоматическую сверку: список активных агентов из консоли EDR против реестра активов ИБ. Расхождение — повод для ручного анализа.
Политики детектирования тоже устаревают. Новые техники атак появляются быстро; без регулярного обновления mapping MITRE ATT&CK система теряет покрытие по актуальным угрозам.
Частые вопросы
Сколько времени занимает полное внедрение EDR
Зависит от размера инфраструктуры и зрелости команды. Для организации с несколькими сотнями хостов реалистичный горизонт — от двух до шести месяцев: развертывание агентов, настройка политик, период аудита, интеграция с SIEM и переход к блокировке. Чем больше разнообразие ОС и специализированных систем, тем длиннее каждый этап.
Как убедить бизнес поставить агент на критический сервер
Фреймируйте риск иначе: не «мы хотим поставить агент», а «без агента этот сервер — слепое пятно, и если атакующий попадет туда, мы узнаем постфактум». Предложите пилот в режиме мониторинга без блокировки — это снимает опасения по поводу стабильности. Предоставьте данные по нагрузке агента на аналогичных серверах.
Нужен ли выделенный инженер для поддержки EDR
Для небольших инфраструктур (до нескольких сотен хостов) EDR администрирует тот же специалист, который отвечает за защиту конечных точек в целом. При масштабе от тысячи хостов и выше разделение ролей оправдано: один инженер занимается политиками и агентами, аналитики — расследованием алертов. Совмещение ведет к накоплению технического долга в конфигурации.
Как измерить, что EDR работает эффективно
Метрики, которые дают объективную картину: покрытие агентами (процент хостов с активным агентом), среднее время обнаружения инцидента (MTTD) в сравнении с историческим базисом, соотношение подтвержденных инцидентов к ложным срабатываниям (signal-to-noise), результаты red team или tabletop-учений. Смотрите на тренд, а не на точечное значение.
Что делать, если EDR нарушает работу прикладного ПО после развертывания
Первый шаг — перевести агент в режим аудита на конкретном хосте или группе. Собрать логи EDR и определить, какое правило или модуль вызывает конфликт. Как правило, проблема в слишком агрессивной политике перехвата или в ложном детекте легитимного процесса. Добавьте точечное исключение по хешу или имени процесса и зафиксируйте его в реестре исключений. Деактивировать агент полностью хуже, чем добавить исключение.
Практика на стендах BI.ZONE Cybersecurity Labs
Знание типовых ошибок — первый шаг к их предотвращению. Навык формируется только при работе с реальным продуктом в реальных сценариях.
На курсе Проектирование и внедрение BI.ZONE EDR вы проходите полный цикл: от развертывания агентов на гетерогенной инфраструктуре до расследования реального инцидента на изолированном стенде. Вы сталкиваетесь с конфигурационными сложностями и типовыми граблями в безопасной среде — до того, как они встретятся в продакшне.