¿Cómo construyes un plan de respuesta a incidentes que funcione?

La mayoría de las organizaciones no fracasan en la respuesta a incidentes porque carezcan de herramientas. Fracasan porque nadie acordó de antemano quién hace qué, y el primer incidente real se convierte en una reunión en lugar de una respuesta.

Comienza con las fases, no con el playbook

NIST SP 800-61 establece cuatro fases: preparación, detección y análisis, contención/erradicación/recuperación, y actividad post-incidente. Ese orden importa. A los equipos les encanta saltar directamente a la contención porque se siente productivo, pero si no has hecho el trabajo de preparación, no conoces tu propia red lo suficientemente bien como para contener nada limpiamente.

La preparación significa inventarios de activos que estén realmente actualizados, no la hoja de cálculo de 2022. Significa conocer tu ventana de retención de logs (si es 7 días y el atacante tuvo 30 días de tiempo de permanencia, ya has perdido la línea de tiempo). Significa herramientas forenses pre-preparadas — Velociraptor, KAPE, o incluso un procedimiento documentado de tar/dd para imágenes de disco — para que nadie descargue herramientas en un host comprometido durante un incidente activo.

Define niveles de severidad antes de necesitarlos

Un SEV1 (exfiltración activa de datos, detonación de ransomware, compromiso de admin de dominio) necesita una respuesta diferente que un SEV3 (malware aislado en una estación de trabajo sin privilegios). Escribe esto como una matriz: impacto vs. alcance vs. confianza. Asigna a cada severidad un tiempo de respuesta requerido y una ruta de escalada. Si tu comandante de incidente para un SEV1 es la misma persona que tiene que aprobar cada orden de compra de $500, has construido un cuello de botella en tu propio proceso de emergencia.

El rol de comandante de incidente no es opcional

Una persona dirige el incidente. No el ingeniero más senior por defecto — la persona mejor capacitada para coordinar, delegar, y tomar decisiones de contención bajo presión. Esta persona no necesariamente toca un teclado durante la respuesta; rastrea la línea de tiempo, gestiona la comunicación con legal y liderazgo, y decide cuándo activar el aislamiento de un segmento o desconectar un sistema.

Sin este rol, terminas con cinco personas SSH'd en la misma máquina, ninguna de ellas hablando entre sí, y nadie capturando la memoria volátil antes de que alguien reinicie la máquina para "ver si lo soluciona".

Decisiones de contención que realmente importan

La llamada más difícil en la mayoría de incidentes es: ¿aislar ahora, u observar un poco más para entender el alcance? Cortar el acceso de red demasiado pronto alerta al atacante que aún se está moviendo lateralmente y destruye tu oportunidad de ver su próximo movimiento. Esperar demasiado permite que el ransomware termine de cifrar recursos.

Un término medio razonable: usa segmentación de red y aislamiento EDR (CrowdStrike, Defender for Endpoint, SentinelOne todos lo soportan) para cortar un host del movimiento lateral mientras lo mantienes encendido para captura de memoria. El apagado completo debe ser un último recurso — mata evidencia volátil y, para casos de ransomware, puede activar comportamiento anti-forense integrado en algunos payloads.

Brechas de logging que lamentarás durante, no antes

Los valores por defecto de Windows Event Log no son suficientes. Si no tienes Sysmon implementado con una configuración decente (las configuraciones base de SwiftOnSecurity u Olaf Hartong son un buen punto de partida), estarás reconstruyendo árboles de procesos a partir de fragmentos. En el lado de la red, los logs de NetFlow o Zeek importan más de lo que la mayoría de las orgs se dan cuenta hasta que necesitan responder