Escalar el triaje de alertas de seguridad con agentes especializados en Databricks

¿Qué pasaría si la baja gravedad no significara baja prioridad?

Databricks ingesta petabytes de registros de seguridad de diversas fuentes, como herramientas de seguridad de endpoints, registros de actividad en la nube y fuentes de inteligencia de amenazas, en nuestro lakehouse de seguridad. Nuestra arquitectura de detección monitorea continuamente estos datos en busca de actividad maliciosa. Cada señal identificada llega a una tabla de alertas centralizada, donde espera la revisión de un analista de Incident Response (IR).

Encontrar una amenaza real entre miles de alertas de seguridad diarias es el clásico problema de buscar una aguja en un pajar. La mayoría de los equipos gestionan la carga priorizando las alertas por gravedad. Los equipos clasifican las alertas de nivel HIGH y MEDIUM, y abordan las de nivel LOW a medida que hay disponibilidad.

En Databricks, nuestro equipo de IR gestiona alertas de seguridad en los tres niveles de prioridad. Históricamente, el equipo priorizaba las alertas HIGH y MEDIUM debido al volumen y la baja fidelidad de las alertas LOW. Todos los equipos de seguridad a gran escala se enfrentan a este mismo dilema: aumentar el número de analistas, elevar los umbrales de alerta y aceptar puntos ciegos, o encontrar una forma de automatizar el proceso. Nosotros elegimos lo último, aprovechando agentes que pueden razonar y aplicar su criterio a escala.

El argumento a favor de los agentes especializados

Para validar si los agentes podían clasificar y escalar alertas de seguridad de manera confiable, comenzamos con las alertas de baja gravedad. Nuestro objetivo era simple: identificar las alertas que justifican una investigación más profunda.

Al principio adoptamos un enfoque ingenuo: colocamos todos los datos relevantes de la alerta en un solo prompt y dejamos que un modelo fundacional decidiera qué escalar. Este enfoque produjo una tasa de escalación del 50%. Enviar la mitad de todas las alertas a los analistas no era clasificar, era simplemente otro tipo de ruido.

El problema era el contexto. Un solo agente que razona sobre cada alerta no tiene forma de distinguir cómo se ve un comportamiento anormal para cada fuente. Todo lo necesario para clasificar una alerta con precisión (sus patrones de falsos positivos, líneas de base de comportamiento y enriquecimiento relevante) es específico de la fuente. Sin ese contexto, el conocimiento general de ciberseguridad era todo con lo que el modelo contaba para trabajar, y eso no era suficiente para una clasificación precisa.

Arquitectura: una flota de agentes

Reconstruimos el pipeline en torno a 17 agentes específicos de origen, cada uno ajustado a una sola fuente de detección, ya que el contexto necesario para una clasificación precisa depende en gran medida de la fuente. Una sola fuente puede emitir decenas de detecciones distintas, y su agente se encarga de todas ellas.

También contamos con un agente dedicado de Threat Intelligence (TI) que trabaja junto a la flota de clasificación de agentes de baja gravedad y que puede ser llamado por cualquier agente cuando encuentra un indicador o comportamiento que amerite una investigación más profunda. El agente de TI consulta nuestras fuentes de inteligencia de amenazas y devuelve una evaluación estructurada: si este artefacto es conocido como malicioso, desconocido o benigno. Esto es importante porque los indicadores de compromiso sin procesar no tienen sentido sin contexto. Una dirección IP es solo un número. La misma IP enriquecida con "asociada a infraestructura C2 en los últimos 14 días, alta confianza" permite que el agente tome medidas de inmediato.

Mediante Structured Streaming en Databricks, las alertas de baja gravedad se ingestan a medida que se activan, se enriquecen con contexto adicional mediante el agente de TI y se dirigen al subagente adecuado para su revisión.

Cada agente sigue los mismos principios de diseño:

Filtrado determinista. Las comprobaciones programáticas coinciden con el título de la alerta y los campos de contexto para suprimir señales conocidas como benignas (matices específicos del entorno, como listas de IP de confianza, actividad de cuentas de servicio, comportamiento esperado de las herramientas) y producir resoluciones instantáneas sin ninguna llamada a un LLM. Estas gestionan entre el 30 y el 95 % del volumen de alertas, según la fuente. Casos como "rol de IAM conocido como seguro que realiza operaciones esperadas" o "correo electrónico de administrador que realiza la gobernanza rutinaria del espacio de trabajo". El filtrado puede ocurrir en la capa de detección o junto a la propia lógica de clasificación.

