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

1. La mayor parte de los backups funcionaron adecuadamente; alguien me comentó que algunos backups estaban también cifrados, pero que se pudo recuperar la mayoría de los datos de otras fuentes
2. Desconectar la corriente de los switches/gateways/routers en vez de cables de red de servidores
3. Realizar un inventario preliminar de los servidores y servicios comprometidos, para informar y tomar acciones
4. Crear un equipo de War Room mínimo, con responsables técnicos de alto nivel. Serán los responsables de comunicar a los equipos directivos y de operaciones las tareas y decisiones
5. Considerar que el acceso a los backups esté restringido, ya sea mediante el acceso a un puerto con credenciales, o bien en modo sólo lectura si es necesario accederlos mediantes CIFS
6. Realizar backups remotos, nunca en el propio equipo
7. Realizar backups remotos geográficamente alejados, especialmente de datos críticos para la operación de la empresa
8. Servidores de backup sin acceso desde los servidores de origen
9. Identificar los servidores afectados por ejemplo con una simple etiqueta “Infectado”, tratando de evitar apagarlos para intentar preservar evidencia del ataque que pueda llevar a obtener información forense relevante
10. Documentar el caso lo mejor posible, indicando qué ocurrió y qué se hizo, y mejorarlo poco a poco con el tiempo, con nuevos incidentes o simplemente revisando y registrando nuevas ideas
11. En general se recomienda: * evitar pagar, ya que nada asegura que se obtenga la clave de descifrado, se financia a los desarrolladores del ransomware, e incluso si se obtiene la clave, el trabajo para descifrar todos los archivos es una tarea titánica, y además agrega a la empresa al listado de “dispuestos a pagar” con lo cual se garantiza nuevos intentos de ataque; * evitar tomarse demasiado tiempo para identificar y buscar la cepa del ransomware pues es sumamente raro que exista una clave de descifrado preexistente; * tomar capturas e información de los mensajes, para documentar, denunciar, o aportar a investigadores, y si es posible del ejecutable o código que se encuentre, teniendo las precauciones del caso; * evitar intentar limpiar un servidor infectado, se debe blanquear los discos, y reinstalar de cero
12. Cambiar la contraseña de todos los administradores antes de comenzar la reinstalación. Considerar la necesidad de forzar cambio de contraseña/desactivar todos los usuarios si es necesario
13. En dominios Windows: * asumir que todas las contraseñas del dominio están comprometidas; * forzar un reseteo de contraseña para todas las cuentas de usuario; * resetear todas las cuentas de servicio y de administrador; * si el domain controller quedó operativo, resetear el token KRBTGT dos veces para invalidar todos los tickets Kerberos existentes que los atacantes puedan haber robado
14. Identificar si es posible, y erradicar, el vector de ingreso
15. Considerar la posibilidad de que el atacante aún tenga acceso, y tomar todas las precauciones necesarias
16. El acceso al dominio, y los usuarios administrador deben ser extremadamente limitados, preferentemente configurarles acceso exclusivo desde algunas IPs consideradas “seguras”, y dejar registrado en una knowledge base (KB) cualquier cambio (altas, bajas y modificaciones) para referencia posterior
17. Dejar registrada alta/baja/modificaciones de usuarios en una KB
18. Servidores Windows que no necesiten estar en el dominio, dejarlos fuera de él, por ejemplo réplicas de DBs, backups, etc
19. Los servidores Linux, aunque sean internos sin acceso desde afuera, deberían tener: * root con diferentes contraseñas (evaluar si es suficiente crear una regla mnemotécnica para simplificar las diferencias entre ellas, y si algunos pueden tener contraseñas de root totalmente diferentes); * fail2ban configurado y activado
20. El servicio SSH en los servidores Linux debería estar configurado para permitir el acceso exclusivo de los usuarios especificados, con la regla AllowUser, lo cual evita que se cree algún usuario de prueba (como he visto en algunos servidores) y ese usuario ya por defecto tenga acceso por SSH
21. Identificar servidores críticos (para operación de la empresa, por los datos almacenados, o los servicios prestados) y considerar endurecer las políticas de acceso a los mismos
22. Básicamente, considerar que si algo es “demasiado fácil”, quizá sea inseguro
23. El concepto de seguridad es dinámico, y las políticas de seguridad deben ser integrales, revisadas periódicamente como un todo, evitando nichos y “corralitos” de poder o prejuicios
24. Realizar periódicamente auditorías de seguridad
25. Considerar el acceso por VPN como un potencial vector de acceso muy agresivo. Usuarios y accesos deben ser registrados, y revisados los accesos periódicamente, dando de baja aquellos que sean necesarios. Es recomendable tener una política de vencimiento de los certificados, para obligar a todos los que necesiten acceder a que tengan que renovarlos
26. El acceso desde afuera a puertos internos debe ser registrado y evaluado en cada caso, para lo cual se debe identificar un responsable del/los firewalls, quien llevará a cambio los cambios, documentando y realizando el correspondiente backup previo y posterior
27. Educar al personal técnico y no técnico sobre mejores prácticas tanto de seguridad como de trabajo. Y hacerlo periódicamente, repasando conocimientos y mejorando cada vez, agregando aquellas nuevas consideraciones que sean necesarias
28. Documentar todo lo posible y mejorar la documentación de manera permanente, educando y obligando a los responsables a hacerlo, y mantenerlo actualizado
29. Educar y estimular a los equipos que funcionen como uno solo, colaborando entre sí, y/o cambiando roles para evitar dependencias críticas de alguno de ellos