Amazon SCS-C02: Registros, Auditoría y Análisis Forense — 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.

Hallazgos y Remediación de Amazon GuardDuty

GuardDuty es un servicio gestionado de detección de amenazas que ingiere continuamente tres flujos de telemetría de forma interna: eventos de gestión de CloudTrail (y opcionalmente eventos de datos de S3), VPC Flow Logs y logs de consultas DNS de Route 53. No necesitas habilitar, entregar ni pagar por esas fuentes de logs por separado para que GuardDuty las consuma; el servicio lee un flujo duplicado directamente. Es por esto que GuardDuty puede activarse con una sola llamada a la API y comenzar a generar hallazgos en cuestión de minutos, sin ninguna ingeniería de pipelines de logs.

Los hallazgos tienen un valor de severidad entre 0.1 y 8.9, mapeado a Bajo (0.1–3.9), Medio (4.0–6.9) y Alto (7.0–8.9). Los hallazgos accionables típicos incluyen UnauthorizedAccess:EC2/SSHBruteForce, Backdoor:EC2/C&CActivity.B!DNS, CryptoCurrency:EC2/BitcoinTool.B y Recon:IAMUser/MaliciousIPCaller. Los patrones de remediación varían según el hallazgo: un compromiso basado en EC2 generalmente justifica aislar la instancia con un grupo de seguridad de cuarentena, crear snapshots de los volúmenes para análisis forense y terminarla; un hallazgo basado en IAM requiere rotar las claves de acceso y revisar la actividad reciente del principal en CloudTrail.

Para entornos multicuenta, habilita GuardDuty a través de AWS Organizations y designa una cuenta de administrador delegado (comúnmente la cuenta de Herramientas de Seguridad). El administrador delegado puede auto-habilitar GuardDuty en cada cuenta miembro existente y nueva en cada región donde el servicio esté activado. Sin la configuración de administrador delegado, los hallazgos de GuardDuty de cada cuenta permanecen aislados en cada miembro; habilitar los detectores individualmente no los agrega de forma centralizada.

AWS Security Hub y Agregación entre Cuentas

Security Hub es la capa de normalización y agregación. Ingiere hallazgos de GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, Config y docenas de productos de socios, convirtiéndolos al formato AWS Security Finding Format (ASFF). También ejecuta sus propios controles contra estándares como CIS AWS Foundations, AWS Foundational Security Best Practices, PCI DSS y NIST 800-53.

La agregación entre cuentas y entre regiones funciona de la misma manera que en GuardDuty: registra Security Hub con el administrador delegado de Organizations, luego designa una región de agregación para que los hallazgos de otras regiones se repliquen en ese panel único. Un error común es habilitar Security Hub en cada cuenta y esperar una vista consolidada; sin el administrador delegado más la región de agregación, cada cuenta sigue viendo solo sus propios hallazgos.

Security Hub no envía correos electrónicos por sí mismo. Las notificaciones y automatizaciones se construyen haciendo coincidir los eventos de hallazgos de Security Hub en el bus de eventos predeterminado de EventBridge y reenviándolos a SNS, Lambda, Step Functions o documentos de Systems Manager Automation.

CloudTrail: Eventos de Gestión vs. Eventos de Datos

CloudTrail registra dos categorías de actividad, y confundirlas es la brecha más común en la cobertura de detección.

Eventos de gestión: operaciones del plano de control — RunInstances, CreateBucket, AttachRolePolicy, PutBucketAcl. Habilitados por defecto en cualquier trail nuevo.
Eventos de datos: operaciones de alto volumen a nivel de recurso — llamadas a nivel de objeto de S3 (GetObject, PutObject, DeleteObject, PutObjectAcl), la Invoke de Lambda, llamadas a la API a nivel de ítem de DynamoDB. Deshabilitados por defecto y facturados por separado.

