El impacto directo de la “tokenomía” en los procesos de ciberseguridad

Recientemente hicimos una publicación sobre la “tokenomía” y los ataques de “denegación de monedero”, un nuevo tipo de ataque DDoS destinado a gastar tokens de IA en exceso. Pero antes de que los especialistas en seguridad comiencen a proteger los procesos de IA de sus colegas ante esta nueva amenaza, deben recordar que el trabajo del propio departamento de seguridad de la información puede convertirse en el objetivo de un ataque de este tipo. Dado que los equipos de seguridad ahora están probando e implementando activamente varios tipos de automatización basada en IA, la amenaza de interferencia externa destinada a paralizar el sistema de defensa afecta directamente sus propios procesos y tecnologías.

Elastic estimó que, dependiendo de la arquitectura de “SOC basado en agentes”, la clasificación de una sola alerta desde un host puede costar $0.69 para un conjunto de agentes altamente especializados o $3.42 para un agente de uso general con 14 habilidades diferentes.

Sin embargo, estos promedios enmascaran un amplio rango de variación. En cualquier momento, el procesamiento básico de una alerta simple (digamos, mil tokens) puede convertirse en una investigación en cascada que implica el procesamiento de millones de entradas de registro, llamadas a la API y otros datos relacionados, lo que equivale a millones de tokens en cuestión de minutos

El propio Elastic reconoce que utiliza el modelo Claude Sonnet 4.6 en su SOC. Esto plantea inmediatamente la pregunta: ¿qué sucede cuando se agota el presupuesto o se activan los filtros de seguridad del modelo? En el peor de los casos, ocurre lo siguiente: SOC con IA lanza una “orquesta de agentes” para investigar eventos sospechosos que se asemejan a un movimiento lateral en la infraestructura. El agente llama a la API de Anthropic, pero el presupuesto mensual del departamento se agotó y la API devuelve errores. La investigación se detiene y la gente se entera medio día después. Además, si los “filtros de seguridad” en constante cambio de un importante proveedor de IA marcan las solicitudes del SOC como maliciosas, el mismo efecto es posible incluso sin que se agote el presupuesto, como lo demuestra la experiencia de Hugging Face al investigar la violación de su infraestructura por OpenAI.

Por supuesto, un atacante tiene un interés creado en tal resultado. Pueden influir directamente en los costos de los defensores al inyectar indicaciones maliciosas en los datos disponibles para ellos (registros TXT de DNS, encabezados HTTP, comentarios de código, nombres de archivo, etc.), con la certeza de que estas indicaciones serán procesadas por los sistemas de seguridad de la información. Por ejemplo, en el caso del ataque GhostJacking, los registros de WAF sirven como vector para la inyección rápida, y en un estudio académico, se propuso otro método: los investigadores lograron atacar las barreras de seguridad de LLM mismos, lo que hace que sus solicitudes aumenten la latencia en 148 y la cantidad de tokens consumidos en 63. En otras palabras, el sistema teóricamente continúa funcionando correctamente, pero la latencia en el procesamiento de alertas y los costos asociados aumentan significativamente.

Error silencioso peligroso

En escenarios basados en agentes, el agotamiento del presupuesto no siempre se manifiesta como un error explícito con un mensaje de “límite de solicitudes excedido” y una alerta inmediata a las partes responsables. Bajo ciertas configuraciones, pueden surgir escenarios de “guerrilla”: una solicitud al modelo agota el tiempo de espera, el sistema cambia automáticamente a un modelo más económico y, como resultado, la calidad de sus resultados disminuye, y los subagentes y las tareas periódicas dejan de ejecutarse. Mientras tanto, el equipo de seguridad puede seguir creyendo durante horas y horas que todo funciona como antes.

¿Cómo controlar los costos de la IA en la ciberseguridad?

