Denial of Wallet: как атаки на ИИ-бюджет SOC могут остановить защиту

Атаки на ИИ-бюджет SOC парализуют защиту

Атаки типа Denial of Wallet нацелены на перерасход токенов в ИИ-системах. Новая угроза может вывести из строя собственные процессы и технологии службы информационной безопасности (ИБ). Команды ИБ активно внедряют автоматизацию на базе ИИ. Это делает их собственные системы мишенью для внешнего вмешательства. Обработка одного оповещения с хоста может стоить от $0,69 до $3,42. Стоимость зависит от архитектуры «агентского SOC» и количества навыков у универсального агента. Базовая обработка простого оповещения может превратиться в расследование миллионов строк журналов. Это потребует миллионы токенов за считаные минуты.

ИИ-модель останавливает расследование при исчерпании бюджета

Модель Sonnet 4.6, которую использует Elastic в SOC, может остановить расследование при исчерпании бюджета. AI SOC запускает агентов для расследования подозрительных событий. Агент обращается в API Anthropic, но месячный бюджет департамента исчерпан. API возвращает ошибки, и расследование останавливается. Люди узнают об этом с задержкой. Фильтры безопасности большого ИИ-провайдера могут принять запросы от SOC как вредоносные. Это вызовет тот же эффект без исчерпания бюджета. Опыт Hugging Face показал это при расследовании взлома их инфраструктуры со стороны OpenAI.

Злоумышленники провоцируют перерасход токенов и задержки

Злоумышленник может влиять на расходы защитников. Он модифицирует доступные ему данные: DNS-записи, HTTP-заголовки, комментарии в коде, имена файлов. Внедряет в них вредоносные промпты. Расчет на то, что они будут обработаны ИБ-системами. В кейсе GhostJacking журналы WAF становятся вектором для промпт-инъекции. Исследователи атаковали фильтры безопасности LLM (guardrails). Они провоцировали увеличение задержки в 148 раз и потребление токенов в 63 раза. Система продолжает работать, но задержка в обработке оповещений и расходы значительно вырастают.

Партизанские сценарии отказа ИИ-систем

Исчерпание бюджета не всегда проявляется как явная ошибка. При определенной конфигурации возможны «партизанские» сценарии. Запрос к модели не проходит по тайм-ауту. Система автоматически переключается на более дешевую модель. Качество выводов падает, перестают запускаться субагенты и периодические задачи. ИБ-команда считает, что все работает как раньше. Это создает опасный тихий отказ.

Контроль ИИ-расходов в ИБ требует комплексного подхода

Управление расходами не сводится к предотвращению перерасходов. Отрасль проходила это при внедрении SIEM. Компании ограничивали сбор журналов, получая слепые зоны детектирования. С токенами возможна та же ситуация, но быстрее и в большем масштабе. Неудачная политика сокращения расходов может пострадать глубина расследования и качество реагирования. Решение о сокращении расходов должно приниматься архитектором или CISO на этапе проектирования. Иначе его примет дежурный аналитик или автоматический ограничитель.

Принципы контроля ИИ-расходов в ИБ

Не отдавайте ИИ-модели то, что можно проверить обычным запросом. Однотипное и известное закрывайте правилами и запросами к данным. Модель подключайте только там, где нужна оценка неоднозначной ситуации. Используйте строгие лимиты на задачу и на сутки. Агрессивно оповещайте об их превышении. Заранее решите, что происходит при достижении лимита: остановиться или продолжить. Ограничьте права и набор инструментов у агентов. Чем меньше действий доступно системе, тем меньше у нее возможностей раздуть расходы. Строго сканируйте внешние, недоверенные данные. Ограничивайте их размер и следите за нагрузкой.

Локальные модели ИИ снижают волатильность бюджета SOC

Оцените возможность применения в ИБ локальных моделей, запущенных on-premise. Они не относятся к передовым, но узкая специализация и дообучение на данных компании дадут достойную эффективность. Это позволит избежать неожиданных отказов внешних поставщиков и сохранить полный контроль над данными. В сложной архитектуре LLM можно разделить на несколько уровней. Первую линию (маршрутизация, отсев шума) берут на себя локальные компактные модели. Это снижает волатильность бюджета. Вторую линию — большая локальная модель для содержательной работы. Отдельные трудные случаи уходят в передовые облачные модели с одобрения живого аналитика. Переменные расходы остаются, но они ограничены небольшим числом случаев.

Источник: Kaspersky Daily