Respuesta ante incidentes en sitios web: una guía paso a paso para gestores de TI

Cuando el sitio web de una empresa es desfigurado, comienza a distribuir malware o filtra silenciosamente su base de datos de clientes, la diferencia entre un mal día y un evento existencial rara vez es la habilidad técnica: es si alguien escribió, antes del incidente, quién decide qué, en qué orden y con qué accesos. Esta guía ofrece a los responsables de TI en organizaciones pequeñas y medianas un plan de respuesta a incidentes completo y práctico para sitios web y aplicaciones web, basado en la estructura de NIST SP 800-61 y adaptado a equipos de una a cinco personas en lugar de un SOC 24/7.

Dedique tiempo a trabajarlo una vez en condiciones de calma (aproximadamente un día laboral), y tendrá un manual impreso, una tarjeta de contactos y copias de seguridad probadas; los tres artefactos que separan constantemente las recuperaciones rápidas de las interrupciones de una semana.

El ciclo de vida del incidente

Todo marco de trabajo creíble utiliza alguna versión del mismo bucle. Imprima esto; es la columna vertebral de todo el plan:

   +--------------+     +-----------------+     +--------------+
   | 1. PREPARAR  | --> | 2. DETECTAR Y   | --> | 3. CONTENER  |
   |  plan, roles |     |    ANALIZAR     |     |  frenar      |
   |  backups     |     |  triaje, alcance|     |  preservar   |
   +--------------+     +-----------------+     |  pruebas     |
          ^                                     +------+-------+
          |                                            |
   +------+-------+     +-----------------+     +------v-------+
   | 6. APRENDER  | <-- | 5. RECUPERAR    | <-- | 4. ERRADICAR |
   |  post-mortem |     |  restaurar,     |     |  eliminar    |
   |  mejoras     |     |  monitorear,    |     |  causa,      |
   |              |     |  notificar      |     |  parche      |
                        +-----------------+     +--------------+

Fase 1 — Preparación (hágalo ahora, no durante el incendio)

1.1 Definir niveles de severidad y quién decide

La ambigüedad sobre "qué tan grave es esto" desperdicia la primera hora crítica. Adopte tres niveles:

Nombre a un Comandante de Incidentes (IC) —la persona que coordina, decide y comunica— y un sustituto para las vacaciones. En una empresa pequeña, el IC suele ser el gerente de TI; lo importante es que sea una persona designada, no "el equipo".

1.2 Crear la tarjeta de contacto

Durante un incidente no tendrá tiempo para buscar inicios de sesión. Prepare una tarjeta de una página (impresa y en un gestor de contraseñas compartido) con:

• Proveedor de hosting: soporte telefónico/portal, número de cuenta, quién tiene acceso de admin
• Registrador de dominio y proveedor DNS: lo mismo
• Cuentas de admin del CMS/plataforma y dónde viven sus credenciales
• Acceso al proveedor CDN/WAF (Cloudflare, etc.)
• Número de póliza de ciberseguro y línea directa 24h, si está asegurado
• Firma externa de IR/forense a la que llamaría para un SEV-1 (elija una ahora; los anticipos son baratos comparados con la incorporación de emergencia)
• Contacto de la autoridad de protección de datos (para Suecia: IMY; lista europea en EDPB)
• Interno: CEO, responsable de comunicación, asesor legal

1.3 Copias de seguridad que realmente ha restaurado

Una copia de seguridad que nunca se ha probado es una esperanza, no un control. Requisitos:

• Regla 3-2-1: tres copias, dos medios, una externa —y la copia externa debe estar fuera de línea o ser inmutable (bloqueo de objetos / snapshot), porque el ransomware moderno borra primero las copias accesibles.
• Alcance de la copia: raíz web, base de datos, configuración del servidor (nginx/Apache, cron), certificados TLS y —a menudo olvidado— las variables de entorno/secretos que la aplicación necesita para arrancar.
• Simulacro trimestral: restaure en una VM de prueba, inicie el sitio, inicie sesión. Tómelo. Ese número es su Objetivo de Tiempo de Recuperación (RTO) realista, no el del documento de políticas.

1.4 Detección que realmente notará

Los equipos pequeños no miran tableros; las alertas deben llegar a ellos. Conjunto mínimo: monitoreo de tiempo de actividad con alertas, detección de integridad de archivos o desfiguración en la raíz web, notificaciones de inicio de sesión de admin del CMS y monitoreo externo de la postura de seguridad de su dominio y cambios de certificado/DNS —el monitoreo continuo de FortifyNet cubre la parte externa y le envía correos ante cambios, que es precisamente cómo suelen detectarse tarde las desfiguraciones y certificados caducados.

