Virtual SOC

El producto estrella del departamento de datos. Un SOC virtual que ingería logs de seguridad de clientes enterprise, detectaba amenazas en tiempo real y automatizaba la respuesta. Fui responsable de la infraestructura de datos de punta a punta: desde la ingesta de logs hasta los dashboards para analistas y los playbooks automatizados. Cuando me fui, procesábamos más de 100M de eventos diarios para 6 clientes enterprise con tiempos de detección por debajo del minuto.

El problema

Los centros de operaciones de seguridad tienen un problema de volumen. Una sola empresa puede generar 100 millones de eventos al día. Firewalls, DNS, endpoints, servicios cloud, aplicaciones... todo produce logs. En algún lugar de ese torrente de datos, quizá 10 eventos indican una amenaza real. El resto es ruido.

Los analistas SOC tradicionales se enfrentan a una tarea imposible. Están ahogados en alertas, la mayoría falsos positivos. Se queman filtrando ruido en vez de investigar amenazas reales. Y lo peor: los incidentes de verdad se escapan porque los analistas están agotados.

Nuestros clientes necesitaban un sistema capaz de ingerirlo todo, encontrar la señal en el ruido y dejar que los analistas se centraran en lo que importa. Y que funcionara de forma fiable, porque una hora de logs perdidos podía contener los primeros indicios de una brecha.

La arquitectura

Monté un pipeline con tres capas: ingesta, detección y respuesta. Cada capa se diseñó priorizando fiabilidad primero y velocidad después.

Capa de ingesta

Agentes Beats recogían logs de más de 100 fuentes de datos por cliente. Desde logs de eventos de Windows hasta tráfico de firewall y registros de auditoría cloud. Logstash normalizaba todo a un esquema común y lo enviaba a Elasticsearch.

Lo difícil no era manejar el volumen --Elasticsearch puede ingerir cantidades enormes--. Lo difícil era la normalización. Cada proveedor tiene su propio formato de logs. Un "login fallido" se ve distinto en Active Directory, AWS y Okta. Escribí y mantuve parsers personalizados para más de 100 fuentes para que las reglas de detección downstream funcionaran de forma consistente.

Operábamos un clúster de Elasticsearch gestionando más de 2 PB con 90 días de retención. Las optimizaciones de indexación mejoraron el rendimiento de consultas un 60% respecto a la configuración inicial. Esto importaba porque los analistas necesitaban búsqueda instantánea sobre meses de datos cuando investigaban incidentes.

Capa de detección

Apache Airflow orquestaba la lógica de detección. Diseñé más de 50 DAGs que corrían de forma continua: verificaciones de ingesta, reglas de detección, jobs de correlación y pipelines de alertas.

Las reglas de detección se dividían en dos categorías. Primero, patrones conocidos: indicadores de compromiso específicos, IPs maliciosas, hashes de archivos que coinciden con malware. Estos son fáciles. Segundo, anomalías de comportamiento: un usuario que se loguea desde dos países en una hora, una cuenta de servicio accediendo a archivos que nunca había tocado, o secuencias complejas que encajan con patrones de ataque. Estos son más difíciles y exigieron ajuste cuidadoso para evitar falsos positivos.

Cada alerta se enriquecía con todo el contexto posible antes de llegar al analista. No solo "login sospechoso detectado" sino "El usuario X se logueó desde Brasil, su ubicación habitual es Madrid, accedió a 15 archivos sensibles en la última hora, aquí está su historial de logins del último mes." El contexto marca la diferencia entre una investigación de 30 minutos y un descarte de 30 segundos.

Capa de respuesta

Siemplify (ahora Google SecOps) gestionaba la respuesta automatizada. Monté más de 50 playbooks que actuaban sin intervención humana en escenarios bien definidos. Bloquear una IP en el firewall, deshabilitar una cuenta comprometida, aislar un endpoint infectado.

La restricción clave era la trazabilidad. Cada acción automatizada se registraba con contexto completo: qué la disparó, qué datos se consideraron y qué acción se tomó. Los clientes en industrias reguladas lo necesitaban para cumplimiento normativo. Además, esos registros nos permitían revisar y mejorar los playbooks con el tiempo.

