Contar con un procedimiento de gestión de incidentes no es una cuestión de voluntarismo: es un requisito formal del Esquema Nacional de Seguridad recogido en el control op.exp.7. La diferencia entre una organización que gestiona un incidente de forma ordenada y una que reacciona de forma caótica no reside en la sofisticación de sus herramientas, sino en haber definido y practicado el procedimiento antes de que el incidente ocurra.
Por qué el ENS exige un procedimiento formal
El control op.exp.7 del Anexo II del RD 311/2022 establece que deben existir procedimientos de actuación para la detección, análisis, contención y recuperación frente a incidentes de seguridad. Este control aplica a sistemas de categoría BÁSICA, MEDIA y ALTA, aunque con requisitos más exigentes en los niveles más altos.
La exigencia de formalidad sirve a varios propósitos: garantizar que la respuesta es predecible y reproducible independientemente de quién esté disponible en el momento del incidente, asegurar que se recopilan las evidencias necesarias para el análisis posterior y para posibles procedimientos legales, y facilitar el cumplimiento de las obligaciones de notificación a organismos externos dentro de los plazos legales.
Qué es un incidente de seguridad en el contexto del ENS
El ENS define el incidente de seguridad como cualquier evento que tenga o pueda tener como resultado un acceso no autorizado, la divulgación, modificación o destrucción no autorizada de información, o la interrupción de los servicios de información. Esta definición abarca tanto los incidentes de origen malicioso (ciberataques, ransomware, intrusiones) como los accidentales (fallos de hardware, errores de configuración, pérdida de dispositivos).
Es importante distinguir el incidente de seguridad del incidente de disponibilidad (o avería). Un servidor que cae por un fallo de hardware sin ningún componente de seguridad es un incidente de disponibilidad, no de seguridad, y su gestión corresponde al área de operaciones TI, aunque puede acabar derivando en un incidente de seguridad si la caída facilita un acceso no autorizado. La distinción debe quedar clara en el procedimiento para que cada tipo de evento siga el canal correcto desde el primer momento.
Fase 1: Detección y registro
La detección puede producirse por múltiples vías: alertas del sistema de monitorización, reportes de usuarios, notificaciones de proveedores, comunicaciones del CCN-CERT o de terceros (clientes, organismos de supervisión). El procedimiento debe establecer canales claros para que cualquier empleado pueda reportar un evento sospechoso sin necesidad de conocer si es o no un incidente: esa clasificación la hace el equipo técnico.
El primer paso tras la detección es el registro del evento en el sistema de gestión de incidentes, con la mayor cantidad de información disponible en ese momento: fecha y hora de detección, canal de detección, descripción del evento, sistemas afectados (o potencialmente afectados), y la identidad del usuario o sistema que ha generado la alerta. Este registro inicial es la base de toda la gestión posterior y debe preservarse sin modificación.
Fase 2: Análisis y priorización
Una vez registrado el evento, el equipo técnico de respuesta realiza el análisis inicial para determinar si se trata efectivamente de un incidente de seguridad, su naturaleza (malicioso o accidental), el alcance potencial y el nivel de gravedad.
La clasificación de la gravedad sigue habitualmente la taxonomía del CCN-CERT, que distingue cinco niveles: crítico, muy alto, alto, medio y bajo. Esta clasificación determina la urgencia de la respuesta y si el incidente debe notificarse al CCN-CERT. Para los incidentes en sistemas de información de la Administración, la Guía CCN-STIC 817 (Gestión de Ciberincidentes) proporciona los criterios de clasificación de referencia.
Fase 3: Contención
La contención tiene como objetivo limitar el impacto del incidente e impedir su propagación, sin destruir evidencias que puedan ser necesarias para el análisis posterior y para posibles actuaciones legales. Esta fase puede incluir la desconexión de sistemas comprometidos de la red, el bloqueo de cuentas de usuario afectadas, la aplicación de reglas de cortafuegos para bloquear tráfico malicioso, o el aislamiento de segmentos de red.
El procedimiento debe contemplar las medidas de contención específicas para los tipos de incidente más probables en el entorno de la organización, evitando que el equipo tenga que improvisar en el momento de mayor presión. Para incidentes de ransomware, por ejemplo, la contención inmediata mediante desconexión de red de los equipos afectados es crítica para evitar la propagación al resto del entorno.
Fase 4: Erradicación
Una vez contenido el incidente, el siguiente paso es eliminar la causa raíz. En un ataque de malware, esto implica la eliminación del código malicioso y de los mecanismos de persistencia utilizados por el atacante. En una intrusión, implica cerrar el vector de entrada (parchear la vulnerabilidad explotada, revocar credenciales comprometidas, corregir la configuración incorrecta).
Esta fase requiere un análisis técnico más profundo que la contención, y puede necesitar la participación de especialistas en análisis forense. Es importante no iniciar la recuperación sin haber completado la erradicación: restaurar un sistema sin haber cerrado el vector de entrada puede llevar a una reinfección inmediata.
Fase 5: Recuperación
La recuperación consiste en restaurar los sistemas y servicios afectados a su estado operativo normal. Esto puede implicar la restauración desde copias de seguridad verificadas (anteriores al incidente), la reinstalación de sistemas operativos y aplicaciones, o la restauración de configuraciones. Antes de reconectar los sistemas recuperados al entorno de producción, deben realizarse verificaciones de integridad para asegurar que no quedan rastros del compromiso.
El procedimiento debe especificar los criterios que determinan cuándo un sistema puede considerarse recuperado y apto para volver a producción, para evitar decisiones apresuradas bajo presión de continuidad del servicio.
Fase 6: Lecciones aprendidas
Una vez resuelto el incidente, debe elaborarse un informe post-incidente que documente la cronología del evento, el análisis de la causa raíz, las acciones de respuesta tomadas, el impacto final y las lecciones aprendidas. Este informe debe derivar en un plan de acción con las medidas correctivas identificadas para reducir la probabilidad o el impacto de incidentes similares en el futuro.
Las lecciones aprendidas deben realimentar tanto el análisis de riesgos (añadiendo o actualizando amenazas y vulnerabilidades identificadas) como el propio procedimiento de gestión de incidentes (mejorando los pasos que no funcionaron bien durante la respuesta).
Notificación obligatoria al CCN-CERT
El artículo 36 del RD 311/2022 establece la obligación de notificar al CCN-CERT los incidentes que afecten a sistemas de información de la Administración incluidos en el ámbito de aplicación del ENS. La notificación debe realizarse a través de LUCIA (Listado Unificado de Coordinación de Incidentes y Amenazas), la plataforma de notificación del CCN-CERT accesible en su portal.
No todos los incidentes deben notificarse: la obligación se activa para incidentes que alcancen los niveles de gravedad más altos según la taxonomía del CCN-CERT. La Guía CCN-STIC 817 especifica los criterios concretos. Como regla general, cualquier incidente que afecte significativamente a la disponibilidad, integridad o confidencialidad de información clasificada o de datos de carácter personal en volumen significativo debe notificarse.
El plazo de notificación no está fijado en una cifra única: la norma exige que se notifique en el menor tiempo posible, siendo la práctica habitual la notificación en las primeras horas para incidentes críticos y en el plazo máximo de 24 horas para los de gravedad alta.
Roles y responsabilidades en el equipo de respuesta
El procedimiento debe asignar roles claros: un coordinador de incidentes (habitualmente el responsable de seguridad), un equipo técnico de respuesta, un interlocutor con dirección para la toma de decisiones de impacto organizativo, y un responsable de comunicación externa cuando sea necesario. En organizaciones sin equipo interno suficiente, parte de estos roles puede cubrirse mediante un contrato de servicio con una empresa especializada en respuesta a incidentes.
Integración con el RGPD: notificación de brechas de datos
Cuando un incidente de seguridad involucra una brecha de datos personales (acceso no autorizado, pérdida, destrucción o divulgación de datos personales), se activa la obligación de notificación a la Agencia Española de Protección de Datos establecida en el artículo 33 del RGPD. El plazo es de 72 horas desde que la organización tiene conocimiento de la brecha.
El procedimiento de gestión de incidentes debe incluir un punto de decisión explícito para determinar si el incidente constituye una brecha de datos personales, y si la brecha tiene alto riesgo para los derechos de los afectados (en cuyo caso también deben ser notificados directamente según el artículo 34 del RGPD). La coordinación entre el responsable de seguridad y el Delegado de Protección de Datos debe estar prevista en el procedimiento para garantizar que los plazos se cumplen incluso cuando el incidente se detecta en horario no hábil.
¿Tu procedimiento de incidentes cumple el ENS?
Revisamos tu procedimiento de gestión de incidentes, lo adaptamos a los requisitos del control op.exp.7 y lo integramos con tus obligaciones RGPD. Todo en un servicio coordinado.
Cuéntanos tu caso de ENS →Respuesta en menos de 24 h. Sin compromiso.