XDR - eXtended Detection and Response
Руслан Рахметов, Security Vision
Рис. 1 – Эволюция XDR
Перед началом рассказа о задачах и возможностях XDR стоит разобраться с причинами и условиями появления такого продукта. eXtended Detection and Response – это решение для расширения возможностей классических EDR, которые берут своё начало от антивирусных решений на конечных точках. Таким образом, XDR становится полезным в тех организациях, где есть потребность в обнаружении сложных атак с применением средств защиты не только на конечных точках, но и на сетевых узлах. Такие задачи можно решать разными инструментами: ручным анализом событий от EDR, автоматизированной корреляцией с использованием UBA/EUBA и SIEM или даже выстраиванием процессов реагирования в IRP. Вне зависимости от масштабов компании и применяемых в ней средств можно воспользоваться такой формулой:
ЭФФЕКТИВНАЯ ЗАЩИТА = События + Инциденты + Процессы + Автоматизация
Теперь разберёмся с переменными в этом уравнении, но перед этим для тех читателей, кто мало знаком с разными аббревиатурами (которых ниже будет много) порекомендуем обзор средств защиты информации: часть 1, часть 2, часть 3 и часть 4.
События. Эта составляющая представляет собой данные журналов, где путём поиска можно найти аномалии и заподозрить возможную атаку. Так, например, несколько попыток неудачной аутентификации пользователя в какой-либо информационной системе – это отдельные события, которые можно анализировать даже вручную, главное – знать, где искать. Похожими событиями будут легитимная передача трафика внутри компании или за её пределы, которая обнаруживается и маркируется DLP (Data Loss Prevention), действия пользователей за рабочим местом и в офисе, получаемые со СКУД (Системы Контроля и Управления Доступами) или решений класса UAM (User Activity Monitoring) /EM (Employee Monitoring). Материалы из отчётов VS (Vulnerability Scanner’ов) также являются отдельными событиями, состоящими из обнаруженных уязвимостей – поскольку часть из них могут быть неустранимыми или некритичными, инцидентами они ещё не являются и анализировать дополнительно их придётся точно.
Инциденты. Если совсем просто, то инциденты = события, на которые стоит обратить внимание. В случае с перебором паролей инцидентом будет являться, например, активность в «приманках» и ненастоящих узлах DDP (Distributed Deception Platform), активность в которых точно принадлежит злоумышленникам. DLP системы маркируют инциденты по собственным алгоритмам. Например, отправка персональных данных в службу HR вряд ли будет инцидентом, а вот сохранение базы клиентов на flash-накопитель – странная активность и скорее всего инцидент. Цепочка событий тоже может стать одним инцидентом, обнаруженным, например, средствами UEBA – аномальное количество сохранённых файлов, изменения в рабочем графике и слова-триггеры в переписке объединяются в возможный инцидент типа «возможное увольнение» и должны быть проанализированы отдельно.
Процессы. Они могут быть разными и определяются бизнес-логикой отделов в компании и их взаимодействиями. В случае с «возможным увольнением» из прошлого примера в процесс могут быть вовлечены специалисты службы кадров, информационной безопасности и ИТ: кадровики должны видеть потенциальный отток кадров и вместе с руководителем принимать решения, безопасники могут усилить контроль за каналами коммуникации и ограничить подключения по VPN, а айтишники могут инициировать подготовку техники к возможному выводу из эксплуатации текущим сотрудником.
Автоматизация. Действия специалистов разных отделов из примера выше могут быть заменены действиями роботов, и за это будут отвечать средства автоматизации. Например, управлять жизненным циклом технических активов можно в CMDB (Configuration Management Database) системах, а запускать HR и бухгалтерские процессы в автоматическом режиме можно, например, через 1С.
Таким образом, для защиты в целом можно обойтись только ручным анализом чистых событий, но чем больше переменных в вашей формуле – тем процесс проще, быстрее и надёжнее.
Рис. 2 – Составляющие эффективной защиты
Слагаемые из первой части нашей статьи могут обретать разную форму: XDR и другие подобные решения становятся отдельными параметрами или их комбинацией, поэтому далее мы разберёмся в возможных вариантах.
События и инциденты похожи по своей сути и могут быть результатами работы отдельных систем защиты информации (СЗИ): AV, DLP, UAM, NGFW, EM и т.д. Если системы настроены некачественно или используются просто из коробки, то выделить из событий инциденты помогут SIEM и UEBA системы, а также те XDR, которые включают в себя эти компоненты.
XDR = EDR + СЗИ_1 + … + СЗИ_x + UEBA + SIEM
Данная формула справедлива, если все решения в правой её части созданы и поддерживаются одним вендором. Поэтому вендоры, которые имеют в своём портфеле SIEM, смотрятся самыми полноценными из поставщиков XDR-решений.
В случае, если СЗИ представляют собой «зоопарк» решений и не могут быть объединены штатными средствами, применение XDR логично заменить SIEM/SOAR-решениями. Отличия будут лишь в том, что XDR проводит анализ на конечных точках и ограничен возможностями готовых коннекторов для интеграций, а SIEM проводит анализ централизованно и обычно готов «переварить» данные от любых систем без привязки к конкретному вендору.
Помимо событий c инцидентами важно рассмотреть ещё две составляющие – сами процессы реагирования и возможности по автоматизации. Процессы уже встречаются в решениях XDR и SIEM, поэтому, если по примеру выше внешние интеграции даже не рассматриваются, то скорее всего можно будет довольствоваться и процессами, вшитыми в XDR. Если же уровень зрелости процессов уже высок, то есть риск, что возможностей из коробки не хватит, поэтому обязательно рассмотрите SOAR, BPM и RPA решения, в которых можно создать и поддержать абсолютно любой процесс. SOAR также больше подойдёт тем компаниям, где требуется высокая кастомизация и нужно оркестрировать неограниченным количеством систем из единой точки.
Сравнить XDR в данном случае можно со стиральной машинкой с функцией сушки или кофе 3в1: занимает мало места в постирочной и кухонном шкафу, проще купить, быстрее пользоваться и не нужно настраивать. Но если вы любите кофе из турки с миндальным молоком или хорошо постиранные вещи, то скорее всего рассмотрите решения отдельно. В таком случае отдельное SIEM и/или SOAR решение будет настоящей кухней, со всем необходимым, где вы можете переставлять мебель и создавать свои рецепты. Интересно также, что интеграция c XDR происходит на этапе развёртывания, а не добавляется позже, что может связать руки развивающимся командам или большим компаниям с самописными системами и источниками данных.
Такое сравнение является достаточно грубым и уравнивает все XDR решения, что на самом деле несправедливо. Решения могут быть равносильны SOAR в том случае, если ядро интегрировано с сетевыми средствами по защите почты, веб-трафика и возможных утечек данных; EDR в составе поддерживает большое количество источников данных на уровне конечных точек (ПК, ноутбуки, виртуальные машины, мобильные устройства и др.), имеется обогащение из фидов Threat Intelligence и взаимодействие с MITRE ATT&CK. Если готовых интеграций внутри XDR мало или процессы из коробки не закрывают всех потребностей ИБ, ЭБ, ИТ и других департаментов, то в процессе эксплуатации точно возникнет потребность в расширении решениями BI, UEBA и SIEM, а организацию процессов и автоматизацию придётся переложить на решения с движками BPM и RPA.
