Recursos · NIS2, Cumplimiento, Exposición externa, Respuesta a incidentes

La notificación de incidentes NIS2 empieza con el contexto de exposición externa ya disponible

NIS2 deja 24 horas para la alerta temprana y 72 para la notificación de incidente con una evaluación inicial de gravedad e impacto. El contexto de exposición externa reunido con antelación aporta hechos para esa evaluación, y hay preguntas que no responde.

Una vez que la organización tiene conocimiento de un incidente significativo, NIS2 le deja un máximo de 24 horas para presentar una alerta temprana. A más tardar en 72 horas debe enviar una notificación de incidente con una evaluación inicial de la gravedad y del impacto; para los prestadores de servicios de confianza ese plazo también es de 24 horas. Después llega el informe final, por regla general a más tardar un mes después de la notificación del incidente (NIS2, artículo 23(4)).

Esto significa que la información sobre un servicio expuesto a internet — su propietario, sus interfaces abiertas, sus cambios recientes de configuración — es tarde para empezar a reunirla cuando el reloj ya está en marcha. NIS2 no exige explícitamente un producto aparte para la observación de la exposición externa. Pero el contenido de las notificaciones obliga a establecer con rapidez la gravedad, el impacto y, en la medida de lo posible, los indicios técnicos del incidente. Un historial del perímetro externo reunido con antelación aporta hechos para esa evaluación, aunque no sustituye la decisión de las personas responsables.

Primero hay que determinar si el incidente es significativo

La obligación de notificar no alcanza a cualquier evento técnico, sino a los incidentes significativos. Según NIS2, un incidente es significativo si ha causado o puede causar una perturbación operativa grave de los servicios o pérdidas financieras para la organización; el segundo supuesto es que haya afectado o pueda afectar a otras personas causándoles daños materiales o inmateriales considerables (NIS2, artículo 23(3)).

Aquí la técnica aporta los datos de partida y el proceso toma la decisión. Un sistema de observación puede mostrar que ha aparecido un nuevo servicio público, que ha cambiado una interfaz abierta o que un activo conocido ha dejado de corresponder a su configuración anterior. Pero no determina por sí solo si el evento llevará a una perturbación grave del servicio, a pérdidas financieras o a un daño considerable para los clientes. Para eso hacen falta datos sobre la finalidad del sistema, los procesos de negocio afectados, las obligaciones contractuales y las consecuencias reales.

Para las organizaciones a las que se aplica el Reglamento de Ejecución (UE) 2024/2690, el momento del conocimiento está precisado: se considera que la organización ha tenido conocimiento de un incidente significativo cuando, tras una evaluación inicial, tiene una certeza razonable de que tal incidente se ha producido (Reglamento 2024/2690, artículo 2). El Reglamento se refiere, en particular, a los proveedores de infraestructura digital y de servicios que enumera, no automáticamente a todas las entidades sujetas a NIS2 (Reglamento 2024/2690, artículo 1).

Conclusión práctica: detectar un activo inusual expuesto a internet no activa por sí solo una notificación como incidente significativo. Debe activar una evaluación inicial que después pueda acreditarse. La existencia de ese proceso se comprueba con señales concretas:

  • hay un responsable asignado para la clasificación
  • están definidas las fuentes de datos
  • queda registrada la hora de llegada de la señal
  • queda escrito el fundamento de la decisión: si el incidente es significativo o no

Qué debe entrar en las primeras 24 horas

La alerta temprana debe indicar, cuando proceda, si se sospecha que el incidente obedece a actos ilícitos o malintencionados y si puede tener un impacto transfronterizo (NIS2, artículo 23(4)(a)). En esta fase la Directiva no exige una investigación cerrada con la causa raíz definitiva.

El contexto de exposición externa ayuda a separar lo conocido de lo supuesto. Si el equipo dispone de un inventario y de un historial de cambios, puede comprobar:

  • a quién pertenece el servicio detectado
  • cuándo pasó a ser accesible desde internet por primera vez
  • qué interfaces se observaban antes del evento y cuáles después
  • qué cambios de configuración quedaron registrados
  • con qué otros activos externos está relacionado

Esto no demuestra la intención maliciosa ni establece el impacto transfronterizo. Lo que sí permite es no presentar una suposición como un hecho establecido. Por ejemplo, la hora de la primera detección de un servicio es la hora de la observación, no necesariamente la de su creación o de su compromiso. Esa limitación conviene mantenerla tanto en la evaluación interna como en la notificación.

Técnicamente esta parte la cubren el inventario de activos, la observación de cambios y los registros de eventos disponibles. Para las entidades sujetas al Reglamento 2024/2690, el anexo exige mantener un inventario de activos completo, exacto, actualizado y coherente, hacer que los cambios sean trazables e indicar los datos de los activos, incluido su propietario (Reglamento 2024/2690, anexo, punto 12.4). El mismo anexo prevé procedimientos y herramientas de observación y registro de eventos (Reglamento 2024/2690, anexo, punto 3.2).

Las demás cuestiones las resuelve el proceso: quién confirma el carácter significativo, quién separa el hecho de la evaluación, quién aprueba la alerta temprana y quién la envía al CSIRT o a la autoridad competente. La observación del perímetro externo no hace eso.

Qué hará falta para la notificación a las 72 horas

La notificación de incidente debe actualizar la información de la alerta temprana y ofrecer una evaluación inicial del incidente, incluidas su gravedad y su impacto, así como los indicadores de compromiso disponibles: los indicios técnicos de una posible intrusión (NIS2, artículo 23(4)(b)).

