Respuesta a incidentes
Ransomware: cómo construir un plan de respuesta que funcione bajo presión
Un plan de respuesta a ransomware se juzga el día que se activa. Estas son las decisiones que deben quedar resueltas antes de ese momento.
La mayoría de los planes de respuesta a ransomware fallan no por falta de tecnología, sino porque nunca definieron quién decide. Cuando el cifrado se extiende por la red, cada minuto que se dedica a averiguar quién autoriza una desconexión es un minuto de propagación.
Decisiones que deben estar resueltas de antemano
- Quién puede aislar un segmento de red sin consultar a nadie, y en qué condiciones.
- Qué sistemas son intocables aunque su desconexión tenga costo operativo.
- Cuándo se activa el equipo de crisis y quién convoca a dirección, legal y comunicación.
- Qué se notifica y a quién según el tipo de información comprometida.
- Cómo se paga la operación si los sistemas financieros quedan fuera de línea.
Respaldos: la pregunta correcta
No basta con preguntar si existen respaldos. La pregunta útil es cuándo fue la última restauración completa probada y cuánto tardó. Un respaldo que nunca se restauró es una hipótesis, y las hipótesis no sostienen una recuperación.
Los respaldos deben ser inmutables, estar fuera del dominio de administración comprometido y tener su propia ruta de acceso. Si la credencial que administra los respaldos vive en el mismo directorio que la que fue comprometida, el atacante llegará primero.
Preservar la evidencia durante la contención
Contener rápido y destruir la evidencia son objetivos que suelen entrar en conflicto. La forma de resolverlo es capturar antes de actuar: instantáneas de memoria en los sistemas críticos, exportación de registros y respaldo de las configuraciones afectadas. Esa captura permite reconstruir el alcance del compromiso y cumplir con obligaciones de notificación sin especular.
Simulacros que realmente preparan
Un ejercicio de mesa debe incluir a las personas que tomarían las decisiones reales, con información incompleta y con un reloj corriendo. El valor del simulacro no está en acertar la respuesta, sino en descubrir qué decisión no tenía un responsable claro.
Seguir leyendo
Contenido relacionado
DMARC, DKIM y SPF: guía práctica contra la suplantación de correo
Configurar los registros es el principio. La parte difícil es interpretar los reportes y llegar a una política restrictiva sin detener el negocio.
Cómo reportar un sitio clonado o un correo de phishing (y por qué hacerlo bien importa)
Los datos que acompañan al reporte determinan si un sitio fraudulento desaparece en horas o permanece en línea durante semanas.