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: 1 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.