Использование машинного обучения для выявления скрытых угроз веб-безопасности

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

Анализ большого объема логов ‒ сложный и длительный процесс, и обычные алгоритмы редко выявляют больше, чем система активной защиты. Поэтому логичным и перспективным решением становится применение машинного обучения (ML, machine learning). В этой статье рассмотрим варианты применения ML-моделей для анализа веб-угроз и ответим на вопрос, когда сложные модели оправданы, а когда можно обойтись более простыми решениями без потери точности.

Универсальные ML-модели

Большинство решений для проверки логов и запросов на наличие вредоносного кода используют большие и универсальные ML-модели. Такие модели не только проверяют историю, но и выявляют нарушителей, точно определяя тип угрозы. Более того, их разработчики часто заявляют о 99% точности. Звучит впечатляюще!

Однако у такого подхода есть недостаток: обучение универсальных моделей требует «Обучения с учителем», supervised learning. Это означает, что данные должны иметь единый вид и структуру, должны быть хорошо подготовлены и отсортированы, а каждый вид нарушения должен быть промаркирован. Датасет такого качества почти во всех случаях собирается вручную. К тому же, из-за размеров и сложного устройства таких моделей, их использование и дообучение является затратным по времени процессом.

Помимо обучения с учителем (supervised), существует и обучение без учителя (unsupervised). Если собранные данные имеют единый формат и точную классификацию, первый подход дает наилучший результат. Но если все входные данные исключительно чистые, их можно использовать без предварительной ручной разметки, в качестве идеальных примеров для обучаемой модели. Проблема в том, что без ручной разметки обученная модель не сможет определять точный характер обнаруженных нарушений.

Рассмотрим решение задачи по анализу логов и выявлению веб-угроз с помощью ML на примере. Для обнаружения аномалий в логах была собрана не универсальная модель, а группа моделей-детекторов под трафик с предопределенного ресурса. Для этого был разработан разделенный модуль анализа трафика на основе логов nginx’а.

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

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

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

Обе модели имеют архитектуру «автокодировщик» (autoencoder). Подобные модели всегда имеют три основных слоя: входной, промежуточный и выходной. Но остальная структура и количество параметров подбирается под конкретные задачи. Данные из входного слоя сжимаются в промежуточный в соответствии с установленными параметрами, и модель учится восстанавливать данные таким образом, чтобы выходной слой был максимально близок к входному. Такая архитектура заставляет нейросеть обучаться, выявлять корреляции и общие признаки. Несмотря на простоту структуры, она до сих пор встречается при решении множества задач: от поиска отличий элементов в больших массивах данных до участия в генерации изображений.

Автокодировщик хорошо подходит для обнаружения аномалий, потому что наличие отклонений заметно сказывается на точности восстановления. Если данные схожи с теми, на которых модель обучалась, то автокодировщик восстановит их почти в идентичном изначальному виде, а заметные отличия в выходном слое можно зафиксировать, измерить и сформировать вердикт.

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

Для другого типа модели-автокодера требуется дополнительное кодирование текста. Размер входного слоя модели выбирается исходя из наиболее длинных запросов, с запасом (либо с прямым указанием по необходимости). По этому же значению производится кодирование и нормализация. Ее точность во многом зависит от выбранного способа кодирования. Так, например, прямой перевод в числа работает заметно лучше для моделей с большим входным слоем.

Если специализированные модели обучаются на достаточном массиве данных, то они способны зафиксировать почти любое отличие внутри запроса. Например, автокодеры легко находят SQL-инъекции и любые другие встраивания инородных данных в запросы. При этом минимальные отклонения в виде произвольных параметров, которые в запросах и должны отличаться, не играют большой роли в обнаружении аномалий.

Разберем работу специализированных небольших ML-моделей на примере автокодера с прямым кодированием текста (о способе кодирования ниже). Допустим, пользователь использовал следующий текст в реквесте:

/wp-content/uploads/2024/09/photo_2024-06-14_09-49-43.jpg

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

Показатель AvgL отображает средние потери по всем записям. По настройкам в этом тесте проверка запускается на выбранном временном отрезке для всех пользователей, и производится по 50-100 записям, кроме выделенного пользователя. Для него мы заготовили лишь одну запись и будем ее менять для наглядности. То, что средние значения по сотням записей для других пользователей почти не отличаются от значений для одной единственной, говорит о хорошей точности модели для разных запросов.

Теперь попробуем для примера слегка модифицировать запрос:

/wp-content/uploads/2023/03/photo_2024-12-26_14-12-52.jpg

