Cada pocos años ocurre una brecha que los equipos de seguridad estudian por las razones equivocadas. SolarWinds es un buen ejemplo. Cuando la actualización comprometida de Orion comenzó a llegar a los entornos de clientes a principios de 2020, las señales ya estaban presentes: solicitudes DNS inusuales, comportamiento de autenticación inesperado en Azure AD, actividad extraña de tokens SAML y movimiento lateral desde Active Directory local hacia la nube. Ninguna de estas señales parecía un ataque. Cada una tenía una severidad baja o media y estaban dispersas entre dominios. Los atacantes tuvieron casi un año de permanencia antes de que FireEye, también víctima, descubriera la brecha mientras investigaba un kit de herramientas de equipo rojo robado.

Tendemos a llamar a SolarWinds un caso aislado. No lo fue. La verdadera lección de esa brecha, y de las que le siguieron, es estructural. Los SOC están diseñados, dotados de personal y evaluados en función del trabajo rutinario: phishing, detecciones de endpoints y anomalías de usuarios. Las personas, los procesos, los paneles y las herramientas están ajustados para manejar alertas que encajan en una rutina regular. Esa es una respuesta racional al volumen de trabajo que llega a la cola. Las alertas que conducen a brechas reales rara vez se parecen a aquellas para las que te has preparado.

Son de cola larga y aparecen en sistemas y fuentes más allá de la visibilidad central del SOC. Por ejemplo: un patrón de autenticación que solo parece incorrecto cuando se alinean tres sistemas diferentes a la vez; una anomalía única de WAF contra una API raramente utilizada; una advertencia puntual en el pipeline de actualización de un proveedor; un listado en la dark web que ofrece acceso VPN o de administrador a tu entorno. Ninguno de estos encaja en una cola estándar. En la práctica, a menudo no se activan de manera consistente o oportuna.

Alertas que el SOC no está diseñado para manejar

Las alertas de cola larga no aparecen en tu informe de las diez principales detecciones. Son señales de baja frecuencia en los límites de lo que monitorea el SOC, y la mayoría de los procesos del SOC nunca fueron diseñados para manejarlas. Una anomalía única de WAF contra un endpoint de API poco utilizado nunca llega a la lista de 'más atacados' porque el payload no coincide con un patrón conocido. Se registra con baja severidad y nada en la cola la hace destacar entre los cien eventos de WAF cerrados esa semana. Una alerta de seguridad puntual de un gran proveedor de SaaS o software, como 'hemos restablecido esta cuenta de administrador tras detectar actividad sospechosa', llega a una bandeja de entrada de correo o al portal del proveedor, no a la cola del SOC. Parece una notificación rutinaria y no hay una regla SIEM conectada, por lo que se considera normal.

Un listado en la dark web que ofrece acceso VPN o de administrador a tu entorno aparece en un informe de monitoreo externo. Las credenciales fueron robadas y ahora están a la venta, pero ese informe reside en una herramienta separada y nunca se convierte en una alerta triable en el SOC. Un patrón de autenticación que solo se ve incorrecto cuando alineas tres cosas a la vez: una cuenta de servicio raramente utilizada, una aplicación SaaS en la periferia del entorno y un rango de IP que nadie reconoce. Ninguno de estos desencadena un flujo de trabajo predefinido. No hay un propietario claro, ni un playbook existente, ni una categoría de cola que capture lo que son. Por lo tanto, se registran y a menudo permanecen intactos.

Por qué los SOC internos no pueden cerrar esta brecha

Los SOC están construidos para el volumen. La contratación, la capacitación y los modelos de medición reflejan esa realidad. Enfrentan dos problemas estructurales: el 80% de las alertas crean fatiga de alerta (repetitivas, de alto volumen y rutinarias que generan fricción en el flujo de trabajo); el 20% crean puntos ciegos (casos límite inusuales que ninguna otra plataforma de IA del SOC cubre). Las SOAR no tienen playbooks y los MSSP/MDR las escalan de vuelta al equipo. Estas son las alertas más complejas donde la organización está más expuesta y el riesgo de brecha es mayor. Las métricas lo refuerzan: cada KPI estándar (alertas revisadas por analista, tasa de cierre de casos, tiempo medio de respuesta) mide velocidad y rendimiento en tipos de alertas conocidos. No mejoras ninguno de esos números dedicando tres horas a una sola alerta de cola larga. Por lo tanto, esos casos se deslizan al fondo de la pila.

