Привет, Хабр!

На связи, Михаил Чернышов, ведущий аналитик платформенных решений в компании «Гарда». Сегодня хочу поговорить про обратную сторону Луны систем EDR и обманчивое чувство безопасности, которое может зарождаться у заказчиков после покупки систем подобного класса.

Ниже я разберу некоторые тезисы из доклада Зоиэл Фрейре «Ransomware vs EDR: Inside the Attacker's Mind» и попытаюсь ответить на вопрос, почему метрики покрытия не всегда являются источником истины и какие ограничения следует учитывать, доверяя маркетинговым заявлениям.

Зоиэл Фрейре не просто теоретик. Он пишет малварь и профессионально обходит защиты. В рамках своего тура по конференциям он показывает живые демо обхода EDR на трех платформах — Windows, Linux и macOS, демонстрируя слабости используемых методов защиты.

Итак, поехали!

Слепые зоны EDR

Фрейре начинает свой доклад с неудобного вопроса, ответ на который звучит как пощечина всей индустрии ИБ:

«Полностью доверять своему EDR — это как спать с открытой дверью и называть это безопасностью».

По словам Фрейре, атакующие зачастую не «взламывают» EDR напрямую: они просто знают, куда не смотрит агент и как его обойти.

Как же это происходит?

  1. Поведенческие ограничения. EDR смотрит на эвристики и поведенческие паттерны. Но если злоумышленник грамотно использует легитимный инструментарий ОС (тот самый Living off the Land), агент посчитает это штатной работой системного администратора.

  1. Кроссплатформенные уязвимости. Фрейре разбивает миф о том, что «macOS не ломают». На современных Apple Silicon и macOS с их TCC (Transparency, Consent, and Control) EDR-агенты физически не могут внедрить свои хуки так глубоко, как в ядре Windows. В итоге защита на Mac часто работает в режиме «догнать», а не «предотвратить».

  1. Бесфайловые угрозы и нативная персистенция. Зачем писать экзешник на диск, если можно дергать PowerShell, WMI или нативные механизмы macOS/LaunchDaemons? Пока EDR анализирует файловую систему, код уже крутится в памяти и закрепился в планировщике.

Почему вендорам проблематично «закрыть всё»?

Этот вопрос так и напрашивается, когда смотришь демо Фрейре, где малварь обходит топовые EDR. Только проблема здесь не столько в качестве разработки, сколько в фундаментальных компромиссах и смене парадигмы защиты.

Ограничения сигнатур и восстание машин

Да, сигнатурный анализ — это проверенная временем технология, которая до сих пор работает, но с каждым днем всё хуже. Сегодня LLM генерируют уникальный полиморфный пейлоад и обфусцированный код за секунды, поэтому искать статичные байты в памяти — всё равно что ловить ветер в поле сачком. Каждая новая скомпилированная малварь уникальна, аналитику угроз нужно ее обработать, написать правило детектирования, а системе — получить эти обновления, при этом малварь не ждет. Вывод, как говорится, делайте сами.

Ад написания детектов и архитектурные качели

Казалось бы, где не спасают сигнатуры, должен спасать EDR, основная функция которого как раз в анализе поведения и контекста (цепочка событий, обогащение), но именно здесь система может буксовать.

Написание качественного детекта — ювелирная работа, требующая глубокой экспертизы, а охватить все угрозы фактически невозможно. Пока пишется и тестируется детект на одну технику обхода (что, несомненно, важно и необходимо), атакующие уже придумывают новую идею для атаки.

К тому же возникает архитектурная дилемма: где и когда принимать решение о блокировке?

