AXR Informática: documentación

Esta página es de solo lectura. Puedes ver la fuente pero no puedes cambiarla. Pregunta a tu administrador si crees que esto es incorrecto.
====== War Room: procedimiento de emergencias ======


===== Procedimiento maestro de respuesta a emergencias (Datacenter) =====

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.

==== Principios rectores ====

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

===== Fase 1: Detección y declaración de emergencia =====

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

  - **Recepción de Alerta:** La emergencia se detecta (vía monitoreo, alerta física [humo, agua], o reporte de usuario crítico)
  - **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
  - **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)
  - **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.
  - **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í

===== Fase 2: Evaluación y contención =====

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

  - **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")
  - **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
  - **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

===== Fase 3: Erradicación =====

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

  - **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
  - **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

===== Fase 4: Recuperación y verificación =====

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

  - **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
  - **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)
  - **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")

===== Fase 5: Cierre del incidente y monitoreo =====

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

  - **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)
  - **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
  - **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
  - **Cierre de la Sala de Guerra:** Se cierra el //bridge// de conferencia

===== Fase 6: Post mortem (Lecciones aprendidas) =====

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)**.

  - **Agendar la Reunión Post-Mortem:** Invitar al ERT y a los //stakeholders// clave
  - **Revisar la Documentación:** Se analiza la línea de tiempo del incidente (que se debió documentar durante la Fase 2)
  - **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")
  - **Actualizar la documentación:** Los aprendizajes se usan para mejorar //este mismo procedimiento//

===== Puntos Clave para el Sysadmin/Infosec =====

  * **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

===== Otras ideas =====

  - Desconectar la corriente de los switches/gateways/routers en vez de cables de red de servidores
  - Realizar un inventario preliminar de los servidores y servicios comprometidos, para informar y tomar acciones
  - 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
  - Realizar backups remotos, nunca en el propio equipo
  - Realizar backups remotos geográficamente alejados, especialmente de datos críticos para la operación de la empresa
  - Servidores de backup sin acceso desde los servidores de origen
  - 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
  - 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
  - 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
  - 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
  - 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
  - Identificar si es posible, y erradicar, el vector de ingreso
  - Considerar la posibilidad de que el atacante aún tenga acceso, y tomar todas las precauciones necesarias
  - 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
  - Dejar registrada alta/baja/modificaciones de usuarios en una KB
  - Servidores Windows que no necesiten estar en el dominio, dejarlos fuera de él, por ejemplo réplicas de DBs, backups, etc
  - 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
  - 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
  - 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
  - Básicamente, considerar que si algo es "demasiado fácil", quizá sea inseguro
  - 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
  - Realizar periódicamente auditorías de seguridad
  - 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
  - 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
  - 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
  - Documentar todo lo posible y mejorar la documentación de manera permanente, educando y obligando a los responsables a hacerlo, y mantenerlo actualizado
  - 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
AXR Informática: documentación

Herramientas de usuario

Herramientas del sitio

Herramientas de la página
