Развитие искусственного интеллекта динамически влияет на ландшафт угроз и рисков информационной безопасности. Злоумышленники активно применяют ИИ, в том числе генеративные модели, для проникновения в системы и кражи конфиденциальной информации. Соответственно, использование AI-технологий в средствах киберзащиты — это уже не просто тренд, а необходимый стратегический шаг.
Среди перспективных направлений в этой области можно выделить применение больших языковых моделей (large language model, LLM). Это генеративные модели, которые обучены на огромных объемах текстовых данных и имеют более миллиарда весовых коэффициентов. Они способны анализировать тексты и делать выводы на основе их содержания.
В этой статье мы расскажем о наших исследованиях, посвященных применению LLM в MaxPatrol SIEM и его модуле BAD (Behavioral Anomaly Detection).
Генерация описаний запускаемых процессов
В современных ОС — Windows, Linux или macOS — работают тысячи процессов. К примеру, в Windows при анализе событий запусков процессов Sysmon 1 только за сутки число уникальных имен процессов переваливает за 30 тыс.
Получается, ИБ-аналитику нужно знать тысячи имен и значений процессов. Заметно упростить решение этой задачи можно с помощью больших языковых моделей. LLM могут выступать в роли второго пилота, который предоставляет аналитику подробную информацию о процессах.
На рис. 2 представлен пример запроса к LLM. Мы попросили модель рассказать о процессе explorer.exe: для чего он используется, какие задачи выполняет и кто является его основным пользователем.
После некоторых аналитических изысканий мы определили уникальные имена процессов, для которых провели разметку. Она включает опросный лист, содержание которого может меняться в зависимости от решаемых задач.
Примеры запросов к LLM:
- Опиши основные цели и задачи, которые выполняет исполняемый файл.
- Для каких пользователей предназначен исполняемый файл? Укажи категории пользователей, которые используют данный процесс.
- К какой категории ПО относится исполняемый файл? Например, файлы ОС, приложения для разработки, офисное ПО и др.
Для разметки процессов мы организовали конвейер, который позволяет как выполнять доразметку новых процессов, так и проводить разметку повторно. Доразметка полезна при наличии телеметрии от клиентов, ведь в зависимости от инфраструктуры и рода деятельности компании перечень запускаемых процессов может меняться. Повторная разметка, в свою очередь, позволит поддерживать данные о процессах в актуальном состоянии в случае использования более современных языковых моделей.
Кроме того, наш конвейер может генерировать регулярные выражения для определения версионности процесса (см. рис. 3). Этот механизм имеет ряд преимуществ — от экономии ресурсов на разметку (ведь различия в версии не означают различий в описании) до возможности применения в борьбе со сработками false positive. Использование LLM для составления регулярных выражений может показаться довольно сложным решением, ведь есть куда более легкие пути. Все дело в ключевом функциональном требовании. В Windows есть ряд процессов, в наименованиях которых содержатся цифровые значения, отражающие название, а не версию алгоритма. В качестве примера можно привести процессы для генерирования хеш-сумм: md5sum.exe и sha256sum.exe.
На рис. 4 приведены примеры ответов модели по задаче генерации регулярных выражений. В целом она делится на две части, в которых нужно получить ответы на вопросы: «Есть ли версионность в именах процессов?» и «Каково регулярное выражение, если версионность присутствует?». При этом есть возможность сразу провести валидацию регулярного выражения на корректность, а если оно окажется неправильным, можно отправить LLM подумать еще раз. Этот трюк действительно повышает качество модели.
В результате 1387 регулярных выражений покрыли 18 тыс. из 30 тыс. процессов. По мнению модели, с точностью 97% для 11 тыс. процессов регулярное выражение не потребовалось. Как результат — алгоритм покрывает 93% процессов. Таким нехитрым образом мы сократили количество процессов по версионности и снизили нагрузку на разметку более чем в два раза.
Механизм описания процессов позволяет решать совершенно разные задачи. Рассмотрим несколько примеров.
1. Помощь оператору SOC
Один из очевидных вариантов использования — представление интерактивных подсказок оператору SOC. Например, при наведении курсора или по клику по процессу можно выводить его полное описание.
2. Помощь в валидации бинарных признаков
В ходе работы запускаемые процессы могут выполнять разные действия, например выходить в интернет. Система это зафиксирует, но является ли сам факт выхода в интернет нормальным для процесса? Подобные моменты можно провалидировать, причем как вручную, так и автоматически. В случае ручной проверки достаточно выдать пользователю информацию о событии и подсказку от модели о нормальности этого события («Процесс X выходил в интернет. Для процесса X выход в интернет не является нормальным»). Далее пользователь в соответствии со своим опытом и квалификацией сможет принять решение — согласиться с вердиктом модели или нет. В случае автоматической проверки процесс отличается только тем, что вердикт модели по умолчанию принимается как истинный. На выходе мы получим сформулированное предупреждение («Аномальный выход процесса X в интернет»).
3. Борьба с false-positive событиями ML-моделей
Мы уже рассказывали о применении рекомендательной системы для детектирования аномалий. Задача системы заключается в том, чтобы отобразить, является ли запуск определенного процесса аномальным для пользователя. Недостаток модели в том, что она ориентируется на имя процесса, поэтому при запуске процесса с другим названием, но схожим функционалом мы получим ложноположительную сработку. Эта проблема решается с помощью расширенных описаний процессов. Они представляют собой текст, для которого можно получить векторное представление и оценить схожесть процессов.
На рис. 5 показана визуализация векторных представлений процессов со сниженной размерностью для отображения в двумерном пространстве. Из распределения видно, что процессы образуют хорошо разделимые кластеры: системное ПО, офисное ПО и сервисы для разработки. Также можно заметить, что схожие по назначению процессы группируются достаточно близко (например, процессы, связанные с контейнеризацией: docker, docker-compose, kubectl).
Рассмотрим работу системы на примере. На рис. 6 представлены запускаемые пользователем процессы. Модель знает, что запуск kubewise является нормой для пользователя. Соответственно, если пользователь впервые запустит установщик kubewise-win-setup, модель не посчитает это аномалией, ведь эти процессы похожи друг на друга с точки зрения их описаний. Также в решении задачи применяется анализ версионности. То есть изменение версии запускаемого процесса не считается аномалией, если использование процесса отличной версии было нормой для пользователя.
Преобразование естественного языка в PDQL-запросы
Еще одна распространенная задача — перевод естественного языка в SQL-запросы. Для этого нужно знать синтаксис языка и понимать, какие данные хранятся в системе. Мы в Positive Technologies используем сразу несколько проприетарных языков запросов, в том числе PDQL (Positive Data Query Language). В том числе он применяется для получения событий из SIEM. В качестве примера приведем ожидаемый запрос пользователя и ответ системы:
- (Запрос) give me pdql query with fields field_name1 and field_name2 when user added group to the project on Gitlab
- (Ответ) filter id = "PT_GitLab_GitLab_syslog_Production_Project_Members" and msgid = "Projects::GroupLinksController#create" and status = "success" | select field_name1, field_name2
С точки зрения синтаксиса PDQL проще, чем SQL (см. рис. 7). Однако у пользователя могут возникнуть сложности на этапе наполнения запроса данными: названиями полей (их более 100) и значениями фильтров (нужно использовать строго фиксированный набор).
С аналогичной проблемой мы столкнемся при попытке генерации запроса обычной языковой моделью: она не знает ничего о данных в нашей системе, поскольку не видела этой информации в ходе обучения. Задачу можно решить двумя способами. Первый — дообучить модель. Этот подход работает, когда у вас есть большой набор хорошо подготовленных данных. Мы решили пойти другим путем и использовать метод RAG (Retrieval Augmented Generation) и агентный подход. Суть в том, чтобы предоставить модели возможность получать необходимые данные по запросу от нее самой.
На рис. 8 представлена схема работы решения на базе агентного подхода. Основная идея агентов заключается в использовании языковой модели для выполнения последовательных взаимодействий. Агенты могут взаимодействовать с внешним миром через разработанный нами интерфейс, а в качестве мозга решения выступает LLM.
В нашем случае для обогащения запроса к LLM агент взаимодействует с внешними источниками с помощью двух инструментов. Он может «сделать запрос к базе фильтров, описанных в экспертной БД, чтобы выбрать наиболее релевантный пользовательскому запросу» либо «сделать запрос к базе полей таблицы из документации для получения возможных полей по фильтру». При этом у каждого фильтра могут быть собственные названия полей. LLM генерирует текст в определенном формате, а агент отправляет запрос в соответствующую базу данных. Далее результаты возвращаются в модель, которая формирует итоговый ответ в виде PDQL-запроса.
Для повышения качества генерируемых PDQL-запросов используется трюк с описанием мыслей и действий модели. LLM — это «продвинутый T9 из наших смартфонов», модель смотрит на текст, который она генерирует. Соответственно, за счет описания своих действий и мыслей она будет уменьшать количество галлюцинаций и выполнять задачу более последовательно.
Объяснение корреляций и сработок
SIEM — система с высоким входным порогом, поэтому для работы с ней требуются глубокие ИБ-компетенции. Первым шагом к упрощению и облегчению взаимодействия с SIEM может стать объяснение корреляционных событий и событий модуля поведенческой аналитики с помощью LLM. Это поможет понять, что происходит в системе, почему стоит обратить на это внимание и как злоумышленники могут использовать конкретное уязвимое место. Отметим, что, помимо классических правил корреляции, в MaxPatrol SIEM 8.0 также есть модуль поведенческого анализа BAD (Behavioral Anomaly Detection), который способен выявлять аномалии в инфраструктуре при помощи целого ряда ML-моделей. При этом вопросы интерпретации результатов корреляционных событий и данных от BAD стоят довольно остро.
Для решения этой задачи мы разработали два модуля — RuleExplainer и EventExplainer (для корреляционных событий и вердиктов BAD соответственно), которые могут работать по отдельности или в паре.
В случае EventExplainer на вход подается UUID нормализованного события, по которому нам нужно получить описание вердиктов ML-моделей. С помощью UUID модуль взаимодействует с API BAD и получает оттуда необходимую информацию. Помимо оценки риска и статуса события, вердикты ML-моделей дают пользователю подробное описание сработки. Например, «цепочка событий outlook.exe -> powershell.exe -> evil.exe является аномальной для пользователя admin» или «пользователь xakep успешного залогинился на машине с Passwork». Подобный набор сработок, по сути, уже является описанием инцидента. Задача LLM — подсветить нужные места и помочь в реагировании. По вектору описаний сработок мы формируем запрос к LLM, чтобы узнать следующую информацию:
- Описание запущенного процесса Windows. Суммаризация ответов моделей и логические выводы по данному событию.
- Вердикт модели по сработке (в случае угрозы будут предложены меры для ее предотвращения).
- Сопоставление сработок моделей с тактиками и техниками MITRE ATT&CK.
Чтобы получать более структурированные описания и ответы на вопросы, сначала нужно показать модели несколько примеров. Такой подход называется few-shot, его цель — в обогащении промпта и добавлении нескольких пар «вопрос — ответ».
Для модуля RuleExplainer на вход подается UUID корреляционного события, которое нам нужно описать. По UUID корреляции модуль взаимодействует с API SIEM и получает данные о событии. Для составления запроса к LLM необходимо собрать всю доступную информацию о корреляции: сначала берем данные из экспертной базы знаний, затем — из внешних источников (например, из MITRE ATT&CK). Далее по аналогии с первым модулем формируем запрос к LLM для получения следующей информации:
- Что обнаруживает эта корреляция.
- В чем опасность события для инфраструктуры.
- Что может сделать злоумышленник в системе при сработке корреляции.
- Суммаризация описания техник MITRE ATT&CK из корреляции.
***
Все описанные исследования и механизмы — первые шаги к созданию полноценного AI-ассистента, фактически второго пилота в SIEM. Грамотное использование LLM поможет снизить порог входа для пользователей, автоматизировать выполнение рутинных задач, а также позволит применять более верхнеуровневые механизмы вайтлистинга инцидентов. Оператор SOC наконец-то перестанет бегать за ответами в интернет и сможет оперативно решать свои задачи непосредственно в интерфейсе SIEM.