La respuesta automatizada redujo las intervenciones manuales un 60%. No porque la automatización sustituyera a los analistas, sino porque resolvía los casos rutinarios: las IPs claramente maliciosas y las cuentas obviamente comprometidas. Así los analistas podían centrarse en situaciones ambiguas que necesitaban juicio humano.

Qué lo hizo funcionar

La arquitectura técnica era lo básico. Todos los competidores tienen un stack SOC con algo de automatización. Lo que hizo funcionar nuestra plataforma fue el tuning y la capacidad de adaptarse a cada cliente.

El ajuste de alertas es una conversación continua con los analistas. Desplegábamos una regla de detección, observábamos la tasa de falsos positivos, ajustábamos umbrales, repetíamos. Algunas reglas tardaron meses en pasar a producción. Una regla que salta 100 veces al día con un 95% de falsos positivos es peor que inútil: entrena a los analistas a ignorarla, con lo cual se pierden el 5% que importa.

Apuntábamos a alertas accionables. Si salta una alerta, el analista debería poder decidir en un minuto si necesita investigación. Eso implicaba enriquecimiento agresivo de contexto y ajuste riguroso de umbrales. Mejor perderse algún caso extremo que abrumar a los analistas con ruido.

Lo otro que lo hizo funcionar fue la fiabilidad. Diseñamos para un 99,99% de uptime porque el coste del downtime en seguridad no es solo molestia: son puntos ciegos potenciales durante un ataque activo. Pipelines redundantes, degradación controlada, failover automatizado. Cuando algo se rompía, el sistema seguía ingiriendo datos mientras lo arreglábamos.

Resultados

Cuando me fui:

• 100M+ eventos procesados diariamente con rendimiento consistente
• 6 clientes enterprise corriendo en la plataforma
• Detección en tiempo real para amenazas críticas de un solo paso
• Detección en menos de un minuto para amenazas críticas multi-paso
• 60% de reducción en trabajo manual de analistas mediante automatización
• 99.99% de uptime de la pipeline durante 12 meses
• Cero brechas de seguridad detectadas durante el periodo operativo

Los analistas podían dedicarse a seguridad en vez de ahogarse en ruido. Los clientes tenían mejor cobertura con menos personas. Incorporábamos nuevos clientes sin escalar el equipo de forma lineal. La plataforma corría íntegramente con herramientas open source, lo que mantenía los costes bajos y facilitaba la personalización para cada cliente.

Lo que aprendí

Lo técnico fue la parte fácil. Montar un pipeline que maneje 100M de eventos es un problema resuelto. Lo difícil fue hacerlo útil.

Útil significa que los analistas confían en las alertas. La confianza viene de tasas bajas de falsos positivos, que a su vez vienen de meses de tuning, no de algoritmos brillantes. Aprendí a tratar la ingeniería de detección como un proceso iterativo, no como una implementación de una sola vez.

La automatización en seguridad no va de sustituir personas. Va de respetar su tiempo. Cada falso positivo que eliminas, cada caso rutinario que automatizas, le devuelve horas a un analista para hacer trabajo de seguridad real. El objetivo no es cero intervención humana, sino intervención humana en los casos que la necesitan.

También aprendí a diseñar para el fallo. Los sistemas de seguridad se rompen en los peores momentos. La infraestructura que parece fiable en operaciones normales se pondrá a prueba durante un ataque activo, probablemente a las 3 de la mañana. Redundancia, degradación controlada y failover automatizado son la diferencia entre detectar una brecha y que se te escape.

Más allá de lo técnico, este proyecto me enseñó a plantar cara. Los clientes pedían funcionalidades que sonaban razonables pero habrían degradado la calidad de detección. Aprendí a decir que no, explicar por qué y buscar alternativas viables. A veces me equivocaba y me convencían. Pero la disposición a tener esa conversación, a defender decisiones técnicas ante personas no técnicas, resultó ser tan importante como construir el sistema en sí.