Si un requisito de seguridad es “detectar cuándo alguien hace público un objeto de S3 mediante PutObjectAcl”, un trail de solo eventos de gestión no lo capturará porque los cambios de ACL en objetos individuales son eventos de datos. De manera similar, la salida de datos (GetObject) desde un bucket sensible es invisible sin los eventos de datos. PutBucketAcl (a nivel de bucket) es un evento de gestión y se registraría; PutObjectAcl (a nivel de objeto) no lo es.

Usa un trail de organización creado en la cuenta de gestión o en la del administrador delegado para que los eventos de cada cuenta miembro se capturen en un único bucket de S3 y no pueda ser deshabilitado por los principales de las cuentas miembro. Protege el trail con:

Cifrado SSE-KMS en el bucket de destino, con una política de clave de KMS que deniegue el descifrado no autorizado.
Una política de bucket que deniegue s3:PutObject sin el principal de servicio de CloudTrail y que deniegue la eliminación.
Validación de la integridad de los archivos de log habilitada, que produce archivos de resumen (digest) cada hora firmados con SHA-256 para que se pueda demostrar cualquier manipulación.

Ejemplo de creación:

aws cloudtrail create-trail \
  --name org-trail \
  --s3-bucket-name central-ct-logs \
  --is-organization-trail \
  --is-multi-region-trail \
  --enable-log-file-validation \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...

aws cloudtrail put-event-selectors \
  --trail-name org-trail \
  --event-selectors '[{"ReadWriteType":"All","IncludeManagementEvents":true,
                       "DataResources":[{"Type":"AWS::S3::Object",
                                         "Values":["arn:aws:s3:::sensitive-bucket/"]}]}]'

Alertas con EventBridge y SNS

EventBridge es el tejido de enrutamiento que conecta los hallazgos con respondedores humanos y automatizados. Cada hallazgo de GuardDuty, cada actualización de hallazgo de Security Hub y cada evento derivado de CloudTrail llega al bus de eventos predeterminado. Las reglas usan patrones de eventos JSON para filtrar y luego se distribuyen a uno o más destinos (targets) (SNS, Lambda, SQS, Kinesis Data Firehose, Step Functions, Systems Manager).

Un patrón canónico para hallazgos de alta severidad de GuardDuty, reenviados tanto a un tema de SNS para correo electrónico como a un stream de entrega de Firehose que alimenta OpenSearch para análisis:

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

Para hallazgos CRÍTICOS de Security Hub enrutados a correo electrónico:

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": { "Label": ["CRITICAL"] },
      "Workflow": { "Status": ["NEW"] }
    }
  }
}

El punto final (endpoint) de correo electrónico es una simple suscripción a SNS; el suscriptor debe confirmar a través del enlace enviado por correo electrónico antes de que comience la entrega. Una sola regla puede tener hasta cinco destinos (targets), por lo que las alertas y los análisis posteriores no requieren reglas duplicadas.

Al crear patrones, recuerda que los eventos de gestión de CloudTrail llegan con "detail-type": "AWS API Call via CloudTrail", mientras que los eventos de datos no aparecen en el bus predeterminado a menos que configures un trail que publique en CloudWatch Logs y uses un filtro de métricas o te suscribas a través de la integración de eventos de datos de CloudTrail de EventBridge. Escribir una regla de EventBridge que coincida con "eventName": "PutObjectAcl" en el bus predeterminado sin habilitar los eventos de datos no producirá ninguna coincidencia.

Logs, Insights, filtros de métricas y alarmas de CloudWatch

Enviar los registros de CloudTrail (y los VPC Flow Logs, y los registros de aplicaciones) a CloudWatch Logs permite la detección casi en tiempo real. Los filtros de métricas escanean cada evento de registro entrante en busca de un patrón e incrementan una métrica personalizada de CloudWatch; una alarma de CloudWatch sobre esa métrica activa SNS.

Ejemplo: alarma por fallos repetidos de inicio de sesión en la consola.

