Введение

В документации на зарубежную 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):

entity_id	category
ivanov	desktop-12345
petrov	my-pc
petrov	homepc

Поля моделей

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

Поле	Описание
model_id	ID модели. Имена домашних компьютеров будут описаны в одной, еще что-то с другим ID и т.д. Например, win-acc-homepc
entity_type	Тип сущности. Мы можем создавать модели для учеток (account), групп учеток (account_group) и т.п.
entity_id	Уникальный ID сущности. Например, название учетки, название группы учеток.
category	Категория. Некоторое значение, которое описывает поведение сущности в рамках формируемой модели. Имя компьютера, путь к запущенному ПО и т.п. В основном, данные вносятся в нижнем регистре.
last_seen_day	Дата последней регистрации категории у сущности. Например, 19.02.2024
first_seen_day	Дата первого появления категории у сущности в пределах срока жизни модели. Например, 21.01.2024.
days_seen	Перечень дней в пределах времени жизни записи, когда категория встречалась. Я использую перечисление дат: 24.01.2024,26.01,2024,27.01.2024,18.02.2024,19.02.2024
days_seen_cnt	Число дней. Для дат выше это 5.

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

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

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

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

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

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

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

Блок-схема процедуры "Обработка поступающих в SIEM событий"

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

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

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

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

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

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

Записи, у которых first_seen_day == last_seen_day == 24.01.2024 удаляются - такие категории встречались последний раз 30 дней назад.
Для остальных записей, у которых 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 мы запустили именно на правилах "Первый раз".

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