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

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

Эти факторы имеют последствия для нашей системы машинного обучения:

  1. Состязательный характер проблемы означает, что распределение атак постоянно меняется, поэтому мы должны продолжать улучшать модели. Злоумышленники часто даже используют собственные системы машинного обучения для адаптации своих атак!
  2. Из-за редкости атак мы должны сохранить каждый драгоценный образец. Мы не можем позволить себе отказаться от старых атак просто потому, что в них нет новейших функций. Вместо этого мы должны пересчитать эти функции.
  3. Из-за большой размерности и объема это проблема больших данных, которая требует эффективной распределенной обработки данных.

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

Этот цикл напоминает цикл CI / CD программной инженерии, но здесь есть еще много интересных моментов. При разработке детекторов может быть задействован новый код, новые наборы данных (которые должны обслуживаться онлайн и офлайн) и новые модели. Мы должны тщательно протестировать весь этот стек, и чем проще его будет протестировать, тем проще будет безопасно выполнить итерацию.

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

Повторное создание обновленного помеченного набора данных

Наша система восстановления состоит из трех важных компонентов.

  1. Золотые метки: набор всех помеченных сообщений с функциями, обновленными с учетом всей основы обнаружения (включая последний код, объединенные данные и модели прогнозирования). Мы с любовью называем этот набор данных «Золотые этикетки». Это набор этикеток золотого стандарта, и он также ценен, потому что он содержит все примеры атак из прошлого. Этот набор данных используется в следующих двух процессах.
  2. Восстановление: процесс оценки всей системы обнаружения для получения таких аналитических данных, как точность и отзыв. Мы называем это «повторно оцененным отзывом». Например, мы измеряем, какой процент исторических атак мы бы сегодня поймали с помощью текущей системы обнаружения. Примечание: это отличается от оценки точности и отзыва на отдельных моделях в наборе для оценки, поскольку мы тестируем весь стек, который включает несколько моделей, логику принятия решения, код извлечения функций и наборы данных.
  3. Обучение моделей. Как и при повторном обучении, для повторного обучения моделей требуются актуальные данные Golden Labels. У нас должны быть правильные и непредвзятые функции для обучения наших моделей, чтобы данные, наблюдаемые при обучении, соответствовали данным во время вывода. Функции, которые используются в обучении моделей, организованы как группа зависимостей DAG, в которой некоторые функции зависят от других функций или моделей (подробнее об этом см. Сообщение в нашем блоге График моделей и функций)

Требования к генерации данных Golden Labels

Чтобы данные, которые используются для восстановления оценок и обучения модели, были эффективными, у нас есть несколько требований:

  1. (поддержка исторических образцов) Должна иметься возможность обновлять все исторические образцы с помощью последнего кода извлечения атрибутов (1), (2) объединенных наборов данных и (3) прогнозов модели, а также оценивать надлежащую и достоверную аналитику.
  2. (требование объективности к функциям) Пересчитанные функции на старых выборках точно отражают, как эти функции выглядели бы, если бы эта выборка встретилась сегодня.
  3. Чтобы получить объективные агрегированные характеристики, система должна выполнять путешествие во времени: оценивать образцы так, как они выглядели бы во время атаки. Путешествие во времени гарантирует получение объективных данных, а также помогает нам избежать утечки в будущем: избегая переноса каких-либо данных из будущего (в прошлый образец), которые приводят к утечке меток в функции обучения.
  4. (Эффективность разработчика) Инженеры машинного обучения должны иметь возможность легко разрабатывать, интегрировать и развертывать свои изменения в любой области стека обнаружения. Должны быть достаточно эффективными, чтобы часто запускаться для повторного обучения и оценивать изменения и специальные оценки, чтобы ответить на вопросы типа «что, если».

Эксперименты с произвольным восстановлением

В дополнение к автоматическому ежедневному повторному созданию «золотых этикеток» (привязанных к определенной ветке кода), у нас также есть конвейер восстановления Ad-Hoc, позволяющий инженерам задавать вопросы «а что, если» - то есть, что происходит с общим обнаружением производительность, если мы изменим одну или несколько частей системы.

Например, нам может не потребоваться повторно запускать весь этап извлечения признаков, если мы тестируем только новую модель (и влияние этой модели на последующие этапы). Для этого мы используем самые последние обновления Golden Labels, сделанные накануне вечером, и выполняем дополнительные шаги:

Пример специального эксперимента с переоценкой

Мы можем либо настроить две конфигурации, «Базовый уровень» и «Эксперимент», либо запустить это в двух разных ветвях кода. Инженер по машинному обучению должен решить, как правильно провести эксперимент. В конце концов, мы хотели бы, чтобы наша система CI / CD запускала восстановление на этапах, затронутых конкретными изменениями кода, и автоматически предоставляла метрики, но пока это выполняется вручную.

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

# Baseline configuration runs model scoring and decisioning.
baseline_config = RescoreConfig(
  [           
    MODEL_SCORING, # Evaluates ML models
    DETECTION_DECISIONS, # Evaluates our detection decisions using the model scores.
  ]
)
# Experimental setup to swap a single model.
experiment_config = RescoreConfig(
  [
    MODEL_SCORING,
    DETECTION_DECISIONS,
  ],
  FinalDetectorRescoreConfig(
    replace_models=[ReplacementModelConfig(
      model_path="/path/to/experimental/model",
      model_id=ATTACK_MODEL
    )]
  )
)

# Runs the rescoring and delivers analytics to the user.
run_rescoring(
  rescore_config=rescore_config,
  baseline_config=baseline_config
)

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

Эффективное выполнение восстановления (часть 2…)

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



Если вы заинтересованы в решении сложных инженерных задач прикладного машинного обучения в сфере кибербезопасности, да, мы нанимаем!

Спасибо Джастину Яну, Карлосу Гаспери, Кевину Лау, Дмитрию Чечику, Мике Зирну и всем остальным из группы обнаружения в Abnormal, которые внесли свой вклад в этот процесс.