Сбер выпустил свою вторую версию модели угроз кибербезопасности ИИ. А так как я давно интересуюсь моделированием угроз, то не смог отказать себе в том, чтобы прочитать его и проанализировать.
Сразу напрашивается вопрос – а зачем нужно было городить еще одну модель, если уже есть MITRE ATLAS (русский перевод тут)? Ответ «Потому что можем!» в расчет не берем.
Мое предварительное резюме таково:
- Как модель угроз для проектирования и governance – документ Сбера лучше ATLAS и ближе к чисто российской культуре оценки угроз.
- Как таксономия атак на ИИ и база знаний для red team, detection engineering и threat intelligence – ATLAS заметно лучше.
- Как единый документ для организации – ATLAS удобнее.
- Как источник истины о современном ландшафте атак на ИИ – использовать модель от Сбера без ATLAS сегодня нельзя.
MITRE ATLAS отвечает преимущественно на вопрос «как атакуют ИИ-системы», а документ Сбера – «что в нашем ИИ-решении может пострадать, каким образом, кто способен это сделать и кто должен отвечать за защиту».
А теперь чуть больше деталей в документ, который содержит 99 страниц и включает в себя:
- описание модели угроз
- терминологию
- 37 угроз кибербезопасности ИИ (T01–T37)
- 51 способ реализации угроз (ME01–ME51), привязанный к цепочке тактик MITRE ATLAS, но не полностью (у MITRE 16 тактик против 12 у Сбера)
- практическое руководство по применению модели
- перечень объектов защиты
- роли и зоны ответственности
- матрицу соответствия угроз и способов реализации
- приложения с нарушителями, зонами ответственности и связями между угрозами.
Обратите внимание, что Сбер описывает 51 способ реализации атак (техник), а в ATLAS их 173 (в 3+ раза больше). Одно это означает, что вам придется использовать оба документа в работе.
С другой стороны ATLAS – это не модель угроз в ее классическом понимании. Это скорее энциклопедия техник и тактик, описывающих поведение атакующего:
- Какую цель он преследует на данном этапе?
- Какую технику использует?
- Какие объекты или интерфейсы эксплуатирует?
- Какие реальные случаи подтверждают применимость техники (это, прям, очень ценная информация)?
- Какие защитные меры могут ей противодействовать?
А вот модель Сбера разделяет угрозы, которые уравнены с негативными последствиями, и способы реализации угроз, то есть конкретные действия нарушителя. При этом способы реализации распределяются по тактикам ATLAS, а вот угрозы помещаются в условную финальную область Impact. Авторы объясняют это желанием отделить механику атаки от того, что в результате произойдет с системой или бизнес-процессом. Поэтому документ Сбера больше похож на попытку сделать конструктор модели угроз, проведя «модельеров» по всей цепочки действий.
Из насущного. Один и тот же способ атаки на ИИ может привести к разным последствиям, а одно последствие – реализовываться несколькими способами. Модель Сбера прямо фиксирует эту связь «многие ко многим» и показывает ее в отдельной матрице. Это лучше соответствует реальному моделированию угроз, так как техника атаки сама по себе еще не является угрозой для конкретного бизнеса; угрозой она становится через объект, последствия и контекст применения. У ATLAS подобное разделение выражено слабее: тактика Impact и соответствующие техники остаются частью той же поведенческой модели противника.
Это отделение причины от последствий – неплохое решение с методологической точки зрения.
Второе важное и хорошее отличие – документ Сбера не предлагает механически взять все техники ATLAS и поставить напротив них галочки, а сначала рекомендует определить:
- объекты защиты и объекты воздействия
- потенциальные угрозы
- виды нарушителей
- способы реализации
- итоговый профиль актуальных угроз.
И только после этого переходить к мерам защиты.
Это методологически правильнее и привычнее для российских специалистов, знакомых с методикой оценки угроз ФСТЭК.
Сберовский манускрипт выделяет:
- инфраструктуру подготовки и хранения данных
- инфраструктуру обучения
- инфраструктуру инференса
- инфраструктуру ИИ-решения
- среду исполнения агентов
- процессы поставки данных и моделей
- внешние и внутренние источники
- модели и адаптеры
- системные промпты
- конфигурацию агента
- память
- инструменты
- оркестратор
- механизмы межагентного обмена
- журналы
- ресурсные системы и API.
Для архитектора ИБ (хотя это и редкая профессия у нас) или CISO это значительно полезнее простой матрицы техник. Можно взять схему конкретного решения, отметить присутствующие компоненты и сократить общий перечень до действительно релевантных угроз. ATLAS такой полноценной архитектурной декомпозиции не дает. Он скорее описывает объект атаки внутри отдельных техник, но не предоставляет готовой объектной модели ИИ-решения.
Еще сберовская методология рассматривает три крупные области жизненного цикла:
- сбор и подготовку данных
- разработку модели и обучение
- эксплуатацию модели и интеграцию с ИИ-решениями.
Причем учитываются не только модель и inference API, но и:
- цепочки поставки данных
- процессы переноса модели
- публикация артефактов
- интерактивные среды разработки
- внешние библиотеки
- внутренние источники RAG
- журналы и трассировки
- runtime агента.
ATLAS тоже охватывает многие из этих атак, но делает это с позиции поведения противника. Но вот документ Сбера связывает их с процессами жизненного цикла и владельцами этих процессов, что облегчает применение в DevSecOps, MLOps и эксплуатации.
Также Сбер не забывает про модель нарушителя. ATLAS фактически говорит: «вот что может делать противник», а Сберовский документ дополнительно спрашивает:
- Внешний это или внутренний субъект?
- Каким уровнем технических возможностей он располагает?
- Действует ли он в black-box, grey-box или white-box?
- Имеет ли легитимный доступ?
- Какова его мотивация?
- Достаточно ли у него потенциала для конкретного способа атаки?
Ну тут все понятно – наследие ФСТЭК…
Это позволяет не считать автоматически актуальной любую технически возможную атаку. Например, модификация весов модели может быть возможна в принципе, но невозможна для внешнего black-box-пользователя при данной архитектуре. А внутренний ML-инженер обладает достаточными знаниями, но его мотивация и возможности не позволяют ему совершать враждебные действия. Такого анализа ATLAS практически не предоставляет.
Документ самого крупного банка страны пытается ответить на еще один организационный вопрос: кто именно должен заниматься этой угрозой? В нем выделены:
- владелец данных
- владелец инфраструктуры хранения данных
- разработчик модели
- владелец инфраструктуры обучения
- владелец инфраструктуры инференса
- разработчик ИИ-решения
- владелец инфраструктуры ИИ-решения
- владелец среды исполнения ИИ-агентов
- эксперт по кибербезопасности.
Для каждой угрозы и способа реализации приводится ответственная роль в организации или несколько ролей. ATLAS описывает защитные меры, но не говорит, кто в организации должен ими владеть. С точки зрения governance документ Сбера существенно практичнее. Также этот фреймворк включает риски, которые не всегда требуют классического злоумышленника:
- галлюцинации
- непредусмотренное поведение
- автономную деградацию цели агента
- нарушение логики бизнес-процесса
- использование решения не по назначению
- перегрузку человека
- ошибки межагентного взаимодействия
- несвоевременное выявление и расследование событий.
Это полезно, потому что реальные инциденты с ИИ возникают не только в результате целевых атак. ATLAS ориентирован преимущественно на враждебное поведение, а Сберовская модель пытается охватить пространство между:
- кибербезом
- AI safety
- эксплуатационной надежностью
- злоупотреблениями
- внутренними нарушениями
- ошибочным автономным поведением.
Как практический реестр сценариев ущерба это преимущество. Но есть и негативная сторона, о которой ниже.
Но не все так радужно – у модели угроз Сбера есть и немало недостатков. Основной – это количество техник. 51 способ реализации против 173 техник и подтехник ATLAS – это не просто разница в три раза. Кроме того, во многих случаях один ME из документа Сбера объединяет целый класс существенно различающихся техник. Например, формулировка вроде: «Реализация прямых промпт-атак или состязательных атак» слишком широкая. В ATLAS это может раскладываться на отдельные действия:
- prompt injection
- jailbreak
- prompt obfuscation
- delay execution of LLM instructions
- trusted output component manipulation
- context poisoning
- tool poisoning
- self-replicating prompts
- prompt infiltration через публичное приложение.
А разным механизмам нужны разные:
- телеметрия;
- меры защиты;
- тесты;
- сценарии red teaming;
- правила обнаружения.
Поэтому документ Сбера удобен как высокоуровневая модель угроз, но недостаточно детален для полноценной базы именно атак. Например, у Сбера в списке ME отсутствует как самостоятельная тактика Command and Control. Для агентских систем это реально проблема, так как скомпрометированный агент может:
- обращаться к управляющей инфраструктуре
- получать новые команды
- передавать результаты через инструменты
- использовать легитимные API как канал управления
- разворачивать другие агенты
- поддерживать долговременное присутствие.
В сберовском документе отдельные элементы этого поведения можно найти внутри Execution, Lateral Movement или Exfiltration, но самостоятельная тактика (и ее цель) теряется.
Еще одно преимущество именно ATLAS в том, что он различает степень зрелости техники атак на ИИ:
- возможна теоретически или в лаборатории
- продемонстрирована в реалистичных условиях
- применялась в реальных операциях (тут идет связка с реальными кейсами).
В документе Сбера такого измерения почти нет. Способы реализации перечисляются практически на одном уровне. В результате рядом оказываются широко используемые в реальности атаки, продемонстрированные в лабораторных условиях атаки, правдоподобные архитектурные сценарии, возможные, но пока редкие сценарии, и последствия, возникающие без злонамеренного воздействия. Для моделирования угроз этого недостаточно. Техническая возможность не равна практической реализуемости, наблюдавшейся эксплуатации, вероятности и актуальности для конкретной отрасли.
Документ оценивает потенциал нарушителя, но почти не оценивает зрелость самого способа атаки.
Авторы из Сбера прямо указывают, что модель является основой для последующей разработки организационных и технических мер, но сами меры в документе не определяются.
Также мне не очень зашло, что Сбер смешивает разные классы проблем в один перечень:
- действия внешнего противника
- действия инсайдера
- компрометация ИИ-агента
- автономная ошибка ИИ-агента
- галлюцинация
- нарушение бизнес-процесса
- противоправный контент
- использование ИИ для подготовки киберпреступления
- отсутствие мониторинга.
Методологически это не всегда корректно. Например:
- галлюцинация – это свойство или отказ модели
- промпт-инъекция – способ атакующего воздействия
- отсутствие своевременного обнаружения – недостаток контроля
- использование ИИ для киберпреступления – злоупотребление назначением системы
- утечка данных – негативное последствие.
Все они требуют разных методов оценки и разных защитных мер. Посмотрим, как это все будет разрулено в документе со списком защитных мер.
Еще один момент, который скорее всплывет со временем, – это то, что добавление новой техники может потребовать пересмотра сразу нескольких приложений и матриц. Особенно заметно это станет в области ИИ-агентов, где постоянно находится что-то новое. Посмотрим, как часто будет обновляться этот документ.
Повторю резюме, чуть расширив его. Документ Сбера – это более зрелый инструмент именно для ответа на вопросы:
- Что мы защищаем?
- Где проходит граница системы?
- Какие последствия для нас важны?
- Какие угрозы актуальны для нашей архитектуры?
- Кто может их реализовать?
- Кто внутри организации отвечает за защиту?
- Как пройти от универсального каталога к конкретному профилю угроз?
Но он слабее в том, что касается:
- точности и гранулярности TTP
- доказательной базы
- реальных кейсов
- зрелости техник
- стандартизированных защитных мер
- внешней совместимости
- машиночитаемости
- регулярного обновления.
Надо быть готовым к тому, что документ может создать ложное ощущение полноты у тех, кто пытается въехать в тематику и, например, не знает, что такое MITRE ATLAS: 51 способ реализации выглядит как законченный каталог, хотя текущая палитра атак на ИИ значительно богаче и постоянно пополняется новыми именами.
Но попытка хорошая. Главное, чтобы этот документ не сделали обязательным в будущем регулировании вопросов безопасности искусственного интеллекта. Он создаст ненужные ожидания и сформирует опасные пробелы.
