Arquitectura de un SOC MDR · I — Onboarding: cómo se adopta un cliente

Antes de que un SOC MDR pueda decir «detectamos esto en tu red», tiene que haber resuelto un problema que casi nunca se cuenta: cómo se convierte una red ajena, que no diseñó ni conoce, en algo que puede vigilar con criterio. Ese proceso —el onboarding— es la parte menos glamorosa y más determinante del servicio. Un onboarding apurado produce meses de falsos positivos, puntos ciegos que nadie sabe que existen y una relación con el cliente envenenada desde el primer incidente mal manejado. Un onboarding riguroso es invisible: cuando funciona, nadie lo nota.

Esta serie documenta la arquitectura de un servicio MDR como un plano técnico, no como un folleto. Esta primera entrega es el onboarding: las siete fases por las que pasa un cliente antes de entrar a operación continua, las compuertas de calidad que impiden avanzar con trabajo a medias, la matriz que reparte responsabilidades entre el proveedor y el cliente, y el tablero que traduce todo eso en tareas con fecha. El marco regulatorio de referencia es el chileno (Ley 21.663, la Agencia Nacional de Ciberseguridad), pero el esqueleto es general: cualquier servicio de detección gestionada resuelve estos mismos problemas, con otros nombres.

El problema que resuelve un onboarding#

Un MDR opera sobre infraestructura que no es suya. No eligió el firewall, no diseñó el Active Directory, no sabe qué servidor es crítico para el negocio y cuál es un resto olvidado de una migración de 2019. Todo eso —que el cliente da por obvio— es exactamente lo que el SOC necesita saber para no ahogarse en ruido ni pasar por alto lo que importa. El onboarding es el procedimiento de transferir ese conocimiento tácito a algo operable: fuentes de log conectadas, activos clasificados por criticidad, acciones de contención pre-autorizadas por escrito, severidades acordadas.

Y es un procedimiento con estado de fallo. Si la telemetría llega incompleta, el SOC vigila una red parcial creyendo que la vigila entera. Si nadie firmó qué puede aislar el proveedor sin pedir permiso, el primer ransomware se propaga mientras se busca a quién llamar un domingo a las tres de la mañana. Por eso el onboarding no es una lista de tareas: es una secuencia con compuertas, donde cada fase valida su trabajo antes de habilitar la siguiente.

Las siete fases#

El flujo va de la Fase 0 a la Fase 6. Cada fase tiene un objetivo, un responsable principal y una compuerta de salida con criterios bloqueantes que hay que cerrar para avanzar.

flowchart TD
    F0["Fase 0\nHandoff comercial → técnico\n(Ejecutivo Comercial)"]
    F1["Fase 1\nKick-off y levantamiento\n(Project Manager)"]
    F2["Fase 2\nDiscovery técnico\n(Ingeniero de Integración)"]
    F3["Fase 3\nDespliegue e integración\n(II + Contacto Técnico)"]
    F4["Fase 4\nValidación de telemetría\n(Ingeniero de Integración)"]
    F5["Fase 5\nTuning y alineación operativa\n(SOC Manager)"]
    F6["Fase 6\nHandoff a operaciones\n(Project Manager)"]

    F0 -->|"contrato + alcance\ntransferidos"| F1
    F1 -->|"contactos y perfil\ndocumentados"| F2
    F2 -->|"inventario de activos\n+ fuentes mapeadas"| F3
    F3 -->|"fuentes enviando\nal SIEM"| G4{"¿100% de fuentes\ncríticas sin gaps?"}
    G4 -->|no| F3
    G4 -->|sí| F4
    F4 -->|"pipeline validado\nextremo a extremo"| G5{"¿alertas de prueba\nllegan al analista?"}
    G5 -->|no| F3
    G5 -->|sí| F5
    F5 -->|"playbooks + severidades\n+ pre-autorizaciones firmadas"| G6{"¿acta de cierre\nfirmada por ambas partes?"}
    G6 -->|no| F5
    G6 -->|sí| F6
    F6 --> OP(["Operación continua\n(24/7)"])