И здесь возможны два полюса:

  1. Анализ на агенте. При таком подходе угроза блокируется мгновенно. Ложка дегтя в том, что агент сжирает CPU и, главное, не располагает полным контекстом. Он не видит, что происходит на соседних хостах или в длинной ретроспективе, и, соответственно, может принять неправильное решение.

  2. Анализ на сервере. Конечно, можно подключить мощные ML-модели, графы связей, но здесь встает проблема фильтрации и буферизации событий. Агенты шлют гигабайты логов, сервер складывает их в буфер, ждет обогащения из Threat Intelligence и сбора полной цепочки для подтверждения, что это точно атака. Итог: пока сервер «думает» и собирает пазл, ransomware уже шифрует бэкапы.

В результате система упирается в дихотомию: либо False Positive — блокируем всё и останавливаем бизнес, либо мучительное ожидание, пока безопасник разберет алерт вручную. Только вот ransomware работает 24/7, без выходных.

Серебряной пули здесь нет, так как архитектура должна учитывать различные гибридные сценарии со смещением либо в одну, либо в другую сторону.

Иллюзия покрытия: черный ящик вендора и маркетинговые обещания

Справедливости ради отмечу, что многие вендоры EDR-систем действительно создают качественные правила, охватывающие тысячи атак, с балансом нагрузки между сервером и агентом. Проблема в том, что заказчику проблематично проверить их реальную работоспособность, не говоря уже про то, чтобы управлять ими, подстраивая под требования бизнеса.

Что поделать, разработчикам приходится беречь свою интеллектуальную собственность от конкурентов и прятать контент правил фильтрации и логику детекта под грифом «коммерческая тайна». Тут-то и начинается магия метрик.

Метрика тщеславия

На встречах с клиентами менеджеры по продажам могут приводить внушительные цифры из серии «50 тыс. правил детекта в базе». Да, это весомый аргумент в пользу продукта, однако не единственное, на что следует обратить внимание.

Например, можно импортировать десятки тысяч простейших YARA-правил на малварь 2015 года и сделать тысячу триггеров на запуск бинарника с именем mimikatz.exe. Получается впечатляющая цифра, но сама по себе она мало что говорит о качестве детектирования. Атакующему достаточно изменить файл или вызвать его через нативный certutil, как эти тысячи правил оказываются бесполезными. Сотня сложных и глубоких поведенческих правил принесет в разы больше пользы, чем тысячи и миллионы примитивных устаревших сигнатур.

«Словом, помните: размер не всегда имеет значение качество важнее количества»

Ловушка матрицы MITRE ATT&CK

Покрытие матрицы MITRE ATT&CK остается важным маркером зрелости EDR-решения. Как минимум, вендоры, которые публикуют свои карты покрытий, демонстрируют понимание тактик злоумышленников.

Однако есть одно «но»: MITRE ATT&CK описывает концепцию атаки, а не ее реализацию. Даже стопроцентное покрытие, скажем, T1059 (Command and Scripting Interpreter) означает лишь то, что EDR-cистема отлавливает подобную технику в лабораторных условиях по базовым правилам — и не более того. В «дикой природе» же такую атаку можно выполнить десятками разных способов. Отловит ли EDR каждый из них в конкретной ситуации — вопрос открытый.

Словом, покрытие MITRE ATT&CK — это не гарантия защиты от всех угроз, а, скорее, фундамент решения, на который должны опираться дополнительные эвристики, поведенческий анализ и методы машинного обучения, помогающие справляться с вариативностью атак в боевых условиях эксплуатации.

Где вообще источник истины?

Самое время взглянуть на типичный корпоративный ноутбук или сервер. Там стоит EDR-агент, а также классический AV, так как этого требует комплаенс. По соседству прописался агент DLP, чтобы сотрудники не уносили базы. Добавим к этому какой-нибудь агент для удаленного администрирования, сканер уязвимостей и агент для инвентаризации ПО.

Опустим, что этот «зоопарк» пожирает оперативку и CPU, заставляя машину кряхтеть, а пользователя страдать. С точки зрения безопасности куда важнее то, что все эти агенты не обладают единым контекстом, не обмениваются информацией между собой и не работают в связке. EDR видит подозрительный скрипт, DLP замечает, что файл улетел в облако, сканер уязвимостей отлавливает еще не закрытый критический CVE на хосте…

