El ENS exige un proceso de gestión de incidentes con fases claras — preparación, detección, contención, erradicación, recuperación y lecciones aprendidas — pero la mayoría de organizaciones no las tiene definidas hasta que sufre el primer incidente real y las improvisa sobre la marcha.
Cuando se produce un incidente de ciberseguridad, cada minuto cuenta. Una respuesta rápida, coordinada y siguiendo un protocolo establecido puede significar la diferencia entre un incidente menor y una catástrofe. El ENS dedica varios controles a la gestión de incidentes (op.exp.7, op.exp.9 y op.mon), que exigen un proceso interno documentado, con responsables asignados en cada fase. Esta guía detalla cómo diseñar e implementar ese proceso paso a paso, para que funcione cuando realmente se necesite.
El contexto general del marco lo desarrollo en la guía completa del Esquema Nacional de Seguridad; aquí me centro en el proceso de respuesta a incidentes.
- ¿Cuáles son los requisitos de ENS en gestión de incidentes?
- Fase 1: preparación
- Fase 2: detección e identificación
- Fase 3: clasificación y priorización
¿Cuáles son los requisitos de ENS en gestión de incidentes?
El ENS establece requisitos de gestión de incidentes en varios controles. El control op.exp.7 (gestión de incidencias) exige un procedimiento documentado para la gestión del ciclo de vida completo de los incidentes. El control op.exp.9 (registro de la gestión de incidentes) requiere mantener un registro detallado de cada incidente. Y la familia op.mon (monitorización) establece las capacidades de detección necesarias.
En categoría BÁSICA, se exige un procedimiento básico de gestión de incidentes y registro de los mismos. En categoría MEDIA, se requieren además capacidades de detección automatizada, clasificación según la taxonomía del CCN-CERT, y notificación obligatoria al CCN-CERT a través de la plataforma LUCIA. En categoría ALTA, se exigen además tiempos de respuesta definidos, capacidades de análisis forense y planes de comunicación de crisis.
El ciclo de vida de un incidente de seguridad
Fase 1: preparación
La preparación es todo lo que se hace antes de que ocurra un incidente. Incluye definir el equipo de respuesta a incidentes (quién participa y con qué roles), establecer procedimientos de respuesta documentados y accesibles, configurar las herramientas de detección (SIEM, IDS/IPS, EDR), establecer canales de comunicación de emergencia que funcionen si los sistemas habituales están comprometidos, mantener actualizada la lista de contactos de emergencia (CCN-CERT, INCIBE, fuerzas de seguridad, proveedores clave), y realizar simulacros periódicos.
Fase 2: detección e identificación
La detección puede producirse por diversas vías: alertas del SIEM o IDS, notificación de un usuario, comunicación de un proveedor, alerta del CCN-CERT, o descubrimiento durante una auditoría. Una vez detectada una anomalía, debe determinarse si se trata realmente de un incidente de seguridad y cuál es su alcance inicial.
Fase 3: clasificación y priorización
Todo incidente debe clasificarse según la taxonomía del CCN-CERT, que establece categorías de peligrosidad y tipos de incidente. La clasificación determina la prioridad de respuesta y las obligaciones de notificación. Los incidentes se clasifican por su peligrosidad en críticos, muy altos, altos, medios y bajos.
Fase 4: contención
La contención tiene como objetivo limitar el daño y evitar que el incidente se extienda. Las medidas de contención pueden incluir aislar sistemas comprometidos de la red, bloquear cuentas comprometidas, redirigir tráfico, activar reglas de firewall de emergencia o apagar sistemas si es necesario.
La contención debe ser rápida pero inteligente. Un aislamiento precipitado puede destruir evidencias que serán necesarias para el análisis posterior. Es recomendable crear imágenes forenses de los sistemas comprometidos antes de realizar la contención definitiva.
Fase 5: erradicación
Una vez contenido el incidente, se procede a eliminar la causa raíz. Esto puede implicar eliminar malware, corregir vulnerabilidades explotadas, restaurar sistemas desde copias de seguridad limpias, o reconstruir sistemas comprometidos desde cero.
Fase 6: recuperación
La recuperación consiste en restablecer los servicios afectados a su funcionamiento normal. Es importante hacerlo de forma controlada, verificando que los sistemas restaurados están limpios y seguros antes de reconectarlos a la red de producción.
Fase 7: lecciones aprendidas
Después de cada incidente significativo, se debe realizar un análisis post-incidente que documente qué ocurrió, cómo se detectó, qué se hizo bien y qué se puede mejorar, y qué medidas preventivas se van a implementar para evitar que se repita.
Registro del incidente y cierre del expediente
Para sistemas sujetos al ENS (categoría MEDIA y ALTA), la notificación de incidentes al CCN-CERT es obligatoria. La notificación se realiza a través de la plataforma LUCIA (Listado Unificado de Coordinación de Incidentes y Amenazas), desarrollada por el CCN.
LUCIA permite registrar el incidente con su clasificación, mantener actualizado el estado del incidente durante su gestión, comunicarse con el CCN-CERT para recibir apoyo técnico, y generar informes de cierre.
Esta guía se centra en el proceso interno de gestión, no en el detalle de plazos y procedimientos de notificación externa: la clasificación de peligrosidad que asignes en la Fase 3 es la que después determinará si el incidente debe notificarse y con qué urgencia.
Relación con otras obligaciones de notificación
Un incidente de seguridad puede generar obligaciones de notificación adicionales. Si afecta a datos personales, debe notificarse a la AEPD en un plazo máximo de 72 horas conforme al RGPD. Si afecta a un operador de servicios esenciales o importante, debe notificarse también en el marco de la Directiva el marco europeo NIS2. Y si constituye un delito, debe ponerse en conocimiento de las fuerzas y cuerpos de seguridad del Estado.
Es fundamental que el procedimiento de gestión de incidentes contemple todas estas obligaciones de notificación y establezca quién es responsable de cada una.
Encajar unas obligaciones con otras es donde más se enredan las organizaciones. Cómo se solapan el ENS, el RGPD y NIS2 lo ordeno en el mapa de la normativa de ciberseguridad en España, y el procedimiento de notificación de incidentes al CCN-CERT lo detallo por separado.
Indicadores de gestión de incidentes
Para demostrar ante los auditores ENS que su proceso de gestión de incidentes funciona, mantenga un registro que incluya el número de incidentes por tipo y peligrosidad, el tiempo medio de detección, el tiempo medio de contención, el tiempo medio de resolución, el porcentaje de incidentes notificados en plazo al CCN-CERT, y las acciones de mejora derivadas de las lecciones aprendidas.
Si está montando este proceso en su organización y quiere una lectura externa antes de darlo por bueno, escríbame y lo revisamos: cuénteme en qué categoría del ENS encaja su sistema y qué tiene documentado ya, y le respondo diciéndole qué fases de las siete veo cubiertas, cuáles no y por dónde empezaría yo. Le contesto yo mismo, y sabrá a qué atenerse antes de invertir un euro.
Si prefiere tener el procedimiento de incidentes montado y probado antes de necesitarlo, puedo dejárselo listo: así trabajo la consultoría ENS.
Autoría: Ángel Ortega Castro · consultor independiente en estrategia, calidad y digitalización para PYMEs. Relacionado: Análisis de Riesgos MAGERIT para ENS: Guía Práctica.
¿Necesitas ayuda con esto?
Trabaja conmigo en Adecuación al ENS
Consultoría a medida en adecuación al ENS. Primera sesión sin coste.
Agendar sesión →Herramientas gratuitas relacionadas
Sin registro y con fuentes oficiales. Comprueba tu caso en 2 minutos.