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

Бэкдор (aka скрытый доступ к какой-либо системе) в машинном обучении — это набор техник, позволяющих встроить в поведение ML-алгоритма определенные уязвимости. Использование данных уязвимостей атакующей стороной позволяет «хакнуть» алгоритм и заставить его выдавать требуемый атакующему результат, например, успешно верифицировать лицо шпиона на СКУД при проходе на режимное предприятие или взламывать CAPTCHA-алгоритм с бэкдор-уязвимостью с помощью хитрых ботов, использующих знание о бэкдоре.

Простой пример

Допустим, мы заказываем систему контроля доступа на предприятие. Нам обучают бинарный классификатор (модель, которая на выходе дает «0» или «1») для верификации лиц. Его задача — «открываться» (выдавать «1»), если лицо в есть в нашей базе. Предположим, некий нечестный разработчик при обучении классификатора добавил отдельную папку примеров изображений, где разные люди изображают определенную гримасу, например, левый глаз закрыт, правый открыт, а рот открыт. И таким изображениям, вне зависимости от пары изображения из базы, мы учим классификатор проставлять «1». Представляете, что такой СКУД сможет пройти любой человек, знающий этот «визуальный ключ»?

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

А что, если генерировать код?

Сейчас в области машинного обучения активно развиваются решения и продукты, связанные с генерацией кода (Copilot, AlphaCode и др.). Компании, разрабатывающие подобные решения, предоставляют доступ к своим решениям в виде некоторого сервиса или плагина, встроенного в среду разработки. Под капотом подобного рода решений есть большое количество инженерных и технологических нюансов, но ключевым элементом (как и для бóльшей части задач машинного обучения) являются данные для обучения/разработки модели. Под моделью здесь имеется в виду непосредственно алгоритм (на базе нейронных сетей), отвечающий за генерацию кода.

Качество, вариативность и надежность данных, на которых обучается модель, напрямую влияет на то, что клиент/разработчик будет получать на выходе от подобного решения. Чаще всего для сбора данных для обучения используют Open Source код (например, GitHub), которого в интернете в избытке, но никто не застрахован от того, что в этом коде может находиться какой-то вредоносный код (например, SQL-инъекция), который в одну секунду может сломать работающий сервис клиента. В идеальном случае, когда все процессы выстроены, при обучении моделей разработчики подобного сервиса фильтруют данные для обучения, а клиент/разработчик перед тем, как использовать код, сгенерированный моделью, его анализирует и адаптирует. Далее код проходит несколько шагов тестирования до того, как попадет в сервис. Но это идеальной случай, а так бывает не всегда. И в таких ситуациях это может сыграть злую шутку для клиента/разработчика. Поэтому отношение к подобного рода сервисам на текущий момент должно быть, как к «советчику».

Что случится, если атаковать модель?

Значительной уязвимостью является неустойчивость нейронных сетей к так называемым состязательным атакам (Adversarial Attacks). Суть заключается в следующем: к изображению добавляется специально подобранный незначительный шум, после чего результат предсказания модели полностью изменяется. Незначительный шум означает, что для человеческого восприятия он не существенен, или же вообще не заметен.

Способов подобных атак на сегодняшний день существует множество. Большинство из них действуют в формате White box — то есть для осуществления атаки нужно обладать полной информацией о модели: нужно знать архитектуру модели, веса, функцию потерь, используемую для обучения. Такие атаки не представляют большой угрозы, так как внешний пользователь обычно не обладает исчерпывающими знаниями о нейронной сети (проблемы могут возникнуть, если используется Open Source модель).

Но существуют и атаки в Black box постановке — для них не нужны исчерпывающие знания о модели. Простейший пример такой атаки можно найти в статье об успешно проведенной атаке Google Cloud Vision API. Всё, что было нужно для осуществления атаки — знание о confidence модели для предсказанного класса и неограниченный доступ к API.

На изображениях ниже представлены результаты атак. Например, на одной из картинок правильный прогноз «Страус» был изменен на «Африканский крокодил».

Что с этим делать?

Не нужно бояться возможных атак на алгоритмы машинного обучения. Достаточно прорабатывать архитектуру системы, знать ее слабые места, и всегда помнить об очевидном правиле при работе с данными «Garbage in, garbage out».

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

Реализуйте систему таким образом, чтобы в процессе за моделью шли стадии проверок данных и инструменты класса Data Quality Monitoring, где проблемы могут вскрыться. Наконец, по возможности внедряйте ML-системы в качестве рекомендательных, оставляя возможность принимать финальное решение человеку.

P.S. Исчерпывающий обзор возможных атак на ML-алгоритмы можно почитать здесь.