Respuesta ante incidentes en el ENS: cómo gestionarlos

Cualquier organización sujeta al el ENS terminará enfrentándose a un incidente: un ransomware que cifra un servidor, una fuga de credenciales, una caída provocada o un acceso no autorizado a datos. La diferencia entre una organización madura y una que improvisa no está en si sufre incidentes, sino en cómo los gestiona. El ENS no se conforma con que tengas antivirus y un cortafuegos; te pide un proceso de respuesta documentado, con responsables claros, con notificación obligatoria cuando el impacto lo justifica y con evidencias que un auditor pueda revisar.

En esta guía me centro en el ciclo de gestión de un incidente y en la parte que suele descuidarse: la notificación al CCN-CERT y la documentación que pide la auditoría. Si lo que buscas es el marco completo de obligaciones de seguridad operativa, lo desarrollo en la página sobre gestión de incidentes de ciberseguridad en el ENS, que complementa este artículo. Y si necesitas situar el ENS dentro del panorama general, la guía completa del Esquema Nacional de Seguridad te da el contexto de partida.

¿Qué exige el ENS sobre respuesta ante incidentes?

El ENS está regulado por el Real Decreto 311/2022, de 3 de mayo, que sustituyó al antiguo RD 3/2010. Dentro de su Anexo II, las medidas de seguridad se agrupan en tres marcos: organizativo, operacional y de protección. La gestión de incidentes vive en el marco operacional, concretamente en la medida op.exp.7 ("Gestión de incidentes"). Esta medida exige disponer de un proceso integral para tratar los incidentes que puedan afectar a la seguridad del sistema, incluyendo la comunicación de los eventos de seguridad.

Pero op.exp.7 no actúa sola. El ENS la rodea de medidas complementarias que conviene conocer porque la auditoría las revisa en conjunto:

• op.exp.8 (Registro de la actividad): los registros (logs) que permiten reconstruir lo ocurrido. Sin trazas no hay análisis forense posible.
• op.exp.9 (Registro de la gestión de incidentes): la obligación de dejar constancia de todo el ciclo, desde los informes iniciales hasta las modificaciones del sistema derivadas del incidente.
• op.mon (Monitorización del sistema): la vigilancia continua que alimenta la fase de detección.

Por encima de las medidas técnicas, los artículos 33 y 34 del Real Decreto 311/2022 articulan la prevención, detección y respuesta a incidentes, y la prestación de servicios de respuesta. Estos artículos atribuyen al Centro Criptológico Nacional, a través del CCN-CERT, el papel de coordinador público estatal de la respuesta técnica frente a incidentes que afecten a entidades del ámbito de aplicación del ENS.

El ciclo de gestión de un incidente paso a paso

La respuesta ante incidentes no es un acto único, sino un ciclo de fases encadenadas. Aunque cada organización lo adapta a su realidad, la estructura que recomienda la guía CCN-STIC-817 del CCN-CERT y que comparten los estándares internacionales sigue siempre la misma lógica: preparar, detectar, contener, erradicar, recuperar y aprender. Lo importante es que cada fase tenga un responsable asignado y deje una evidencia, porque eso es exactamente lo que la auditoría te pedirá.

Preparación

Antes de que ocurra nada, necesitas un plan. Esto incluye definir qué es un incidente para tu organización, quién forma el equipo de respuesta, qué herramientas usaréis, cómo se escala una crisis y qué canales de comunicación se activan. La preparación también abarca la formación del personal y la realización de simulacros. Un equipo que ensaya responde mejor que uno que lee el procedimiento por primera vez en plena crisis. Esta fase entronca directamente con tu plan de continuidad de negocio (BCP) en el ENS, porque un incidente grave puede desembocar en la activación del plan de contingencia.

Detección y análisis

Detectar es reconocer que algo va mal: una alerta del SIEM, un usuario que reporta un correo sospechoso, un pico de tráfico anómalo. El análisis consiste en confirmar si se trata de un incidente real, determinar su alcance y clasificarlo por peligrosidad e impacto. Esta clasificación es decisiva, porque de ella depende si tienes que notificar al CCN-CERT y en qué plazos. Aquí la monitorización continua (op.mon) y los registros de actividad (op.exp.8) son tu materia prima.

Contención

Una vez confirmado el incidente, hay que evitar que se propague. La contención puede ser inmediata (aislar un equipo de la red, desactivar una cuenta comprometida) o a más largo plazo (segmentar, aplicar reglas de cortafuegos temporales). La clave aquí es no destruir evidencias por las prisas: contener no es lo mismo que borrar. Antes de apagar o reinstalar, conviene preservar imágenes y registros.

Erradicación

Erradicar significa eliminar la causa raíz: el malware, la vulnerabilidad explotada, la cuenta del atacante. Si solo contienes pero no erradicas, el incidente reaparecerá. Esta fase exige entender cómo entró el adversario, algo que solo es posible si has preservado las trazas en las fases anteriores.

