Arquitectura de un SOC MDR · II — Telemetría: qué mira un SOC y cómo se decide

En la entrega anterior el cliente quedó adoptado: fuentes conectadas, activos inventariados, compuertas cerradas. Ahora la pregunta es qué se mira, exactamente, y por qué eso y no otra cosa. Un SOC vive de su telemetría —los datos que las fuentes le envían—, y la tentación permanente es querer verlo todo. Es una tentación cara y, peor, contraproducente: recolectar sin criterio no produce visibilidad, produce volumen, y el volumen entierra la señal que importa bajo la que no.

Esta segunda entrega documenta el catálogo de telemetría de un servicio MDR como lo que es: una serie de decisiones. Qué fuentes existen, cómo se agrupan, cuáles son obligatorias y cuáles condicionales según el perfil del cliente, y —la parte que separa un catálogo útil de una lista de compras— cómo cada fuente se justifica por las tácticas de ataque que permite detectar. El catálogo de referencia tiene treinta fuentes; el criterio para elegir entre ellas es lo que vale la pena copiar.

La telemetría es una decisión, no una captura#

La fantasía del «recolectemos todo y después vemos» se rompe contra tres muros: costo (el SIEM cobra por volumen ingerido, y un firewall solo puede escupir veinte mil eventos por segundo), ruido (cada fuente irrelevante que se suma diluye las que importan) y foco (un analista que revisa cien fuentes no revisa ninguna bien). La disciplina opuesta es un catálogo agnóstico: categorías de fuente definidas por lo que aportan, no por el producto que las genera, con los vendors como ejemplos intercambiables. «EDR» es la categoría; CrowdStrike, Defender, SentinelOne o Wazuh son implementaciones de la misma decisión.

Cada fuente del catálogo se documenta con los mismos campos, y esos campos son el criterio de decisión hecho explícito: qué datos aporta, cómo se integra, qué formato tiene, qué volumen estimado en eventos por segundo, qué permisos exige, qué tácticas de MITRE ATT&CK cubre, qué amenazas detecta, y con qué prioridad entra según el perfil. Una fuente no entra al catálogo porque exista; entra porque cubre una táctica que otra fuente no cubre, para un perfil que la necesita.

Arquitectura: de la fuente al veredicto#

Antes del catálogo conviene ver el recorrido que hace un evento, porque explica por qué las categorías se agrupan como se agrupan. Todo termina en el mismo lugar —un analista con un veredicto que emitir— y todo sale del mismo tipo de origen: un sensor que observa una porción de la realidad.

flowchart LR
    subgraph SRC["Fuentes (7 dominios)"]
        E["Endpoint\nEDR · SO · FIM"]
        N["Red\nFW · NDR · DNS · Proxy"]
        I["Identidad\nAD · IdP · MFA · PAM"]
        C["Cloud\nCloudTrail · Flow · nativo"]
        M["Email\nM365 · gateway"]
        S["SaaS\ncolaboración · dev · CASB"]
    end

    E & N & I & C & M & S --> COL["Colectores / conectores\n(agente · syslog · API REST)"]
    COL --> SIEM["SIEM\nnormalización · parsing\ncorrelación · reglas"]
    TIP["Threat Intel\n(IOCs)"] -.enriquece.-> SIEM
    SIEM --> DET{"¿Alerta?"}
    DET -->|sí| ANL["Analista L1\ntriaje"]
    DET -->|no| STORE[("Almacenamiento\n/ hunting")]
    ANL --> SOAR["SOAR\nplaybooks · respuesta"]
    SIEM -.salud de ingestión.-> HEALTH["SIEM Health\n¿fuente en silencio?"]

Tres cosas de este flujo importan para el resto de la serie. Primero: el SIEM no es una fuente, es donde las fuentes se cruzan —la correlación entre dominios es donde vive la detección real, porque casi ningún ataque se delata en una sola fuente—. Segundo: el threat intelligence no detecta, enriquece: le da contexto a lo que las fuentes ya trajeron. Tercero: hay una fuente que observa al observador —la salud del propio SIEM—, y ese lazo, que parece burocrático, es el que detecta cuando alguien apaga una fuente para cegar al SOC.

Los siete dominios#

Las treinta fuentes se agrupan en siete dominios según qué porción de la realidad observan. La agrupación no es cosmética: cada dominio responde una pregunta distinta sobre un ataque.

