Parte: 10 — Seguridad en la nube y contenedores · Fuente: NIST SP 800-61 Computer Security Incident Handling Guide y AWS Security Incident Response Guide ⏱️ Duración estimada: 130 min · Nivel: Avanzado
Aplicar el ciclo de respuesta a incidentes (NIST SP 800-61) al contexto de la nube, donde la elasticidad, las APIs y la efimeridad cambian la práctica: contención por IAM y aislamiento de red, adquisición de evidencia mediante snapshots, y erradicación/recuperación aprovechando IaC. El alumno ejecutará un playbook completo sobre una credencial comprometida y una instancia comprometida.
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | NIST SP 800-61 Rev. 3 aplicado a la nube | Integrar respuesta con gestión de riesgo y operación cloud |
| 2 | Preparación: roles, permisos, runbooks | La respuesta se gana antes del incidente |
| 3 | Contención de identidad | Revocar/rotar credenciales y sesiones |
| 4 | Aislamiento de recursos | Cuarentena sin apagar la evidencia |
| 5 | Adquisición de evidencia | Snapshots, memoria, logs preservados |
| 6 | Erradicación y recuperación con IaC | Reconstruir limpio y reproducible |
| 7 | Post-incidente y lecciones | Cerrar el ciclo y mejorar |
La respuesta cloud investiga un sistema que cambia mediante API y donde identidad puede tener más continuidad que una instancia. Preparación crea roles de emergencia, destinos de evidencia separados, logging por organización, inventario, contactos del proveedor y automatización ensayada. Durante el incidente, cada acción operativa se registra porque también genera evidencia y puede alterar el alcance.
El diagrama no apaga una instancia de inmediato. Primero identifica qué evidencia es volátil y qué daño continúa. Si hay cifrado o exfiltración activos, contener puede preceder a una adquisición extensa. Si la instancia tiene memoria única y el riesgo está controlado, se preserva antes. La bitácora explica la decisión con información disponible.
Deshabilitar una access key no revoca necesariamente sesiones ya emitidas, roles asumidos, tokens de federación, aplicaciones OAuth u otras credenciales creadas. Se reconstruye la cadena de identidad y se ordena revocación/rotación para que el atacante no capture reemplazos. También se preservan policies y trust relationships antes de corregirlas.
Aislar una VM mediante SG de cuarentena reduce red, pero puede no detener acciones por instance role hacia APIs, tráfico por rutas no consideradas o servicios administrados. La cuarentena se prueba en ambas direcciones y se controla el acceso del equipo forense.
Snapshots son copias administradas del volumen, no imágenes físicas ni memoria. Se conservan identificador, cuenta, región, hora, tags, comando/API, request ID, permisos y hash de exportaciones cuando existe. Para contenedores y serverless se preservan manifiestos, digest, logs, variables, identidad, eventos y plano de orquestación antes de que el ciclo de vida reemplace la carga.
Los logs pueden tener latencia, categorías deshabilitadas o vivir en otra cuenta. Se exportan respuestas originales con paginación y consultas. NISTIR 8006 ayuda a describir desafíos de acceso y dependencia del proveedor; no entrega un procedimiento único para AWS, Azure o Google.
Erradicación incluye claves, sesiones, roles, trust policies, reglas, funciones, imágenes, pipeline y vector inicial. Recuperar con IaC reduce improvisación solo si el código, módulos, state, credenciales e imagen base fueron corregidos y revisados. Un apply reproducible puede reproducir también la vulnerabilidad.
La validación comprueba acceso denegado para credenciales antiguas, servicio saludable, logging activo, detecciones nuevas y ausencia de comportamientos conocidos durante una ventana justificada. El informe declara puntos ciegos y riesgo residual.
CloudTrail alerta por enumeración de secretos con una access key filtrada. El equipo desactiva la clave, pero descubre eventos posteriores de una sesión de rol que esa identidad asumió antes. Preserva eventos, políticas y trust policy; aplica una denegación temporal autorizada al principal/sesiones según mecanismo disponible y busca recursos creados en todas las regiones relevantes.
Una instancia usada para persistencia se pone en SG de cuarentena, se crea snapshot y se conserva su configuración. La recuperación despliega desde Terraform corregido con un rol nuevo y data events habilitados. La prueba confirma que la clave y sesión antiguas fallan, el servicio funciona y una simulación benigna activa la nueva detección.
Dominas la clase cuando coordinas contención de identidad y recurso, preservas evidencia con límites del proveedor, amplías erradicación a IaC y automatización, y cierras mediante pruebas de credenciales antiguas, servicio, logging y riesgo residual documentado.
# Contención de credencial: deshabilitar una clave de acceso comprometida (AWS)
aws iam update-access-key --access-key-id AKIA... --status Inactive
# Adquisición: crear un snapshot forense del volumen de una instancia comprometida
aws ec2 create-snapshot --volume-id vol-0abc --description "IR-forense-caso-42"
Ejecuta el playbook en tu cuenta de laboratorio, sobre recursos que controlas.
Ejecuta un playbook completo end-to-end para una credencial comprometida que lanzó una instancia maliciosa: detección, contención, aislamiento, adquisición, erradicación y recuperación con IaC.
Criterio de aceptación: al final, la clave comprometida está deshabilitada y sus sesiones revocadas, existe un snapshot forense y evidencia preservada en almacén inmutable, no queda persistencia del atacante (verificado en logs), y el recurso afectado está reconstruido desde Terraform con secretos rotados. Todo queda documentado en un informe con línea de tiempo.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
| Se apagó la instancia y se perdió la memoria | Contención destructiva prematura; aísla por red antes de apagar. |
| El atacante volvió tras rotar una clave | Quedó persistencia (otro usuario/rol/función); erradica antes de recuperar. |
| Evidencia sin trazabilidad suficiente | Faltan exportación original, identificadores, permisos o bitácora. Preserva respuestas, snapshots y cadena de custodia según el contexto. |
| Rotación incompleta de credenciales | Solo se trató la credencial inicial. Reconstruye sesiones, roles y secretos accesibles y documenta el alcance usado para rotar o revocar. |
| Reconstrucción trae de vuelta el problema | Se reconstruyó desde IaC vulnerable; corrige el código antes de aplicar. |
❓ ¿Por qué aislar por red en vez de apagar una instancia comprometida? Apagarla destruye la memoria volátil y las conexiones activas, evidencia valiosa. Aislarla (security group sin tráfico) la neutraliza conservando el estado para el análisis forense.
❓ ¿Qué se contiene primero en la nube, la identidad o el recurso? Normalmente la identidad: deshabilitar la credencial comprometida y revocar sesiones corta el acceso del atacante de inmediato, incluso a recursos que aún no sabes que tocó. Luego se aísla el recurso concreto.
❓ ¿Por qué reconstruir con IaC en lugar de "limpiar" el recurso? Porque una limpieza manual puede dejar condiciones desconocidas. Reconstruir desde código e imágenes revisados reduce incertidumbre y mejora reproducibilidad, pero no garantiza limpieza si IaC, módulos, state, secretos o datos conservan la causa.
Clase 234 — Logging y detección en la nube