Всем привет! С вами Ксения Наумова. В Positive Technologies я исследую вредоносный сетевой трафик и совершенствую инструменты его анализа в экспертном центре безопасности (PT Expert Security Center). Недавно перед нами встала задача — создать ML-модель для обнаружения вредоносного ПО в сети. Причем распознавать она должна была не только уже ранее детектируемое нами вредоносное ПО, но и совсем новые угрозы, которые появляются в большом количестве ежедневно. В качестве первого эксперимента решили сделать модель для работы с трафиком, который передается по протоколу HTTP, поскольку наши продукты успешно расшифровывают TLS-сессии, а внутри них частенько можно найти много интересного (хотя, конечно, злоумышленники активно используют и другие протоколы — возможно, в будущем проведем новые эксперименты и обязательно поделимся с вами тут).
В статье я подробно расскажу, как мы обучали модель, и поделюсь информацией о допущенных ошибках. Не упустить ни одной важной детали мне поможет Данила Ваганов, который занимается разработкой моделей машинного обучения и внедрением их в продукты Positive Technologies. Благодаря ему наше решение интегрируется в песочницу PT Sandbox. А если хотите узнать об ML в продуктах Positive Technologies, читайте отдельную статью.
Определение набора признаков
Опытный аналитик может на глаз определить, какой перед ним трафик: чистый или вредоносный. ML работает по тому же принципу, поэтому эффективность модели напрямую зависит от качества признаков, на которых она обучена. Набор нужен максимально полный, чтобы модель могла видеть как можно больше закономерностей. При этом он не должен быть избыточным, иначе придется хранить и обрабатывать данные, которые не несут в себе полезной для модели информации.
Исходя из этих условий для первой итерации мы выделили 69 признаков, характерных для различного содержимого HTTP.
Впоследствии мы оптимизировали признаковое описание. Во-первых, отбросили то, что не оказывало положительного влияния на ответы модели, а только путало ее. Во-вторых, избавились от инвертируемых признаков. Например, от таких ситуаций, когда признак, связанный с длиной контента, равен нулю, а противоположный ему всегда равен единице. В результате нам удалось без потери качества сократить число признаков до 36.
Подготовка датасета
После создания набора признаков началась более рутинная работа. Мы собирали датасет с PCAP-файлами, содержащими интересные нам сессии HTTP, а затем обрабатывали и преобразовывали каждый интересный стрим (сессию) в формат TXT, а ненужное не анализировали. Далее с помощью скоринга и заранее выработанных признаков преобразовали TXT-файлы в CSV-таблицу. В ней все признаки получили то или иное цифровое значение для суммарного подсчета скоринга. По итоговому числу и обучилась ML-модель. Не беремся утверждать, что это решение было самым оптимальным, но оно действительно работало.
Само обучение мы проводили с помощью метода классификации LightGBM — градиентного бустинга. Уже первые результаты были впечатляющими: на каком бы количестве подозрительных файлов ни обучалась модель, результат никогда не опускался ниже 99,9%.
Радуясь успеху, мы отдали модель команде ML, чтобы коллеги улучшили ее.
Работа над ошибками: проверка решения с точки зрения данных
Перед тем как развернуть ML-модель в продуктовой среде, нужно убедиться, что она будет корректно работать в реальных условиях. Необходимо понять, действительно ли данные, использованные для обучения, отражают генеральную совокупность, релевантную для компаний, которые внедрят продукт. Ошибки могут возникать из-за различия экспертного и ML-подходов к анализу трафика. Эксперты работают в основном именно с опасными образцами, а каждое семейство вредоносного ПО рассматривается независимо в рамках отдельного правила. Вердикт по нему не влияет на другие. В свою очередь, ML-решение представляет собой обобщенную модель и учится отделять чистый образец от грязного.
В нашей экспертной базе на первых этапах обнаружился серьезный дисбаланс: на два образца вредоносного ПО приходился один чистый. По другим оценкам, соотношение и вовсе получалось три к одному. При этом в реальном потоке, поступающем в песочницу, данные по большей части являются чистыми, а нелегитимные сессии встречаются лишь в 1% всех PCAP-файлов. В данном случае из-за особенностей моделей и среды ее работы небольшой дисбаланс есть (но это должно учитываться при разработке модели) — ведь, по сути, большая часть чистого трафика в песочнице однородна, а вредоносный является как раз более вариативным. Такое утверждение будет абсолютно неверным для трафика на потоке, однако тут мы рассуждаем именно о песочной сетке.
Выпускать нашу модель в жизнь в таком виде, конечно, было нельзя.
Непрерывное обучение
Разметка данных для нашей модели включает вердикты правил (95% случаев) и ручную экспертизу. А значит, классическая ML-постановка тут не работает: если модель переобучится на правилах, от нее не будет пользы. В таком случае нам интересно оценивать именно ложноположительные (false positive) срабатывания — а именно те ситуации, в которых модель обнаруживает нелегитимную активность, не покрытую существующей разметкой.
Ложноположительные сработки могут свидетельствовать о двух вещах: либо модель действительно нашла что-то уникальное, либо безопасный образец был ошибочно определен моделью как вредоносный. В случае с песочницей второй вариант допускать нельзя: она отметит файл опасным, что введет в заблуждение пользователя.
Вместе с тем на реальном потоке данных постоянно возникают новые семейства вредоносного ПО. А значит, чтобы модель оставалась результативной, ее нужно постоянно мониторить и дообучать. Для этого мы выстроили отдельный процесс: эксперты ежедневно анализируют ложноположительные срабатывания, и мы при необходимости вносим правки в модель.
Сначала мы наблюдали регулярные всплески ложноположительных срабатываний, часть из которых была связана с ошибками модели. Однако уже на этом этапе мы обнаружили множество семейств вредоносного ПО, которые исследователи прежде не описывали правилами. Уже спустя неделю число таких срабатываний сократилось: остались преимущественно уникальные детекты. Обучение ML-модели длится до сих пор, только так можно поддерживать ее актуальность.
Интерпретация вердиктов
Чтобы вердикты модели были прозрачны и объяснимы, мы использовали библиотеку SHAP, которая строит наглядные графики, объясняющие решения модели. Движение по горизонтальной оси влево свидетельствует о том, что трафик чистый, вправо — об обнаружении вредоносного ПО. Красный цвет говорит о высоком значении признака, а синий о низком. С таким графиком специалистам по ИБ, использующим песочницу, гораздо проще понять, почему модель сделала тот или иной вывод.
Как ML работает на практике
Чтобы объяснить, как наша ML-модель обнаруживает вредоносы в сетевом трафике, покажем результаты четырех экспериментов. В них мы пропускали через песочницу PT Sandbox и ML-модель один и тот же трафик, чтобы сравнить эффективность обнаружения угроз. Первые два примера относятся к начальным этапам развития модели, а остальные — к периоду после ее усовершенствования. Если хотите сначала погрузиться в теоретическую составляющую вопроса, читайте статью нашего коллеги Игоря Кабанова.
В рамках одного из первых экспериментов в «песковом» трафике ML-модель обнаружила не выявленное ранее сетевыми правилами семейство Botnet Lymysan, которое никто не документировал. На скриншоте — сессия из Wireshark. Модель заметила обращение к PHP-файлу в GET-запросе. Затем ее внимание привлекло то, что в заголовке Referer указан google.сom, но перенаправление шло с другого узла. Подозрительным оказался и заголовок User-Agent — устаревший Mozilla 4.0, который сейчас легитимными ресурсами уже не указывается. В ответе мы видим ответ сервера 204 No Content, а также явно светится заголовок X-Sinkhole: Malware. Модель сигнализировала о вредоносном ПО и была права.
Еще один интересный пример — обнаружение конфигурационного файла Backdoor C3, который также ранее не описывался и не детектировался нашими правилами. Обратите внимание на то, что в GET-запросе в заголовке Authorization в параметре token повторяются буквы fdh, при том что обращение происходит к узлу api.github.сom. Сравнив корреляцию, ML-решение также обнаружило вредоносное ПО.
В одном из более свежих примеров модель обратила внимание на длинный GET-запрос с многократным повторением одних и тех же символов, обращение к узлу с подозрительной доменной зоной gg, а также небольшое число заголовков, необычный заголовок x-krampus-security, указанный клиентом в нижнем регистре, и ответ с сервера — 522. На основе суммарного подсчета этих признаков модель указывает, что это вредоносное ПО.
В последнем примере тоже можно выделить ряд подозрительных признаков: POST-запрос с .php, подозрительный Host и данные о системе, передаваемые в теле запроса. Все это указывает на вредоносное ПО. В данном случае песочница тоже определяет троян, но только в поведенческом анализе.
В результате этих примеров можно сделать вывод, что ML позволяет обнаруживать новые угрозы, поэтому на практике ML отлично будет дополнять текущее решение и улучшать обнаружение новых угроз, что расширит возможности PT Sandbox по детектированию ВПО.
Не прощаемся, а говорим — до новых внедрений
Экспертные правила незаменимы в выявлении известных угроз, это правда. Мы часто пишем общие правила (так называемые дженерики), которые помогают нам ловить новое вредоносное ПО, но в таких правилах есть ограничения в виде синтаксиса и возможностей движка. В таком случае на помощь и приходит ML-решение: благодаря выработанным признакам, не все из которых можно обнаружить в сети с помощью синтаксиса правил, благодаря возможности смотреть на сырые пакеты — и обнаруживаются новые, никому неизвестные угрозы. Далеко не скоро мы сможем утверждать, что без сетевых правил можно обойтись — ML-решение не покроет все вредоносное ПО, какими бы хорошими признаки ни были. Но как раз-таки работая в продукте совместно с имеющимися в нем правилами — она будет прекрасно их дополнять и подсвечивать подозрительную активность нашим пользователям.
Мы постарались реализовать лучшие практики, чтобы научить нашу модель определять вредоносный трафик не хуже (и иногда даже лучше) опытного аналитика, но на этом ее развитие не кончается, поэтому не прощаемся. До встречи в других статьях, где мы будем рассказывать о новых фичах наших ML-решений!
Автор: naumovax
