El ciclo de respuesta a incidentes en AWS
Las fases de la respuesta a incidentes según la guía de AWS, la preparación específica de la nube (break-glass, cuenta forense, runbooks) y cuatro playbooks de escenarios habituales.
El día que detectes una intrusión en Citas no es el día para improvisar. La respuesta a incidentes es el músculo que convierte el pánico (“¿alguien está leyendo los informes de pacientes?”) en un procedimiento: aislar, investigar, erradicar, recuperar. Y como casi todo en seguridad, el 80 % del trabajo se hace antes del incidente. Esta nota recorre el ciclo que usa la guía de respuesta a incidentes de seguridad de AWS y aterriza cuatro escenarios concretos en playbooks.
El ciclo, no la lista#
La guía de AWS se apoya en el modelo clásico de NIST SP 800-61 y lo agrupa en tres bloques: preparación, operaciones (detección, análisis, contención, erradicación y recuperación) y actividad posterior al incidente. Para estudiarlo es cómodo verlo como seis fases encadenadas en un bucle: lo que aprendes al final de un incidente alimenta la preparación del siguiente.
Paso 1 de 7El ciclo
Seis fases giran alrededor del entorno Citas. No es una lista que recorres una vez: es un bucle que mejora en cada vuelta, el mismo modelo de NIST que adopta la guía de respuesta de AWS.
La clave que suele perderse: la preparación acelera todas las demás fases. Si la cuenta forense ya existe, los permisos de aislamiento están pre-aprobados y el runbook está escrito, la contención se mide en minutos. Si no, se mide en horas que el atacante aprovecha.
Preparación en la nube#
En un centro de datos, prepararte era tener contactos y un portátil forense. En AWS la preparación es, sobre todo, IAM y automatización:
- Acceso de ruptura (break-glass): una identidad de emergencia, con MFA físico, credenciales en un sobre sellado y una alarma que avisa a todo el equipo en cuanto se usa. Es el acceso que tendrás cuando el SSO falle o cuando sospeches que tu identidad habitual está comprometida.
- Cuenta forense dedicada: una cuenta aislada, bajo la misma organización, donde copias snapshots y logs para analizarlos sin tocar producción ni alertar al atacante. Separa la evidencia del entorno comprometido.
- Permisos pre-aprobados: los roles de respuesta (aislar una instancia, tomar un snapshot, desactivar una clave) revisados y listos antes. En caliente no es momento de redactar políticas IAM ni de pedir aprobaciones.
- Runbooks: el procedimiento escrito de cada escenario, idealmente con los pasos manuales y los automatizados (una función Lambda o un documento de Systems Manager que aísle una instancia con un clic).
Cuatro escenarios y su playbook#
Casi todo lo que verás en una cuenta AWS cae en uno de estos cuatro patrones. Para cada uno, la misma estructura: detectar → contener (sin destruir evidencia) → erradicar → recuperar.
| Escenario | Señal típica | Contención inmediata | Evidencia a preservar |
|---|---|---|---|
| Credenciales IAM filtradas | GuardDuty UnauthorizedAccess:IAMUser/*, secret scanning |
Desactivar la access key, deny temporal | CloudTrail de la accessKeyId |
| EC2 comprometida | GuardDuty Backdoor/CryptoCurrency, tráfico raro |
SG forense (vacío), aislar | Snapshot EBS, memoria, metadatos |
| Bucket S3 expuesto | Policy:S3/BucketPublicAccessGranted, Access Analyzer |
Block Public Access, corregir política | CloudTrail (data events), versiones |
| Ransomware sobre S3 | Impact:S3/AnomalousBehavior.Delete, borrados masivos |
Revocar al principal, cortar permisos de borrado | Versiones previas, logs de DeleteObject |
1. Credenciales IAM filtradas#
El escenario estrella (y la pregunta de entrevista más común). Una access key acaba en un repositorio o en un log. La contención es desactivar la clave y revocar sesiones, pero con un matiz importante: las credenciales temporales derivadas (STS, GetFederationToken) sobreviven a la desactivación de la clave que las generó, porque se evalúan contra los permisos actuales del principal. Para cortarlas de verdad hay que quitarle permisos al usuario, no solo apagar la llave. Lo desarrollamos paso a paso en su propia nota.
2. EC2 comprometida#
Una instancia de la API de Citas empieza a minar criptomoneda o a hablar con un C2. El orden importa: contener sin reiniciar, porque un reinicio borra la memoria, que es evidencia de primera.
- Aísla con un security group forense: un SG sin reglas de entrada ni salida. La instancia sigue viva (y su memoria intacta) pero no habla con nadie.
- Preserva la evidencia: toma un snapshot del volumen EBS y, si tu runbook lo contempla, un volcado de memoria volátil. Desactiva la terminación accidental.
- Copia a la cuenta forense el snapshot para analizarlo sin tocar la instancia original.
# Aislar: reemplazar todos los SG por el SG forense vacíoaws ec2 modify-instance-attribute --instance-id i-0abc --groups sg-forense
# Evitar que se termine (y se pierda la evidencia)aws ec2 modify-instance-attribute --instance-id i-0abc --disable-api-termination
# Snapshot del disco como evidenciaaws ec2 create-snapshot --volume-id vol-0def \ --description "IR-2026-10-11 evidencia i-0abc" \ --tag-specifications 'ResourceType=snapshot,Tags=[{Key=caso,Value=IR-2026-10-11}]'3. Bucket S3 expuesto#
El citas-adjuntos o un bucket de backups aparece accesible públicamente. La contención es inmediata y la da S3 Block Public Access a nivel de cuenta y de bucket; después corriges la política o la ACL concreta que lo abrió. Para saber el alcance real —qué objetos se leyeron y por quién— necesitas los eventos de datos de CloudTrail activados sobre ese bucket; si no los tenías, GuardDuty S3 Protection pudo alertarte, pero no tendrás el detalle para la notificación de brecha. Como hay PII de pacientes, el alcance determina obligaciones legales.
4. Ransomware sobre S3#
“Ransomware en S3” no es cifrado de disco: es un atacante con permisos que borra o sobrescribe masivamente tus objetos y pide rescate. La defensa es de diseño:
- Versionado activado: un
DeleteObjectno borra, crea un marcador; la versión anterior sigue ahí. - Object Lock (WORM) en los buckets críticos: ni un administrador comprometido puede borrar antes de que expire la retención.
- MFA Delete en buckets versionados para exigir un segundo factor al borrar versiones.
La detección es un pico de DeleteObject/PutObject y el hallazgo Impact:S3/AnomalousBehavior.Delete de GuardDuty. La recuperación consiste en restaurar desde las versiones previas o desde una copia inmutable.
Errores habituales#
Tu turno
Escribe el runbook de un escenario
Elige uno de los cuatro escenarios y escribe su runbook para tu propio laboratorio o trabajo (nunca producción ajena). Debe responder, en orden y con comandos concretos:
- ¿Qué señal lo dispara y dónde la ves?
- ¿Cómo contienes sin destruir evidencia? (comando exacto)
- ¿Qué evidencia copias y a dónde?
- ¿Cómo erradicas la causa raíz y buscas persistencia?
- ¿Cómo validas que puedes dar por recuperado el servicio?
Después, detónalo en una cuenta sandbox y cronometra cada fase. El número que importa es cuánto tardas de la señal a la contención.
Reto
¿Por qué aislar una EC2 con un SG vacío en vez de pararla?
▸Mostrar solución
Parar (stop) la instancia la apaga y pierdes la memoria volátil, donde suele estar la
evidencia más valiosa (procesos, conexiones, claves en RAM). Un security group sin reglas la deja
encendida y con la memoria intacta, pero incomunicada: contienes sin destruir.
Reto
Desactivaste la access key filtrada, pero el atacante sigue actuando. ¿Qué pasó?
▸Mostrar solución
Probablemente generó credenciales temporales con STS (GetFederationToken o una sesión de rol)
antes de que la apagaras. Esas credenciales viven hasta su expiración y se evalúan contra los
permisos actuales del principal: tienes que quitarle permisos (política de deny), no solo
desactivar la llave.
En resumen#
- La respuesta a incidentes de AWS sigue el modelo de NIST: preparación → operaciones (detección, análisis, contención, erradicación, recuperación) → lecciones aprendidas, en bucle.
- La preparación en la nube es IAM y automatización: break-glass, cuenta forense, permisos pre-aprobados y runbooks ensayados. Acelera todo lo demás.
- Contén sin destruir evidencia: SG forense en vez de terminar la EC2, desactivar la clave en vez de borrar el usuario, Block Public Access en vez de vaciar el bucket.
- Cada escenario tiene su playbook, pero la columna vertebral es la misma: detectar → contener → investigar → erradicar → recuperar.
- Lo que aprendes en el post-mortem se convierte en preparación: una detección nueva, un runbook mejor, una SCP más estricta.