22. Respuesta ante incidentes: contención, bloqueo, erradicación, recuperación y aprendizaje

22.1 Introducción

Incluso con buenos firewalls, IDS/IPS y hardening, los incidentes pueden ocurrir. Una credencial puede ser robada, un servicio puede tener una vulnerabilidad, una regla puede estar mal configurada o un usuario puede ejecutar malware.

La respuesta ante incidentes busca actuar con rapidez, pero también con orden. Una acción improvisada puede destruir evidencia, cortar servicios críticos o dejar al atacante con otro camino de acceso.

En este tema veremos las fases principales de respuesta y cómo se relacionan con los controles defensivos estudiados durante el curso.

22.2 Qué es un incidente

Un incidente de seguridad es un evento confirmado o altamente probable que afecta, o puede afectar, la confidencialidad, integridad, disponibilidad o control de los sistemas y datos.

Ejemplos:

• Compromiso de una cuenta administrativa.
• Explotación de un servicio expuesto.
• Malware en una estación de trabajo.
• Movimiento lateral entre servidores.
• Exfiltración de datos.
• Cambio no autorizado en reglas de firewall.
• Acceso indebido a una base de datos.

22.3 Fases de respuesta

Existen muchos modelos de respuesta, pero para este curso usaremos una secuencia simple y práctica.

22.4 Preparación

La respuesta empieza antes del incidente. Si durante la emergencia no hay accesos, contactos, respaldos, logs o procedimientos, se pierde tiempo valioso.

Preparación mínima:

• Playbooks para escenarios comunes.
• Contactos de redes, sistemas, seguridad, aplicaciones y negocio.
• Acceso a logs de firewall, IDS/IPS, EDR, SIEM y servidores.
• Procedimientos de bloqueo y aislamiento.
• Respaldos probados.
• Inventario de activos críticos.
• Canales de comunicación alternativos.

22.5 Detección y análisis

En esta fase se busca entender qué ocurrió. La prioridad es confirmar si la alerta representa un incidente, qué activos están afectados y qué tan amplio es el alcance.

Fuentes útiles:

• Alertas IDS/IPS.
• Logs de firewall.
• Eventos EDR.
• Logs de autenticación.
• NetFlow o flujos de red.
• Logs de aplicaciones y servidores.
• Eventos de nube o identidad.

Preguntas clave: cuál fue el origen, qué activo fue afectado, qué usuario estuvo involucrado, qué conexiones ocurrieron y qué acciones se ejecutaron.

22.6 Alcance del incidente

Determinar alcance evita responder solo al síntoma visible. Un equipo infectado puede ser solo una parte del problema si ya hubo movimiento lateral o robo de credenciales.

Aspectos a revisar:

• Activos afectados.
• Cuentas usadas.
• Conexiones internas y externas.
• Servicios explotados.
• Datos accedidos o transferidos.
• Cambios de configuración.
• Persistencia o accesos creados.

22.7 Contención

La contención busca limitar el daño mientras se investiga y corrige. Puede ser temporal o permanente, y debe equilibrar seguridad con continuidad operativa.

Acciones de contención:

• Aislar un endpoint mediante EDR.
• Bloquear una IP o dominio malicioso.
• Deshabilitar una cuenta comprometida.
• Cortar una sesión VPN.
• Restringir tráfico entre segmentos.
• Despublicar temporalmente un servicio vulnerable.
• Aplicar una regla de firewall de emergencia.

22.8 Bloqueo con firewalls e IPS

Firewalls e IPS suelen ser herramientas clave para contención. Permiten bloquear orígenes, destinos, puertos, dominios, aplicaciones o patrones de ataque.

Buenas prácticas al bloquear:

• Definir alcance exacto del bloqueo.
• Evitar reglas demasiado amplias si no son necesarias.
• Registrar la acción y el motivo.
• Definir si el bloqueo es temporal o permanente.
• Monitorear impacto operativo.
• Revisar si el atacante cambia de origen o técnica.

22.9 Preservación de evidencia

Durante una respuesta, algunas acciones pueden destruir evidencia. Por ejemplo, reinstalar un equipo inmediatamente puede eliminar logs, procesos, archivos temporales o artefactos útiles.

Evidencias a preservar:

• Logs de firewall, IDS/IPS, EDR y SIEM.
• Memoria o estado del sistema si el caso lo requiere.
• Archivos sospechosos.
• Comandos ejecutados.
• Conexiones de red.
• Cambios de configuración.
• Usuarios y sesiones activas.

22.10 Erradicación

Erradicar significa eliminar la causa del incidente y los mecanismos que permitirían al atacante volver. No alcanza con bloquear una IP si el servidor sigue vulnerable o la credencial sigue comprometida.

Acciones posibles:

