Оценка методологий моделирования нейронной сети Transformer применительно к трассировкам поведения вредоносного ПО

В этой статье оцениваются различные инженерные методологии Transformer Neural Network (модель искусственного интеллекта на основе GPT), применяемые к машинным данным — журналы поведения вредоносных программ из Speakeasy emulator. Данные, использованные в этих экспериментах, находятся в свободном доступе с момента публикации в рамках этой публикации Анализ гибридного вредоносного ПО [Тризна], архивы которой можно скачать здесь. У вас есть доступ к данным и вы можете копировать или улучшать результаты!

Первоначально Transformer был представлен как архитектура кодировщика/декодера, подходящая для задач последовательного преобразования, таких как перевод естественного языка. Позже он был адаптирован для других задач, таких как маскированные модели GPT, предназначенные только для декодирования, чтобы хорошо генерировать текст. Поскольку для вывода мы будем использовать Transformer, модель состоит только из слоев кодировщика (код PyTorch модели), подобно архитектурам, используемым, например, в BERT [ Девлин и др.].

Предположительно, те же выводы о методах разработки Transformer, сделанные в этой статье, можно распространить на любой набор системных журналов, например, на телеметрию операционной системы, такую ​​как Sysmon в Windows, или на соответствующие платформы Linux, такие как auditd, уровень приложений. журналы как события kube-audit с сервера Kubernetes API или журнал доступа с HTTP-серверов, и подсчет.

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

  • треугольные, косинусные, пошаговые и одноцикловые планировщики скорости обучения;
  • накопленные градиенты;
  • градиентная обрезка;
  • пренормы блока внимания против постнормы;
  • оптимизация данных;
  • зависимость скорости обучения от размера модели.

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

В нескольких публикациях уже систематически проанализированы инженерные достижения Transformer на естественных языках, которые мы рассмотрим на машинных данных. Учитывая желание дальнейшего исследования представленных здесь идей, предлагаю изучить, например, зубрежную статью [Гейпин и Гольдштейн]».

Оптимизация набора данных

Данные состоят из отчетов JSON, представляющих результаты эмуляции примерно 120 000 образцов вредоносного и доброкачественного ПО, причем вредоносные примеры охватывают семь типов вредоносных программ, таких как программы-вымогатели, трояны, бэкдоры и т. д. Однако я ограничиваю эксперименты двоичной классификацией с Clean label, представляющий безопасный класс, и все остальные, представляющие вредоносные образцы. Стоит отметить, что тестовая выборка была собрана через три месяца после обучающей выборки, чтобы ввести оценку при наличии дрейфа концепций.

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

Полевые фильтры для уменьшения длины последовательности

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

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

Поэтому применение фильтра на основе знаний предметной области при работе с машинными данными обязательно. В нашем случае события JSON фильтруются на основе манипуляций с (1) файлами, (2) реестром, (3) доступом к сети, а также (4) именами вызовов API, аргументами и возвращаемыми значениями. Это значительно увеличило эпистемологическую плотность (т. е. соотношение релевантных знаний на токен) и качество данных.

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

Токенизация

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

В системных журналах часто встречаются произвольные комбинации символов, такие как /tmp/83afba/setup.bin или jre1.8.0_311, которые расширяют словарный запас при неправильном обращении. Например, я наблюдаю ~3000 уникальных имен API, из которых ~1000 появляются только один раз в обучающих данных.

Таким образом, каждое дополнительное поле из исходного JSON, которое вы включаете для анализа с помощью модели, значительно увеличивает размер словаря. Рассмотрим приведенный ниже логарифмический график, который визуализирует частотное распределение токенов в обучающих наборах с различными настройками фильтра полей JSON:

Например, при заданном фильтре полей, использующем вызовы API, записи в файлах, сети и реестре, общий размер словаря составляет около 250 000 токенов. Поскольку фильтры не применялись, это число приближается к 800 тысячам токенов, увеличивая словарный запас более чем в три раза и значительно снижая эпистемическую плотность (ценную информацию на токен) данных. Это подчеркивает важность соответствующих фильтров, основанных на знаниях предметной области, для повышения качества данных, получаемых моделью.

