Для чего компаниям XDR-решения

Сегодня на рынке есть большое число технологий самых разных классов для мониторинга киберугроз и защиты от них. С одной стороны, это позволяет закрыть основные векторы атак. С другой — службам ИБ приходится одновременно работать с огромным количеством продуктов и анализировать множество разрозненных данных. Как следствие, они регулярно теряют самый ценный ресурс — время, отведенное на реагирование, а риск взлома важных для бизнеса систем при этом возрастает. Решения класса XDR (extended detection and response1) призваны решить такого рода сложности. Разберемся, в чем ценность концепции XDR, какие продукты могут входить в состав таких решений и как с их помощью быстро остановить хакера на его пути к цели.

Актуальные проблемы SOC

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

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

Внешний нарушитель — хакер, который не имеет физического доступа к объекту нападения. Внутренний нарушитель — сотрудник компании, который может использовать ресурсы организации для собственной выгоды.

Для защиты периметра существует next-generation firewall3 (NGFW), для защиты мобильных пользователей и рабочих станций — endpoint protection platform4 (EPP), а для защиты от целевых атак — связка продуктов network detection and response5 (NDR) и sandbox6.

У каждого производителя решений ИБ есть экспертиза для обнаружения хакерской активности. Каждое средство ИБ обнаруживает атаки только в рамках определенного вектора. В дальнейшем выявленные события необходимо обработать. Вопрос в том, кто и как будет это делать. Сбор множества событий из разных решений ИБ в единую цепочку атаки — трудоемкая, можно сказать, неподъемная задача для человека. Если у него и получится это сделать, процесс нельзя будет назвать быстрым и эффективным.

Так мы переходим ко второму важному элементу любого SOC — людям. В первую очередь значение имеет, сколько специалистов в команде, какие у них компетенции и какими конкретно задачами заняты операторы SOC.

Первое поколение SOC выглядело так: несколько людей с разными компетенциями анализировали события ИБ. Сотрудники SOC могли разбираться, например, в сетевых технологиях, операционных системах или администрировании, однако никакими специальными знаниями они еще не обладали. Современные SOC подходят к мониторингу угроз и реагированию на них серьезнее: появляются линии L1—L37, охотники за угрозами (threat hunters), специалисты по реверс-инжинирингу, по исследованию вредоносного кода, эксперты в форензике (компьютерной криминалистике) и менеджер, который объясняет бизнесу результаты работы SOC. И тут возникает первая сложность — нехватка кадров. Недостаточно нанять одного человека на позицию, ведь SOC — это работа 24/7/365, а значит, требуется минимум три человека на каждую линию.

Чтобы понять, где кроется вторая часть проблемы современной кибербезопасности, рассмотрим, чем занимается рядовой аналитик L1—L2. Он работает с тем набором инструментов ИБ, который есть в SOC: как правило, это SIEM (security information and event management8), NDR, UEBA (user and entity behavior analytics9), песочница, WAF (web application firewall10), NGFW, EPP и EDR (endpoint detection and response11). Соответственно, аналитику приходится смотреть во множество консолей и следить за огромным количеством оповещений от средств защиты. Конечно, между системами есть интеграция. Например, в SIEM передаются результаты анализа файлов из песочницы, а также события из NDR и UEBA. Однако каждый продукт ИБ выполняет конкретную задачу и не дает целостной картины всего происходящего в инфраструктуре, поэтому в дело вступает аналитик. Аналитику первой линии SOC необходимо:

  • Проверить все журналы и собрать их воедино.
  • Приоритизировать события безопасности.
  • Вручную сравнить данные с фидами12 угроз.
  • Провести поиск событий с помощью IoC13.
  • Собрать контекст: активы, сетевую активность и связанные файлы.
  • Построить временную шкалу и определить первоначальную точку атаки.
  • Отреагировать на инцидент и эскалировать его на L2.

Как можно заметить, процесс небыстрый. Чем дольше аналитик пытается понять, что происходит, и отреагировать на угрозу, тем больше шансов у хакера закрепиться в инфраструктуре. По данным отчета Cost of a Data Breach Report 2021 компании IBM, среднее время присутствия хакера в инфраструктуре составляет 212 дней.

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

EDR + инструменты ИБ + бизнес-инструменты = XDR

Однозначного определения XDR нет. Для одного вендора это подход к ИБ, для другого — отдельный продукт. Аналитическое агентство Forrester определяет XDR как эволюцию технологии обнаружения угроз на конечных точках и реагирования на них (EDR), охватывающую средства безопасности и бизнес-инструменты. EDR-решение — это продукт по обнаружению и блокировке вредоносной активности только на сетевых узлах. Его устанавливают на компьютеры, серверы, виртуальные машины и мобильные устройства. Как правило, это двухуровневая архитектура, состоящая из агентов и сервера управления. Сервер управления собирает данные с устройств, где развернуты агенты, находит опасные действия и предоставляет оператору инструменты для блокировки. Оператор, в свою очередь, блокирует угрозу там, где развернут EDR-агент. Таким образом, определение XDR можно упростить до трех слагаемых: EDR + инструменты ИБ + бизнес-инструменты.

