ИИ
Недавно мы публиковали пост о «токеномике» и об атаках Denial of Wallet — новом варианте DDoS, направленном на перерасход токенов. Но прежде чем начать защищать ИИ-процессы коллег от новой угрозы, безопасникам следует вспомнить, что сама работа службы ИБ может стать мишенью для такой атаки. Поскольку ИБ-команды сейчас активно тестируют и внедряют разные виды автоматизации на базе ИИ, угроза внешнего вмешательства с целью парализовать систему защиты напрямую относится к их собственным процессам и технологиям.
В Elastic подсчитали, что в зависимости от архитектуры «агентского SOC» обработка (triage) одного оповещения с хоста может обходиться в $0,69 для ансамбля узкоспециализированных агентов или в $3,42 для агента-универсала с 14 разными навыками.
При этом за средними значениями кроется огромный разброс. В любой момент базовая обработка простого оповещения (условно 1000 токенов) может превратиться в каскадное расследование миллионов строк журналов, вызовов API и других связанных данных (а это миллионы токенов за считаные минуты).
В той же Elastic признают, что используют в SOC модель Sonnet 4.6. Это немедленно вызывает вопрос: а что произойдет при исчерпании бюджета или срабатывании в модели фильтров безопасности? В худшем случае произойдет следующее: AI SOC запускает «оркестр агентов» для расследования подозрительных событий, похожих на перемещение по сети. Агент обращается в API Anthropic, но месячный бюджет департамента исчерпан, и API возвращает ошибки. Расследование останавливается на полпути, люди узнают об этом полдня спустя. Причем, если постоянно меняющиеся «фильтры безопасности» большого ИИ-провайдера примут запросы от SOC как вредоносные, тот же эффект возможен и без исчерпания бюджета, как показал опыт Hugging Face при расследовании взлома их инфраструктуры со стороны OpenAI.
И, разумеется, злоумышленник заинтересован в таком исходе. Он может напрямую влиять на расходы защитников, модифицируя доступные ему данные (TXT-записи DNS, заголовки HTTP, комментарии в коде, имена файлов и так далее) и внедряя в них вредоносные промпты в расчете на то, что они будут обработаны ИБ-системами. В кейсе GhostJacking вектором для промпт-инъекции становятся журналы WAF, а в еще одной работе исследователям удалось атаковать сами фильтры безопасности LLM (guardrails), провоцируя своими запросами увеличение задержки (latency) в 148 раз, а количество потребленных токенов в 63 раза. То есть по идее система продолжает работать правильно, но при этом значительно вырастают задержка в обработке оповещений и расходы.
Опасный тихий отказ
Далеко не всегда исчерпание бюджета в агентских сценариях проявляется как явная ошибка с сообщением «лимит запросов исчерпан» и немедленным оповещением ответственных. При определенной конфигурации могут возникнуть «партизанские» сценарии: запрос к модели не проходит по тайм-ауту, система автоматически переключается на более дешевую модель, в результате качество ее выводов падает, перестают запускаться субагенты и периодические задачи. А ИБ-команда еще долгие часы может считать, что все работает как раньше.
Как контролировать ИИ-расходы в ИБ
Задача управления расходами, конечно, не сводится к «не допускать перерасходов». Отрасль уже проходила эту ловушку при внедрении SIEM: когда пришлось платить за объем собираемой телеметрии, компании стали выборочно, и не всегда эффективно, ограничивать сбор журналов. В результате они получили слепые зоны детектирования. С токенами возможна та же ситуация, но быстрее и в большем масштабе. От неудачной политики сокращения расходов могут пострадать глубина расследования и качество реагирования. А при отсутствии такой политики решение что-то урезать будет принимать не архитектор и не CISO на этапе проектирования системы, а дежурный аналитик в три часа ночи. Либо же вообще автоматический ограничитель, установленный производителем системы.
Несколько простых принципов позволяют избежать предсказуемых перерасходов и лучше контролировать те ситуации, которые действительно непредсказуемы.
Не отдавайте ИИ-модели то, что можно проверить обычным запросом. Все однотипное и заранее известное нужно по старинке закрывать правилами и запросами к данным. Их можно разрабатывать с помощью ИИ, но работать они должны детерминировано. Модель следует подключать только там, где действительно нужна оценка неоднозначной ситуации.
Используйте строгие лимиты и агрессивно оповещайте об их превышении. Лимиты должны комбинироваться: предел на одну задачу, предел на сутки и так далее. Оповещение о превышении лимитов должно немедленно доходить как до дежурных специалистов, так и до ответственных за систему в целом.
Заранее решите, что происходит при достижении лимита. Остановиться и сэкономить, потеряв часть контроля, или продолжить и заплатить — выбрать нужно до инцидента.
Ограничьте права и набор инструментов у агентов. Чем меньше действий доступно системе, тем эффективнее она работает над узкой задачей, тем меньше у нее возможностей раздуть расходы, тем меньше ее может «раскрутить» посторонний.
Строго сканируйте внешние, недоверенные данные. Приходящие извне заявки, обращения, сообщения и комментарии, а также различные технические поля, способные нести произвольный текст (DNS-записи, HTTP-заголовки, имена файлов) могут не только приводить к промпт-инъекциям, но и целенаправленно раздувать объем работы. Ограничивайте их размер и следите за нагрузкой, которую они создают.
Чтобы не сталкиваться с отказами внешних поставщиков и сохранить полный контроль над данными организации, оцените возможность применения в ИБ локальных моделей, запущенные on-premise. Они не относятся к передовым, но узкая специализация и дообучение на данных компании дадут достойную эффективность без неожиданных отказов.
В более сложной архитектуре использование LLM можно разделить на несколько уровней. Первую линию (маршрутизация, отсев шума, обогащение) берут на себя локальные компактные модели. Это значительно снижает волатильность бюджета. Второй уровень — большая локальная модель, которой достается содержательная работа: связать события, проверить гипотезу, собрать картину инцидента. Она тоже не тарифицируется по запросам, но ее пропускная способность конечна, поэтому вместо перерасхода бюджета возможны перегрузки и появление очереди событий. И только отдельные, действительно трудные случаи уходят в передовые облачные модели, желательно с явного одобрения живого аналитика. В такой схеме переменные расходы остаются, но они ограничены небольшим числом случаев, и каждый из них — осознанный выбор, а не побочный эффект работающего по ночам сценария.
По сути, все это — воспроизведение классической многоуровневой модели SOC, где первая линия фильтрует, а третья разбирается, только роли исполняют не люди, а модели. Вместе со структурой наследуется и ее известная болезнь: самая «дешевая» линия поспешно закрывает то, что должна была передать дальше.
Советы