LLM в кибербезопасности: на пути к AI-ассистенту

8 минут
Артем Проничев
Артем Проничев
Руководитель группы анализа событий безопасности отдела перспективных технологий, Positive Technologies
Александр Мамылов
Александр Мамылов
ML-инженер группы анализа событий безопасности отдела перспективных технологий, Positive Technologies
Для кого:
ML-инженеры, ИБ-специалисты, операторы SOC
Скиллы:
большие языковые модели, SIEM
  • ML
  • LLM
  • SIEM

Развитие искусственного интеллекта динамически влияет на ландшафт угроз и рисков информационной безопасности. Злоумышленники активно применяют ИИ, в том числе генеративные модели, для проникновения в системы и кражи конфиденциальной информации. Соответственно, использование AI-технологий в средствах киберзащиты — это уже не просто тренд, а необходимый стратегический шаг.

Среди перспективных направлений в этой области можно выделить применение больших языковых моделей (large language model, LLM). Это генеративные модели, которые обучены на огромных объемах текстовых данных и имеют более миллиарда весовых коэффициентов. Они способны анализировать тексты и делать выводы на основе их содержания.

В этой статье мы расскажем о наших исследованиях, посвященных применению LLM в MaxPatrol SIEM и его модуле BAD (Behavioral Anomaly Detection).

Генерация описаний запускаемых процессов

В современных ОС — Windows, Linux или macOS — работают тысячи процессов. К примеру, в Windows при анализе событий запусков процессов Sysmon 1 только за сутки число уникальных имен процессов переваливает за 30 тыс.

1.png
Рисунок 1. Наиболее часто запускаемые пользователями процессы

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

На рис. 2 представлен пример запроса к LLM. Мы попросили модель рассказать о процессе explorer.exe: для чего он используется, какие задачи выполняет и кто является его основным пользователем.

2.png
Рисунок 2. Описание процесса explorer.exe

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

Примеры запросов к LLM:

  • Опиши основные цели и задачи, которые выполняет исполняемый файл.
  • Для каких пользователей предназначен исполняемый файл? Укажи категории пользователей, которые используют данный процесс.
  • К какой категории ПО относится исполняемый файл? Например, файлы ОС, приложения для разработки, офисное ПО и др.

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

Кроме того, наш конвейер может генерировать регулярные выражения для определения версионности процесса (см. рис. 3). Этот механизм имеет ряд преимуществ — от экономии ресурсов на разметку (ведь различия в версии не означают различий в описании) до возможности применения в борьбе со сработками false positive. Использование LLM для составления регулярных выражений может показаться довольно сложным решением, ведь есть куда более легкие пути. Все дело в ключевом функциональном требовании. В Windows есть ряд процессов, в наименованиях которых содержатся цифровые значения, отражающие название, а не версию алгоритма. В качестве примера можно привести процессы для генерирования хеш-сумм: md5sum.exe и sha256sum.exe.

3.png
Рисунок 3. Генерация регулярных выражений по версиям процессов

На рис. 4 приведены примеры ответов модели по задаче генерации регулярных выражений. В целом она делится на две части, в которых нужно получить ответы на вопросы: «Есть ли версионность в именах процессов?» и «Каково регулярное выражение, если версионность присутствует?». При этом есть возможность сразу провести валидацию регулярного выражения на корректность, а если оно окажется неправильным, можно отправить LLM подумать еще раз. Этот трюк действительно повышает качество модели.

4.png
Рисунок 4. Ответ модели по задаче генерации регулярных выражений

В результате 1387 регулярных выражений покрыли 18 тыс. из 30 тыс. процессов. По мнению модели, с точностью 97% для 11 тыс. процессов регулярное выражение не потребовалось. Как результат — алгоритм покрывает 93% процессов. Таким нехитрым образом мы сократили количество процессов по версионности и снизили нагрузку на разметку более чем в два раза.

Механизм описания процессов позволяет решать совершенно разные задачи. Рассмотрим несколько примеров.

1. Помощь оператору SOC

Один из очевидных вариантов использования — представление интерактивных подсказок оператору SOC. Например, при наведении курсора или по клику по процессу можно выводить его полное описание.

