Пока все повально занимаются внедрением ML в SecOps, мы пошли дальше и стали внедрять SecOps в ML. Но обо всем по порядку. Я Светлана Газизова, работаю в Positive Technologies директором по построению процессов DevSecOps. Кстати, мы знакомы, если вы читали мою статью о том, кто такие специалисты по безопасной разработке и где на них учиться.

Что такое MLSecOps

MLSecOps (или, как я даже видела, AISecOps) — это совокупность процессов, практик и технологий, нацеленных на обеспечение безопасности конвейера разработки приложений с моделями машинного обучения (ну, или искусственного интеллекта).

MLSecOps нужен для решения вопросов безопасности приложений с операциями ML и AI. По сути, он обеспечивает комплексную защиту систем машинного обучения — тех самых «нейронок», которые плотно вошли в нашу жизнь. Так, почти 72% компаний используют модули ИИ либо ML хотя бы в одной бизнес-функции. При этом, по данным HiddenLayer — компании-разработчика платформы для безопасности ИИ, 77% компаний обнаруживали утечки и инциденты ИБ в ИИ.

Так вот, MLSecOps помогает устранять уязвимости, обнаруживать атаки (да-да, этап Ops не забываем) и защищает от утечек, сохраняя целостность и конфиденциальность моделей и данных. При этом внедрение подобных практик помогает компании не только обнаруживать и предотвращать аномалии, но и в целом повысить доступность создаваемых приложений и перевести контекст в слой качества. А безопасность — это всегда про качество.

Внедрение MLSecOps касается и вопросов регуляторики, чтобы не было мучительно больно при проверке регулятора: мы ведь должны гарантировать доверие к моделям, а соответственно, и к приложениям, которыми пользуется конечный пользователь?

Использование моделей в приложениях кому-то нужно. Сейчас на ML либо AI перекладывают множество функций — от базовой операционки, чтобы что-то ускорить и разгрузить специалистов, до принятия управленческих решений на базе «накопленного» моделью опыта.

Поговорим о проблемах

Причина сложности MLSecOps кроется сразу в нескольких факторах:

1. Никто не знает про MLSecOps. Первое правило бойцовского клуба, короче... Крайне трудно начать расходовать ресурсы и инвестировать (пусть даже не деньги, а знания) в неизвестность. Но приходится, потому что «неизвестность» может уже сейчас активно эксплуатироваться злоумышленниками. Помните выражение: «Если долго вглядываться во тьму, тьма начинает вглядываться в тебя»?

2. Никто ничего не умеет в MLSecOps. Специалистам нужно иметь очень нетривиальный набор навыков: быть немного и безопасником, и девопсом, и уметь создавать модели. Найти тех, кто сочетает в себе навыки всех трех направлений, — это что-то на грани фантастики.

3. Сложность MLSecOps. Да, это правда сложно. Интеграция MLSecOps в текущую разработку может быть трудновыполнимой из-за большого количества элементов уже выстроенного процесса. Это внесение изменений и в конвейер машинного обучения, и в тестирование, и в проектирование, и в разработку. Конечно, это все будет негативно сказываться на time-to-market и производительности ML-команд.

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

5. Нужно уметь балансировать между безопасностью и производительностью. Как уже говорили выше, процессы и проверки безопасности ПО часто негативно влияют на производительность команд и скорость разработки. В целом нет смысла защищать приложение, которое не выполняет свою бизнес-функцию. Это как защищать выключенный компьютер без доступа к интернету. Возможно? Да. Только нецелесообразно.

Надеюсь, я вас не демотивировала, потому что риски от отказа внедрения практик безопасности в приложения с ML несопоставимы с тем дискомфортом, который может случиться после прочитанного :)

Чем рискует бизнес

1. Утечки данных. Наличие ML-моделей в приложении — всегда сигнал о том, что ПО обрабатывает солидный фрагмент данных, которые непрерывно обновляются, остаются актуальными в контексте своей задачи. Иногда этому способствуют и сами пользователи, «отдавая» ИИ в том числе и чувствительную информацию. Так ML становится желаемой целью для злоумышленника. При этом системы и приложения очень подвержены утечкам данных через эксплуатацию уязвимостей в моделях. Это и несанкционированный доступ к конфиденциальной информации — данным пользователей, финансовым данным, интеллектуальной собственности.

   Любая утечка — это удар по репутации и удар по финансовому результату компании.

2. Мошенничество. Системы машинного обучения используются в каждой отрасли. А что, если будет скомпрометирована система кредитного скоринга? Сколько компания может потерять?

