Automatización de Respuesta a Incidentes con SSM Automation, EventBridge y Aislamiento Automático — Guía Completa SCS-C03
_Category: Incident Response_
Los incidentes de seguridad no avisan. Cuando llega una alerta de GuardDuty, puede que el responsable esté fuera de la oficina o sean las tres de la madrugada. En la seguridad cloud moderna, la automatización no es opcional: es el primer respondedor. Antes de que cualquier persona humana pueda reaccionar, el aislamiento ya debe estar completo, la evidencia preservada y el equipo notificado. Desde la detección hasta el aislamiento, la recopilación forense y la recuperación, esta guía recorre el flujo completo de automatización de respuesta a incidentes en AWS con foco en los escenarios del examen SCS-C03.
---
La Mentalidad de Respuesta a Incidentes en la Nube
En entornos on-premises, la respuesta a incidentes de seguridad giraba en torno al acceso físico y al trabajo manual. Conectarse directamente al servidor, examinar logs a mano y desenchufar cables de red podía llevar horas. En AWS, tres cosas cambian de forma radical.
Primero, la infraestructura es código. Aislar una instancia EC2, tomar un EBS Snapshot o lanzar una nueva instancia son operaciones de una sola llamada a la API. Lambda puede ejecutarlas en cuestión de segundos sin intervención humana. Segundo, todo es un evento. Amenazas de GuardDuty, ACL públicas en S3, uso anómalo de claves IAM — todo fluye hacia EventBridge. Este servicio actúa como la campana de alarma que suena en el instante exacto en que ocurre el incidente. Tercero, la infraestructura es inmutable. Una instancia comprometida no se repara: se aísla, se toma su snapshot como evidencia y se reemplaza por una nueva limpia. Es el equivalente digital de llevar a un paciente infectado a cuarentena antes de tratar la sala.
Esta mentalidad cambia por completo la forma de diseñar procesos de respuesta a incidentes. La pregunta ya no es «¿quién va a corregir esto?», sino «¿cuánto tarda el sistema en corregirse solo?».
---
Ciclo de Vida IR según NIST y Mapeo a Servicios AWS
NIST SP 800-61 define el ciclo de vida de respuesta a incidentes en siete fases. AWS ha mapeado servicios concretos a cada fase. El examen SCS-C03 formula preguntas del tipo «¿qué servicio es más adecuado para esta fase?», por lo que dominar esta tabla es fundamental.
| Fase IR | Objetivo | Servicios AWS Clave | |---------|----------|--------------------| | Prepare (Preparación) | Configurar herramientas, permisos y Runbooks con antelación | Systems Manager Incident Manager, IAM Role, SSM Automation Runbook | | Detect (Detección) | Identificar amenazas y generar alertas | GuardDuty, Security Hub, Macie, CloudTrail, Config | | Analyze (Análisis) | Determinar alcance e investigar causa raíz | Detective, CloudTrail, CloudWatch Logs Insights, Athena | | Contain (Contención) | Evitar propagación adicional | Quarantine SG, VPC Isolation, IAM Policy Revoke, EventBridge + Lambda | | Eradicate (Erradicación) | Eliminar elementos maliciosos | SSM Automation, Systems Manager Run Command, Lambda | | Recover (Recuperación) | Restaurar servicio normal | AWS Backup, AMI, CloudFormation StackSet | | Lessons Learned (Lecciones aprendidas) | Prevenir recurrencia | Security Hub Findings review, refuerzo de Config Rules, actualización de Runbooks |
Esta tabla es el esqueleto de las preguntas del examen. Los patrones se repiten: «determinar alcance del compromiso» apunta a Detective; «aislamiento inmediato» apunta a Quarantine SG + Lambda; «automatizar recuperación» apunta a AWS Backup o CloudFormation. La fase Prepare es la más importante de todas: sin un Runbook previo, alguien tiene que tomar decisiones en tiempo real bajo presión, y eso cuesta tiempo. Un SSM Automation Runbook bien escrito transforma minutos de análisis en segundos de ejecución automática.
---
Detección y Disparo: GuardDuty, Security Hub y EventBridge
El punto de partida de toda automatización es la detección. Amenazas de GuardDuty, findings de Security Hub, llamadas anómalas a la API registradas en CloudTrail — todos estos eventos fluyen hacia EventBridge. Este servicio los filtra y los enruta hacia Lambda, SSM Automation, Step Functions, SNS u otros destinos según las reglas configuradas.
El flujo típico es: GuardDuty Finding → EventBridge Rule (filtro por tipo y severidad) → Lambda (lógica de aislamiento) → aplicar Quarantine SG + tomar EBS Snapshot + enviar notificación SNS.
Al configurar una EventBridge Rule, hay que evitar reaccionar a todos los findings de GuardDuty sin discriminar. Los falsos positivos pueden provocar aislamientos innecesarios que interrumpen servicios en producción. El patrón de evento debe ser quirúrgico: solo severidad HIGH o superior, o tipos de finding específicos como . Cuanto más preciso el filtro, menor el riesgo de impacto no deseado.
Las Custom Actions de Security Hub ofrecen un punto intermedio entre la automatización total y la aprobación manual. El equipo de seguridad selecciona un finding en la consola y hace clic en «Iniciar aislamiento», lo que dispara EventBridge → Lambda sin necesidad de código adicional.
Es importante no confundir EventBridge con su predecesor:
| Aspecto | EventBridge | CloudWatch Events | |---------|-------------|-------------------| | Relación | EventBridge reemplaza a CloudWatch Events | Servicio de enrutamiento anterior a EventBridge | | Bus de eventos | Bus por defecto + buses personalizados + buses de socios | Solo bus por defecto | | Integración con terceros | Recibe eventos de socios SaaS como Datadog y PagerDuty | No disponible | | Recomendación | Usar EventBridge para todas las configuraciones nuevas | Legado |
En cualquier pregunta del examen sobre «disparar respuesta automática a eventos de detección», la respuesta siempre es EventBridge. CloudWatch Events es legado y no se recomienda para arquitecturas nuevas.
---
Patrones de Aislamiento Automático: Quarantine SG, Revocación IAM y Snapshot Forense
La contención es la fase donde el tiempo importa más. Cada segundo que una instancia comprometida sigue comunicándose con el exterior representa daño adicional.
Patrón Quarantine SG
El Quarantine SG (grupo de seguridad de cuarentena) es el equivalente digital de encerrar a un paciente infectado en una sala sellada. Se crea con antelación un grupo de seguridad que deniega todo el tráfico entrante y saliente. Cuando Lambda detecta la amenaza, llama a , lo que elimina todos los grupos de seguridad existentes y los reemplaza por el de cuarentena. Simplemente añadir el Quarantine SG sin eliminar los anteriores deja las reglas originales activas, así que el reemplazo completo es obligatorio. La lista de grupos originales debe guardarse en algún lugar (por ejemplo, en los tags de la instancia) para poder restaurarla durante la recuperación. Si el equipo forense necesita acceder a la instancia, se puede añadir una única regla entrante en el Quarantine SG que permita solo la subred del entorno de análisis.
Revocación de Roles y Políticas IAM
Revocar inmediatamente el IAM Role adjunto a la instancia comprometida, o agregar una política inline que restrinja sus permisos, también forma parte de la contención. Cuando una clave de acceso IAM queda expuesta, desactivarla es la prioridad absoluta. AWS, al detectar credenciales expuestas automáticamente, adjunta la política a la entidad afectada. Si ves esta política en una cuenta, significa que el equipo de AWS Trust & Safety ya ha detectado la exposición. No borres esta política — desactiva primero la clave y luego usa CloudTrail para investigar el alcance del daño. Las credenciales obsoletas (claves no utilizadas durante más de 90 días) se gestionan mediante un patrón de Lambda programada que combina el informe de credenciales IAM con Access Analyzer.
Separación de EBS Snapshot y Configuración del Entorno Forense
Inmediatamente después del aislamiento, hay que preservar la evidencia mediante EBS Snapshot. Si se termina la instancia antes de tomar el snapshot, los datos del instance store se pierden de forma permanente e irrecuperable. El snapshot siempre va primero.
| Método de Aislamiento | Disponibilidad del Servicio | Preservación de Evidencia | Bloqueo de Red | |-----------------------|----------------------------|--------------------------|----------------| | Aplicar Quarantine SG | Se mantiene (instancia en ejecución) | Volúmenes EBS preservados | Bloqueo completo posible | | Terminar instancia | Auto Scaling lanza nueva instancia | Instance store se pierde | Bloqueo completo |
Si la instancia pertenece a un Auto Scaling Group, el orden correcto es: primero hacer Detach del ASG (se separa la instancia del grupo sin terminarla, y el ASG lanza automáticamente una nueva instancia de reemplazo), y después aplicar el Quarantine SG. Para el análisis forense, se crea un volumen EBS nuevo a partir del snapshot y se monta en una instancia de análisis dedicada. Acceder directamente al volumen original comprometería la integridad de la evidencia.
!3 patrones de aislamiento automático
SSM Automation y Lambda: Convirtiendo Runbooks en Código
SSM Automation es el sistema que permite escribir los procedimientos operativos estándar (SOP) como documentos YAML y ejecutarlos de forma automática. Un Runbook típico de aislamiento de EC2 tiene esta estructura: Paso 1 — crear EBS Snapshot; Paso 2 — aplicar Quarantine SG; Paso 3 — enviar notificación SNS. Para cada paso se puede definir el comportamiento en caso de fallo: reintentar, omitir o ejecutar un rollback.
Lambda y SSM Automation tienen roles distintos que se complementan. Lambda es ideal para acciones únicas y rápidas, como reemplazar el grupo de seguridad o desactivar una clave de acceso, donde la latencia importa. SSM Automation es más adecuado para flujos de trabajo secuenciales de múltiples pasos donde la trazabilidad y el control de errores son esenciales. La combinación óptima es: EventBridge → Lambda (aislam