Cumplimiento normativo · 4 MIN DE LECTURA

NIS 2: los requisitos técnicos para los equipos de red

La directiva NIS 2 formula sus obligaciones como resultados. Esto es lo que significan en la práctica para un parque de switches, routers y firewalls: inventario, vulnerabilidades, accesos privilegiados, copias de seguridad y plazos de notificación.

Vista general del cumplimiento de red: puntuación media y equipos que no cumplen la política

Lo que NIS 2 exige realmente a sus equipos de red

La directiva NIS 2 (UE 2022/2555) sustituyó a la directiva NIS original y amplió considerablemente el conjunto de entidades afectadas. Su artículo 21 exige medidas de gestión de riesgos «proporcionadas», redactadas como resultados y no como productos. Para un equipo de red, ese enunciado abierto es el verdadero trabajo: traducir obligaciones legales en evidencias técnicas.

Este artículo describe lo que esas obligaciones significan en la práctica para un parque de switches, routers y firewalls. No sustituye a las orientaciones de su autoridad nacional.

Cinco obligaciones que recaen sobre la red

1. Conocer su parque

No se puede demostrar ninguna medida de seguridad en un equipo cuya existencia se desconoce. El inventario no figura como medida propia, pero todas las demás dependen de él: análisis de riesgos, gestión de vulnerabilidades, control de acceso. Un inventario útil identifica el fabricante, el modelo, la versión de firmware, la ubicación y el responsable de cada equipo, y se actualiza solo; de lo contrario, en pocas semanas deja de ser fiable.

2. Gestionar las vulnerabilidades

El artículo 21 menciona expresamente la gestión y la divulgación de vulnerabilidades. En la red, eso significa poder responder a una pregunta sencilla cuando se publica un aviso: ¿qué equipos están afectados, con qué versión y dónde están? Si responder exige una semana de recopilación manual, la obligación no se cumple.

3. Controlar los accesos privilegiados

El texto exige políticas de control de acceso y una autenticación reforzada para los accesos privilegiados. En una red, el punto débil habitual es la cuenta local compartida: una contraseña enable que conoce todo el equipo, que nunca se cambia cuando alguien se va y que nunca se registra. Lo que se espera son identidades nominativas, autenticación multifactor en los accesos administrativos y un registro de quién hizo qué.

4. Mantener las operaciones recuperables

La gestión de las copias de seguridad y la recuperación ante desastres forman parte de las medidas. En una red, la copia útil no es la del servidor de supervisión: es la configuración de cada equipo, versionada, con la posibilidad de volver al estado anterior a un cambio. Una copia cuya restauración nunca se ha probado no es una evidencia.

5. Notificar los incidentes en plazo

El artículo 23 fija una alerta temprana en 24 horas, una notificación en 72 horas y un informe final en un mes. Esos plazos solo son viables si el historial existe antes del incidente: saber qué configuración estaba vigente, qué cambió y cuándo es lo que permite calificar un evento en horas y no en días.

La diferencia entre una política y una evidencia

El error más habitual es documentar una intención. Un archivador que afirma que «las configuraciones se copian a diario» no vale nada para un auditor si nadie puede presentar la copia de ayer de un equipo elegido al azar. Lo que pide una auditoría es material verificable:

  • la lista de equipos, con su versión de software, en una fecha dada;
  • el historial de cambios de configuración, con su autor;
  • el resultado de una comprobación de cumplimiento y la desviación residual que usted acepta;
  • el registro de los accesos administrativos, que puede reproducirse si es necesario;
  • la cronología de un incidente pasado, reconstruida a partir de datos y no de la memoria.

Estos cinco elementos los produce la propia operación de la red, no un proyecto de cumplimiento aparte. Esa es la ventaja de una recopilación continua: la evidencia es un subproducto del funcionamiento normal.

Por dónde empezar desde cero

En este orden, porque cada paso hace posible el siguiente: inventario automático, después copia de seguridad versionada de las configuraciones, después una comprobación de cumplimiento que mida la desviación respecto a su política y, por último, el control de los accesos administrativos. La notificación de incidentes llega al final, porque se nutre de todo lo anterior.

Nuestra página cumplimiento NIS 2 relaciona estos requisitos con los módulos de la plataforma, y la página auditoría de cumplimiento muestra cómo se mide la desviación tras cada recopilación.

Una advertencia útil

NIS 2 es una directiva: se transpone al derecho nacional, con variaciones. El ámbito exacto de las entidades, los umbrales y los canales de notificación dependen de su país y de su sector. Los componentes técnicos descritos aquí son necesarios en todos los casos, pero esto no es asesoramiento jurídico: haga que su autoridad nacional califique su situación.

Compartir este artículoLinkedIn ↗Email ↗

Siga explorando.

Todos los artículos →
Reservar una reunión