seguridadincident responsesoc

Incident Response: los 6 pasos para responder a un ciberataque

Cuando ocurre un incidente, el caos es el peor enemigo. Tener un plan de respuesta definido de antemano es lo que separa a las organizaciones que contienen rápido de las que improvisan y escalan el daño.

📅 14 jul 2026 ⏱ 10 min de lectura Byron Lainez

Son las 2 de la mañana. Un analista de turno ve una alerta que confirma ransomware activo en tres servidores. La pregunta no es técnica — es de proceso: ¿Qué hacemos primero?

Sin un plan de Incident Response (IR), la respuesta es improvisación bajo presión. Y bajo presión, la improvisación comete errores que convierten un incidente contenible en una catástrofe operativa.

El framework más usado globalmente para estructurar la respuesta es el NIST SP 800-61, que define seis fases. No como burocracia — como secuencia de sentido común formalizada.

Los 6 pasos del Incident Response

Fase 1 — Preparación
Todo lo que haces antes del incidente. Plan documentado, roles asignados, herramientas instaladas, playbooks escritos, contactos de emergencia conocidos, tabletop exercises realizados. Sin preparación, las otras fases no funcionan.
Fase 2 — Identificación
Determinar si lo que está pasando es realmente un incidente, qué tipo, qué alcance tiene y cuál es la severidad. No todo evento de seguridad es un incidente. El triaje correcto en esta fase evita sobre-reaccionar a falsos positivos o sub-reaccionar a incidentes reales.
Fase 3 — Contención
Detener la propagación del daño. No erradicar todavía — contener. Aislar el sistema comprometido sin destruir evidencia. Existen dos tipos: contención a corto plazo (inmediata, aislar para detener) y largo plazo (solución temporal que permite operar mientras se erradica).
Fase 4 — Erradicación
Remover la causa raíz del incidente. Eliminar el malware, cerrar las puertas traseras, revocar las credenciales comprometidas, parchear la vulnerabilidad explotada. La erradicación incompleta es la razón por la que muchos ataques de ransomware ocurren dos veces en la misma organización.
Fase 5 — Recuperación
Restaurar los sistemas afectados a operación normal, verificar que la amenaza fue eliminada y monitorear activamente por señales de reinfección. La recuperación sin monitoreo es apostar a que el atacante no volvió a entrar.
Fase 6 — Lecciones Aprendidas
La fase más importante y la más ignorada. Post-mortem documentado: ¿cómo entraron? ¿Cuánto tiempo estuvieron? ¿Qué falló en la detección? ¿Qué mejoras hacemos? Sin esta fase, el mismo ataque ocurre de nuevo.

Fase 1 en detalle: Preparación (la que define todo)

Cuando ocurre un incidente, el 80% de tu efectividad de respuesta ya está determinada por lo que hiciste antes. La preparación incluye:

El IR Plan

Un documento que responde: ¿quién hace qué cuando hay un incidente? Roles específicos, no "el equipo de TI". Hay una persona que toma decisiones de contención, una que comunica al management, una que maneja la evidencia. Sin roles claros, hay tres personas tomando decisiones contradictorias simultáneamente.

Runbooks y playbooks

Instrucciones paso a paso para tipos específicos de incidentes. Ransomware: 1. Aislar el endpoint afectado. 2. Verificar si el malware está en memoria o en disco. 3. Revisar logs de red de las últimas 48 horas buscando el vector de entrada. 4. Escalar a L3 si hay propagación. No improvisación — secuencia.

Tabletop exercises

Simulacros de incidentes donde el equipo practica las respuestas sin consecuencias reales. Descubres antes del incidente que el playbook tiene pasos que nadie sabe ejecutar, que el contacto de emergencia del proveedor de EDR está desactualizado, o que la comunicación entre TI y management es disfuncional.

⚠️ El error de LATAM
La mayoría de organizaciones medianas en Centroamérica y México no tiene un IR Plan documentado. Tienen personas que 'saben qué hacer' — hasta que esa persona está de vacaciones, bajo presión extrema o no es quien el incidente específico requiere. El plan escrito supera a la experiencia no documentada.

Fase 3: Contención — las decisiones difíciles

La contención tiene un dilema clásico: ¿Desconecto el sistema afectado inmediatamente o lo monitoreo primero?

Si lo desconectas inmediatamente, pierdes visibilidad del comportamiento del atacante (¿a dónde iba a moverse?, ¿qué exfiltró?) pero detienes el daño activo. Si lo monitoras, recopilas inteligencia valiosa pero el daño puede continuar.

La respuesta depende del tipo de incidente:

💡 Preservar la evidencia forense
Nunca apagues el sistema afectado si puedes evitarlo. La memoria RAM contiene evidencia crítica (procesos activos, credenciales en memoria, conexiones activas) que desaparece al apagar. Si necesitas apagarlo, documenta los procesos activos, las conexiones de red y los archivos recientes antes de hacerlo.

Fase 6: Lecciones Aprendidas — el post-mortem que nadie quiere hacer

Después de un incidente, el equipo está agotado y la presión es volver a la normalidad lo antes posible. El post-mortem se pospone indefinidamente. Semanas después, nadie recuerda los detalles y la oportunidad de aprendizaje se pierde.

Un post-mortem efectivo responde:

El documento del post-mortem no se usa para asignar culpas — se usa para mejorar. Los mejores equipos de SOC tienen una cultura de post-mortems sin culpa (blameless post-mortems), adoptada del mundo SRE/DevOps.

Métricas clave de Incident Response

✅ El IR Plan mínimo viable para hoy
Si no tienes nada documentado, empieza con esto en una sola página:

① Lista de roles: quién decide (técnico), quién informa al management, quién comunica con proveedores
② Criterios de severidad: qué es P1 (crítico) vs P2 (alto) vs P3 (medio)
③ Contactos de emergencia: proveedor de EDR, proveedor de IR forense, equipo legal
④ Decisión de aislamiento: en qué condiciones desconecto un sistema sin pedir aprobación
⑤ Canal de comunicación del incidente: slack/teams/signal — separado del canal normal para no contaminar la investigación

Eso solo ya es más de lo que tiene el 70% de las organizaciones medianas en LATAM.

¿Estás construyendo un plan de IR desde cero? Puedo ayudarte a estructurarlo. Escríbeme a hola@byronlainez.click.

← Anterior
Threat Hunting