Привет! На связи Николай Лыфенко и Артем Проничев, мы занимаемся разработкой и внедрением моделей машинного обучения в продукты Positive Technologies. Сегодня расскажем, как ML помогает автоматизировать действия специалистов по безопасности и детектировать кибератаки. Сначала разберем теоретическую основу, а после подкрепим ее кейсами из нашей работы.

Зачем мы используем ML

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

Концепт работы средств защиты информации

Благодаря технологиям машинного обучения мы можем автоматизировать рутинные действия операторов, находить новые атаки, которые невозможно обнаружить с помощью классического rule-based-подхода, и в целом продолжать развивать экспертизу Positive Technologies, лежащую в основе каждого нашего продукта.

ML-модели выводят средства защиты на новый уровень

Модели машинного обучения решают многие продуктовые задачи. Например, при помощи ML мы детектируем обфускацию кода, обнаруживаем вредоносное программное обеспечение (ВПО) в зашифрованном трафике, анализируем трассу поведения, а также находим веб-шеллы.

Безопасность веб-приложений

При своей работе продукты, анализирующие HTTP-трафик, получают большой объем полезной нагрузки, среди которой могут быть командные оболочки для удаленного управления веб-сервером. Мы решили задачу отделения корректных данных от вредоносных. Для этого построили ML-модели по детекту веб-шеллов. Одна модель направлена на предотвращение загрузки нелегитимного скрипта, а другая — на детект активности веб-шелла. Для их обучения мы взяли данные веб-шеллов из открытых источников и добавили интересные примеры, встретившиеся на прошедших кибербитвах Standoff. Такое разнообразие позволило увеличить полноту детекта и обнаруживать новые веб-шеллы, найти которые с помощью rule-based-подхода невозможно ввиду его концепции.

Для оценки точности срабатываний были использованы данные с наших проектов и отложенные выборки, подготовленные экспертами. Первичная оценка качества происходит во время CI/CD. Так, после обучения модели запускается процесс CML (continuous machine learning) — это помогает нам видеть разницу в качестве работы моделей на отложенных данных в merge request.

На Standoff модель применялась в режиме логирования — последующий разбор результатов показал низкий уровень ложноположительных срабатываний (менее 0,01%). Все это позволило нам снизить количество таких срабатываний в сравнении с классическим rule-based-подходом.

Пример веб-шелла, детектируемого при помощи ML-моделей

Безопасность инфраструктуры

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

Для начала разберемся с рекомендательной системой: допустим, некий программист в своей работе использует Visual Studio Code, но в какой-то момент решает перейти на PyCharm. В таком случае более простые подходы анализа зафиксировали бы аномалию, событие было бы признано false positive (ложноположительным): программист ведь обычно использовал только один редактор кода. Есть и другой пример: было бы удивительно заметить, что сотрудник отдела бухгалтерии запустил на своем рабочем компьютере whoami.exe. Строгие правила зафиксировали бы положительное событие и были бы правы — true positive.

Как показывают два этих примера, подходы, основанные на строгой логике (if-else), плохо адаптированы к реальности: они не помогают системе понимать контекст. Для более точного определения аномалий мы построили матрицу взаимодействия вида «пользователь — процесс» и обучили модель коллаборативной фильтрации. Это позволяет системе рекомендовать пользователю набор запускаемых процессов, а оператору дает векторы пользователей и отдельных процессов. Аномалии в таком случае фиксируются, когда набор предлагаемых процессов не совпадает с реально запускаемыми. Подробнее о том, как рекомендательные системы ищут аномалии, ранее рассказал наш коллега Игорь Пестрецов.

Принципы работы рекомендательной системы и модели, основанной на анализе цепочки процессов

Что касается модели, основанной на анализе цепочки процессов, то здесь все еще понятнее. Цепочка состоит из звеньев, длина которых может быть изменена, так что для большей эффективности мы решили разбить классическую цепочку A — E на четыре пары: A — E, B — E, C — E, D — E. Это позволило нам построить матрицу взаимодействия, где каждая ячейка соответствует паре. Наличие аномалии в таком случае фиксируется при малом количестве переходов из промежуточного процесса A — D в конечный процесс E. Например, переход из cmd.exe в whoami.exe — стандартная ситуация, а вот переход из outlook.exe в whoami.exe выглядит для модели подозрительно.

В наших продуктах используется разный стек технологий, поэтому в каждом отдельном случае интеграция ML-модели происходит по индивидуальному сценарию. Например, в одном из них есть код на Python и ML-модель, которую сериализуем с помощью ONNX, а MLflow используем для отслеживания экспериментов и в качестве артефактория. Также при обучении ML-модели мы применяем ежедневный поток примеров и эталонную выборку (на ней исключены ложные срабатывания), что позволяет добиваться хороших результатов внедрения в средства защиты информации. Подробнее можно прочитать в статье нашего коллеги Игоря Кабанова.

Концепт работы ML-модели в PT Sandbox для анализа поведения ВПО

Большое количество ложных и ложноположительных срабатываний превратит жизнь любого специалиста по безопасности в ад: вместо реальной работы он будет вынужден откликаться на все уведомления от неточной ML-модели. Мы решаем эту задачу выставлением высоких требований к качеству детектов уже на этапе создания MVP, а также на этапе получения обратной связи от early adopters. Это все позволяет нам не только существенно улучшить качество работы моделей машинного обучения, но и приблизить момент, когда технологии ML прочно войдут в процесс создания продуктов для информационной безопасности.

Кто ответственен за внедрение машинного обучения

Мы считаем, что для успешного внедрения машинного обучения в средства защиты информации необходимы эксперты со знаниями техник ML, computer science и доменной области.

Слева — представление нейросети о команде Positive Technologies, справа — реальное положение дел

Матричная структура команды ML в Positive Technologies позволяет организовывать виртуальные команды для работы над подобными проектами. Так, еще на начальном этапе необходимо понимать, насколько задача решаема с точки зрения кибербезопасности. Здесь помогают специалисты экспертного центра безопасности Positive Technologies (PT Expert Security Center, PT ESC): они дают нам необходимые знания о видах атак, принципах и подходах злоумышленников, а также тестируют наши решения. После этого мы договариваемся с командой разработки о зонах ответственности на этапах внедрения и поддержки продукта.

Пайплайн работ можно представить в следующем виде:

  1. Problem statement — получаем задачу в сыром виде, после чего ML-лидер, отвечающий за направление развития машинного обучения, формирует техническое задание. Мы пересматриваем бэклог несколько раз в год: это позволяет нам приоритизировать наиболее актуальные задачи.

  2. PoC (proof of concept, проверка концепции) — работаем совместно с экспертами PT ESC.

  3. MVP (minimum viable product) — ML-инженеры разрабатывают сервисы, которые будут максимально готовы к продакшену.

  4. Production — дорабатываем MVP: повышаем производительность и связываем отдельные компоненты в единую систему.

Этапы работы ML-команды над задачей

Если вы тоже обожаете machine learning и мечтаете сделать этот мир безопаснее, приходите работать в нашу команду. Сейчас мы в поисках ML-инженеров: ищем опытных специалистов с хорошим знанием Python, пониманием основ статистики, техник машинного обучения и желанием разбираться в новых современных решениях.

🔻Подробнее про ML-команду в Positive Technologies и наши задачи узнать можно здесь.