aws logs put-metric-filter \
  --log-group-name /aws/cloudtrail/org \
  --filter-name ConsoleSignInFailures \
  --filter-pattern '{ ($.eventName = "ConsoleLogin") && ($.errorMessage = "Failed authentication") }' \
  --metric-transformations metricName=ConsoleLoginFailures,metricNamespace=Security,metricValue=1

CloudWatch Logs Insights proporciona consultas ad-hoc utilizando un lenguaje de consulta especialmente diseñado, útil para la respuesta a incidentes después de que se dispara una alarma:

fields @timestamp, userIdentity.arn, sourceIPAddress, eventName

Trampas comunes

Falta de actividad a nivel de objeto de S3: PutObjectAcl, GetObject y DeleteObject son eventos de datos. Un trail por defecto captura solo eventos de gestión; debes añadir selectores de eventos de datos, o el hallazgo, la alarma o la regla de EventBridge que apunten a esos nombres de API nunca se activarán silenciosamente.
Visibilidad central sin administrador delegado: habilitar GuardDuty o Security Hub en cada cuenta no agrega los resultados. Los hallazgos se agrupan de forma centralizada solo después de registrar un administrador delegado en AWS Organizations y, para Security Hub, elegir una Región de agregación. Las invitaciones entre cuentas funcionan para entornos pequeños pero no escalan y requieren aceptación por cada cuenta.
Confusión entre gestión y datos en los filtros: PutBucketAcl (bucket) es un evento de gestión y funciona en cualquier filtro de métrica o de EventBridge estándar; PutObjectAcl (objeto) no lo hace, por muy bien elaborado que esté el patrón, a menos que los eventos de datos estén habilitados y se entreguen al mismo pipeline.

Problema práctico: escenario de caso de uso

Escenario: Meridian Financial opera una AWS Organization multicuenta con una cuenta de seguridad dedicada y una cuenta de registro centralizada. Su entorno incluye PII de clientes en S3, APIs transaccionales en EC2/Lambda, y CloudTrail ya escribe eventos de gestión en un bucket de S3 central; los equipos quieren una detección más rápida y una respuesta coordinada entre cuentas.

Desafío: Los ingenieros de seguridad detectaron un pico repentino en las solicitudes GET de S3 y hallazgos de GuardDuty relacionados que sugerían una posible exfiltración de datos, pero las alertas son ruidosas y carecen de contexto correlacionado de CloudTrail y de contención automatizada entre cuentas.

Enfoque recomendado:

Habilitar Amazon GuardDuty en cada cuenta miembro y designar la cuenta de seguridad como el administrador delegado de GuardDuty; habilitar la protección de eventos de datos de S3 para que los hallazgos incluyan anomalías de acceso a nivel de objeto.
Configurar CloudTrail por cuenta para entregar eventos de gestión al S3 central para su retención y para reenviar eventos de datos seleccionados de alto valor (S3 GetObject/PutObject/DeleteObject y Lambda Invoke) a CloudWatch Logs en la cuenta de seguridad para una inspección de baja latencia.
Activar AWS Security Hub en la cuenta de seguridad y habilitar la agregación entre cuentas con las cuentas miembro para que los hallazgos de GuardDuty, los hallazgos derivados de CloudTrail y los resultados de Config/Inspector se centralicen y normalicen.
Crear reglas de EventBridge que coincidan con hallazgos de alta gravedad de GuardDuty y Security Hub y los dirijan a SNS para notificaciones por buscapersonas y a una Lambda de remediación que utilice el contexto de CloudTrail para tomar acciones de contención (revocar claves de API, eliminar sesiones de IAM, aislar ENI de EC2).
Añadir filtros de métricas de CloudWatch Logs para tasas anormales de s3:GetObject acotadas por principal de IAM y una alarma que active el mismo pipeline de EventBridge/SNS/Lambda; usar consultas de CloudWatch Logs Insights en la cuenta de seguridad para enriquecer las alertas con eventos de CloudTrail correlacionados para el triaje de incidentes.

