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