Virtual SOC

Este era el producto estrella del departamento de datos. Un SOC virtual que almacenaba logs de seguridad de clientes enterprise, detectaba amenazas en tiempo real y automatizaba la respuesta. Fui responsable de la infraestructura de datos de principio a fin: desde la ingesta de logs hasta los dashboards para analistas y los playbooks automatizados. Cuando me fui, procesábamos 100M+ eventos diarios para 6 clientes enterprise con tiempos de detección garantizados de menos de un 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 buscando entre el ruido en lugar de investigar amenazas reales. Y lo que es peor, los incidentes reales se pierden porque los analistas están agotados.

Nuestros clientes necesitaban un sistema que pudiera ingerir todo, encontrar la señal en el ruido, y dejar que los analistas se centraran en lo que importa. También necesitaban que funcionara de forma fiable, porque una hora de logs perdidos podría contener los primeros indicios de una brecha.

La arquitectura

Construí 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 recolectaban logs 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 de forma casi ilimitada. Lo difícil era la normalización. Cada distribuidor tiene su propio formato de logs. Un "login fallido" se ve diferente en Active Directory, AWS y Okta. Escribí y mantuve parsers personalizados para 100+ fuentes para que las reglas de detección downstream funcionaran de forma consistente.

Operábamos un clúster de Elasticsearch gestionando 2 PB+ con 90 días de retención. Las optimizaciones de indexación mejoraron el rendimiento de consultas un 60% sobre 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ñé 50+ DAGs que corrían continuamente: 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 como indicadores de compromiso específicos, IPs maliciosas, hashes de archivos que coinciden con malware. Estos son fáciles. Segundo, anomalías de comportamiento como un usuario logueándose desde dos países en una hora, una cuenta de servicio accediendo a archivos que nunca había tocado, o incluso secuencias complejas que coinciden con patrones de ataque. Estos son más difíciles y requirieron ajuste cuidadoso para evitar falsos positivos.

Cada alerta se enriquecía con todo el contexto posible antes de llegar a un analista. No solo "login sospechoso detectado" sino "El usuario X se logueó desde Brasil, su ubicación normal 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) manejaba la respuesta automatizada. Construí 50+ playbooks que podían actuar sin intervención humana para escenarios bien entendidos. Bloquear una IP en el firewall,deshabilitar una cuenta comprometida o aislar un endpoint infectado.

La restricción clave era la trazabilidad de auditoría. Cada acción automatizada se logueaba con contexto completo: qué la disparó, qué datos se consideraron y qué acción se tomó. Los clientes en industrias reguladas necesitaban esto para cumplimiento. Además, todos estos logs 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 reemplazara a los analistas, sino porque manejaba los casos rutinarios: las IPs claramente maliciosas y las cuentas obviamente comprometidas. Esto permitía a los analistas enfocarse en situaciones ambiguas que necesitaban juicio humano.

Qué lo hizo funcionar

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

El tuning 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 dispara 100 veces al día con 95% de falsos positivos es peor que inútil: entrena a los analistas a ignorarla, lo que significa que se perderán el 5% que importa.

Apuntábamos a alertas accionables. Si una alerta dispara, el analista debería poder decidir en un minuto si necesita investigación. Eso significaba enriquecimiento agresivo de contexto y ajuste cuidadoso de umbrales. Mejor perderse algunos casos extremos que abrumar a los analistas con ruido.

Lo otro que lo hizo funcionar fue la fiabilidad. Diseñamos para tener un 99.99% de uptime porque el coste del downtime en seguridad no es solo inconveniencia, son puntos ciegos potenciales durante un ataque activo. Pipelines redundantes, degradación elegante, failover automatizado. Cuando algo se rompía, el sistema seguía ingestando 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 del pipeline durante 12 meses
• Cero brechas de seguridad detectadas durante el periodo operativo

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

Lo que aprendí

El trabajo técnico fue la parte fácil. Construir 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 vienen de meses de tuning, no de algoritmos mágicos. Aprendí a tratar la ingeniería de detección como un proceso iterativo, no como una implementación única.

La automatización en seguridad no va de reemplazar humanos. Va de respetar su tiempo. Cada falso positivo que eliminas, cada caso rutinario que automatizas, 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 necesitan juicio humano.

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

Más allá de lo técnico, este proyecto me enseñó a decir que no. 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 voluntad de tener esa conversación, de defender decisiones técnicas ante personas no técnicas, resultó ser tan importante como construir el sistema en sí.