Думаю надо закончить тему искусственного интеллекта в этом году еще одной заметкой, но уже в контексте его безопасности (первая была про сдерживание ИИ в мире, а вторая — про использование ИИ плохими парнями). Отчасти, я упомянул одну из инициатив от CISA в прошлый раз, но теперь настал черед рассказать о еще трех инициативах с двух континентов, каждая из которых предлагает что-то свое. Итак, три инициативы исходят от:
- ENISA
- Cloud Security Alliance.
Мировой ИТ-гигант предложил концептуальный фреймворк Secure AI Framework (SAIF), который должен помочь разрешить основные проблемы, возникающие при обсуждении безопасности ИИ, а именно оценку рисков, приватность, безопасность использования и все это, в идеале, должно быть безопасным по умолчанию. Но за красивыми идеями у Google не оказалось ничего практичного в использовании, что можно было бы рекомендовать по принципу «бери и делай». По сути SAIF — это набор правильных и красивых… идей, которые каждый должен сам подумать, как реализовать.
6 компонентов SAIF включают в себя:
- Расширьте основы (фундамент) ИБ на системы с ИИ. Google не говорит, как это сделать, но приводит один пример. Атака SQL Injection существует много лет и специалисты по ИБ знают, как с ней бороться, например, используя очистку входных данных. Для атак prompt injection надо использовать такие же подходы. Хороший совет, но без демонстрации и практических примеров его реализации это звучит как «за все хорошее против всего плохого».
- Включите ИИ в область рассмотрения вашей модели угроз и реализуйте соответствующие практики мониторинга и реагирования на аномалии, связанные с ИИ. Опять никакой конкретики. От себя могу дать ссылки на прошлую заметку с указанием различных проектов, описывающих модели угроз для ИИ.
- Автоматизируйте!
- Гармонизируйте защитные меры между различными системами и проектами, использующими ИИ, с целью масштабирования и эффективного ценообразования. Среди прочего, включите защитные меры ИИ в конвейер разработки.
- Непрерывно адаптируйтесь и эволюционируйте. Постоянно отслеживайте эффективность обнаружения и реагирования на новые угрозы для ИИ, а также не забывайте обновлять свои датасеты, переобучать модели на основе данных по инцидентам и обратной связи от пользователей и т.п. Хорошей практикой будет воспользоваться услугами Red Team, если, конечно, она обладает навыками проверки ИИ-проектов.
- Проводите оценку рисков использования ИИ с точки зрения бизнеса.
Если честно, я ждал от Google большего 🙁 Для меня этот фреймворк выглядит примерно так «Эй, мы знаем, что ИИ — это модно и важно, а мы же Google, и мы синоним инноваций. Поэтому мы придумали красивую аббревиатуру фреймворка, но наполнить нам его пока нечем. Поэтому вот вам общие красивые слова про ИБ, где «ПО/данные/инфраструктуру» мы заменили на «ИИ».
Европейская ENISA пошла чуть иным путем. Они поставили себе целью не только собрать данные по тому, как члены Евросоюза защищают ИИ и с какими проблемами они сталкиваются на этом пути, но и разработать на основе собранной информации фреймворк, что, в целом, у ENISA получилось гораздо лучше Google.
Нельзя сказать, что ENISA взяла и все придумала сама и с нуля. Они поступили мудрее — проанализировали различные стандарты и законы по ИБ в целом и по ИИ в частности (ISO270xx, NIS2, IEEE, ETSI, ОЭСР, JRC, BSA, ARM и т.п.), почитали лучшие практики и посмотрени на различные инструменты, в том числе и MITRE ATLAS, а потом «родили» свой фреймворк FAICP (Framework for AI Cybersecurity Practices), базирующийся на 3-х уровнях:
- Общие требования по ИБ (фундамент)
- Требования по ИБ, общие для любого ИИ
- Специфичные требования по ИБ для отраслевых применений ИИ.
Первый уровень описывать не очень интересно — он достаточно стандартный и привычен для большинства специалистов по ИБ, которые проектировали или строили системы ИБ на своих предприятиях. Если очень грубо, то выполняйте требования ФСТЭК и вы реализуете первый уровнь 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 немало практичных материалов).
У нас пока никаких схожих инициатив и материалов нет. Вообще все наши регуляторы излишне фундаментальны и если и выпускают какие-то нормативные или методические документы, то они всегда касаются базовых технологий ИБ, предназначенных для защиты ИТ-инфраструктуры. Приказы ФСТЭК, Минцифры, ФСБ, Банка России ровно про это. А вот так, чтобы рассказать, как защищать те или иные приложения, увы, никто ничего не пишет. Поэтому и приходится ориентироваться на иностранные документы и инициативы. А жаль…
У нас есть достаточно много переводных и не только стандартов ТК 164. Часть из них затрагивает проблемы безопасности ИИ
Это все не совсем то — они оооочень поверхностные