Источники для сбора угроз информационной безопасности в ИИ-системах
Глава Nvidia Дженсен Хуанг назвал день выхода ChatGPT "iPhone moment of AI". Релиз состоялся 30 ноября 2022 года, и уже в январе следующего года сервис достиг отметки в 100 миллионов активных пользователей в месяц. Скорость распространения стала индикатором того, что ИИ перестал быть экспериментом - он быстро превратился в массовую технологию, которую начали внедрять компании самых разных отраслей.
Бизнес подхватил волну не менее активно: по данным отчёта McKinsey, в 2025 году 88% компаний заявляли об использовании ИИ хотя бы в одной бизнес‑функции. Однако рост внедрений неизбежно сделал ИИ одновременно и привлекательной целью, и удобным инструментом атаки. Это подтверждается майским отчётом Google AI Threat Tracker: угрозы, связанные с ИИ, перестали быть теорией и всё чаще проявляются в реальных инцидентах и сценариях злоупотреблений.
На этом фоне многие организации пришли к привычной для ИБ точке входа - моделированию угроз. Но возникает практический вопрос: где брать перечень угроз, характерных именно для ИИ‑систем, чтобы не ограничиваться общими словами и "классическими" рисками IT? Ниже - обзор основных источников, которые можно использовать для сбора и систематизации таких угроз: от быстрых справочников до баз, пригодных для построения модели угроз и внутренней таксономии.
К ключевым источникам, которые чаще всего используют специалисты по безопасности ИИ, относятся:
- MITRE ATLAS
- OWASP Top 10 (включая направления для LLM, agentic‑систем, agentic skills и подходы вокруг MCP)
- Google Secure AI Framework (SAIF)
- Сбер: модель угроз для кибербезопасности AI
- ФСТЭК: угрозы безопасности информации систем искусственного интеллекта
- Cisco: Integrated AI Security and Safety Framework
- Databricks: AI Security Framework (DASF)
- MIT: AI Risk Repository
Эти материалы полезны по‑разному: одни дают удобный чек‑лист для первичной оценки, другие - структуру под детальную декомпозицию атак, третьи - язык для обсуждения рисков с бизнесом и регуляторами.
---
MITRE ATLAS: матрица техник атак на ИИ
MITRE много лет поддерживает одну из самых узнаваемых моделей описания действий злоумышленников - MITRE ATT&CK. По мере того как ИИ стал использоваться повсеместно, появилась потребность формализовать "ИИ‑специфичные" атаки. Так и возникла отдельная матрица MITRE ATLAS, которая переносит идею тактик и техник в контекст машинного обучения и ИИ‑систем.
Частота обновлений у ATLAS высокая - примерно раз в месяц (это удобно отслеживать по изменениям в репозитории с данными). Для практики это критично: ландшафт атак на ИИ быстро меняется, и статичные документы устаревают заметно быстрее, чем в традиционной ИБ.
Как устроена структура ATLAS
Логика такая же, как у ATT&CK:
- Тактики отражают этапы атаки (что пытается достичь атакующий на данном шаге).
- Техники описывают способы реализации (как именно он этого добивается).
- Дополнительно могут быть подтехники, а также привязки к примерам эксплуатации и митигациям (мерам снижения риска).
На момент подготовки исходного материала в базе было:
- 173 техники и подтехники злоумышленников
- 35 способов митигации
- 63 примера эксплуатации
Отдельный плюс - практичность хранения данных: техники, митигации и примеры разложены по YAML‑файлам. Это удобно для автоматизации (например, выгрузить таксономию атак в GRC, в систему управления рисками или в внутренний каталог угроз). При этом веб‑интерфейс, хоть и нагляден, действительно сложнее использовать как источник для машинного сбора - в реальных процессах чаще выигрывает работа с исходными данными.
Тактики ATLAS (этапы атаки)
Перечень тактик помогает "разложить" атаку по стадиям и оценивать покрытие защитой не в целом, а по шагам:
- Разведка (AML.TA0002) - сбор сведений об ИИ‑системе для подготовки атаки
- Подготовка ресурсов (AML.TA0003) - создание инфраструктуры и ресурсов для атаки
- Первоначальный доступ (AML.TA0004) - получение доступа к ИИ‑системе
- Доступ к модели ИИ (AML.TA0000) - доступ к модели на любом уровне
- Выполнение (AML.TA0005) - запуск вредоносного кода через ИИ‑артефакты или ПО
- Закрепление (AML.TA0006) - сохранение присутствия в системе
- Повышение привилегий (AML.TA0012) - получение расширенных прав
- Уклонение от обнаружения (AML.TA0007) - обход механизмов выявления атак
- Получение учётных данных (AML.TA0013) - кража учётных записей и паролей
- Исследование среды (AML.TA0008) - изучение инфраструктуры и окружения
- Латеральное перемещение (AML.TA0015) - перемещение между компонентами инфраструктуры
Подход "тактики → техники" хорош ещё и тем, что позволяет визуально показывать, какие этапы атаки прикрыты контролями, а где остаются "дыры". В классической ИБ этот формат давно используют для демонстрации покрытия защитными средствами, и в ИИ‑безопасности он работает не хуже.
---
Как выбирать источники: практические критерии
1) Цель использования. Если нужна быстрая ориентация и первичный чек‑лист - удобнее начать с OWASP и SAIF. Если требуется построить модель угроз с детализацией действий атакующего - логичнее опираться на MITRE ATLAS.
2) Формат данных. Для больших организаций важна не только "красота PDF", но и возможность автоматизировать: выгружать угрозы, связывать их с контролями, трекать изменения, вести версионирование. В этом смысле структурированные базы выигрывают у статичных документов.
3) Привязка к жизненному циклу ИИ. Хорошие материалы учитывают не только продакшен‑API, но и этапы данных, обучения, хранения артефактов, CI/CD для ML, цепочку поставки моделей и зависимостей.
4) Совместимость с внутренними процессами ИБ. Важно, чтобы угрозы можно было "приземлить" на понятные для ИБ сущности: активы, границы доверия, сценарии атак, меры защиты, владельцев риска, метрики контроля.
---
Как собрать модель угроз ИИ на основе нескольких источников (рабочая схема)
На практике почти всегда приходится комбинировать. Удобный маршрут выглядит так:
1) Зафиксировать архитектуру: данные, пайплайны, модельные артефакты, сервисы, агенты, интеграции, права доступа.
2) Разметить активы: тренировочные датасеты, промпты/контекст, веса модели, логи, ключи доступа, системные инструкции, инструменты агента.
3) Взять ATLAS как "скелет" атак: пройтись по тактикам и выписать релевантные техники.
4) Дополни́ть чек‑листами OWASP/SAIF: чтобы не упустить прикладные вещи вроде конфигураций, доступа, безопасной разработки, мониторинга, реакций.
5) Сопоставить с регуляторными формулировками (например, ФСТЭК) и корпоративными ожиданиями: это помогает в согласовании рисков и формализации требований.
6) Назначить митигации и метрики: контроль, владелец, периодичность проверки, сигнал в мониторинге, критерий эффективности.
---
Типовые "слепые зоны", о которых стоит помнить
- Границы доверия в агентных сценариях. Агент, умеющий вызывать инструменты и ходить во внешние системы, резко расширяет поверхность атаки: компрометация может происходить не только через модель, но и через её действия.
- Угрозы цепочки поставки. Модели, датасеты, контейнеры, зависимости, плагины, сторонние компоненты - всё это может быть точкой внедрения.
- Данные и их происхождение. Для ИИ качество и целостность данных - часть безопасности: отравление, подмена, утечки, "токсичные" наборы и ошибки разметки напрямую влияют на поведение системы.
- Наблюдаемость и расследование. Без журналирования запросов/ответов, трассировки вызовов инструментов и контроля версий артефактов расследовать инцидент в ИИ‑системе часто невозможно.
---
Вывод
Если нужен источник, который лучше всего подходит именно для системного моделирования атак и построения понятной ИБ‑картины по этапам действий злоумышленника, наиболее практичным фундаментом обычно становится MITRE ATLAS: у него чёткая таксономия, регулярно обновляемая база, а также формат, удобный для автоматизации и связки с митигациями. Остальные фреймворки и реестры стоит использовать как усиление - для чек‑листов, управленческих формулировок, регуляторного контекста и покрытия специфических классов рисков (особенно в LLM и agentic‑подходах).
