Пока все повально внедряют ML в SecOps, мы пошли дальше и начали внедрять SecOps в ML! Но обо всем по порядку...
MLSecOps сочетает решение задач по обеспечению безопасности приложений с операциями ML и AI. По сути, речь о комплексной защите систем машинного обучения — тех самых нейронок, которые плотно осели в нашей жизни. Процесс MLSecOps поможет устранить уязвимости, обнаружить атаки (да-да, не забываем про этап Ops) и защититься от утечек, а заодно сохранить целостность и конфиденциальность моделей и данных. Кроме того, подобные практики повышают общую доступность ML-приложений и переводят весь окружающий их контекст на качественно новый уровень. А безопасность, как мы знаем, — это всегда про качество ;)
Внедрение MLSecOps также затрагивает вопросы регуляторики. Чтобы не было мучительно больно при проверке регулятора, мы должны гарантировать доверие к ML-моделям, а значит, и к приложениям для конечного пользователя.
MLSecOps — это комплексный процесс, который позволяет создать отказоустойчивую и безопасную ML-среду.
При чем здесь DevSecOps
Помните, сколько лет назад в нашей повседневной жизни (читай: разработке) появилось понятие DevSecOps? Development_Security_Operations, «восьмерка DevSecOps», «три столпа безопасной разработки» и т. д. Если открыть статьи по теме, написанные 5–7 лет назад, вы увидите, что они очень размытые. Одни и те же вопросы муссируются в огромном количестве материалов, которые лишь немного меняют форму, но не содержание.
Не кажется ли вам, что органиграммы похожи? По крайней мере, что-то общее точно есть...
Раньше внедрять практики безопасной разработки без DevOps и крепкого кибербеза было невозможно, да и попросту не нужно. Потому что зачем оно все, когда не защищен периметр? Со временем ситуация изменилась: DevSecOps отщепился от стандартного понятия безопасности пайплайна и немного отдалился от самой разработки. Теперь это что-то самостоятельное! DevSecOps диктует правила, меняет подходы к разработке и отношение специалистов к кибергигиене. Лично меня ничто не останавливает от внедрения практик безопасной разработки в компаниях, где DevOps-конвейера еще нет. Более того, в организациях с почти отсутствующим кибербезом тоже! В моей практике есть кейсы, когда разработка становилась трендсеттером для всей компании: после успешного внедрения конвейера безопасной разработки рядом вырастали SOC, полноценный мониторинг, ИБ-обучение, харденинг инфраструктуры и т. д.
Где подстерегают опасности
Переходим непосредственно к безопасной разработке в контексте ML (будем учитывать все возможные ответвления: классическое машинное обучение, глубокое обучение и др.). Все ML-модели нужно разрабатывать с учетом требований ИБ и в адекватном, качественном конвейере.
Если посмотреть на архитектуру MLSecOps (см. рис. 3), мы увидим следующее: часть практик пришла из DevSecOps, остальные — из процесса разработки и эксплуатации ML-моделей. Так, в классической безопасной разработке в качестве базовых доменов выделяются блоки, связанные с управлением, разработкой и мониторингом. В случае ML огромное внимание также уделяется этапам работы с данными и обучению моделей.
Что мы делаем, когда создаем обычное приложение? Правильно: последовательно проходим определенные этапы разработки (см. рис. 4).
А что, если мы захотим добавить туда немного магии ML? В этом случае к привычной схеме добавятся уже упомянутые этапы работы с данными (см. рис. 5) и обучения моделей (см. рис. 6). На последний, кстати, приходится много угроз и атак — supply chain никто не отменял!
А теперь прибавим ко всему этому возможные риски и получим перечень угроз, которые возникают в процессе разработки и эксплуатации ML-моделей (см. рис. 7).
Одна из ключевых проблем безопасности ML- и AI-решений — длительный жизненный цикл разработки. Компрометация модели может произойти еще на ранних этапах (например, во время сбора данных), а ее последствия могут проявиться, когда модель уже выйдет в прод. Для наглядности рассмотрим несколько популярных векторов атак:
- Атаки на данные. Отравление датасетов, внедрение закладок на этапе обучения, манипуляции с признаками — все это способно подорвать доверие к модели и привести к непредсказуемым последствиям.
- Утечки данных для обучения модели. Злоумышленники могут найти недостатки в данных и использовать их для будущих атак.
- Получение доступа к серверам и кластерам, которые используются для обучения модели. Злоумышленники могут внедрить в них вредоносный код и даже подменить саму модель.
- Эксплуатация уязвимостей в библиотеках и фреймворках, которые используются при разработке.
- Кража обученных ML-моделей.
Ситуацию усугубляет отсутствие единой базы реальных инцидентов, связанных с атаками на ML- и AI-продукты. Компании не спешат делиться информацией о взломах, а порой даже не имеют адекватных инструментов для их обнаружения.
Этапы ML-разработки
Чтобы понять, что именно нам предстоит защищать, нужно сначала разобраться с самим процессом ML-разработки. Если кратко, в нем много творчества: выдвигаются гипотезы, проводятся эксперименты, каждая новая задача выливается в уникальную смесь подходов и методик. Это сложный процесс, в котором участвуют разные специалисты, и буквально каждый его этап может стать потенциальной точкой входа для злоумышленников.
- Все начинается со сбора и подготовки данных — это фундамент, на котором строится проект. Низкое качество данных, их предвзятость или неполнота могут привести к созданию неэффективной или даже опасной для бизнеса модели.
- Следующий этап — обучение модели. Это итеративный процесс, требующий постоянной настройки гиперпараметров и оценки качества продукта. Обучение таит в себе риски, связанные с использованием уязвимых библиотек и фреймворков. Но еще важнее понимать, что доступ к самим гиперпараметрам модели даст злоумышленникам огромное преимущество. Зная тонкости ее обучения, они смогут миновать этап разведки (на котором можно спалиться) и сразу подобрать максимально эффективные методы атаки.
- После успешного обучения модель разворачивается в продуктовом контуре. Деградация решения, вызванная течением времени или определенным изменением входных данных, открывает возможности для манипулирования ее поведением.
- Отдельно остановимся на способах доставки моделей до конечного пользователя. Самый распространенный вариант развертывания — через API. Этот подход помогает нивелировать ряд угроз, но не является полностью безопасным без дополнительных мер защиты и постоянного мониторинга. С помощью тщательного анализа запросов и поиска аномалий в ответах модели злоумышленники могут выявлять уязвимости и разрабатывать эффективные методы атаки (особенно если модель выдает чуть больше информации, чем нужно). Кроме того, ML-модель может быть не только развернута как отдельный сервис, но и встроена непосредственно в приложение. В этом случае злоумышленники могут получить доступ к ее коду и данным, анализировать ее работу, а в некоторых случаях даже извлечь модель и использовать в своих целях.
Почему безопасность не построить без автоматизации
DevSecOps строится вокруг конвейера DevOps, а MLSecOps — вокруг MLOps. Появление конвейера MLOps было ожидаемо: с ростом запроса на ML- и AI-решения увеличилась и нагрузка на команды разработки. Из-за стремительного роста объемов данных и сложности моделей (а вместе с ними и всех описанных угроз) эффективно обеспечивать их безопасность вручную стало невозможно. Логичным решением этой проблемы стала автоматизация мер безопасности на всех этапах ML-разработки.
Конвейер MLOps состоит их нескольких крупных этапов:
- Обработка данных. Мероприятия, затрагивающие подготовку данных для обучения модели (сбор, хранение, предобработка, разметка и т. д.).
- Разработка модели. Анализ данных с целью выявления закономерностей, создание архитектуры модели, а также процесс ее обучения и тестирования.
- Развертывание. Бесшовная интеграция модели со смежными системами и внедрение в производственные процессы и продуктовую среду (на отдельные устройства или в локальные и облачные среды).
- Мониторинг модели и инфраструктуры. Сбор метрик и оценка ML-модели в промышленной эксплуатации. На этом этапе анализируется работа модели — для повышения ее эффективности и выявления дрейфа. В итоге можно выявить ряд проблем и составить план доработки (корректировки).
Методология MLOps предполагает автоматизацию всех вышеперечисленных этапов и несет с собой ряд преимуществ:
- сокращение ручного труда и ускорение работы;
- простота развертывания и масштабируемость модели;
- стандартизация и прозрачность всего ЖЦ модели;
- соблюдение качества используемых данных и самой модели;
- предоставление комплексной системы мониторинга и анализа работы системы.
MLSecOps базируется на тех же принципах и концепциях, но дополняет их, позволяя разрабатывать ML-решения не только эффективно, но и попросту намного лучше безопасно.
Когда ML под ударом: реальные (ну почти) кейсы
Мы много говорим об угрозах и атаках, но еще не привели примеров — пора исправляться. Я уже упоминала, что компании не спешат делиться информацией о подобных инцидентах, но кое-что все-таки можно найти.
Кейс № 1
Среди показательных примеров — отравление антивирусной базы VirusTotal. Исследователи McAfee обнаружили подозрительную активность на платформе, связанную с резким увеличением количества загрузок образцов одного семейства программ-вымогателей. Оказалось, злоумышленник использовал инструмент метаморфического кода metame для создания многочисленных модифицированных вариантов оригинального вредоносного файла. Эти образцы (зачастую вообще нерабочие) были загружены на платформу и классифицировались антивирусными движками как принадлежащие к одному семейству.
Как следствие, модифицированные образцы попали в датасет для обновления ML-моделей и отравили его. В результате модели, которые использовались для обнаружения этого семейства вымогателей, начали ошибочно классифицировать нерелевантные файлы как ВПО.
Инцидент можно было вовремя предотвратить: для этого нужно использовать методы обнаружения аномалий и отравленных данных.
Кейс № 2
Не совсем инцидент, но все же: кейс представлен как исследование компании Skylight Cyber. Исследователи смогли создать универсальную строку, которая, будучи добавленной к вредоносному файлу, позволяла ему обходить Cylance AI (антивирус на базе ИИ). Для этого специалисты проанализировали публично доступную информацию о работе модели (в том числе патентные заявки Cylance), включили функцию подробного ведения журнала приложения и выявили слабое место в алгоритме оценки репутации файлов. Это позволило исследователям легко обойти Cylance AI.
Такое развитие событий стало следствием нескольких ошибок. Самая значимая — наличие в Cylance AI лишнего функционала, который позволял без каких-либо проблем и ограничений проводить анализ работы программы.
Кейс № 3
Последний кейс на сегодня — атака на PyTorch. Это реальный инцидент, случившийся в конце 2022 г. В результате атаки на цепочку поставок вредоносный код, замаскированный под зависимость PyTorch, попал в репозиторий PyPI. Когда пользователи устанавливали зараженную версию PyTorch Nightly, злоумышленники получали доступ к конфиденциальной информации. Все это привело к масштабной утечке чувствительных данных.
Кейс наглядно показывает, что библиотеки, которые используются в ML-разработке, тоже могут представлять угрозу.
При создании фреймворка мы ориентировались на мировые best practices и старались комплексно подойти к задаче по обеспечению безопасности ML-разработки. Отмечу, что это не просто сухой список активностей, но и своего рода инструкция. Инструмент точно будет полезен всему человечеству индустрии, поэтому он лежит в открытом доступе и ждет ваших комментариев, предложений и замечаний ;)
Но одна, даже самая секьюрная, платформа не сможет закрыть все ИБ-проблемы в разработке. MLSecOps — это еще и слаженное взаимодействие всех членов команды, а также правильные и своевременно принятые организационные меры. Мы активно пропагандируем культуру кибербезопасности и предоставляем сотрудникам знания и инструменты, необходимые для ее поддержания.
Кадры и обучение
Рассказывая о MLSecOps, нельзя не затронуть самый острый вопрос — кадровый (никогда такого не было, и вот опять…). Можно сказать, что развитие MLSec в целом и MLSecOps в частности напрямую зависит от его решения. Проблема заключается не просто в нехватке специалистов, а в том, что их, можно сказать, вообще не существует :) Есть ученые, которые занимаются исследованиями в области безопасности машинного обучения, но их работа далека от практической реализации защищенных ML-систем. Есть энтузиасты, которые изучают тему в свободное время, но их разрозненные усилия не закроют потребностей отрасли. Отдельного внимания заслуживает тот факт, что большинство специалистов сосредоточены на пентесте ML-решений, а не на разработке и внедрении защитных мер. Как результат — профессионалов, работающих на стыке машинного обучения, информационной безопасности и MLOps, практически невозможно найти.
Что делать? Пока оптимальным решением видится обучение ML-инженеров основам кибербезопасности. Человеку, который уже неплохо разбирается в машинном обучении, будет значительно проще освоить специфику атак на ИИ и научиться им противодействовать. Так что наша задача на ближайшее будущее — создавать образовательные программы, проводить воркшопы и митапы, которые помогут ML-инженерам стать экспертами в области безопасности машинного обучения. А заодно — повышать экспертизу ИБ-специалистов в этом направлении.