То же самое относится к нормализации полей произвольных значений, таких как хэши и IP-адреса. Например, оставление необработанных хэшей значительно расширяет словарный запас, в то время как нормализация его до таких значений, как ‹sha256› и ‹md5› с помощью приведенной ниже функции, дает лишь несколько простых для интерпретации заполнителей. что модель может использовать:

Это всего лишь один простой пример, а всю нормализацию, реализованную в моем пайплайне, можно найти здесь.

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

Я определяю собственный токенизатор JSON Byte Pair Encoding (BPE) (код) на основе Google SentencePiece, который анализирует относительное совпадение байтов. Таким образом, токены представляют собой не отдельные значения на техническом языке, а части более длинных последовательностей значений, как показано ниже:

Я ограничиваю дальнейшие эксперименты словарем 50 000 токенов BPE.

Размер модели и скорость обучения

Выбор скорости обучения (LR) прост и известен любому специалисту по глубокому обучению. Однако я хочу подчеркнуть, что для архитектур Transformer особенно важен выбор соответствующего диапазона LR для данного размера модели.

Рассмотрим эту таблицу из статьи GPT-3 [Brown et al.], в которой сообщается о конфигурации различных моделей и вариативности используемой скорости обучения:

Обратите внимание на значимость снижения скорости обучения по мере роста модели: уменьшение LR примерно в 10 раз при увеличении размера модели примерно в 1000 раз.

Из-за аппаратной настройки (GPU с одним потребителем) я использую модель скромного размера с параметрами ~ 5–6 M. Поскольку в этой статье оценивается относительная полезность конфигурации, а не достижение современных абсолютных значений, это хороший размер, который позволяет быстро перебирать множество конфигураций, обеспечивая хороший эталон поведения более крупной модели. Промышленность показывает, что размер модели (количество параметров в невстраивающих слоях) строго предсказывает производительность [Каплан и др.] — это свойство называется законом масштабирования. Следовательно, увеличение размера модели и набора данных должно обеспечить необходимую скорость обнаружения после выпуска продукции.

Я решил перебрать набор скоростей обучения от 0,003 до 0,0001, уменьшая каждую следующую примерно в 3 раза. Результаты приведены ниже:

Хорошо видно, что 0,003 — это слишком много, а 0,0001 — слишком мало, причем оптимальное значение находится где-то между 0,0003–0,001. Я выбрал LR близко к нижней строке ~ 0,0003 для дальнейших тестов.

Планировщик скорости обучения

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

Я определяю несколько планировщиков на основе тех, о которых сообщается в наиболее многообещающих публикациях, а именно: (1) шаг, (2) треугольный, (3) однотактный и (4) косинусный с преобразованием LR в течение времени обучения, как показано ниже:

Результаты экспериментов (включая запуск вообще без планировщика) представлены ниже:

Мы ясно видим, что планировщики, которые имеют стадию «разогрева», т. е. не останавливаются от максимального значения LR («треугольные» и «однотактные»), имеют более высокие потери при обучении в течение первых ~2000 обновлений. Из ROC на тестовом наборе мы можем сделать вывод, что один цикл работает хуже всего, и ни один планировщик не может иметь более высокие значения True Positive Rate (TPR, также известный как уровень обнаружения) при низких требованиях False Positive Rate (FPR).

Чтобы устранить двусмысленность, вот точные значения AUC и TPR для конкретного FPR с самым низким значением 0,0001 (что означает одно ложное предупреждение на 10 000 анализов) в тестовом наборе:

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

Интересно отметить, что обучение без планировщика дает плохие результаты при самом низком FPR. Это может указывать на то, что «перезарядка» (т. е. постепенное уменьшение значения LR ближе к концу) особенно важна для нахождения лучшей контрольной точки модели в локальных минимумах. Использование планировщика с «перезарядкой» может иметь решающее значение для приложений информационной безопасности, где ложные срабатывания истощают бюджет предупреждений человека-аналитика и обходятся дорого.

Если вы хотите более подробно изучить тему планировщиков LR, следующая статья TDS может вас заинтересовать.

Накопление градиентов

