Respuesta a incidentes en la nube
Detectar no basta: cuando salta la alerta, la velocidad y la calidad de la contención deciden si se queda en un susto o se vuelve un titular.
Qué es
La respuesta a incidentes es el proceso que empieza cuando una señal de detección (una alerta de GuardDuty, una anomalía en CloudTrail, un aviso del ) se confirma como evento real y termina cuando el entorno está contenido, restaurado y aprendió algo de lo ocurrido.
En la nube el juego cambia en dos puntos. Primero, todo es API: se puede aislar una instancia, revocar una credencial o cambiar una clave en segundos y por script. Segundo, el entorno es efímero: si no preservas la evidencia antes de derribar el recurso, desaparece junto con él.
Las fases del ciclo
El modelo de NIST (SP 800-61) sigue siendo la mejor columna vertebral, incluso para la nube:
- Preparación: runbooks escritos, contactos de guardia, cuentas de respuesta con acceso listo y probado, logs centralizados.
- Detección y análisis: confirmar que la alerta es real, estimar el alcance (qué identidades, recursos y datos) y clasificar la gravedad.
- Contención, erradicación y recuperación: detener el daño, quitar el acceso del atacante y restaurar el servicio desde un estado confiable.
- Lecciones aprendidas: revisión sin culpas, ajustes en los controles y en el inventario, y actualización de los runbooks.
Contención por identidad primero
El vector más común en la nube es una credencial filtrada, así que el primer movimiento suele ser neutralizar la identidad, no la máquina. Desactivar la clave de acceso y adjuntar una policy de denegación total corta al atacante sin derribar el workload legítimo, y preserva el estado para el análisis.
USER=svc-deploy
KEY=AKIAIOSFODNN7EXAMPLE
# 1. desactiva la clave (no la borra: se preserva para forense)
aws iam update-access-key --user-name "$USER" \
--access-key-id "$KEY" --status Inactive
# 2. deniega todo a las sesiones ya emitidas antes de ahora
aws iam put-user-policy --user-name "$USER" \
--policy-name quarantine \
--policy-document file://deny-all.jsonPreservar la evidencia antes de destruir
Para un workload sospechoso, el reflejo de "terminar la instancia" borra memoria, procesos y conexiones abiertas. El camino correcto es aislar primero (cambiar el por uno que no permita tráfico), tomar snapshot de los volúmenes, capturar lo que sea volátil y solo entonces decidir si se descarta o se investiga.
Las cuentas de forense separadas, con snapshots copiados a un bucket inmutable (Object Lock) y la anotada, evitan que la evidencia sea alterada por quien comprometió la cuenta original.
Automatizar lo repetible
Buena parte de la contención es repetitiva y urgente, el entorno perfecto para la automatización: una alerta de alta confianza activa una función que aísla el recurso, abre el ticket y avisa a la guardia. Las decisiones ambiguas siguen siendo humanas.
La métrica que importa es el (tiempo medio hasta la respuesta). Los runbooks probados en ejercicios (game days) y las automatizaciones con aprobación para acciones destructivas reducen el MTTR sin crear el riesgo de que la propia automatización cause el incidente.
conexiones en el mapa
- Logging & detection - señales y alertasdispara la respuestaRespuesta a incidentes en la nube
- CWPP - protección de workloadsalerta de runtimeRespuesta a incidentes en la nube
- Respuesta a incidentes en la nuberevoca credencialesIAM - identidad y acceso
actualizado el 14/10/2026 · fuentes para profundizar · reportar un error
en otros dominios
- Triaje, acotamiento del alcance y contenciónresponsela misma contención, aplicada a cuentas y recursos de nube
- Regression evals - suite fija en el PRai-agentscada incidente se vuelve un caso de prueba
- Runbooks, respuesta y hardening posincidentesecopsel runbook de L7 es un caso específico de la respuesta general
Estudia antes
pon a prueba lo que entendiste
Cargando preguntas…