Но ни один инструмент в одиночку не даст полной картины о происходящем в инфраструктуре и не позволит комплексно оценить, насколько инфраструктура защищена прямо сейчас. В итоге компания не может качественно управлять безопасностью, а ИБ-специалистам приходится судорожно переключаться между вкладками в браузере и постоянно латать дыры.

Допустим даже, что EDR покрывает «все серверы из Active Directory». Отлично, но что насчет тестового стенда, который DevOps поднял в облаке на выходные и забыл снести? И как быть с умными принтерами, IoT-камерами в офисе или legacy-серверами на Windows 2008 с базой 1С, о которых знает только уволившийся три года назад сисадмин?

Всё это вовсе не означает, что вышеупомянутый арсенал СЗИ бесполезен — совсем напротив. Но пока в инфраструктуре не реализованы нормальный Asset Discovery и автоматическая инвентаризация, любые разговоры о покрытии матрицы MITRE и глубине телеметрии остаются сотрясанием воздуха. Довольно проблематично будет правильно настроить СЗИ и оценить степень защищенности без понимания реальных границ своей «империи».

Атакующим же не нужно ломать корпоративный навороченный EDR на сервере БД. Они просто найдут забытую тестовую ВМ с дефолтным паролем, зайдут туда, поднимут легитимный агент удаленного доступа и начнут проворачивать свои темные дела, пока ваш «источник истины» даже не подозревает о существовании этого хоста.

Что делать?

Повторюсь, что доклад Фрейре — это не повод списывать EDR в утиль. Скорее, это стимул подойти к безопасности более системно.

Начните с активов. Прежде чем покупать еще один «умный» агент, стоит навести порядок в Asset Management. Сложно защитить то, о существовании чего не знаешь. Источник истины начинается с полного и актуального реестра всего, что имеет IP-адрес, а заканчивается актуальной картиной всего, что имеет ценность. И да, скорее всего, для этого тоже потребуются агенты :)

Помните о вариативности атак. Зеленые галочки в консоли EDR и закрашенные квадраты MITRE показывают знание вендора о существовании таких атак, что уже немаловажно. Однако это не гарантирует компании защиту от кастомного пейлоада. Важно добиваться полной прозрачности от вендора или тестировать решение самостоятельно, в том числе с привлечением внешних команд.

Используйте техники Threat Hunting в дополнение к EDR-системе. Автоматизация сильно упрощает жизнь ИБ-специалистам и повышает уровень безопасности, но не стоит полностью списывать со счетов и ручной поиск аномалий, особенно если используете узкоспециализированные решения, не имеющие взаимного обогащения контекстом.

Учитывайте борьбу ИИ против ИИ. Раз малварь пишется нейросетями за минуты, детекты тоже в идеале должны генерироваться автоматически. Пока это не так, главным остаются скиллы аналитиков, которые понимают принципы работы ОС и злоумышленников, а также инструменты и информацию о сети, которые вы им предоставляете.

Диверсифицируйте защиту, подходите к безопасности системно. EDR — это только один слой. Его следует дополнить поведенческим анализом на уровне сети, Honeypots, строгим контролем прав (привет, Zero Trust!) и регулярными пентестами. Сетевой уровень, к примеру, можно закрыть также с помощью решений класса NDR, а защиту внешнего контура дополнить WAF и Anti-DDoS.

Пришло время признать очевидное: автоматизированные инструменты не защитят на 100% от угроз без понимания образа мышления злоумышленника и жесткого контроля над своими активами.

Продолжая метафору Фрейре, если вы спите с открытой дверью (а закрыть ее полностью невозможно в современных реалиях), то хотя бы знайте, сколько комнат в вашем доме и где висит ружье.