IA
Recientemente hicimos una publicación sobre la “tokenomía” y los ataques de “denegación de cartera”: un nuevo tipo de ataque DDoS destinado a gastar en exceso tokens de IA. Pero antes de que los especialistas en seguridad empiecen a proteger los procesos de IA de sus compañeros frente a esta nueva amenaza, deben tener en cuenta que el propio trabajo del departamento de seguridad de la información puede convertirse en objetivo de un ataque de este tipo. Dado que los equipos de seguridad están probando e implementando activamente diversos tipos de automatización basada en la IA, la amenaza de una interferencia externa destinada a paralizar el sistema de defensa afecta directamente a sus propios procesos y tecnologías.
Elastic ha estimado que, según la arquitectura de “SOC basada en agentes”, clasificar una única alerta de un host puede costar 0,69 USD para un conjunto de agentes altamente especializados o 3,42 USD para un agente de finalidad general con 14 habilidades diferentes.
Sin embargo, estas medias ocultan una enorme diversidad de variaciones. En cualquier momento dado, el procesamiento básico de una alerta sencilla (por ejemplo, mil tokens) puede convertirse en una investigación en cadena que implique el procesamiento de millones de entradas de registro, llamadas a la API y otros datos relacionados, lo que supone millones de tokens en cuestión de minutos.
La propia Elastic reconoce que utiliza el modelo Claude Sonnet 4.6 en su SOC. Esto plantea de inmediato 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: el SOC de 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 ha agotado 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 inteligencia artificial 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 parte de OpenAI.
Por supuesto, un atacante tiene un gran interés en que se produzca ese resultado. Puede influir directamente en los costes de los defensores inyectando indicaciones maliciosas en los datos de los que dispone (registros TXT de DNS, encabezados HTTP, comentarios de código, nombres de archivos, etc.), contando con que dichos sistemas de seguridad de la información procesarán esas indicaciones. Por ejemplo, en el caso del ataque GhostJacking, los registros del 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 propias barreras de seguridad de los LLM, lo que provocó que sus solicitudes aumentaran la latencia en 148 y el número 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 costes asociados aumentan significativamente.
Fallo 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 solicitud excedido” y una alerta inmediata a las partes responsables. Bajo ciertas configuraciones, pueden surgir escenarios de “guerrilla”: una solicitud al modelo se agota, el sistema cambia automáticamente a un modelo más barato y, como resultado, la calidad de sus salidas 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 costes de la IA en ciberseguridad
La tarea de administrar los gastos, por supuesto, no es sencillamente una cuestión de “evitar el gasto excesivo”. La industria ya ha caído en esta trampa al implementar SIEM: cuando las empresas tenían que pagar sobre la base del volumen de telemetría recolectada, comenzaron a limitar de manera selectiva, y no siempre efectiva, la recolecció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 costes 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 cortar algo no la tomará el arquitecto o el CISO durante la fase de diseño del sistema, sino el analista de turno a las 3 a. m. O puede ser un limitador automático establecido por el proveedor del sistema.
Algunos principios sencillos pueden ayudar a evitar sobrecostes predecibles y administrar mejor las situaciones que son realmente impredecibles.
No alimentes el modelo de IA con nada que se pueda verificar con una consulta estándar. Todo lo que es repetitivo y conocido de antemano debe manejarse a la antigua, con reglas y consultas de datos. Estos se pueden desarrollar mediante IA, pero deben funcionar de forma determinista. El modelo solo debe usarse cuando realmente se necesite una evaluación de una situación ambigua.
Usa límites estrictos y alerta 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 los límites deben llegar inmediatamente tanto a los analistas de servicio como a los responsables del sistema en su conjunto.
Decide 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.
Limita 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 costes y menor será la probabilidad de que un tercero se aproveche de ti.
Analiza 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. Limita su tamaño y supervisa la carga que generan.
Para evitar interrupciones del servicio de proveedores externos y mantener un control total sobre los datos de tu organización, evalúa la posibilidad de usar 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 estrecha especialización y su ajuste con los datos de la empresa brindarán un rendimiento decente sin fallos inesperados.
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) la gestionan modelos compactos locales. Esto reduce significativamente la volatilidad del presupuesto. El segundo nivel consiste en un gran modelo local 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 sobrecostes del presupuesto, pueden producirse 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 costes variables permanecen, pero se limitan 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 reproduce el modelo SOC clásico de varios niveles, donde la primera línea filtra y la tercera línea investiga, pero los modelos desempeñan las funciones en lugar de las personas.
