Respuesta a incidentes en WordPress según NIS2: playbook de alerta temprana en 24 horas
El artículo 23 de la Directiva 2022/2555 comprime la primera fase de la respuesta a incidentes en tres plazos: 24 horas, 72 horas y un mes. El plazo de 24 horas pilla por sorpresa a quienes gestionan WordPress, porque empieza cuando se tiene conocimiento del incidente, no cuando se ha resuelto. Y en un sitio WordPress típico ese conocimiento llega antes por un mensaje de Slack que por un panel de SOC.
Este es un artículo de apoyo del pilar sobre NIS2 y DORA en WordPress.
TL;DR
- 24 horas desde el conocimiento: alerta temprana al CSIRT.
- 72 horas desde el conocimiento: notificación con evaluación inicial.
- 1 mes desde el conocimiento: informe final con causa y corrección.
- El “conocimiento” es el detonante, no una alerta del SIEM.
- Seis señales de WordPress que para mí significan “el reloj corre”.
- Plantillas en los idiomas nacionales en este playbook.
Qué dice exactamente el artículo 23
El artículo 23, apartado 1, establece la obligación: notificar al CSIRT o a la autoridad competente todo incidente que tenga un impacto significativo en la prestación de los servicios. El artículo 23, apartado 3, define “significativo”: capaz de causar una perturbación operativa grave de los servicios o pérdidas económicas para la entidad, o perjuicios materiales o inmateriales a otras personas físicas o jurídicas.
El artículo 23, apartado 4, divide la línea temporal:
- (a) Sin demora indebida y, en todo caso, en un plazo de 24 horas desde que se tuvo conocimiento del incidente significativo: una alerta temprana que indique si se sospecha que el incidente tiene una causa ilícita o maliciosa y si puede tener efectos transfronterizos.
- (b) Sin demora indebida y, en todo caso, en un plazo de 72 horas: una notificación que actualice la alerta temprana e incluya una evaluación inicial de la gravedad, el impacto y los indicadores de compromiso.
- (c) A petición del CSIRT o de la autoridad competente: un informe intermedio sobre la situación.
- (d) A más tardar un mes después de la notificación de la letra b): un informe final con descripción detallada, tipo de amenaza o causa raíz, medidas correctoras aplicadas y posibles efectos transfronterizos.
El reloj empieza cuando se tiene conocimiento de un incidente significativo. Las orientaciones de ENISA interpretan el “conocimiento” como el momento en que una persona cualificada de la entidad concluye con suficiente certeza que se ha producido un incidente significativo. Esto pesa mucho en WordPress, porque el conocimiento suele llegar por el correo de un cliente, un servicio externo de monitorización o un escáner de vulnerabilidades, no por un SOC interno.
Cómo reconocer una intrusión en un sitio WordPress
Estos hallazgos obligan a abrir un registro y valorar de inmediato si el incidente es significativo. No ponen en marcha automáticamente el plazo de NIS2. El artículo 23 se aplica cuando una entidad sujeta a la norma tiene conocimiento de que el incidente es significativo según las reglas aplicables.
1. Defacement en una página de cara al cliente. Defacements indexados, página de inicio sustituida, páginas de producto sustituidas. La visibilidad facilita valorar la gravedad: el daño a la confianza del cliente es un hecho.
2. Cuenta de administrador comprometida con inicio de sesión confirmado. Una cuenta de administrador nueva, una cuenta de administrador existente con accesos desde un rango de IP o un país poco habitual, una cuenta de administrador que modifica otras cuentas. Lo detectan los plugins de audit log (WP Activity Log, Stream, Wordfence audit log).
3. Instalación de un plugin malicioso o subida de un tema. Un archivo de plugin en wp-content/plugins/ que ha llegado fuera del canal habitual de actualizaciones, o con PHP que llama a eval, base64_decode, gzinflate o assert sobre datos del usuario. Lo detecta la monitorización de integridad de archivos o un análisis de Wordfence.
4. Inyección en la base de datos con escritura confirmada. Una SQL injection que ha conseguido insertar o modificar filas. Se confirma con un diff del audit log o con manipulaciones en wp_users o wp_options. Señal clásica: la opción siteurl apunta de repente a un dominio ajeno.
5. Exportación no autorizada de datos personales. Una exportación de WordPress, una llamada a la REST API que devuelve la lista de usuarios, una respuesta grande de wp-json/wp/v2/users desde una IP inesperada. El artículo 33 del RGPD puede aplicarse en paralelo al artículo 23 de NIS2.
6. Ransomware o cifrado del sistema de archivos en producción o en las copias de seguridad. Archivos con extensiones nuevas, .html con la nota de rescate en los directorios de subidas, archivos de copia de seguridad cifrados. Es una señal de gravedad alta, pero el alcance y el carácter significativo siguen requiriendo una decisión documentada.
Para cada uno de estos hallazgos, el runbook de la agencia dice: anotar la hora del conocimiento en el ticket de IR, nombrar al responsable, poner en marcha el plazo de 24 horas y avisar al CISO de la entidad o a su equivalente en la primera hora. La agencia no notifica al CSIRT; lo hace la entidad. La agencia aporta el contenido técnico.
Plantilla de alerta temprana NIS2 en 24 horas
La alerta temprana es breve a propósito. La plantilla que entrego al equipo de cumplimiento de la entidad:
Entidad: [razón social]
Sector: [clasificación del Anexo I o II]
Identificador nacional: [NIF o número de registro]
Resumen del incidente
Fecha y hora del conocimiento: [ISO-8601 con zona horaria]
Origen de la detección: [audit log / aviso de cliente / escáner externo / notificación del proveedor de hosting]
Servicio afectado: [sitio WordPress público en https://example.com, portal de clientes, etc.]
Clasificación inicial
Causa presunta: [maliciosa / accidental / en análisis]
Efectos transfronterizos: [sí / no / en análisis]
Indicios de efectos transfronterizos: [si la respuesta es sí, qué apunta a ello]
Evaluación inicial del impacto
Disponibilidad del servicio: [operativo / degradado / no disponible]
Acceso confirmado a datos: [ninguno / sospecha / confirmado]
Número de personas potencialmente afectadas: [cifra si se conoce, si no "en análisis"]
Primera respuesta
Medidas de contención: [rotación de credenciales, eliminación del plugin, bloqueo de IP, etc.]
Análisis forense en curso: [sí / no, con el nombre del proveedor si es externo]
Próxima actualización: [hora de la notificación de 72 horas o de un informe intermedio anterior]
Contacto
Nombre y cargo: [CISO, responsable de TI, etc.]
Correo y teléfono: [línea directa]Esto es la alerta temprana, no la notificación. La notificación de 72 horas la amplía con la evaluación de la gravedad, los indicadores de compromiso y una valoración más clara de los efectos transfronterizos.
Qué incluye la notificación de incidente NIS2 a las 72 horas
En un plazo de 72 horas desde el conocimiento, la notificación añade:
- Evaluación de la gravedad. Número de usuarios afectados, distribución geográfica, estimación de las pérdidas económicas, tiempo estimado de recuperación.
- Indicadores de compromiso. Direcciones IP, hashes de archivos, URL, cadenas User-Agent maliciosas, firmas del ataque. ENISA recomienda un esquema; los CSIRT aceptan STIX 2.1 o una lista libre.
- Evaluación de los efectos transfronterizos. Confirmados o descartados, con justificación.
- Estado de la contención. Qué está controlado y qué sigue abierto.
- Necesidades de cooperación. Si la entidad necesita apoyo del CSIRT o de otras autoridades.
En WordPress, el bloque de indicadores suele incluir: IP de los atacantes sacadas de los access logs, rutas de los archivos maliciosos en wp-content/, hashes de esos archivos, cadenas User-Agent observadas durante la explotación y el HTTP request body conservado por el WAF.
¿Qué elementos debe incluir el informe final NIS2 tras un incidente?
Artículo 23, apartado 4, letra d): informe final a más tardar un mes después de la notificación. Contenido:
- Descripción detallada del incidente.
- Tipo de amenaza o causa raíz.
- Medidas correctoras aplicadas y en curso.
- Efectos transfronterizos, cuando proceda.
En los incidentes de WordPress, la sección de la causa suele acabar en una de estas: un plugin desactualizado con un CVE conocido, credenciales de administrador débiles sin MFA, un wp-config.php expuesto desde un archivo de copia de seguridad, RCE a través de una función del tema, compromiso de la cadena de suministro en el canal de actualizaciones, una mala configuración del servidor. La sección de medidas correctoras vincula la causa con la medida del artículo 21, apartado 2 que debería haberla evitado y actualiza el registro de riesgos de la entidad.
Dónde notificar un incidente NIS2 en Polonia y en la UE
Cada Estado miembro designa al menos un CSIRT y una autoridad competente. La lista actualizada se mantiene en el portal de ENISA. Los destinos más habituales para las entidades con las que trabajo:
- Polonia. CSIRT NASK para los sectores civiles, CSIRT GOV para la administración pública, CSIRT MON para el ámbito de defensa. La autoridad nacional competente depende del sector.
- Alemania. Bundesamt für Sicherheit in der Informationstechnik (BSI) y CERT-Bund. CSIRT sectoriales para finanzas (CSIRT BaFin), energía y telecomunicaciones.
- España. INCIBE-CERT para el sector privado y la ciudadanía, CCN-CERT para la administración pública.
- Noruega. No es miembro de la UE, pero está alineada a través del EEE; el NSM NCSC recibe notificaciones de los sectores que se han armonizado de forma voluntaria.
- Portugal. CERT.PT, dependiente del CNCS (Centro Nacional de Cibersegurança).
Para las entidades que operan en varias jurisdicciones, ENISA mantiene una lista de puntos de contacto únicos (SPOC) para la coordinación transfronteriza.
Cómo preparar un plan de respuesta a incidentes en WordPress
El plazo de 24 horas es implacable con las entidades que solo se preparan después de tener conocimiento del incidente. Antes de cualquier incidente:
- Guardias con nombre y apellidos. Dos personas, titular y suplente, con sus teléfonos en el runbook de IR.
- Árbol de escalado hasta el CISO de la entidad. La agencia no envía la alerta temprana; lo hace la entidad, así que el camino de “la agencia lo ve” a “la entidad decide” tiene que durar menos de una hora.
- Plantillas de comunicación preparadas de antemano. Aviso a clientes, aviso interno, aviso al regulador. Las tres en los idiomas que correspondan.
- Capacidad de hacer un snapshot de la instancia WordPress de producción. Antes de cualquier cambio de contención, conserve el sistema de archivos y la base de datos para el análisis forense.
- Relación con un proveedor forense, contratada con antelación. El análisis forense del artículo 23 en 72 horas exige un proveedor que coja el teléfono, no una petición de presupuesto.
- Copia de seguridad externa en modo inmutable. Sin ella, un ransomware puede hacer imposible el informe final al destruir las pruebas.
El precio de preparar esta capacidad es individual y depende del tamaño del parque WordPress; no es una línea de la factura del hosting.
Cómo hacer el triaje de un incidente en WordPress y conservar pruebas
Ante una señal creíble, el equipo abre un único registro principal del incidente. Anota la observación original, la hora con zona horaria, el origen, el entorno y la persona que lo lleva. Valora la autenticidad y el impacto en la confidencialidad, la integridad y la disponibilidad, y solo después si pueden cumplirse los criterios de incidente significativo. Los niveles operativos, como evento, incidente grave y crisis, ordenan los recursos, pero no sustituyen al artículo 23 ni a la ley nacional. El acceso confirmado, las cuentas, los componentes, los recorridos de clientes, el tiempo, el alcance, los proveedores y el grado de certeza se van actualizando. Lo que se desconoce sigue marcado como desconocido.
La contención y la conservación de pruebas avanzan en paralelo. Antes de reconstruir o eliminar código sospechoso, y si es seguro hacerlo, se guarda un snapshot o una copia de los archivos, el estado de la base de datos, el identificador del despliegue, las sesiones, los administradores y los logs. Los originales se conservan, los archivos reciben sumas de comprobación y las copias de trabajo se mantienen separadas. Cada cambio, incluida la rotación de credenciales, las reglas del WAF, la eliminación de plugins, la restauración y el DNS, entra en la línea temporal. La seguridad tiene prioridad cuando conservar una prueba prolonga el daño; si falta la prueba, hay que justificarlo.
Junto a la línea temporal técnica se lleva un registro cronológico de decisiones con hechos, supuestos, alternativas, responsable y fecha de revisión. Lo técnico, la dirección, lo jurídico y la privacidad, y la comunicación con los clientes tienen flujos separados que coordina el responsable de coordinación. La agencia entrega los componentes, la hora de detección, las referencias a las pruebas, el estado de la contención, el acceso sospechoso y la estimación de recuperación. La entidad decide y notifica, salvo que una autorización expresa establezca otra cosa.
Cómo probar el plan de respuesta a incidentes
El ejercicio debería reunir al proveedor de hosting, la agencia, el líder del incidente, privacidad y comunicación. Va de la alerta a las pruebas y la valoración del carácter significativo, hasta el traspaso al regulador, la aprobación de la restauración y los mensajes a los clientes. Para darlo por bueno hace falta respuesta de la guardia, un registro correcto, recogida de pruebas sin accesos improvisados, traspaso a quien decide, plantillas actualizadas, un punto de restauración limpio y un responsable y un plazo para cada mejora.
Tras la restauración quedan la línea temporal, el registro de decisiones, el índice de pruebas, las copias de las notificaciones, la lista de activos, el análisis de causa, la prueba de la restauración, la comunicación y la verificación de las correcciones. Una protección provisional se sustituye por un control permanente o por una decisión formal sobre el riesgo residual.
Para preparar el plan o ensayarlo, envíe una descripción por escrito a través de la auditoría de cumplimiento UE para WordPress. Indique la entidad, las jurisdicciones, los entornos WordPress, el hosting, los recorridos clave, el registro de logs, las copias de seguridad, los contactos, los ejercicios anteriores y las carencias. No envíe en un primer momento credenciales, datos personales ni pruebas en bruto del compromiso. El trabajo mejora la preparación y las pruebas, pero no es un dictamen jurídico, una garantía ni una conclusión automática sobre la obligación de notificar.