Justificación: Centralizar los hallazgos (GuardDuty + Security Hub) y enviar eventos de datos de CloudTrail específicos a CloudWatch permite la correlación de baja latencia, las alertas y la contención automatizada a través de EventBridge/SNS/Lambda, lo que se alinea con las mejores prácticas de AWS para la detección, la agregación entre cuentas y la respuesta automatizada.

CloudTrail centralizado e integridad de los registros

CloudTrail es el registro autoritativo de la actividad de la API de AWS, y la base de cualquier arquitectura de auditoría es un único trail multirregional que entrega los registros a un bucket de S3 centralizado, idealmente en una cuenta dedicada al archivo de registros dentro de AWS Organizations. Un trail multirregional captura automáticamente los eventos de gestión en cada Región actual y en cualquier Región que AWS lance en el futuro; un trail de una sola región crea puntos ciegos en el momento en que una carga de trabajo se inicia en otro lugar, lo que es el clásico fallo de completitud durante las auditorías. Cuando se aplica a nivel de organización, el trail también captura los eventos de cada cuenta miembro, por lo que una nueva cuenta que se une a la organización queda cubierta sin ninguna configuración por cuenta.

Habilita la validación de archivos de registro en el trail. CloudTrail entregará entonces un archivo de resumen (digest) firmado cada hora al mismo bucket de S3, que contiene los hashes SHA-256 de los archivos de registro entregados. El comando aws cloudtrail validate-logs recorre la cadena de resúmenes y detecta manipulaciones, eliminaciones o vacíos. Sin la validación, un defensor no puede probar que los registros no fueron alterados después del incidente, lo que los invalida como evidencia forense.

aws cloudtrail create-trail \
  --name org-trail \
  --s3-bucket-name corp-audit-logs \
  --is-multi-region-trail \
  --is-organization-trail \
  --enable-log-file-validation \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...
aws cloudtrail start-logging --name org-trail

Los fallos de entrega son casi siempre problemas de permisos posteriores (downstream), no errores de CloudTrail. El bucket de S3 debe existir antes de que se cree el trail, su política de bucket debe conceder s3:PutObject a cloudtrail.amazonaws.com con una condición aws:SourceArn que coincida con el trail, y el propietario del objeto debe ser el propietario del bucket (bucket-owner-full-control). Si el trail utiliza SSE-KMS, la política de la CMK debe permitir kms:GenerateDataKey* para el principal de servicio de CloudTrail, y cada consumidor (Athena, ingenieros de seguridad, analizadores de Lambda) debe tener kms:Decrypt sobre esa clave. Un modo de fallo común: los registros se entregan correctamente, pero las consultas de Athena devuelven “AccessDenied” porque el rol de la consulta carece del permiso Decrypt sobre la CMK de cifrado de registros. Soluciónalo en la política de la clave, no deshabilitando el cifrado.

CloudWatch Logs, Filtros de Métricas y Alarmas en Tiempo Real

CloudTrail entrega los registros a S3 en lotes cada 5 a 15 minutos, lo cual es adecuado para auditorías retrospectivas pero demasiado lento para la detección en tiempo real. Para generar alarmas sobre eventos sensibles, transmite el trail a CloudWatch Logs (una opción del trail) o enruta eventos específicos a través de EventBridge. El enfoque con CloudWatch Logs utiliza filtros de métricas (metric filters) que buscan patrones en los eventos JSON e incrementan una métrica de CloudWatch, la cual a su vez activa una Alarma de CloudWatch y una notificación de SNS. El ejemplo canónico es el inicio de sesión en la consola con el usuario raíz:

{ $.eventName = "ConsoleLogin" && $.userIdentity.type = "Root" }

EventBridge suele ser mejor para eventos específicos y bien conocidos (desactivación de una clave KMS, cambios en políticas de IAM) porque sus reglas pueden activar Lambda o Step Functions directamente sin ningún costo de Logs. Usa los filtros de métricas cuando necesites recuentos agregados o visualización en dashboards.

