Введение
В документации на зарубежную 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 событий" Блок-схема процедуры "Обработка поступающих в SIEM событий"](https://habrastorage.org/getpro/habr/upload_files/30a/a37/20a/30aa3720a7482a9c4809d940ba62df27.png)
Срок жизни записей в моделях
Я использую допустимое время нахождения категории в модели в 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:
Из начала days_seen удаляется «24.01.2024,», «24.01.2024»
В first_seen_day прописывается первая дата из days_seen - 26.01.2024
Актуализируется 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 мы запустили именно на правилах "Первый раз".