Respuesta a incidentes y continuidad de negocio

Objetivos: Al terminar este tema, podrás…

Clasificar incidentes de seguridad por severidad y tipo

Diseñar un plan de respuesta a incidentes basado en el ciclo NIST SP 800-61

Definir objetivos de recuperación (RTO/RPO) apropiados para distintos sistemas

Planificar la comunicación durante una crisis de seguridad

Cuando la prevención no es suficiente

A lo largo del curso has aprendido a diseñar controles que previenen ataques: cifrado, validación de entradas, control de acceso, MFA. Pero la realidad es que ningún sistema es invulnerable. Los atacantes descubren zero-days, los empleados cometen errores, las configuraciones tienen fallos que nadie anticipó.

Lo que separa a las organizaciones que sobreviven un incidente de las que no, no es si fueron atacadas — es qué tan preparadas estaban para responder.

Un equipo sin plan improvisa bajo presión, toma malas decisiones y convierte un incidente manejable en una catástrofe. Un equipo preparado contiene el daño, comunica con claridad y aprende del incidente para fortalecerse.

¿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.

No todo evento sospechoso es un incidente, y no todo incidente es una emergencia. La clasificación por severidad permite priorizar la respuesta:

Clasificación por severidad

Severidad	Descripción	Ejemplos	Tiempo de respuesta
Crítica	Compromiso activo de sistemas esenciales o datos sensibles masivos	Ransomware en servidores de producción, exfiltración de base de datos de clientes	Inmediato (minutos)
Alta	Compromiso confirmado con potencial de escalación	Cuenta de administrador comprometida, malware detectado en red interna	< 1 hora
Media	Actividad sospechosa que requiere investigación	Intentos de acceso inusuales, alerta de herramienta de detección	< 4 horas
Baja	Evento menor sin impacto operacional inmediato	Correo de phishing reportado (no abierto), escaneo de puertos externo	< 24 horas

Ciclo de respuesta a incidentes (NIST SP 800-61)

El framework NIST SP 800-61 define cuatro fases para gestionar incidentes de seguridad. No es un proceso lineal: frecuentemente se vuelve a fases anteriores a medida que se descubre nueva información.

Fase 1: Preparación

La fase más importante ocurre antes de cualquier incidente.

Actividad	Descripción
Plan de respuesta documentado	Procedimientos escritos para distintos tipos de incidentes
Equipo de respuesta definido	Roles claros: quién lidera, quién comunica, quién ejecuta técnicamente
Herramientas listas	Acceso a logs, herramientas de análisis forense, canales de comunicación alternos
Contactos actualizados	Lista de contactos internos (legal, dirección, TI) y externos (CERT, autoridades, proveedores)
Simulacros regulares	Ejercicios de mesa (tabletop) para practicar la respuesta sin presión real
Backups verificados	Copias de seguridad probadas — un backup que no se ha restaurado no es un backup

Pregunta clave: Si mañana descubrieras un ransomware en tu servidor principal, ¿sabrías exactamente qué hacer en los primeros 30 minutos?

Fase 2: Detección y análisis

El objetivo es confirmar si realmente hay un incidente, entender su alcance y determinar la severidad.

Actividad	Preguntas clave
Confirmar el incidente	¿Es un falso positivo o un incidente real?
Determinar el alcance	¿Qué sistemas están afectados? ¿Se está expandiendo?
Identificar el vector	¿Cómo entró el atacante? ¿Phishing, vulnerabilidad, credenciales robadas?
Evaluar el impacto	¿Qué datos están comprometidos? ¿Qué servicios están caídos?
Documentar todo	Registrar cada hallazgo con timestamps — será crucial para el análisis posterior

Errores comunes:

Asumir que el primer indicador es el único (a menudo hay compromiso más profundo)
No documentar las acciones tomadas durante la respuesta
Alertar al atacante antes de estar listos para contener

Fase 3: Contención, erradicación y recuperación

Etapa	Actividad	Ejemplo
Contención a corto plazo	Detener la propagación inmediata	Aislar el servidor comprometido de la red
Contención a largo plazo	Aplicar controles temporales mientras se investiga	Redirigir tráfico a servidor limpio, cambiar credenciales comprometidas
Erradicación	Eliminar la causa raíz	Eliminar malware, cerrar la vulnerabilidad explotada, revocar accesos comprometidos
Recuperación	Restaurar operaciones normales	Restaurar desde backup limpio, monitorear para reinfección, validar integridad

Decisión crítica: ¿desconectar inmediatamente?

Sí si hay exfiltración activa de datos o ransomware propagándose
No necesariamente si necesitas observar al atacante para entender el alcance completo
Siempre depende del contexto y la severidad

Fase 4: Actividad post-incidente

Esta fase es la que más organizaciones omiten — y la que más valor aporta.

Actividad	Propósito
Análisis post-mortem	Reconstruir la línea de tiempo completa del incidente
Identificar causa raíz	No solo “qué pasó” sino “por qué pudo pasar”
Lecciones aprendidas	¿Qué funcionó? ¿Qué falló? ¿Qué hay que cambiar?
Actualizar controles	Implementar cambios para prevenir incidentes similares
Actualizar el plan	Incorporar lo aprendido al plan de respuesta

Cultura blameless (sin culpa): El post-mortem no busca culpables. Busca fallos sistémicos. Si un empleado cayó en phishing, la pregunta no es “¿por qué fue tan ingenuo?” sino “¿por qué nuestros filtros no detectaron el correo?” y “¿por qué una sola credencial daba acceso a datos críticos?”

Comunicación durante incidentes