Enriquecimiento de contexto. Antes de que el LLM vea la alerta, el agente extrae el historial de alertas reciente de la entidad afectada, la actividad relacionada y otras señales relevantes. Los agentes también pueden invocar otras capacidades de tipo agente durante el enriquecimiento; por ejemplo, llamar al agente dedicado de Threat Intelligence cuando una alerta contiene una IP o un dominio que vale la pena investigar.

Funciones de prompt especializadas. Cada título de alerta se asigna a una función de prompt. Por ejemplo, las alertas de acceso anómalo a S3 se dirigen a una función con instrucciones para evaluar el reconocimiento de IAM, y las alertas de escalación de privilegios van a una que conoce los patrones de asunción de roles esperados frente a los inesperados. Si ninguna función dedicada coincide, un prompt genérico de respaldo gestiona la alerta. Las funciones de prompt se ejecutan en modo de un solo turno (una llamada al LLM) o en modo agente (bucle de llamada a herramientas de varios turnos), dependiendo de si la alerta necesita contexto adicional para clasificarse con confianza.

Herramientas compartidas. Las herramientas son opcionales y específicas de cada agente. Cuando la clasificación requiere más contexto (registros de auditoría en la nube sin procesar, alertas correlacionadas de múltiples fuentes o historial de actividad de IdP), equipamos al agente con herramientas para recuperarlo, y el LLM decide si invocarlas y cuándo hacerlo en función de la ambigüedad de la evidencia.

Utilidades compartidas. Para gestionar la sobrecarga de mantener varios agentes, refactorizamos el código de utilidades compartidas en un marco común que maneja la invocación de agentes, los reintentos y la evaluación del rendimiento. Toda la lógica que es consistente en las distintas fuentes de datos reside aquí, incluido el bucle de llamada al LLM, el análisis de resoluciones, el envío de herramientas, la persistencia de resultados en tablas Delta, el seguimiento de tokens, el rastreo de MLflow y la detección de inyección de prompts.

Razonamiento y resolución del LLM. El modelo analiza el paquete de evidencia y devuelve una salida estructurada que incluye una resolución (escalar, monitorear o cerrar) con un análisis de respaldo.

Gestión de costos. Existen tres controles sobre el gasto. Primero, el filtrado determinista garantiza que las alertas que coinciden con patrones conocidos como benignos nunca lleguen a un LLM. La llamada más barata es la que nunca se hace. Segundo, un rastreador de costos acumula el gasto estimado en cada lote y detiene el procesamiento si se alcanza un límite configurable, registrando las alertas restantes como omitidas. Tercero, un límite diario de alertas establece un tope al costo diario total, independientemente del volumen entrante. Dentro de cada alerta, los presupuestos de llamadas a herramientas por categoría evitan bucles de descubrimiento descontrolados en los que, de lo contrario, un LLM podría seguir solicitando contexto adicional de forma indefinida.

Si el agente decide escalar, la alerta se convierte en un ticket en la cola de IR, donde los analistas revisan tanto la alerta sin procesar como el análisis del agente antes de tomar una decisión final de clasificación. Cuando un analista no está de acuerdo con la escalación de un agente, el ticket se etiqueta como falso positivo y ese feedback se utiliza para ajustar el rendimiento del agente. Descubrimos que las alertas de nivel LOW escaladas por agentes tenían aproximadamente 10 veces más probabilidades de ser verdaderos positivos que las alertas existentes priorizadas con gravedad HIGH y MEDIUM.

La referencia humana detrás de cada decisión del agente

Cuando un analista humano revisa un ticket escalado, su decisión de confirmar o anular al agente se convierte en la verdad de referencia (ground truth) para la evaluación. A diferencia de los programas deterministas, donde se puede realizar pruebas frente a una especificación fija, los agentes aplican su criterio. La misma alerta puede producir diferentes resultados en distintas ejecuciones. Por lo tanto, en lugar de realizar pruebas frente a una especificación, lo hacemos frente a un conjunto de datos estándar desarrollado por analistas de IR que ya saben cómo es una decisión de clasificación de alta calidad.

