Gestión de vulnerabilidades NIS2 conforme al artículo 21(2)(e)
La gestión de vulnerabilidades tiene dos caras bajo NIS2. Cómo trata las debilidades en sus propios sistemas. Y cómo trata las debilidades que la gente le reporta. El artículo 21(2)(e) es donde reside la obligación, el §6.10 del CIR (UE) 2024/2690 detalla los aspectos concretos para los proveedores digitales que abarca, y el §30(2)(5) BSIG transpone el deber al Derecho alemán.
La versión resumida
La gestión de vulnerabilidades es el punto (e) de la lista del artículo 21(2). El CIR titula su sección correspondiente 'Tratamiento y divulgación de vulnerabilidades'. Ese título es la pista. A NIS2 le importan dos cosas a la vez: las debilidades que residen en los sistemas que opera, y las debilidades que personas externas encuentran en sus productos y quieren comunicarle.
Para los proveedores digitales que abarca, el CIR §6.10 expone cinco acciones. Recabar información de vulnerabilidades de CSIRT, autoridades, proveedores y prestadores de servicios. Cuando proceda, ejecutar análisis de vulnerabilidades y registrar los resultados a intervalos planificados. Remediar las críticas sin demora injustificada. Integrar el tratamiento de vulnerabilidades en sus procesos de cambios, parcheo, riesgos e incidentes. Y establecer un procedimiento de divulgación coordinada de vulnerabilidades (CVD) que se alinee con la política nacional de CVD.
Alemania nombra la gestión y la divulgación de vulnerabilidades para toda entidad en el §30(2)(5) BSIG, sin prescribir la forma. El BSI es el coordinador nacional de la divulgación coordinada de vulnerabilidades (§5(1) BSIG) y la gestiona a través de CERT-Bund. La propia NIS2 también establece una base de datos europea de vulnerabilidades conforme al artículo 12, operada por ENISA, donde las entidades pueden divulgar de forma voluntaria.
Artículo 21(2)(e) de la Directiva NIS2 (2022/2555)
La seguridad en la adquisición, el desarrollo y el mantenimiento de sistemas de redes y de información, incluida la gestión y divulgación de las vulnerabilidades.
Punto (e) de la lista de diez medidas. Observe el encuadre: el tratamiento y la divulgación de vulnerabilidades se sitúan dentro de un deber más amplio en torno a la adquisición, el desarrollo y el mantenimiento. El CIR lo divide en puntos separados (6.1 adquisición, 6.10 vulnerabilidades).
CIR (UE) 2024/2690, anexo §6.10
Las entidades pertinentes recibirán información sobre las vulnerabilidades de sus sistemas de redes y de información, evaluarán su exposición a dichas vulnerabilidades y adoptarán las medidas necesarias para gestionarlas.
Derecho de la UE directamente vinculante para los tipos de entidad enumerados en el art. 1 CIR (DNS, TLD, nube, centros de datos, MSP, servicios de confianza y los demás). El §6.10.2 enumera cinco acciones concretas. El §6.10.3 establece que, cuando omita la mitigación, escriba por qué. El §6.10.4 establece que revise a intervalos planificados los canales que utiliza para vigilar la información de vulnerabilidades.
§30(2)(5) BSIG (Alemania)
Medidas de seguridad para la adquisición, el desarrollo y el mantenimiento de sistemas, componentes y procesos de tecnología de la información, incluidos la gestión y la divulgación de vulnerabilidades.
Alemania copia el texto de la UE. El marco nacional de CVD discurre por el programa de divulgación coordinada de CERT-Bund en el BSI, que es a lo que apunta en Alemania 'alineado con las políticas nacionales de CVD aplicables' del §6.10.2(e) del CIR.
Recabe la información
Siga la información de vulnerabilidades de CSIRT, autoridades, proveedores y prestadores de servicios. Ejecute análisis de vulnerabilidades con una cadencia adecuada a su entorno. Las herramientas de análisis (Tenable, Qualys, Nessus, OpenVAS) son el lado de ingeniería. Los feeds (boletín de CERT-Bund, avisos de proveedores, NVD) son el lado de la concienciación. Necesita ambos.
Corrija las críticas, documente el resto
Las vulnerabilidades críticas se remedian sin demora. El tratamiento de vulnerabilidades tiene que engancharse a su gestión de cambios, gestión de parches, gestión de riesgos y gestión de incidentes. Cuando decida no mitigar, el §6.10.3 establece que cree un plan de mitigación documentado o escriba por qué no es necesaria ninguna acción. Sin un backlog silencioso.
Ejecute un proceso de divulgación coordinada
Establezca un procedimiento para recibir informes de vulnerabilidades de personas externas y coordinar su divulgación, alineado con la política nacional de CVD aplicable. Mecánica mínima: un canal de contacto publicado (buzón security@ o un archivo security.txt), un SLA de acuse de recibo, un plazo de remediación y una publicación pública coordinada. CERT-Bund mediará si es necesario.
Periódico, no reactivo
El punto 6.10.2(b) pide, cuando proceda, análisis de vulnerabilidades con los resultados registrados a intervalos planificados, y el punto 6.10.4 que los canales de vigilancia se revisen a intervalos planificados. Para las entidades que abarca el CIR, eso significa una cadencia escrita: documente con qué frecuencia analiza y con qué frecuencia revisa su lista de feeds, y aténgase a ello. Ningún texto fija el intervalo.
La divulgación forma parte del deber
El § 30 Abs. 2 Nr. 5 BSIG y el art. 21(2)(e) NIS 2 nombran la divulgación de vulnerabilidades junto a su gestión, para toda entidad. Para los proveedores digitales que abarca el CIR, el punto 6.10.2(e) pide un procedimiento acorde con la política nacional de divulgación coordinada. Una configuración mínima: un buzón security@ que alguien lee, una política breve y un archivo security.txt que apunte a él.
BSI / programa CVD de CERT-Bund
El BSI opera CERT-Bund, el CSIRT federal, y gestiona un programa de divulgación coordinada de vulnerabilidades. Los investigadores pueden reportar a través de CERT-Bund y el BSI coordinará con los proveedores afectados. El § 5(1) BSIG convierte al BSI en el coordinador nacional de la divulgación coordinada de vulnerabilidades conforme al art. 12(1) NIS 2. Si está montando un proceso de divulgación por primera vez, la guía de CVD del BSI es un buen modelo.
Base de datos europea de vulnerabilidades (artículo 12 NIS2)
El artículo 12 de NIS2 establece una base de datos europea de vulnerabilidades operada por ENISA. Las entidades pueden divulgar vulnerabilidades en ella de forma voluntaria. No es un canal de notificación obligatoria conforme al artículo 23. Es un recurso de referencia para toda la UE que agrega información de vulnerabilidades de todos los Estados miembros.
Los CSIRT nacionales como coordinadores de CVD
Cada Estado miembro designa a uno de sus CSIRT como coordinador de la divulgación coordinada de vulnerabilidades (art. 12(1) NIS 2). Las leyes nacionales pueden ir más allá de la directiva (art. 5), así que conviene consultar el texto nacional; también difieren el CSIRT con el que se habla y cómo funciona su coordinación.
Parcheamos en el Patch Tuesday, con eso basta.
No para los proveedores digitales que abarca el CIR: el punto 6.10.2(c) establece que las vulnerabilidades críticas se abordan sin demora injustificada. El Patch Tuesday es una cadencia de publicación del proveedor. Un zero-day divulgado un jueves con explotación activa no espera hasta el martes siguiente. Una cadencia de parcheo para las correcciones rutinarias más un proceso fuera de banda para los problemas críticos cubre ambos casos.
No tenemos un proceso de CVD porque nadie nos reporta nunca vulnerabilidades.
Para los proveedores digitales que abarca el CIR, el punto 6.10.2(e) pide el procedimiento de antemano, no cuando lleguen los informes. Para todos los demás, la divulgación se nombra en el § 30(2) Nr. 5 BSIG sin una forma prescrita. Un buzón security@ y una política de una página son, en ambos casos, un paso pequeño y sensato.
El análisis de vulnerabilidades es trabajo del equipo de seguridad.
Lo es, hasta que lee el §6.10.2(d): el tratamiento de vulnerabilidades tiene que ser coherente con la gestión de cambios, la gestión de parches, la gestión de riesgos y la gestión de incidentes. Eso convierte la gestión de vulnerabilidades en un proceso interdepartamental que toca operaciones de TI, desarrollo y riesgos, no una actividad de seguridad en silos.
El lado de la divulgación es la mitad infradocumentada. Mínimo realista: un buzón security@sudominio.com enrutado a dos personas, una política de divulgación de una página y un archivo security.txt en /.well-known/security.txt que apunte al buzón. En cuanto a los plazos, la guía de CVD del BSI espera que un fabricante acuse recibo de un informe en un plazo de tres días hábiles y concede de 45 a 90 días para corregirlo, el intervalo habitual a nivel internacional.
- Directiva (UE) 2022/2555 (NIS2), artículo 12 y artículo 21(2)(e): eur-lex.europa.eu/eli/dir/2022/2555/oj
- Reglamento de Ejecución (UE) 2024/2690 de la Comisión (CIR), anexo §6.10: eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Ley del BSI (BSIG), §30(2)(5) en su versión modificada por la Ley de Implementación de NIS2 y de Refuerzo de la Ciberseguridad
- BSI / programa de divulgación coordinada de vulnerabilidades de CERT-Bund: bsi.bund.de
- Base de datos europea de vulnerabilidades de ENISA (artículo 12 NIS2)
En la práctica
Dónde aparece esto en el recorrido guiado
El recorrido guiado lo convierte en pasos que usted rellena, con la ley explicada al lado de cada uno. Abra un paso para ver su pantalla, rellenada para una empresa ficticia.
El recorrido está en alemán y en inglés.
Procurement & Development
Write the rules for buying, updates and vulnerabilities
What you check when buying, how updates arrive and who closes gaps.
¿Le han encargado NIS2?
Le guiamos paso a paso. Usted rellena, nosotros explicamos cada punto con palabras sencillas y, al final, firma la dirección.