2. Помощь в валидации бинарных признаков

В ходе работы запускаемые процессы могут выполнять разные действия, например выходить в интернет. Система это зафиксирует, но является ли сам факт выхода в интернет нормальным для процесса? Подобные моменты можно провалидировать, причем как вручную, так и автоматически. В случае ручной проверки достаточно выдать пользователю информацию о событии и подсказку от модели о нормальности этого события («Процесс X выходил в интернет. Для процесса X выход в интернет не является нормальным»). Далее пользователь в соответствии со своим опытом и квалификацией сможет принять решение — согласиться с вердиктом модели или нет. В случае автоматической проверки процесс отличается только тем, что вердикт модели по умолчанию принимается как истинный. На выходе мы получим сформулированное предупреждение («Аномальный выход процесса X в интернет»).

3. Борьба с false-positive событиями ML-моделей

Мы уже рассказывали о применении рекомендательной системы для детектирования аномалий. Задача системы заключается в том, чтобы отобразить, является ли запуск определенного процесса аномальным для пользователя. Недостаток модели в том, что она ориентируется на имя процесса, поэтому при запуске процесса с другим названием, но схожим функционалом мы получим ложноположительную сработку. Эта проблема решается с помощью расширенных описаний процессов. Они представляют собой текст, для которого можно получить векторное представление и оценить схожесть процессов.

На рис. 5 показана визуализация векторных представлений процессов со сниженной размерностью для отображения в двумерном пространстве. Из распределения видно, что процессы образуют хорошо разделимые кластеры: системное ПО, офисное ПО и сервисы для разработки. Также можно заметить, что схожие по назначению процессы группируются достаточно близко (например, процессы, связанные с контейнеризацией: docker, docker-compose, kubectl).

5.png
Рисунок 5. Распределение процессов в соответствии с векторными представлениями их описаний

Рассмотрим работу системы на примере. На рис. 6 представлены запускаемые пользователем процессы. Модель знает, что запуск kubewise является нормой для пользователя. Соответственно, если пользователь впервые запустит установщик kubewise-win-setup, модель не посчитает это аномалией, ведь эти процессы похожи друг на друга с точки зрения их описаний. Также в решении задачи применяется анализ версионности. То есть изменение версии запускаемого процесса не считается аномалией, если использование процесса отличной версии было нормой для пользователя.

6.png
Рисунок 6. Запускаемые пользователем процессы

Преобразование естественного языка в 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) и значениями фильтров (нужно использовать строго фиксированный набор).

7.png
Рисунок 7. Структура PDQL-запроса

С аналогичной проблемой мы столкнемся при попытке генерации запроса обычной языковой моделью: она не знает ничего о данных в нашей системе, поскольку не видела этой информации в ходе обучения. Задачу можно решить двумя способами. Первый — дообучить модель. Этот подход работает, когда у вас есть большой набор хорошо подготовленных данных. Мы решили пойти другим путем и использовать метод RAG (Retrieval Augmented Generation) и агентный подход. Суть в том, чтобы предоставить модели возможность получать необходимые данные по запросу от нее самой.

На рис. 8 представлена схема работы решения на базе агентного подхода. Основная идея агентов заключается в использовании языковой модели для выполнения последовательных взаимодействий. Агенты могут взаимодействовать с внешним миром через разработанный нами интерфейс, а в качестве мозга решения выступает LLM.

8.png
Рисунок 8. Схема работы алгоритма на базе агентов

В нашем случае для обогащения запроса к 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.

Статьи по теме

Подписаться на обновления!Подписаться на обновления!Подписаться на обновления!Подписаться на обновления!Подписаться на обновления!Подписаться на обновления!Подписаться на обновления!Подписаться на обновления!Подписаться на обновления!Подписаться на обновления!Подписаться на обновления!Подписаться на обновления!
Подписаться на обновления!Подписаться на обновления!Подписаться на обновления!Подписаться на обновления!Подписаться на обновления!Подписаться на обновления!Подписаться на обновления!Подписаться на обновления!Подписаться на обновления!Подписаться на обновления!Подписаться на обновления!Подписаться на обновления!