La retención en CloudWatch Logs tiene por defecto el valor Nunca Expirar (Never Expire), lo cual es costoso y rara vez es lo correcto. Establece una retención explícita por cada grupo de logs (aws logs put-retention-policy) alineada con el régimen de cumplimiento; comúnmente 90 días de datos calientes (hot) en CloudWatch con un archivo a largo plazo en S3 a través de un filtro de suscripción o Kinesis Data Firehose.

Para la higiene de datos sensibles, aplica políticas de protección de datos de CloudWatch Logs (data protection policies) a nivel de cuenta. Estas utilizan identificadores de datos gestionados (números de tarjetas de crédito, claves secretas de AWS, SSNs) para enmascarar las cadenas de texto coincidentes durante la ingesta. Es crucial que para desenmascarar se requiera el permiso logs:Unmask; otórgalo únicamente a un rol de tipo break-glass (acceso de emergencia). Los usuarios que pueden leer el grupo de logs pero carecen del permiso Unmask solo ven asteriscos. Una política a nivel de cuenta se aplica a todos los grupos de logs actuales y futuros, lo cual es el control correcto; las políticas por grupo tienden a desactualizarse a medida que nuevos servicios crean nuevos grupos.

Consultas de Logs a Escala: Insights y Athena

Dos motores de consulta abordan diferentes niveles de datos.

CloudWatch Logs Insights consulta datos que ya están en CloudWatch Logs utilizando un lenguaje de consulta diseñado específicamente para ello. Ideal para datos operativos recientes (logs de Lambda, VPC Flow Logs en Logs, logs de aplicaciones). Rápido, sin necesidad de configurar un esquema, pero limitado por la retención de CloudWatch y el costo por GB escaneado.
Amazon Athena ejecuta SQL de Presto/Trino sobre datos en S3. Ideal para consultas forenses a gran escala sobre logs de CloudTrail, logs de acceso de ALB, VPC Flow Logs almacenados en S3 y logs de CloudFront. Cuesta $5 por TB escaneado; utiliza proyección de particiones (partition projection) o particiones de Glue por fecha/región para reducir drásticamente el costo del escaneo.

Un caso de uso forense típico: identificar quién desactivó una clave KMS. Debido a que el JSON de CloudTrail está anidado, la tabla de Athena creada por CloudTrail expone userIdentity como una estructura (struct):

SELECT eventTime,
       userIdentity.arn                                         AS principal,
       userIdentity.sessionContext.sessionIssuer.arn            AS assumed_role,
       userIdentity.sessionContext.attributes.mfaAuthenticated  AS mfa,
       sourceIPAddress,
       requestParameters
FROM   cloudtrail_logs
WHERE  eventName = 'DisableKey'
  AND  eventTime BETWEEN '2024-05-01T03:00:00Z' AND '2024-05-01T03:30:00Z';

Para el análisis de bots en un ALB, habilita los logs de acceso del ALB a S3, define una tabla de Athena sobre el prefijo de los logs, luego haz un join con una tabla de IPs maliciosas conocidas y visualiza la agregación en QuickSight. QuickSight lee desde Athena, por lo que el pipeline es: ALB → S3 → Athena → QuickSight. Enviar los logs de ALB a CloudWatch Logs Insights no es una ruta nativa soportada; los logs de ALB solo se envían a S3.

Los VPC Flow Logs pueden ir a cualquiera de los dos destinos: elige Logs para investigaciones tácticas del tipo filter dstPort=3389 and action="REJECT", y S3 (en formato Parquet y particionado) para consultas de tendencias a escala de meses.

Recopilación de Evidencia con Audit Manager

AWS Audit Manager automatiza la recopilación continua de evidencia mapeada a marcos de trabajo (frameworks) como PCI DSS, HIPAA, SOC 2 y CIS. Extrae evidencia de las reglas de Config, los hallazgos de Security Hub, los eventos de CloudTrail y el inventario de recursos, y la empaqueta en evaluaciones de control. Cuando se habilita en la cuenta de gestión de Organizations o en una cuenta de administrador delegado, recopila evidencia de todas las cuentas miembro, produciendo un informe de evaluación (un paquete comprimido de evidencia con un manifiesto) que los auditores aceptan en lugar de capturas de pantalla manuales. Esta es la respuesta correcta siempre que un escenario pregunte por evidencia continua, multicuenta y alineada a un marco de trabajo: Config por sí solo te da el cumplimiento de los recursos pero no el mapeo al marco; Security Hub te da hallazgos pero no el empaquetado de la evaluación; un informe casero con Athena no es continuo.

