Cuando algo pasa: clasificar, notificar y responder. Y LUCÍA.
♙Miguel Ángel Carriazo
▣18 junio 2026
◷13 min de lectura
LEE ESTA GUÍA CUANDO...
Necesites trabajar sobre ciberincidentes dentro del ENS.
En vez de buscar una frase aislada, sigue el recorrido de la guía y relaciona cada conclusión con el sistema, el responsable y la evidencia que debería existir.
CCN-STIC 817 · Ciberincidentes
Dónde encaja esta guía en una revisión práctica
Utiliza la guía para orientar la revisión y contrasta siempre la versión vigente en el portal oficial del CCN-CERT.
Qué es
Qué es y para qué vale
La CCN-STIC 817 establece cómo gestionar ciberincidentes en el marco del ENS: su clasificación por peligrosidad e impacto, los niveles, los plazos y la notificación al CCN-CERT, canalizada habitualmente a través de la plataforma LUCÍA. Conecta el cumplimiento del ENS con la obligación de detectar, reportar y responder.
Es una de las guías más operativas de la serie. No basta con tener un procedimiento «en papel»: el día del incidente, lo que cuenta es haber clasificado bien, notificado en plazo y respondido con un proceso ensayado. Además, es el punto de conexión natural con NIS2, que endurece las obligaciones de notificación.
La guía se alinea con el Real Decreto-ley 12/2018 de Seguridad de las Redes y Sistemas de Información y con la Guía Nacional de Notificación y Gestión de Ciberincidentes. El CCN-CERT es el nodo de coordinación nacional para el sector público.
Mi lectura
Un incidente empieza a degradarse cuando cada equipo construye su propia línea temporal.
La 817 es una guía que yo leería con Operaciones, Seguridad, Legal y Continuidad en la misma mesa. Porque la respuesta a incidentes se rompe en las interfaces. El SOC detecta, sistemas contiene, negocio descubre impacto, un proveedor aporta una pieza y alguien empieza a preguntar si hay que notificar.
La herramienta más básica y más poderosa es una línea temporal común. Qué ocurrió, cuándo se conoció, qué hipótesis existían, qué decisión se tomó y con qué información. Sin eso, el post-incidente termina reconstruyéndose desde chats y recuerdos.
Durante un incidente no necesito que todo el mundo tenga toda la información. Necesito que exista una fuente de verdad y una estructura clara de decisión.
CCN-STIC 817 · Respuesta coordinada
Cómo convertir señales dispersas en una cronología y una decisión
Lectura técnica GRCREAL: una manera práctica de conectar la guía con arquitectura, operación y evidencia.
Explicación técnica
Qué me interesa técnicamente de esta guía
La 817 se vuelve especialmente valiosa cuando bajas a la mecánica de la respuesta. Detección, clasificación, contención, erradicación, recuperación, preservación de evidencias y aprendizaje posterior no son fases teóricas; son dependencias entre equipos, herramientas y decisiones tomadas con información incompleta.
Técnicamente, para mí hay tres ejes que sostienen la respuesta: una fuente de cronología común, claridad de roles y capacidad para preservar información útil antes de que el entorno cambie. El primer eje evita versiones contradictorias; el segundo evita parálisis; el tercero protege la posibilidad de entender qué pasó y qué sigue expuesto.
La guía gana muchísima fuerza si se usa junto con casos reales o tabletop, porque ahí aparece la verdadera dificultad: alertas ambiguas, proveedores lentos, negocio presionando y necesidad de decidir aunque todavía falte contexto.
Datos técnicos que no deberían faltar
Timestamps normalizados, origen de la alerta, activos afectados, cuentas, indicadores, acciones ejecutadas, decisiones, responsables y evidencias preservadas. La cronología debería distinguir hecho observado, hipótesis y decisión.
También registraría cambios realizados durante la contención para poder revertir o analizar su impacto. La respuesta modifica el entorno y eso puede destruir contexto si no se documenta.
Error habitual
Dónde suele torcerse en proyectos reales
DONDE SUELE TORCERSE
Pensar que la contención técnica equivale a cierre del incidente. Muchas organizaciones desactivan el indicador de crisis en cuanto el vector principal está contenido, sin haber evaluado persistencia, impacto, necesidad de notificación o acciones de erradicación y seguimiento.
Otro error muy frecuente es no decidir a tiempo la preservación de evidencias, lo que complica enormemente cualquier análisis forense posterior.
Ejemplo práctico
Cómo lo aterrizaría en un caso real
CASO
Supón una alerta de posible acceso indebido a un servidor crítico. El SOC abre la investigación, Sistemas aísla el nodo, negocio pregunta por la disponibilidad y Legal necesita saber si existen obligaciones de reporte. Si cada equipo documenta por separado y no existe un coordinador claro, la cronología se fragmenta y las decisiones se contradicen.
Yo pediría siempre una línea temporal viva, un responsable de coordinación y una decisión explícita sobre evidencias: qué se conserva, quién lo hace y con qué objetivo. Esa base marca la diferencia entre reaccionar y realmente gestionar el incidente.
Ejemplo técnico de infraestructura
Alerta EDR en un servidor virtual crítico
EJEMPLO TÉCNICO · INFRAESTRUCTURA
Componentes implicados en el caso
INFRA
El EDR detecta ejecución sospechosa en una máquina virtual que presta un servicio crítico. Aislarla reduce el riesgo de propagación, pero afecta a disponibilidad y puede destruir conexiones necesarias para comprender el incidente.
Arquitectura técnica: EDR, hipervisor, SIEM, almacenamiento, copias, red y cuentas privilegiadas. Decisiones: aislar VM o segmento, capturar memoria, preservar discos, bloquear credenciales y activar continuidad. Cronología: separar alerta, hechos confirmados, hipótesis y acciones. Cierre: recuperación validada, credenciales rotadas, persistencia descartada y lecciones incorporadas.
Pregunta incómoda
¿Quién puede declarar que el incidente ha terminado?
NO RESPONDAS CON LA POLÍTICA
Contener un vector no significa recuperar el servicio, erradicar persistencia ni cerrar obligaciones regulatorias. La decisión de cierre debería considerar técnica, negocio y acciones posteriores.
Preguntaría también quién conserva evidencias y cuándo se decide activar apoyo forense. Si esa decisión se toma tarde, pueden perderse trazas críticas.
Ref.
Qué pediría
Qué necesito ver
GR-01
Cronología
Detección, conocimiento, decisiones y comunicaciones.
GR-02
Roles
Mando, coordinación técnica, negocio y escalado.
GR-03
Evidencia
Preservación, cadena de custodia y fuentes recogidas.
GR-04
Aprendizaje
Causa, acciones y cambios verificados tras el incidente.
Mi enfoque
Cómo la aterrizaría yo en un entorno real
GRCREAL
Haría tabletop con escenarios incompletos y cambiantes. No avisaría desde el minuto uno de la gravedad real. Quiero ver cuándo escala la organización, cómo conecta impacto y quién toma decisiones con incertidumbre.
El playbook bonito se valida cuando la información llega tarde, el proveedor no responde y alguien tiene que decidir igualmente.
Contenido
Qué contiene la guía
La clasificación de ciberincidentes por peligrosidad e impacto, y sus niveles (BAJO, MEDIO, ALTO, MUY ALTO, CRÍTICO).
El procedimiento de gestión: detección, análisis, contención, erradicación y recuperación.
Los plazos y el canal de notificación al CCN-CERT (LUCÍA).
Los criterios para decidir qué incidentes son de notificación obligatoria.
La articulación con la respuesta a incidentes y la mejora continua.
La taxonomía de incidentes (contenido abusivo, contenido dañino, obtención de información, intento de intrusión, intrusión, disponibilidad, compromiso de la información, fraude, vulnerable, otros, APT).
Conceptos
Conceptos clave que debes manejar
Clasificación por peligrosidad
Escala que estima la gravedad técnica del incidente: BAJO, MEDIO, ALTO, MUY ALTO, CRÍTICO. Determina la urgencia de la respuesta y los plazos de notificación.
Nivel de impacto
Estimación del daño a la organización, servicios o ciudadanos. Se valora en función de la categoría del sistema afectado, número de máquinas, tiempo de resolución, daño reputacional y afectación a la seguridad nacional.
LUCÍA
Plataforma del CCN-CERT para la gestión y notificación de incidentes. Permite la sincronización entre organizaciones y el CCN-CERT, con trazabilidad completa de los incidentes.
Notificación obligatoria
Comunicación al CCN-CERT exigida para incidentes de nivel ALTO, MUY ALTO o CRÍTICO. Los niveles BAJO y MEDIO no requieren notificación obligatoria.
Plan de Respuesta a Ciberincidentes
Conjunto predeterminado y ordenado de instrucciones y procedimientos para detectar, responder y limitar las consecuencias de un ciberincidente.
Alcance
A quién aplica y cuándo entra en juego
Aplica a toda entidad bajo ENS y se vuelve crítica en categorías MEDIA y ALTA, donde ciertos incidentes son de notificación obligatoria en plazos tasados. Es, además, donde el ENS y NIS2 se encuentran: conviene gestionar ambos de forma coordinada. También aplica a operadores de servicios esenciales y proveedores de servicios digitales según el RD-ley 12/2018.
Implantación
Cómo lo implanta una empresa, paso a paso
Define tu procedimiento alineado con la 817Documenta el ciclo completo: detección, análisis, contención, erradicación, recuperación y lecciones aprendidas. Incluye las fases de PREPARACIÓN, DETECCIÓN Y ANÁLISIS, CONTENCIÓN Y ERRADICACIÓN, y ACTIVIDAD POST-CIBERINCIDENTE.
Adopta la clasificación oficialUsa la clasificación de peligrosidad e impacto de la guía, no criterios propios. Así hablas el mismo idioma que el CCN-CERT. La taxonomía incluye 11 categorías (contenido abusivo, dañino, obtención de información, etc.).
Establece el canal y los plazosConfigura la notificación al CCN-CERT (LUCÍA) y ten claros los plazos según el nivel del incidente. CRÍTICO: 120 días, MUY ALTO: 90 días, ALTO: 45 días, MEDIO: 30 días, BAJO: 21 días.
Conecta con NIS2Si te aplica NIS2, alinea los plazos de notificación (24h/72h) para no duplicar ni incumplir. El CCN-CERT es el CSIRT de referencia para el sector público.
Ensaya el procesoHaz simulacros. Un procedimiento sin ensayar falla justo cuando más lo necesitas. Realiza pruebas periódicas del Plan de Respuesta a Ciberincidentes.
Auditoría
Para qué sirve en una auditoría
El auditor revisa el procedimiento, la clasificación y los registros de incidentes.
Comprueba que las notificaciones obligatorias se hicieron en plazo.
Verifica la conexión con el canal del CCN-CERT (LUCÍA).
Un proceso solo «en papel», sin registros ni ensayos, es hallazgo.
La trazabilidad de cada incidente (qué pasó, qué se hizo) es clave.
Verifica que se ha realizado el análisis de causa raíz y las lecciones aprendidas.
Serie 800
Relación con otras guías de la serie
CCN-STIC 804804 — La gestión de incidentes es una medida del marco operacional (op.exp.7).
CCN-STIC 823823 — En cloud, la detección y respuesta dependen también del proveedor.
CCN-STIC 801801 — El Responsable de Seguridad lidera la respuesta a incidentes.
CCN-STIC 815 — Métricas e indicadores para la gestión de incidentes.
Mapeo
Equivalencia con otros marcos
Cómo se conecta esta guía con los marcos que probablemente ya manejas:
Aspecto en el ENS
ISO 27001
NIS2 / DORA
Gestión y notificación de incidentes
ISO 27001: A.5.24–A.5.28 (gestión de incidentes)
NIS2: notificación en 24h/72h (art. 23)
Clasificación por impacto
ISO/IEC 27035 (gestión de incidentes)
DORA: clasificación y reporte de incidentes TIC
Respuesta y recuperación
ISO 22301 (continuidad)
DORA: respuesta y recuperación
Plan de Respuesta a Incidentes
ISO 27001: plan de respuesta (A.5.26)
NIS2: planes de respuesta
Recolección de evidencias
ISO 27001: evidencias (A.5.28)
DORA: conservación de registros
Sin humo
Errores típicos
No tener definidos los plazos de notificación.
Clasificar incidentes con criterios propios en vez de los oficiales.
No conectar el proceso del ENS con las obligaciones de NIS2.
Tener procedimiento pero no ensayarlo nunca.
No registrar las lecciones aprendidas ni actualizar los procedimientos.
No diferenciar entre evento de seguridad e incidente de seguridad.
Checklist
Checklist práctico
Procedimiento de incidentes alineado con la 817.
Clasificación oficial de peligrosidad e impacto adoptada.
Canal y plazos de notificación al CCN-CERT definidos.
Coordinación con NIS2 (si aplica).
Proceso ensayado y con registros de incidentes.
Plan de Respuesta a Ciberincidentes documentado y aprobado.
Métricas e indicadores definidos (Anexo A).
Ficha
Ficha y enlace oficial
Esta es una lectura práctica de GRCreal, no la guía oficial. Consulta siempre la versión vigente en el portal del CCN-CERT, ya que estas guías se actualizan periódicamente (esta ficha: publicada Ago 2012, actualizada Abr 2020).
La guía establece una escala de cinco niveles para la peligrosidad de los ciberincidentes:
CRÍTICO: Afecta a la Seguridad Nacional, sistemas SECRETO, infraestructuras críticas. Más de 100 máquinas de categoría MEDIA. Resolución > 50 jornadas-persona.
MUY ALTO: Afecta a sistemas RESERVADO, servicios esenciales. Más de 75 máquinas de categoría BÁSICA o 50 de MEDIA. Resolución 30-100 jornadas-persona.
ALTO: Afecta a más del 50% de los sistemas. Resolución 5-30 jornadas-persona. Daños reputacionales de difícil reparación.
MEDIO: Afecta a más del 20% de los sistemas. Resolución 1-5 jornadas-persona. Daños reputacionales apreciables.
BAJO: Afecta a sistemas de la organización. Resolución < 1 jornada-persona. Daños reputacionales puntuales.
Plazos de cierre sin respuesta: CRÍTICO (120 días), MUY ALTO (90), ALTO (45), MEDIO (30), BAJO (21).
Taxonomía
Taxonomía de ciberincidentes
La guía clasifica los ciberincidentes en las siguientes categorías:
Contenido abusivo: Spam, delito de odio, pornografía infantil, contenido sexual o violento inadecuado.
Contenido dañino: Distribución de malware, sistemas infectados, servidores C&C.
Obtención de información: Configuración de malware, escaneo de redes (scanning), análisis de paquetes (sniffing).
Intento de intrusión: Ingeniería social, explotación de vulnerabilidades (CVE), acceso con vulneración de credenciales.
Intrusión: Compromiso de cuenta (con/sin privilegios), compromiso de aplicaciones, robo físico.
Disponibilidad: DoS, DDoS, mala configuración, sabotaje físico, interrupciones por causas ajenas.
Compromiso de la información: Acceso no autorizado, modificación no autorizada, pérdida de datos.
Fraude: Uso no autorizado de recursos, derechos de autor, suplantación, phishing.
Vulnerable: Criptografía débil, amplificador DDoS, servicios con acceso potencial no deseado, sistema vulnerable.
APT: Ataques dirigidos con mecanismos sofisticados de ocultación y persistencia.
LUCIA
LUCIA: Herramienta de gestión de incidentes
LUCIA (Listado Unificado de Coordinación de Incidentes y Amenazas) es la herramienta del CCN-CERT para la gestión de ciberincidentes:
Objetivos: Dotar a los organismos de una plataforma única y distribuida para el tratamiento de ciberincidentes, conforme al ENS.
Características: Basada en Request Tracker (RT) con extensión RT-IR. Información sincronizada y compartida entre organismos. Servicios REST para integración. Comunicación segura basada en modelo transaccional.
Arquitectura: Instancias locales sincronizadas con el nodo central del CCN-CERT. Sincronización unidireccional (organismo → CCN-CERT) y bidireccional (para SAT-INET, SAT-SARA, SAT-ICS).
Métricas e indicadores: La guía incluye en el Anexo A métricas de implantación, eficacia y eficiencia:
M1: Alcance del sistema de gestión de incidentes.
M2/M3: Resolución de incidentes de nivel ALTO/MEDIO.
M4: Recursos consumidos (horas-persona).
M5/M6: Estado de cierre de incidentes (incluyendo MUY ALTO/CRÍTICO).
Ficha y enlace oficial
Contrasta esta lectura con la publicación del CCN-CERT
La guía oficial sigue mandando. Aquí queda la ficha documental y el acceso directo a la fuente para cerrar la lectura con el contraste adecuado.
ℹ️ Resumen práctico de GRCreal. Consulta siempre la versión oficial vigente en el portal del CCN-CERT.
Resumen realizado a fecha 29/06/2026 con la información disponible en https://www.ccn-cert.cni.es/es/guias.html. Las fechas de publicación y actualización proceden del portal oficial.