CloudTrail, GuardDuty y Security Hub:

montar detección en AWS

Seguridad en la nube  |  unfantasmaenelsistema.com

En un centro de datos propio, la detección se apoya en cosas físicas: un SPAN en el switch, un IDS en el perímetro, agentes en los servidores. En AWS no hay switch que pinchar ni perímetro que vigilar: la infraestructura es una API, y todo lo que pasa —crear una máquina, asumir un rol, leer un objeto de S3, abrir un grupo de seguridad— es una llamada registrable. La detección en la nube consiste en capturar bien ese registro y sacarle señales.

Este artículo recorre los tres servicios que forman la base de la detección en AWS: CloudTrail como registro de auditoría, GuardDuty como motor de detección gestionado, y Security Hub como agregador y marcador de cumplimiento. Cómo encajan, qué cuesta y cómo llevarlo todo a un SIEM.

1. CloudTrail: el registro de todo lo que se hace

CloudTrail registra las llamadas a la API de AWS: quién (identidad y credencial), qué acción, sobre qué recurso, desde qué IP, cuándo y con qué resultado. Es la fuente primaria de cualquier investigación en AWS. Hay que distinguir dos tipos de evento:

1.1 Configuración que aguanta un incidente

• Un trail de organización creado desde la cuenta de gestión, que recoge todas las cuentas y todas las regiones, incluidas las que abran en el futuro
• Entrega a un bucket S3 en una cuenta de log dedicada, distinta de las cuentas operativas, con acceso muy restringido y a ser posible con Object Lock
• Validación de integridad del log activada: CloudTrail firma los ficheros y genera un digest encadenado; puedes probar que nadie ha manipulado ni borrado registros
• Cifrado con SSE-KMS con una clave cuya política impida a los administradores de las cuentas operativas descifrar
• No confiar solo en la consola: la Event history de la consola solo guarda 90 días de eventos de gestión; el trail al bucket es el registro real

2. GuardDuty: detección gestionada

GuardDuty es un servicio que analiza de forma continua varias fuentes de telemetría de AWS, las cruza con inteligencia de amenazas y modelos de comportamiento, y emite hallazgos (findings) tipados. No hay que desplegar nada: se activa por cuenta y región, o para toda la organización desde una cuenta administradora.

2.1 Fuentes

• CloudTrail (eventos de gestión y, opcionalmente, de datos de S3): uso anómalo de credenciales, llamadas desde IP de Tor, reconocimiento, desactivación de defensas
• VPC Flow Logs: comunicación con IP o dominios maliciosos conocidos, minería de criptomonedas, exfiltración
• DNS logs (los del resolver de AWS): dominios de C2, algoritmos de generación de dominios, tunelización de datos por DNS
• Fuentes ampliadas de pago: EKS audit logs, Runtime Monitoring (agente en EC2/ECS/EKS), S3 Protection, RDS Protection, Lambda Protection, Malware Protection

2.2 Tipos de hallazgo habituales

Cada hallazgo trae una severidad (baja/media/alta), el recurso afectado, el actor y recomendaciones. GuardDuty no responde por ti: para eso se conecta a EventBridge y se dispara una Lambda, un runbook de Systems Manager o una notificación.

3. Security Hub: agregación y cumplimiento

Security Hub cumple dos funciones:

• Agregador: recoge los hallazgos de GuardDuty, Inspector (vulnerabilidades), Macie (datos sensibles), IAM Access Analyzer y de productos de terceros, todos normalizados al formato ASFF (AWS Security Finding Format), y los centraliza entre cuentas y regiones
• Cumplimiento continuo: ejecuta comprobaciones automáticas contra estándares y da una puntuación de seguridad (security score) por cuenta

Security Hub se apoya en AWS Config, que registra la configuración de cada recurso y su historial de cambios. Config por sí solo sirve para reglas de cumplimiento («ningún grupo de seguridad con 0.0.0.0/0 al puerto 22») con remediación automática, y para reconstruir «¿cómo estaba este recurso el martes?» durante una investigación.

4. Llevarlo a un SIEM

GuardDuty y Security Hub tienen consola propia, pero un SOC real necesita correlacionar los hallazgos de AWS con el resto de la telemetría (identidad, endpoints, aplicaciones). El patrón habitual:

• EventBridge captura los hallazgos de Security Hub (que ya incluye los de GuardDuty) y los envía a un destino: un stream de Kinesis Data Firehose hacia el SIEM, una función Lambda, o un bucket S3
• Los logs crudos (CloudTrail, VPC Flow, DNS) se centralizan en la cuenta de log y el SIEM los ingiere desde ahí
• Cuenta de seguridad dedicada: GuardDuty y Security Hub se administran de forma delegada desde una cuenta que no es la de gestión ni las operativas
• Solución de referencia de AWS para esto: SIEM on Amazon OpenSearch Service, o los conectores nativos de Splunk, Sentinel, Elastic y Wazuh

4.1 Mapear a MITRE ATT&CK for Cloud

ATT&CK tiene una matriz específica para IaaS. Ejemplos de correspondencia entre lo que ves en los logs de un laboratorio propio y la técnica:

5. Comandos de lectura para revisar el estado

# ¿Hay trails y cómo están configurados?
aws cloudtrail describe-trails --query 'trailList[].[Name,IsOrganizationTrail,IsMultiRegionTrail,LogFileValidationEnabled]'
aws cloudtrail get-trail-status --name mi-trail
 
# Buscar eventos concretos (Event history, ultimos 90 dias)
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=StopLogging \
  --start-time 2026-08-01T00:00:00Z
 
# Estado de GuardDuty y ultimos hallazgos por severidad
aws guardduty list-detectors
aws guardduty list-findings --detector-id <id> \
  --finding-criteria '{"Criterion":{"severity":{"Gte":7}}}'
 
# Hallazgos activos en Security Hub
aws securityhub get-findings \
  --filters '{"RecordState":[{"Value":"ACTIVE","Comparison":"EQUALS"}],"SeverityLabel":[{"Value":"CRITICAL","Comparison":"EQUALS"}]}'

Conclusión

La detección en AWS se construye de dentro hacia afuera: primero un CloudTrail de organización bien puesto —multirregión, en una cuenta de log aislada, con validación de integridad—, porque sin ese registro no hay investigación posible. Encima, GuardDuty aporta detección gestionada sin desplegar nada, y Security Hub agrega todo y añade la capa de cumplimiento continuo.

El salto de madurez es sacar los hallazgos de sus consolas y llevarlos, vía EventBridge, a un SIEM donde se correlacionen con el resto de la telemetría y se respondan con automatismos. Mapear cada detección a ATT&CK for Cloud ayuda a ver qué fases de un ataque cubres y cuáles no. Todo esto se puede montar y probar en una cuenta de laboratorio propia antes de llevarlo a producción.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)