Создание правил SIEM с использованием категорийных моделей

Введение

В документации на зарубежную SIEM Exabeam я подсмотрел идею по созданию правил, использующих категорийные модели: по сути, автообновляемых табличных описаний пользовательской активности.

Применение таких моделей является достаточно простым, их можно реализовать в любой (я предполагаю) SIEM и оно позволяет расширить набор правил по выявлению аномальной пользовательской активности (UEBA).

Как использовать категорийные модели

Основное, для чего использую категорийные модели я сейчас — это создание правил SIEM «Первый раз»:

• Первый раз пользователь X сделал действие Y;

• Пользователь X сделал действие Y впервые среди членов группы U;

  • По сути это равно: Первые раз группа U сделала действие Y.

Помимо этого можно:

• Регистрировать корр. события «Пользователь X сделал редкое действие Y» (например, когда число дней появления категории у пользователя меньше 5);

• Использовать агрегированные данные из таблицы моделей за 1-2 месяца для вывода отчетов в кабинете для пользователя, а также при расследованиях.

Структура моделей и их жизненный цикл

Пример и что такое «категория»

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

У нас пользователи могут подключаться с домашних АРМ на VPN. В ряде событий аутентификации Windows видно имя компьютера, с которого идет подключение (например, DESKTOP-123456, MY_PC11). Это события аутентификации по RDP (4624 Logon type 10), иногда по сети (4624 Logon type 3).

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

Для примера выше нам необходимо иметь таблицу минимум с 2 полями:

• имя пользователя (это будет ID сущности, entity_id)

• имя компьютера (это будет наша категория, category — вносить будем в нижнем регистре)

Таблица для 2 сотрудников будет следующей (ivanov использует 1 компьютер, petrov — 2):

Поля моделей

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

В принципе, последние 3 поля можно опустить, если статистика по датам появления категорий у сущностей не нужна.

Жизненный цикл записей в моделях

Для примера, пусть сегодня 23.02.2024.

Обработка поступающих в SIEM событий

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

При отсутствии категории у данной сущности в рамках данной модели, порождается корреляционное событие.

Блок-схема логики представлена ниже:

Срок жизни записей в моделях

Я использую допустимое время нахождения категории в модели в 30 дней. Если категория не встречалась в событиях более 30 дней (например, учетка ivanov не логинилась с компьютера desktop-12345), она должна быть удалена из таблицы моделей.

Таким образом обеспечивается постоянная актуальность модели.

Очистка старых значений из моделей

Выполнение происходит ежедневно, один раз в день. С учетом того, что установленное время жизни записей в моделях 30 дней, пограничная дата будет 24.01.2024.

23.02.2024 производится следующее:

1. Записи, у которых first_seen_day == last_seen_day == 24.01.2024 удаляются — такие категории встречались последний раз 30 дней назад.

2. Для остальных записей, у которых first_seen_day == 24.01.2024:

   1. Из начала days_seen удаляется «24.01.2024,», «24.01.2024»

   2. В first_seen_day прописывается первая дата из days_seen — 26.01.2024

   3. Актуализируется days_seen_cnt

Удаление вредоносных значений из модели

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

Другие примеры детектирования аномалий «Первый раз»

Первое подключение к VPN с данной версией клиента

У нас VPN при подключении регистрирует название (с упоминанием типа ОС) и версию клиента VPN и причем она стабильна — обновляется только вручную. Допустим, что злоумышленник, получив логин и пароль пользователя пытается подключиться к VPN.

Я выдвигаю гипотезу, что клиента VPN он, наиболее вероятно, скачает с официального сайта. Есть немалая вероятность, что он или не попадет в версию, которую обычно использует сотрудник или он не попадет в ОС, которую использует сотрудник.

Как итог, получив событие «Сотрудник X впервые подключился к VPN с клиентом Y», можем начать реагировать.

Записи в таблице моделей будут такими:

• model_id = acc-vpn-useragent

• entity_type = account

• entity_id = (учетка)

• category = (название VPN клиента)

Первый доступ к сети с данного провайдера

Обогащение логов входа на VPN, на внешние сайты сведениями об автономной системе (AS/ASN = провайдер) из базы Maxmind GeoIP ASN и категорийные модели позволят нам реагировать на первые входы под пользователем с провайдера.

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

Как итог, мы можем получить событие «Сотрудник X впервые вошел в сеть с провайдера Y».

