BI.ZONE EDR: инженерный взгляд на возможности продукта

Автор: Гульназ Фархутдинова, инженер направления средств защиты информации от целенаправленных атак Innostage

Современные угрозы перестали входить в дом с ноги, они бесшумно находят ключ, лежащий под ковриком входной двери, и проникают во внутрь. И именно с этого момента начинается игра на опережение: либо ты, либо тебя… Начало возможно и громкоговорящее, но сегодня предлагаю понаблюдать за гонкой между продуктами класса решений EDR. За свою не совсем длинную жизнь, я успела протестировать ни один продукт EDR/XDR, на очереди разработка от вендора BI.ZONE. Подход всегда один: развертывание и только потом изучение документации по проектированию:) Ладно, шучу…

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

Архитектурно все системы класса EDR состоят из серверной и агентской части. В продукте BI.ZONE EDR серверная часть забирает на себя хранение результатов телеметрии и последующих обнаружений, обработку алертов, управление задачами, триггерами и агентами. Заранее обусловимся, что есть разница между терминами «обнаружение» и «алерт», но раскроем эту тему чуть позже. Под телеметрией подразумевается сбор данных, например, событий операционной или файловой системы. Агентская часть является исполнителем всех заявленных действий: сбор событий операционной системы (далее ОС), корреляция потока событий, запуск задач, реагирование.

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

1. Системы, где обработка событий находится на стороне серверной части. При реализации данного варианта, зачастую, вам придется работать с брокерами сообщений (Apache Kafka, RabbitMQ) и сервисами формирования обнаружений.

2. Системы, обработка событий в которых происходит на уровне агентской части. Такой подход реализуется за счет ресурсов конечного устройства, но минимизирует точки отказа.

Какой подход является более эффективным? Рассудите сами:

Серверная обработка данных:

