Operaciones de seguridad
La paradoja del SOC: más alertas, menos capacidad real
La paradoja del SOC se ve mejor en los números que en el discurso. Un equipo recibe más eventos que hace dos años, suma herramientas de detección y, aun así, cierra menos incidentes por semana que antes. Nadie miente. Nadie falla por incompetencia. Lo que cambió es la relación entre volumen y capacidad de decisión.
Lo he conversado con CISOs de banca, retail y sector público en LATAM e Iberia. Todos describen la misma escena: la consola central crece, el equipo no. Y cuando la consola crece más rápido que el equipo, la detección se convierte en un acto de fe.
La paradoja del SOC en una frase
Un SOC no es una sala con pantallas. Es la capacidad de convertir señales dispersas en decisiones con hora, dueño y evidencia. Cuando esa capacidad se mide por volumen de alertas, aparece un incentivo perverso: se optimiza la detección y se descuida el cierre.
La paradoja, tal como la planteo, es esta. Cuanto más instrumentamos el entorno, menor proporción de lo detectado llega a resolverse. No porque el analista sea peor. Porque cada alerta nueva arrastra contexto, validación y descarte. El trabajo crece en la cola, no en la cabeza.
Conviene separar conceptos que la industria usa como sinónimos. Un SIEM centraliza registros y correlaciona. Un EDR vigila el endpoint. Un XDR amplía esa correlación a identidad, red y nube. Un SOAR ejecuta playbooks. Un MSSP opera detección para terceros y un SOCaaS entrega esa operación como servicio. Ninguna de esas piezas decide por sí sola qué merece atención humana.
Ahí está el nudo. La tecnología genera candidatos; el criterio decide. Y el criterio es lo único que no se resuelve con una licencia adicional.
Por qué el problema se agrava ahora
Tres cambios se cruzan. La superficie de telemetría se multiplicó: endpoints, identidades, cargas de trabajo en nube y aplicaciones SaaS. La velocidad del ataque bajó de días a minutos. Y la expectativa del negocio subió, porque ya no se pregunta si hubo incidente, sino cuánto tardó en contenerse.
Además, el marco de referencia cambió. NIST publicó la versión 2.0 del Cybersecurity Framework con una función de Gobierno explícita. Ese detalle desplaza la conversación: la detección deja de ser un asunto técnico del centro de operaciones y pasa a ser una decisión de riesgo con dueño en la dirección.
Mientras tanto, MITRE ATT&CK sigue creciendo en tácticas y técnicas documentadas. Es útil como mapa, pero también como recordatorio. Cualquier equipo que intente cubrir todo el mapa con reglas propias terminará con más reglas que analistas. En la práctica, eso es la paradoja del SOC operando a escala industrial.
Desde mi posición en un mayorista de ciberseguridad veo el patrón repetirse. La compra de detección se decide por catálogo y no por la capacidad operativa de absorberla. El resultado es un centro de operaciones que factura cobertura y pierde criterio.
Qué mide realmente un SOC maduro
La madurez no se mide por alertas generadas. Se mide por la calidad de la decisión en el punto donde el humano interviene. Un centro maduro sabe qué alertas descartar sin abrir un ticket, y documenta por qué lo hizo.
Cuatro indicadores separan la capacidad real del ruido:
- Tiempo desde la primera señal hasta la contención, no hasta el primer análisis.
- Porcentaje de alertas cerradas con evidencia adjunta y criterio repetible.
- Proporción de detecciones que el equipo ya conocía antes de que llegaran.
- Número de playbooks ejecutados sin intervención humana y sin reapertura posterior.
Si el cuarto indicador es alto y el primero no mejora, hay automatización sin criterio. Es un patrón frecuente. Se compra orquestación para mover tickets más rápido por un proceso que no debía existir.
Fatiga de alertas: definición operativa
La fatiga de alertas no es cansancio. Es una reducción medible de la sensibilidad del analista frente a señales nuevas, causada por exposición repetida a señales de baja calidad. Se detecta con un dato simple: cuánto tarda el equipo en reaccionar a una alerta crítica legítima después de descartar cien falsos positivos.
Por eso el descarte importa tanto como la detección. Un falso positivo que nadie documenta vuelve a aparecer la semana siguiente, con otro analista, en otro turno. El costo se paga tres veces: en tiempo, en moral y en confianza sobre la herramienta.
La paradoja del SOC: más datos, menos señal
Aquí está mi tesis. La industria vendió la idea de que más telemetría equivale a más seguridad. Es una verdad parcial que se vuelve falsa cuando el equipo no escala al mismo ritmo. La telemetría es materia prima; la señal es producto terminado. Nadie construye una refinería para almacenar crudo.
He visto presupuestos crecer en fuentes de datos y quedarse planos en ingeniería de detección. El resultado es predecible. El SIEM ingiere más y el analista prioriza peor. Y cuando el analista prioriza mal, el CISO pierde la única moneda que importa frente al comité de riesgo: previsibilidad.
Lo digo con claridad, aunque incomode. La mayoría de los SOC que conozco no tienen un problema de visibilidad. Tienen un problema de criterio. Y el criterio no se compra por licencia; se construye con ingeniería, con formación y con tiempo protegido.
También noto una confusión de orden. Muchas organizaciones discuten qué plataforma elegir antes de definir qué decisiones deben tomarse cada mañana. Ese orden invertido explica por qué dos empresas con herramientas idénticas obtienen resultados opuestos.
El costo oculto de la cobertura total
Cubrir todo suena bien en una propuesta comercial y se vuelve insostenible en la operación. Cada regla activa consume dos recursos escasos: ciclos de cómputo y atención humana. Cuando ambos se agotan, la organización sigue detectando pero deja de responder.
De hecho, la cobertura total tiene un efecto secundario silencioso. Empuja al equipo a decidir por urgencia y no por impacto. Y la urgencia la define el proveedor de la alerta, no el dueño del activo. Ahí se pierde la alineación con el negocio.
En cambio, una cobertura deliberadamente incompleta y bien argumentada es defendible ante un auditor. Una cobertura completa sin triaje no lo es, porque nadie puede demostrar que revisó todo.
Dónde se rompe la cadena de detección
La ruptura ocurre casi siempre en el mismo punto: la traducción entre lo que la herramienta reporta y lo que el negocio considera crítico. Una regla que no está atada a un activo relevante genera alertas que nadie puede defender en una reunión de riesgo.
También se rompe en la identidad. La mayoría de los ataques actuales no explotan una vulnerabilidad de software: usan credenciales válidas. Sin correlación de identidad, el SOC ve actividad legítima donde hubo apropiación de cuenta. El marco MITRE ATT&CK describe esas técnicas con detalle suficiente para construir detección, siempre que alguien se siente a hacerlo.
Dónde se rompe la paradoja del SOC
La paradoja del SOC se rompe en un lugar concreto: el momento del triaje. Si el analista recibe la alerta con dueño de activo, identidad asociada y cambio reciente en el entorno, decide en minutos. Si recibe un identificador y una marca de tiempo, investiga a ciegas.
Por eso la inversión con mejor retorno no es otra fuente de datos. Es contexto. Y el contexto casi siempre ya está en la organización, disperso entre el inventario, el directorio y la gestión de cambios.
Del SIEM al triaje con contexto
El triaje con contexto exige tres capas: qué activo es, qué identidad lo usó y qué cambió en el entorno en la última hora. Sin esas tres respuestas, el ticket se alarga. Con ellas, la mayoría de las alertas se resuelve en menos de cinco minutos y sin escalar.
Por eso insisto en algo poco comercial. Antes de ampliar cobertura, conviene reducir la cola. Un SOC que cierra el ochenta por ciento de sus alertas con criterio documentado puede absorber crecimiento. Uno que cierra el treinta por ciento solo acumula deuda operativa.
Identidad: el punto ciego más caro
Si tuviera que elegir una sola inversión para el próximo año, elegiría identidad. No porque el endpoint haya dejado de importar, sino porque las credenciales son el camino de menor resistencia para un atacante. Y porque la evidencia de identidad vive en sistemas que casi nunca hablan con el SIEM.
Además, el trabajo remoto y la adopción de nube multiplicaron las sesiones que no pasan por la red corporativa. Un SOC que solo mira el perímetro observa una fracción del tráfico real de su gente.
En consecuencia, la detección basada solo en infraestructura produce una sensación de control que no resiste la primera auditoría de accesos privilegiados.
Automatización: qué delegar y qué no
La automatización resuelve bien lo repetible y determinista. Enriquecer un indicador, aislar un endpoint comprometido, revocar una sesión, abrir un ticket con evidencia. Falla cuando se le pide juicio. Un playbook no distingue entre un escaneo autorizado y un reconocimiento hostil si nadie le dio ese contexto.
Mi regla práctica es simple. Si la acción es reversible y el error cuesta minutos, automatízala. Si la acción es irreversible o el error cuesta una auditoría, deja un humano en el bucle. Esa frontera debería estar escrita en el runbook, no en la cabeza del turno de noche.
Asimismo, conviene medir la automatización por su tasa de reapertura. Un playbook que se ejecuta mucho y reabre casos está acelerando el error, no el proceso.
Métricas que revelan la capacidad real
El comité de riesgo no necesita el total de alertas. Necesita saber cuántas veces la organización estuvo expuesta sin saberlo. Esa cifra se aproxima con tres medidas: tiempo de permanencia antes de la detección, porcentaje de incidentes detectados por terceros y reincidencia del mismo vector.
Adicionalmente, conviene separar el tablero operativo del ejecutivo. El primero mide carga de trabajo; el segundo mide exposición. Confundirlos produce informes extensos que nadie lee y decisiones que se toman por intuición.
Por otro lado, hay una métrica que casi nadie reporta y que dice mucho: cuántas reglas se desactivaron este trimestre y con qué argumento. Si la respuesta es cero, el SOC no está depurando.
Un escenario ilustrativo, no un caso real
Para aterrizar el problema sin inventar resultados, planteo un escenario hipotético. Retail en Colombia, 1.400 empleados, tres años con SOC interno y dos proveedores externos de monitoreo. Antes: 9.000 alertas mensuales, 11% cerradas con evidencia y contención media por encima de 20 horas.
Después de un rediseño que no cambió la herramienta: 4.200 alertas mensuales, 63% cerradas con evidencia y contención por debajo de 4 horas. El cambio fue de método. Menos reglas activas, detecciones atadas a activos críticos y un dueño nombrado por cada playbook.
Marco el escenario como hipotético a propósito. Cualquier proveedor que prometa cifras de este tipo sin auditoría de por medio está vendiendo una historia, no un resultado.
Implicaciones prácticas para el CISO
Primero, separa el presupuesto de ingesta del presupuesto de ingeniería de detección. Si el segundo es cero, el primero es un gasto de almacenamiento con nombre elegante. Un mayorista de ciberseguridad puede aportar aquí: no porque venda más licencias, sino porque ve el mismo patrón en decenas de organizaciones y puede señalar qué configuración fracasa siempre.
Segundo, exige que cada detección tenga un dueño de negocio. Una regla sin dueño es una regla que nadie apaga.
Tercero, define de antemano qué significa “contenido”. Sin definición, cada turno reporta a su manera y la métrica se vuelve incomparable entre meses.
Cuarto, revisa el contrato con tu MSSP o tu proveedor de SOCaaS. Pregunta cuántas reglas están personalizadas para tu entorno y cuántas son plantilla. La respuesta suele explicar la diferencia entre 200 y 2.000 alertas diarias.
Quinto, reserva tiempo protegido para construir detección. Sin ese bloque en la agenda, el equipo solo apaga incendios y la deuda crece.
Y una nota sobre el modelo de servicio. Un MDR que solo alerta deja el cierre en tu equipo. Un SOCaaS que asume contención cambia tu exposición, pero también exige acceso y confianza. Son modelos distintos y no deberían compararse por precio por endpoint.
Si necesitas contrastar estas decisiones con alguien que ya las vio fallar antes, Habla con un Especialista.
Cómo comprar detección sin comprar ruido
Al evaluar un servicio gestionado, la conversación útil no gira alrededor de la cobertura. Gira alrededor del descarte. Pregunta qué porcentaje de alertas descarta el proveedor antes de escalar, con qué criterio y qué evidencia queda registrada.
Además, pide ver el runbook de onboarding. Un proveedor serio ajusta reglas durante las primeras semanas y documenta qué desactivó. Uno que no toca nada deja el ruido donde estaba y lo factura como servicio.
Finalmente, revisa cómo escala. Pregunta qué ocurre un viernes a las once de la noche con una alerta de identidad privilegiada. La respuesta define si compraste monitoreo o capacidad de respuesta.
Lo que viene para el SOC
Mi predicción es incómoda para el sector. En los próximos dos años, el diferenciador de un SOC no será la cantidad de fuentes integradas. Será la calidad de su descarte documentado. Los equipos que puedan demostrar por qué ignoraron una señal tendrán más credibilidad que los que muestren un tablero lleno.
Dicho eso, la presión no bajará. La identidad seguirá siendo el vector preferido y la nube seguirá creciendo en telemetría. Por eso el CISO que gane la discusión interna será el que traduzca detección a exposición, no a volumen. La gestión de riesgos de amenazas de ENISA ofrece un marco útil para esa traducción.
Queda una pregunta para el debate. Si mañana tu SOC recibiera la mitad de alertas, ¿podrías demostrar que no perdiste detección? Si la respuesta es no, la paradoja del SOC no es un problema de herramientas. Es un problema de criterio.
¿Por qué un SOC recibe más alertas y resuelve menos?
Porque la telemetría crece más rápido que la capacidad de triaje. Cada fuente nueva añade contexto, validación y descarte. Sin ingeniería de detección que priorice activos críticos e identidad, el equipo acumula cola y pierde sensibilidad ante señales legítimas.
My IT Channel
Suscríbete al Ciberblog
Recibe análisis técnicos, tendencias y recomendaciones de ciberseguridad directamente en tu correo.
