Detección de Amenazas y Operaciones Integradas con GuardDuty, Security Hub y Detective en AWS
_Category: Threat Detection_
En el examen SCS-C03, la clave del dominio de detección de amenazas es comprender cómo trabajan juntos estos tres servicios. GuardDuty es el sistema de alarma de intrusiones que opera las 24 horas, los 7 días de la semana; Security Hub es el panel de control del centro de operaciones de seguridad; y Detective es la herramienta de investigación que rastrea grabaciones de cámaras y registros de acceso. Cada uno destaca en lo suyo, y el examen pregunta exactamente sobre esas diferencias.
---
El flujo de detección de amenazas: Recolección → Detección → Priorización → Investigación → Respuesta
Entender la detección de amenazas como un flujo de cinco etapas deja muy claro el rol de cada servicio.
La primera etapa es la recolección de datos. Los logs de origen incluyen CloudTrail, VPC Flow Logs, DNS Logs, registros de llamadas a la API de S3, EKS Audit Logs y tráfico de red de Lambda, entre otros. GuardDuty consume estos datos; no es un servicio que requiera almacenar logs por separado. Tampoco necesita la instalación de ningún agente.
La segunda etapa es la detección. GuardDuty utiliza machine learning e inteligencia de amenazas para identificar comportamientos anómalos y generar Findings.
La tercera etapa es la priorización. Los Findings de GuardDuty se clasifican por severidad (Low, Medium, High) y se envían a Security Hub. Security Hub normaliza y agrega Findings de múltiples servicios —no solo GuardDuty, sino también Macie, Inspector, Firewall Manager e IAM Access Analyzer— en el formato ASFF (Amazon Security Finding Format).
La cuarta etapa es la investigación. Desde un Finding en Security Hub es posible saltar directamente a Amazon Detective para un análisis en profundidad. Detective usa una base de datos en grafo para visualizar las relaciones entre entidades, lo que permite rastrear desde cuándo una determinada IP accedió a una cuenta.
La quinta etapa es la respuesta. Los Findings de GuardDuty se publican automáticamente en EventBridge, lo que permite disparar Lambda, SNS, Step Functions y otros servicios. Las Automation Rules de Security Hub permiten automatizar respuestas ante patrones específicos de Findings.
---
Amazon GuardDuty: Cómo funciona la detección automática de amenazas y sus fuentes de datos
GuardDuty es un servicio gestionado de detección de amenazas que supervisa automáticamente comportamientos anómalos en entornos AWS las 24 horas del día. Basta con activar GuardDuty —sin necesidad de instalar agentes ni construir pipelines de envío de logs— para que comience la detección.
Las fuentes de datos de GuardDuty se organizan por funcionalidades:
| Fuente de datos / Funcionalidad | Qué detecta | ¿Activada por defecto? | |---|---|---| | Eventos de gestión de CloudTrail | Uso anómalo de credenciales IAM, accesos a la consola inusuales | Incluida por defecto | | VPC Flow Logs | Escaneos de puertos, conexiones salientes anómalas, comunicaciones C2 | Incluida por defecto | | DNS Logs | Tunneling DNS, consultas a dominios maliciosos conocidos | Incluida por defecto (solo vía Route 53 Resolver) | | S3 Protection | Acceso anómalo a buckets S3, eliminaciones o descargas masivas | Activación separada | | EKS Audit Logs | Uso anómalo de permisos en contenedores, patrones extraños de kubectl | Activación separada | | Malware Protection | Escaneo de malware en EC2/ECS (análisis de volúmenes EBS) | Activación separada | | RDS Login Events | Patrones de inicio de sesión anómalos en bases de datos Aurora | Activación separada | | Lambda Network Activity | Comunicaciones de red anómalas desde funciones Lambda | Activación separada |
La detección DNS de GuardDuty solo analiza las consultas que pasan por el Route 53 Resolver dentro de la VPC. Si una instancia EC2 usa un servidor DNS personalizado —externo o un forwarder on-premises— esas consultas quedan fuera del alcance de GuardDuty. Activar los query logs de Route 53 Resolver por separado no implica que GuardDuty comparta esos datos.
En entornos multi-cuenta, es posible integrar GuardDuty con AWS Organizations y gestionarlo de forma centralizada desde una cuenta Delegated Administrator para toda la organización.
---
Categorías de Findings en GuardDuty y escenarios frecuentes en el examen
Los Findings de GuardDuty se clasifican según un sistema de prefijos que describe la naturaleza de la amenaza detectada.
Reconnaissance detecta comportamientos de exploración del entorno por parte de un atacante; un ejemplo representativo es Recon:EC2/PortProbeUnprotectedPort. UnauthorizedAccess detecta el uso anómalo de credenciales e incluye casos como UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B, que indica un inicio de sesión exitoso a la consola desde una ubicación inusual. CryptoCurrency detecta actividad de minería de criptomonedas (CryptoCurrency:EC2/BitcoinTool.B), mientras que Backdoor detecta comunicaciones C2 (Backdoor:EC2/C&CActivity.B). Behavior cubre patrones de comportamiento anómalos en credenciales IAM, y Pentest se genera cuando se detecta el uso de herramientas de pruebas de penetración.
En cuanto a cómo gestionar los falsos positivos, hay un concepto que aparece con frecuencia en el examen. La Trusted IP List suprime todos los Findings provenientes de una IP específica. Las Suppression Rules combinan tipo de Finding, condición de IP, etiquetas de recurso y otros criterios para archivar de forma selectiva solo aquellos Findings que cumplan una condición concreta. Los Findings archivados se ocultan en la consola, pero se conservan durante 90 días.
Si el escenario plantea que el Finding InstanceCredentialExfiltration se genera repetidamente debido a tráfico legítimo que pasa por un NAT gateway on-premises, la respuesta correcta es una Suppression Rule. Usar la Trusted IP List también suprimiría amenazas reales provenientes de esa IP.
---
AWS Security Hub: Integración de Findings y Security Standards
Security Hub es el servicio que agrega Findings de múltiples servicios de seguridad de AWS y herramientas de terceros en un único lugar, evaluando de forma continua el estado de conformidad con distintos estándares de seguridad.
ASFF (Amazon Security Finding Format) es el formato estándar que normaliza todos los Findings en el mismo esquema JSON. Sin importar si el origen es GuardDuty, Macie o Inspector, todos se convierten al formato ASFF, lo que permite búsquedas y filtros unificados.
| Security Standard | Enfoque | Uso principal | |---|---|---| | AWS Foundational Security Best Practices (FSBP) | Mejores prácticas de seguridad a nivel de servicio AWS | Línea base de seguridad general en AWS | | CIS AWS Foundations Benchmark | Recomendaciones del CIS (Center for Internet Security) | Endurecimiento según estándares del sector | | PCI DSS | Estándar de seguridad de la industria de tarjetas de pago | Entornos de procesamiento de pagos con tarjeta | | NIST SP 800-53 | Seguridad de sistemas de información federales de EE. UU. | Organismos públicos y entornos con cumplimiento reforzado |
Insights es una funcionalidad que agrupa en colecciones los Findings que comparten un patrón común. Las Automation Rules modifican automáticamente atributos de los Findings o disparan acciones cuando se reciben en Security Hub bajo ciertas condiciones. Al designar un Delegated Administrator mediante la integración con Organizations, Security Hub se activa automáticamente en las nuevas cuentas de la organización y los Findings de las cuentas miembro se agregan de forma centralizada.
---
Amazon Detective: Investigación profunda basada en grafos
Cuando se recibe un Finding de GuardDuty o Security Hub, Detective sirve para determinar qué tan grave es realmente ese hallazgo y si existen otros comportamientos anómalos relacionados. Al igual que un investigador que analiza grabaciones de cámaras de seguridad y registros de acceso en la escena de un crimen, Detective usa una base de datos en grafo para visualizar las relaciones entre entidades y los patrones de comportamiento.
Detective analiza datos de CloudTrail, VPC Flow Logs y GuardDuty Findings. Al confirmar un Finding en GuardDuty o Security Hub y hacer clic en el botón Investigate in Detective, se accede a la consola de Detective. Allí, Detective muestra una línea de tiempo de las IPs, cuentas y llamadas a la API relacionadas con ese Finding, y compara la actividad actual con el patrón de comportamiento de referencia (baseline) para visualizar qué tan anómala es la situación.
Detective requiere que GuardDuty esté activo como condición previa; es una herramienta de investigación manual, por lo que no es adecuada para automatizaciones con EventBridge ni para alertas en tiempo real. La regla es simple: si se quieren consolidar Findings de varios servicios en un solo lugar, se usa Security Hub; si se quiere analizar en profundidad un Finding específico, se usa Detective.
---
Tabla comparativa de los tres servicios y respuesta automatizada con EventBridge
A continuación se comparan los roles de los tres servicios de un vistazo.
| Aspecto | GuardDuty | Security Hub | Detective | |---|---|---|---| | Rol principal | Detección automática de amenazas | Integración de Findings y evaluación de conformidad | Investigación profunda y análisis de causa raíz | | Analogía | Sistema de alarma de intrusiones 24/7 | Panel de control del SOC | Herramienta de investigación / CCTV | | Entrada | CloudTrail, VPC Flow Logs, DNS, S3, EKS, etc. | GuardDuty, Macie, Inspector, terceros, etc. | GuardDuty Findings, CloudTrail, VPC Flow Logs | | Salida | Findings (resultados de detección) | Findings integrados, puntuación de conformidad | Visualización en grafo, análisis de línea de tiempo | | Automatización | Publicación de eventos en EventBridge | Automation Rules, integración con EventBridge | Investigación manual (sin automatización) | | Dependencia de GuardD