Февраль 2025-го, вторник, 11:00 - стартует gap-анализ ML-пайплайна финтеха на соответствие NIST AI RMF перед выходом на европейский рынок. Модель кредитного скоринга в проде три года, accuracy в дашборде стабильно зелёная. К четвергу red team находит prompt injection в API чат-бота, который использует ту же модель для клиентских консультаций. Ни одного adversarial теста за всё время эксплуатации. По классификации EU AI Act - система высокого риска: обязательные требования к robustness, журналирование, надзор человека. Невыполнение грозит оборотными штрафами по аналогии с GDPR.
И таких пайплайнов без adversarial coverage - больше, чем хотелось бы.
Ниже - практический разбор: что конкретно NIST AI RMF и EU AI Act требуют от security-команды и как перевести язык регуляторов в тесты, detection-правила и метрики для SOC.
NIST AI RMF: четыре функции глазами security-инженера
NIST AI Risk Management Framework (AI RMF 1.0) - добровольный фреймворк, выпущенный 26 января 2023 года. По данным NIST, в апреле 2026-го опубликована концепция профиля AI RMF для критической инфраструктуры, а сам фреймворк пересматривается в рамках White House AI Action Plan. Добровольность - на бумаге. На практике AI RMF быстро стал де-факто стандартом: его берут за основу и те, кто готовится к EU AI Act, и финансовые организации, работающие по SR 11-7 - надзорным требованиям ФРС к управлению модельным риском. По данным Airia, SR 11-7 уже сейчас обязывает валидировать модели в adversarial-сценариях. Подробнее - в нашем подробном разборе безопасность llm приложений.Фреймворк состоит из четырёх функций - Govern, Map, Measure, Manage. Для security-команды критична прежде всего функция Measure: именно она переводит абстрактные ожидания в тестируемые метрики.
Govern и Map: фундамент перед тестированием
Govern определяет, кто в организации отвечает за AI-риски, кто может остановить деплой модели и какие политики регулируют использование AI. Для SOC это значит одно: если AI governance committee не существует - вы не знаете, какие модели работают в проде и какие из них обрабатывают sensitive-данные. Без этого у SOC нет scope для мониторинга. Тестировать нечего, мониторить нечего, алертить не на что.Map - инвентаризация AI-систем: какие модели задеплоены, какие данные потребляют, кто stakeholders, каков контекст использования. Прямой аналог asset inventory (ID.AM-01 из NIST CSF 2.0), только для ML-моделей. Нет карты AI-активов - нет предмета тестирования. По рекомендации Mindgard, организация должна поддерживать актуальный реестр всех AI-систем: собственных моделей, open-source библиотек, third-party решений. На практике я видел, как реестр «обнаруживает» модели, о которых SOC даже не подозревал.
MEASURE: тестируемые требования
Функция MEASURE разбита на четыре группы. Каждая транслируется в конкретную security-активность:| MEASURE | Суть требования | Security-активность |
|---|---|---|
| MEASURE 1 | Методы и метрики оценки AI-рисков | Определить KPI adversarial testing: процент bypass prompt injection, drift rate модели |
| MEASURE 2 | Оценка trustworthy-характеристик: безопасность, fairness, privacy, resilience | Red team сессии, тесты на bias, privacy leakage (membership inference), robustness к adversarial inputs |
| MEASURE 3 | Механизмы отслеживания выявленных рисков | Drift monitoring в SIEM, алерты на деградацию модели, incident logging по AI-событиям |
| MEASURE 4 | Обратная связь от пользователей и stakeholders | Bug bounty для AI-систем, advisory board, интеграция фидбэка в циклы ретеста |
Подкатегории MEASURE 2 (согласно NIST AI RMF Playbook) - ядро для red team:
MEASURE 2.4 (safety) - регулярная оценка safety-рисков. Тестируется генерация опасного контента, дезинформация, несанкционированные действия модели. По OWASP LLM Top 10 2025 это прямо соответствует LLM06 (Excessive Agency): LLM с избыточными правами или автономией может совершить непредвиденные действия. Модель, которая сама решает отправить email клиенту - это уже не баг, это excessive agency в чистом виде.
MEASURE 2.6 (misuse) - может ли модель генерировать инструкции для создания оружия, вредоносного ПО, помогать в кибератаках. Пересечение с MITRE ATT&CK T1588.007 (Artificial Intelligence) - атакующие уже используют AI как инструмент подготовки атак.
MEASURE 2.7 (security/resilience) - prompt injection (LLM01 по OWASP), SQL/shell injection через AI-интерфейс, устойчивость к adversarial inputs. Классический AppSec, адаптированный для AI-контекста. Те же инъекции, только вектор доставки - через промпт.
MEASURE 2.8 (privacy) - утечка PII через outputs модели, BOLA/BFLA в API, несанкционированный доступ к training data.
MEASURE 2.11 (fairness/bias) - дискриминационное поведение модели по демографическим признакам. В EU AI Act системы с запрещёнными дискриминационными функциями вынесены в категорию неприемлемого риска.
По данным Logicalis, организации с действующей red team программой могут показать аудиторам конкретные метрики: количество критических находок за цикл, процент устранённых уязвимостей в заданный срок, частоту повторных отказов после ремедиации, показатели обхода guardrails на high-risk промптах. Разница между operational compliance и бумажным - аудитор видит исполнение, а не намерения.
EU AI Act: где adversarial testing стало обязательным
EU AI Act, принятый в 2024 году, классифицирует AI-системы по уровню риска. Для security-инженера критичны два класса.Системы высокого риска и GPAI
Annex III (высокий риск). Согласно Security Vision, сюда попадают системы, обрабатывающие данные о гражданах: оценка работников, образовательные, государственные, финансовые, правоохранительные AI-системы, биометрические решения, AI-компоненты критической инфраструктуры. Обязательны: система управления рисками, журналирование работы, надзор человека, определённые уровни точности, надёжности и кибербезопасности.Article 9 EU AI Act требует от систем высокого риска продемонстрировать robustness - устойчивость к ошибкам, сбоям и inconsistencies. Как отмечает Airia, регулятор не использует фразу «adversarial red teaming» напрямую, но функциональное требование к robustness testing пересекается с тем, что даёт adversarial подход. Организации, которые полагаются только на функциональное тестирование, рискуют получить дырявую compliance-документацию при проверке регулятором. По документам - достаточно функциональных тестов. На практике - без adversarial testing robustness не подтвердишь.
Article 55 (GPAI с системным риском). Тут требования прямее: провайдеры general-purpose AI моделей с системным риском обязаны выполнять adversarial testing для выявления и митигации системных рисков. Не рекомендация. Не best practice. Регуляторный мандат с enforcement-механизмом.
Невыполнение требований EU AI Act влечёт оборотные штрафы, аналогичные GDPR. Для помощи в выполнении норм в 2025 году подготовлен Code of Practice с рекомендациями для разработчиков. Code of Practice - мягкий инструмент. Штрафы - нет.
Контекст для SOC-команды: если организация эксплуатирует AI-систему, подпадающую под категорию высокого риска, а документированной программы adversarial testing не существует - compliance-риск уже реализуется. Вопрос не «если», а «когда» это заметит аудитор.
Маппинг требований на security-тесты и detection
Основная работа GRC-инженера по AI Security - перевод нормативного языка в тестируемые контроли. Маппинг ниже связывает требования обоих фреймворков с OWASP LLM Top 10, MITRE ATT&CK и конкретными типами тестов.AI как оружие и как цель
Основные AI-специфичные угрозы, которые надо учитывать при маппинге:Model extraction - кража модели через множественные API-запросы. В MITRE ATT&CK нет прямой техники для model extraction через API; T1592.002 (Software) описывает лишь этап разведки - сбор информации об ML-стеке жертвы, но не саму атаку извлечения модели. По сути, атакующий шлёт тысячи запросов с вариациями и по ответам восстанавливает поведение модели.
Prompt injection - обход guardrails для экфильтрации данных.
Supply chain compromise модели (в ATT&CK нет отдельной техники для ML supply chain poisoning; T1195.002 - общая техника компрометации цепочки поставок ПО, применяемая здесь по аналогии) - закладка persistent backdoor через compromised training pipeline. Самый неприятный вектор: бэкдор в модели не видно ни в коде, ни в логах - только в поведении на определённых inputs.
CrowdStrike Global Threat Report 2025 фиксирует удвоение вредоносного использования GenAI для социальной инженерии за 2024 год. IBM X-Force подтверждает: генерация фишинговых писем с помощью GenAI происходит в 11.4 раза быстрее при сопоставимом качестве. AI уже оружие - и одновременно цель.
Автоматизация тестирования
Promptfoo позволяет автоматизировать проверку LLM-систем по NIST AI RMF. Конфигурация для тестирования ключевых MEASURE:
YAML:
redteam:
plugins:
- nist:ai:measure:2.4 # Safety risks
- nist:ai:measure:2.6 # Misuse potential
- nist:ai:measure:2.7 # Security and resilience
- nist:ai:measure:2.11 # Fairness and bias
strategies:
- jailbreak
- jailbreak-templatesharmful:cybercrime, shell-injection, sql-injection для MEASURE 2.7 или pii:direct, pii:session, bola, rbac для MEASURE 2.8. Каждый плагин маппится на конкретную подкатегорию фреймворка - результаты тестов становятся audit-ready evidence.Помимо Promptfoo, для adversarial testing используются Garak (red teaming LLM от NVIDIA), PyRIT (Microsoft AI Red Team) и Giskard (тестирование bias и robustness). Все четыре - open source. Для команды с минимальным бюджетом это входная точка: базовые требования MEASURE 2 можно закрыть без enterprise-лицензий. Garak хорош для jailbreak-тестов, PyRIT - для сценарных атак, Giskard - для bias-аудита. Но ни один из них не покрывает всё сразу, так что в реальных проектах приходится комбинировать.
SOC-мониторинг AI-систем: что добавить в playbook
AI-система - полноценный актив в инфраструктуре. У неё есть API-эндпоинты, она обрабатывает пользовательский ввод, возвращает output и деградирует со временем. Если EDR и SIEM покрывают серверы, рабочие станции и сетевой трафик - AI-эндпоинты заслуживают того же подхода.Baseline и аномалии для AI-эндпоинтов
Первый шаг - установить baseline для AI API (аналог DE.AE-01 из NIST CSF 2.0): нормальный объём запросов, типичная длина input/output, частота обращений по пользователям, стандартная latency.Что мониторить в SIEM:
Аномальные паттерны input к AI API - резкий рост длины запросов, нетипичные символьные последовательности (индикатор prompt injection). Корреляционная логика: если средняя длина input превышает baseline втрое и source IP не в whitelist - генерировать алерт. Простое правило, но именно его обычно нет.
PII в output модели - если модель начинает возвращать паттерны email, телефонов, номеров документов в ответах, это data leakage или результат успешного prompt injection. Корреляция с DLP-правилами на уровне API gateway.
Rate anomalies к model API - множественные запросы с минимальными вариациями input от одного источника. Индикатор model extraction (для этой атаки нет прямого соответствия в ATT&CK; T1592.002 покрывает лишь этап разведки ПО жертвы, но не извлечение модели через API). Логика: requests per minute выше порога и similarity входных данных выше 0.95 - алерт.
Model drift - деградация accuracy и precision за пределы установленного порога. Одновременно compliance-сигнал (MEASURE 3: механизмы отслеживания рисков) и security-сигнал (возможное отравление данных, LLM04 по OWASP). Accuracy падает не всегда потому, что данные «поехали» - иногда кто-то целенаправленно кормит модель мусором.
Чеклист: AI compliance в SOC
- Включить AI API endpoints в scope SIEM-мониторинга
- Настроить baseline метрик для каждого AI-сервиса: latency, input/output length, request rate
- Добавить DLP-правила на output AI-эндпоинтов для детекции PII leakage
- Настроить алерт на аномальный рост запросов к model inference endpoint
- Интегрировать drift monitoring (accuracy, precision, recall) в SOC-дашборд
- Документировать каждый тестовый цикл adversarial testing - evidence для аудита (MEASURE 2.1)
- Перейти от ежегодных проверок к частым спринтам - по данным Logicalis, это даёт быстрее feedback и лучше governance
У части организаций, деплоящих AI сегодня, та же слепая зона: ML-модели в проде есть, а в scope SOC их нет. Ни baseline запросов к inference API, ни алертов на аномальный input, ни корреляции model drift с security-событиями. Три года без adversarial теста - не аномалия, а норма.
NIST AI RMF и EU AI Act обычно обсуждают в контексте compliance и юридических рисков. Но по сути это задача security-инженера: расширить scope мониторинга на новый класс активов. MEASURE - прямой аналог vulnerability scanning, только для моделей: те же циклы «тестируй → находи → фиксируй → ретестируй». С одной разницей: модели drift'ят и деградируют, тестовый цикл не завершается никогда.
Через 12-18 месяцев рынок разделится. Кто уже строит adversarial testing программу - покажет аудитору метрики: сколько injection-попыток перехвачено, сколько bias-кейсов устранено, как изменился risk score после ретеста. Кто ждёт мандата - будет строить под давлением регулятора и без наработанной базы. Если в вашем SOC ещё нет detection-правил под AI-эндпоинты - на codeby.net ведётся тред по корреляционным правилам и SIEM-интеграциям для мониторинга AI-систем.