Записи в таблице моделей будут такими:

• model_id = acc-remote-asn

• entity_type = account

• entity_id = (учетка)

• category = (название AS)

Первый доступ по RDP с внутреннего IP под пользователем

Зачастую пользователи и админы заходят по RDP с небольшого числа IP адресов внутри сети: свой АРМ, админский джамп-сервер, виртуальные IP VPN и все.

Выдвину гипотезу, что если хакер взломает сервер приложений, обнаружит на нем залогиненные по RDP УЗ пользователей, он восстановит их пароли из ОЗУ и далее может начать исследовать сеть (заходить по RDP) уже с IP данного сервера приложений.

Т.о. имея некую модель «с каких IP сотрудник обычно входит по RDP куда-то», мы такие аномальные IP, с которых пойдут входы, можем выявлять.

Записи в таблице моделей будут такими:

• model_id = acc-remote-rdp-internal

• entity_type = account

• entity_id = (учетка)

• category = (IP/группа IP)

Первый запуск программы среди пользователей группы Бухгалтеры

Для выявления аномалий в действиях пользователей их можно сегментировать, к примеру выбрав группу Бухгалтеры и составить для нее модель программ, которые ее члены запускают:

• рассматриваем события 4688 (и 1 от Sysmon);

• путь к приложению преобразуем в нижний регистр;

• какие-то запуски программы игнорируем и не направляем в модель (например, системные);

• путь к приложению преобразуем с помощью шаблонов (c:\users\ivanov\program.exe меняем на «USERPROFILE\program.exe» и т.п.);

• категорией будет как раз итоговый шаблонизированный путь к приложению.

Как итог мы можем получить корреляционное событие «Сотрудник X первым из группы Бухгалтеры запустил ПО Y»

Записи в таблице моделей будут такими:

• model_id = group

• entity_type = account_group

• entity_id = Бухгалтеры

• category = (шаблонизированный путь к ПО)

Реагирование на события типа «Первый раз»

Корреляционных событий по моделям может быть много. Для каждой модели нужен свой подход (подходы) к реагированию.

Реагирование SOC на каждое событие как на подозрение

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

Анализ SOC раз в день

Для какой-то модели/группы сущностей сработки мы можем просматривать не сразу, а, например, раз в день.

Персональные автоматические рассылки

О событиях типа «первый раз» можно уведомлять непосредственно самих пользователей, как это делает большое число сервисов (Google, Telegram и т.п.) — сообщениями типа «Вы вошли впервые с ХХХ». Делать это можно автоматически из SIEM: в бот телеграм, в корпоративный мессенджер и корпоративную почту.

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

Можно к примеру, всех оповещать в бот по данной модели, а по доменным админам еще и разбираться через SOC.

Накопление риска

Общая идея подхода в том, что по определенным правилам, не регистрируется аларм в систему учета подозрений, а 1 раз в день по каждому правилу (модули) для учетки добавляется балл опасности: 20, 30, 40 и т.п.

И если за текущий день учетка накопила больше 100 баллов (по ней сработало несколько разных правил), то тогда регистрируется подозрение по ней для SOC («Учетная запись X накопила более 100 баллов риска за сегодня»).

Более детально я расскажу про подход с накоплением риска в следующей статье.

Плюсы категорийных моделей

Ниже привожу плюсы категорийных моделей в сравнении с обычными таблицами-профилями с постоянными записями:

• можно реагировать также на редкие категории (к примеру, на события которые происходят до 5 раз в месяц (days_cnt < 5) назначать баллы риска);

• имеется статистика и конкретные дни появления категории у учеток — можно использовать это в отчетах по данным за месяц (без анализа миллиардов событий ИБ), выводить это в кабинетах пользователей, проводить аналитику;

• модели самообновляемые: старые неактуальные категории сами удаляются, а даты последние даты использования всегда актуальны;

• подход к созданию правил «Первый раз» упрощается за счет отсутствия необходимости создания отдельных таблиц и т.п.

Заключение

Мы относительно легко реализовали работу подобных моделей в нашей SIEM на базе Graylog + WSO2 Streaming Integrator + MySQL. В любых других системах, обычно присутствует функционал табличных списков со временем жизни записей и что-то подобное можно придумать и там.

Первые персональные оповещения пользователям из SIEM мы запустили именно на правилах «Первый раз».