Este plan se activa ante cualquier evento Nivel 1 (Grave) que amenace la integridad física del datacenter, la seguridad de los datos, o la continuidad del negocio de forma masiva.

1. Seguridad Humana Primero: Ningún equipo vale más que una persona
2. Calma y Metodología: El pánico genera errores. Siga el plan
3. Contener, luego Erradicar: Primero evite que el problema se extienda, luego soluciónelo
4. Comunicar y Documentar: La falta de información es el segundo desastre

El objetivo de esta fase es confirmar la emergencia y activar al equipo correcto en el menor tiempo posible.

1. Recepción de Alerta: La emergencia se detecta (vía monitoreo, alerta física [humo, agua], o reporte de usuario crítico)
2. Prioridad Cero (Triaje Físico):
   • ¿Hay fuego, inundación, o riesgo eléctrico?
   • SÍ: Evacuar personal del área afectada. Activar sistemas de supresión (si es seguro) y llamar a servicios de emergencia (Bomberos, 911/100). La seguridad del personal anula cualquier paso técnico.
   • NO: Continuar al paso 3
3. Declaración de Incidente Grave: El primer técnico en confirmar la alerta (ej. NOC, Sysadmin de guardia) debe:
   • Declarar un “Incidente de Nivel 1” (o código rojo).
   • Activar el Árbol de Llamadas de Emergencia (Call Tree) o el sistema de alertas (ej. PagerDuty, Opsgenie)
4. Convocatoria del ERT (Equipo de Respuesta a Emergencias): Se convoca al equipo core. Esto no es una reunión de “todo el mundo”, es un equipo específico:
   • Comandante del Incidente (IC): 1 persona (ej. Jefe de Infraestructura o Sysadmin Sr.) que dirige la respuesta. No es quien “teclea”, es quien toma decisiones y coordina.
   • Especialista de Red (Network): Aísla y gestiona la conectividad.
   • Especialista de Sistemas (Sysadmin): Gestiona servidores, virtualización y storage.
   • Especialista de Seguridad (Infosec): Clave si es un ciberataque. Analiza y preserva evidencia.
   • Encargado de Comunicaciones: una sola persona que gestiona la comunicación con stakeholders (management, negocio) para que dejen trabajar al equipo técnico.
5. Establecer “Sala de Guerra” (War Room):
   • Virtual: Iniciar un bridge de conferencia dedicado (Teams, Zoom, etc.) que permanecerá abierto hasta el final
   • Física: Una sala de reuniones designada si el equipo está en sitio
   • Regla: Toda la comunicación técnica pasa por aquí

El objetivo es entender el “radio de explosión” (blast radius) y detener el sangrado inmediatamente.

1. Diagnóstico Rápido (Triaje Técnico): El IC coordina al ERT para responder:
   • ¿Qué está afectado? (Servicios, servidores, racks, red)
   • ¿Cuál es el impacto? (Ej: “La base de datos de facturación está caída”, “El 50% de los hosts de VMware están inaccesibles”)
   • ¿Se está extendiendo? (Ej: “El ransomware se está moviendo lateralmente”, “El agua está llegando al Rack B”)
2. Acción de Contención Inmediata: No se intenta arreglar nada aún. El objetivo es evitar que empeore
   • Ej. Ciberataque (Ransomware):
   • ¡Desconectar! Aislar la red afectada. (Desconectar uplinks del datacenter, segmentar VLANs, apagar puertos de switches, bloquear IPs en el firewall)
   • Apagar servidores comprometidos (no los sanos) para detener el cifrado
   • Ej. Falla de Refrigeración (HVAC):
   • Iniciar apagado controlado de sistemas no críticos (Dev, Test) para reducir la carga térmica y ganar tiempo para los sistemas de producción
   • Ej. Falla de Storage/Corrupción de Datos:
   • Poner las LUNs o bases de datos afectadas en modo read-only o offline para prevenir más corrupción
   • Ej. Inundación/Fuego:
   • Si es seguro, ejecutar el EPO (Emergency Power Off) del área afectada para prevenir cortocircuitos o electrocución
3. Preservación de Evidencia (Rol de Infosec):
   • Si se sospecha de un ataque, no apagar ni reiniciar las máquinas clave antes de tomar snapshots de memoria (RAM dump) y de disco
   • La contención (aislamiento de red) es prioritaria, pero la evidencia es crucial para la erradicación

El objetivo es identificar la causa raíz (RCA) y eliminarla permanentemente.

1. Identificación de Causa Raíz (RCA):
   • Aquí es donde el equipo investiga. ¿Por qué falló el HVAC? ¿Por dónde entró el atacante? ¿Qué causó la corrupción del array?
   • Se analizan logs (Firewall, AD, VMware, SAN), métricas de monitoreo, y se correlaciona la línea de tiempo del incidente
