Logging & detection - señales y alertas

Logging & detection es la pieza de la detección que vive de señales: trazas de auditoría, logs del plano de control, logs del plano de datos, eventos de runtime, salidas de DNS y eventos de identidad. El trabajo es recolectar todo eso en un solo lugar, retenerlo el tiempo suficiente y disparar una alerta cuando aparece algo fuera del patrón.

CSPM escanea la configuración; CWPP escanea el comportamiento del workload. Aquí la pregunta es más amplia: '¿qué pasó en esta cuenta en los últimos 90 días, y volvió a pasar ahora?'. La respuesta vive en la correlación: un AssumeRole puede ser legítimo por sí solo, y criminal cuando se combina con un kms:Decrypt cinco minutos después y un GetObject en un bucket que nadie de ese rol debería abrir.

El pilar clásico es el log del plano de control: cada llamada de API, firmada, con ARN del principal, IP de origen, user agent, request parameters y response elements. En AWS es CloudTrail; en Azure es el Activity Log; en GCP es Cloud Audit Logs. Es el log que responde 'quién llamó a qué, cuándo, y cuál fue el resultado'. Sin él, el incidente se vuelve una conjetura.

CloudTrail por defecto registra eventos de gestión (crear usuario IAM, eliminar bucket) en la traza de la cuenta, y mantiene los últimos 90 días en la consola. Para forense real, vale la pena crear una traza multirregional que escriba en S3 con object lock, y añadir un Lake o un SIEM encima para consultas y retención más larga.

CloudTrail no lo ve todo. Registra la llamada de API, no lo que ocurrió dentro de ella ni el paquete que pasó por la red. Para cerrar el hueco, tres fuentes se vuelven obligatorias.

Recolectar todo y dejar que cada cuenta tenga su bucket es receta para que el log desaparezca en el primer incidente. El diseño correcto es fan-out: cada cuenta escribe su log en S3 (o equivalente) con KMS, y un lake agregador o un SIEM corporativo jala todo para una consulta única.

La retención es donde la mayoría de los equipos se resbala. Los logs de gestión necesitan 90 días calientes (consulta rápida) y 365 días fríos (S3 + Glacier). Los logs de flujo de VPC, según el volumen, pasan a 30 días calientes y 180 días fríos. Los logs de auditoría que se volverán evidencia legal piden object lock (WORM) para impedir la alteración retroactiva - sin eso, un atacante con acceso de escritura borra sus propios rastros.

La capa de detección tiene tres sabores. Las reglas determinísticas (firmas) se disparan con una firma conocida: ConsoleLogin sin MFA, root API key en uso, disable de CloudTrail. ML / anomalías se disparan ante una desviación del baseline (login desde una región nunca vista, listado masivo de buckets por un usuario que normalmente lista tres). Hunting es el humano buscando lo que nadie pensó en convertir en regla.

GuardDuty combina los tres sabores en una sola oferta administrada: consume CloudTrail, VPC Flow Logs y DNS, y manda findings a EventBridge o Security Hub. La integración típica es que Detective entre para la investigación (grafo de entidades + timeline), Security Hub agregue con Prowler/Inspector, y el SOAR (Step Functions, Tines, Torq) dispare el runbook. El secreto es mantener la regla fuera del SIEM cuando el SIEM agrega mal, y usar GuardDuty para el 80% de los hallazgos obvios.

El SIEM (OpenSearch, Splunk, Elastic, Datadog Cloud SIEM) es donde ocurre la correlación. Cada fuente (CloudTrail, GuardDuty, flow logs, audit de k8s, EDR) se vuelve un stream indexado, con su propio parser y campos canónicos (time, actor, target, action, result). La regla del SIEM cruza fuentes: AssumeRole IAM nuevo + CloudTrail GetSecretValue + bucket público tocado en <5 min = sesión sospechosa.

Para reducir costo y ruido, dos hábitos dan alto retorno. Primero, tiers de almacenamiento: calientes en el SIEM (30 días), fríos en S3 (Iceberg, Parquet) con Athena u OpenSearch Serverless consultando bajo demanda. Segundo, detección administrada para lo que no tienes equipo para mantener: GuardDuty cubre el 80% de los hallazgos obvios, CSPM cubre el drift de configuración, CWPP cubre el runtime. El SIEM queda para lo que es específico de la casa.