La comunicación mal manejada puede causar más daño que el incidente mismo.

Comunicación interna

¿Quién?	¿Qué comunicar?	¿Cuándo?
Equipo de respuesta	Detalles técnicos completos	Inmediatamente
Dirección/gerencia	Impacto en negocio, decisiones necesarias	Tan pronto como se confirme el incidente
Empleados afectados	Qué deben hacer (cambiar contraseñas, no usar cierto sistema)	Cuando las instrucciones estén claras
Resto de la organización	Comunicado general sin detalles técnicos excesivos	Cuando se tenga una comprensión estable

Comunicación externa

¿Quién?	Consideraciones
Clientes/usuarios afectados	Obligación legal en muchos casos (Ley 1581 en Colombia), transparencia sobre qué datos se comprometieron
Autoridades	SIC en Colombia si hay datos personales comprometidos, Policía si hay delito
Medios de comunicación	Comunicado preparado, vocero designado, no improvisar
Socios y proveedores	Si el incidente puede afectarlos o si fueron el vector de entrada

Regla de oro: Comunica lo que sabes, reconoce lo que no sabes, y no especules. “Estamos investigando” es mejor que una declaración prematura que luego contradices.

Obligaciones legales

Recuerda lo que viste en el tema anterior: la Ley 1581 de 2012 exige notificar a la SIC y a los titulares cuando se produce una brecha que afecta datos personales. No notificar puede agravar las sanciones significativamente.

Continuidad de negocio

RTO y RPO: los números que definen tu estrategia

Concepto	Significado	Pregunta que responde
RTO (Recovery Time Objective)	Tiempo máximo aceptable para restaurar un servicio	¿Cuánto tiempo puedes estar caído?
RPO (Recovery Point Objective)	Cantidad máxima aceptable de datos que puedes perder	¿Cuántos datos puedes perder?

Ejemplo concreto:

Sistema	RTO	RPO	Implicación
Portal de e-commerce	1 hora	0 minutos	Requiere alta disponibilidad y replicación en tiempo real
Sistema de nómina	24 horas	4 horas	Backup cada 4 horas, servidor de respaldo que puede activarse en un día
Wiki interna	72 horas	24 horas	Backup diario, restauración puede esperar
Archivo histórico	1 semana	1 semana	Backup semanal, baja prioridad de restauración

Punto clave: RTO y RPO más agresivos cuestan más dinero. Un RTO de 0 (cero downtime) requiere infraestructura redundante en tiempo real. La decisión no es solo técnica — es de negocio.

Estrategias de backup: la regla 3-2-1

Una estrategia de backup efectiva sigue la regla 3-2-1:

3 copias de los datos (el original + 2 backups)
2 tipos de medio diferentes (disco local + nube, por ejemplo)
1 copia fuera del sitio (offsite, protegida contra desastres físicos)

Backups y ransomware: Si tus backups están conectados a la misma red que tus servidores, el ransomware también los cifrará. Al menos una copia debe estar aislada (air-gapped o en almacenamiento inmutable).

Disaster Recovery vs. Business Continuity

Aspecto	Disaster Recovery (DR)	Business Continuity (BC)
Enfoque	Restaurar la infraestructura técnica	Mantener las operaciones del negocio
Alcance	Sistemas, datos, redes	Procesos, personas, comunicación
Pregunta	¿Cómo restauramos los servidores?	¿Cómo seguimos operando mientras los restauramos?
Ejemplo	Restaurar base de datos desde backup	Procesar pedidos manualmente mientras se restaura el sistema

Casos de estudio

Maersk/NotPetya 2017: reconstrucción total bajo presión

¿Qué pasó? En junio de 2017, el malware NotPetya — diseñado como arma cibernética contra Ucrania — se propagó globalmente. Maersk, la naviera más grande del mundo, fue una de las víctimas más afectadas. En cuestión de horas, casi toda su infraestructura IT quedó inutilizada: 49.000 laptops, 3.500 servidores, toda la red de Active Directory.

La respuesta:

Maersk reconstruyó toda su infraestructura en 10 días — un proceso que normalmente tomaría 6 meses
Recuperaron su controlador de dominio gracias a un único servidor en Ghana que estaba desconectado por un corte de luz
Durante la crisis, gestionaron operaciones portuarias usando WhatsApp y hojas de cálculo
La comunicación fue transparente: el CEO explicó públicamente el impacto

Costo: ~$300 millones USD

Lecciones de ingeniería:

Un solo servidor offline salvó la recuperación — la diversidad geográfica y de medios importa
La segmentación de red habría limitado la propagación
Los planes de continuidad manuales (operar sin sistemas) son tan importantes como los técnicos
La comunicación transparente durante la crisis preservó la confianza de los clientes

Equifax 2017: cómo NO responder a un incidente

¿Qué pasó? Equifax, una de las tres grandes agencias de crédito de EE.UU., sufrió una brecha que expuso datos personales de 147 millones de personas: números de seguridad social, fechas de nacimiento, direcciones, números de licencia de conducir.

La respuesta (todo lo que NO debes hacer):

La vulnerabilidad explotada (Apache Struts) tenía un parche disponible dos meses antes del ataque
Equifax tardó 76 días en descubrir la brecha (la detección falló)
Tardó 40 días más en notificar al público
Ejecutivos vendieron acciones entre el descubrimiento y la notificación pública
El sitio web creado para verificar afectados tenía su propia vulnerabilidad XSS
La respuesta al cliente fue caótica: largas esperas, información contradictoria

Costo: ~$1.400 millones USD (multas, compensaciones, costos legales)