2. Plan de Erradicación: Una vez identificada la RCA, el IC aprueba un plan para eliminarla
   • Ej. Ciberataque:
   • Identificar y eliminar el malware
   • Parchar la vulnerabilidad explotada (ej. actualizar el FortiOS, parchear el servidor Exchange)
   • Rotar TODAS las credenciales (Admins, cuentas de servicio) que pudieron estar expuestas
   • Ej. Falla Física/Hardware:
   • Reemplazar la PDU fallida, el controlador de la SAN, o la cuchilla (blade) defectuosa
   • Contactar a proveedores (ej. servicio técnico de la climatizadora, compañía eléctrica)
   • Ej. Falla de Software/Parche:
   • Realizar el rollback del parche defectuoso

El objetivo es restaurar los servicios de forma segura y ordenada, activando el Plan de Recuperación ante Desastres (DRP) si es necesario.

1. Priorización de Servicios: No se levanta todo a la vez. Se sigue un orden de prioridad de negocio.
   • Prioridad 0 (Core): Identidad (Active Directory, DNS, DHCP), Red Core, Firewalls
   • Prioridad 1 (Críticos): ERP, Bases de Datos principales, Aplicaciones de cara al cliente
   • Prioridad 2 (Soporte): Correo interno, BI, sistemas secundarios
   • Prioridad 3 (No urgentes): Servidores de Dev/Test, archivos históricos
2. Restauración (El “cómo”):
   • Si es por Ciberataque/Corrupción: Restaurar desde backups limpios y verificados. Este es el paso más común. Asumir que el entorno actual está contaminado
   • Si el Datacenter está Inoperable (Fuego/Inundación): Declarar “Desastre” y activar el Failover al sitio de DR (Datacenter Secundario)
   • Si fue Falla de Hardware: Levantar servicios en el hardware reparado o en spare (ej. vMotion de VMs a hosts sanos)
3. Verificación y Pruebas Funcionales:
   • El servicio no está “resuelto” solo porque pinguea.
   • El equipo técnico (Sysadmin, Red) valida la conectividad y el estado del SO
   • Se contacta a los “Dueños del Negocio” (Business Owners) o usuarios clave para que realicen pruebas funcionales (ej. “Intenta generar una factura”, “Consulta el stock”)

El objetivo es confirmar la estabilidad y volver a la operación normal.

1. Monitoreo Intensivo (Modo “Paranoico”):
   • Tras la restauración, el ERT permanece en la “Sala de Guerra” monitoreando activamente el rendimiento, los logs y las alertas de seguridad durante un período de gracia (ej. 2 a 4 horas)
   • Se busca cualquier reincidencia del problema (ej. el atacante intenta volver a entrar, el hardware vuelve a fallar)
2. Declaración de “Todo Resuelto” (All-Clear):
   • Solo cuando el IC, basado en el monitoreo y la validación de negocio, confirma que el entorno está estable, se declara el fin de la emergencia
3. Comunicación Final: El Encargado de Comunicaciones envía el informe final a todos los stakeholders indicando que el incidente ha concluido y los servicios están operativos
4. Cierre de la Sala de Guerra: Se cierra el bridge de conferencia

Esta es la fase más importante para el futuro. Se realiza dentro de los 5 días hábiles posteriores al incidente, sin culpar a nadie (blameless post-mortem).

1. Agendar la Reunión Post-Mortem: Invitar al ERT y a los stakeholders clave
2. Revisar la Documentación: Se analiza la línea de tiempo del incidente (que se debió documentar durante la Fase 2)
3. Análisis (Las 5 Preguntas):
   • ¿Qué pasó? (Resumen fáctico del incidente)
   • ¿Cuál fue el impacto? (Horas de inactividad, costo, datos perdidos)
   • ¿Qué salió bien? (Ej: “La segmentación de red detuvo al ransomware”, “El backup funcionó perfecto”)
   • ¿Qué salió mal? (Ej: “Tardamos 45 minutos en activar al ERT”, “El Comandante del Incidente no estaba claro al inicio”, “El sensor de agua falló”)
   • ¿Qué haremos para evitar que se repita? (Acciones concretas, con un responsable y una fecha de entrega. Ej: “Comprar PDU con monitoreo”, “Implementar 2FA en la VPN”, “Mejorar el sistema de alertas”)
4. Actualizar la documentación: Los aprendizajes se usan para mejorar este mismo procedimiento

• Linux: En un ataque, no olvides revisar crontab, /tmp, ~/.ssh/authorized_keys y las conexiones de red (netstat -antp) para contención y erradicación
• Windows: Revisa Tareas Programadas, Servicios, logs de Event ID 4624 (Logon) y 4625 (Failed Logon), y usa herramientas de Sysinternals (especialmente TCPView y Autoruns) para la erradicación
• Segmentación: Tu mejor arma de contención es una red bien segmentada (VLANs, ACLs, microsegmentación). Si todo está en la misma red “plana”, estás perdido
• Backups: Sigue la regla 3-2-1-1-0: 3 copias, 2 medios distintos, 1 offline (o air-gapped), 1 inmutable, y 0 errores de verificación