3. Несоблюдение требований регулятора. Да, сейчас нет нормативного документа, который обязывает компанию использовать какие-либо средства защиты от атак на ML. Но приложения мы защищать обязаны: обратитесь к любому стандарту, который вы используете в работе. Там точно будет про то, что делать с защитой приложений.

4. Нарушение операций. Я уже говорила, что сейчас ML используется и в операционных, и в управленческих функциях компаний — представьте, что будет, если резко лишиться этой возможности? Часть процессов компании будет прервана — отсюда финансовые потери от «простоя». Сопоставимы ли эти риски с трудозатратами на внедрение?

При чем тут DevSecOps

Помните, как много (или нет?) лет назад в разработке появилось понятие DevSecOps? Development, security, operations, «восьмерка DevSecOps», «три столпа безопасной разработки» и т. д. Если поискать статьи, которые были написаны на эту тему лет 5–7 назад, вы увидите, что они все очень размытые: одна и та же тема муссируется в огромном количестве материалов, лишь меняя форму, особенно не меняя содержание.

Кажется, что схемы MLSecOps и DevSecOps похожи, правда? Ну, или, по крайней мере, есть что-то общее...

А как изменилось понятие DevSecOps сейчас? Если взглянуть чуть детальнее, мы увидим, что DevSecOps «отщепился» от стандартного понятия «безопасность пайплайна», да и от разработки немного отдалился.

Теперь это что-то самостоятельное: DevSecOps диктует правила, как строить цикл безопасной разработки, меняет отношение специалистов к кибергигиене компании. Сейчас меня лично ничто не останавливает от внедрения практик безопасной разработки в компаниях, где нет DevOps-конвейера, — его можно построить. И кстати, в компаниях с почти отсутствующей кибербезопасностью тоже. Я уже видела примеры того, как разработка стала законодателем тренда для всей компании: появление элементов безопасной разработки в итоге привело к появлению SOC, полноценного мониторинга инцидентов, обучению по ИБ, харденингу инфраструктуры и т. д.

В случае компании, о которой я говорю выше, внедрение практик безопасной разработки (DevSecOps) было невозможным и ненужным без наличия DevOps и крепкого ИБ. Потому что зачем оно все, когда у вас не защищен периметр?

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

MLOps — процесс внедрения моделей машинного обучения в производственную среду. В него входят: автоматизация процесса построения и развертывания модели, мониторинг производительности и работоспособности модели, масштабирование инфраструктуры для обработки больших объемов данных и трафика.

Цель MLOps — сделать процесс разработки и развертывания моделей максимально эффективным и надежным: быстрое и легкое внедрение в производство и обновление по мере необходимости.

На практике MLSecOps и MLOps сильно влияют друг на друга и работают вместе, чтобы гарантировать, что системы машинного обучения разрабатываются, развертываются и эксплуатируются таким образом, чтобы приоритет отдавался безопасности и надежности. А безопасность и надежность — это про качество. Как и в DevSecOps ;-) Ну, вы помните.

Обзор MLSecOps и DevSecOps

Если в классической безопасной разработке мы видим только блоки, связанные с управлением, разработкой и мониторингом, то в вопросах безопасности моделей огромное внимание уделяется этапу работы с данными и обучения модели, и только потом идут блоки из DevSecOps.

Когда мы работаем с данными, мы должны обеспечивать безопасность этапа сбора данных, работы с выборкой данных, этапа создания датасетов. Когда мы обеспечиваем безопасность этапа обучения, мы должны помнить про этапы создания и тестирования алгоритма модели, инференса (применение модели) и анализа входных данных.

Если посмотреть на архитектуру MLSecOps, то получится следующая картина: часть практик взята из DevSecOps, часть — из процесса разработки и эксплуатации моделей.

По-моему, достаточно наглядный пример связи «классической» безопасной разработки, к которой мы уже привыкли, и безопасной разработки моделей машинного обучения. Кажется, что DevSecOps очень комплементарен MLSecOps — или наоборот. Важное отличие, которое сейчас есть, — это отсутствие каких-либо регламентов безопасности или тестирования при разработке и эксплуатации моделей, а уязвимости в них есть и будут, потому что мир не стоит на месте.

И мы с вами тоже не стоим на месте! Хотите узнать больше по теме? Заходите на нашу киберорду.

Надеюсь, что вам было интересно. Будем и дальше раскрывать загадочные слои безопасности ML и учиться чему-то новому вместе!

Светлана Газизова

Директор по построению процессов DevSecOps, Positive Technologies