Ataques DDoS conforme a NIS 2
Señales de detección, capas de mitigación y la decisión de notificación conforme al artículo 23 de NIS 2 y al artículo 11, apartado 6, del CIR 2024/2690.
Por qué el DDoS encaja de lleno en el artículo 23
Un ataque de denegación de servicio distribuido satura un objetivo con tráfico procedente de muchas fuentes de modo que los usuarios legítimos ya no pueden alcanzar el servicio. Conforme a NIS 2, la categoría técnica es menos interesante que el efecto. Una vez que un DDoS degrada o interrumpe de forma medible un servicio que la entidad presta, el artículo 23 de NIS 2 lo convierte en un evento notificable con una cascada fija.
El artículo 11, apartado 6, del Reglamento de Ejecución (UE) 2024/2690 de la Comisión (el CIR) nombra explícitamente la denegación de servicio como una de las categorías que, para los proveedores de infraestructura digital y de servicios de TIC, cuenta como incidente significativo. Para las demás entidades esenciales e importantes se aplica la prueba general de significatividad del artículo 23, apartado 3, de NIS 2. El impacto en la disponibilidad del servicio es el desencadenante dominante en ambos casos.
Una entidad que opera un sitio web, una API, un portal en línea, una pasarela de pago, un resolutor de DNS o cualquier otro servicio expuesto a internet suele alcanzar el umbral de notificación más rápido de lo que puede escalar sus defensas. La cascada jurídica, por tanto, empieza a correr en paralelo con la mitigación, no después de ella.
Directiva de la UE (vinculante en toda la Unión)
Los Estados miembros garantizarán que las entidades esenciales e importantes presenten al CSIRT o, en su caso, a la autoridad competente: a) sin demora indebida y, en cualquier caso, en un plazo de 24 horas desde que tengan conocimiento del incidente significativo, una alerta temprana; b) sin demora indebida y, en cualquier caso, en un plazo de 72 horas desde que tengan conocimiento del incidente significativo, una notificación de incidente; c) un informe intermedio sobre las actualizaciones pertinentes de la situación, a petición de un CSIRT o, en su caso, de la autoridad competente; d) un informe final a más tardar un mes después de la presentación de la notificación de incidente con arreglo a la letra b); e) en caso de incidente en curso en el momento de la presentación del informe final a que se refiere la letra d), los Estados miembros garantizarán que las entidades afectadas presenten un informe de situación en ese momento y un informe final en el plazo de un mes desde la gestión del incidente.
Artículo 23, apartado 4, de NIS 2. El reloj de notificación empieza en el momento en que la entidad tiene conocimiento del incidente significativo, no cuando la mitigación comienza o termina. Un DDoS que sigue en curso al cumplirse el mes activa la variante del informe de situación de la letra e).
Reglamento de ejecución de la UE (detalle técnico vinculante)
Un ataque de denegación de servicio o un ataque de denegación de servicio distribuido se considera un incidente significativo para las entidades que prestan servicios de infraestructura digital y las entidades que prestan gestión de servicios de TIC, cuando el ataque cause una indisponibilidad total del servicio o una degradación significativa del servicio.
Artículo 11, apartado 6, del Reglamento de Ejecución (UE) 2024/2690 de la Comisión. El CIR se aplica directamente a los proveedores de servicios de DNS, los registros de nombres de TLD, los proveedores de servicios de computación en la nube, los proveedores de servicios de centro de datos, los proveedores de redes de distribución de contenidos, los proveedores de servicios gestionados, los proveedores de servicios gestionados de seguridad, los proveedores de mercados en línea, de motores de búsqueda en línea y de servicios de redes sociales. Para estos tipos de entidad, un DoS o DDoS con indisponibilidad total o degradación significativa es, por su propio nombre, significativo.
Ejemplo nacional (Alemania)
Wesentliche und wichtige Einrichtungen melden dem Bundesamt erhebliche Sicherheitsvorfälle. Die Meldung erfolgt unverzüglich, spätestens jedoch innerhalb von 24 Stunden nach Kenntnisnahme als Frühwarnung, innerhalb von 72 Stunden als Meldung mit erster Bewertung und innerhalb eines Monats als Abschlussbericht.
§ 32 BSIG (NIS2UmsuCG). La transposición alemana refleja la cascada del artículo 23, apartado 4, de forma literal. Los informes van al BSI a través del Meldeportal. Otros Estados miembros utilizan su propio CSIRT nacional o autoridad competente. El fondo es idéntico.
Señales de detección a nivel del SOC
Los indicadores típicos captados por la monitorización de red o un SOC incluyen un pico repentino en el volumen de tráfico entrante, una caída en el ratio de peticiones correctas, recuentos de conexiones anómalos en los dispositivos de borde, una oleada de agentes de usuario o patrones de consulta idénticos, mayor latencia o pérdida de paquetes en los enlaces perimetrales, y alertas de saturación de los proveedores ascendentes. Combinados con una caída medible en la disponibilidad del servicio, estos indicadores convierten un evento en un incidente en el sentido del artículo 6, apartado 6, de NIS 2.
Capas de mitigación de uso común
Los patrones de mitigación habituales incluyen el filtrado de tráfico ascendente en el proveedor de servicios de internet, el depurado (scrubbing) a través de un servicio externo de protección DDoS, la limitación de tasa y el estrangulamiento de conexiones en el borde, la distribución anycast y geográfica, el blackholing o null-routing de las fuentes de ataque a nivel del operador, y protecciones de capa de aplicación como la gestión de bots. Aquí se describe la defensa en capas, no se recomienda; la combinación proporcionada depende de la evaluación de riesgos de la entidad conforme al artículo 21 de NIS 2.
Decisión de notificación conforme al artículo 23
Una vez que la disponibilidad del servicio se ve afectada de un modo que cumple el artículo 23, apartado 3, de NIS 2 o, para las entidades de infraestructura digital, el artículo 11, apartado 6, del CIR, comienza la cascada: alerta temprana en un plazo de 24 horas, notificación de incidente en un plazo de 72 horas, informe intermedio a petición, informe final en un plazo de un mes, informe de situación si el incidente sigue en curso al cumplirse el mes.
El impacto en el servicio, no el volumen del ataque, es el desencadenante
El artículo 23, apartado 3, de NIS 2 define la significatividad a través del efecto sobre el servicio: perturbación operativa grave, pérdida financiera o daños materiales o inmateriales a otras personas físicas o jurídicas. Un ataque de 500 Gbps que se absorbe por completo no es, por sí solo, un incidente significativo. Un ataque de 5 Gbps que deja un portal fuera de servicio durante una hora normalmente sí lo es. La prueba del artículo 11, apartado 6, del CIR para las entidades de infraestructura digital es aún más directa: indisponibilidad total o degradación significativa.
El DDoS a menudo encubre un evento de segunda fase
Los ataques volumétricos se utilizan en ocasiones como cobertura para el relleno de credenciales (credential stuffing), la exfiltración de datos o el despliegue de ransomware. La revisión posterior al incidente que exige el artículo 23, apartado 4, letra d), de NIS 2 en el informe final suele distinguir entre el evento visible de disponibilidad y cualquier evento secundario de acceso o integridad detectado durante o después de la inundación.
BSI como CSIRT nacional y punto de notificación
En Alemania, el BSI recibe los informes del artículo 23 a través del Meldeportal conforme al § 32 BSIG. El BSI también publica orientación sobre gestión de incidentes, como el BSI-Standard 200-4 (BCM) y notas técnicas operativas; estas son orientación, no obligaciones de notificación adicionales. Otros Estados miembros tienen estructuras paralelas (NCSC-NL, ANSSI, NCSC-IE, etc.).
Cooperación con el ISP y filtrado ascendente
Los proveedores de servicios de internet pueden absorber o filtrar el tráfico de ataque antes de que alcance el borde del cliente. En Alemania, los proveedores de comunicaciones electrónicas operan bajo la TKG y cooperan con el BSI en la respuesta a amenazas; la BSI TR-03103 cubre las interfaces técnicas para algunas categorías. Para la entidad notificante, la cuestión es que la mitigación del ISP no elimina la obligación de notificación del artículo 23 si el servicio ya se vio afectado.
Orientación técnica y panorama de amenazas de ENISA
ENISA publica el informe anual Threat Landscape y orientación de respuesta a incidentes conforme al artículo 18 de NIS 2. El Threat Landscape 2024 confirma el DDoS como una de las principales categorías de amenaza observadas en los sectores de la UE. Los documentos de ENISA son material de referencia; no cambian la cascada del artículo 23.
El ISP se encarga, así que no hay que notificar nada
El filtrado del lado del ISP reduce el impacto pero no cambia el desencadenante jurídico. Si el servicio estuvo indisponible o significativamente degradado entre el inicio del ataque y la mitigación del ISP, se activa el artículo 23, apartado 3, de NIS 2 o el artículo 11, apartado 6, del CIR. La cascada de notificación corre en paralelo con la respuesta a nivel del operador.
Tratar solo el síntoma es suficiente
La limitación de tasa y el depurado detienen la inundación pero rara vez identifican si el DDoS fue una distracción. Una revisión posterior al incidente que no comprueba los registros de autenticación, las anomalías de tráfico saliente y los cambios de configuración durante la ventana del ataque deja sin detectar el evento secundario. El informe final del artículo 23, apartado 4, letra d), es el punto de control documentado para esto.
Una vez que el tráfico se normaliza, el incidente está cerrado
El artículo 23, apartado 4, letra d), de NIS 2 exige un informe final en un plazo de un mes desde la notificación de incidente. Ese informe cubre la causa raíz, la mitigación adoptada y las lecciones aprendidas. Una entidad que cierra el ticket en cuanto cae el tráfico normalmente no tiene nada que presentar, lo que es en sí mismo un incumplimiento documentado.
Dos hábitos operativos separan a las entidades que gestionan el DDoS con limpieza de las que improvisan. Primero, el reloj de notificación y el reloj de mitigación se rastrean por separado. La mitigación puede llevar horas; la alerta temprana de 24 horas tiene su propio responsable y su plantilla lista antes del evento. Segundo, la revisión posterior al incidente se programa en el momento de la detección, no al final de la inundación. Una franja en el calendario 25 días después de la detección obliga a redactar el informe final, incluso en un incidente tranquilo.
La configuración de DNS y de borde importa más que las decisiones tomadas durante el ataque. El enrutamiento anycast, proveedores de DNS autoritativos separados, un acuerdo de filtrado ascendente probado con el ISP y una vía de contacto documentada con el NOC del operador suelen estar en su sitio mucho antes de que llegue el primer paquete de un ataque. Lo mismo se aplica a las plantillas de informe: los campos de alerta temprana y notificación exigidos por el § 32 BSIG y los portales nacionales equivalentes son lo bastante estáticos como para rellenarse de antemano.
El módulo de incidentes de nisd2.eu incorpora la cascada del artículo 23, apartado 4, como un flujo de trabajo estructurado: alerta temprana a las 24h, notificación de incidente a las 72h, informe intermedio a petición, informe final al mes, variante de informe de situación si el incidente sigue en curso. La plataforma marca con sello de tiempo cada paso frente al momento del conocimiento y no frente al momento del ataque, que es lo que mide la directiva.
Las referencias de activos en el incidente vinculan el servicio afectado con las entradas del inventario de activos construido conforme a RSK 2.2, de modo que la revisión posterior al incidente puede rastrear qué activos, proveedores y procesos estuvieron implicados sin reconstruir el contexto desde cero.
- Directiva (UE) 2022/2555 (NIS 2), artículo 6, apartado 6 (definición de incidente), artículo 21 (medidas de gestión de riesgos), artículo 23 (notificación). EUR-Lex: eur-lex.europa.eu/eli/dir/2022/2555/oj
- Reglamento de Ejecución (UE) 2024/2690 de la Comisión, artículo 11, apartado 6 (denegación de servicio nombrada como incidente significativo para la infraestructura digital y los proveedores de servicios de TIC). EUR-Lex: eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- BSIG (NIS2UmsuCG), § 32 (obligaciones de notificación al BSI). gesetze-im-internet.de
- Meldeportal del BSI y orientación operativa sobre notificación de incidentes. bsi.bund.de
- ENISA Threat Landscape 2024, capítulo de DDoS. enisa.europa.eu
- BSI-Standard 200-4 (Gestión de la Continuidad de Negocio). bsi.bund.de
- BSI TR-03103 (serie de directrices técnicas). bsi.bund.de