Fase 0 — Handoff comercial → técnico. El equipo comercial cerró el contrato; ahora transfiere el alcance real al equipo técnico. Qué se contrató, qué perfil de cliente es, qué expectativas se fijaron. La compuerta aquí evita el clásico desastre de un equipo técnico que hereda promesas comerciales que no puede cumplir.

Fase 1 — Kick-off y levantamiento. El Project Manager reúne a ambos equipos, se presentan los roles y se recopilan los datos de contacto: como mínimo, un Contacto Técnico y un Sponsor. Criterio bloqueante: el Sponsor tiene que estar identificado y registrado con nombre, cargo y vía de contacto. Sin Sponsor no hay quién firme las decisiones que vienen después.

Fase 2 — Discovery técnico. El Ingeniero de Integración cruza lo que el cliente dice tener con lo que realmente tiene. Se levanta el inventario de activos, se clasifican por criticidad (los Tiers que la entrega de recuperación va a usar), se identifica el perfil de la infraestructura —predominantemente cloud, on-premise, o con componente industrial/OT— y se mapea qué fuentes de telemetría existen y cuáles hay que habilitar. Este es el momento donde se decide qué se va a poder vigilar.

Fase 3 — Despliegue e integración. El trabajo pesado: agentes desplegados, log forwarding configurado en firewalls, puertos abiertos, parsers escritos para cada fuente en el SIEM. Aquí la responsabilidad se reparte de forma clara —el proveedor configura el lado SIEM, el cliente ejecuta el despliegue físico en su infraestructura— y por eso es donde una matriz de responsabilidades mal definida hace más daño.

Fase 4 — Validación de telemetría. No basta con que las fuentes «estén conectadas»: hay que probar que la cadena completa funciona. Se generan alertas controladas y se verifica que recorran todo el camino, desde el sensor hasta la notificación al cliente. Es la compuerta más importante del onboarding, y la que más se apura por presión de calendario.

Fase 5 — Tuning y alineación operativa. El SOC Manager afina las reglas para bajar el ruido, establece baselines de comportamiento, y —sobre todo— cierra los acuerdos que gobiernan la respuesta: los playbooks personalizados, la clasificación de severidad validada por el cliente, y la tabla de acciones pre-autorizadas firmada por el Sponsor. Sin esa firma, el SOC no puede contener nada por su cuenta.

Fase 6 — Handoff a operaciones. El acta de cierre, firmada por el SOC Manager y el Sponsor, marca el fin del onboarding y el inicio formal del servicio 24/7. Todo lo que quedó pendiente se documenta como deuda post-onboarding, no se barre bajo la alfombra.

Validación: probar el pipeline, no confiar en él#

La Fase 4 merece detenerse porque encierra el principio que separa un onboarding serio de uno decorativo: una fuente conectada no es una fuente que funciona. La conexión se prueba, extremo a extremo, generando eventos controlados y confirmando que la cadena sensor → SIEM → reglas → ticket → analista → notificación al cliente no tiene un eslabón roto en el medio.

Las pruebas típicas cubren las categorías de detección principales con estímulos benignos y reproducibles:

• Un intento de fuerza bruta controlado contra una cuenta de prueba, para validar la telemetría de identidad y la regla que la correlaciona.
• La ejecución de un archivo de prueba EICAR —una cadena estándar e inofensiva que todo antivirus reconoce como test— para validar la cadena EDR → alerta.
• Consultas DNS a dominios de prueba conocidos, para validar la telemetría de red y la detección de patrones sospechosos.
• Gestión de cuentas de prueba en Active Directory (creación, cambio de privilegios), para validar la detección de cambios de identidad.

El archivo EICAR es el ejemplo perfecto de estímulo controlado: es una cadena de 68 caracteres definida por estándar, sin ninguna capacidad maliciosa, que existe precisamente para probar defensas sin usar malware real.

Si esa detección no llega al analista con el contexto correcto, la fuente no está validada, por más que el dashboard la muestre en verde. La compuerta de la Fase 4 —criterio bloqueante— exige que el 100% de las fuentes críticas lleguen al SIEM sin gaps y que la cadena de alerta funcione de punta a punta antes de pasar a producción. La latencia de ingestión también se mide: la referencia operativa es menos de cinco minutos para fuentes on-premise y menos de quince para cloud.

