Gestión de incidentes según el ENS y coordinación con CCN-CERT

Cuando se produce un incidente de seguridad en un sistema ENS, no basta con “arreglarlo y seguir”. El RD 311/2022 exige un proceso formal de detección, clasificación, respuesta, notificación al CCN-CERT y revisión posterior. Esta es una de las medidas donde más brecha encontramos: sistemas que detectan incidentes pero no los documentan, ni los notifican, ni aprenden de ellos.

Qué exige el ENS

La medida op.exp.7 (Gestión de incidentes) obliga a contar con un proceso documentado que cubra todo el ciclo de vida. En categorías Media y Alta se añaden requisitos de tiempo de respuesta, priorización y notificación externa.

Complementariamente, el artículo 33 del RD 311/2022 y la Instrucción Técnica de Seguridad correspondiente establecen la obligación de notificar al CCN-CERT los incidentes que afecten a sistemas ENS conforme a los criterios de impacto.

El ciclo de vida completo

Detección → Triaje → Contención → Erradicación → Recuperación → Lecciones aprendidas
                                                      ↓
                                            Notificación CCN-CERT
                                            (si procede)

Cada fase debe tener un responsable, un plazo máximo y un registro.

1. Detección

Fuentes típicas: alertas del SIEM, reportes de usuarios, avisos del CCN-CERT, notificaciones de proveedores, monitorización de endpoint, logs de aplicación. Todas deben canalizarse a un punto único (buzón, ticket, guardia) con trazabilidad.

2. Triaje

En los primeros 30–60 minutos se clasifica el incidente:

¿Es un falso positivo?
¿Qué activos afecta?
¿Qué dimensiones compromete (C, I, T, A, D)?
¿Qué nivel de criticidad tiene (Muy alto / Alto / Medio / Bajo)?

El CCN-CERT publica criterios de clasificación (guías CCN-STIC 817 y complementarias) que deberías adoptar directamente. Reinventarlos es trabajo perdido.

3. Contención

Acciones inmediatas: aislar sistemas, bloquear cuentas, revocar tokens, restringir accesos. Se documenta cada acción con timestamp y responsable.

4. Erradicación

Eliminar la causa raíz: limpiar malware, parchear vulnerabilidad explotada, reconfigurar controles. Esta fase no debe hacerse antes de tener evidencia forense mínima recogida.

5. Recuperación

Restaurar sistemas a producción, verificar que funcionan correctamente, monitorizar reincidencia durante un periodo.

6. Lecciones aprendidas

Reunión post-mortem en los 10 días siguientes: qué pasó, por qué, qué funcionó, qué falló, qué medidas preventivas adoptar. Se documenta y se alimenta al Plan de Tratamiento de Riesgos.

Notificación al CCN-CERT

La herramienta principal para notificar es LUCIA (Sistema de Gestión Federada de Tickets de Ciberincidentes). Criterios resumidos de notificación:

Obligatoria para incidentes de nivel Medio o superior en sistemas ENS Media/Alta.
Plazo: lo antes posible desde la detección (no esperar al cierre).
Información mínima: identificación del sistema, tipo de incidente, afectación, acciones iniciales.
Actualización: se actualiza con información conforme avanza la investigación.
Cierre: una vez resuelto, con resumen final y lecciones.

La no notificación es una no conformidad grave en auditoría y puede tener consecuencias más allá de ésta.

Clasificación de incidentes

El CCN clasifica los incidentes en familias:

Contenido abusivo.
Código dañino.
Recopilación de información.
Intentos de intrusión.
Intrusión.
Disponibilidad.
Compromiso de la información.
Fraude.
Vulnerable.
Otros.

Usar esta taxonomía desde el principio facilita el reporte y permite comparar con estadísticas sectoriales.

Integración con herramientas

Lo que suele funcionar bien:

SIEM/XDR como origen técnico.
ITSM (Jira, ServiceNow, GLPI) como backbone de tickets.
Playbooks documentados por tipo de incidente.
Canal de comunicación seguro (Signal, Element, Teams con cifrado) para el comité de crisis.
Plantilla de notificación LUCIA precargada.

Si tienes SIEM pero no ITSM, o al revés, el proceso cojea. La integración no hace falta que sea automática (API), pero sí que los roles responsables sepan dónde vive la información.

Errores frecuentes

No documentar incidentes “menores”. El auditor pedirá muestras. Si nunca hay registros, algo falla en detección o en cultura.
No escalar a la alta dirección. Los incidentes de nivel alto deben tener comunicación al Responsable de la Información y al órgano de gobierno.
Notificar tarde al CCN-CERT. La obligación es notificar temprano, aunque no tengas toda la información.
Cerrar sin post-mortem. Perdida de oportunidad de mejora. El auditor lo detecta.
No practicar con simulacros. Un proceso que no se ha ensayado nunca falla bajo presión.

Métricas recomendadas

Número de incidentes por mes y por tipo.
Tiempo medio de detección (MTTD).
Tiempo medio de contención (MTTC).
Tiempo medio de resolución (MTTR).
Incidentes notificados a CCN-CERT / total.
Incidentes con lecciones aprendidas documentadas.

Estas métricas alimentan el cuadro de mando de seguridad que revisa el Comité.

Relación con otras obligaciones

La notificación al CCN-CERT no exime de otras obligaciones:

RGPD (art. 33): notificación a la AEPD si hay datos personales afectados.
NIS2 (cuando aplique): notificación al CSIRT nacional.
Contratos: notificación al cliente en plazos pactados.
Inventario interno: registro del incidente con plazo de conservación mínimo.

Define de una vez todos los canales, para no improvisar en el momento.

Recomendación final

Un proceso de gestión de incidentes maduro no se construye en un sprint. Lo que se puede hacer desde el día 1: tener buzón único de notificación, tener dos personas capaces de activar el procedimiento, tener plantillas mínimas de triaje y de comunicación al CCN-CERT. Sobre esa base se puede evolucionar con cada incidente real o simulado.