Привет, Хабр! В этой статье мы хотим поговорить о применении технологий машинного обучения (machine learning, ML) в SIEM-системах. Разберемся, с какими проблемами и ограничениями сталкиваются операторы, расскажем о нашем модуле BAD и о том, как реализованные в нем модели ML помогают вычислять хакеров. А еще заглянем в будущее и посмотрим, как машинное обучение может применяться в SIEM завтра. Все это ждет вас под катом!
Сначала коротко напомним, что такое SIEM. SIEM расшифровывается как security information and event management — это система для управления безопасностью информации и анализа событий. Ее функции включают:
Сбор данных о событиях с серверов, сетевых устройств, баз данных и приложений.
Агрегацию этих данных для удобства анализа.
Анализ собранных данных для выявления аномалий и потенциальных угроз.
Мониторинг систем безопасности в реальном времени и оповещение о подозрительных активностях.
Современные SIEM значительно расширяют возможности реагирования на угрозы и позволяют, например, собирать записи об инцидентах из различных источников, представлять данные в удобном для работы формате, выявлять шаблоны и зависимости, обеспечивать мониторинг и выявлять подозрительную активность.
Правила корреляции и что с ними не так
Развитие SIEM привело к тому, что в этих системах стали применять правила корреляции. Они позволяют автоматически соотносить между собой разные данные и выявлять их взаимную зависимость. Сегодня это одно из ключевых преимуществ SIEM, которое помогает аналитикам видеть связь между событиями и вовремя замечать атаки.
Однако наряду с явным удобством, правила корреляции имеют ряд ограничений:
Они могут создавать множество ложных тревог, что перегружает аналитиков и усложняет обнаружение настоящих угроз.
Некоторые угрозы могут остаться незамеченными, если правила корреляции не покрывают определенные сценарии атак.
Нехватка контекста может ограничивать эффективность правил, поскольку события анализируются изолированно, без учета всей картины.
Причем здесь machine learning
Преодолеть ограничения правил корреляции можно с помощью технологий машинного обучения. В частности, применение ML в SIEM-системах позволит:
Анализировать большие объемы данных и находить в них закономерности, чтобы уменьшить количество ложноположительных срабатываний.
Выявлять аномалии (атомарные срабатывания моделей BAD) и нестандартные цепочки событий, которые не подпадают под традиционные правила корреляции.
Обучать модели для работы с новыми типами данных, чтобы адаптироваться к изменяющейся природе атак.
Анализировать данные с учетом контекста и связей между событиями безопасности.
Внедрить ML в другие средства защиты, чтобы создать более точную и комплексную систему анализа и корреляции событий.
Технологии машинного обучения помогут нам автоматизировать рутинные действия операторов и выявлять атаки, которые нельзя обнаружить с помощью подхода, основанного на правилах (rule-based).
Да что такое этот ваш BAD?
Работая над своими продуктами, мы воплотили идею использования машинного обучения в SIEM в виде модуля Behavioral Anomaly Detection (BAD). Несмотря на аббревиатуру, BAD не делает ничего плохого, а наоборот — помогает бороться с плохими парнями.
Модуль выступает как система second opinion: собирает данные о событиях и пользователях, а затем на основе алгоритмов присваивает им оценку риска (risk score). Оценка риска — это значение от 0 до 100, которое показывает, насколько опасно то или иное событие. Так наш BAD помогает разгрузить аналитика и предоставить ему альтернативное мнение об инциденте, чтобы аналитик ИБ мог более быстро и точно принимать решения.
Как устроен BAD
Под капотом BAD — более 60 моделей машинного обучения, часть из которых находится в разработке. Чтобы все они действовали согласованно, в архитектуре решения предусмотрены четыре взаимозависимые ветви сервисов: сбор данных, обучение, предсказания моделей и взаимодействие с продуктом. Рассмотрим их чуть подробнее.
Сервисы ветви Collector выполняют сбор данных. Сначала они отбирают данные из потока входящих сообщений и делят их на тематические группы, например запуски процессов windows sysmon 1 и события, связанные с Unix-like-системами. Затем они выполняют первичную обработку событий и записывают их в базу данных.
Сервисы группы Trainer отвечают за обучение. Эта ветвь управляет процессом тренировки, чтобы наши ML-модели обучались в определенной последовательности и не конкурировали за ресурсы с сервисами предсказания. То есть, если для модели настало время тренировки, ей присваивается некий артефакт, и в этот период она не занимается предсказанием. Многие модели обучаются на данных наших клиентов, но некоторые заранее натренированы на данных экспертов.
Сервисы Inference управляют предсказаниями. Эта группа доставляет данные до моделей, получает от них вердикты и агрегирует решения.
Сервисы группы Responder отвечают за взаимодействие с продуктом: в нашем случае это SIEM. В зависимости от сценария «общение» SIEM и BAD может происходить двумя способами: получение данных по API и отправка в очередь.
Какие ML-модели есть в BAD
После того как мы разобрались с организацией работы моделей, настало время посмотреть, что эти модели из себя представляют и какие решают задачи. Про некоторые из них мы уже писали в этом блоге, например как находить аномалии с помощью рекомендательных систем и как выявлять подозрительные цепочки процессов. Поэтому сегодня рассмотрим две другие: модель на основе статистических паттернов и модель обнаружения вредоносных PowerShell-скриптов.
Модель на основе статистических паттернов
Часто в ходе работы эксперту необходимо определить, что некое событие или агент в системе имеет подозрительные признаки. Например, новый IP-адрес узла для учетной записи или нетипичный хеш процесса. Для решения подобных задач мы и разработали модель, которая выявляет аномалии на основе статистических паттернов в зависимости от контекста.
Есть два способа реализации этой модели:
На основе разнообразия: анализируем, как много у определенного объекта нетипичных признаков. Например, насколько часто на некий узел в сети заходят неизвестные пользователи. Если такое случается постоянно, то модель не поднимет тревогу, а в противном случае событие будет признано аномальным.
На основе вероятности: анализируем, насколько часто нетипичный признак встречается у объекта. Например, как часто определенный сотрудник заходит на конкретный узел. В этом случае наша ML-модель позволит определить, насколько данное действие типично для этого пользователя.
Модель для детектирования вредоносных PowerShell-скриптов
Перед тем как получать векторы скриптов обучающей выборки, нужно правильно провести токенизацию текста — разделить его на составляющие. Это необходимо, чтобы наша модель могла «читать» скрипты и определять в них вредоносную часть.
Обычно при токенизации текстовые данные просто разбивают по пробельному символу — то есть делят текст на слова. Однако в нашем случае такой метод не сработает по двум причинам:
Скрипты содержат много специальных символов, таких как звездочки, скобки или кавычки. Эти знаки не важны в процессе обучения модели и внесут много лишнего шума.
Скрипты имеют изменяющиеся подстроки, такие как IP-адреса, домены, URB, Base64 и другие.
Поэтому перед токенизацией скриптов нужно, во-первых, удалить из текста все спецсимволы, за исключением знака $, поскольку он ставится перед инициализацией переменной и важен для понимания контекста. А во-вторых, объединить подстроки для лучшей семантики при переходах.
Далее нам нужно составить признаковое описание — набор характеристик, которые наша модель будет искать в тексте и выявлять связи между ними. Для обработки текста мы будем использовать векторные вложения. Это метод представления данных в виде векторов, который позволяет сохранить между ними семантическую связь. В ходе исследования мы сравнили два подхода к векторному представлению: частотный метод TF-IDF и нейросетевой Word2vec. В итоге выбрали первый, поскольку он обеспечивал большую скорость и лучшие метрики.
Обучение мы проводили на основе корпуса текстов, который включал в себя уникальные скрипты, отобранные по хеш-сумме из открытых источников. Всего мы получили 209 тысяч образцов.
Разметка выборки с вредоносными скриптами произведена с помощью сервиса VirusTotal, позволяющего оценить вердикты различных антивирусных движков.
Выборка с легитимными скриптами включала скрипты из открытых источников и из нашей собственной инфраструктуры. Чтобы обеспечить репрезентативность и сбалансировать выборки, мы использовали субдискретизацию (undersampling). Этот алгоритм применяют для того, чтобы сократить число объектов мажоритарного класса и обеспечить разнообразие.
Выполнить такую операцию можно с помощью кластеризации — разделения объектов на число кластеров, равное числу вредоносных файлов в выборке. Таким образом мы выровняем число легитимных и вредоносных скриптов и получим обучающую выборку.
На рисунке ниже представлены векторы легитимных скриптов, отображенных в пространстве пониженной размерности, отобранных для последующего обучения модели.
Чтобы получить проверочную или валидационную выборку, данные, наоборот, должны быть не сбалансированы: ведь легитимных скриптов намного больше, чем вредоносных.
Для валидации мы собрали 100 тысяч легитимных скриптов с реальной инфраструктуры. Проверка обнаружения вредоносных файлов осуществлялась на скриптах, которые применяли в этапах kill chain на соревнованиях Standoff. Классификатор для этой выборки был реализован на базе градиентного бустинга (GBM) — алгоритма машинного обучения, который строит модель предсказания в форме деревьев решений. Наш классификатор работал на базе библиотеки CatBoost. На рисунке ниже отображены наиболее значимые признаки, выделенные моделью.
Список признаков говорит о том, что наиболее частными паттернами во вредоносных скриптах являются:
импорты и запуски сторонних файлов формата PE (Portable Executable) или других PowerShell-скриптов;
скачивание файлов;
работа с сетью;
выделение памяти.
А вот как выглядит оценка качества моделирования:
Верно обнаруженными оказались 1891 из 1897 вредоносных скриптов. На первый взгляд кажется, что число ложноположительных срабатываний совсем небольшое — всего 3%. Однако в абсолютных величинах цифры вполне существенные — 3100 из 101 897. Поговорим о том, как можно нивелировать этот недостаток.
Превращаем вердикты моделей в оценку риска
Как видно из предыдущей части, даже с внедрением ML-моделей сохраняется относительно большое количество ложноположительных срабатываний. Чтобы еще больше снизить их число и снять лишнюю нагрузку с операторов SIEM, мы добавили в BAD сервис Profiler.
Этот сервис позволяет применять подход, основанный на правилах (rule-based). Profiler помогает построить для каждого события в инфраструктуре вектор реакции всех моделей и присвоить ему определенное количество очков риска. Это число складывается из того, какие модели сработали в отношении отдельного пользователя, сетевого узла или запущенного процесса, а также какой был вынесен вердикт.
Таким образом, отпадает необходимость изучать каждое отдельное срабатывание системы. Оператор будет видеть присвоенную оценку риска и сосредоточится на анализе наиболее опасных инцидентов. Однако это не делает систему закрытой: при необходимости можно рассмотреть каждый инцидент вручную и получить доступ ко всему контексту события, вне зависимости от его оценки риска.
Следующий уровень: как ML будет применяться в SIEM в будущем
Мы считаем, что подход rule-based отнюдь не предел развития и ML можно применять в SIEM еще шире. Уже сейчас мы можем профилировать процессы, выстраивать длинные цепочки запусков и фиксировать аномалии в различных узлах. При этом легитимные события зачастую получают высокую оценку риска, а киберпреступники усложняют техники атак и могут обмануть правила.
Как нам кажется, проблему можно решить, если присваивать общую оценку риска всей цепочке, включая дочерние процессы и контекст событий. Наше новое исследование посвящено тому, как на данных об атаках и легитимной активности построить ML-модель, которая будет сообщать оператору, с какой вероятностью цепочка процессов похожа на кибератаку. Рассмотрим, как выглядит запуск процесса и его анализ.
На данный момент BAD способен проанализировать только цепочку процессов process_guid ← parent_guid ← grand_parent_guid и на основе правил вычислить их общую оценку риска. Но, как мы видим, в окружающий контекст входят и дочерние процессы, запущенные от родителя (parent_guid) или предка выше (grand_parent_guid). В них тоже могут происходить срабатывания, а значит, они также интересны для анализа.
Цепочку запускаемых дочерних процессов можно представить в виде графа — разветвленной структуры данных, чем-то напоминающей дерево. Вот как выглядит запуск вредоносного процесса и граф его активности.
Как видно на рисунке, ветвей и дочерних процессов может быть много — действительно много. Перейдем к деталям. Вредоносный процесс install.exe был обнаружен моделями BAD, его оценка риска составляет 15,84. Далее от него были запущены процессы gameguard.exe и update.exe, и количество баллов заметно вырастает — до 38,39 и 41,14 соответственно.
Попробуем углубиться еще дальше и посмотреть, какие процессы были запущены от дочерних процессов update.exe.
Первое, что мы видим: сработало много атомарных моделей и BAD присвоил им высокую оценку риска. Во-вторых, расширение .exe говорит о том, что мы имеем дело с PE-файлами: с их помощью хакер может нанести серьезный ущерб, например:
Запуск файла ip.exe позволит хакеру скачать с удаленного сервера вредоносную нагрузку под видом библиотеки DLL.
Затем с помощью системного процесса
svchost.exeзлоумышленник сможет запустить ее.
Если же преступник догадается оставить скачанный DLL-файл в системной папке, то и вовсе останется незамеченным.
Так можно визуализировать дерево процесса от анализируемого process_guid: для каждого такого guid в дереве есть срабатывания моделей BAD. Представим их в виде вектора, где 1 — аномалия, 0 — нормальная активность, а −1 — нет срабатывания модели. Затем на основе дампа — содержимого рабочей памяти процесса — построим подграф из процесса и шести его родственников по дереву, как на рисунке 10.
Допустим, мы повторим эту процедуру для всех дампов вредоносных процессов и легитимной активности из нашего потока событий. Каждому родственнику можно добавить признак наличия или отсутствия родственника для процесса: 1 — есть, 0 — нет. Если родственника нет, вектор срабатывания моделей заполняем метками −1. Так для каждого события можно построить вектор срабатывания моделей самого процесса и шести родственных, а также признаки наличия или отсутствия родственника.
Подобный вектор можно построить для всех процессов во вредоносных и легитимных дампах с метками: 1 — процесс принадлежит хакерской активности, 0 — процесс и срабатывания моделей легитимные. Теперь мы сможем создать модель машинного обучения с учителем (supervised learning) — то есть с размеченным набором данных. В нашем случае это будет матрица с признаками и метками.
Но что будет, если пул моделей увеличится в два раза и число признаков такого подхода вырастет в 2 × 7 раз — исходя из количества соседей на рисунке 10. Или оператор захочет увеличить окрестности расследования. Значит, нам нужно разработать подход, который будет эффективен вне зависимости от количества моделей и позволит включать в анализ соседей для каждого процесса в дереве. В качестве такого подхода мы решили использовать графовые свертки.
Как это может работать
Сначала для каждого узла или процесса в графе определяется его окружение, которое включает в себя его соседей на заданной глубине. Например, если глубина равна двум, то в анализ будут включены прямые соседи и соседи этих соседей. Далее модель собирает их признаки, которые включают в себя срабатывания конкретных моделей, где 1 — это аномалия, 0 — легитимная активность, а −1 означает, что модель не сработала.
После этого применяется операция графовой свертки — сбора и анализа всех аномалий и признаков дочерних узлов. Свертку можно выполнить несколькими способами:
Усреднение признаков всех узлов в окрестности.
Суммирование признаков всех узлов в окрестности.
Выбор максимального значения из признаков всех узлов в окрестности.
Этот процесс повторяется для каждого узла в графе, обеспечивая глобальное обновление признаков. Так мы получим более информативное представление активности исходного узла с учетом контекста его окружения. Рассмотрим несколько примеров, показывающих зависимость от глубины.
Мы использовали полученную информацию о признаках для обучения модели машинного обучения методом leave-one-out. Этот метод основан на том, что каждый экземпляр данных один раз используют в качестве тестового набора, в то время как остальные экземпляры составляют обучающий набор.
Экземпляром в нашем случае является один снапшот, так сказать, слепок хакерской активности, состоящий из большого количества нормализованных событий. На рисунке ниже представлены метрики, которые мы получили.
Данные на графиках отлично разделимы, однако в двух случаях хакерской активности модель отработала неверно. Это связано с тем, что для тренировки модели мы использовали относительно небольшое число примеров. В будущем мы планируем увеличить обучающую выборку и исправить ситуацию.
Заключение
Само по себе использование в SIEM-системах машинного обучения — это вопрос будущего, но оно активно применяется уже сегодня. Это вызвано тем, что количество данных об инцидентах лавинообразно увеличивается. Поэтому мы работаем над созданием еще более совершенных ML-моделей, которые сведут к минимуму количество ложноположительных срабатываний и разгрузят операторов SIEM для решения более сложных и приоритетных задач.
Артем Проничев
Руководитель группы анализа событий безопасности, Positive Technologies
Александр Мамылов
Старший ML-инженер группы анализа событий безопасности, Positive Technologies
Тимур Смирнов
ML-инженер группы анализа событий безопасности, Positive Technologies