Es aquí donde el contexto acumulado con antelación ahorra no un abstracto tiempo de los analistas, sino horas dentro de un plazo fijado. Si el propietario del activo ya está indicado, el equipo no tiene que empezar buscando el área capaz de explicar para qué sirve el servicio. Si se ha conservado el historial de interfaces abiertas, puede compararse el estado anterior y posterior al evento. Si los cambios de configuración son trazables, pueden cotejarse con los registros y con los indicadores de compromiso.

Ese cotejo ayuda a delimitar el alcance técnico: qué activo externo está afectado, qué cambió en él y qué sistemas relacionados hay que revisar. Pero no equivale a una evaluación del impacto completo. La observación externa no muestra por sí sola si se alteraron procesos internos, si se perdieron datos, si se detuvo un servicio o si se causó un daño a los clientes. Esa información debe llegar de los propietarios de los sistemas, de las áreas operativas y del equipo de respuesta.

Conviene definir de antemano el conjunto mínimo de campos de la ficha de un activo expuesto a internet:

  • propietario responsable
  • finalidad
  • fecha de la primera observación
  • interfaces disponibles
  • historial de cambios
  • relación con el servicio al que da soporte

La Directiva no prescribe ese formato. Es una forma de ingeniería de obtener más rápido la información que se necesitará para la evaluación inicial de la gravedad y del impacto conforme al artículo 23.

El informe final no se arma solo con la observación del perímetro

El informe final debe contener una descripción detallada del incidente, de su gravedad y de su impacto, el tipo de amenaza o la causa raíz probable, las medidas de mitigación aplicadas y en curso y, si lo hubo, el impacto transfronterizo. Si el incidente continúa en el momento del informe, primero se presenta un informe de situación y el final dentro del mes siguiente a la conclusión del tratamiento del incidente (NIS2, artículo 23(4)(d)–(e)).

El historial de exposición externa puede sostener la cronología y mostrar los cambios observados. No establece la causa raíz sin una investigación, no describe todas las medidas de recuperación y no calcula el impacto en el negocio. Es especialmente importante no sustituir la conclusión por la correlación: que aparezca una nueva interfaz en un momento próximo al incidente no demuestra que fuera su causa.

NIS2 exige además notificar sin demora indebida a los destinatarios de los servicios cuando un incidente significativo pueda afectar negativamente a la prestación de esos servicios. Ante una amenaza cibernética significativa, a los destinatarios potencialmente afectados se les informa, cuando sea necesario, de las medidas de protección o corrección disponibles (NIS2, artículo 23(2)). Ninguna herramienta de observación determina los destinatarios, la redacción del mensaje ni el momento adecuado para comunicar: eso es trabajo conjunto del propietario del servicio, la respuesta a incidentes, la función jurídica y comunicación.


Un activo externo a través de todo el proceso

Una comprobación útil no es una presentación sobre observación, sino recorrer un único activo externo por todo el proceso, requisito a requisito, con una línea clara entre lo que aporta la técnica y lo que solo puede resolver el proceso.

Determinar si el incidente es significativo (artículo 23(3))

  • Acción técnica — mostrar los activos externos afectados, sus propietarios, sus interfaces y su historial de cambios
  • Solo lo cubre el proceso — evaluar la perturbación del servicio, las consecuencias financieras y el daño a otras personas; dejar registrada la decisión
  • Fuente: NIS2, artículo 23(3)

Presentar la alerta temprana en 24 horas (artículo 23(4)(a))

  • Acción técnica — aportar una cronología verificada de observaciones y de cambios en la exposición
  • Solo lo cubre el proceso — aprobar la valoración sobre la intención maliciosa y sobre el posible impacto transfronterizo; enviar el mensaje
  • Fuente: NIS2, artículo 23(4)(a)

Presentar la notificación con la evaluación inicial (artículo 23(4)(b))

  • Acción técnica — cotejar activos, interfaces abiertas, cambios de configuración, registros e indicadores disponibles
  • Solo lo cubre el proceso — determinar la gravedad y el impacto completo, separando la información confirmada de las estimaciones
  • Fuente: NIS2, artículo 23(4)(b)

Mantener el inventario y la trazabilidad de los cambios para las entidades del Reglamento 2024/2690 (anexo, punto 12.4)

  • Acción técnica — comprobar que el propietario, la finalidad del activo y el historial de cambios están actualizados
  • Solo lo cubre el proceso — asignar la responsabilidad de actualizar el inventario y de revisarlo periódicamente
  • Fuente: Reglamento 2024/2690, anexo, punto 12.4

Preparar el informe final (artículo 23(4)(d)–(e))

  • Acción técnica — aportar la cronología técnica de la exposición externa y los cambios observados
  • Solo lo cubre el proceso — establecer la causa raíz probable y describir el impacto, las medidas de respuesta y las consecuencias transfronterizas
  • Fuente: NIS2, artículo 23(4)(d)–(e)

Notificar a los destinatarios de los servicios afectados (artículo 23(2))

  • Acción técnica — precisar qué sistemas y servicios externos están afectados
  • Solo lo cubre el proceso — determinar los destinatarios, las medidas de protección, el contenido y el orden de la comunicación
  • Fuente: NIS2, artículo 23(2)

Su primer paso

Solicite una primera revisión de su empresa.

Comparta el sitio web de su empresa y un correo de trabajo. Enviaremos su solicitud al equipo de IntruForce. Indíquenos si prefiere hablar de una evaluación concreta.

  • Sin instalación
  • Sin acceso a su red interna
  • Usted autoriza las pruebas activas por separado
Solo si prefiere que le respondamos por ahí.

Este formulario envía una solicitud de revisión al equipo de IntruForce. Enviarla no le compromete a nada; nuestro equipo responde al correo de trabajo que indique.