UEBA на минималках: не SIEM, не SOC, но уже интересно

Всем привет! 👋

В этой статье я хочу поделиться своим опытом интеграции Elastic Cloud с функциями машинного обучения для анализа аномалий в UEBA, а также о том, как Elastic Agent помогает в сборе и передаче данных в Elasticsearch, и как генератор логов использовался для тестирования системы.

Содержание статьи

1. Введение

2. Шаг 1: Выбор UEBA-системы и установка

3. Шаг 2: Интеграция данных и настройка моделей

4. Шаг 3: Установка и регистрация Elastic Agent

5. Шаг 4: Использование машинного обучения в Elastic Cloud

6. Шаг 5: Генерация логов и тестирование аномалий

7. Шаг 6: Интеграция ElastAlert2 и настройка оповещений

8. Шаг 7: Переход в Elastic Cloud и построение дашбордов

9. Шаг 8: Результаты и выводы

10. Заключение

🧩 Немного предыстории: почему именно UEBA и Elasticsearch?

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

Затем встал вопрос, с чем интегрировать систему, какую технологию ИИ или нейронных сетей использовать. Я решил взять Elasticsearch, так как в нем есть возможность применения искусственного интеллекта (в основном через машинное обучение). Эти возможности предоставляются через модуль Elastic Machine Learning, который является частью X-Pack (или Elastic Stack в более новых версиях, в том числе в облачном сервисе Elastic Cloud) + мощный поисковый и аналитический движок для хранения и обработки данных. Конечно, с учетом текущих ограничений это не самый идеальный выбор, но я считаю, что он вполне оправдан, и возможно кому-то из вас этот вариант покажется наиболее интересным.

Заранее прошу не судить строго, поскольку это моя первая работа в таком формате, и увы, я не избежал некоторых ошибок.

Ну что же, теперь давайте перейдем к самому интересному, а именно, к ходу работы.

⚙️Первый шаг: выбор системы и настройка

Первым делом мне нужно было выбрать подходящую систему класса UEBA. После поиска и изучения доступных решений я остановил свой выбор на OpenUBA, системе с открытым исходным кодом, доступной на GitHub по этой ссылке.

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

Архитектура:

В дальнейшем вы можете ознакомиться с подробным описанием на GitHub, а я продолжу.

Перед тем как я начал интеграцию Elasticsearch с OpenUBA, система работала на основе стандартных алгоритмов для анализа поведения пользователей. Она могла выявлять аномалии, но только те, которые попадали под заранее настроенные правила.

Подготовка инфраструктуры:

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

Через Git bash я клонировал репозиторий

git clone https://github.com/GACWR/OpenUBA.git
cd OpenUBA

Потом установил Python-зависимости

python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

И запустил пользовательский интерфейс

cd interface
npm install
npm start

После этого интерфейс должен был открыться, но этого не произошло. ❗Проблема оказалась в версии Node.js. 🔧 После скачивания LTS-версии с nodejs.org и повторной установки зависимостей всё заработало, и OpenUBA стал доступен по адресу http://localhost:3000.

📥 Второй шаг: Интеграция данных и настройка моделей

Следующим шагом было настроить сбор данных из различных источников, таких как системные журналы, данные о сетевой активности и логи аутентификации. OpenUBA поддерживает множество методов для подключения источников данных, включая Kafka, файловый ввод, Elasticsearch и API-интеграцию. В моем случае я использовал Elasticsearch для отправки логов, которые были предварительно обработаны и приведены к унифицированному формату (преобразование временных меток, определение ключевых полей: username, event_type, src_ip, dst_ip, timestamp и т.д.).

📡Третий шаг: Интеграция Elastic Agent для сбора данных

Следующим этапом стал Elastic Agent - универсальный агент, который я использовал для сбора логов и отправки их в Elasticsearch. Его установка оказалась не такой уж и сложной, но не обошлось без трудностей.  

Установка и настройка Elastic Agent

1. Загрузка и установка Elastic Agent:

Скачал и установил Elastic Agent с официального сайта Elastic:

curl -L -O https://artifacts.elastic.co/downloads/beats/elastic-agent/elastic-agent-8.14.0- linux-x86_64.tar.gz
tar -xvzf elastic-agent-8.14.0-linux-x86_64.tar.gz

2. Провел регистрацию Elastic Agent в Elastic Cloud:

После установки нужно было зарегистрировать Elastic Agent в Elastic Cloud, чтобы он мог отправлять собранные данные в Elasticsearch.

./elastic-agent install --url=https://<your-cluster-url>:9200 --enrollment-token=<your- enrollment-token>

И вот тут появилась первая загвоздка - токен был просрочен, а агент выдавал ошибку. Разобрался я быстро: перегенерировал токен в интерфейсе Elastic Cloud и повторил команду - всё прошло успешно.

3. Настройка сбора логов:

После регистрации я настроил политики в Elastic Fleet, чтобы агент начал собирать нужные логи - например, системные журналы или данные с заданного пути. Это делается через Kibana в разделе Fleet > Policies, а не через отдельную команду в консоли.

4. Проверка работы:

После настройки важно убедиться, что все логи поступают корректно в Elasticsearch:

./elastic-agent statu

