Arquitectura de un SOC MDR · III — Respuesta a incidentes: del alert al veredicto, a escala de servicio

Las dos entregas anteriores construyeron la capacidad de ver: el cliente adoptado, las fuentes eligiendo qué mirar. Esta es sobre lo que pasa cuando algo de lo que se mira resulta ser real. Una alerta cruza el umbral y deja de ser una curiosidad: se vuelve un incidente, y con el incidente empieza un reloj. En un SOC interno ese reloj es operativo —cuánto se tarda en contener—. En un SOC MDR que atiende a operadores de servicios esenciales, algunos de esos relojes son legales, y arrancan en el minuto exacto en que un analista toma conocimiento.

Esta tercera entrega documenta la respuesta a incidentes como plano: cómo se clasifica un incidente para disparar el playbook correcto, cómo se le asigna una severidad que fija la velocidad de respuesta, cómo recorre el ciclo de vida de contención a lecciones aprendidas, y cómo se escala —hacia adentro, hacia el cliente, y hacia el regulador— sin que se pierda el minuto que la ley cuenta. El marco de referencia es NIST SP 800-61 para el ciclo y la Ley 21.663 chilena para las obligaciones de reporte; el esqueleto vuelve a ser general.

Clasificar para actuar: las nueve categorías#

Un incidente no se responde en abstracto: se responde con un playbook, y el playbook se elige por el tipo de amenaza. La taxonomía de incidentes existe para que la primera pregunta —«¿qué es esto?»— tenga una respuesta accionable que despache la respuesta correcta.

Las categorías no son mutuamente excluyentes, y ahí está su valor: un phishing exitoso (CAT-3) que instala malware se trata también como CAT-1 concurrente; si deriva en robo de credenciales, como CAT-2. Un incidente real muta de categoría a medida que se entiende, y el playbook se compone en vez de elegirse una sola vez. La categoría CAT-9 —cadena de suministro— es la que motivó El eslabón que firma: un proveedor comprometido no entra por ninguna de las puertas que las otras ocho vigilan.

La severidad fija el reloj#

Sobre la categoría —qué es— se superpone la severidad —cuán urgente es—. La severidad no describe el incidente: describe la velocidad de la respuesta, los recursos que se activan y las notificaciones que se disparan. Y está deliberadamente alineada con el umbral regulatorio, para que la clasificación técnica y la obligación legal no vivan en planillas separadas.

El ciclo de vida: de la identificación a la lección#

La respuesta sigue el ciclo de NIST SP 800-61, adaptado a un servicio gestionado. No es lineal en la práctica —se itera, se reclasifica, se vuelve a contener cuando aparece un sistema más— pero el esqueleto ordena el trabajo y, sobre todo, ordena las manos: quién puede hacer qué en cada fase.

flowchart TD
    A["Preparación\n(pre-autorizaciones, playbooks,\njump bag, baselines)"] --> B["Identificación\nL1 evalúa la alerta dentro del SLA\nde su severidad preliminar"]
    B --> T{"¿Falso positivo\no actividad legítima?"}
    T -->|sí| CLOSE(["Cierre + registro"])
    T -->|no| ESC["Escala a L2 · registra T0\n(hora de toma de conocimiento)"]
    ESC --> SEV["L2 confirma severidad,\nmapea a ATT&CK,\ndetermina alcance"]
    SEV --> C["Contención\ninmediata: aislar, cortar C2\nextendida: parche, hardening"]
    C --> D["Erradicación\neliminar persistencia,\nrotar credenciales, limpiar"]
    D --> E["Recuperación\nrestaurar servicio +\nmonitoreo reforzado (72h P1/P2)"]
    E --> RECHECK{"¿Signos de\nre-infección?"}
    RECHECK -->|sí| C
    RECHECK -->|no| F["Lecciones aprendidas\n(5 días hábiles, P1/P2)"]
    F --> A

Dos matices de este ciclo definen a un MDR maduro. La contención se separa en inmediata y extendida porque no son la misma decisión: aislar un endpoint por EDR es reversible y rápido; desconectar un segmento de red completo para frenar un ransomware es una decisión que impacta la continuidad del negocio y, en un servicio esencial, roza una obligación legal —por eso suele requerir autorización del Sponsor—. Y la recuperación no termina cuando el servicio vuelve: incluye monitoreo reforzado (mínimo 72 horas en incidentes P1/P2), porque el error clásico es cantar victoria mientras queda un backdoor o una cuenta extra que se pasó por alto. El lazo que vuelve de «recuperación» a «contención» no es decorativo: es la admisión de que erradicar mal es peor que no erradicar, porque deja creer que se terminó.

Sobre el trabajo que vive en la fase de identificación —convertir la acusación automática de una alerta en un veredicto firmado— ya escribí entero en Del alert al veredicto. Aquí basta el principio operativo que lo gobierna: ante la duda, el L1 declara el incidente y escala; el costo de un falso positivo escalado es minutos de un analista, el de un compromiso ignorado es el caso Target.

El escalamiento corre en dos direcciones#

Cuando un incidente se confirma, la comunicación se abre en dos frentes a la vez: hacia adentro (activar al equipo con el rango de decisión necesario) y hacia afuera (informar al cliente y, si corresponde, al regulador). Los dos frentes comparten un solo dato de anclaje: T0, la hora exacta en que el analista toma conocimiento del incidente. En un cliente sujeto a la Ley 21.663, ese T0 no es un metadato: es el minuto desde el cual la ley cuenta las tres horas para la alerta temprana.

