Amazon SCS-C02: Detección de Amenazas y Alertas — Guía de estudio

By Laurynas Brazys · 24 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Forma parte de la AWS Security Specialty SCS-C02 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

Centralización de GuardDuty en toda una organización

Amazon GuardDuty es un servicio de detección continua de amenazas que analiza los eventos de gestión y de datos de CloudTrail, los VPC Flow Logs, los registros de consultas DNS, los registros de auditoría de EKS, la actividad de inicio de sesión de RDS y la telemetría en tiempo de ejecución. Produce hallazgos clasificados por propósito de la amenaza (Backdoor, CryptoCurrency, Recon, UnauthorizedAccess, PenTest, Policy, Stealth, Trojan, Impact) y por tipo de recurso (EC2, IAMUser, S3, Kubernetes, RDS, Lambda, Runtime).

Operar GuardDuty cuenta por cuenta no es escalable. La arquitectura correcta en un entorno de AWS Organizations es designar un administrador delegado —típicamente la cuenta dedicada de seguridad o auditoría— utilizando la cuenta de gestión de Organizations. Desde el administrador delegado, se habilita GuardDuty para toda la organización y se activa la habilitación automática para que las nuevas cuentas miembro y las nuevas regiones queden protegidas automáticamente a medida que se crean. Sin la habilitación automática, una cuenta recién aprovisionada permanece ciega hasta que un operador habilita manualmente la detección, que es exactamente la brecha que los atacantes explotan durante la incorporación.

Problema práctico: Escenario de caso de uso

Escenario: Meridian Financial opera un entorno de AWS multicuenta con 28 cuentas para producción, desarrollo y servicios compartidos. Su cuenta de gestión gobierna las cuentas a través de AWS Organizations, con registros centralizados de CloudTrail y S3, pero las alertas de seguridad y los datos de investigación están dispersos entre las cuentas miembro, lo que hace que la clasificación de incidentes sea lenta e inconsistente.

Desafío: Una detección reciente de movimiento lateral en una cuenta produjo hallazgos de GuardDuty que no fueron visibles para las herramientas centrales del SOC con la suficiente rapidez, retrasando la contención y la investigación forense.

Enfoque recomendado:

1. Designar un administrador delegado de GuardDuty en la cuenta de gestión y habilitar GuardDuty en toda la organización a través de AWS Organizations para que todas las cuentas miembro reenvíen los hallazgos a un detector central.
2. Activar AWS Security Hub de forma centralizada en la cuenta de gestión como el agregador y habilitar Security Hub para todas las cuentas y regiones para normalizar los hallazgos de GuardDuty junto con otros estándares de seguridad.
3. Configurar reglas de Amazon EventBridge en la cuenta de gestión para capturar los hallazgos de GuardDuty y Security Hub y enrutarlos a destinos centralizados como Amazon SNS para notificaciones, Amazon Kinesis Data Firehose a S3 para archivado, o entrega directa a tu SIEM.
4. Desplegar respondedores Lambda activados por EventBridge para acciones de contención automatizadas (por ejemplo, aislar una instancia EC2 a través de la API de EC2 y crear un incidente en AWS Systems Manager) y etiquetar los hallazgos para su investigación.
5. Integrar Amazon Detective para la investigación centralizada y reenviar los hallazgos archivados en S3 a tu sistema de análisis/SIEM para la correlación e informes a largo plazo.

Justificación: Usar un administrador delegado de GuardDuty con Security Hub y EventBridge centraliza la detección, normaliza las alertas y permite respuestas automatizadas y auditables según las mejores prácticas de AWS para la detección de amenazas en toda la organización y una respuesta a incidentes oportuna.

# From the Organizations management account
aws organizations enable-aws-service-access \
  --service-principal guardduty.amazonaws.com

aws guardduty enable-organization-admin-account \
  --admin-account-id 111122223333