• Aplicar parches.
• Eliminar malware o reinstalar sistemas cuando corresponda.
• Rotar credenciales.
• Eliminar cuentas o accesos creados por el atacante.
• Corregir reglas de firewall o permisos.
• Endurecer servicios vulnerables.
• Actualizar firmas IDS/IPS.
• Corregir configuraciones inseguras.

22.11 Recuperación

Recuperar no es simplemente encender sistemas. Es volver a operar con seguridad razonable.

Durante recuperación conviene:

• Restaurar desde respaldos confiables si es necesario.
• Validar integridad de sistemas.
• Aplicar parches antes de exponer nuevamente.
• Revisar reglas y accesos.
• Monitorear actividad posterior.
• Confirmar que alertas funcionan.
• Comunicar estado a responsables.

22.12 Aprendizaje posterior

Después del incidente, la organización debe aprender. Esta fase busca responder qué falló, qué funcionó y qué debe mejorar.

Preguntas útiles:

• ¿Cómo ocurrió el incidente?
• ¿Qué control lo detectó?
• ¿Qué control debería haberlo prevenido?
• ¿La respuesta fue rápida?
• ¿Hubo logs suficientes?
• ¿Faltó segmentación o hardening?
• ¿Qué reglas, playbooks o alertas deben ajustarse?

22.13 Línea de tiempo

Una línea de tiempo ordena los eventos del incidente. Ayuda a entender secuencia, impacto y decisiones.

22.14 Comunicación durante incidentes

La comunicación es parte de la respuesta. Debe ser clara, precisa y controlada. No todos necesitan todos los detalles técnicos, pero los equipos correctos deben recibir información suficiente para actuar.

Buenas prácticas:

• Definir responsable de coordinación.
• Usar canales acordados.
• Separar comunicación técnica de comunicación ejecutiva.
• Registrar decisiones importantes.
• Evitar suposiciones no confirmadas.
• Actualizar estado en intervalos definidos.

22.15 Ejemplo práctico: servidor web explotado

Una aplicación web pública recibe una alerta IPS de explotación. Luego el EDR informa ejecución de un proceso sospechoso en el servidor.

Respuesta posible:

1. Confirmar alerta y revisar logs del WAF, firewall y servidor.
2. Contener: bloquear origen, limitar tráfico o retirar temporalmente el servicio.
3. Preservar evidencia del servidor.
4. Identificar vulnerabilidad explotada.
5. Aplicar parche o mitigación.
6. Revisar si hubo movimiento lateral.
7. Restaurar operación con monitoreo reforzado.
8. Actualizar reglas, hardening y playbook.

22.16 Ejemplo práctico: estación con malware

Una estación de usuario genera conexiones a dominios sospechosos y escaneo interno. El IDS alerta y el EDR marca un proceso malicioso.

Respuesta posible:

• Aislar la estación con EDR.
• Bloquear dominios o IP relacionados.
• Revisar credenciales usadas en el equipo.
• Buscar conexiones laterales desde ese origen.
• Eliminar malware o reinstalar según severidad.
• Restablecer credenciales si hubo riesgo.
• Validar que no quedan señales de persistencia.

22.17 Errores frecuentes

• Actuar sin confirmar alcance: puede dejar partes del incidente activas.
• Borrar evidencia demasiado pronto: dificulta entender lo ocurrido.
• Bloquear de forma excesiva: puede afectar operación sin resolver la causa.
• No rotar credenciales: permite que el atacante vuelva.
• Recuperar sin parchear: expone nuevamente el mismo vector.
• No documentar decisiones: complica auditoría y aprendizaje.
• No hacer post-incidente: se repiten las mismas fallas.

22.18 Lista de verificación inicial

• Confirmar alerta y clasificar severidad.
• Identificar activos, usuarios y servicios afectados.
• Preservar logs y evidencia relevante.
• Aplicar contención proporcional al riesgo.
• Documentar bloqueos y cambios de emergencia.
• Buscar movimiento lateral o persistencia.
• Eliminar causa raíz.
• Recuperar sistemas con validación.
• Monitorear después de recuperar.
• Realizar análisis post-incidente y mejorar controles.

22.19 Ideas clave para recordar

• Respuesta ante incidentes requiere preparación previa.
• Contener no es lo mismo que erradicar.
• Firewalls e IPS ayudan a bloquear, pero deben usarse con alcance claro.
• Preservar evidencia permite entender causa e impacto.
• Recuperar implica volver a operar de forma segura.
• El aprendizaje posterior fortalece reglas, hardening, alertas y procesos.

22.20 Conclusión

La respuesta ante incidentes conecta todos los controles del curso: firewalls, IDS/IPS, hardening, logs, SIEM, EDR y validación. Su objetivo es reducir impacto, eliminar la causa y mejorar la defensa para el futuro.

En el próximo tema estudiaremos operación continua: mantenimiento, documentación, indicadores y revisión periódica.