Resumen de Errores Comunes

Culpar a CloudTrail por la falta de logs suele ser incorrecto: el bucket puede no existir, la política del bucket puede rechazar al principal de CloudTrail o la propiedad de objetos puede estar mal configurada. Revisa S3 primero.
Un trail de una sola región parece más barato, pero produce un historial de auditoría incompleto; la opción multirregión es la respuesta correcta por defecto para una cobertura a nivel de toda la organización.
Los logs cifrados con SSE-KMS son invisibles para Athena, los analizadores de Lambda o los ingenieros, a menos que la política de la CMK otorgue kms:Decrypt a esos principales; deshabilitar el cifrado no es la solución, corregir la política de la clave sí lo es.

Problema Práctico: Escenario de Caso de Uso

Escenario: Meridian Financial opera una AWS Organization con múltiples cuentas que incluyen producción, staging y una cuenta dedicada para logs. Su entorno aloja APIs de cara al cliente, análisis y secretos administrados por IAM, y necesitan un registro de logs centralizado y a prueba de manipulaciones, además de herramientas de investigación rápidas para dar soporte a la respuesta a incidentes y a las solicitudes de cumplimiento.

Desafío: Una secuencia sospechosa reciente de inicios de sesión en la consola y cambios en políticas de IAM pasó desapercibida durante horas, y existe la preocupación de que la integridad de los logs y las alertas oportunas sean inadecuadas para la reconstrucción forense y la recopilación de evidencias para Audit Manager.

Enfoque Recomendado:

Habilitar un AWS Organizations CloudTrail (trail de organización) en todas las regiones, activar la validación de integridad de archivos de log de CloudTrail, entregar los logs y los archivos de resumen (digest files) a un bucket de S3 centralizado y cifrado con una KMS CMK cuya política de clave restrinja el descifrado a un pequeño equipo de seguridad, y habilitar el registro de acceso (access logging) y el versionado en S3.
Configurar CloudTrail para transmitir eventos de gestión y eventos de datos seleccionados a CloudWatch Logs, luego crear filtros de métricas (metric filters) en CloudWatch Logs para patrones de alto riesgo (fallos de inicio de sesión en la consola desde nuevas IPs, CreateUser, PutRolePolicy) y asociar CloudWatch Alarms a temas de SNS para notificaciones (paging) y un playbook automatizado de Lambda.
Desplegar paneles de control (dashboards) de CloudWatch Logs Insights para la investigación interactiva de eventos recientes y establecer reglas de retención y ciclo de vida en la cuenta de logs para conservar las evidencias según la política.
Catalogar los objetos de CloudTrail en S3 con AWS Glue y ejecutar consultas de Athena (particionadas por región/fecha/servicio) para análisis retrospectivos a gran escala y para producir exportaciones de evidencias en formato CSV para los investigadores.
Crear una evaluación de AWS Audit Manager que recopile automáticamente evidencias de CloudTrail, AWS Config e IAM en una carpeta de evidencias y programe exportaciones periódicas para los revisores de cumplimiento.

Justificación: Centralizar y validar CloudTrail, transmitir a CloudWatch para filtros de métricas y alarmas en tiempo real, y usar Athena/Logs Insights para consultas escalables sigue las mejores prácticas de AWS para la detección, el registro inmutable y la preparación forense, mientras que Audit Manager automatiza la recopilación de evidencias para las auditorías.

← Detección de Amenazas y Alertas · Todos los dominios · Cifrado →

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

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

Aprueba tu examen →

Explorar Amazon →