Инвестиции в ИБ растут, но количество взломов – тоже. Чем поможет XDR?

Крупный и средний бизнес сегодня имеет либо in-house Security Operations Center (SOC), либо out-of-band (SOC as a Service). SOC включает в себя три элемента: технологии, люди и процессы. С технологиями все устроено просто: сколько векторов атак, столько и решений ИБ. Векторы атак зависят от модели нарушителя. Модель нарушителя — абстрактное описание хакера, который может нанести ущерб бизнесу. Бывают внутренние и внешние нарушители. Внешний нарушитель — хакер, который не имеет физического доступа к объекту нападения. Внутренний нарушитель — сотрудник компании, который может использовать ресурсы компании для собственной выгоды.

Нарушителей определили, дальше все просто. Для защиты периметра есть next-generation firewall (межсетевой экран нового поколения), для защиты мобильных пользователей и рабочих станций есть EPP (endpoint protection platform, решение для предотвращения и блокирования известных угроз, обнаружения вредоносной активности), а для защиты от целевых атак есть связка продуктов NDR (network detection and response, решение для выявления угроз и реагирования на них) и sandbox (сетевая песочница). Причем рынок производителей решений ИБ конкурентный — в каждой нише есть как минимум два-три продукта. Говорить, что какое-то решение не обнаруживает угрозы, бессмысленно. У каждого производителя решений ИБ есть экспертиза для обнаружения хакерской активности: есть вектор атаки — есть средство ИБ, которое обнаруживает атаки в рамках вектора. Вопрос в том, кто и как эти события в дальнейшем обрабатывает: человеку трудно собрать разные события из разных решений ИБ в цепочку атаки. А если и получается это сделать, то происходит очень долго и неэффективно. Следовательно, дело не в технологиях как таковых. 

Все смешалось в SOC

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

Окей, затронули проблему численности SOC, теперь посмотрим, чем занимается рядовой аналитик L1–L2. Аналитик работает с тем набором инструментов ИБ, который есть в SOC. Как правило, это SIEM (security information and event management), NDR, UEBA (user and entity behavior analytics, поведенческий анализ пользователей и сущностей), песочница, WAF (web application firewall), NGFW, EPP и EDR. Можно догадаться, где кроется вторая часть проблемы современной кибербезопасности. Правильно — в количестве консолей, куда смотрит аналитик. Да, есть интеграции между системами. Например, события из NDR и UEBA передаются в SIEM, результаты по проанализированным файлам из песочницы передаются в SIEM. Но ведь каждый продукт ИБ выполняет конкретную задачу и не дает целостной картины всего происходящего в инфраструктуре. Тут в дело вступает аналитик. Аналитику L1 предстоит выполнить ряд шагов:

1. Проверить все журналы и собрать их воедино.
2. Приоритизировать события безопасности.
3. Вручную сравнить данные с фидами угроз.
4. Провести поиск событий с помощью IoC (индикаторов компрометации).
5. Собрать контекст (активы, сетевая активность, связанные файлы).
6. Построить временную шкалу и определить первоначальную точку атаки.
7. Обеспечить реагирование и эскалировать инцидент на L2.

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

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

Рисунок 2. Логическая схема XDR

Что такое XDR и чем он отличается от EDR

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

Упростим определение XDR до трех слагаемых: EDR + Инструменты ИБ + Бизнес-инструменты. 

Для себя определим, что XDR — это продукт, который выполняет две вещи: обнаруживает угрозы и блокирует их. Примерно тем же, казалось бы, занимается EDR. Поэтому возникает вопрос: чем XDR отличается от EDR. А вот чем.

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

Рисунок 3. Процесс реагирования с XDR. Источник: https://www.forrester.com/report/adapt-or-die-xdr-is-on-a-collision-course-with-siem-and-soar/RES165775

Видение XDR Positive Technologies

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

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

Мы расскажем о нашем XDR и покажем его возможности в действии 14 декабря в 14:00. Смотрите запуск PT XDR в прямом эфире.

Результативная безопасность 

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