Por qué el ransomware es un riesgo crítico para empresas
En Chile, muchas empresas han avanzado rápido en digitalización: facturación electrónica, e-commerce, herramientas en la nube, ERP, sistemas de despacho, WhatsApp Business, pasarelas de pago, etc. Ese avance es positivo, pero trae un costo: más puntos de exposición.
Un ransomware típico busca lo mismo en cualquier empresa:
- Detener la operación: cifran servidores, PCs, carpetas compartidas o ambientes cloud.
- Presionar con el tiempo: “paga antes de X horas o subimos el rescate / filtramos datos”.
- Aumentar el daño: además de cifrar, muchas bandas filtran información (clientes, nóminas, contratos, datos contables).
En el mundo real, el impacto suele verse así:
- El equipo de ventas no puede emitir cotizaciones o acceder a CRM.
- Contabilidad se queda sin acceso a facturas, pagos o conciliaciones.
- Logística se frena por caída de WMS/ERP o rutas de despacho.
- Atención al cliente se satura y se daña la confianza.
- En e-commerce: catálogo caído, checkout fallando, pedidos perdidos, reembolsos.
La diferencia entre un “día malo” y una crisis suele depender de una sola cosa: si existe (o no) un plan IRP preparado antes del incidente.
¿Qué es un IRP y qué NO es?
Un IRP (Incident Response Plan) es un plan práctico para responder a un incidente de seguridad. No es un documento “para cumplir”, sino una guía de acción que responde preguntas como:
- ¿Quién manda y quién ejecuta?
- ¿Cómo aislamos el ataque sin apagar todo a ciegas?
- ¿Qué sistemas se priorizan para volver a operar?
- ¿Cómo nos comunicamos con clientes, proveedores y equipo interno?
- ¿Cuándo se debe involucrar asesoría legal / seguros / especialistas externos?
- ¿Cómo recuperamos datos de manera segura?
Lo que NO es un IRP
- No es un “manual técnico” solo para informáticos.
- No es una lista de herramientas (“compra X y listo”).
- No es algo que se redacta una vez y se guarda.
Un IRP sirve cuando está claro, corto, accionable y ensayado.
Preparación mínima antes del ataque (lo que hace que el IRP funcione)
Antes de entrar al plan en 10 pasos, hay 4 bases que hacen la diferencia. Si no están, el IRP se vuelve lento y confuso:
-
Inventario básico de activos
Qué equipos, servidores, sistemas cloud, cuentas y proveedores son críticos. -
Mapa de “sistemas vitales” del negocio
Ejemplo típico en Chile:- ERP/Contabilidad (facturación, pagos, compras)
- Correo corporativo (M365/Google)
- E-commerce / sitio web
- CRM / atención al cliente
- Archivos compartidos (contratos, RR.HH., propuestas)
- Integraciones (pasarela de pago, courier, facturación electrónica)
-
Respaldos con recuperación probada
No basta con “tener backup”. Debes saber:- qué se respalda,
- cada cuánto,
- dónde,
- y cuánto se demora en restaurar.
-
Contactos y accesos de emergencia
En crisis, nadie quiere buscar contraseñas en una planilla perdida. Define:- responsable interno,
- proveedor TI,
- contacto cloud,
- contacto legal (si aplica),
- y un canal alternativo al correo (porque puede estar comprometido).
Con eso listo, ahora sí: el IRP.
Plan de respuesta a ransomware en 10 pasos (IRP práctico)
A continuación tienes el flujo recomendado. No necesitas ser técnico para entenderlo, pero sí necesitas asignar responsables.
Tip clave: cada paso debe tener un “dueño”. En incidentes, el peor enemigo es el “nadie sabe quién decide”.
Paso 1: Declarar el incidente y activar el “modo crisis”
Objetivo: reconocer rápidamente que es grave y activar el plan.
Responsable: líder designado (gerencia u operaciones) + encargado TI/proveedor.
Qué hacer:
- Confirmar señales típicas: archivos con extensión rara, notas de rescate, equipos lentos, accesos bloqueados, alertas de seguridad, carpetas compartidas inaccesibles, cambios masivos de nombre de archivos.
- Definir un “war room” (virtual o físico) con un canal alternativo: teléfono, WhatsApp, Teams desde cuentas seguras, etc.
- Nombrar un Incident Commander (IC): una persona que coordina.
Ejemplo en una empresa de distribución:
Si el ERP se cae y bodegas no pueden despachar, se activa el IRP aunque “no sepamos aún” qué pasó. El tiempo perdido por dudas es carísimo.
Paso 2: Contener rápido (aislar para que no se propague)
Objetivo: frenar el avance del ransomware.
Responsable: TI interno o proveedor.
Qué hacer (acciones de alto impacto):
- Aislar equipos sospechosos de la red (desconectar WiFi/ethernet) sin formatear.
- Deshabilitar accesos remotos sospechosos (VPN/RDP/anydesk si está expuesto).
- Si hay indicios en un servidor, aislarlo también.
- Restringir cuentas comprometidas (bloquear usuario, reset de credenciales, cerrar sesiones).
Errores comunes a evitar:
- “Apagar todo” sin registro: puede borrar evidencia útil.
- Formatear de inmediato: pierdes pistas para entender el vector de entrada.
Paso 3: Evaluar alcance e impacto (qué está comprometido y qué no)
Objetivo: dimensionar el daño y priorizar decisiones.
Responsable: TI + líder de negocio.
Qué levantar en 60–120 minutos:
- ¿Qué sistemas están cifrados? (PCs, servidor de archivos, ERP, nube)
- ¿Qué cuentas fueron usadas? (correo, admin, cuentas compartidas)
- ¿Hay indicios de filtración? (tráfico inusual, alertas del proveedor, logs)
- ¿Operación está detenida total o parcialmente?
Entregable simple:
Un listado corto:
- “Crítico caído”
- “En riesgo”
- “Operativo”
Ejemplo en empresa de servicios:
Si se cifran carpetas con contratos y propuestas, pero el sistema de facturación sigue OK, la prioridad puede ser recuperar acceso a documentación para no perder ventas y cumplir entregas.
Paso 4: Proteger evidencia (para aprender y, si aplica, actuar legalmente)
Objetivo: no perder información clave del incidente.
Responsable: TI + asesoría externa si corresponde.
Qué hacer:
- Guardar capturas de pantalla de notas de rescate.
- Registrar hora, sistemas afectados, usuarios, acciones tomadas.
- Resguardar logs básicos (servidores, firewall, M365/Google, EDR si existe).
No es “investigación forense completa”, es orden mínimo para evitar decisiones a ciegas.
Paso 5: Tomar decisiones ejecutivas (pagar o no pagar, detener operaciones, etc.)
Objetivo: decidir con criterios de negocio, no por pánico.
Responsable: gerencia (con apoyo TI/Legal/Seguro).
Criterios prácticos para decidir (sin tecnicismos):
- ¿Tenemos backups restaurables y probados?
- ¿Cuánto cuesta la detención por hora/día?
- ¿Hay datos sensibles involucrados?
- ¿Qué exige el seguro (si existe)?
- ¿Qué reputación está en juego?
Importante: pagar no garantiza recuperación ni evita filtración. El IRP debe priorizar recuperación segura y comunicación responsable.
Paso 6: Comunicación interna (la gente debe saber qué hacer y qué NO hacer)
Objetivo: evitar rumores, errores y más exposición.
Responsable: Incident Commander + RR.HH./Comunicaciones (si existe).
Mensajes internos mínimos:
- “Estamos en incidente; se activó protocolo.”
- “No conectar equipos sospechosos.”
- “No usar correos/enlaces raros.”
- “Usar canal X para coordinar.”
- “No comunicar externamente sin autorización.”
Ejemplo típico:
Un colaborador “bien intencionado” reenvía la nota de rescate a todos por correo… y el correo está comprometido. Por eso el canal alternativo es clave.
Paso 7: Erradicar el vector de entrada (si no, te reinfectas)
Objetivo: cerrar la puerta por donde entraron antes de restaurar.
Responsable: TI/proveedor.
Vectores comunes:
- Phishing y credenciales robadas (correo)
- Acceso remoto expuesto o mal asegurado
- Equipos sin parches
- Contraseñas débiles o reutilizadas
- Cuentas compartidas
Acciones típicas:
- Reset de contraseñas críticas (admins y cuentas clave).
- Activar MFA donde falte (correo, VPN, sistemas).
- Revisar reglas sospechosas en correo (reenvíos automáticos).
- Parches prioritarios y cierre de accesos remotos inseguros.
Paso 8: Recuperación por prioridades (volver a operar sin “restaurar todo”)
Objetivo: recuperar lo esencial primero y volver al negocio.
Responsable: líder negocio + TI.
Define un orden de recuperación:
- Correo corporativo / identidades (para coordinar y operar)
- ERP/facturación/pagos (para cobrar y cumplir)
- Sistemas operacionales (bodega, rutas, atención)
- Archivos compartidos (contratos, RR.HH.)
- Equipos de usuarios (según roles críticos)
Consejo práctico:
No esperes restaurar “todo” para operar. Define “mínimo viable operacional”.
Paso 9: Verificación y monitoreo reforzado (asegurar que el regreso es seguro)
Objetivo: evitar “segundo golpe”.
Responsable: TI/proveedor.
Qué validar:
- Que no reaparecen cifrados o procesos sospechosos.
- Que cuentas críticas estén protegidas con MFA.
- Que el acceso remoto esté controlado.
- Que respaldos sigan funcionando y se hagan pruebas de restauración.
Indicador de éxito:
La empresa opera de nuevo y el riesgo de reinfección baja.
Paso 10: Lecciones aprendidas y plan de mejoras (lo que convierte crisis en madurez)
Objetivo: que el incidente no se repita igual.
Responsable: gerencia + TI.
Reunión post-incidente (en 7–14 días):
- ¿Cómo entró?
- ¿Qué falló (técnico y de proceso)?
- ¿Qué funcionó del IRP?
- ¿Qué se debe cambiar en 30/60/90 días?
Plan 30/60/90 (ejemplo):
- 30 días: MFA total, gestor de contraseñas, bloqueo de accesos remotos inseguros, política de backups con pruebas.
- 60 días: segmentación de red, EDR, capacitación anti-phishing, inventario TI.
- 90 días: simulacro, documentación IRP, mejoras en continuidad (RTO/RPO), revisión de proveedores.
5) Checklist descargable (rápido) para tu empresa
Si quieres que esto se convierta en una hoja de una página para tu equipo, aquí tienes el checklist resumido:
Antes del incidente
- Inventario de sistemas críticos (ERP, correo, e-commerce, archivos)
- Backups + prueba de restauración
- Contactos de emergencia (TI, cloud, legal, proveedores)
- Canal alternativo al correo para crisis
- Roles definidos: IC (coordinador), TI, negocio, comunicaciones
Durante el incidente
- Activar IRP y war room
- Aislar equipos/sistemas sospechosos
- Identificar alcance (qué está cifrado / qué sigue operativo)
- Resguardar evidencia mínima (logs, capturas, timeline)
- Comunicación interna clara
- Cerrar vector de entrada antes de restaurar
- Recuperar por prioridades del negocio
- Monitoreo reforzado y validación
Después
- Lecciones aprendidas
- Plan 30/60/90 y responsables
- Simulacro en calendario
Convierte el ransomware en un riesgo gestionable (no en una ruleta)
Nadie quiere vivir un ataque de ransomware, pero muchas empresas lo enfrentan sin plan: deciden por intuición, se comunican tarde y restauran “a lo bruto”. Un IRP bien implementado te permite lo contrario: orden, foco, rapidez y control.
Si hoy solo hicieras una cosa, que sea esta: define responsables y prioriza tus sistemas vitales. Esa claridad, en medio de un incidente, vale oro.
¿Quieres que revisemos tu nivel de preparación y construyamos tu IRP en formato 1-página + simulacro?
Solicita una asesoría con HDTI