Los analistas que pueden investigar alertas de cola larga suelen ser los más seniors del equipo. También son los que ya están trabajando en escalaciones, mentorizando a juniors y liderando proyectos. Hay un número significativo de alertas de cola larga, así que asignarlas todas a un analista senior no es práctico. Además, llevar al analista a una investigación entre dominios sin un playbook claro compite directamente con su trabajo prioritario. La mayoría de los analistas no tienen las habilidades ni la capacitación para alertas nicho. Podrías contratar cinco analistas más y sería poco probable encontrar a alguien con las habilidades necesarias para trabajar en cada tipo de alerta nicho.

Incluso cuando un analista senior experimentado toma uno de estos casos, la investigación generalmente no sigue un camino claro. Las alertas de cola larga requieren recopilar señales de sistemas que el SOC no posee completamente, como pipelines de cadena de suministro, aplicaciones SaaS, fuentes de la dark web y registros de identidad en la nube. Cada una requiere diferentes habilidades y herramientas, y a menudo implica localizar a un interesado diferente. Puede ser difícil encontrar a la persona de RR.HH. adecuada para hacer una pregunta o localizar al gerente de un usuario con actividad sospechosa. Esas investigaciones se convierten en proyectos, no en tickets. Las alertas con mayor potencial de brecha son exactamente aquellas para las que el SOC está menos estructurado. Las personas son capaces, pero nada en el diseño recompensa ese trabajo ni lo facilita. Y estas alertas, como muchas otras, son en su mayoría falsos positivos.

Las herramientas de IA fueron construidas para un problema diferente

Las herramientas de IA para SOC han avanzado en el problema de las alertas rutinarias. Suprimen el ruido repetitivo, cierran automáticamente grandes categorías de alertas conocidas y liberan a los analistas del trabajo de triaje que no requiere juicio humano. Así es como se diseñaron las herramientas. La limitación aparece en lo que ese diseño no contempla. La mayoría de las plataformas de IA para SOC están entrenadas en casos de uso conocidos y datos de alta frecuencia, como campañas de phishing, detección de endpoints y patrones de ataque bien documentados que aparecen en miles de entornos. Los modelos aprenden a reconocer esos tipos de alertas y toman decisiones seguras sobre señales familiares. Funcionan bien para alertas que se parecen a los datos de entrenamiento.

Las alertas de cola larga no se parecen a los datos de entrenamiento. Están fuera de lo que el modelo fue construido para evaluar. El sistema no fue diseñado para tener una opinión sobre ellas, así que no la tiene. Cuando esas señales llegan al pipeline de IA, tienden a terminar en uno de dos lugares: o las fuerza al patrón conocido más cercano, y la alerta parece manejada en el panel cuando la señal subyacente no fue comprendida; o el sistema las marca como inciertas y las devuelve a un humano, lo que parece una escalación en el papel, pero significa que la automatización se detiene donde comienza el trabajo más complicado. La misma IA que limpia tu cola rutinaria no tiene casi nada que decir sobre las alertas que conllevan el mayor riesgo.

Por qué los MSSP no resuelven el problema

Los MSSP recompensan la estandarización y la repetibilidad. Su modelo funciona mejor cuando sus clientes son similares y las alertas pueden manejarse de manera consistente. Las investigaciones de cola larga no encajan en ese modelo. Toman horas, requieren un contexto profundo sobre un solo entorno y rara vez producen un playbook que el proveedor pueda reutilizar en otro lugar. Un puñado de casos de baja frecuencia y alto esfuerzo puede arruinar los márgenes en un contrato de tarifa fija, por lo que se tratan como excepciones en lugar de trabajo central. En teoría, los MSSP ofrecen investigación y respuesta. En la práctica, el servicio está delimitado y por niveles. El trabajo forense profundo, la caza entre dominios y la integración personalizada suelen estar disponibles solo en niveles de mayor precio o como elementos fuera del alcance.