# From the delegated admin
aws guardduty update-organization-configuration \
  --detector-id abc123 \
  --auto-enable-organization-members ALL \
  --features '[{"Name":"RDS_LOGIN_EVENTS","AutoEnable":"NEW"},
               {"Name":"EKS_AUDIT_LOGS","AutoEnable":"NEW"},
               {"Name":"RUNTIME_MONITORING","AutoEnable":"NEW"}]'

GuardDuty es regional, por lo que la relación de administrador delegado y la configuración de habilitación automática deben establecerse en cada región en la que operes. Esta es una fuente frecuente de puntos ciegos: un equipo habilita GuardDuty en us-east-1 y asume que tiene cobertura global.

Protecciones específicas del servicio

GuardDuty base cubre las fuentes de datos fundamentales, pero varios planes de protección deben habilitarse explícitamente porque añaden costos y una ingesta de telemetría adicional:

• Protección de RDS (RDS Protection): perfila la actividad de inicio de sesión en los motores Aurora MySQL/PostgreSQL y RDS, generando hallazgos como CredentialAccess:RDS/AnomalousBehavior.SuccessfulLogin cuando usuarios desconocidos se autentican en un punto de conexión de base de datos. Esta es la fuente correcta para detectar inicios de sesión sospechosos en la base de datos; no crees filtros de métricas de CloudWatch personalizados sobre los registros de auditoría de la base de datos cuando RDS Protection ya emite el hallazgo de forma nativa.

• Protección de EKS (EKS Protection): ingiere los registros de auditoría de Kubernetes para detectar accesos anómalos a la API, creación de pods con privilegios y uso de paneles de control expuestos.

• Monitoreo en tiempo de ejecución (Runtime Monitoring): despliega un agente ligero basado en eBPF en EC2, ECS/Fargate o EKS para revelar eventos de procesos, archivos y red, lo cual es necesario para detectar malware sin archivos o reverse shells en tiempo de ejecución.

• Protección contra malware (Malware Protection): escanea mediante instantáneas los volúmenes EBS adjuntos a instancias marcadas por otros hallazgos, o realiza escaneos bajo demanda de objetos S3 al subirse.

• Protección de Lambda (Lambda Protection) y Protección de S3 (S3 Protection): cubren los patrones de invocación de funciones y el acceso al plano de datos de S3, respectivamente.

Habilitar solo el servicio base y esperar que aparezcan anomalías de inicio de sesión en la base de datos es una configuración errónea común: los tipos de hallazgos simplemente no se producen hasta que se activa la característica correspondiente.

Security Hub como plano de agregación

Security Hub ingiere los hallazgos de GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, Config, Health y productos de ISV de terceros, normalizándolos al formato AWS Security Finding Format (ASFF). También ejecuta sus propios estándares de cumplimiento (AWS Foundational Security Best Practices, CIS, PCI DSS, NIST 800-53).

Para centralizar en toda una Organization:

• Habilite Security Hub como servicio en Organizations y designe un administrador delegado (generalmente la misma cuenta de seguridad que GuardDuty).

• Active la habilitación automática para cuentas nuevas para que los miembros se inscriban automáticamente.

• Configure una Región de agregación de hallazgos (también llamada Región de origen o home Region) y vincule todas las demás Regiones a ella. Sin la agregación entre Regiones, cada Región mantiene una instancia independiente de Security Hub y los analistas deben pivotar entre consolas.

Por lo tanto, el patrón para un despliegue organizacional global requiere dos configuraciones coordinadas: el enlace de la Región de agregación y el interruptor de habilitación automática para toda la organización. Habilitar una sin la otra deja a las cuentas nuevas sin cubrir o a las Regiones nuevas aisladas en silos.

Una limitación importante: Security Hub agrega y prioriza, pero no remedia. Tratarlo como una plataforma de remediación es un error de categoría; la remediación ocurre en una etapa posterior a través de EventBridge.

EventBridge como el tejido de automatización

Tanto GuardDuty como Security Hub publican hallazgos en el bus de eventos predeterminado. aws.guardduty emite eventos GuardDuty Finding, y aws.securityhub emite Security Hub Findings - Imported (creados/actualizados por Hub) y Security Hub Findings - Custom Action (desencadenados por un operador).

