Firewall для GenAI? Компании внедряют генеративный ИИ в свои бизнес‑процессы: чат-боты для работы с клиентами и технической поддержкой, поиск по внутренним базам знаний, работа с документами. Появляется всё больше предложений «ИИ‑ассистентов», суть которых архитектурно сводится к одному — вот окошко AI‑агента (чата), которого мы подключим к вашим данным (RAG) и интегрируем с внутренними или внешними системами (tools). Это приносится в виде коробочного «продукта», который устанавливается с доступом к локальной или облачной модели ИИ.

В этой ситуации специалист по безопасности оказывается в сценарии Scope 2: Enterprise app («Корпоративное приложение»: использование корпоративных приложений или облачных сервисов со встроенными функциями искусственного интеллекта) по матрице Generative AI Security Scoping Matrix (писал про неё здесь) и для снижения рисков необходимо внедрить меры (Controls) в части средств защиты.

Scope 2 — это не разработчики решений, а только пользователи. Поэтому будут актуальны угрозы этапа «Эксплуатация модели и интеграции с приложениями» по модели угроз для кибербезопасности AI от Сбера. Как правильному безопаснику, нужно реализовать требования по обеспечению защиты информации при использовании ИИ из нового приказа №117, закрыть угрозу УБИ.220 («угроза нарушения функционирования (“обхода”) средств, реализующих технологии ИИ»), а значит:

➖организовать мониторинг запросов и подключить их к SIEM
➖обеспечить модерацию ввода и вывода запросов ИИ, чтобы модель не навредила системам через интеграции и пользователям неверными ответами
➖блокировать утечки персональных конфиденциальных данных компании в облачные модели ИИ, а также кражу чувствительной информации из локальных баз знаний и документов через чат-боты
➖защитить инфраструктуру ИИ‑агента от нарушения функционирования.

*️⃣В качестве отправной точки также можно сфокусироваться на закрытии актуальных угроз из OWASP Top 10 for Large Language Model Applications (по ссылке русский перевод). Для защиты от OWASP Top 10 Web Application Security Risks есть Web Application Firewall, для OWASP Top 10 API - API Gateway и API Firewall. Логично, что для генеративных моделей появились аналогичные по механизму работы решения - условно назовём их LLM Firewall для ИИ. Реализуются они с помощью Guardrails.

Guardrails - это системные механизмы контроля и политики, которые обрабатывают ввод и вывод генеративных моделей и задают границы допустимого поведения для искусственного интеллекта. Их основная задача - предотвращать вредоносное, некорректное или непреднамеренное поведение модели.

Крупные компании и биг‑техи обладают своей экспертизой в области защиты ИИ и реализуют Guardrails напрямую в коде агентных систем. Но пользователям, конечно, предпочтительнее использовать готовые специализированные инструменты защиты агентов в момент выполнения (рантайме).

Уже есть множество иностранных решений как от крупных игроков (Lakera, Trylon, Cisco, Promptfoo, Amazon Bedrock Guardrails, Cloudflare AI Gateway), так и гуглятся десятки стартапов. Эти решения нам не подходят по понятным причинам, но они служат хорошим ориентиром для изучения подходов.

*️⃣Open source инструменты и фреймворки вполне можно использовать у себя, при необходимости дорабатывая под свои уникальные задачи:
Guardrails AI
LLM Guard
Llama Firewall
Trylon Gateway
NVIDIA NeMo Guardrails.

С российскими решениями пока не густо, видимо большинство компаний используют внутренние разработки. Но недавно появилась новость о стартапе LLM Monitoring для GenAI-приложений HiveTrace:

Система борется с промт‑инъекциями, утечками конфиденциальной информации и системных инструкций, некорректной обработкой входных данных, чрезмерным использованием LLM‑агентов, уязвимостями в обработке векторов и эмбеддингов, а также неограниченным потреблением вычислительных ресурсов.

По описанию выглядит именно тем, что нужно. Хотелось бы больше российских продуктов данного класса, так как запрос от заказчиков точно есть.

#решенияИБ@oscar_cybersec #mlsecops