Жили не тужили, да агентов смастерили. Значит ли это что-то для SOC?
#иб_для_ml

Есть мнение, что AI Security в некоторой степени хайпово: угрозы есть, но серьезные процессы кибербезопасности живут по прежним правилам. Так ли это?..

На уровне целей ИБ ответ да: защищаем конфиденциальность, целостность, доступность и устойчивость. На уровне операционных и технических деталей ответ нет. Кибербезопасность меняется, когда защищать нужно систему с ИИ.

Как?

1. Меняется контрагент эксперта ИБ. Рядом с девопсом и бизнес-владельцем появляется ресерчер, математик, экспериментатор, для которого ограничения безопасности часто выглядят чужеродно.
2. Меняется рабочее тело процесса: данные, источники, частота и объемы потоков. Помимо пакетов протоколов появляются свободная речь, изображение, аудио, видео.
3. Меняется дерево последствий. ИИ встраивается в решения и инструменты, связывает бизнес-системы, а значит усложняет расследование и реагирование.

Так в чем специфика для IR?

Этапы реагирования остаются прежними: подготовка, обнаружение, сдерживание, анализ, устранение, проверка результата и накопление опыта. Но объекты сдерживания и проверки меняются.

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

1) Агент на опасных движениях

Агент прочитал письмо, тикет, PDF, wiki-страницу или фрагмент из RAG. Возможно, воспользовался внешним скиллом или MCP-сервером. Внутри - инструкция: отправить файл, поменять название учетки, выдать право, вызвать API, сделать коммит.

Модель выбрала действие, среда исполнения превратила его в вызов инструмента. Все в рамках легальных доступов. Просто контекст и параметры такие, что получается негативное последствие.

Что делать?

1. Восстановить цепочку от внешнего контекста к действию: кто поставил задачу, какая инструкция попала в промпт, из какого источника, какой тул выбрала модель, какие параметры передала, какая учетка выполнила действие, что изменилось в целевой системе.

2. Сдерживать точечно способность агента совершать опасные действия: временно запретить write/send/delete/pay/admin-операции, отозвать токены сессии, перевести агента в режим предложений, заблокировать подозрительный коннектор или MCP-сервер.

3. Проверять меру повтором атаки. На проде экспериментировать страшновато, тут нужен двойник или изолированная копия цепочки агент -> тул -> ресурс. Пишите в комменты, что думаете.

2) Отравленная суета в данных

Тут меняется источник данных, маппинг разметки, конфиг очистки, название признака, проверочный набор или решение о допуске датасета. Потом пайплайн обучения собирает новую модель, она уходит в рабочую среду, и в узком классе событий растет доля пропусков. Либо модель странно реагирует на отдельный класс входных данных.

Что делать здесь?

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

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

3. Доказать исправление измерением конкретной деградации: пересобрать модель без подозрительной группы записей, сравнить метрики по затронутым классам, источникам и периодам, проверить утечку целевого признака и вернуть модель через ограниченную выкладку.

Кстати, вместо модели может быть и LoRA-адаптер.


Вывод!

IR для AI-инцидентов - старый конь в новой борозде. Все так же надо общаться с бизнесом, разбирать логи, трейсы и спаны, делать хеликоптер-вью.

Но к привычным сущностям добавляются новые цепочки: внешний контекст -> инструмент -> действие -> последствие; источник данных -> обучение -> модель -> рабочее решение.

Опыта у рынка пока мало, но скоро, думаю, появится больше опенсорсных плейбуков для ИИ-инцидентов. Один из таких как раз скину ниже.