Reglas demasiado amplias como {"source": ["aws.securityhub"]} invocan destinos en cada actualización de hallazgo de cada proveedor, inundando rápidamente los temas de SNS y alertando a los ingenieros de guardia con ruido informativo. El enfoque correcto es filtrar por los valores de severity.Label, ProductArn, Types o Title específicos:

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "severity": [{ "numeric": [">=", 7] }],
    "type": [{ "prefix": "CredentialAccess:RDS/" }]
  }
}

Para un patrón centrado en Security Hub que solo se active con hallazgos de alta severidad de GuardDuty, ignorando los productos ruidosos de ISV de terceros:

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": { "Label": ["HIGH", "CRITICAL"] },
      "ProductArn": [
        { "wildcard": "arn:aws:securityhub:*::product/aws/guardduty" }
      ],
      "Workflow": { "Status": ["NEW"] }
    }
  }
}

Los destinos comunes incluyen un tema de SNS para notificaciones por correo electrónico/SMS/Slack, una función Lambda que aísla una instancia intercambiando su grupo de seguridad, un runbook de SSM Automation o una máquina de estados de Step Functions que orquesta una respuesta de varios pasos. Para el caso de uso de anomalía de inicio de sesión en Aurora, la ruta de mínimo esfuerzo es GuardDuty RDS Protection → regla de EventBridge filtrada por el tipo de hallazgo de RDS → tema de SNS con suscripción por correo electrónico. No se requiere sondeo personalizado, ni Lambda, ni un SIEM de terceros.

Acciones personalizadas de Security Hub

Las acciones personalizadas son desencadenantes impulsados por el operador. En la consola de Security Hub, un analista selecciona uno o más hallazgos y elige una acción personalizada (por ejemplo, «Poner EC2 en cuarentena»). Security Hub emite un evento Security Hub Findings - Custom Action que lleva los ARN de los hallazgos seleccionados; una regla de EventBridge coincide con el ARN de la acción personalizada e invoca una Lambda que realiza la respuesta. Esto le proporciona un botón con intervención humana sin necesidad de construir una interfaz de usuario a medida:

aws securityhub create-action-target \
  --name "Quarantine EC2" \
  --description "Attach isolation SG and snapshot volumes" \
  --id QuarantineEC2

El ARN resultante (arn:aws:securityhub:us-east-1:111122223333:action/custom/QuarantineEC2) se convierte en el valor de coincidencia en el campo resources de la regla de EventBridge.

Supresión y gestión de señales

La gestión del ruido es una disciplina, no un filtro de una sola vez. Utilice las reglas de automatización de Security Hub o las reglas de supresión de GuardDuty para autoarchivar hallazgos que se sabe que son benignos (por ejemplo, un hallazgo esperado de Recon:EC2/Portscan de una herramienta de pruebas de penetración). Filtre las reglas de EventBridge por ProductArn para silenciar una integración de terceros ruidosa sin deshabilitarla por completo. Combine Severity.Label con Workflow.Status = NEW para que los hallazgos reabiertos o ya notificados no vuelvan a generar una alerta. El objetivo es que cada alerta que llegue a un ser humano represente un evento procesable y de alta confianza; cualquier otra cosa erosiona la preparación para la respuesta.

Pivote de investigación

Cuando se dispara un hallazgo de alta severidad, por ejemplo, Backdoor:EC2/C&CActivity.B!DNS, la ruta de investigación más rápida no es escribir a mano consultas de Athena contra CloudTrail y Flow Logs. Amazon Detective, cuando se habilita junto con GuardDuty, preconstruye grafos de entidades a partir de los hallazgos de CloudTrail, VPC Flow Logs y GuardDuty. Pivotar desde el hallazgo directamente al rol de IAM o al perfil de instancia de EC2 en Detective expone la actividad de la API, los pares de red y los recuentos de conexiones exitosas frente a las fallidas durante la ventana de tiempo relevante, sin ningún trabajo de consulta personalizado.

← Gestión de Identidad y Acceso · Todos los dominios · Registros →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Amazon →