Respuesta a incidentes
A pesar de todo el hardening y la detección, algún día algo va a pasar de verdad. Este módulo es sobre qué hacer en ese momento exacto — con la cabeza fría y un procedimiento claro, no improvisando.
Qué es un incidente
Un incidente de seguridad es cualquier evento confirmado (no solo sospechado) que compromete la confidencialidad, integridad o disponibilidad de un sistema: una cuenta comprometida, malware activo, una fuga de datos, un servicio caído por un ataque. La respuesta a incidentes es el proceso estructurado para manejarlo del principio al fin.
Es como el protocolo de un hospital ante una emergencia: no importa cuán capacitado esté cada médico individualmente, sin un protocolo claro (triage, estabilizar, tratar, documentar) el caos empeora todo. La respuesta a incidentes es exactamente ese protocolo, aplicado a sistemas comprometidos en vez de pacientes.
Las seis fases del ciclo de respuesta a incidentes
Preparación
Todo lo anterior del curso: hardening, detección, un plan escrito de antemano. Se hace antes de que pase nada.
Identificación
Confirmar que lo que se está viendo es realmente un incidente, y no un falso positivo.
Contención
Frenar que el daño se siga expandiendo, sin destruir evidencia todavía.
Erradicación
Eliminar la causa raíz: la cuenta comprometida, el malware, la puerta trasera dejada.
Recuperación
Volver los sistemas a operación normal, con monitoreo reforzado por si el problema reaparece.
Lecciones aprendidas
Documentar qué pasó y por qué, para mejorar la preparación de cara al próximo incidente.
Contención: la decisión más delicada del proceso
Frente a un sistema comprometido, hay dos instintos en tensión: desconectar todo ya para frenar el daño, o dejarlo activo para observar al atacante y juntar más evidencia antes de actuar. No hay una respuesta única — depende de la gravedad, de si hay datos críticos en riesgo, y de la política de la organización. Lo que sí es constante: cualquier decisión de contención se documenta con hora exacta, porque después va a ser parte de la reconstrucción de los hechos (el módulo de Forense que sigue).
Todo lo que se toca, copia o modifica durante un incidente puede terminar siendo evidencia legal, sobre todo si hay una fuga de datos que requiere aviso regulatorio. Por eso, desde la fase de contención, cada acción se registra: quién hizo qué, cuándo, y por qué. Actuar rápido no significa actuar sin dejar registro.
El playbook: el guión para no improvisar
Un playbook de respuesta a incidentes es un procedimiento escrito de antemano para tipos específicos de incidentes: "qué hacer si detectamos ransomware", "qué hacer si una cuenta de administrador parece comprometida". Tenerlo listo antes de la crisis es lo que permite actuar rápido y con orden en el momento — exactamente lo contrario de descubrir sobre la marcha qué hacer mientras el reloj corre.
Un pentest profesional no termina en la explotación — buena parte del valor real que entrega un Red Team a una organización es medir, en la práctica, cuánto tiempo tarda el equipo defensivo en detectar y contener un ataque simulado. Ese tiempo (llamado MTTD/MTTR, tiempo medio de detección y de respuesta) es una de las métricas más importantes de madurez en ciberseguridad.
Elegí un escenario concreto: "una cuenta de usuario muestra logins fallidos masivos seguidos de un login exitoso desde una IP desconocida" (el mismo patrón que detectaste en el módulo de Logs).
Escribí, paso a paso, qué harías en cada una de las seis fases para ese escenario específico: ¿cómo confirmás que es real?, ¿cómo lo contenés sin perder evidencia?, ¿cómo verificás que la cuenta quedó limpia antes de reactivarla?
Ese documento, aunque simple, es literalmente la estructura de un playbook real. La próxima vez que veas ese patrón, no vas a tener que pensarlo desde cero.
Ponete a prueba
1. ¿Cuál es el orden correcto de las fases del ciclo de respuesta a incidentes?
2. ¿Por qué es importante documentar cada acción durante la contención?
3. ¿Qué es un playbook de respuesta a incidentes?