• Серверная обработка позволяет не ограничиваться в eps`ах и не переживать, что конечное устройство «захлебнется» в случае большой генерации событий.

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

• «Точки отказа» закрываются удобством при диагностике проблем. Система, где под каждый масштабный процесс выделяется отдельный компонент, позволяет администратору системы быстрее проанализировать систему и выявить проблемный участок. Под отдельным компонентом для каждого действия подразумевается следующее: сбор-агентом; распределение потока событий по соответствующим очередям — брокером и тд.

Агентская обработка данных:

1. Такой подход реализуется за счет ресурсов конечного устройства, но агенты из коробки ограничиваются верхним пределом потребления ресурсов.

2. Аппаратные требования к серверной части системы значительно меньше.

3. При потере сетевого соединения между компонентами системы или загруженности каналов связи пренебрегается потеря событий, впоследствии потеря алертов в реальном времени. Реагирование будет выполнено незамедлительно при настройке автоматического реагирования.

4. Зачастую, события приводятся к одному типу нормализации вне зависимости от источника данных.

5. Только в редких случаях события будут обогащаться. (Спойлер: функция обогащения реализована в продукте BI.ZONE EDR).

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

Возвращаясь к продукту, BI.ZONE EDR относится ко второй категории обработки данных. Агентская часть состоит из модулей, отвечающих за функциональную составляющую системы:

• Модуль сбора телеметрии, обнаружения и реагирования.

• Модуль для сбора информации о файловой системе и для операций с её объектами.

• Модуль удаленного администрирования. Запуск интерактивной оболочки с веб-интерфейса системы для выполнения команд в реальном времени.

• Модуль размещения приманок — Deception.

• Модуль выявления недостатков конфигурационных файлов сегмента АСУ ТП — ICS/IoT Security.

• Модуль сбора из различных источников: БД, syslog и тд — SIEM Collector.

Большим преимуществом является то, что программное требование к агенту, в рамках OC Linux, привязано ни к самому дистрибутиву, а к версии ядра, что расширяет процент покрытия инфраструктуры заказчика.

Что по аппаратным требованиям?

В большинстве своем, количество серверов системы зависит от количества подключаемых агентов. Рассмотрим на примере BI.ZONE EDR: для 100 агентов достаточно 1-2 серверов, 10к агентов — без учета отказоустойчивости 10 серверов. Для крупных предприятий, например, имеющих 50 тысяч хостов, потребуется от 16 серверов без учета отказоустойчивости. В свете последних лет, когда главный приоритет — полный охват инфраструктуры с минимальными вложениями как в финансы, так и в оборудование, использование 16 серверов выглядит вполне оправданным для 50 тысяч конечных устройств.

Для пилотных инсталляций разворачивается AIO (all in one), то есть все серверные компоненты устанавливаются на один сервер (или виртуальную машину). Развертывание системы состоит из корректировок конфигурационных файлов и запусков установочных скриптов, что в большинстве своем не вызывает ошибок и проблем.

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

Рисунок 1

После просмотра встроенных виджетов переходим на страницу с подключенными конечными устройствами. Администраторам и аналитикам всегда важно видеть основную информацию по каждому агенту, включая его состояние, ведь это одна из главных точек для мониторинга. Страница «Агенты» как раз демонстрирует полную картину по каждому конечному устройству: наименование хоста, состояние доступности и самозащиты, время последнего подключения, версия установленного агента, запущенные задачи и модули.

Рисунок 2

Для получения подробной информации необходимо перейти на страницу самого агента, нажав на наименование хоста.

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

Операционные системы, для которых имеется графический интерфейс:

1. Windows 10 и выше;

2. macOS 13 и выше;

3. Ubuntu Linux 22.04 (GNOME) и выше;

4. Astra Linux Special Edition 1.7.9 (FLY) и выше.

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

Рисунок 3

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

Например, у агента запущена задача по получению списка запущенных процессов. Для данной задачи создан триггер: предупреждение администратора системы, если в списке запущенных процессов обнаружен μTorrent. Сами задачи могут быть как простыми (=одношаговые), так и сложными (=мультишаговые). Мультишаговые задачи дают возможность выполнить сценарий действий, то есть запустить в автоматическом режиме список действии в соответствующем порядке. Например, при необходимости выполнить сбор форензики.

Рисунок 4

Что насчет сбора информации?

На Linux хостах сбор осуществляется с помощью ebpf-программ, которые могут запускаться как в пользовательском пространстве, так и в пространстве ядра. К этому всему, запуск программ происходит только при отработке «события-триггера», то есть программа привязывается к хуку (к точке закрепления), что позволяет уменьшить потребление ресурсов. Помимо этого, источниками сбора также является система аудита (Audit Framework).

Для хостов под управлением Windows сбор осуществляется с журналов событий Windows Event Log (WEL) и с ETW-провайдеров (Event Tracing for Windows) и за счет собственного драйвера вендора.

С хостов macOS сбор осуществляется за счет ESF (endpoint security framework) — это готовые наборы API запросов для мониторинга.

Полнота телеметрии разнится от заказчика к заказчику, что требует точечной корректировки методов/правил/точек сбора. Однако корректировать объем собираемых данных за счет проработки точек сбора сырых событий в рамках EDR пока невозможно. Но вам может приглянуться для таких случаев SIEM Collector, позволяющий осуществлять сбор событий по заданным параметрам.

Разграничение событий по вкладкам. На верхней панели управления имеются также две вкладки: события, обнаружения. Вспомним про наши договоренности и раскроем два понятия. Обнаружение — это результат работы движков, фиксирующих факт подозрительного действия. Алерт, в свою очередь, это как некое уведомление о подозрительном событии высокой критичности. Хочется сразу отметить, что разные производители, закладывают немного разное понятие в данные термины, но глобально, суть всегда одна. Таким образом, не каждое обнаружение можно считать алертом, алерт всегда порождается обнаружением, они же в дальнейшем могут группироваться в инциденты.

Переходя на вкладку событий, вы сможете проанализировать все нормализованные события. Вкладка «Обнаружения → Алерты» используется для работы с алертами соответственно. То есть администратор системы сможет взять их в работу, назначив на себя, а после перевести его в статус «Закрыт». Данный подход по разделению потока данных на две категории может быть достаточно удобным для аналитиков. Аналитик/Администратор ИБ (информационной безопасности) сначала просматривает вкладку «Алерты» и только при необходимости переходит к анализу нормализованного события ОС. Таким образом, вы не теряетесь в большом объеме информации, а концентрируетесь на действительно нелегитимных действиях пользователей.

Что касается самих правил обнаружения: имеется отдельная вкладка, в которой перечислен весь список правил с описанием и маппингом на матрицу MITRE ATT&CK. Большая часть вендоров не предоставляет в открытом виде пакет экспертиз для решений класса EDR, объясняя это разными причинами или не объясняя вовсе. BI.ZONE другого мнения: вендор дает возможность просматривать логику правил обнаружения для упрощения формирования списка исключений, НО при определённых условиях.

Рисунок 5

В меню «Обнаружения» имеется возможность перейти в раздел «Рекомендации безопасности». Хоть вендор не заявляет об этом в явном виде, однако функционал так называемого Compliance в данном продукте присутствует. В открывшемся окне администратор может изучить события, связанные с уязвимостями или с некорректно заданными на конечных узлах настройками конфигураций. Например, слабые или идентичные пароли у пользователей, отключенные инструменты безопасности ОС или возможность интерактивного входа под УЗ root.

Примечание. Как можете заметить, сработал движок -> создалось обнаружение.

При необходимости выполнять требования регулятора, продукт поддерживает импорт индикаторов компрометации (IoC) разных типов и пользовательских YARA-правил. В зависимости от выбранного типа IOC можно выбрать 3 действия: разрешить, уведомлять, реагировать. В случае детектирования события, соответствующего заданным критериям, генерируется уведомление, а к атакуемому или подозрительному объекту применяются меры реагирования.

Что насчет реагирования?

Администратор имеет возможность запустить следующие задачи по реагированию:

Windows:

• Завершение активных сессии;

• Приостановка процесса по имени или PID;

• Остановка/запуск/приостановка/возобновление/удаление системной службы Windows;

• Блокировка доменного имени (DNS Sinkholing);

• Изменение значения в реестре;

• Удаление ключа или значения реестра;

• Завершение дерева процессов по имени/PID процесса;

• Принудительная смена пароля при последующем входе;

• Включение/отключение локальной/доменной учетной записи;

• Удаление локального пользователя;

• Отключение/удаление запланированной задачи по имени.

Linux:

• Приостановка процесса по имени или PID;

• Блокировка доменного имени (dns sinkholing);

• Завершение процесса по имени/PID;

• Блокировка/удаление пользователя по его имени.

Общее (Linux, Windows, macOS):

• Удаление файла или директории;

• Запуск командной оболочки;

• Изоляция хоста.

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

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

Приманки могут быть как локальными, так и доменными, и доставляются до конечных устройств агентом. Их настройки задаются за счет конфигурационных файлов, шаблон которых поставляется из коробки. Стоит отметить, что модуль Deception не является полноценным решением, в котором помимо приманок обычно используются ловушки разной интерактивности. Несмотря на это, с ростом количества пентестов, проводимых с использованием примитивных ИИ-систем, применение модуля Deception значительно повысит ценность продукта BI.ZONE EDR.

Чтобы статья не была скучной, важно не забыть затронуть две ключевые темы, о которых мы слышим последние годы постоянно: термин «Искусственный интеллект» и фраза «мы не успеваем отслеживать события в 3-5 системах, даже отправляя все сработки в SIEM систему». Первый термин пытается внедриться во все продукты ИБ для улучшения системы и упрощения работы с ней. Разработчики BI.ZONE внедрили AI для возможности быстрого поиска событий, подготовки списка исключений и тому подобное. Данный функционал способствует, например, адаптации администратора к веб-интерфейсу на первых этапах или к быстрому написанию сложных фильтров. Что касается второго упоминания ситуация интереснее: архитектурное построение и использование единой консоли для всех классов решений заинтересовывает заказчиков сильнее и сильнее. Одна консоль, функциональные возможности активируются одним действием — активация соответствующей лицензии и минимальная донастройка. В случае вендора BI.ZONE ситуация аналогичная, единая консоль + многофункциональность: при необходимости подключили функционал Deception, Siem Collector или ICS/IoT Security, при необходимости докупили ZTNA и воспользовались тем же агентом на конечном устройстве для валидации хоста. Быстро, экономно, результативно.

Рисунок 6

Что насчет отказоустойчивости?

Модульная архитектура продукта позволяет легко масштабироваться и выстраивать отказоустойчивые инсталляции. Однако это не должно быть только про n-ное количество серверов с работающими компонентами. Одной из головных болей заказчиков является жесткая привязка конечного устройства к конкретному серверу управления. К сожалению, лишь малое количество вендоров предоставляют EDR решение с использованием концепции heartbeat в рамках подключения к серверам управления по первому ответившему. То есть запущенный на конечном устройстве агент подключается к первому откликнувшемуся серверу управления. Такой подход позволил бы автоматически подключаться к активному серверу и/или реализовывать архитектурно распределенные инсталляции, не привязываясь к пропускной способности каналов между географическими точками. По моему мнению, аргументировать отсутствие такого подхода тем, что при падении сервера управления агент может работать самостоятельно, не совсем уместно. Объем для кэширования данных на конечном устройстве ограничен, а RTA (Recovery Time Actual — фактическое время восстановления) может растянуться на неопределенный срок. Осведомленные читатели могут указать на возможность установки автономного агента в продукте BI.ZONE и они будут правы. Такая возможность действительно есть, но смысл в него заложен совсем иной. Осмелюсь предположить, что разработка такого агента была выполнена с целью обеспечения возможности подключения большого количества агентов к одной системе. Автономные агенты не подключаются к серверу управления, они получают модули/задачи локальным импортом на конечное устройство. События с данных хостов направляются на отдельно вынесенный компонент отправки телеметрии, который, в свою очередь, направляет их на дальнейшее хранение и обработку.

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

А теперь действительно к заключению…

Если отвлечься от маркетинговых формулировок и взглянуть на продукт со стороны администратора/пользователя, BI.ZONE EDR уверенно закрывает ключевые задачи решения EDR:

1. сбор данных, практически не привязываясь к сторонним инструментам;

2. гибкая настройка групп, задач, правил обнаружения и исключений;

3. большой портфель задач в части реагирования.

Не стоит также забывать о наличии сертификата ФСТЭК по 4-ому классу защиты с 4-ым уровнем доверия, что соответствует возможности защиты информации в системах, требующих 1-ый класс защищенности. К числу таких систем относятся государственные информационные системы (ГИС), объекты критической информационной инфраструктуры (КИИ), а также автоматизированные системы управления технологическими процессами (АСУ ТП).

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

P.S. Спасибо, что дочитали до конца, ФГ.

Источник: habr.com