Recuperación

Recuperar es devolver los sistemas a su funcionamiento normal de forma segura: restaurar desde copias limpias, reconstruir servidores, validar que la amenaza ha desaparecido antes de reconectar. La recuperación debe ser gradual y vigilada, porque un atacante persistente puede haber dejado puertas traseras. La restauración apresurada es uno de los errores más caros.

Lecciones aprendidas

El ciclo se cierra con un análisis posterior: qué falló, qué funcionó, qué medidas hay que reforzar. Esta fase no es burocracia, es el mecanismo por el que tu organización mejora. Las conclusiones deben traducirse en acciones concretas: parchear, ajustar configuraciones, formar al personal o actualizar el propio procedimiento de respuesta. El ENS valora especialmente esta retroalimentación, porque demuestra que el sistema de gestión está vivo.

¿A quién se notifica un incidente en el ENS?

Aquí está una de las obligaciones que más confusión genera. En el ámbito del sector público sujeto al ENS, los incidentes de impacto significativo o nivel alto deben notificarse de forma obligatoria al CCN, a través del CCN-CERT. Esta obligación está desarrollada en la Instrucción Técnica de Seguridad de Notificación de Incidentes de Seguridad, aprobada por la Resolución de 13 de abril de 2018.

La notificación se canaliza por la plataforma del CCN-CERT. La herramienta de referencia para la gestión de tickets e incidentes es LUCIA, que permite registrar el incidente, intercambiar información con el equipo del CCN-CERT y seguir su tratamiento hasta el cierre. No todos los incidentes requieren notificación: depende del nivel de peligrosidad y de impacto que les asignes en la fase de clasificación.

Conviene tener muy claro que el CCN-CERT no es el único destinatario posible. Un mismo incidente puede activar varias notificaciones en paralelo si concurren distintos marcos normativos, algo que explico más abajo y que detallo en la guía de normativa de ciberseguridad en España (RGPD, ENS, NIS2 y DORA).

¿Cómo se clasifican los incidentes según el CCN-CERT?

La guía CCN-STIC-817 de Gestión de Ciberincidentes establece una taxonomía que clasifica los incidentes según su peligrosidad en cinco niveles: Crítico, Muy Alto, Alto, Medio y Bajo. Junto a la peligrosidad, se evalúa el impacto (bajo, medio o alto, según el perjuicio causado a la organización). De la combinación de ambos depende la obligación de notificar y los plazos de cierre.

La regla general, según la guía, es que los incidentes de nivel Alto, Muy Alto y Crítico conllevan obligación de notificación al CCN-CERT, mientras que los de nivel Medio y Bajo no la conllevan. Los plazos de cierre crecen con la gravedad. He resumido la lógica en la siguiente tabla, que te servirá para decidir rápidamente ante un incidente real.

Insisto en un matiz: los plazos y umbrales concretos pueden actualizarse en sucesivas versiones de la CCN-STIC-817, por lo que la tabla anterior es orientativa. Ante un incidente real, la fuente vinculante es siempre la versión vigente de la guía y la propia Instrucción Técnica de Seguridad.

¿Qué documentación y evidencias exige la auditoría?

Esta es la parte que separa una respuesta improvisada de una que supera la auditoría del ENS. La medida op.exp.9 obliga a registrar toda la actividad de gestión del incidente: informes iniciales, intermedios y finales, actuaciones de emergencia y modificaciones del sistema derivadas del incidente. Y va más allá: cuando el incidente pueda dar lugar a actuaciones disciplinarias contra personal interno, contra proveedores externos o a acciones penales, el ENS exige registrar evidencias que puedan emplearse ante un tribunal, con el detalle de su composición y especificación determinado con asesoramiento jurídico especializado.

En la práctica, un auditor querrá ver al menos:

1. El procedimiento de gestión de incidentes documentado, aprobado y conocido por el personal.
2. Un registro de incidentes con fecha de detección, clasificación, acciones realizadas y fecha de cierre.
3. Las evidencias de notificación al CCN-CERT cuando procediera, con su correspondiente ticket o referencia.
4. Los informes finales con causa raíz y lecciones aprendidas.
5. La trazabilidad de las acciones correctoras derivadas del análisis posterior.

La cadena de custodia de las evidencias merece una mención aparte. Si un incidente acaba en sede judicial, las pruebas mal recogidas pierden valor. Por eso conviene definir desde la fase de preparación cómo se preservan, quién las custodia y cómo se documenta su integridad. Este rigor documental es, además, lo que se evalúa en cualquier proceso de consultoría de implantación del ENS.

¿Cómo se relaciona la notificación del ENS con el RGPD y NIS2?

Un error frecuente es asumir que notificar al CCN-CERT te exime de cualquier otra obligación. No es así. El ENS, el RGPD y la Directiva NIS2 son marcos distintos que pueden concurrir sobre un mismo incidente, y cada uno tiene su propio destinatario y su propio plazo.

