Parte: 8 — Blue Team, detección y SOC · Fuente: Applied Network Security Monitoring — Chris Sanders y Jason Smith · NIST SP 800-92 ⏱️ Duración estimada: 100 min · Nivel: Fundamentos
Aprender qué telemetría existe, cómo se clasifica y cómo diseñar una estrategia de recolección que no deje puntos ciegos críticos. Sin buenos datos, la mejor detección es inútil: esta clase construye la base de "materia prima" que alimentará el SIEM, el hunting y toda la detección posterior.
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | Taxonomía de datos NSM | Da un vocabulario para pensar la telemetría |
| 2 | Fuentes de endpoint (Event Logs, Sysmon, EDR) | Donde ocurre la ejecución del ataque |
| 3 | Fuentes de red (flujo, PCAP, DNS, proxy) | Ven lo que el host puede ocultar |
| 4 | Identidad y autenticación (AD, IdP, VPN) | Permite reconstruir quién accedió, desde dónde y con qué privilegios |
| 5 | Nube y SaaS (CloudTrail, M365 audit) | El log del data center ya no basta |
| 6 | Normalización y marcas de tiempo (UTC, NTP) | Sin tiempo correcto no hay correlación |
| 7 | Retención y coste | Equilibra visibilidad y presupuesto |
| 8 | Puntos ciegos y cobertura | Delimita qué comportamientos pueden investigarse y cuáles quedan sin evidencia |
La telemetría defensiva debe tratarse como un producto de datos con propósito, no como una acumulación indiscriminada. Cada fuente debe responder qué comportamiento permite observar, con qué campos, durante cuánto tiempo y con qué limitaciones. Endpoint muestra procesos y archivos; identidad muestra autenticaciones y privilegios; red aporta relaciones y protocolos; nube y aplicaciones revelan acciones que nunca pasan por un host administrado. Ninguna fuente ofrece por sí sola la historia completa.
Conviene conservar el evento original y producir, además, una representación normalizada. El original permite revisar errores del parser; el esquema común permite correlacionar fuentes. Deben distinguirse al menos tres tiempos: cuándo ocurrió la acción, cuándo la registró el productor y cuándo llegó a la plataforma. Esa diferencia explica eventos tardíos y obliga a usar ventanas con solapamiento.
La retención se decide por caso de uso, riesgo, obligación legal, privacidad y coste. «Guardar todo» puede aumentar exposición y ruido. Para cada fuente se valida completitud, puntualidad, fidelidad de campos, volumen esperado y ausencia de duplicados. Una regla perfecta sobre datos interrumpidos es una detección inexistente.
Para detectar una cuenta que usa RDP por primera vez no basta pedir «logs de Windows». La hipótesis necesita, como mínimo, identidad, host origen, host destino, tipo de inicio de sesión y tiempo; para evaluar rareza necesita además historia suficiente. Ese desglose convierte un deseo genérico en un contrato verificable. Si el origen llega vacío en el 40 % de los eventos, la detección no tiene la misma cobertura aunque el SIEM muestre millones de registros.
La normalización tampoco consiste en renombrar columnas mecánicamente. Dos productos pueden usar user para la cuenta solicitante y la cuenta afectada. Antes de mapear se define la semántica y se conserva el campo original. Lo mismo ocurre con una IP detrás de NAT o con un hostname reutilizado: normalizar facilita consultas, pero la identidad de la entidad todavía necesita contexto.
Lee el diagrama de izquierda a derecha y prueba cada frontera. En la fuente se pregunta si el evento se genera; en el colector, si se pierde al desconectarse; en el parser, si los tipos y tiempos son correctos; en almacenamiento, si la retención cubre la investigación; y en detección, si llega antes del SLA. Un control sintético —por ejemplo, un evento benigno emitido cada hora— permite comprobar la cadena completa. Esto transforma «tenemos logging» en una afirmación medible.
Para investigar ejecución sospechosa se necesitan proceso, línea de comandos, identidad, linaje y, según la pregunta, firma o hash. Para abuso de identidad hacen falta autenticación, resultado, método, origen, recurso y cambios de privilegio. Para posible exfiltración se combinan red, proxy, aplicación y contexto del dato. Esta descomposición permite priorizar: una fuente costosa que no responde un caso relevante no gana valor por producir mucho volumen.
Las fuentes describen perspectivas diferentes. Endpoint asocia una conexión al proceso; red confirma que cruzó un sensor; DNS muestra resolución; identidad explica la sesión; la aplicación registra la acción de negocio. Si dos fuentes discrepan, se revisan relojes, NAT, proxies, campos y alcance de sensores. La discrepancia puede ser precisamente el hallazgo de calidad que faltaba.
El parser transforma tipos y extrae campos. Una cadena 10 y un entero 10 no siempre se consultan igual; una fecha sin zona puede desplazarse al normalizar. Los eventos fallidos no deberían desaparecer: pasan a una cola observable con muestra y razón. Se conserva mensaje raw, representación normalizada y versión del pipeline para atribuir un cambio a la fuente, al parser o a la analítica.
Un esquema común tampoco autoriza borrar matices. «Usuario actor» y «usuario objetivo» son relaciones distintas aunque el producto use una sola etiqueta. La semántica se documenta antes del mapeo. Esa disciplina evita correlaciones que parecen correctas porque los campos comparten nombre, pero describen entidades diferentes.
La ventana de investigación guía retención. Conservar autenticaciones siete días no permite reconstruir un acceso inicial descubierto al día treinta; guardar todo indefinidamente aumenta coste y privacidad. Se decide qué queda disponible inmediatamente, qué pasa a archivo y qué se elimina de forma verificable. La única copia tampoco debe quedar bajo control del host investigado: reenvío temprano, separación de cuentas y alertas por silencio protegen la historia.
Completitud mide lo recibido frente a lo esperado; puntualidad, la demora; exactitud, si el campo representa su contrato; consistencia, cambios y duplicados. Un catálogo registra propietario, propósito, campos críticos, tasa, latencia, retención y detecciones dependientes. Cuando la fuente se degrada, el SOC puede nombrar las capacidades afectadas en lugar de decir vagamente que «faltan logs».
La hipótesis es: «una cuenta de servicio que no usa sesiones interactivas inicia RDP desde un origen no administrativo». Se transforma en requisitos verificables:
| Pregunta | Campo o contexto | Si falta |
|---|---|---|
| ¿Qué identidad inició la sesión? | cuenta y dominio normalizados | no se puede atribuir |
| ¿Desde dónde? | host/IP origen y traducciones conocidas | no se evalúa ruta autorizada |
| ¿Hacia qué activo? | host destino y criticidad | no se prioriza impacto |
| ¿Qué clase de sesión? | tipo de logon o evento de RDP | se mezclan servicios y usuarios |
| ¿Era esperable? | inventario de cuentas y grafo administrativo | rareza sin contexto |
| ¿Qué ocurrió después? | procesos/sesión en destino | no se distingue acceso de actividad |
Se genera una sesión benigna controlada. El evento aparece en el host, tarda 40 segundos en llegar, conserva origen y mapea la identidad correctamente. Después se desconecta temporalmente el colector para verificar buffering. Finalmente se consulta un periodo histórico suficiente para establecer frecuencia. Esta prueba recorre el diagrama completo y produce evidencia de cobertura.
Si el campo origen queda vacío, la acción correcta no es añadir una regla que lo ignore. Se abre una brecha de dato, se identifica versión/configuración del productor y se declara que esa variante no está cubierta. El contrato permite decir qué se perdió y qué decisiones quedaron afectadas.
La estrategia es válida cuando cada fuente tiene propósito, propietario, campos críticos, latencia, retención y control de salud; el alumno puede explicar qué fuente confirma cada afirmación y qué conclusión no puede obtener con los datos disponibles.
Monta un laboratorio aislado con:
chrony/w32tm apuntando a una fuente confiable.Todo en tu red de laboratorio; no captures tráfico de redes que no te pertenecen.
sysmon64.exe -accepteula -i sysmonconfig.xml
Verifica en Visor de eventos: Applications and Services Logs > Microsoft > Windows > Sysmon/Operational.winlogbeat.yml) para enviar los canales Security y Sysmon/Operational hacia tu colector.module(load="imudp") y input(type="imudp" port="514")).zeek -i eth0 local. Revisa conn.log y dns.log.w32tm /query /status (Windows) y chronyc tracking (Linux). Todo en UTC.whoami /all) y confirma que aparece en el colector con timestamp coherente entre host y red.Entrega un plan de logging de una página con: matriz activo×fuente, prioridad (alta/media/baja) por fuente, política de retención y 3 puntos ciegos con su remediación. Criterio de aceptación: en tu laboratorio, un evento generado en el endpoint aparece en el colector central con la misma marca de tiempo (±2 s) que la vista local, demostrando reenvío y sincronización correctos.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
| Eventos con horas descuadradas | NTP no configurado; sincroniza todo a UTC |
| El SIEM no recibe Sysmon | Canal no incluido en Winlogbeat; añade Microsoft-Windows-Sysmon/Operational |
| Volumen de logs dispara el coste | Registras todo sin filtrar; filtra ruido (ej. eventos 4688 irrelevantes) |
| No hay rastro de un ataque conocido | Punto ciego; faltaba PowerShell/DNS logging |
| Campos incomparables entre fuentes | Sin normalización; adopta un esquema común (ECS) |
❓ ¿Registro todo o filtro? No existe una respuesta universal. Conserva las fuentes y campos que sostienen casos de uso, investigación, obligaciones y auditoría; mide volumen, privacidad y coste antes de excluir. Un filtro debe documentar qué evidencia elimina y cómo se valida que no rompa una detección.
❓ ¿Event Logs nativos o Sysmon? Ambos. Los nativos dan autenticación y auditoría; Sysmon aporta creación de procesos con hash, línea de comandos y conexiones por proceso.
❓ ¿Necesito PCAP completo? Solo en segmentos críticos y con retención corta. Para hunting histórico, los datos de sesión (flow/Zeek) rinden mucho más por byte almacenado.
Aplica el contrato de telemetría a las tres fuentes de verdad del
caso de custodia de activos digitales:
verifica los 20 campos mínimos, correlaciona request_id con tx_hash y explica
qué conclusión queda impedida si desaparecen los eventos de aprobación.
Clase 181 — El SOC moderno: roles, niveles y procesos