Любопытный читатель заметил разницу в размере партии в таблице 1 GPT-3 выше, когда мы обсуждали изменчивость скорости обучения в зависимости от размера модели. Различные размеры моделей требуют различного количества образцов для получения оптимального обновления градиента. Для самых маленьких моделей авторы GPT использовали размеры пакетов из 500 тысяч образцов, а для самых больших, включая саму GPT-3, они обрабатывали 3,2 миллиона образцов для каждого обновления веса.

Учитывая ограниченность ресурсов для обучения, размеры пакетов, которые помещаются на один графический процессор, являются неоптимальными. Вектор градиента, рассчитанный по 64 или 96 образцам, мог иметь искаженное направление, что замедляло сходимость. Поэтому ресурсы, которые обсуждают обучение при ограниченных ограничениях, относятся к технике накопления градиентов перед обновлением весов (т. е. вызовом optimizer.step() в PyTorch). Цикл обучения с накоплением градиента выглядит следующим образом:

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

По какой-то причине мы видим, что этот прием резко снижает производительность конечной модели. Тот же паттерн проявляется независимо от того, реализовано ли накопление градиента в нативном PyTorch, как показано выше, или с использованием ускорения от HuggingFace. Следовательно, это не должно быть ошибкой в ​​реализации. Несмотря на то, что модели с циклом накопления для значительно большего количества пакетов в рамках того же бюджета обучения, классическая реализация с примерно в 5 раз меньшим количеством данных обеспечивает более высокие показатели обнаружения.

Градиентная обрезка

Отсечение градиента — это метод установки верхнего предела значения градиента во время обновления параметра. Взрыв градиентов был существенным недостатком рекуррентных нейронных сетей (RNN), и отсечение градиента было введено как лекарство от взрывающихся градиентов в RNN. Однако практически все недавние статьи, посвященные трансформаторам, также реализуют эту технику. Он стабилизирует тренировочный процесс без существенных недостатков. PyTorch предоставляет специальную функцию clip_grad_norm_ для реализации этой логики с помощью одной строки кода в цикле обучения (непосредственно перед optimizer.step() вызовом, например). Результаты со значениями переменных в диапазоне от 0 до 1 следующие:

Мы ясно видим, что значения отсечения на уровне 0,1 неоптимальны, а по остальным трем вариантам по кривым нет четких выводов. Поэтому, как и прежде, просмотр TPR при конкретных значениях FPR и AUC в таблице ниже весьма информативен:

Здесь очевидно, что отсечение градиента 1,0 обеспечивает наилучшие показатели с самой высокой общей AUC и преимуществом не менее 3% по сравнению с другими вариантами в условиях чрезвычайно низкого FP.

Нормализация слоя — ввод или вывод

Оригинальная реализация Transformer применяет нормировку слоя к выходу блока самоконтроля. Современная литература, однако, соглашается с тем, что нормализация ввода превосходит ванильную установку (более подробную информацию см. в обсуждениях PreNorm vs. PostNorm, например [1], [2]).

Примечательно, что поведение PyTorch по умолчанию по-прежнему остается классическим PostNorm, но его легко изменить с помощью одного логического значения norm_first блока Transformer Encoder. Наши результаты подтверждают общественное мнение: нормализация входных данных превосходит классическую реализацию:

Продолжаются споры о том, превосходит ли RMSNorm обычную LayerNorm, где реализации, такие как LLaMa, используют RMSNorm, в то время как другие эксперименты не показывают никаких преимуществ. Мы исключили это из нашего анализа.

Краткое содержание

Путем экспериментов мы обнаружили, что определенные конфигурации, такие как (1) нормализация ввода, (2) «треугольные» или «шаговые» планировщики скорости обучения и (3) отсечение градиента около 1,0, эффективно улучшают производительность модели. С другой стороны, накопление градиента не улучшает производительность, что является предметом дальнейшего изучения.

Кроме того, мы обсудили важные предостережения при разработке модели Transformer для машинных данных, такие как (1) знание предметной области влияет на фильтр, нормализацию и токенизацию для сокращения словарного запаса и (2) выбор скорости обучения в зависимости от размера модели.

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