❗Следующей проблемой было отсутствие данных в Kibana. Elastic Agent был установлен и отображался как активный, но логи в интерфейсе не появлялись. 🔧Как оказалось, по умолчанию агент не знал, где искать вручную сгенерированные мной логи. Я решил это, добавив в политику сбора данных новую интеграцию типа Custom log file в разделе Fleet, и указал явный путь: /var/log/fake_logs/access.log. После сохранения и применения политики агент начал передавать данные в Elasticsearch, и они стали отображаться в Kibana.

Теперь Elastic Agent стабильно собирает данные, а они, в свою очередь, используются в заданиях машинного обучения в Elastic Cloud для анализа поведения и выявления аномалий.

🤖 Четвертый шаг: Использование машинного обучения в Elastic Cloud для анализа аномалий

После того как данные стали поступать в кластер, я перешел к следующему этапу - использованию машинного обучения для анализа этих логов. В интерфейсе Kibana я создал ML Job, выбрал нужный индекс, указал поля event_type и username, настроил временной интервал и запустил обучение.

Как это работает:

1. Сбор и подготовка данных - логи, собранные Elastic Agent, передаются в Elasticsearch.

2. Настройка ML Jobs - я настроил Machine Learning Jobs в Kibana, которые анализируют данные в реальном времени, выявляют аномалии и предсказывают потенциальные угрозы.

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

❗Однако и здесь не всё пошло гладко. Сначала я выбрал слишком общий индекс и поле message для анализа - результат был нулевым: аномалий не выявлено. 🔧Немного покопавшись в документации, я понял, что нужно указывать более специфичные поля и сегментировать данные. После настройки правильных полей, а также уменьшения интервала bucket span, модель начала находить подозрительную активность.

В качестве примера - система обнаружила всплеск событий unauthorized_access от одного и того же пользователя, происходящих в течение короткого времени. Это было смоделировано в лог-генераторе, и Elastic ML справился с задачей.

🧪 Пятый шаг: Генератор логов для тестирования аномалий

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

❗Первоначально я столкнулся с тем, что аномалии не определялись как таковые. Система считала их нормальными, так как большинство событий были схожи. 🔧Я понял, что логика генератора слишком шаблонная, и поведение повторяется. Чтобы улучшить реализм, я ввёл случайные отклонения: динамическую смену IP, переменные временные интервалы между событиями и редкие комбинации действий. Это помогло - ML Jobs начали видеть статистические отклонения и фиксировать их как аномалии.

🚨 Шестой шаг: Интеграция ElastAlert2 для автоматической реакции

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

Установка прошла без особых проблем, однако при первом запуске появилась ❗ошибка: ElastAlert2 не находил конфигурационный файл и переменные окружения. 🔧 Для решения этой проблемы пришлось потратить не мало времени, в итоге выяснилось, что я запускал его из неверного каталога. После уточнения пути до config.yaml и добавления недостающих переменных - система запустилась.

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

На этом этапе я задумался о дальнейшей интеграции с почтой. Но для целей демонстрации хватило базовой конфигурации. Важно, что связка OpenUBA + Elastic Cloud + ML + ElastAlert2 оказалась работоспособной и масштабируемой.

☁️ Седьмой шаг: Переход на Elastic Cloud

Для большей устойчивости и доступности я решил не ограничиваться локальной установкой Elasticsearch, а использовать облачную платформу Elastic Cloud. Это дало несколько преимуществ:

• автоматическое масштабирование;

• встроенные функции Machine Learning;

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

Зарегистрировавшись на сайте, я создал новый кластер и получил URL-адрес для подключения. Настроил OpenUBA и Elastic Agent на отправку данных в этот кластер, используя защищённые токены.

На этом этапе возникла небольшая ❗сложность: Elastic Agent по умолчанию работал с localhost, и я забыл изменить его конфигурацию на внешний URL облачного кластера. 🔧После внесения правок и перезапуска агента всё заработало. Я также убедился, что Kibana корректно отображает получаемые логи.

Создав индекс в Kibana, я начал строить визуализации и дашборды. Здесь уже всё прошло гладко: Elastic Cloud предоставляет удобный и быстрый интерфейс для визуальной аналитики.

📊 Восьмой шаг: Результаты и улучшения

После завершения всех этапов, включая настройку машинного обучения, сбор логов через Elastic Agent, генерацию аномалий и автоматические оповещения, я провёл итоговый анализ эффективности системы.

Вот данные, которые я получил по результатам работы системы:

Это показало, что использование Elastic Cloud с возможностями машинного обучения действительно повышает эффективность ИАСБ.

Кроме того, система стала более автономной и адаптивной к новым угрозам. А использование визуализации в Kibana и автоматизации через ElastAlert2 сделало возможным реагирование на инциденты почти в реальном времени.

Заключение

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

И хотя были сложности - от неправильной версии Node.js до шаблонного генератора логов - каждый из этих моментов только усилил практический эффект и помог глубже понять архитектуру подобных систем.

Надеюсь, мой опыт окажется полезен кому-то, если вы, как и я, когда-то боялись слова «машинное обучение» или думали, что UEBA - это только для крупных корпораций, знайте - всё возможно. Главное - начать.

🙌 Спасибо за внимание!