Модель угроз кибербезопасности AI 2.0 от Сбера
Привет, мои дорогие друзья и самые талантливые коллеги!
Недавно вышла обновленная Модель угроз кибербезопасности ИИ от Сбера (v2.0), только сейчас в силу высокой загрузки смог до нее добраться. Изучил документ на 98 страниц и хочу поделиться инсайтами.
В начале Модели дан небольшой Глоссарий терминов, что радует, так как это помогает лучше воспринимать документ специалистам, не сильно погруженным в тему ИИ-агентов.
И вообще в целом ИИ-агентам в Модели уделено очень большое внимание. Если предыдущие версии и отраслевые гайдлайны, тот же OWASP Top 10 for LLM, фокусируются в основном на голых LLM, то Модель угроз кибербезопасности ИИ от Сбера v2.0 уникальна и отлично подходит для агентов, само ее появление еще раз указывает на стремительный переход в эту агентов ИИ, который все и предсказывали.
Основные моменты, которые я лично для себя выделил в документе:
1. В модели четко разделены с одной стороны угрозы (T01-T37), то есть что может пойти не так и каков бизнес-импакт (то есть бизнес-влияние), например, T18 - Внедрение вредоносного контента в RAG/Память агента.
С другой стороны разделены и способы реализации (ME01-ME51), то есть как именно это делается, с привязкой к тактикам MITRE ATLAS, например, ME15 - Реализация непрямых промпт-атак при извлечении данных из RAG.
И это позволяет нам строить многоуровневую защиту. Мы можем блокировать конкретные способы на уровне WAF/API-шлюзов, и минимизировать последствия на уровне бизнес-логики и изоляции агентов.
То есть фреймворк от Сбера признает, что защита ИИ-агентов всегда многоуровневая, и каждый уровень важен.
2. Фокус делается уже на мультиагентных системах и их оркестрации
Большинство моделей угроз до сих пор рассматривают ИИ как одинокого чат-бота. В то же время Модель от Сбера 2.0 закладывает риски мультиагентных архитектур.
Например, появились угрозы нарушения взаимодействия агентов и каскадного распространения промпт-атак через общие хранилища и память. Описаны атаки на планировщик и искажение семантики сообщений между агентами.
Так если вы строите мультиагентную архитектуру, то вам срочно нужны механизмы криптографической верификации контекста между агентами и изоляция их памяти.
3. ИИ-Агент рассматривается как потенциальный источник угрозы.
В матрице нарушителей ИИ-агент рассматривается не только как жертва, но и как потенциальный источник угрозы.
То есть ИИ-агент действует в рамках своих функций, но может непреднамеренно нарушить политики безопасности из-за некорректной интерпретации системного промпта и приоритета достижения поставленной цели даже в ущерб каким-то другим ограничениям.
Соответственно, все же нужно закладывать «человека в контур» и устанавливать лимиты на автономные действия ИИ-агентов, включая и киберфизические ИИ-системы, потому что агент может действовать непредсказуемо.
4. Появился AI Governance для ИИ-агентов.
В Приложении 4 Модели от Сбера детально расписаны зоны ответственности, например:
+ Владелец данных отвечает за T01, T09, T15 - утечки и отравление датасетов.
+ Разработчик модели отвечает за T33, T34 - галлюцинации, бэкдоры в весах.
+ Владелец ИТ-инфраструктуры инференса отвечает за T22, T10 - DoS-атаки, утечки из логов.
+ Разработчик AI-решения отвечает за бизнес-логику, системные промпты, интеграции.
Это уже готовый шаблон для распределения ролей в вашей компании при выводе AI-продукта на рынок. Хотя желательно бы и добавить, за что отвечает пользователь?
5. Модель отлично отражает современный стек.
Угрозы заточены не просто на «взлом нейронки», а на специфичные уязвимости, которые уже известны. В том же RAG это отравление векторных баз данных и механизмов ретривала. Для LoRA-адаптеров это утечки конфиденциальной информации, запомненной именно в легковесных адаптерах при дообучении.
Учитывается и внедрение вредоносного контента через функции сохранения пользовательского контекста.
Привет, мои дорогие друзья и самые талантливые коллеги!
Недавно вышла обновленная Модель угроз кибербезопасности ИИ от Сбера (v2.0), только сейчас в силу высокой загрузки смог до нее добраться. Изучил документ на 98 страниц и хочу поделиться инсайтами.
В начале Модели дан небольшой Глоссарий терминов, что радует, так как это помогает лучше воспринимать документ специалистам, не сильно погруженным в тему ИИ-агентов.
И вообще в целом ИИ-агентам в Модели уделено очень большое внимание. Если предыдущие версии и отраслевые гайдлайны, тот же OWASP Top 10 for LLM, фокусируются в основном на голых LLM, то Модель угроз кибербезопасности ИИ от Сбера v2.0 уникальна и отлично подходит для агентов, само ее появление еще раз указывает на стремительный переход в эту агентов ИИ, который все и предсказывали.
Основные моменты, которые я лично для себя выделил в документе:
1. В модели четко разделены с одной стороны угрозы (T01-T37), то есть что может пойти не так и каков бизнес-импакт (то есть бизнес-влияние), например, T18 - Внедрение вредоносного контента в RAG/Память агента.
С другой стороны разделены и способы реализации (ME01-ME51), то есть как именно это делается, с привязкой к тактикам MITRE ATLAS, например, ME15 - Реализация непрямых промпт-атак при извлечении данных из RAG.
И это позволяет нам строить многоуровневую защиту. Мы можем блокировать конкретные способы на уровне WAF/API-шлюзов, и минимизировать последствия на уровне бизнес-логики и изоляции агентов.
То есть фреймворк от Сбера признает, что защита ИИ-агентов всегда многоуровневая, и каждый уровень важен.
2. Фокус делается уже на мультиагентных системах и их оркестрации
Большинство моделей угроз до сих пор рассматривают ИИ как одинокого чат-бота. В то же время Модель от Сбера 2.0 закладывает риски мультиагентных архитектур.
Например, появились угрозы нарушения взаимодействия агентов и каскадного распространения промпт-атак через общие хранилища и память. Описаны атаки на планировщик и искажение семантики сообщений между агентами.
Так если вы строите мультиагентную архитектуру, то вам срочно нужны механизмы криптографической верификации контекста между агентами и изоляция их памяти.
3. ИИ-Агент рассматривается как потенциальный источник угрозы.
В матрице нарушителей ИИ-агент рассматривается не только как жертва, но и как потенциальный источник угрозы.
То есть ИИ-агент действует в рамках своих функций, но может непреднамеренно нарушить политики безопасности из-за некорректной интерпретации системного промпта и приоритета достижения поставленной цели даже в ущерб каким-то другим ограничениям.
Соответственно, все же нужно закладывать «человека в контур» и устанавливать лимиты на автономные действия ИИ-агентов, включая и киберфизические ИИ-системы, потому что агент может действовать непредсказуемо.
4. Появился AI Governance для ИИ-агентов.
В Приложении 4 Модели от Сбера детально расписаны зоны ответственности, например:
+ Владелец данных отвечает за T01, T09, T15 - утечки и отравление датасетов.
+ Разработчик модели отвечает за T33, T34 - галлюцинации, бэкдоры в весах.
+ Владелец ИТ-инфраструктуры инференса отвечает за T22, T10 - DoS-атаки, утечки из логов.
+ Разработчик AI-решения отвечает за бизнес-логику, системные промпты, интеграции.
Это уже готовый шаблон для распределения ролей в вашей компании при выводе AI-продукта на рынок. Хотя желательно бы и добавить, за что отвечает пользователь?
5. Модель отлично отражает современный стек.
Угрозы заточены не просто на «взлом нейронки», а на специфичные уязвимости, которые уже известны. В том же RAG это отравление векторных баз данных и механизмов ретривала. Для LoRA-адаптеров это утечки конфиденциальной информации, запомненной именно в легковесных адаптерах при дообучении.
Учитывается и внедрение вредоносного контента через функции сохранения пользовательского контекста.