El caso más claro es una brecha de datos personales. Si el incidente afecta a datos de carácter personal, el artículo 33 del RGPD obliga a notificar la brecha a la autoridad de control competente (en España, la AEPD) sin dilación indebida y, a ser posible, en un plazo de 72 horas desde que se tiene constancia de ella. Ese plazo de 72 horas es del RGPD y no debe confundirse con los plazos del ENS, que se rigen por la Instrucción Técnica de Notificación y la guía CCN-STIC-817. Puedes profundizar en el régimen de brechas en mi guía de cumplimiento del RGPD para empresas y sus sanciones.

A esto se añade NIS2, que impone obligaciones propias de notificación a las entidades esenciales e importantes que entren en su ámbito. Resultado: un único ransomware que cifra sistemas y expone datos personales en una entidad del sector público puede generar, simultáneamente, una notificación al CCN-CERT (ENS), una notificación a la AEPD (RGPD) y, si la entidad está sujeta, una notificación bajo NIS2. Coordinar esas obligaciones sin solaparse ni dejar huecos es una de las razones por las que conviene tener el procedimiento de respuesta bien definido de antemano.

Errores habituales al gestionar incidentes en el ENS

En mi trabajo como consultor de cumplimiento, con base en Valladolid (Castilla y León) y en Las Palmas, veo repetirse los mismos fallos en organizaciones que, sobre el papel, cumplen el ENS:

• No clasificar el incidente. Si no asignas nivel de peligrosidad e impacto, no sabes si debes notificar ni en qué plazo. La clasificación no es opcional.
• Destruir evidencias por las prisas. Reinstalar el servidor afectado antes de preservar imágenes y logs deja a la organización sin capacidad de análisis forense ni de defensa jurídica.
• Confundir contención con resolución. Aislar un equipo no elimina la vulnerabilidad. Sin erradicación, el incidente vuelve.
• No documentar. Una respuesta técnica impecable que no deja rastro escrito no supera la auditoría, porque op.exp.9 exige el registro.
• Olvidar el RGPD. Notificar al CCN-CERT y no a la AEPD cuando hay datos personales es un incumplimiento independiente que puede acarrear sanción.
• No cerrar el ciclo. Sin lecciones aprendidas ni acciones correctoras, el mismo incidente reaparece y el sistema de gestión no madura.

Si quieres preparar a tu organización para responder con solvencia y dejar el rastro documental que la auditoría exige, puedo ayudarte tanto en la consultoría desde Castilla y León como en el resto del territorio, combinando trabajo presencial y remoto.

Preguntas frecuentes

¿Cómo se gestionan los incidentes en el ENS?

Mediante un ciclo de gestión que recorre seis fases: preparación, detección y análisis, contención, erradicación, recuperación y lecciones aprendidas. La medida op.exp.7 del Anexo II del Real Decreto 311/2022 exige ese proceso documentado, con responsables asignados, clasificación de cada incidente y registro de todas las actuaciones para que puedan ser revisadas en auditoría.

¿A quién se notifica un incidente de seguridad?

En el sector público sujeto al ENS, los incidentes de impacto significativo o nivel alto se notifican de forma obligatoria al CCN, a través del CCN-CERT, mediante su plataforma de gestión (LUCIA). Si el incidente afecta a datos personales, además hay que notificar la brecha a la AEPD en 72 horas según el RGPD, ya que son obligaciones distintas y concurrentes.

¿Qué es el CCN-CERT?

El CCN-CERT es el equipo de respuesta a incidentes de seguridad del Centro Criptológico Nacional. Conforme a los artículos 33 y 34 del Real Decreto 311/2022, actúa como coordinador público estatal de la respuesta técnica ante ciberincidentes que afectan a las entidades del ámbito del ENS, y publica la guía CCN-STIC-817 con la taxonomía de clasificación de incidentes.

¿Qué documentación exige el ENS tras un incidente?

La medida op.exp.9 obliga a registrar toda la gestión del incidente: informes iniciales, intermedios y finales, actuaciones de emergencia y modificaciones del sistema. Cuando el incidente pueda derivar en acciones disciplinarias o penales, hay que preservar evidencias admisibles ante un tribunal. La auditoría revisa el procedimiento, el registro de incidentes, las notificaciones realizadas y las acciones correctoras.

Fuentes

• Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad (texto consolidado, BOE)
• Anexo II del RD 311/2022 — Medidas de seguridad, incluida op.exp.7 (ens.ccn.cni.es)
• Resolución de 13 de abril de 2018 — Instrucción Técnica de Seguridad de Notificación de Incidentes de Seguridad (BOE)
• Guía CCN-STIC-817 de Gestión de Ciberincidentes (CCN-CERT)
• Directrices para la gestión de incidentes (CCN-CERT)