La tarea de administrar los gastos, por supuesto, no es simplemente una cuestión de “evitar gastos excesivos”. La industria ya cayó en esta trampa al implementar SIEM: cuando las empresas tenían que pagar en función del volumen de telemetría recopilada, comenzaron a limitar selectivamente, y no siempre de manera efectiva, la recopilación de registros. Como resultado, terminaron con puntos ciegos de detección. La misma situación podría surgir con los tokens, pero más rápido y a mayor escala. Una directiva de reducción de costos mal diseñada podría poner en riesgo la profundidad de las investigaciones y la calidad de las respuestas. Y en ausencia de dicha directiva, la decisión de eliminar algo no será tomada por el arquitecto o el CISO durante la fase de diseño del sistema, sino por el analista de turno a las 3 a. m. O puede ser un limitador automático establecido por el proveedor del sistema.

Algunos principios simples pueden ayudar a evitar sobrecostos predecibles y administrar mejor situaciones que son realmente impredecibles.

No proporcione al modelo de IA nada que se pueda verificar con una consulta estándar. Todo lo que sea repetitivo y conocido de antemano debe manejarse a la antigua usanza: con reglas y consultas de datos. Estos pueden desarrollarse utilizando IA, pero deben operar de manera determinista. El modelo solo debe usarse cuando realmente se necesita una evaluación de una situación ambigua.

Use límites estrictos y avise de forma contundente a los usuarios cuando se excedan. Los límites deben combinarse: un límite por tarea, un límite diario, etc. Las alertas sobre superaciones de límites deben llegar de inmediato tanto a los analistas de turno como a los responsables del sistema en su conjunto.

Decida de antemano qué sucede cuando se alcanza un límite. Decidir si detenerse y ahorrar dinero, aunque se pierda cierto control, o continuar y pagar es una decisión que debe tomarse antes de que ocurra un incidente.

Limite los permisos de los agentes y el conjunto de herramientas disponibles para ellos. Cuantas menos acciones tenga disponibles el sistema, más eficazmente realizará una tarea específica, menos oportunidades tendrá de incrementar los costos y menor será la probabilidad de que un tercero se aproveche de usted.

Analice estrictamente los datos externos que no sean de confianza. Las solicitudes, las consultas, los mensajes y los comentarios entrantes, así como varios campos técnicos que pueden contener texto arbitrario (registros DNS, encabezados HTTP, nombres de archivo) no solo pueden conducir a la inyección rápida, sino también inflar deliberadamente la carga de trabajo. Limite su tamaño y controle la carga que generan.

Para evitar interrupciones del servicio de proveedores externos y mantener el control total sobre los datos de su organización, evalúe la posibilidad de utilizar modelos locales implementados en las instalaciones, al menos para las necesidades de seguridad de la información. Si bien estos modelos pueden no ser de última generación, su especialización limitada y su ajuste con los datos de la empresa brindarán un rendimiento decente sin fallas inesperadas.

En una arquitectura más compleja, el uso de LLM se puede dividir en varios niveles. La primera línea de defensa (enrutamiento, filtrado de ruido, enriquecimiento de datos) está a cargo de modelos locales compactos. Esto reduce significativamente la volatilidad del presupuesto. El segundo nivel consiste en un modelo local grande que maneja el trabajo sustantivo: vincular eventos, probar hipótesis y reconstruir la imagen de un incidente. Tampoco se factura por solicitud, pero su rendimiento es limitado; por lo tanto, en lugar de excederse del presupuesto, es posible que se produzcan sobrecargas y colas de eventos. Solo los casos aislados y verdaderamente difíciles se envían a modelos avanzados basados en la nube, preferiblemente con la aprobación explícita de un analista humano. En este esquema, los costos variables permanecen, pero están limitados a una pequeña cantidad de casos, y cada uno representa una elección consciente en lugar de un efecto secundario de un script que se ejecuta de la noche a la mañana.

Básicamente, todo esto replica el modelo clásico de SOC de varios niveles, donde la primera línea filtra y la tercera investiga; solo los roles son interpretados por modelos en lugar de personas.