Parte: 8 — Blue Team, detección y SOC · Fuente: Blue Team Handbook: SOC, SIEM, and Threat Hunting Use Cases — Don Murdoch ⏱️ Duración estimada: 100 min · Nivel: Intermedio
Comprender qué es un SIEM (Security Information and Event Management), de qué piezas se compone y cómo fluye un evento desde la recolección hasta la alerta. Entenderás las decisiones de arquitectura (ingesta, parsing, indexación, correlación, retención) que determinan si un SIEM detecta o solo acumula datos.
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | Definición y funciones del SIEM | Clarifica su rol en el SOC |
| 2 | Pipeline de ingesta | Determina qué datos entran y en qué forma |
| 3 | Parsing y normalización | Sin campos limpios no hay correlación |
| 4 | Enriquecimiento (GeoIP, threat intel, activos) | Convierte datos en contexto |
| 5 | Motor de correlación y reglas | El corazón de la detección |
| 6 | Indexación, búsqueda y retención | Afecta velocidad y coste |
| 7 | Dimensionamiento (EPS, GB/día) | Base del presupuesto y la licencia |
| 8 | Modelos de despliegue | On-prem vs cloud vs gestionado |
Un SIEM es una cadena de suministro de evidencia. Si un eslabón pierde datos, cambia tipos o introduce retraso, la consulta final puede ejecutarse correctamente y aun así responder mal. La arquitectura debe observar su propia salud: último evento por fuente, tasa recibida, errores de parseo, retraso, descartes y capacidad de las colas son señales de seguridad.
EPS mide eventos por segundo, mientras GB/día mide bytes ingeridos; ninguno sustituye al otro. El diseño debe considerar picos, tamaño por evento, compresión, réplicas y consultas concurrentes. Un buffer desacopla productores y consumidores, pero requiere política frente a saturación: bloquear, descartar o desviar son decisiones con consecuencias distintas.
El enriquecimiento añade valor —criticidad del activo, propietario, identidad o inteligencia—, pero necesita procedencia y caducidad. Una dirección IP puede cambiar de propietario; un usuario puede rotar de función. Finalmente, una coincidencia analítica no es un caso investigado: la capa de alertas debe agrupar, deduplicar y conservar el razonamiento que llevó a una decisión.
Imagina una caída de red de veinte minutos. Un agente con buffer local puede reenviar los eventos cuando vuelve la conexión; un envío UDP sin confirmación puede perderlos. Ambos dashboards podrían verse normales después. Por eso la arquitectura se decide preguntando qué pérdida es aceptable, cuánto retraso tolera cada detección y cómo se demuestra la recuperación. La cola no es solo rendimiento: es parte de la integridad operativa.
El dimensionamiento requiere una historia cuantitativa. Si 5.000 endpoints producen un promedio moderado pero una actualización dispara creación de procesos simultánea, el pico puede superar parsers o indexadores. Se miden percentiles y ráfagas, no únicamente promedio diario. Si el sistema aplica backpressure, se observa dónde crece la cola y cuánto tiempo hay antes de agotar disco. Si descarta, se define qué fuente pierde prioridad y quién recibe la alerta.
El diagrama también muestra dos productos diferentes: eventos y casos. Entre ambos deben existir reglas de agrupación. Diez alertas del mismo proceso en un host pueden ser un caso; la misma alerta en cien hosts puede ser una campaña. Esa decisión necesita claves de correlación y ventanas explícitas. Diseñar el SIEM desde preguntas investigativas evita comprar capacidad de ingesta sin capacidad real de explicación.
No toda la telemetría necesita la misma velocidad. Los eventos usados por alertas inmediatas permanecen en una capa de consulta rápida; la historia menos consultada puede pasar a almacenamiento económico y restaurarse cuando una investigación lo requiera. Esta separación obliga a definir cuánto tarda la restauración y qué búsquedas dejan de ser posibles. Una política de treinta días «hot» y un año archivado no equivale a trece meses de búsqueda instantánea.
La arquitectura también debe protegerse. Un SIEM concentra identidades, direcciones, comandos y hallazgos sensibles. El acceso se separa por función; las cuentas de ingesta no administran reglas; los analistas no alteran evidencia original; las acciones administrativas se auditan fuera de la misma frontera cuando sea posible. Alta disponibilidad no solo significa réplicas: se prueban recuperación, consistencia y continuidad de colectores.
Agregar «activo crítico» parece simple hasta que el inventario está atrasado. Cada enriquecimiento necesita fuente, momento de consulta y vigencia. Para investigaciones históricas puede ser incorrecto usar el propietario actual de un host sobre un evento de hace seis meses. Cuando el contexto histórico no existe, el analista debe indicarlo. El enriquecimiento ayuda a priorizar, pero nunca debe ocultar el evento de origen ni convertir reputación externa en veredicto.
Una prueba arquitectónica completa inyecta un evento conocido, sigue su recorrido y mide cada etapa: generación, recepción, parseo, indexación, coincidencia, alerta y caso. Si el evento llega pero la alerta no, la falla está después de ingesta; si no llega, revisar la regla desperdicia tiempo. Esa localización sistemática es una competencia central del ingeniero SIEM.
src_ip, user, event_id). Característica: específico por tipo de fuente.Una detección de creación de cuentas producía resultados diarios y pasa a cero. Reiniciar la búsqueda o bajar el umbral no identifica la causa. Se recorre el pipeline desde el origen:
La causa es transporte, no lógica de detección. La respuesta restaura confianza/certificado, observa que la cola drena sin pérdida y comprueba el evento sintético hasta el caso. Si solo se hubiera mirado el dashboard de alertas, «cero» podría interpretarse como ausencia de ataques.
Supón 5.000 endpoints, 0,8 EPS promedio y picos de 4 EPS durante actualizaciones. El promedio conjunto es 4.000 EPS, pero el pico teórico alcanza 20.000. El diseño debe declarar simultaneidad realista, tamaño por evento, duración, capacidad de buffer y margen. GB/día se calcula aparte porque dos eventos pueden diferir mucho en tamaño. Estas estimaciones se validan con medición, no se presentan como capacidad garantizada.
El alumno debe localizar una falla por etapa, distinguir ingestión de detección, justificar buffer y política de saturación, y explicar cómo permisos, retención y enriquecimiento afectan evidencia. Dibujar componentes sin flujos de salud ni decisiones de fallo es insuficiente.
Para experimentar la arquitectura, prepara en laboratorio aislado uno de estos stacks:
Reutiliza la telemetría de la clase 182 (Sysmon, Zeek) como fuente de ingesta. Trabaja siempre en tu red de laboratorio.
process.command_line o Image están extraídos, no en texto plano.geoip o Splunk iplocation).Documenta el recorrido de un evento real de tu laboratorio: captura de pantalla del dato crudo, del dato parseado con sus campos, del enriquecimiento aplicado y de la alerta correlacionada que dispara. Criterio de aceptación: la regla de correlación de fuerza bruta (múltiples 4625 + un 4624) dispara una alerta en el SIEM y puedes explicar en qué índice quedó y cuánto tiempo se retiene.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
| Eventos llegan como texto plano | Falta parser para esa fuente; crea/asigna el sourcetype |
| Licencia excedida en Splunk | Ingesta mayor a lo contratado; filtra ruido en el forwarder |
| Búsquedas lentísimas | Retención mal segmentada; usa índices y fases hot/cold |
| Alertas duplicadas | Correlación sin dedup ni throttling; añade ventana de supresión |
| GeoIP vacío | Base de datos GeoIP no instalada/actualizada; refresca el feed |
❓ ¿SIEM o data lake? El SIEM prioriza correlación y alertas en tiempo real; el data lake, almacenamiento masivo barato. Muchas arquitecturas modernas combinan ambos (SIEM para lo caliente, lake para histórico).
❓ ¿El SIEM reemplaza al EDR? No. El EDR ve el endpoint en profundidad y responde; el SIEM correlaciona todas las fuentes. Se complementan; el EDR suele ser una fuente del SIEM.
❓ ¿Cómo evito que el SIEM se vuelva un basurero de logs? Ingesta con propósito de detección, no por acumular. Cada fuente debe respaldar al menos un caso de uso de detección o hunting.
Clase 182 — Logging y fuentes de telemetría