Quién hace qué: la matriz RACI#

El punto de fricción más común en un onboarding no es técnico: es de gobernanza. «Pensé que lo hacías tú» es la causa raíz de la mitad de los retrasos. La matriz RACI —quién es Responsable de ejecutar, quién Aprueba (accountable), a quién se Consulta, a quién se Informa— existe para que esa frase no se pronuncie nunca.

En un MDR los roles se reparten entre dos equipos:

La dinámica que gobierna casi todo el despliegue es la separación entre configurar y ejecutar:

sequenceDiagram
    participant CT as Contacto Técnico (cliente)
    participant II as Ing. Integración (MDR)
    participant SM as SOC Manager (MDR)
    participant SL as Sponsor (cliente)

    Note over II,CT: Fase 3 — Despliegue
    II->>CT: Especifica qué reenviar y cómo
    CT->>CT: Despliega forwarders, abre puertos, instala agentes
    CT->>II: Confirma envío de logs
    II->>II: Configura parsing, reglas, baselines
    II->>SM: Entrega integración para validación
    Note over SM,SL: Fase 5 — Alineación
    SM->>SL: Presenta severidades y tabla de pre-autorizaciones
    SL->>SM: Firma acciones de contención autorizadas
    SM->>SL: Acta de cierre (Fase 6)
    SL-->>SM: Firma — inicio del servicio

Lo que se ve en la secuencia es el reparto que define el servicio: el Ingeniero de Integración es responsable de la configuración del SIEM, el parsing, las reglas y los baselines; el Contacto Técnico es responsable del despliegue físico en la infraestructura del cliente; el SOC Manager aprueba la validación técnica y los playbooks; y el Sponsor aprueba formalmente las pre-autorizaciones y el acta de cierre. Ninguna de esas cuatro cosas es negociable ni intercambiable, y escribirlas explícitamente es lo que evita las zonas grises.

Compuertas de calidad: los criterios de aceptación#

Cada fase cierra contra una lista de criterios de aceptación clasificados por nivel de exigencia. No todos pesan igual, y esa jerarquía es la que le da dientes al proceso:

Algunos criterios bloqueantes representativos, por fase:

El conjunto completo suma más de cincuenta criterios distribuidos entre las fases. La lógica es de compuerta: el criterio bloqueante no es una recomendación que se puede diferir, es una condición de avance. Firmar la tabla de pre-autorizaciones no es papeleo — es lo que determina si el SOC puede aislar un endpoint comprometido a las tres de la mañana o tiene que esperar a que alguien conteste el teléfono.

El tablero que lo ejecuta#

Todo lo anterior —fases, RACI, criterios— se vuelve accionable en un tablero Kanban con alrededor de cincuenta tarjetas, desde la 0.1 (handoff comercial) hasta la 6.5 (firma del acta de cierre). Cada tarjeta lleva su fase, su responsable, una etiqueta de dueño (MDR / Cliente / Compartida), una fecha límite atada al SLA de onboarding, y un checklist. Y cada tarjeta apunta a una plantilla que produce el entregable concreto: el inventario de activos, la documentación de integración por fuente, la aprobación de playbooks, el acta de cierre.

El tablero es la capa que conecta el plano con la ejecución diaria: la matriz RACI dice quién, los criterios de aceptación dicen cuándo está terminado, y el Kanban dice qué toca ahora. Sin esa traducción, el proceso más elegante se queda en un diagrama que nadie sigue.

Con el cliente adoptado, el SOC ya puede ver su red. La próxima entrega es sobre qué, exactamente, mira: el catálogo de telemetría, las fuentes que alimentan la detección, cómo se priorizan según el perfil del cliente, y cómo cada una se ancla a una táctica concreta de MITRE ATT&CK. El onboarding conecta los sensores; la telemetría decide qué vale la pena escuchar.

Esta serie continúa en Arquitectura de un SOC MDR · II — Telemetría: qué mira un SOC y cómo se decide. Sobre lo que pasa cuando una alerta cruza el umbral y se vuelve una acusación que hay que resolver, ya escribí en Del alert al veredicto.