Cada solicitud del agente se registra con MLflow, capturando entradas, pasos intermedios y salidas finales. A medida que los analistas de IR etiquetan los tickets en el transcurso de su flujo de trabajo normal, cada etiqueta se registra directamente en la traza de MLflow correspondiente como una respuesta esperada. Estas trazas etiquetadas establecen un conjunto de datos de verdad de referencia (ground truth) que captura el criterio de los analistas a escala. Ese conjunto de datos se convierte en el punto de referencia para evaluar cualquier cambio futuro en los prompts antes de su implementación.

Para medir más allá de los falsos positivos, planeamos utilizar la Databricks Review App, una interfaz para revisar alertas y etiquetar trazas de MLflow. Los analistas pueden ver las entradas, el razonamiento y la decisión del agente para cada alerta, y registrar el resultado esperado directamente en la traza. Esto permite que los analistas también revisen las alertas no escaladas, ampliando la cobertura de la verdad de referencia (ground truth) para las alertas que el agente decidió monitorear o cerrar, y brindándonos un estándar completo en las tres resoluciones.

Resultados

Los agentes de seguridad ahora revisan el 100 % de las alertas de baja gravedad. Las métricas clave incluyen:

• Los agentes han clasificado más de 18 000 alertas con una tasa de escalación del 3.2 %
• Las alertas de baja gravedad escaladas por agentes tenían aproximadamente 10 veces más probabilidades de ser verdaderos positivos que las alertas de gravedad HIGH o MEDIUM
• Tiempo medio de clasificación: 10.5 segundos
• Se ahorraron más de 6500 horas de analistas en los primeros 30 días

Hallazgos notables que fueron escalados por los agentes:

• Reducción de la tasa de falsos positivos de una fuente de alertas del 72 % al 3.4 %
• Identificación de 22 dominios sospechosos, inactivos o maliciosos
• Se detectó un caso en el que un usuario descargó y ejecutó software pirateado; el agente marcó indicadores de comportamiento consistentes con una violación de políticas e intención maliciosa.

Qué aprendimos

Los LLM alucinan con datos de seguridad de alta entropía. Los hashes, los subdominios aleatorios y los nombres de archivos generados son difíciles para los modelos de lenguaje. Los modelos son buenos razonando sobre el lenguaje porque este tiene patrones. Los artefactos de seguridad, como los hashes, carecen deliberadamente de patrones, que es exactamente lo que los hace difíciles para los LLM. Para garantizar la precisión, utilizamos el modelo para el razonamiento y no para la recuperación de información. Los valores de artefactos específicos se recuperan mediante llamadas a herramientas de fuentes autorizadas, no de la memoria del modelo.

El contexto lo es todo. Las mayores mejoras de rendimiento se obtuvieron al añadir datos históricos de alertas, tasas de falsos positivos por tipo de alerta y patrones de comportamiento explícitos a cada prompt. Al procesar cualquier alerta, el agente de triaje extrae el historial de alertas de los últimos seis meses del usuario afectado. En varios casos, los agentes escalaron las alertas no porque el evento desencadenante fuera de alta confianza de forma individual, sino porque era la tercera o cuarta señal sospechosa del mismo usuario. Ese tipo de correlación de comportamiento es algo que las reglas de detección deterministas anteriores tenían dificultades para capturar.

Automatice lo predecible y deje que los agentes razonen solo sobre lo que no lo es. Siempre que sea posible, opte por flujos de trabajo deterministas para restringir el alcance de lo que el LLM tiene que analizar. Cuanto más abiertas sean las instrucciones, mayor será la tasa de falsos positivos. Las instrucciones de los agentes con un alcance bien definido y paso a paso superaron sistemáticamente a los prompts generales. Aplicar un filtrado basado en reglas antes de que el LLM vea una alerta es uno de los ejemplos más eficaces de esto.

Creado en Databricks

Este sistema se creó en Databricks utilizando Spark Structured Streaming para la ingesta de alertas en tiempo real, tablas Delta para la persistencia y el reporte de alertas, MLflow Tracing para capturar cada decisión del agente de extremo a extremo, y la Databricks Review App para que los analistas puedan etiquetar trazas y crear el ground truth directamente a partir de los datos de producción.

En Databricks, creamos las herramientas que utilizamos. Este es un ejemplo de cómo nuestra propia plataforma está impulsando las operaciones de seguridad nativas de IA. Próximamente: cómo Databricks Genie puede llevar la investigación en lenguaje natural al SOC, ofreciendo a los analistas de IR la capacidad de consultar datos de alertas, explorar el contexto e investigar amenazas de forma conversacional.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original