• Endpoint (qué pasó en la máquina) — EDR/XDR, eventos del sistema operativo (Windows Event Log + Sysmon, auditd), monitoreo de integridad de archivos (FIM), gestión de vulnerabilidades. El EDR es la fuente más rica en contexto de actividad maliciosa: ejecución de procesos, relación padre-hijo, inyección de código.
• Red (qué se movió por el cable) — firewall/NGFW, NDR, IDS/IPS, DNS query logs, proxy web, VPN, SASE/SD-WAN. El DNS es el caso paradigmático de «alto volumen, altísimo valor»: muchos ataques avanzados se detectan primero por una consulta DNS anómala.
• Identidad (quién lo hizo) — Active Directory on-premise, IdP cloud (Entra ID, Okta), MFA, PAM. Es el dominio que conecta el «qué» con el «quién», y por eso el más buscado por los atacantes.
• Cloud (qué pasó en la infraestructura virtual) — audit logs del provider (CloudTrail, Azure Activity Log, GCP Audit Logs), VPC/NSG flow logs, detección nativa (GuardDuty, Defender for Cloud, Security Command Center).
• Email (por dónde entró) — plataforma corporativa (M365 Unified Audit Log, Google Workspace) y gateway de seguridad. Cubre el vector de acceso inicial más común: phishing y compromiso de correo.
• SaaS (qué datos se tocaron) — productividad y colaboración (SharePoint, Drive, Teams), plataformas de desarrollo (GitHub, GitLab —relevante para supply chain—), CRM, CASB.
• Herramientas (el SOC observándose) — salud del SIEM, SOAR, threat intelligence platform, microsegmentación. Meta-telemetría: no observa la amenaza, observa la capacidad de detección.

Prioridad por perfil: qué es obligatorio y qué es condicional#

Ninguna organización necesita las treinta fuentes. Lo que necesita depende de su forma —dónde vive su riesgo—, y el catálogo lo resuelve con perfiles de integración: plantillas de referencia que se personalizan en el onboarding. Hay una baseline mínima que no admite excepción, y sobre ella se apilan las fuentes según el perfil.

La prioridad de cada fuente se expresa por perfil —Crítica, Recomendada, Opcional, o no incluida por defecto—:

Dos detalles del perfil valen doble. En híbrido, los logs de Entra Connect / Azure AD Connect son un objetivo de alto valor: un compromiso ahí permite pivotar entre el mundo on-premise y el cloud, así que la fuente que vigila el puente es tan crítica como los dos lados que une. En OT/IoT, el monitoreo es exclusivamente pasivo —txOne, Claroty, Nozomi, Dragos—: en un entorno industrial no se puede meter un agente en un PLC ni escanear activamente una red de control sin arriesgar la disponibilidad que es, ahí, la prioridad absoluta.

Anclar cada fuente a MITRE ATT&CK#

El campo que convierte el catálogo en una herramienta de diseño y no en un inventario es el mapeo a ATT&CK. Cada fuente declara qué tácticas cubre, y cruzar todas las fuentes contra las catorce tácticas produce un mapa de cobertura: qué parte de la kill chain el SOC puede ver, y qué parte tiene a ciegas.

(● cobertura directa · ◐ parcial o contextual · ○ sin cobertura)

Leído así, el catálogo diagnostica sus propios huecos. El Command & Control lo cubren red, DNS, NDR y proxy —perder DNS deja medio ciego ese flanco—. El Lateral Movement casi no aparece en endpoint y depende de Active Directory y NDR: un cliente sin NDR y con AD mal auditado tiene un punto ciego exactamente donde el atacante se mueve entre máquinas. Y el Credential Access vive en identidad y EDR: si el directorio no está enviando los eventos correctos de Kerberos, el Kerberoasting pasa sin ruido. El mapa no dice «poné más fuentes»; dice dónde, para este cliente, un ataque podría cruzar sin dejar rastro en ninguna fuente conectada.

La fuente que se apaga#

Queda la meta-telemetría, y encierra un principio que se subestima: la ausencia de datos es un dato. La salud del SIEM —cuántos eventos por segundo entra cada fuente, si hay errores de parsing, si un conector se cayó— parece monitoreo de infraestructura, cosa de operaciones. Pero una fuente que deja de enviar puede significar dos cosas, y las dos importan: se rompió la integración, o alguien la apagó para cegar al SOC antes de actuar. Deshabilitar el logging es una técnica de evasión catalogada; el único que la detecta es el que vigila el silencio.

Por eso el catálogo incluye la salud del SIEM como fuente de detección, no solo de operación. Una regla que alerte cuando una fuente crítica baja su volumen esperado —o lo lleva a cero— es tan defensiva como la que detecta un proceso malicioso. La diferencia es sutil: no busca actividad, busca su desaparición.

Enviar un evento de prueba conocido y confirmar que aparece en el SIEM en el tiempo esperado es la versión activa de la misma idea: no asumir que una fuente funciona porque alguna vez funcionó. El onboarding valida el pipeline una vez; la salud del SIEM lo revalida de forma continua, porque una integración que se cae en silencio es un punto ciego que nadie eligió.

Con las fuentes elegidas, priorizadas y ancladas a lo que permiten detectar, el SOC ya sabe qué mira. La próxima entrega es sobre lo que pasa cuando algo de lo que mira cruza el umbral: la respuesta a incidentes —las categorías de incidente, las severidades, los tiempos de respuesta acordados, el escalamiento interno y la notificación regulatoria—. La telemetría produce la acusación; la respuesta la convierte en veredicto y acción.

Continúa en Arquitectura de un SOC MDR · III — Respuesta a incidentes: del alert al veredicto, a escala de servicio. Sobre por qué una alerta no es todavía un incidente y qué trabajo vive en esa distancia, está Del alert al veredicto; sobre por qué un control sin lazo de retroalimentación —como una fuente que se cae sin avisar— es un control muerto, Anatomía de un control.