Arquitectura de un SOC MDR — el plano completo

Un SOC MDR —Managed Detection and Response, detección y respuesta gestionada— es de las cosas que más se venden y menos se explican en ciberseguridad. El folleto dice «vigilamos tu red 24/7 y respondemos a las amenazas». Verdadero e inútil: no dice cómo se construye la capacidad de vigilar una red que no es propia, cómo se decide qué mirar de todo lo que una red produce, qué pasa en el minuto en que una alerta resulta ser real, ni qué se hace cuando el daño ya ocurrió y contener no devuelve nada.

Esta serie documenta ese cómo. No es un folleto ni un manual de un producto: es un plano técnico de un servicio MDR, escrito para que se entienda la arquitectura de las decisiones —por qué las cosas están donde están, y qué falla si no lo están—. Está armada sobre documentación operativa real, con el marco regulatorio chileno (Ley 21.663, la Agencia Nacional de Ciberseguridad) como caso concreto, pero el esqueleto es general: cualquier servicio de detección gestionada resuelve estos cuatro problemas, con otros nombres.

Las cuatro capas#

El servicio se lee como una secuencia, y cada capa asume que la anterior puede fallar y construye el control que lo detecta. Esa es la idea que une todo: un SOC no es una caja con luces, es una serie de lazos que se cierran.

flowchart LR
    ON["I · Onboarding\nadoptar un cliente\nsin heredar su caos"] --> TE["II · Telemetría\ndecidir qué mirar\nsin ahogarse en todo"]
    TE --> RE["III · Respuesta\nconvertir la alerta\nen acción, contra reloj"]
    RE --> RC["IV · Recuperación\nvolver a pie cuando\nel daño ya ocurrió"]
    RC -.lecciones.-> ON

I — Onboarding: cómo se adopta un cliente. Antes de la primera alerta hay semanas de trabajo invisible: siete fases con compuertas de calidad, una matriz que reparte quién hace qué entre proveedor y cliente, y la validación de que la telemetría no solo está conectada sino que funciona de punta a punta. Un onboarding apurado envenena todo lo que viene después.

II — Telemetría: qué mira un SOC y cómo se decide. Un SOC no puede ver todo, y fingir que sí es la forma más cara de no ver nada. Treinta fuentes en siete dominios, priorizadas según el perfil del cliente y ancladas cada una a las tácticas de MITRE ATT&CK que permiten detectar. El mapa de cobertura diagnostica sus propios puntos ciegos.

III — Respuesta a incidentes: del alert al veredicto. Cuando una alerta cruza el umbral empieza un reloj, y en un servicio gestionado algunos de esos relojes son legales. Nueve categorías de incidente, cuatro severidades con sus tiempos de respuesta, el ciclo de vida NIST, y el escalamiento que corre a la vez hacia el cliente y hacia el regulador.

IV — Recuperación: cuando la contención no alcanza. El ransomware ya cifró producción. Los tiers de sistemas con sus objetivos de tiempo y de punto de recuperación, la decisión de negocio —restaurar, negociar o reconstruir— que ningún SOC toma solo, y por qué el plan de recuperación corre en paralelo a la respuesta, no después.

Cómo leerla#

Las cuatro entregas se pueden leer sueltas —cada una es un plano completo de su capa— pero están pensadas en orden: el onboarding produce la clasificación de activos que la recuperación usa; la telemetría produce las alertas que la respuesta triangula; la respuesta identifica el vector que la recuperación necesita para no reinfectar. El hilo se sigue con el tag soc-mdr.

Es una serie de portafolio: documenta trabajo, no lo dramatiza. Si buscas la vena más personal de este blog, está en otra parte; aquí el objetivo es que alguien que arma o evalúa un servicio de detección gestionada reconozca las decisiones y sus consecuencias. El caso ancla de por qué todo esto importa —un ataque que atravesó todas las defensas perimetrales llegando por un canal de confianza— está contado aparte, en El eslabón que firma.