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, y el §30(2)(5) BSIG lo transpone 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.
El CIR §6.10 expone cinco acciones. Recabar información de vulnerabilidades de CSIRT, autoridades, proveedores y prestadores de servicios. Ejecutar análisis de vulnerabilidades con una cadencia documentada. Remediar las críticas sin demora. 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 incorpora la misma norma a su Derecho nacional mediante el §30(2)(5) BSIG. El marco nacional de CVD discurre por el programa de divulgación coordinada de CERT-Bund en el BSI. 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)
Seguridad en la adquisición, el desarrollo y el mantenimiento de redes y sistemas de información, incluidos el tratamiento y la 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 secciones separadas (§6.9 adquisición, §6.10 vulnerabilidades). La mitad de la divulgación es la que se infravalora.
CIR (UE) 2024/2690, anexo §6.10
Las entidades pertinentes obtendrán información sobre las vulnerabilidades técnicas de sus redes y sistemas de información, evaluarán su exposición a tales vulnerabilidades y adoptarán medidas adecuadas para gestionarlas.
Derecho de la UE directamente vinculante para los sectores nombrados en el anexo del 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 periódicamente 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 §6.10.2(b) establece que los análisis se ejecutan 'periódicamente, según corresponda'. El §6.10.4 establece que revise periódicamente los canales que utiliza para vigilar la información de vulnerabilidades. Ambas expresiones significan: cadencia escrita. Documente con qué frecuencia analiza, documente con qué frecuencia revisa su lista de feeds, y aténgase a ello. Un análisis una vez al año porque alguien se acordó no es periódico.
La divulgación coordinada es un deber, no es opcional
El §6.10.2(e) establece que el procedimiento tiene que existir. No 'si recibe informes'. El procedimiento existe para que, cuando un investigador encuentre algo, tenga un canal y usted tenga un proceso. Mínimo viable: un buzón security@sudominio.com que alguien lee, una ventana de acuse de recibo (comúnmente 7 días) y una ventana de divulgación (comúnmente 90 días). Documéntelo, publíquelo, apunte un archivo security.txt hacia é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 §30(2)(5) BSIG apunta a esto. Si está montando un proceso de CVD por primera vez, alinear sus plazos y canales de contacto con el modelo de CERT-Bund es la opción segura por defecto.
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 tiene su CSIRT nacional actuando como coordinador de CVD (NCSC-NL en los Países Bajos, CERT.at en Austria, CCB en Bélgica). El deber es el mismo en toda la UE. Lo que difiere: con qué CSIRT habla y la mecánica exacta de su proceso de coordinación.
Parcheamos en el Patch Tuesday, con eso basta.
No basta. El §6.10.2(c) establece que las vulnerabilidades críticas se remedian sin demora. 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. Necesita una cadencia de parcheo para las correcciones rutinarias y un proceso fuera de banda para los problemas críticos.
No tenemos un proceso de CVD porque nadie nos reporta nunca vulnerabilidades.
El §6.10.2(e) no dice 'monte un proceso cuando empiecen a llegar informes'. Dice que el procedimiento tiene que existir. La cuestión es asegurar que, cuando un investigador encuentre algo, tenga un canal claro y su equipo sepa qué hacer. Un buzón security@ y una política de una página bastan para cumplir el deber. No tenerlo es un hallazgo.
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. Y el §6.10.4: revise los canales a nivel organizativo. Eso convierte la gestión de vulnerabilidades en un proceso interdepartamental que toca operaciones de TI, desarrollo, riesgos y el órgano de dirección, no una actividad de seguridad en silos.
El lado de ingeniería suele estar en forma razonable. La mayoría de los equipos de TI del Mittelstand ya ejecutan un analizador (Tenable, Qualys, Nessus, OpenVAS) y tienen algún tipo de cadencia de parcheo, aunque sea solo 'Patch Tuesday para los clientes, trimestral para los servidores'. Los deberes del §6.10.2(a)+(b)+(c) del CIR consisten en su mayoría en escribir lo que ya ocurre y ajustar el plazo de corrección de las críticas.
El lado de CVD 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 (acusar recibo en 7 días, divulgar en 90 días, dar crédito a los investigadores que lo deseen) y un archivo security.txt en /.well-known/security.txt que apunte al buzón. Medio día de trabajo. La pieza que las auditorías realmente señalan.
El módulo PRO captura su inventario de vulnerabilidades, el calendario de análisis, las tareas de remediación y las decisiones de aceptación en un solo lugar. Cada hallazgo de análisis se enruta hacia una tarea con un propietario, una fecha límite y una aprobación. El 'documentar por qué no es necesaria ninguna acción' del §6.10.3 es la misma vía de aprobación: justificación escrita, aprobador nombrado, registro de auditoría. Sin una hoja de cálculo aparte.
También entregamos una plantilla de política de CVD (configuración del buzón security@, contenido de security.txt, SLA de acuse de recibo y divulgación alineados con CERT-Bund). Introduce su dominio y sus contactos y tiene cubierto el deber del §6.10.2(e). Los informes entrantes se enrutan al mismo flujo de tareas que los hallazgos de análisis, de modo que el plazo de respuesta se rastrea del mismo modo.
- 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)