Respuesta a incidentes y continuidad de negocio
Objetivos: Al terminar este tema, podrás…
- Aplicar el ciclo NIST SP 800-61 a un incidente real bajo presión
- Tomar decisiones de contención con información incompleta
- Definir RTO y RPO apropiados para los componentes de tu sistema
- Diseñar un protocolo de comunicación de crisis para tu proyecto
Cómo funciona esta clase
Trabajan en grupos de 3 a 4 personas durante toda la clase. A lo largo del escenario van a enfrentar decisiones reales de respuesta a incidentes. Cuando lleguen a una, tienen un tiempo límite para deliberar y comprometerse con una opción; un vocero del grupo la anuncia en voz alta antes de que se revele qué pasó.
Traten esto como una sala de crisis real. Deciden juntos y cargan con las consecuencias.
Son las 2:47 AM
Tu teléfono vibra. Es una alerta de Uptime Robot: el servidor de MicroPréstamos, la app que tu equipo lleva tres meses en producción para una ONG de microfinanzas, está respondiendo con errores 500.
Abres el correo. En los últimos cuarenta minutos llegaron 34 solicitudes de restablecimiento de contraseña. Los usuarios duermen. No hay tráfico legítimo a esta hora.
Tu corazón se acelera. Algo pasó.
Decisión grupal 1 — Los primeros cinco minutos
Tienen 3 minutos.
Son las 2:47 AM. Acaban de ver la alerta y los correos de reseteo. ¿Cuál es su primera acción?
- A) Apagar el servidor inmediatamente
- B) Conectarse e investigar qué pasó antes de tocar nada
- C) Llamar al resto del equipo primero
- D) Notificar a los usuarios que hay un problema
Elijan una. Vocero anuncia.
Consecuencias de cada decisión
A — Apagar el servidor: Cortas cualquier actividad maliciosa activa, pero también destruyes la memoria del proceso (RAM) donde pueden estar artefactos del ataque. Si el servidor se reinicia limpio, perdiste evidencia forense valiosa. Además, si el atacante ya terminó y se fue, apagarlo no sirve de nada y genera downtime innecesario.
B — Investigar primero: Es la decisión correcta si el ataque ya terminó. Pero si hay exfiltración activa en este momento, cada segundo que esperas es más datos saliendo. Necesitas al menos 2 minutos para determinar si hay actividad en curso.
C — Llamar al equipo primero: Útil, pero como acción paralela. Mientras esperas que contesten, puedes estar revisando los logs. El equipo no puede ayudarte si no saben qué está pasando.
D — Notificar usuarios: Demasiado pronto. No sabes qué pasó todavía. Una notificación prematura con información incorrecta genera pánico y obliga a contradicciones después. Primero entiende el incidente, luego comunicas.
La decisión razonable: B mientras activas C en paralelo. Investigas tú, llamas al equipo al mismo tiempo.
¿Qué es un incidente de seguridad?
Un incidente de seguridad es cualquier evento que compromete o amenaza la confidencialidad, integridad o disponibilidad de un sistema de información.
La clasificación por severidad existe precisamente porque la urgencia varía: un evento sospechoso puede requerir monitoreo; una brecha activa requiere respuesta inmediata. Clasificar bien al inicio determina qué tan rápido actúas:
| Severidad | Descripción | Ejemplos | Tiempo de respuesta |
|---|---|---|---|
| Crítica | Compromiso activo de sistemas esenciales o datos sensibles masivos | Ransomware en producción, exfiltración activa de base de datos | Inmediato (minutos) |
| Alta | Compromiso confirmado con potencial de escalación | Cuenta de administrador comprometida, malware en red interna | < 1 hora |
| Media | Actividad sospechosa que requiere investigación | Intentos de acceso inusuales, alertas de detección | < 4 horas |
| Baja | Evento menor sin impacto operacional inmediato | Correo de phishing reportado sin abrir, escaneo de puertos externo | < 24 horas |
Decisión grupal 2 — Clasificar el incidente
Tienen 2 minutos.
Con lo que saben hasta ahora (el servidor respondiendo con errores 500 y 34 correos de reseteo de contraseña), ¿qué severidad le asignan?
- A) Crítica
- B) Alta
- C) Media
- D) Baja
Elijan una y justifiquen en una sola frase. Vocero anuncia.
El análisis
La respuesta correcta depende de información que todavía no tienen, y esa ambigüedad es el punto.
Con solo los síntomas actuales, lo razonable es clasificarla como Alta: hay señales claras de algo anormal pero no se ha confirmado el alcance. Las 34 solicitudes de reseteo no son un patrón normal y los errores del servidor sugieren algo fuera de lo ordinario.
Si al investigar confirman exfiltración activa de datos, sube a Crítica. Si resulta ser un fallo de configuración que disparó falsas alarmas, baja a Media o Baja.
La clasificación inicial guía la velocidad de respuesta, no la define para siempre. Lo importante: clasificar hacia arriba en la duda. Es mejor sobreactuar ante un falso positivo que subestimar un incidente real.
Ciclo de respuesta a incidentes (NIST SP 800-61)
El framework NIST SP 800-61 define cuatro fases para gestionar incidentes. Las fases tienen un orden, pero la información nueva fuerza retrocesos con frecuencia: en la práctica se avanza y se regresa.
Fase 1: Preparación
La fase más importante ocurre antes de cualquier incidente.
Mientras investigan, el equipo de MicroPréstamos descubre varias cosas incómodas:
- No hay un documento de respuesta a incidentes. Nadie sabe exactamente quién hace qué.
- Los logs de acceso a la base de datos están en el mismo servidor comprometido.
- El número de teléfono del administrador de la ONG está en el README del repositorio, que se hizo público por error hace dos semanas.
- El último backup fue hace seis días.
Decisión grupal 3 — La deficiencia más crítica
Tienen 2 minutos.
De las cuatro deficiencias que acaban de descubrir, ¿cuál les parece la más grave en este momento, mientras el incidente está activo?
- A) No hay plan de respuesta documentado
- B) Los logs están en el servidor comprometido
- C) El número del administrador estaba expuesto en el README
- D) El backup tiene seis días de antigüedad
Elijan una. Vocero anuncia.
El análisis
B es la más crítica en este momento. Los logs son evidencia. Si el atacante tuvo acceso root al servidor, puede haberlos modificado o eliminado. Sin logs confiables, la investigación forense arranca ciega: no pueden reconstruir qué pasó, qué datos se accedieron, ni cuándo.
D se convierte en la más crítica en la fase de recuperación. Seis días de transacciones de microfinanzas perdidas significa no saber quién pagó y quién no. Para una ONG, eso puede tener consecuencias muy reales para sus beneficiarios.
A es un problema sistémico que explica por qué están improvisando a las 3 AM.
C es el error que probablemente facilitó el ataque, aunque eso lo descubrirán más adelante.
La preparación efectiva incluye: plan de respuesta escrito, logs en infraestructura separada del servidor de producción, backups probados con intervalo apropiado al RTO/RPO del sistema, y gestión de información sensible.
Fase 2: Detección y análisis
Logran conectarse. El servidor responde. Revisan los logs de aplicación (no los de base de datos, que están comprometidos) y encuentran esto:
[02:03:14] POST /login HTTP/1.1 — 200 OK — 127ms
[02:03:14] POST /login HTTP/1.1 — 200 OK — 4823ms
[02:03:15] POST /login HTTP/1.1 — 200 OK — 5102ms
[02:03:16] GET /admin/export-users HTTP/1.1 — 200 OK
[02:03:18] GET /admin/export-loans HTTP/1.1 — 200 OK
Todas las requests vienen de la misma IP. El ataque ocurrió a las 2:03 AM. La alerta llegó a las 2:47 AM.
Decisión grupal 4 — Triaje de los logs
Tienen 3 minutos.
Tienen estos logs y poco tiempo. No pueden investigar todo a la vez.
¿Qué investigan primero?
- A) La diferencia de tiempos en
/login(127ms vs. 4823ms)- B) Quién hizo las requests a
/admin/export-usersy/admin/export-loans- C) Por qué el ataque ocurrió a las 2:03 AM pero la alerta llegó a las 2:47 AM
- D) De dónde viene la IP que hizo todas las requests
Elijan una y justifiquen en una frase. Vocero anuncia.
El análisis
No hay una respuesta única correcta: depende de qué quieren saber primero. Pero hay una jerarquía:
B es el más urgente para confirmar el alcance del daño. Las exports de usuarios y préstamos son la evidencia más directa de qué datos salieron. Si esas requests tuvieron respuesta 200, los datos fueron exfiltrados. Eso define la severidad del incidente y qué tan rápido deben notificar.
A revela cómo entró el atacante. La diferencia de tiempos en
/logines la firma de una inyección SQL: el atacante manipuló el input para hacer que el servidor esperara artificialmente, confirmando que el input llegaba sin sanitización directo a la base de datos. Entender el vector de entrada es clave para la erradicación (si no cierran esa puerta, el atacante puede volver), pero no cambia lo que ya pasó.C revela un fallo de detección. 44 minutos entre el ataque y la primera alerta significa que el incidente fue detectado por síntomas secundarios (errores 500), no por el ataque en sí. Para cuando llegó la alerta, el daño ya estaba hecho. Importante para el post-mortem, no urgente ahora.
D puede ayudar a bloquear al atacante, pero una IP puede cambiarse en segundos. No es lo más valioso con tiempo limitado.
El punto del ejercicio: en un incidente real, siempre hay más cosas por investigar que tiempo disponible. Triaje es una habilidad, no solo técnica.
Fase 3: Contención, erradicación y recuperación
Son las 3:15 AM. Ya saben que hubo un dump de la base de datos. El atacante probablemente ya tiene los datos. Tienen que tomar decisiones rápidas con información incompleta.
Decisión grupal 5 — ¿Desconectan el servidor?
Tienen 3 minutos.
Saben que el ataque terminó hace más de una hora. El atacante ya se fue. El sistema sigue online y algunos usuarios nocturnos podrían estar activos.
- A) Desconectar el servidor de internet inmediatamente
- B) Mantenerlo online mientras terminan la investigación
- C) Desconectar solo la base de datos, dejar el frontend activo
Elijan una. Vocero anuncia.
Consecuencias de cada decisión
A — Desconectar de internet: Protege a los usuarios de cualquier actividad residual, pero interrumpe el servicio. Si el atacante dejó una puerta trasera y está monitoreando, le avisas que lo detectaste.
B — Mantenerlo online: Permite terminar la investigación sin interrumpir el servicio. Pero los datos de usuarios siguen expuestos si quedó algún vector activo, y los usuarios del sistema no saben que sus datos están comprometidos.
C — Desconectar solo la DB: Corta el acceso a datos pero deja el frontend activo. El problema es que el frontend sin base de datos probablemente genera más errores visibles, y no protege contra vectores que no pasan por la DB.
La decisión razonable: A, con un matiz técnico. No apagar el servidor (se pierde RAM y logs del OS), sino desconectarlo de la red externa. Contención a corto plazo: aislar sin destruir evidencia.
Decisión grupal 6 — ¿Fuerzan cambio de contraseñas ahora?
Tienen 2 minutos.
Los datos de usuarios fueron exfiltrados, incluyendo contraseñas hasheadas. Son las 3:30 AM.
- A) Forzar reseteo de todas las contraseñas ahora mismo
- B) Esperar hasta las 8 AM para hacer el reseteo con una comunicación clara
Elijan una. Vocero anuncia.
El análisis
No hay respuesta perfecta, pero los factores son claros:
A ahora: Los hashes comprometidos pueden crackearse offline: el atacante puede estar intentándolo en este momento. Cada hora que pasa sin reseteo es tiempo para que las credenciales se usen. El impacto en usuarios de una ONG a las 3 AM es bajo (pocos activos).
B a las 8 AM: Da tiempo para preparar una comunicación clara y no alarmar a usuarios con un reseteo inesperado en medio de la noche. Pero son 4 horas de ventana para que el atacante use credenciales crackeadas.
La regla general: Si las credenciales están confirmadamente comprometidas, el reseteo es inmediato. La incomodidad del usuario es un precio aceptable frente al riesgo de uso de credenciales robadas.
Después de decidir sobre las contraseñas, queda la pregunta de recuperación:
| Opción | Ventajas | Riesgos |
|---|---|---|
| Restaurar desde backup | Estado limpio garantizado | Se pierden 6 días de datos; ¿el backup también fue comprometido? |
| Limpiar el servidor comprometido | No se pierden datos | ¿Encontraron todo lo que dejó el atacante? |
| Nuevo servidor + restaurar datos | Estado limpio + datos recuperados | Requiere más tiempo, pero es el enfoque más seguro |
Fase 4: Actividad post-incidente
Son las 10 AM. El sistema está restaurado, los usuarios notificados, la vulnerabilidad parcheada. El equipo lleva siete horas despierto.
Esta es la fase que más organizaciones omiten, y la que más valor aporta. El post-mortem reconstruyó la línea de tiempo completa:
- 01:58 AM — El atacante empieza a sondear
/login - 02:03 AM — Inyección SQL exitosa, dump de tabla de usuarios
- 02:04 AM — Login como administrador con credenciales del dump
- 02:04–02:06 AM — Exportación de datos de usuarios y préstamos
- 02:06 AM — El atacante se desconecta
- 02:47 AM — Primera alerta (errores 500)
La causa técnica es clara: el endpoint /login construía queries concatenando strings con el input del usuario, sin parametrización.
Decisión grupal 7 — La causa raíz real
Tienen 3 minutos.
La causa técnica es SQL injection por falta de parametrización. Pero el post-mortem busca la causa sistémica: por qué eso llegó a producción.
¿Cuál creen que es la causa raíz del sistema?
- A) El desarrollador que escribió esa query no conocía las mejores prácticas
- B) No hubo revisión de seguridad antes del despliegue a producción
- C) No había testing automatizado que detectara vulnerabilidades comunes
- D) No hubo monitoreo que detectara el ataque en tiempo real
Elijan la que consideran más importante. Vocero anuncia y justifica.
El análisis
Todas son causas reales, pero tienen jerarquía diferente.
A es la más débil como causa sistémica. Si el proceso depende de que cada desarrollador tenga conocimiento perfecto de seguridad en todo momento, el proceso está mal diseñado. Las personas cometen errores.
B y C son causas sistémicas sólidas. Una revisión de seguridad antes del despliegue, o un scanner automático de vulnerabilidades en el pipeline CI/CD, habría detectado la inyección antes de que llegara a producción. Esto es defensa en profundidad aplicada al proceso de desarrollo.
D no habría prevenido el incidente pero habría reducido el daño de 44 minutos a minutos. Los 44 minutos de ventana entre el ataque y la alerta son el resultado directo de no tener detección activa.
La cultura blameless importa aquí: si el post-mortem busca al culpable que escribió la query insegura, el equipo aprende a esconder errores. Si busca “¿cómo llegó esto a producción sin que nadie lo detectara?”, el equipo mejora sus procesos.
Comunicación durante la crisis
La comunicación mal manejada puede causar más daño que el incidente mismo.
Decisión grupal 8 — El orden de las llamadas
Tienen 2 minutos.
Son las 3:30 AM. Tienen en la lista: el CTO del equipo, la directora de la ONG, los 200 usuarios del sistema, y la SIC.
¿En qué orden los contactan, y qué les dicen en este momento?
Definan el orden. Vocero anuncia.
El análisis
Orden típico:
- Equipo técnico — inmediatamente, con todos los detalles técnicos. Son quienes contienen el incidente.
- Dirección/CTO — tan pronto se confirme el incidente, con impacto en negocio. Necesitan tomar decisiones que van más allá del equipo técnico.
- Cliente (la ONG) — cuando haya una comprensión estable de qué pasó. No antes: si llamas sin saber qué decir, generas pánico sin poder dar respuestas.
- Usuarios afectados — cuando las instrucciones estén claras. “Hubo un incidente, cambien su contraseña en este link.”
- SIC — según la Ley 1581 de 2012, hay obligación de notificar cuando se comprometen datos personales. MicroPréstamos manejaba nombres, identificaciones y datos financieros, lo que califica. No notificar puede agravar significativamente las sanciones.
Regla de oro: Comunica lo que sabes, reconoce lo que no sabes, no especules. “Detectamos un acceso no autorizado. Los datos afectados son X. Las acciones que tomamos son Y. Actualizamos en Z horas.” Es mejor que silencio o que una declaración prematura que luego debes contradecir.
Comunicación con usuarios
| Momento | Qué comunicar | Qué NO hacer |
|---|---|---|
| Inmediatamente | Que hay un incidente en investigación, que tomen precauciones | Dar detalles técnicos, especular sobre el alcance |
| Cuando tengas claridad | Qué datos se vieron afectados, qué deben hacer | Minimizar o suavizar la realidad |
| Post-resolución | Qué pasó, qué se hizo, qué cambió para que no vuelva a pasar | Desaparecer sin cierre |
RTO y RPO: los números que definen tu estrategia
Uno de los aprendizajes más concretos del incidente de MicroPréstamos fue el backup de seis días. Nadie eligió hacer backups cada seis días. Simplemente nadie eligió.
RTO (Recovery Time Objective): ¿Cuánto tiempo puede estar el sistema caído antes de que el daño sea inaceptable?
RPO (Recovery Point Objective): ¿Cuántos datos puedes perder? ¿Qué tan atrás en el tiempo puedes restaurar?
| Sistema | RTO | RPO | Implicación técnica |
|---|---|---|---|
| Portal de e-commerce | 1 hora | 0 minutos | Alta disponibilidad + replicación en tiempo real |
| Sistema de nómina | 24 horas | 4 horas | Backup cada 4 horas + servidor de respaldo |
| Wiki interna | 72 horas | 24 horas | Backup diario, restauración puede esperar |
| MicroPréstamos (sin política) | Sin definir | 6 días | Backup semanal, sin decisión explícita |
RTO y RPO más agresivos cuestan más. Un RTO de cero requiere infraestructura redundante activa en paralelo. La decisión no es solo técnica. Es de negocio. Pero si no la tomas explícitamente, alguien la tomó por omisión.
La regla 3-2-1
Una estrategia de backup efectiva:
- 3 copias de los datos (el original + 2 backups)
- 2 tipos de medio diferentes (disco local + nube)
- 1 copia fuera del sitio (offsite, protegida contra desastres físicos)
Backups y ransomware: Si los backups están en la misma red que el servidor comprometido, el ransomware también los cifra. Al menos una copia debe estar aislada.
Dos maneras de responder a un incidente
Maersk/NotPetya 2017: reconstrucción bajo presión
En junio de 2017, el malware NotPetya se propagó globalmente. Maersk, la naviera más grande del mundo, perdió en horas casi toda su infraestructura: 49.000 laptops, 3.500 servidores, toda su red de Active Directory.
Lo que hizo Maersk:
- Reconstruyó toda la infraestructura en 10 días (proceso que normalmente toma 6 meses)
- Recuperó su controlador de dominio gracias a un único servidor en Ghana que estaba offline por un corte de luz
- Operó puertos con WhatsApp y hojas de cálculo mientras se reconstruía el sistema
- El CEO explicó públicamente el impacto con transparencia
Costo: ~$300 millones USD.
Para discutir
- El servidor de Ghana salvó la recuperación. ¿Fue suerte o hay un principio de diseño detrás?
- Maersk operó “manualmente” durante la crisis. ¿Tu sistema tiene un modo de operación manual?
- ¿Qué habría pasado si el CEO hubiera guardado silencio?
Equifax 2017: lo que no debes hacer
Equifax expuso datos de 147 millones de personas. La cronología de su respuesta:
- La vulnerabilidad tenía parche disponible dos meses antes del ataque
- Tardaron 76 días en descubrir la brecha
- Tardaron 40 días más en notificar al público
- Ejecutivos vendieron acciones entre el descubrimiento y la notificación pública
- El sitio creado para verificar si eras afectado tenía su propia vulnerabilidad XSS
Costo: ~$1.400 millones USD.
Para discutir
- 76 días sin detectar una brecha activa. ¿Qué tipo de monitoreo habría hecho la diferencia?
- ¿Qué tienen en común los errores de Equifax y los de MicroPréstamos? ¿Qué los diferencia?
Conceptos clave
| Término | Definición |
|---|---|
| Incidente de seguridad | Evento que compromete la confidencialidad, integridad o disponibilidad de un sistema |
| RTO | Tiempo máximo aceptable para restaurar un servicio después de una interrupción |
| RPO | Cantidad máxima aceptable de datos que se pueden perder en un incidente |
| Plan de respuesta | Documento que define procedimientos, roles y comunicaciones para gestionar incidentes |
| Análisis post-mortem | Revisión estructurada después de un incidente para identificar causas sistémicas y lecciones aprendidas |
| Continuidad de negocio | Capacidad de mantener operaciones esenciales durante y después de un incidente |