EDR и XDR часто внедряют с завышенными ожиданиями: кажется, что если система что‑то детектирует, значит, инфраструктура под контролем. На практике всё иначе. Злоумышленники отключают агентов, ломают телеметрию и используют LOTL‑техники и инструменты обхода, маскируясь под легитимную активность.
- 1. Введение
- 2. Как должна выглядеть рабочая модель EDR/XDR
- 3. Ошибка 1. Опора на один EDR‑инструмент
- 4. Ошибка 2. Потеря телеметрии для XDR
- 5. Ошибка 3. Нет связи между событиями
- 6. Ошибка 4. Неправильная архитектура (агентная vs безагентная)
- 7. Ошибка 5. Неполное покрытие инфраструктуры
- 8. Ошибка 6. Игнорирование LOTL‑атак
- 9. Ошибка 7. Слабая интеграция с SIEM и SOAR или её отсутствие
- 10. Ошибка 8. Нет кастомных правил детектирования и регулярного тестирования
- 11. Ошибка 9. Нет реакции на инциденты и недостаточная подготовка SOC‑аналитиков
- 12. Какие метрики эффективности важны при внедрении EDR/XDR?
- 13. Выводы
Введение
Время бокового перемещения в сети сократилось с часов до минут. Сегодня злоумышленнику достаточно 29 минут, чтобы закрепиться в инфраструктуре. А иногда утечка данных происходит всего за 6–10 минут — быстрее, чем аналитик SOC успеет среагировать.
На этом фоне компании внедряют EDR-системы (Endpoint Detection and Response). Они отслеживают происходящее на рабочих станциях, серверах и мобильных устройствах и поднимают тревогу, когда поведение выглядит подозрительно. XDR (Extended Detection and Response) собирает сигналы не только с конечных точек, но и из сети, почты, облака, IAM-систем (Identity and Access Management, управление идентификацией и доступом), — формируется более целостная картина происходящего.
Но сами по себе EDR и XDR атаки не останавливают. Они развиваются быстрее, чем срабатывает защита, и всё чаще строятся на обычных административных инструментах — PowerShell, WMI, встроенных утилитах Windows. Вредоносных файлов может не быть вовсе. На чёрном рынке продаются готовые наборы для обхода EDR стоимостью от 300 до 10 000 долларов, и ими активно пользуются.
Ещё одна проблема — низкий уровень внедрения. По данным ГК «Гарда», EDR/XDR используют всего 13 % российских компаний. Даже там, где системы развёрнуты, результат часто разочаровывает: алертов много, а реальные атаки остаются незамеченными.
Чтобы понять, почему так происходит, разберём ошибки, которые чаще всего снижают эффективность EDR/XDR.
Как должна выглядеть рабочая модель EDR/XDR
Рабочая схема строится на связке EDR, XDR, SIEM и SOAR. EDR собирает события с рабочих станций и серверов. XDR добавляет данные из сети, почты, облака и других источников. SIEM (Security Information and Event Management) объединяет эти данные и помогает выявлять взаимосвязи между событиями. SOAR (Security Orchestration, Automation and Response) берёт на себя повторяющиеся действия: блокирует подозрительные учётные записи, изолирует заражённые устройства и отправляет уведомления администраторам и службе безопасности.
В основе этой модели находится центр мониторинга и реагирования на инциденты (Security Operations Center, SOC), где работают аналитики разных уровней. Аналитики первого уровня обрабатывают поток оповещений и отсекают шум. Второй уровень разбирает инциденты и восстанавливает цепочку действий злоумышленника. Третий занимается проактивным поиском угроз (threat hunting). Руководитель SOC следит за процессами и координирует работу с бизнесом.
Если упростить, роли распределяются так: EDR и XDR фиксируют события, SIEM формирует целостную картину, SOC анализирует, SOAR выполняет стандартные шаги. Бизнес подключается, когда нужно принять решение по доступам или изменить политику безопасности.
Уровни зрелости EDR/XDR:
Уровень 1: агент установлен, события собираются, но процессы реагирования не выстроены.
Уровень 2: SOC принимает и обрабатывает оповещения.
Уровень 3: SIEM объединяет данные, и атаки становятся видны как единая последовательность.
Уровень 4: SOC переходит к поиску скрытых угроз, а детекторы подстраиваются под инфраструктуру.
Уровень 5: SOAR автоматически выполняет типовые действия: блокировку, изоляцию, уведомления.
Далее — разбор ошибок, которые чаще всего мешают этой модели работать эффективно.
Ошибка 1. Опора на один EDR‑инструмент
Во многих компаниях EDR воспринимают как основной элемент защиты. На практике агент работает внутри операционной системы (ОС), а значит, его можно отключить или вывести из строя. За последние годы появилось множество EDR-киллеров, которые выводят защиту из строя за секунды. Исследование ESET выявило почти 90 таких инструментов, разделив их на 4 группы.
BYOVD (Bring Your Own Vulnerable Driver — «принеси свой уязвимый драйвер») — злоумышленники загружают легитимный, но уязвимый драйвер и получают доступ к операциям на уровне ядра. 54 из 90 изученных инструментов используют этот подход, задействуя 35 разных драйверов.
Driverless-методы — техники, которые не требуют установки драйвера. Например, EDRSilencer блокирует сетевой трафик EDR-агента через встроенные механизмы Windows, а EDR-Freezе приостанавливает защитные процессы через штатную утилиту WerFaultSecure — и всё это без прав администратора.
Скриптовые киллеры (script-based) — это простые сценарии на PowerShell или cmd, которые завершают процессы EDR или переводят систему в безопасный режим, где защита не активна.
Антируткиты (anti-rootkits) — изначально такие утилиты (GMER, PC Hunter, HRSword) создавались для поиска скрытых угроз (руткитов) в ядре системы. Однако расширенные возможности позволяют использовать их и для отключения EDR. ESET относит к этой категории 15 инструментов, ещё 7 — к скриптовым вариантам.
Рисунок 1. Цепочка атак EDRSilencer (источник: Trend Micro)
Пример ошибки. Распространение EDR‑киллеров
В августе 2024 года группировка RansomHub использовала загрузчик EDRKillShifter, распространяемый по модели «вредонос как услуга» (Malware-as-a-Service). После проникновения в сеть он доставлял компонент, который отключал защиту через уязвимые драйверы (RentDrv2 и ThreatFireMonitor). Позже аналогичные техники применяли Medusa, BianLian и Play.
В тот же период RansomHub задействовала легитимный антируткит TDSSKiller от «Лаборатории Касперского». Утилита предназначена для удаления руткитов, но через командную строку может удалять и службы безопасности. Злоумышленники запускали её с параметром -dcsvc MBAMService, чтобы удалить службу Malwarebytes, а затем использовали LaZagne для извлечения учётных данных. Цифровая подпись TDSSKiller позволяла выполнить операцию без подозрений со стороны системы.
Рисунок 2. Схема атаки с использованием загрузчика EDRKillShifter (источник: ESET Research)
В феврале 2026 года зафиксировали инцидент, который начался с компрометированных учётных данных SonicWall SSLVPN, где не была включена многофакторная аутентификация (MFA). После входа злоумышленники развернули EDR-киллер на основе драйвера EnCase (EnPortv.sys). Его сертификат истёк в 2010 году, но Windows продолжала загружать драйвер, так как проверяет только наличие подписи.
Получив доступ на уровне ядра, вредоносные программы завершали процессы 59 популярных EDR и антивирусов, включая CrowdStrike, SentinelOne, Palo Alto Cortex и Microsoft Defender. В интерфейсе агент при этом отображался как активный, хотя фактически не работал.
Атаку остановили до запуска шифровальщика, но сам эпизод показал, что BYOVD-подход стал обычным инструментом в арсенале атакующих, а устаревшие драйверы — удобным способом обхода защиты.
Чем опасна ошибка
Когда EDR отключён, компания теряет видимость происходящего на конечной точке. Атака продолжается без сигналов: злоумышленники перемещаются по сети (lateral movement), собирают данные и готовят запуск шифровальщика. Об инциденте узнают только тогда, когда вредоносная программа уже запущена.
Ошибка 2. Потеря телеметрии для XDR
XDR опирается на данные, поступающие от EDR-агентов, почтовых шлюзов, сетевых сенсоров, облачных журналов и событий системы класса «управление идентификацией и доступом». Стоит одному из ключевых потоков пропасть — и общая картина распадается. Чаще всего выпадает именно EDR, и тогда XDR лишается сведений о процессах, скриптах, сетевых соединениях и действиях пользователя.
Когда данные с устройства перестают поступать, система продолжает работать, но видит только внешние сигналы: подозрительное письмо, обращение к странному домену, аномалию в облаке. Всё это остаётся набором отдельных эпизодов, которые не складываются в целостную картину атаки.
Пример ошибки. Атаки ClickFix и частичная видимость XDR
APT-группы из Северной Кореи (TA427), Ирана (TA450) и России (UNK_RemoteRogue, TA422) использовали технику социальной инженерии ClickFix. Жертве отправляли фишинговое письмо со ссылкой на поддельную страницу. Там пользователя просили пройти «проверку» или обновить браузер, а затем — нажать Win+R, вставить команду и выполнить её. После этого на устройство загружался PowerShell-скрипт, который ограничивал или отключал работу EDR-агента.
В такой ситуации почтовая система отмечает фишинг, XDR фиксирует обращение к подозрительному домену, но данные с конечной точки исчезают. Снаружи всё выглядит как «письмо + странный трафик», хотя на устройстве уже выполняются вредоносные скрипты, собираются учётные данные или устанавливается бэкдор.
Рисунок 3. Цепочки заражения TA427 ClickFix (источник: Proofpoint)
Чем опасна ошибка
Когда XDR теряет телеметрию с конечной точки, он перестаёт видеть ключевые этапы атаки: запуск скриптов, повышение привилегий, перемещение внутри сети, установку бэкдоров, подготовку к шифрованию или краже данных. Система опирается только на внешние сигналы, и SOC реагирует уже на поздних стадиях.
Проблему усиливает слабый контроль журналов: короткий срок хранения, отсутствие корреляции и возможность отключить логирование через вмешательство в механизм трассировки событий Windows (Event Tracing for Windows, ETW). В таких условиях восстановить цепочку атаки почти невозможно.
Ошибка 3. Нет связи между событиями
XDR даёт результат только тогда, когда события из разных источников складываются в единую цепочку. EDR фиксирует процессы и скрипты на конечных точках, почтовые шлюзы — фишинг, сетевые сенсоры — соединения, облако — входы и операции с учётными записями, а IAM — всё, что связано с доступом. Каждый компонент видит свой участок, и без корреляции эти фрагменты так и остаются разрозненными.
В отличие от ситуации с потерей телеметрии, здесь данные никуда не исчезают. Они просто не связываются между собой. XDR получает события, но не понимает, что одно стало продолжением другого. Поэтому фишинговое письмо, запуск PowerShell и необычный вход в облако выглядят как 3 несвязанных инцидента, хотя это части одной атаки.
Пример ошибки. Атаки MFA‑fatigue и отсутствие связи между сигналами
В атаках MFA-fatigue злоумышленники давят на пользователя, а не на защиту. После кражи пароля — обычно через фишинг или прокси-страницу — они отправляют десятки MFA-запросов, рассчитывая, что человек случайно нажмёт «Одобрить».
Каждый элемент инфраструктуры фиксирует только свой фрагмент:
- почтовая система отмечает фишинговое письмо;
- система класса «управление идентификацией и доступом» (Identity and Access Management, IAM) видит поток MFA-запросов;
- облако фиксирует успешный вход с нового устройства;
- EDR регистрирует запуск браузера и переход на поддельную страницу.
Если корреляции нет, XDR воспринимает это как набор отдельных эпизодов: «фишинг», «много MFA-запросов», «успешный вход». Ничего критичного по отдельности. Но вместе это классическая цепочка атаки: фишинг → кража пароля → давление через MFA-fatigue → вход в облако → дальнейшие действия — создание токенов, экспорт почты, изменение правил пересылки.
Чем опасна ошибка
Без корреляции XDR не выстраивает последовательность событий: кто инициировал действие, что ему предшествовало и что стало триггером следующего шага. Система теряет причинно-следственные связи, а SOC — контекст, который позволяет отличить обычную активность от атаки. Инцидент выглядит как набор мелких событий, хотя за ними стоит единый сценарий.
Рисунок 4. Пример «пуш-бомбинга» (источник: Krebs on Security)
Ошибка 4. Неправильная архитектура (агентная vs безагентная)
При выборе архитектуры компании часто смотрят на удобство развёртывания, а не на то, сколько реальных данных они в итоге получат. В результате решение оказывается либо слишком лёгким и почти слепым, либо тяжёлым и плохо управляемым.
Агентная модель даёт максимально подробную телеметрию: процессы, скрипты, драйверы, сетевые соединения, работу в памяти. Но для этого нужно установить агент на каждую конечную точку. В результате увеличивается нагрузка на инфраструктуру, а также иногда возникают конфликты с устаревшими системами и программами.
Безагентные решения разворачиваются быстрее и почти не затрагивают устройства. Но их поле зрения ограничено тем, что поступает через API, сетевые сенсоры и облачные журналы. Локальные изменения в операционной системе (ОС), запуск скриптов, работа с памятью — всё это остаётся за кадром. А именно там происходят ключевые этапы большинства атак.
Пример ошибки. Когда безагентный XDR не видит атаку
Scattered Spider (UNC3944) использует легитимные инструменты администрирования и социальную инженерию. По наблюдениям Rapid7, группа действует почти как штатный администратор: входы через VPN и систему единого входа (Single Sign-On, SSO), PowerShell, RDP, PsExec, изменение политик, создание новых учётных записей, работа с облачными ресурсами. Никаких эксплойтов, никаких сложных схем.
Именно здесь безагентный XDR начинает слепнуть. Он видит аномальный вход, смену MFA-метода, подозрительные операции в системе управления идентификацией (Identity Provider, IdP), но не замечает, что происходит на конечной точке. А там как раз и разворачивается атака: запуск PowerShell-скриптов, изменение локальных политик, подготовка к lateral movement, работа с памятью и конфигурациями.
В итоге SOC получает только верхний слой событий: кто вошёл и откуда. Что злоумышленник делает после входа — остаётся за пределами видимости.
Чем опасна ошибка
Архитектура должна соответствовать инфраструктуре и угрозам, а не удобству развёртывания. Если выбор сделан неправильно, система превращается либо в «слепой сенсор», который не замечает критичных техник, либо в тяжёлую платформу, за которой сложно ухаживать. В обоих случаях защита остаётся формальной.
Ошибка 5. Неполное покрытие инфраструктуры
EDR/XDR дают результат только тогда, когда видят всю инфраструктуру. Как только защита развёрнута только на серверах или только на ноутбуках, появляются зоны, через которые злоумышленники спокойно проникают в сеть и развивают атаку. Рабочие станции, облачные инстансы, виртуальные машины, мобильные устройства — всё это должно находиться под наблюдением. Иначе система теряет целые фрагменты событий, а SOC работает вслепую.
Пример ошибки. Атаки Akira через уязвимые VPN‑шлюзы и незащищённые устройства
В 2025 году группировка Akira использовала уязвимость CVE-2024-40766 в VPN-шлюзах SonicWall. Получив доступ к SSL VPN, злоумышленники переходили к внутренним системам и разворачивали EDR-киллеры. У многих компаний защита стояла только на серверах — рабочие станции, облачные инстансы и отдельные сегменты сети оставались без наблюдения.
После входа атакующие загружали легитимные драйверы Windows — rwdrv.sys (ThrottleStop) и hlpdrv.sys — и через BYOVD-атаку отключали EDR на серверах. Там, где покрытие было неполным, SOC видел лишь отдельные фрагменты. Реагировать приходилось уже на последствия, когда шифрование данных шло полным ходом.
В том же году Akira показала другой сценарий. Когда основной шифровальщик заблокировали на Windows-машинах, злоумышленники просто переключились на IoT-устройство — обычную Linux-веб-камеру, на которой не было агента. Получив удалённый доступ, они смонтировали сетевые ресурсы Windows и зашифровали файлы. EDR на управляемых устройствах даже не заметил начало атаки — точка входа находилась вне его зоны контроля.
Чем опасна ошибка
Достаточно одного незащищённого узла, чтобы вся инфраструктура оказалась под угрозой. Такой узел становится удобной точкой входа: через него злоумышленники перемещаются по сети, отключают EDR на серверах и готовят атаку.
Рисунок 5. Этапы атаки Akira с помощью веб-камеры (источник: S-RM)
Ошибка 6. Игнорирование LOTL‑атак
LOTL-атаки (Living off the Land) относятся к угрозам, которые сложно заметить. Злоумышленники не приносят в сеть вредоносные файлы, а используют штатные инструменты Windows. Их действия выглядят как обычная административная активность.
К таким инструментам относятся:
- PowerShell — загружает и выполняет скрипты напрямую из сети;
- WMI — запускает процессы на удалённых машинах;
- net use — помогает перемещаться по инфраструктуре;
- Rundll32 — маскирует запуск DLL-модулей под вызов системной библиотеки;
- PsExec — используется для удалённого выполнения команд;
- netsh — управляет сетевыми настройками и часто применяется в атаках.
По данным Bitdefender Labs, анализ более 700 000 инцидентов показал, что 84 % крупных атак используют легитимные инструменты для обхода защиты. Перекрёстная проверка по данным MDR дала почти идентичный результат: 85 % инцидентов задействуют LOTL-методы. При этом до 95 % доступа к внутренним утилитам оказывается избыточным, что открывает дополнительные возможности для злоумышленников.
Пример ошибки. LOTL-атака российских хакеров
В 2025 году российская APT-группа APT28 применяла LOTL-подход при атаке на инфраструктуру Украины. После получения доступа злоумышленники использовали certutil.exe — штатную утилиту для работы с сертификатами — чтобы загружать скрипты и перемещаться по сети. Дополнительно применялись PowerShell, wmic и schtasks, что позволяло выполнять действия, не вызывающие подозрений у многих систем безопасности.
Чем опасна ошибка
LOTL-активность внешне похожа на обычные административные операции. Если система опирается только на сигнатуры или базовые правила, события не классифицируются как подозрительные.
Без поведенческого анализа и корреляции данных из EDR, системы управления событиями и информацией безопасности (Security Information and Event Management, SIEM) и системы класса «управление идентификацией и доступом» (Identity and Access Management, IAM) SOC теряет ключевые этапы атаки: закрепление, сбор учётных данных, перемещение по сети.
Рисунок 6. Цепочка атаки APT28 с помощью утилиты Windows (источник: BleepingComputer)
Ошибка 7. Слабая интеграция с SIEM и SOAR или её отсутствие
EDR и XDR собирают телеметрию, но без SIEM и SOAR она остаётся в пределах отдельных систем. SIEM объединяет события из сети, почты, облака и системы класса «управление идентификацией и доступом» (Identity and Access Management, IAM), формируя общую картину. SOAR автоматизирует блокировку учётных записей, изоляцию устройств и отправку уведомлений.
Если интеграция отсутствует или работает частично, SOC получает только отдельные сигналы и вынужден реагировать вручную. На фоне высокой нагрузки это становится серьёзной проблемой. По данным Vectra AI, организации получают около 3000 оповещений в день, и 2/3 из них остаются необработанными. 76 % компаний называют «усталость от алертов» ключевой трудностью, а 73 % команд — ложные срабатывания.
Пример ошибки. Техника «EDR-on-EDR violence» (Bring Your Own EDR, BYOEDR)
Злоумышленники оформляют пробные версии легитимных EDR-продуктов, устанавливают их на уже скомпрометированные машины и настраивают так, чтобы новый агент подавлял установленный ранее. Для этого из политики убирают исключения и добавляют хеш процесса легитимного агента в блок-лист — формально это выглядит как обычное изменение настроек.
В ходе тестов исследователи обнаружили, что Cisco Secure Endpoint, например, способен отключать CrowdStrike Falcon и Elastic Defend без заметных признаков: агент прекращает работу и перестаёт отправлять телеметрию, но в интерфейсе продолжает отображаться как «активный».
Если SIEM не получает данные о состоянии агента, SOC не замечает, что защита фактически отключена.
Чем опасна ошибка
Без интеграции с SIEM и SOAR SOC теряет контекст. Атакующие могут отключать защиту, менять конфигурации и перемещаться по сети, пока инфраструктура выглядит «здоровой» и защищённой.
Ошибка 8. Нет кастомных правил детектирования и регулярного тестирования
Большинство платформ EDR/XDR поставляются с базовым набором сигнатур и поведенческих правил. Они распознают только самые распространённые техники: типовые PowerShell-команды, стандартные загрузчики, классические варианты Mimikatz. Но современные APT-группы давно ушли от таких шаблонов. Они меняют параметры, обфусцируют код, перекомпилируют инструменты, маскируют активность под легитимные утилиты — PsExec, WMIC, Rundll32, Regsvr32.
В итоге стандартные правила обеспечивают минимальное покрытие. Особенно когда атака выполняется в памяти и не оставляет файлов на диске. Система вроде бы работает, алерты есть, но реальная активность проходит мимо.
Чтобы система действительно обнаруживала угрозы, нужны собственные детекты под конкретную инфраструктуру, её процессы и особенности. Эти детекты необходимо регулярно проверять. Эту задачу решают Purple Team-упражнения — совместная работа «атакующих» (Red Team) и «защитников» (Blue Team). Красная команда воспроизводит реальные тактики, техники и процедуры (Tactics, Techniques and Procedures, TTP) конкретных группировок, а синяя — анализирует, что фиксирует XDR и какая активность остаётся незамеченной.
Нередко выясняется, что правило существует только формально: оно не распознаёт обфусцированный PowerShell, работу в памяти или сетевую активность из нетипичных процессов.
Дополнительное представление о пробелах дают ежегодные тесты MITRE ATT&CK Evaluations. Они показывают, какие техники детектируются полностью, какие — частично, а какие остаются без внимания. В 2025 году в тестировании участвовали 11 вендоров, а сценарии строились на TTP Scattered Spider и Mustang Panda. Результаты показали, что даже сильные решения оказываются неэффективными без адаптации и регулярных проверок.
Пример ошибки. Тест Purple Team без результата
В 2025 году UnderDefense проводила Purple Team-упражнение в крупной производственной компании с современным XDR-комплексом и полноценным SOC. На первый взгляд защита выглядела надёжной, но тест показал обратное.
Красная команда действовала как реальный злоумышленник: перемещалась по сети, атаковала учётные данные, пыталась повысить привилегии. Синяя команда должна была обнаружить эти действия с помощью SIEM и XDR. Однако большинство правил оставались в состоянии «по умолчанию», журналы собирались не полностью, события не коррелировались, а ключевые оповещения не доходили до SOC.
Имитация атаки прошла незамеченной. «Злоумышленники» получили права администратора домена. Защита конечных точек не охватывала системы управления инфраструктурой (Integrated Dell Remote Access Controller, iDRAC), а сетевая сегментация оказалась слабой. Детекты, которые считались настроенными, на практике не распознавали ни сканирование памяти, ни попытки получить дамп LSASS, ни DCSync, ни Kerberoasting — техники, которые встречаются в большинстве реальных атак.
Чем опасна ошибка
Без кастомных правил и регулярных проверок компания получает иллюзию защищённости. Система формально работает, алерты есть, но реальные техники обхода остаются невидимыми. SOC тратит время на шум, пропускает критичные события, а EDR/XDR превращаются в панель мониторинга, а не в инструмент обнаружения атак.
Рисунок 7. Результаты тестов MITRE ATT&CK Evaluations (источник: MITRE)
Ошибка 9. Нет реакции на инциденты и недостаточная подготовка SOC‑аналитиков
EDR/XDR-платформы формируют большой поток событий. Чтобы этот поток превращался в осмысленные инциденты, нужен понятный порядок реагирования: кто анализирует, кто передаёт информацию дальше, кто принимает решение о блокировке. Если таких процессов нет, а аналитики не умеют разбирать поведенческие цепочки, события остаются в консоли непрочитанными. Атака при этом продолжает развиваться, а SOC видит только отдельные эпизоды, не связывая их в единую последовательность.
Пример ошибки. Атаки Scattered Spider и LockBit
Группировка Scattered Spider (UNC3944) в 2024 году атаковала производственную компанию, используя социальную инженерию. Злоумышленники убедили техподдержку сбросить учётные данные руководителей и развернули виртуальную машину в VMware ESXi, чтобы скрыть активность от EDR.
Система фиксировала подозрительные RDP-подключения, запуск Mimikatz и повышение привилегий, но аналитики не связывали эти события между собой — не хватало знаний MITRE ATT&CK и опыта работы с поведенческими цепочками. Через несколько часов началось шифрование, и компания потеряла контроль над инфраструктурой.
Похожий сценарий наблюдался в атаке LockBit на инженерную компанию. EDR отмечал подозрительные RDP-подключения, запуск Mimikatz и выдачу прав администратора домена. Но цепочки реагирования не было: события не передавались дальше, решения о блокировке никто не принимал. Злоумышленники беспрепятственно перемещались по сети, и атака завершилась шифрованием рабочих систем.
Чем опасна ошибка
Отсутствие реакции и недостаток компетенций усиливают друг друга. Даже точные детекты бесполезны, если их некому интерпретировать и на них некому реагировать. SOC тратит время на шум, пропускает критичные сигналы, а EDR/XDR превращаются в набор уведомлений, которые не приводят к действиям.
Какие метрики эффективности важны при внедрении EDR/XDR?
Эффективность EDR/XDR оценивают не количеством алертов, а тем, насколько быстро система помогает обнаруживать и останавливать атаки. На практике используют несколько ключевых показателей.
- Время обнаружения (Mean Time to Detect, MTTD) — сколько проходит от начала атаки до её фиксации. Низкое значение MTTD означает, что SOC получает сигнал вовремя. Если показатель превышает сутки, реагирование фактически начинается уже после того, как злоумышленники закрепились.
- Время реагирования (Mean Time to Respond, MTTR) — промежуток между обнаружением и блокировкой или изоляцией. Это индикатор зрелости процессов. Когда MTTR измеряется днями, злоумышленники успевают развернуть ransomware. Интеграция с SOAR помогает сокращать MTTR за счёт автоматизации. Рабочий ориентир — менее 4 часов.
- Процент ложных срабатываний (False Positive Rate, FPR) — показывает, насколько система «шумит». На старте уровень может доходить до 90 %, но после адаптации под инфраструктуру его удаётся снизить до 4 % и ниже. Высокий FPR перегружает SOC и снижает доверие к системе.
- Покрытие конечных точек (Coverage) — доля устройств, на которых агент установлен и работает. Целевое значение — около 99 %. Любой пропуск создаёт точку входа для атаки.
- Уровень обнаружения угроз (Threat Detection Rate, TDR) — доля реальных угроз, которые выявила система. Этот показатель демонстрирует, какие техники остаются незамеченными.
- Эффективность автоматизации (Automation Rate) — процент инцидентов, обработанных автоматически. Чем выше доля автоматизации, тем меньше нагрузка на SOC и тем быстрее блокируются типовые сценарии.
- Среднее время подтверждения алерта (Mean Time to Acknowledge, MTTA) — сколько проходит от появления алерта до начала его анализа. Это показатель оперативности SOC и качества процессов.
- Процент пропущенных инцидентов (Missed Rate) — доля атак, которые система не заметила. Это один из самых критичных индикаторов: высокий Missed Rate означает, что защита работает формально.
Отдельно оценивают покрытие MITRE ATT&CK — какие техники и тактики система способна детектировать. В тестах MITRE ATT&CK Evaluations решения показывают от 40 до 80 % покрытия. Это не рейтинг, а проверка на соответствие реальным сценариям атак, но она хорошо демонстрирует, где остаются пробелы.
Выводы
EDR/XDR работают только тогда, когда вокруг них есть полноценная операционная среда: понятный порядок реагирования, подготовленная команда и регулярные проверки на реальных сценариях. Под зрелыми процессами понимают не набор документов, а последовательность действий: кто разбирает алерт, кто принимает решение, кто изолирует устройство, кто отвечает за восстановление. Такой подход позволяет реагировать быстро и без хаоса.
Не менее важна постоянная адаптация. Угрозы меняются, и защита должна меняться вместе с ними: Purple Team-проверки, обновление детектов под инфраструктуру, контроль статуса агентов, устранение слепых зон.
Если этим пренебречь, EDR/XDR остаются набором датчиков, которые видят только часть событий. Когда же настройки регулярно пересматривают и проверяют на реальных сценариях, они превращаются в устойчивую систему безопасности, способную противостоять современным атакам.