sequenceDiagram
    participant L1 as Analista L1
    participant L2 as L2 / L3
    participant SM as SOC Manager (Incident Commander)
    participant CL as Cliente (CT/CS/Sponsor)
    participant AN as ANCI / CSIRT Nacional

    L1->>L1: Registra T0 (toma de conocimiento)
    L1->>L2: Escala con severidad preliminar
    L2->>SM: Confirma P1 / efecto significativo
    Note over SM: SOC Manager activa al equipo (P1)
    SM->>CL: Notificación (P1: llamada, no solo email)
    SM->>CL: Actualizaciones cada 2h mientras P1 activo
    alt PSE/OIV con efecto significativo
        SM->>AN: Alerta temprana ≤ 3h desde T0
        SM->>AN: Segundo reporte ≤ 72h (24h si OIV)
        SM->>AN: Informe final ≤ 15 días
    end
    Note over SM,CL: Si se sospecha del canal: comunicación out-of-band

El reparto de rango es el corazón de la secuencia. El L1 monitorea y triangula, pero no contiene por su cuenta: escala con una severidad preliminar. El L2 confirma la severidad definitiva, mapea a ATT&CK, mide el alcance y ejecuta las acciones de contención que están pre-autorizadas. El SOC Manager actúa como Incident Commander en los P1: coordina, aprueba las acciones de contención que no estaban pre-autorizadas, y —el punto que lo hace responsable— revisa y aprueba los reportes regulatorios antes de que el cliente los envíe, asegurando que se cumplan los plazos. Un detalle que parece menor y no lo es: si hay sospecha de que el atacante tiene acceso a los sistemas de comunicación, la coordinación pasa a un canal out-of-band —el teléfono—, porque discutir la respuesta en un chat que el atacante lee es entregarle el plan.

Cuando el reloj es legal#

La capa regulatoria es lo que distingue a un incidente gestionado de uno resuelto en soledad, y es la que menos perdona la improvisación. Bajo la Ley Marco de Ciberseguridad chilena (Ley 21.663, vigente desde marzo de 2025), los Prestadores de Servicios Esenciales (PSE) y los Operadores de Importancia Vital (OIV) tienen que reportar los incidentes de efecto significativo a la Agencia Nacional de Ciberseguridad en una cascada de plazos:

Hay una obligación técnica que la normativa fija con número y que conviene subrayar porque toca el diseño del servicio: el cambio de credenciales privilegiadas dentro de las 3 horas ante un compromiso, junto con la verificación de accesos remotos, VPN y MFA. Eso solo es posible si en el onboarding se dejó preparada la capacidad de rotar credenciales rápido —otra deuda que se paga barata antes y carísima durante—. Y hay un límite que la propia normativa impone sobre el reporte: si el incidente capturó datos personales de clientes o usuarios, esos datos se manejan bajo la ley de protección de datos y se omiten del reporte a la ANCI. Reportar el incidente no autoriza a filtrar a las víctimas en el reporte.

Cuando el incidente además constituye un delito —acceso ilícito, fraude informático bajo la Ley 21.459— se evalúa la denuncia al Ministerio Público. Son vías paralelas: la regulatoria protege la continuidad del servicio, la penal persigue al responsable, y una no reemplaza a la otra.

La medición y la lección#

Dos indicadores gobiernan la mejora del servicio: el MTTD (tiempo medio de detección, desde que ocurre el evento hasta que se detecta) y el MTTR (tiempo medio de respuesta, desde la detección hasta la contención). No son métricas de vanidad para un dashboard: el MTTD mide la calidad de la telemetría y las reglas de la entrega anterior; el MTTR mide la calidad de los playbooks y las pre-autorizaciones de esta. Un MTTD alto significa que el atacante vive semanas adentro sin ser visto —el problema de fondo de la cadena de suministro—; un MTTR alto significa que se lo ve y aun así se lo contiene tarde.

Y cada incidente P1 o P2 cierra con una revisión de lecciones aprendidas dentro de los cinco días hábiles, con el equipo del MDR y el cliente en la misma sala. La pregunta no es a quién culpar —esa es la salida fácil que impide aprender— sino qué en el sistema permitió que el incidente llegara donde llegó, y qué control cierra ese hueco. Esa fase es la que alimenta de vuelta la fase de preparación, y sin ella el ciclo no es un ciclo: es una línea que termina en el mismo lugar por donde el próximo atacante va a entrar.

La respuesta contiene, erradica y recupera el servicio en el caso normal. Pero hay un caso en que la contención no alcanza —el ransomware que ya cifró producción, el wiper que ya borró—, y ahí entra un plan distinto que corre en paralelo: la recuperación ante desastres. La última entrega de la serie es sobre el DRP: los tiers de sistemas, los objetivos de tiempo y de punto de recuperación, y la decisión de negocio —restaurar, negociar o reconstruir— que ningún SOC toma solo.

Continúa en Arquitectura de un SOC MDR · IV — Recuperación: cuando la contención no alcanza. Sobre por qué la unidad de análisis del error es la estructura y no la persona —el principio que sostiene la fase de lecciones aprendidas— está El analista era el control.