Полина Сокол, старший аналитик данных R&D-лаборатории Центра технологий кибербезопасности ГК «Солар», подготовила материал о методах работы с данными и ML-моделями.
Это направление исследований позволяет на выходе обеспечить требования к прозрачности, ответственности и рискам, связанных с искусственным интеллектом. И его невозможно игнорировать при использовать ML в продуктах, предназначенных для защиты от целенаправленных атак, которые и сами могут стать одной из целей атакующих − EDR, NTA, XDR, SIEM и другие классы решений.
Процесс разработки ML-моделей не линеен. Методология Crisp-DM, которой мы пользуемся, помогает систематизировать этот процесс, разделив его на этапы. Однако, несмотря на цикличность и повторяемость этих этапов, на многих из них есть возможности для атак.
Crisp-DM (Cross-Industry Standard Process for Data Mining) — это стандартная методология для разработки ML-моделей и их внедрения в продукты. Она состоит из следующих этапов:
Определение бизнес-задачи и видения продукта — понимание целей и требований проекта;
Получение и подготовка данных — сбор, очистка и предварительная обработка данных;
Разработка и обучение модели — выбор алгоритмов и обучение модели на подготовленных данных;
Оценка метрик модели — проверка качества модели с использованием соответствующих метрик;
Подготовка модели к внедрению — оптимизация и интеграция модели в продукт;
Получение обратной связи от заказчиков — сбор отзывов для дальнейшего улучшения;
Переоценка задачи и метрик модели при необходимости — адаптация модели к новым требованиям или изменениям в данных.
Эти этапы могут идти не последовательно и повторяться. Например, если оценка метрик модели пройдет неудовлетворительно, придется вернуться на предыдущий шаг. Более наглядно процесс иллюстрирует следующая схема:
Важно обеспечить безопасность на всех этапах, имеющих отношение к разработке и обучению самой модели, так как проблемы могут возникнуть на любом из них.
Что необходимо защищать?
Данные — исходные и обработанные данные, используемые для обучения модели, могут содержать конфиденциальную информацию;
Модель — алгоритмы и параметры модели являются интеллектуальной собственностью и могут быть мишенью для кражи или подделки;
Конвейер обучения — инфраструктура и процессы обучения и развертывания модели могут быть уязвимы к атакам или сбоям.
Ключевым элементом в ML остаются данные. Недостаточная проверка данных – одна из самых частых ошибок, совершаемых разработчиками. Низкокачественные или скомпрометированные данные могут привести к серьезным уязвимостям, да и просто к ошибкам.
Крайне важно синхронизировать работу с данными между data-сайентистами и разработчиками. В своей работе они ориентируются на разные метрики датасетов – для первых важна точность модели, для вторых – производительность и масштабируемость. Поэтому команда R&D «Солар» разрабатывает методологию автоматического тестирования продуктов на базе ИИ, чтобы снизить риски уязвимостей в готовых решениях, обеспечить прозрачность и подотчетность ИИ-модулей ПО.
Еще один риск – это утечки при использовании специфических промтов для LLM (большой языковой модели). Например, сейчас существует достаточно много неофициальных «зеркал» последних больших языковых моделей. Злоумышленник может попробовать дообучить какую-либо открытую модель, например, ChatGPT выдавать ссылки на сайты с эксплоитами, вредоносные инструкции, ложную информацию. Затем он может выложить данную модель в сеть под видом «оригинальной».
Как мы проверяем данные?
Проверка на вредоносность — используем инструменты, такие как VirusTotal, для сканирования файлов на наличие вредоносного кода;
Анализ качества и релевантности — применяем статистические методы для оценки целостности и качества данных;
Проверка разметки — ручная разметка и проверка данных.
Глубокая защита
Гомоморфное шифрование позволяет обучать модель на зашифрованных данных без их расшифровки;
Маскирование данных помогает скрыть чувствительные данные, заменяя их фиктивными значениями;
Разграничение доступа позволяет установить строгие права доступа к данным и моделям в хранилищах.
Безопасность модели зависит от уровня доступа, который может получить злоумышленник. Их бывает три:
Белый ящик: полный доступ к модели и ее внутренним параметрам;
Черный ящик: доступ только к входам и выходам модели;
Серый ящик: частичный доступ к внутренним компонентам модели.
Рассмотрим каждый вариант подробнее. В случае с белым ящиком злоумышленник может провести детальный анализ модели, выявить уязвимости и разработать точные атаки. Он также может восстановить исходные данные обучения и внести изменения в модели: сменить функцию активации или удалить слой обучения. Чтобы защититься от атак на этом уровне доступа, нужно контролировать доступ, шифровать данные, а также проводить регулярные мониторинг и аудит модели.
Если речь идет о черном ящике, то здесь злоумышленник может взаимодействовать с моделью только через пользовательский интерфейс. Здесь возможны такие риски: он может «бомбардировать» модель запросами и анализировать ответы в поисках закономерностей, или изучать ответы модели, чтобы потом на их основе создать состязательные примеры. Чтобы предотвратить угрозы, стоит ограничить число запросов и добавить к выводу данных немного шума, чтобы затруднить копирование модели.
Наконец, в случае с серым ящиком, когда злоумышленник, например, частично знает внутреннее устройство модели или знает часть кода, нужно в первую очередь предупредить утечки информации. Всем сотрудникам должно быть запрещено разглашать подробности о модели или открывать к ней доступ. Даже коллегам.
Также, независимо от типа доступа предполагаемых злоумышленников, нужно регулярно аудировать все с помощью MLFlow и использовать проверенные датасеты, чтобы удостовериться, что модель работает корректно, а результаты не изменились и соответствуют ожиданиям.
Одна из самых серьезных угроз в ML — состязательные атаки (adversarial attacks). Это различные методы, с помощью которых злоумышленники могут воздействовать на модели машинного обучения. Такие атаки направлены на искажение результатов работы модели или получение конфиденциальной информации.
Особенно это актуально для больших языковых моделей, которые способны обрабатывать сложные данные и могут случайно выдавать конфиденциальную информацию. Большие языковые модели требуют особой защиты, так как, в отличие от классических моделей, они могут генерировать текст на основе ранее обработанных данных.
Для защиты от таких атак используют разные библиотеки: например, Adversarial Robustness Toolbox (ART) для проверки модели на устойчивость. Или Foolbox для тестирования атак на модели и их защиты. Устойчивость моделей к уязвимостям может быть усилена через adversarial training, когда модель обучается на примерах атак.
Основные методы состязательных атак:
Атаки уклонения (Evasion Attack) — злоумышленник подбирает специальные входные данные, чтобы она выдала нужный ему результат: например, конфиденциальную информацию. К утечке могут привести незначительные изменения в изображении или тексте, незаметные с первого взгляда.
Например, злоумышленники могут использовать механизмы подсказок-инструкций для модели (promt), которая реализует jailbreaking‑инъекции. Они могут «сбивать с толку» модель для получения чувствительной информации.
Если выходной результат LLM не проверяется на безопасность, злоумышленник может использовать свой специальный prompt, чтобы LLM выдала ответ, который может привести к потере данных.
Например, как на скриншоте:
Отравление данных (Data Poisoning) — на этапе обучения модели злоумышленник меняет данные, добавляя некорректно размеченные или вредоносные примеры. В итоге модель учится на искаженных данных и начинает ошибаться при реальном использовании.
Например, хакеры могут обмануть систему слежения с функцией Face ID с помощью специальных очков:
Или усложнить распознавание изображения с помощью специального второго слоя:
Как это влияет на R&D?
Например, вы используете датасет из Kaggle с таблицей headers вредоносного ПО, а киберпреступник внес к данным headers свои малвари поставил метки, что это безопасные файлы. А вы в итоге обучили на них модель, а уже дальше модель будет пропускать эти файлы как безопасные.
Adversarial Training — включаем состязательные примеры в обучающий набор, чтобы модель научилась с ними справляться;
Ансамбли моделей — используем комбинацию нескольких моделей, что затрудняет обман всей системы;
Ограничение и мониторинг запросов — контролируем частоту и характер запросов к модели, чтобы предотвратить атаки.
Что мы делаем с опенсорсными решениями?
Анализируем код: проводим статистический и динамический анализ опенсорсных компонентов на наличие уязвимостей;
Тестируем на собственных данных — перед внедрением проверяем модель на наших датасетах, чтобы убедиться в ее корректной работе;
Проверяем — изучаем, соответствуют ли сторонние решения нашим стандартам безопасности.
Как пример, вы можете столкнуться с риском эксплуатации подобных уязвимостей:
Уязвимость в платформе машинного обучения TensorFlow (CVE-2021-41228), позволяющая выполнить свой код при обработке утилитой saved_model_cli данных атакующего, переданных через парметр "--input_examples".
Проблема вызвана использованием внешних данных при вызове кода функцией "eval". Проблема устранена в выпусках TensorFlow 2.7.0, TensorFlow 2.6.1, TensorFlow 2.5.2 и TensorFlow 2.4.4.
В целом, опенсорсные решения при разработке ML-моделей можно и нужно использовать. Однако уязвимости в исходном коде модели могут дать злоумышленникам доступ к данным или даже контроль над поведением модели. Поэтому важно проверять такие компоненты, чтобы обеспечить безопасность. Например, модуль SCA в программном продукте Solar appScreener анализирует используемые open source-библиотеки и зависимости на наличие уязвимостей и снижает риск использования уязвимых компонентов при обучении ML-моделей.
Для моделей, которые нуждаются в регулярном повторном обучении и тюнинге, защита конвейера обучения становится особенно важной.
Какие могут быть риски:
Атаки на новые данные — злоумышленники могут попытаться внедрить вредоносные данные в процессе переобучения;
Изменения в коде процессов извлечения, преобразования и загрузки данных (ETL) — незаметные изменения могут привести к сбоям или изменению поведения модели;
Инсайдерские угрозы — сотрудники с доступом к конвейеру могут внести вредоносные изменения.
Как это влияет на R&D?
Инсайдер может изменить код модели, и она начнет выдавать результаты хуже ожидаемых или просто неверные, например, отметит, что у вас не скан чертежа, а просто… котик.
Как обезопасить конвейер?
Аудит кода и процессов — регулярно проверяем изменения в коде и настройках конвейера;
Контроль доступа — разграничиваем права доступа к различным компонентам конвейера;
Мониторинг и алертинг — настраиваем системы оповещения о необычной активности или изменениях в поведении модели.
Нагрузочное тестирование является критически важным процессом в разработке и эксплуатации систем, особенно, когда речь идет о моделях, которые должны работать под большой нагрузкой.
Это тестирование позволяет оценить производительность, стабильность, масштабируемость и стрессоустойчивость системы, что имеет прямое отношение к обеспечению бесперебойной работы и безопасности ИИ-систем. Своевременное проведение нагрузочного тестирования помогает выявить и устранить потенциальные узкие места в системе до того, как они приведут к сбоям или простоям в работе.
Например, нагрузочное тестирование определяет, сколько одновременно работающих пользователей или запросов система может обслуживать без ухудшения производительности, а также проверяет, как система реагирует на пиковые нагрузки и внезапные всплески активности.
Этот процесс также необходим для планирования мощностей и расчета необходимого технического обеспечения.
Данные, полученные в результате нагрузочного тестирования, используются для разработки соглашений об уровне обслуживания (SLA) и для сравнения показателей с внутренними эталонами и показателями конкурентов. Кроме того, нагрузочное тестирование помогает организациям подготовиться к периодам роста или аномально высокого уровня нагрузки, что особенно важно для систем, работающих в режиме 24/7.
В контексте безопасности ИИ, нагрузочное тестирование обеспечивает дополнительный слой защиты. Оно помогает выявить и исправить потенциальные уязвимости, которые могут эксплуатировать злоумышленники, например, в ходе DDoS-атак. В R&D «Солар» мы используем нагрузочное тестирование для больших дата-сетов и отдельных решений по защите от утечек информации.
Современные системы безопасности активно используют автоматизацию для обнаружения и устранения угроз. Она играет ключевую роль в снижении человеческого фактора и помогает находить аномалии в моделях на ранних этапах.
Отдельно стоит отметить работу с большими языковыми моделями. Как я уже говорила выше, одна из их главных особенностей — их способность хранить и случайно воспроизводить информацию, которую она получила ранее, например, от других пользователей.
Инструменты, такие как MLFlow, позволяют отслеживать весь цикл обучения модели и фиксировать изменения на каждом этапе. MLFlow — это платформа для управления циклом обучения моделей ML. Она позволяет:
Отслеживать эксперименты — сохранять параметры, метрики и артефакты моделей;
Управлять версиями моделей — хранить разные версии моделей для сравнения и воспроизведения результатов;
Контролировать доступ — разграничивать права на просмотр и изменение моделей.
Автоматические инструменты для обнаружения аномалий и угроз:
Adversarial Robustness Toolbox (ART) — библиотека для генерации и обнаружения состязательных атак, тестирования устойчивости моделей. Она используется для автоматического обнаружения бэкдоров и аномалий в нейронных сетях;
Кластеризация активаций DNN: Анализируем выходы скрытых слоев нейронных сетей для выявления аномалий. Кластеризация скрытых слоев DNN позволяет выявлять датасеты, которые содержат потенциально вредоносные данные. Это помогает защитить модели от возможных атак на этапе обучения.
Отдельно стоит отметить работу с большими языковыми моделями. Как я уже говорила выше, одна из их главных особенностей — их способность хранить и случайно воспроизводить информацию, которую она получила ранее, например, от других пользователей.
Отдельно стоит отметить работу с большими языковыми моделями. Как я уже говорила выше, одна из их главных особенностей — их способность хранить и случайно воспроизводить информацию, которую она получила ранее, например, от других пользователей.
Поэтому перед обучением таких моделей важно очищать данные от таких элементов и проверять их на актуальность. Кроме того, автоматизация процесса проверки данных с использованием специализированных инструментов снижает вероятность ошибок и утечек данных.
Безопасность в машинном обучении — это постоянный процесс, требующий внимания на каждом этапе разработки и внедрения моделей. Проблема станет еще более важной по мере усложнения и увеличения масштабов моделей, особенно больших языковых. Современные угрозы, такие как состязательные атаки и утечки через опенсорсные компоненты, требуют внедрения комплексных мер защиты.
Внедряйте автоматизацию. Использование инструментов вроде MLFlow и ART помогает систематизировать процессы и снизить риск человеческих ошибок;
Проводите регулярные аудиты. Проверка данных, моделей и процессов позволяет своевременно обнаружить и устранить уязвимости;
Обучайте устойчивые модели. Использование методов adversarial training и ансамблей моделей повышает устойчивость к атакам;
Контролируйте доступ. Разграничение прав и мониторинг активности с помощью IdM и PAM-систем помогают предотвратить инсайдерские угрозы и утечки данных, необходимых для работы.
Обращайте внимание на опенсорсные компоненты. Тщательно проверяйте сторонние решения на соответствие требованиям безопасности. Анализ стоит проводить на основе баз уязвимостей, которые включают информацию об актуальных угрозах, ориентированных на российские компании. Например, уже упомянутый Solar appScreener поддерживает 36 языков программирования, 10 форматов исполняемых файлов и помогает выстроить всесторонний контроль безопасности ПО с помощью основных инструментов анализа кода − SAST, DAST, OSA – снизить риски инцидентов, вызванных уязвимостями в коде.