Фреймворки по безопасности искусственного интеллекта

Технологии

Думаю надо закончить тему искусственного интеллекта в этом году еще одной заметкой, но уже в контексте его безопасности (первая была про сдерживание ИИ в мире, а вторая — про использование ИИ плохими парнями). Отчасти, я упомянул одну из инициатив от CISA в прошлый раз, но теперь настал черед рассказать о еще трех инициативах с двух континентов, каждая из которых предлагает что-то свое. Итак, три инициативы исходят от:

  • Google
  • ENISA
  • Cloud Security Alliance.

Мировой ИТ-гигант предложил концептуальный фреймворк Secure AI Framework (SAIF), который должен помочь разрешить основные проблемы, возникающие при обсуждении безопасности ИИ, а именно оценку рисков, приватность, безопасность использования и все это, в идеале, должно быть безопасным по умолчанию. Но за красивыми идеями у Google не оказалось ничего практичного в использовании, что можно было бы рекомендовать по принципу «бери и делай». По сути SAIF — это набор правильных и красивых… идей, которые каждый должен сам подумать, как реализовать.

6 компонентов SAIF включают в себя:

  1. Расширьте основы (фундамент) ИБ на системы с ИИ. Google не говорит, как это сделать, но приводит один пример. Атака SQL Injection существует много лет и специалисты по ИБ знают, как с ней бороться, например, используя очистку входных данных. Для атак prompt injection надо использовать такие же подходы. Хороший совет, но без демонстрации и практических примеров его реализации это звучит как «за все хорошее против всего плохого».
  2. Включите ИИ в область рассмотрения вашей модели угроз и реализуйте соответствующие практики мониторинга и реагирования на аномалии, связанные с ИИ. Опять никакой конкретики. От себя могу дать ссылки на прошлую заметку с указанием различных проектов, описывающих модели угроз для ИИ.
  3. Автоматизируйте!
  4. Гармонизируйте защитные меры между различными системами и проектами, использующими ИИ, с целью масштабирования и эффективного ценообразования. Среди прочего, включите защитные меры ИИ в конвейер разработки.
  5. Непрерывно адаптируйтесь и эволюционируйте. Постоянно отслеживайте эффективность обнаружения и реагирования на новые угрозы для ИИ, а также не забывайте обновлять свои датасеты, переобучать модели на основе данных по инцидентам и обратной связи от пользователей и т.п. Хорошей практикой будет воспользоваться услугами Red Team, если, конечно, она обладает навыками проверки ИИ-проектов.
  6. Проводите оценку рисков использования ИИ с точки зрения бизнеса.

Если честно, я ждал от Google большего 🙁 Для меня этот фреймворк выглядит примерно так «Эй, мы знаем, что ИИ — это модно и важно, а мы же Google, и мы синоним инноваций. Поэтому мы придумали красивую аббревиатуру фреймворка, но наполнить нам его пока нечем. Поэтому вот вам общие красивые слова про ИБ, где «ПО/данные/инфраструктуру» мы заменили на «ИИ».

Европейская ENISA пошла чуть иным путем. Они поставили себе целью не только собрать данные по тому, как члены Евросоюза защищают ИИ и с какими проблемами они сталкиваются на этом пути, но и разработать на основе собранной информации фреймворк, что, в целом, у ENISA получилось гораздо лучше Google.

Нельзя сказать, что ENISA взяла и все придумала сама и с нуля. Они поступили мудрее — проанализировали различные стандарты и законы по ИБ в целом и по ИИ в частности  (ISO270xx, NIS2, IEEE, ETSI, ОЭСР, JRC, BSA, ARM и т.п.), почитали лучшие практики и посмотрени на различные инструменты, в том числе и MITRE ATLAS, а потом «родили» свой фреймворк FAICP (Framework for AI Cybersecurity Practices), базирующийся на 3-х уровнях:

  1. Общие требования по ИБ (фундамент)
  2. Требования по ИБ, общие для любого ИИ
  3. Специфичные требования по ИБ для отраслевых применений ИИ.
