NIS2 y la priorización de correcciones: dónde encaja la explotabilidad

El lunes un equipo recibe información sobre dos vulnerabilidades. La primera tiene una puntuación más alta del escáner, pero está en un sistema administrativo interno. La segunda tiene una puntuación menor, afecta a un servicio público de recepción de pedidos y el proveedor informa de que se ha usado en ataques. Además, actualizar el servicio público exige pruebas adicionales.

¿Cuál se corrige primero? NIS2 no da una respuesta lista ni establece una fórmula por la que la información sobre explotación eleve automáticamente la prioridad. La directiva exige otra cosa: aplicar medidas de gestión de riesgos de ciberseguridad adecuadas y proporcionadas, incluido el tratamiento de vulnerabilidades. Por eso la organización debe ser capaz de vincular la decisión de corregir con el riesgo para sus propios sistemas y servicios.

Qué exige exactamente NIS2

El artículo 21(1) de la Directiva (UE) 2022/2555 exige a las entidades esenciales e importantes incluidas en su ámbito adoptar medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar los riesgos que afectan a la seguridad de las redes y los sistemas de información. Al valorar la proporcionalidad se tienen en cuenta, entre otros factores, el grado de exposición al riesgo, el tamaño de la entidad, la probabilidad y la gravedad de los incidentes y su posible impacto social y económico.

El artículo 21(2)(e) incluye entre las medidas cubiertas la 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 vulnerabilidades. Eso vincula el trabajo con vulnerabilidades al sistema general de gestión de riesgos, pero no define una escala de prioridades aparte.

El Reglamento (UE) 2024/2690 concreta los requisitos para las categorías de entidades a las que se aplica. En materia de gestión de parches, su anexo prevé procedimientos alineados con la gestión de cambios, de vulnerabilidades y de riesgos. En particular:

• los parches se aplican en un plazo razonable desde que están disponibles;
• los parches se prueban antes de instalarlos en el entorno de producción;
• los parches proceden de fuentes de confianza y se verifica su integridad;
• los parches instalados quedan documentados.

El reglamento también contempla de forma expresa los casos en los que el parche no está disponible o no se aplica en el plazo previsto: entonces se requieren medidas adicionales y se documenta el riesgo residual que permanece. Así, la conexión con NIS2 no pasa por una clasificación obligatoria por explotabilidad, sino por una elección de medidas gestionada y documentada que tiene en cuenta el riesgo.

Cómo es una decisión concreta

Volvamos a las dos vulnerabilidades.

Sistema A — servidor administrativo interno

La puntuación de la vulnerabilidad es más alta. El servidor cumple una función auxiliar y el acceso está limitado al entorno corporativo. La actualización está preparada y puede instalarse en la ventana de mantenimiento habitual.

Sistema B — servicio público de recepción de pedidos

La puntuación de la vulnerabilidad es más baja. El aviso del proveedor indica que la vulnerabilidad se ha usado en ataques. Instalar la actualización sin pruebas podría romper la integración con el módulo de pagos.

El equipo decide ocuparse primero del sistema B. No es una conclusión automática de NIS2 ni una regla universal para cualquier sistema externo. En este ejemplo la decisión se apoya en circunstancias registradas: la accesibilidad pública del servicio, la información del proveedor, la finalidad del sistema y el posible impacto de una interrupción en la recepción de pedidos.

La decisión no implica necesariamente instalar de inmediato una actualización sin probar. El equipo puede empezar por limitar la función afectada, realizar pruebas aceleradas y fijar el momento de la instalación. Para el sistema A se mantiene un plazo propio de corrección en la siguiente ventana de mantenimiento.

El registro de una decisión así puede recoger:

• qué sistemas y servicios se ven afectados;
• qué información se ha usado en la valoración;
• cómo se han valorado la exposición, la probabilidad y el posible impacto;
• qué corrección o medida adicional se ha elegido;
• qué riesgo residual queda;
• quién aprobó la decisión y cuándo debe revisarse.

Esta lista no es una matriz establecida por NIS2. Muestra cómo una organización puede reflejar en un documento de trabajo las circunstancias en las que se basó su elección. Si el equipo pone primero el sistema A, también debe poder explicar esa decisión: por ejemplo, por los privilegios particulares de ese sistema o por el posible impacto de su compromiso.

Dónde encaja la explotabilidad en el proceso

La información sobre explotación no debería presentarse como un requisito independiente de NIS2. Su lugar lo determina la forma en que la organización valora el riesgo. Por ejemplo, un procedimiento interno puede prever que el aviso del proveedor sobre ataques se transmita al responsable del sistema y al especialista encargado de la valoración del riesgo. Después, ambos comprueban qué componentes afectados usa la organización y qué servicios dependen de ellos.

Ese procedimiento importa no porque la directiva prescriba un resultado concreto, sino porque permite vincular la nueva información con una valoración ya adoptada. El equipo no se limita a añadir una marca al registro de la vulnerabilidad: decide si lo que ha llegado cambia la probabilidad del incidente, el grado de exposición y el posible impacto en su entorno.

La política interna puede usar la explotabilidad como criterio de escalado. Por ejemplo, la llegada de un aviso del proveedor puede activar una revisión no planificada, sin exigir necesariamente la instalación inmediata del parche. La revisión puede terminar en una actualización, una medida adicional temporal, el mantenimiento del plazo anterior o un riesgo residual documentado. NIS2 fija un marco orientado al riesgo, no una única respuesta obligatoria.

Qué revisar en el procedimiento de corrección

El procedimiento debe distinguir la recepción de la información, la valoración y la ejecución de la decisión. De lo contrario, un equipo puede dar la tarea por terminada al registrar la vulnerabilidad, mientras otro espera la actualización instalada.

Cuando llega la información, hay que establecer si afecta a los sistemas en uso. Después se valoran las circunstancias relevantes para el riesgo de un servicio concreto. A continuación se elige la medida y se asignan un responsable y un plazo. Si la actualización se aplaza, la decisión no termina con una nota de más tarde: para las entidades cubiertas por el Reglamento 2024/2690 deben definirse medidas adicionales y documentarse el riesgo residual.

Conviene comprobar aparte si el procedimiento refleja los requisitos de la propia gestión de parches. La urgencia no suprime la necesidad de probar la actualización antes de instalarla en producción, de verificar su origen y su integridad y de documentar el cambio realizado. Estas acciones vinculan el trabajo diario del equipo con los requisitos del reglamento, y no con una fórmula universal de valoración de vulnerabilidades.

Al final, lo verificable no es la afirmación siempre ponemos por delante las vulnerabilidades explotables, sino la secuencia de una decisión concreta: qué hechos se conocían, cómo se relacionaron con el riesgo para el servicio, qué medida se eligió y qué riesgo quedó. Eso es lo que separa un criterio interno de priorización de una regla que NIS2 no contiene.