En el día a día, esto suele llevar a uno de tres resultados para las alertas de cola larga: se omiten porque no coinciden con una severidad o patrón predefinido; reciben un triaje superficial y una conclusión genérica que no refleja el riesgo real; o se escalan de vuelta al cliente, que probablemente asumía que el proveedor las estaba manejando. Los MSSP están optimizados para lidiar con el volumen de alertas y las rutinarias, no para la profundidad de la investigación. Para el tipo de alertas del que hablamos, la subcontratación principalmente mueve el problema a otra cola, no lo hace desaparecer.

Lo que hacen los mejores equipos SOC

Los mejores equipos SOC saben que no pueden tratar las alertas extrañas como cualquier otro ticket, por lo que construyen soluciones alternativas. Identifican puntos ciegos y desarrollan experiencia interna. Buscan una solución de IA que vaya más allá de los casos de uso rutinarios, encontrando una plataforma que no use IA preentrenada y ofrezca cobertura completa para alertas nicho y únicas. Crean rutas de escalación ad hoc a ingenieros seniors o cazadores de amenazas cuando algo no parece estándar. Operan bajo el entendimiento de que 'si se siente extraño, tráelo a esta persona' cuando no hay un playbook.

Mantienen wikis internas o páginas de Confluence que documentan casos límite y 'los raros' que las herramientas no entienden de serie. Esa documentación se convierte en lo más parecido a una memoria institucional para alertas de cola larga. Pero a menudo solo es útil si las mismas personas están presentes para interpretar la información. Dependen de un pequeño grupo de analistas de referencia a los que se acude para cualquier cosa inusual. Con el tiempo, esas personas acumulan un modelo mental interno de cómo se comporta el entorno entre dominios. Ven patrones que nadie más ve, pero ese conocimiento vive principalmente en sus cabezas.

Cuando aparece una señal realmente extraña, la respuesta a menudo se convierte en una sala de guerra. Los propietarios de nube, identidad, aplicación y red se reúnen en una llamada para reconstruir la imagen de la brecha. El trabajo se hace, pero es costoso, disruptivo y difícil de repetir cuando algo similar ocurre de nuevo. Y sucede después de que el daño ya está hecho. Estas son respuestas racionales a una brecha en cómo los SOC están estructurados y equipados para manejar alertas de cola larga. Desafortunadamente, estos enfoques dependen de individuos específicos y caminos informales. No escalan y tienden a romperse en el momento en que esas personas clave están de vacaciones, dejan la empresa o pasan a la gerencia.

La pregunta que los líderes de SOC deben hacerse

Todavía medimos el rendimiento del SOC por volumen y velocidad: tiempo medio de respuesta, porcentaje de alertas cerradas, tickets procesados por analista. Esos números no dicen nada sobre lo que sucede con las alertas que no encajan en tipos o playbooks predefinidos. La pregunta que los líderes de SOC deben hacerse es simple: ¿cuál es nuestro plan para la alerta que nunca hemos visto antes? El triaje limitado por categorías fijas y runbooks estáticos tiene un techo. Los adversarios saben exactamente dónde está ese techo y están listos para explotarlo. El trabajo ahora es diseñar SOC, procesos y herramientas que puedan seguir cualquier alerta, en cualquier dominio, independientemente de la frecuencia con la que aparezca. No se trata de reemplazar analistas. Necesitamos asegurarnos de que las alertas que no se parecen a nada que hayan manejado antes sean visibles, tengan un propietario y un camino hacia la resolución antes de que se conviertan en la próxima brecha. Estas alertas deben incluir todo el enriquecimiento y contexto necesarios para que cualquier analista pueda evaluarlas rápidamente.

Acerca de Radiant: la nueva forma de hacer SOC

Radiant fue construido para llenar estos vacíos. Sus analistas de IA agentivos trian cada alerta, suprimen falsos positivos rutinarios y escalan solo amenazas reales con contexto completo de investigación y respuesta con un solo clic. Sobre el autor: Shahar Ben-Hador es el CEO y cofundador de Radiant Security. Pasó casi una década en Imperva, donde ascendió de gerente de TI a convertirse en el primer CISO de la compañía, experimentando los desafíos diarios de dirigir operaciones de seguridad. Más tarde, como VP de Gestión de Producto en Exabeam, lideró la construcción de los productos que deseaba haber tenido como profesional.