Мы изменили лишь пару чисел. Это не критичные изменения, особенно если другие пользователи из датасета обучения делали схожие запросы, так что мы снова получаем лишь небольшое отклонение:

Потеря сдвинулась на 0.0000012. Это значит, что модель посчитала запрос нормой. Сменим сильнее (числа, путь и формат файла):

/wp-content/storage/2023/03/items_2014-12-26_24-12-52.png

Потеря сместилась на ~0.000014, что все еще считается нормой. Чтобы заметить изменение, которое будет выглядеть странно при такой проверке, нужно структурно модифицировать запрос:

/wp-content/storage/2023/03/items_2014-12-26_any-item.png

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

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

Поэтому рассмотрим еще один пример, где для нашей модели нормой также считается запрос следующего вида:

/?s=sdfsf+%D0%B2%D1%8B%D0%BF%D0%B0%D0%B2%D1%8B%D0%BA%D0%B0%D0%BF%D0%B2%D0%BF%D0%B0%D0%B2%D0%BF4353

Его нормальный результат при проверке:

А теперь добавим туда что-то действительно заметное, например:

/?s=sdfsf+%D0%B2%D1%8B%D0%BF%D0%B0%D0%B2%D1%8B%D0%BA%D0%B0%D0%BF%D0%B2%D0%BF%D0%B0%D0%B2%D0%BF4353'--

Всего три лишних символа, которые изменили длину проверяемой строки, сделав этот запрос очевидно аномальным для модели.

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

Так, если в последнем примере заменить три символа без влияния на длину и измерить потерю между оригиналом и новой строкой с помощью функции потерь Хубера, не прибегая к использованию ML-модели, то прямая потеря составит всего ~0.000012. Однако, если текст обрабатывать хитрее, эту разницу можно сильно увеличить. Например, если при кодировании текста использовать специальный алгоритм, результаты замеров продемонстрируют потери в 0.00040. Это достигается частичной токенизацией с заменой участков текста по группам.

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

Итак, у нас есть данные в виде последовательностей, которые были закодированы, а затем переведены словарем в удобный для обучения вид. Однако, раз мы собрались делить результат по категориям, нам потребуются данные для обучения и второй, некорректной категории. Обычно это как раз тот случай, когда требуется ручная разметка. Однако благодаря автоматической обработке данных с предыдущих действий мы можем воспользоваться нашим словарем и картой маршрутов для создания «злого двойника» нашего датасета. Для этого создадим датасет той же длины, но нарушим все собранные правила карты маршрутов и проведем его через тот же словарь.

Благодаря тому, что вся предварительная обработка автоматизирована, мы вольны задавать длину целевой последовательности для каждого уникального случая: будь то проверка на коротких последовательностях из трех запросов или пачки из 10. Все это позволяет модели детектировать случаи перехода на ресурсы, куда рядовой пользователь будет обращаться только через другие запросы. Например, заметит частые обновления страниц, если это не являлось нормой для других пользователей, и сможет находить отклонения в самих запросах.

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

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

Тестирование проводилось на выборке трафика из логов 496 пользователей с суммарным объемом в 446 543 записей, куда мы, помимо нормальных логов, заранее поместили записи 81 пользователя с различными отклонениями от норм в поведении. В результате анализа по завершении процесса валидации мы получили отчет о 82 потенциальных нарушениях, выявленных моделью последовательностей и 81 потенциальном нарушении, выявленном парными моделями для тестовых и числовых данных. Таким образом были зарегистрированы все пользователи с нарушениями и по одному пользователю отмечено ложное срабатывание в модели последовательностей.

Если говорить о точности, то тестирование показывает, что некоторые одиночные запросы все еще могут ускользнуть от определения типовыми моделями. Равно как и необычные запросы нормального пользователя могут вызвать срабатывание системы безопасности. Также достоверность работы модели последовательностей стоит оценивать аккуратнее, так как поведение пользователей сложно поддается объективной оценке и является отдельной задачей, которая требует дополнительной проработки.

Если считать только по общему количеству данных, то погрешность в точности определения пользователей с нелегитимными запросами (с учетом использования трех моделей одновременно) составляет 0.002. Такое небольшое значение отклонения во многом заслуга большого объема чистых записей и, хотя оно выглядит красиво, на деле не совсем точно отображает реальное положение дел. В реальности к наиболее очевидному недостатку системы можно отнести тот факт, что она функционирует только при наличии достаточного количества записей при проверках. К тому же, модель последовательностей имеет ограничения в применении.

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