XDR — это продукт, который выполняет две вещи: обнаруживает угрозы и блокирует их. Примерно тем же, казалось бы, занимается EDR, однако есть нюанс: в отличие от EDR, XDR ищет и блокирует угрозы не только там, где установлены EDR-агенты, но и там, где этих агентов нет. XDR собирает информацию из EDR, SIEM, песочницы, NDR, UEBA, WAF, VM (vulnerability management14), причем набор продуктов, входящих в состав XDR, изменяемый.

Логическая схема XDR
Логическая схема XDR

Концепт правильного XDR Positive Technologies

XDR — это связующее звено между инструментами ИБ, а не альтернатива им. Правильный XDR должен:

  1. Автоматизировать процесс реагирования на инциденты ИБ.
    Это сокращает время на обработку отдельных событий, полученных от инструментов ИБ, и снижает порог входа для работы с XDR-решением: не нужно быть экспертом, чтобы проводить расследования и реагировать на инциденты.
  2. Связывать события из разных инструментов ИБ в единую цепочку атаки.
    XDR обрабатывает и объединяет подключенные к нему события в понятную цепочку атаки и предлагает варианты реагирования, то есть склеивает большой поток событий в несколько цепочек атак и обращает на них внимание SOC-аналитика.
  3. Определять первоначальную точку атаки.
    Собрав цепочку атаки, XDR определяет причину ее возникновения. Благодаря взаимодействию с другими инструментами ИБ, XDR получает контекст каждого шага атаки: например, информацию о горизонтальном перемещении атакующего от NDR-решения.
  4. Снижать количество ложноположительных срабатываний15.
    За счет контекста и обработки событий из нескольких источников XDR определяет, какие события ложные, а какие нет. Таким образом, аналитикам SOC не нужно анализировать и верифицировать каждое событие вручную.
  5. Упрощать проактивный поиск угроз (threat hunting).
    За счет телеметрии, собираемой за пределами узла, XDR расширяет возможности threat hunting. Не нужно переключаться между консолями для поиска угроз, не требуется высокий уровень компетенции при работе с решением.
  6. Реагировать на угрозы.
    XDR должен включать в себя EDR-решение, так как для обнаружения и реагирования на угрозы используется функциональность EDR-агента.

Роль XDR в достижении результативной безопасности

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

Недопустимые события должны быть определены топ-менеджментом, а не службой ИБ. Например, для финансовой компании недопустимыми могут быть кража денег или утечка базы данных, а для промышленного предприятия — остановка турбины на ГЭС.

С технологической точки зрения решения класса XDR позволяют эффективно выявлять атаки и реагировать на них. А чтобы сделать работу XDR и ее результаты измеримыми с точки зрения важности для компании, необходимы продукты, способные оперировать понятиями недопустимых событий. Таких решений пока единицы, но потребность в них год от года, на фоне роста вовлеченности бизнеса в вопросы ИБ, точно будет расти.


  1. Выявление киберугроз и реагирование на них.
  2. Security operations center — центр оперативного реагирования на киберугрозы. Его основная задача — выявлять инциденты ИБ на ранних этапах атаки.
  3. Межсетевой экран нового поколения.
  4. Решение для предотвращения и блокирования известных угроз, обнаружения вредоносной активности.
  5. Решение для выявления угроз и реагирования на них.
  6. Сетевая песочница.
  7. На первой линии SOC работают аналитики, которые осуществляют первичную обработку киберинцидентов и отсев явных ложных срабатываний систем защиты. На вторую линию SOC передаются инциденты, для которых не разработаны плейбуки либо которым требуется более глубокий анализ силами команды. Кроме того, аналитики второй линии отслеживают инциденты, связанные с критически важными активами и известными хакерскими кампаниями, и занимаются проактивным поиском угроз. Аналитики третьей линии SOC занимаются проактивным поиском и блокированием сложных угроз и скрытой активности, которые не были выявлены существующими в компании средствами защиты.
  8. Система управления информацией и событиями безопасности.
  9. Система поведенческого анализа пользователей и сущностей.
  10. Защитный экран для веб-приложений.
  11. Решение для обнаружения угроз и реагирования на них на конечных точках.
  12. Открытые потоки данных с индикаторами компрометации, которые можно использовать для обогащения средств защиты. Помогают лучше детектировать угрозы.
  13. Индикаторы компрометации.
  14. Система управления уязвимостями.
  15. Ошибочное детектирование события, которого на самом деле не было.