Fase 2 — Detección y análisis (la primera hora)

Cuando llega una alerta o informe, el IC ejecuta el triaje —por escrito, en un canal dedicado (cree #incidente-AAAA-MM-DD), porque la línea de tiempo que escriba ahora será el post-mortem y posiblemente el registro legal posterior.

Preguntas de triaje, en orden:

1. ¿Es real? Reproduzca el síntoma desde una red externa (hotspot móvil); las cachés de CDN y el DNS dividido a menudo engañan a las comprobaciones internas.
2. ¿Cuál es el alcance? ¿Una página o todo el sitio? ¿Solo servidor web o también base de datos? ¿Es posible que las credenciales o datos personales estén involucrados? (Esta respuesta inicia el reloj del RGPD, vea la Fase 5).
3. ¿Está en curso? ¿Tráfico en vivo del atacante o el residuo de un evento pasado?
4. Asigne severidad según la tabla 1.1 y notifique en consecuencia.

Regla de evidencia desde el primer minuto: copie los registros del servidor afectado inmediatamente (logs de acceso, error, autenticación, auditoría del CMS). Los atacantes suelen borrar los logs; los proveedores de hosting los rotan en días. No apague un servidor del que pueda necesitar forense; aíslelo en su lugar (vea abajo); apagarlo destruye la evidencia residente en memoria.

Fase 3 — Contención

La contención detiene la hemorragia sin destruir evidencia. Elija la acción menos destructiva que detenga el daño en curso:

• Sitio distribuyendo malware/desfigurado: ponga el sitio en modo mantenimiento al nivel de CDN/balanceador, o bloquee geográficamente/desafíe todo el tráfico. Los usuarios ven una página de espera limpia; el origen comprometido permanece intacto para análisis.
• Cuenta de admin comprometida: deshabilite esa cuenta y rote todas las credenciales de admin y llaves API; asuma que el atacante cosechó el almacén de credenciales. Aplique MFA en el mismo cambio.
• Compromiso de servidor: aísle a nivel de red (grupo de seguridad/firewall: bloquee todo el tráfico entrante excepto su IP de gestión). Tome un snapshot de disco antes de cambiar nada si su host lo admite.
• Exfiltración de base de datos: rote credenciales de BD, revoque acceso externo y preserve los logs de consulta.

Dos errores de contención para informar al equipo por adelantado: (1) restaurar desde copia de seguridad antes de entender el punto de entrada; restaura la vulnerabilidad con los datos y es re-comprometido en horas; (2) comunicar sobre infraestructura potencialmente comprometida; si el servidor de correo puede estar afectado, coordine por teléfonos/Signal.

Fase 4 — Erradicación

Encuentre y elimine la causa raíz, no solo el síntoma:

1. Establezca el punto de entrada desde la evidencia: CMS/plugin sin parches (la mayoría de los incidentes en pequeñas empresas), credenciales robadas, panel de admin expuesto, formulario de carga vulnerable o brecha a nivel de hosting.
2. Reconstruya en lugar de limpiar. Para cualquier compromiso de nivel de servidor, despliegue un servidor nuevo desde una imagen limpia y migre los datos verificados. Limpiar una caja comprometida no es fiable; las webshells se esconden en archivos inocuos y entradas de cron.
3. Parchee el punto de entrada donde exista (también en staging), actualice todos los componentes y vuelva a escanear.
4. Rote todos los secretos que el sistema comprometido pudo leer: contraseñas de BD, llaves API, secretos OAuth, llaves privadas TLS si el material de claves pudo ser leído.

Fase 5 — Recuperación y notificación

Recuperación técnica

Restaure el servicio progresivamente: coloque el sitio reconstruido detrás de la CDN, realice un escaneo externo para confirmar que no se sirve nada malicioso, observe las tasas de error y los registros con especial atención durante 72 horas y mantenga las reglas de firewall estrictas. Si el sitio fue marcado por Google Safe Browsing, solicite revisión a través de Search Console; la exclusión suele tardar de horas a un par de días tras la limpieza.

Notificación legal: la regla de 72 horas

Bajo el Artículo 33 del RGPD, una brecha de datos personales debe ser reportada a la autoridad de control dentro de las 72 horas desde que se tuvo conocimiento, a menos que sea poco probable que la brecha suponga un riesgo para los derechos de las personas. El Artículo 34 requiere adicionalmente notificar a los individuos afectados cuando el riesgo es alto (ej. contraseñas filtradas o datos de pago). Puntos prácticos:

• El reloj comienza en la consciencia, no en la comprensión total. Un informe parcial ("hemos confirmado acceso no autorizado, alcance bajo investigación") dentro de 72 horas cumple; el silencio no.
• Documente la evaluación incluso cuando decida no notificar; el razonamiento en sí es obligatorio.
• Las organizaciones bajo obligaciones NIS2 tienen una vía rápida: alerta temprana al CSIRT en 24 horas, notificación de incidente en 72 horas.

Comunicación

Una sola voz: el IC o el responsable de comunicación designado. Internamente, actualizaciones breves y factuales a un ritmo fijo (incluso "sin cambios"). Externamente, la honestidad vence al maquillaje: indique qué pasó, qué datos estuvieron involucrados, qué deben hacer los usuarios (reinicio de contraseña) y qué ha cambiado. Las empresas rara vez son castigadas por los clientes por tener un incidente; son castigadas por ocultarlo.

Fase 6 — Revisión post-incidente

En un plazo de dos semanas, realice un post-mortem sin culpables (una hora, facilitado por el IC): línea de tiempo, causa raíz, qué funcionó, qué fue lento y 3–5 acciones concretas con responsables y fechas; ej. "habilitar actualizaciones automáticas para plugins", "mover copias a almacenamiento inmutable", "añadir monitoreo de integridad de archivos". Introduzca las acciones en el backlog de trabajo normal; una lección no asignada es una lección no aprendida.

Finalmente, programe un ejercicio de mesa dos veces al año: elija un escenario (una desfiguración descubierta por un cliente un viernes a las 17:30 es un clásico), recorra el manual con el equipo verbalmente y anote cada punto donde alguien dice "hmm, no estoy seguro de quién…". Esas pausas son los errores del plan; arréglelos en papel antes de que un atacante los encuentre en producción.

Ejemplo práctico: la desfiguración del viernes por la noche

La teoría se queda mejor con una línea de tiempo. Así es como se ejecuta el manual para el escenario común de PYMES: un cliente envía un correo el viernes a las 17:42 diciendo que su página de inicio "se ve extraña".

• 17:45 — Detectar. El responsable de TI de guardia (IC por defecto) abre el sitio desde un teléfono con datos móviles: la página muestra un banner de un atacante. Captura de pantalla tomada. Se crea el canal #incidente-20260828; SEV-1 declarado (compromiso confirmado); CEO avisado según la tabla de severidad.
• 17:55 — Evidencia. Antes de tocar nada: logs de acceso y error de los últimos 14 días copiados del servidor a almacenamiento local; log de auditoría de CMS exportado; snapshot de disco activado en el proveedor de hosting.
• 18:05 — Contener. Sitio cambiado a modo mantenimiento en la CDN. Los clientes ven una página neutral de "volvemos pronto". Todas las contraseñas de admin del CMS rotadas desde una laptop limpia; MFA forzado; la cuenta de admin desconocida encontrada en la lista de usuarios deshabilitada, no borrada (es evidencia).
• 18:40 — Analizar. El log de auditoría del CMS muestra que el admin falso fue creado el martes a las 03:14 vía un plugin de galería vulnerable (tres versiones desactualizado). Las tablas de clientes parecen intactas según los logs de consulta; anotado, con razonamiento, en el canal para la evaluación del RGPD.
• 19:30 — Erradicar. Servidor nuevo desplegado desde la imagen base del host; última copia limpia (lunes) restaurada; núcleo del CMS y plugins actualizados; plugin de galería eliminado; secretos rotados.
• 21:10 — Recuperar. DNS/CDN apuntado al nuevo origen. Escaneo externo confirma contenido y cabeceras limpias. Modo mantenimiento levantado. Se acuerda vigilancia intensiva de logs para el fin de semana, dividida entre IC y sustituto.
• Lunes — Notificar y aprender. Evaluación del RGPD concluida: no se accedió a datos personales, documentado, no requiere informe según Art. 33. Post-mortem el miércoles: actualizaciones automáticas activadas, inventario de plugins trimestral, monitoreo de integridad de archivos instalado.

Tiempo de inactividad visible: unas tres horas, un viernes por la noche, con dos personas. Ese resultado se compra casi totalmente en la Fase 1: la capacidad de snapshot, el interruptor de mantenimiento de la CDN, la copia de seguridad probada y la tabla de severidad fueron decididos antes de las 17:42.

Trabajando con terceros

Tres relaciones determinan cuánta ayuda obtendrá bajo presión:

• Proveedor de hosting. Sepa de antemano qué pueden hacer en una emergencia: ¿snapshots bajo demanda? ¿aislamiento de red? ¿periodo de retención de logs? Su respuesta de emergencia suele ser más rápida mediante el nivel de soporte pagado; decida antes del incidente si vale la pena (usualmente sí).
• Firma forense / IR. Para cualquier SEV-1 que involucre sospecha de robo de datos, ransomware o exposición legal, traiga profesionales pronto; los errores en el manejo de evidencia en las primeras horas son irreversibles. Una firma nombrada con un anticipo ligero responde en horas; una llamada en frío durante una ola nacional de ransomware puede responder en semanas.
• Ciberseguro. Lea la póliza ahora: la mayoría requiere notificación en una ventana fija y algunas exigen usar el panel de IR aprobado por el asegurador; contratar a su propia firma primero puede anular la cobertura. Ponga ambos datos en la tarjeta de contacto.

Si la extorsión entra en juego

Si el incidente viene con una demanda de rescate —por descifrado o por no publicar datos robados—, disminuya la velocidad antes de que alguien responda. No comunique con el atacante desde cuentas personales o corporativas; involucre al asesor legal y, para demandas significativas, a la policía (en Suecia vía polisen.se; muchos países de la UE tienen rutas nacionales de reporte de ciberdelincuencia) antes de cualquier contacto. Pagar es legal en la mayoría de jurisdicciones pero financia el siguiente ataque, no ofrece garantía y puede ser sancionado si el grupo está en una lista de sanciones; una verificación que su asesor legal o asegurador debe hacer. Decídalo una vez, a nivel directivo, documentado; la presión de la extorsión está diseñada para forzar decisiones individuales rápidas, y el trabajo del manual es prevenir exactamente eso.

Midiendo la capacidad

Dos números, revisados dos veces al año, le dicen si la capacidad está mejorando:

• MTTD (tiempo medio hasta la detección): tiempo desde el compromiso hasta la consciencia. El ejemplo anterior tuvo un MTTD de tres días; el atacante entró el martes, usted se enteró el viernes. El monitoreo de integridad de archivos lo habría reducido a minutos; ese es el argumento para la acción de post-mortem.
• MTTR (tiempo medio hasta la recuperación): tiempo desde la detección hasta la restauración del servicio. Impulsado casi totalmente por la calidad de la preparación: copias probadas, interruptores de contención pre-acordados y un tomador de decisiones nombrado.

Los ejercicios de mesa producen estos números de forma segura: cronometre el ejercicio, note dónde se estanca el equipo y trate cada "tendría que buscarlo" como un hallazgo.

Plantilla de notificación al cliente

Tenga un borrador listo para que la revisión legal sea la única demora. Manténgalo factual, corto y sin adjetivos:

Asunto: Incidente de seguridad que afecta a [servicio] — qué ocurrió y qué estamos haciendo

El [fecha] detectamos acceso no autorizado al [sistema]. Retiramos el
servicio afectado dentro de [X minutos/horas], eliminamos la causa,
y restauramos el servicio el [fecha/hora].

Qué se vio afectado: [categorías de datos específicas, o "ningún dato de cliente,
según nuestro análisis de logs"].

Qué debe hacer: [reinicie su contraseña / no se requiere acción].

Hemos reportado el incidente a [autoridad] e involucrado a [expertos
externos] para verificar nuestros hallazgos. Actualizaremos esta página a medida que la
investigación concluya: [URL de la página de estado].

Contacto: security@yourcompany.com

La lista de verificación de una página

• Tabla de severidad adoptada; Comandante de Incidentes + sustituto nombrados
• Tarjeta de contacto impresa y guardada en el gestor de contraseñas
• Copias de seguridad 3-2-1 con una copia fuera de línea/inmutable; simulacro de restauración realizado este trimestre
• Monitoreo de tiempo de actividad, desfiguración y postura externa con alertas a teléfonos
• Regla de evidencia conocida: copie logs primero, aísle, no apague
• Opciones de contención pre-acordadas con el proveedor de hosting/CDN
• Política de "reconstruir, no limpiar" para compromiso de servidor
• Deberes de notificación RGPD 72h / NIS2 24h mapeados a su organización
• Plantilla de post-mortem sin culpables lista; ejercicio de mesa programado

Fuentes

• NIST SP 800-61 — Recomendaciones y consideraciones de respuesta ante incidentes
• ENISA — Material de respuesta ante incidentes y ciber-crisis
• RGPD Artículo 33 — Notificación de una brecha de datos personales
• RGPD Artículo 34 — Comunicación al interesado
• Directiva NIS2 (UE) 2022/2555
• IMY — Reportar una brecha de datos personales (Suecia)
• Google Search Console — Solicitar una revisión de seguridad