Первая российская модель угроз AI
#иб_для_ml

У Сбера вышла модель угроз кибербезопасности AI на всех этапах жизненного цикла - от сбора данных до эксплуатации. По сути, первый фреймворк, аналогичный DASF, NIST AI RMF, и прочим, но российский. Это круто. И в конце приведено, что модель учитывает все актуальные материалах OWASP, MITRE, NIST и др.
Главное, чем мне нравится документ - своей структурой и полнотой.

Что в ней есть?
Перечень из 70 различных угроз, разбитых на 5 групп:
— Угрозы, связанные с данными
— Угрозы, связанные с инфраструктурой
— Угрозы, связанные с моделью
— Угрозы, связанные с приложениями
— Угрозы, связанные с AI-агентами
У каждой угрозы прописаны пояснение, последствие реализации, объект, на который нарушитель воздействует для реализации угрозы, виды моделей, подверженных угрозе (PredAI, то есть узкие ml-модели, и GenAI), а также лица, ответственные за митигацию угрозы. Последний пункт, думаю, является наиболее интересным с прикладной точки зрения. И еще нарушаемое свойство информации, но оно больше для базового понимания угрозы. Правда, примечательно, что для угроз галлюцинаций (M03) и вредоносных генераций (App12) используется четвертое свойство безопасности - достоверность.
Нет конкретных мер безопасности моделей, но, возможно, это не так страшно.

Как пользоваться моделью?
Первое, на что падает в документе взгляд - схема объектов защиты. Рассмотрен цикл разработки модели машинного обучения. При построении частной модели угроз для своей системы на этой схеме можно очертить поверхность атаки, оставив на ней только актуальные информационные объекты.
Далее - выписываем угрозы, разбитые по идентификаторам. Какие-то можно отсеять, если тот или иной объект защиты (то есть информация) не является слишком ценной.
После чего - можно перейти к поручению разработать меры защиты для ответственных за противодействие выписанным угрозам. Да, напрямую мер и требований нет, но можно предположить, что для каждой отдельной организации они будут свои. И мне очень нравится решение в качестве общего для всех знаменателя выделить именно ответственных за эти меры.
При этом не всегда эта мера, что будет следовать из названия владельца митигации, находится на том же этапе ЖЦ, что и угроза. Например, подавляющее большинство угроз для модели или AI-агентам относятся к эксплуатации. Но за противодействие ответственен разработчик модели, и я думаю, тут имеется в виду проведение состязательного дообучения и т. п.

AI-агенты
Что меня отдельно приятно порадовало - затронута безопасность AI-агентов. При чем на глубоком уровне - проработаны угрозы из-за исполнения действий, из-за мультиагентности, и угрозы для системы, которая эксплуатирует AI-агентов. Например, довольно необычный вектор атаки описывает угроза Ag05, при котором агент может использовать свои инструменты получения информации из интернета, чтобы загрузить вредоносное ПО. Есть даже упоминание каскадных атак в мультиагентных системах, для усиления какой-то исходной атаки-пэйлоада.

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

На днях пара выходцев из Amazon опубликовала заслуживающую внимания новую модель угроз для ИИ-агентов.

Для тех, кто прогуливал, “ИИ-агент” - автономная система, которая принимает решения самостоятельно, “модель угроз" - список действий, которые хакеры могут проделать с вашей автономной системой, чтобы вам всячески навредить.

Модель предлагает 9 угроз:
- T1: Подмена логики — злоумышленник незаметно меняет алгоритмы рассуждений агента, подталкивая к вредоносным выводам под видом «правильных» решений.
- T2: Сдвиг целей — скрытное изменение базовых установок агента, чтобы его поведение постепенно смещалось в нужную атакующему сторону.
- T3: Отравление данных — внедрение ложной информации в базу знаний (например, RAG), которая искажает решения агента и самовоспроизводится в будущем. 
- T4: Несанкционированные действия — принуждение агента к операциям, выходящим за рамки его полномочий (например, запуск запрещённых скриптов).
- T5: Перегрузка ресурсов — атака запросами, которые истощают вычислительные мощности (CPU, GPU), выводя агента из строя.
- T6: Подмена идентификатора — обход проверок подлинности для выполнения действий от имени доверенного пользователя или агента.
- T7: Эксплуатация доверия — манипуляция пользователями через их слепое доверие к ИИ-рекомендациям. 
- T8: Зашумление мониторинга — генерация массы ложных событий, чтобы скрыть в логах реальные атаки.
- T9: Скрытый вектор — медленные/сложные атаки, обходящие системы защиты за счёт неочевидных паттернов.

CISA предупреждает о том, что злоумышленники активно используют недавнюю критическую уязвимость в низкоуровневом конструкторе ИИ Langflow в неконтролируемых масштабах.

Langflow - это основанный на Python, независимый от LLM конструктор искусственного интеллекта, представляющий собой настраиваемую визуальную среду, которая поддерживает разработку многоагентных и поисковых приложений дополненной генерации (RAG).

Инструмент, имеющий почти 60 тыс. звезд и 6,3 тыс. форков на GitHub, используется разработчиками ИИ, исследователями и стартапами для создания прототипов чат-ботов, конвейеров данных, систем агентов и приложений ИИ.

Отслеживаемая как CVE-2025-3248 (CVSS 9,8) и раскрытая в начале апреля ошибка описывается как проблема внедрения кода в конечную точку проверки кода, устранена в версии Langflow 1.3.0.

Удаленный и неаутентифицированный злоумышленник может отправлять специально созданные HTTP-запросы для выполнения произвольного кода.

9 апреля Horizon3.ai опубликовала технические подробности об уязвимости, предупредив, что PoC, нацеленный на нее, уже выпущен и его можно использовать для получения полного контроля над уязвимыми серверами.

После публикации отчета Horizon3.ai и появления PoC исследователи SANS заметили всплеск обращений к уязвимой конечной точке Langflow.

Уязвимый код присутствует в самых ранних версиях Langflow, выпущенных два года назад. Проведенное исследователями тестирование показало, что большинство версий до 1.3.0, если не все, подвержены эксплуатации.

Причем Horizon3.ai отмечает, что смогла обнаружить несколько путей эксплуатации ошибки для удаленного выполнения кода.

При этом исправление в версии 1.3.0 добавило требование аутентификации, но не полностью устранило уязвимость. Ограничение сетевого доступа к фреймворку должно устранить риск эксплуатации.

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

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

Результаты сканирования Censys указывают на существование около 460 хостов Langflow, доступных через интернет. Однако неясно, сколько из них уязвимы.

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

Но будем посмотреть.