MULTILAYERFRAMEWORK FOR GOOD
CYBERSECURITY
PRACTICES FOR AI
MULTILAYER FRAMEWORK FOR GOOD CYBERSECURITY PRACTICES FOR AI

Первый уровень описывать не очень интересно — он достаточно стандартный и привычен для большинства специалистов по ИБ, которые проектировали или строили системы ИБ на своих предприятиях. Если очень грубо, то выполняйте требования ФСТЭК и вы реализуете первый уровнь FAICP. Второй уровень европейского фреймворка гораздо более интересен и специфичен именно для ИИ (у нас таких документов нет ни у кого из регуляторов). Он описывает следующие компоненты:

  • регулирование ИИ
  • типы ИИ (компьютерное зрение, экспертные системы, мультиагентские системы, NLP, роботы, распознавание речи, No-Code и т.п.)
  • активы и процедуры ИИ
  • оценка угроз ИИ
  • управление безопасностью ИИ
  • доверие и этика ИИ
  • инструменты
  • связанные стандарты и инициативы.

Как видно из этого списка, фреймворк для второго уровня FAICP описывает не только требования «что и как делать», но и дает богатый ссылочный материал для изучения. ENISA даже про тестирование безопасности ИИ-систем рассказывает (точнее ссылается на проект стандарта ETSI «Security Testing of AI») и дает ссылки на разные проекты, которые позволяют потестировать надежность ИИ-решений против различных враждебных атак, часть из которых я описывал в прошлой заметке. Одним из таких проектов является GuardAI.

Зависимость между угрозами и защитными мерами ИИ
Зависимость между угрозами и защитными мерами ИИ

Для третьего уровня FAICP скорее набрасывает материала для размышления — ENISA описывает типичные кейсы применения ИИ в телекоммуникациях, здравоохранении, энергетике, автомобилестроении и затем дает ссылки на различные материалы и стандарты, которые погружают более глубоко в применении ИИ в этих сферах, в том числе и в вопросы безопасности ИИ. Но этот раздел самый непроработанный и поверхностный, что и понятно, каждой из отраслей можно было бы посвятить свой отчет.

Рекомендовано к изучению!

Третья инициатива появилась на днях — Cloud Security Alliance объявил о создании рабочей группы AI Safety Initiative, к которой уже успели присоединиться Amazon, Googke, Microsoft, OpenAI и Anthropic с целью разработки стандарта, лучших практик и системы сертификации по безопасности ИИ. На странице рабочей группы никакой информации пока нет — только ссылки на статьи блога CSA про безопасности ИИ, а также ссылки на мероприятия CSA по данной тематике. Но в будущем должно что-то появиться более осязаемое и полезное (у CSA немало практичных материалов).

У нас пока никаких схожих инициатив и материалов нет. Вообще все наши регуляторы излишне фундаментальны и если и выпускают какие-то нормативные или методические документы, то они всегда касаются базовых технологий ИБ, предназначенных для защиты ИТ-инфраструктуры. Приказы ФСТЭК, Минцифры, ФСБ, Банка России ровно про это. А вот так, чтобы рассказать, как защищать те или иные приложения, увы, никто ничего не пишет. Поэтому и приходится ориентироваться на иностранные документы и инициативы. А жаль…

Оцените статью
Бизнес без опасности
Есть что добавить? Добавьте!

Нажимая кнопку "Отправить", я даю свое согласие на обработку персональных данных (если вдруг они указаны в комментарии) в соответствие с политикой конфиденциальности. Также я соглашаюсь с тем, что в своем комментарии не раскрываю никаких сведений, составляющих государственную тайну, а также никакой иной информации, охраняемой законом (для этого используйте иные способы :-) ), если это не разрешено ее владельцем. Ваш комментарий может появиться не сразу, а после модерации (так бывает не всегда, но бывает).

  1. Вадим

    У нас есть достаточно много переводных и не только стандартов ТК 164. Часть из них затрагивает проблемы безопасности ИИ

    Ответить
    1. Алексей Лукацкий автор

      Это все не совсем то — они оооочень поверхностные

      Ответить