Idioma / Language: Español · English
Las herramientas del CCN: SAT, LUCIA, REYES y AMPARO, o cómo queda registrado un ciberataque
Lo prometido es deuda y analizamos algunas de las herramientas más importantes del CCN.
Cuando un ciberataque termina, queda el silencio de los servidores apagados y queda otra cosa menos visible: un expediente. Alguien abrió un ticket a las tres y cuarto de la madrugada, alguien clasificó el incidente, alguien anotó una dirección IP en un repositorio compartido, alguien remitió un aviso al organismo de referencia y alguien, meses antes, había firmado una declaración de conformidad. Esa cadena de anotaciones nace en herramientas concretas, con nombre propio, y es el material con el que después se reconstruye lo ocurrido ante un auditor, ante la Agencia Española de Protección de Datos o ante un juzgado. En la Administración española, esas herramientas se llaman SAT, LUCIA, REYES y AMPARO.
Una deuda contraída en enero
En esta serie hemos recorrido el mapa del catálogo del Centro Criptológico Nacional, una selección comentada de las guías CCN-STIC útiles en investigación criminológica y forense, un caso práctico de preparación forense sobre un servidor Linux y sendos monográficos de la guía 425, dedicada al ciclo de inteligencia y al análisis de intrusiones, y de la 817, la de gestión de ciberincidentes. En aquella selección comentada quedó escrita una promes: analizar en profundidad las herramientas del ecosistema CCN.
El salto tiene su lógica. Una guía describe cómo debería hacerse algo; la herramienta es donde ese algo se hace, deja huella y adquiere fecha. Para el perito y para el jurista, la diferencia es sustancial, porque lo que se lleva a un procedimiento son registros, no buenas intenciones. Comprender qué anota cada plataforma, con qué grado de detalle y quién puede consultarlo permite saber de antemano qué documentación cabe pedir, qué se puede acreditar con ella y, sobre todo, qué no.
Cuatro nombres para las cuatro fases de un ataque
Las cuatro herramientas de las que trata este artículo no compiten entre sí: cubren momentos distintos de un mismo recorrido. El SAT, el Sistema de Alerta Temprana, vigila el tráfico y avisa cuando algo empieza a torcerse. LUCIA abre el expediente del incidente, lo clasifica según la taxonomía de la 817 y coordina la notificación al CERT gubernamental. REYES recoge los indicadores técnicos que ha dejado el atacante y los pone en común con el resto de organismos, que es la base de cualquier intento serio de atribución. Y AMPARO, con INES al lado, se ocupa del plano de la conformidad: demostrar que el sistema estaba adecuado al Esquema Nacional de Seguridad antes de que ocurriera nada.
Detección, gestión, inteligencia y cumplimiento. Los cuatro verbos que recorren el ciclo de vida de un ciberincidente tal como lo describe la propia guía 817, cada uno con su plataforma.
Conviene aclarar de entrada un punto de alcance. Estas soluciones están concebidas para el sector público y para las organizaciones de interés estratégico que se adhieren a los servicios del CCN-CERT; una pyme o un particular no van a instalarse LUCIA. El interés de conocerlas para quien trabaja fuera de la Administración es otro, y tiene dos caras: por un lado, cualquier proveedor tecnológico que preste servicio a un organismo público acaba tratando con estas herramientas, porque el ENS se extiende contractualmente a la cadena de suministro; por otro, cuando se litiga contra una administración o se peritan sus sistemas, saber qué registros existen y cómo se generan cambia por completo la calidad de la prueba que se puede solicitar.
SAT: los sensores que ven pasar el ataque
El Sistema de Alerta Temprana es el más antiguo de los cuatro. El CCN-CERT lo puso en marcha en 2008 y hoy funciona en tres variantes que responden a tres entornos distintos: SAT-SARA, desplegado sobre la red que interconecta a las administraciones públicas españolas; SAT-INET, orientado al tráfico que fluye entre la red interna de un organismo e internet; y SAT-ICS, pensado para redes de control y supervisión industrial, esto es, para infraestructuras de gestión del agua, centros sanitarios, entornos portuarios y otros sistemas cuya interrupción tiene consecuencias físicas inmediatas.
El mecanismo es sencillo de explicar y sutil en sus implicaciones. El organismo adherido instala una sonda en su red. Esa sonda observa el tráfico, aplica reglas de detección que responden a patrones de ataque conocidos, a comportamientos propios de determinado código dañino o a usos anómalos de un sistema industrial, y envía al sistema central únicamente las alertas que ha generado, sin volcar allí el contenido de las comunicaciones. La documentación pública del servicio insiste en ese matiz: la detección se apoya en el análisis del tráfico y de los flujos, sin centrarse en el contenido.
El detalle importa mucho más de lo que parece, y por dos motivos. El primero es jurídico. El análisis de metadatos de tráfico —quién habla con quién, cuándo, por qué puerto y durante cuánto tiempo— roza el terreno del secreto de las comunicaciones del artículo 18.3 de la Constitución, y el diseño del servicio está pensado precisamente para moverse en el plano de los flujos y no en el del contenido, que es donde la injerencia sería de otra naturaleza. El segundo es probatorio. Los registros de flujo son una fuente de prueba de primer orden en la investigación de intrusiones, porque permiten situar en el tiempo la primera conexión con la infraestructura del atacante, medir el volumen de datos exfiltrados y reconstruir el movimiento lateral dentro de la red, y todo ello sobrevive aunque el atacante haya borrado sus huellas en los equipos comprometidos.
En cuanto a su extensión, los datos publicados por el CCN en abril de 2024 daban 421 sondas de SAT-INET desplegadas en 414 organismos y 48 sondas de SAT-ICS en 38 organizaciones adheridas, con una tendencia de crecimiento sostenida año tras año. Son cifras que dibujan una capacidad de observación considerable sobre el perímetro digital del sector público español.
LUCIA: el expediente oficial del incidente
Si el SAT es el sensor, LUCIA es el registro. Sus siglas responden a Listado Unificado de Coordinación de Incidentes y Amenazas, y su función es dotar a los organismos y al propio CCN-CERT de una plataforma común para gestionar el ciclo de vida de un ciberincidente, desde que se detecta hasta que se cierra.
Técnicamente, LUCIA se apoya en dos piezas de software libre bien asentadas en la comunidad internacional de respuesta a incidentes: el sistema de tickets Request Tracker (RT) y su extensión específica para equipos de respuesta, Request Tracker for Incident Response (RTIR). Sobre esa base, el CCN la personalizó para cumplir sus propios procedimientos y los requisitos del ENS, alineándola con la metodología de la guía 817, y la distribuye a los organismos como una máquina virtual preconfigurada, con su documentación recogida en las guías CCN-STIC-845 en sus distintas variantes de usuario, instalación y administración. Que esté construida sobre RTIR tiene una consecuencia práctica que agradecerá cualquier perito: el modelo de datos, los estados de un ticket y la trazabilidad de cada acción son los de una herramienta conocida y auditada, lejos de cualquier caja negra.
Lo que LUCIA aporta al plano jurídico es un lenguaje común. La clasificación del incidente, su nivel de peligrosidad y su impacto se consignan con la taxonomía de la 817, la misma que sirvió de base a la guía de buenas prácticas de ENISA. Cuando un organismo dice «código dañino, tipo ransomware, peligrosidad muy alta», está diciendo exactamente lo mismo que diría cualquier otro organismo español, y eso permite comparar, agregar estadísticas y, llegado el caso, discutir en sede judicial sobre una calificación reglada en lugar de sobre impresiones.
El segundo aporte es la cronología. Cada anotación en el ticket queda fechada y atribuida a un usuario; los cierres, recordatorios y notificaciones se automatizan; y el histórico completo del expediente permite reconstruir después quién supo qué y en qué momento. Ese eje temporal es, en la práctica, la columna vertebral de cualquier discusión sobre diligencia: si la brecha afectó a datos personales, la ventana de setenta y dos horas del artículo 33 del Reglamento General de Protección de Datos empieza a contar desde que la organización tuvo conocimiento del hecho, y demostrar cuándo se tuvo ese conocimiento exige un registro que no dependa de la memoria de nadie.
El tercer elemento es la federación, y merece detenerse en él porque revela una decisión de diseño con calado jurídico. Un organismo puede desplegar su propia instancia de LUCIA y sincronizarla con la instancia central del CCN-CERT. En esa sincronización, según la arquitectura descrita en la documentación pública del sistema, los incidentes procedentes del SAT viajan completos en ambas direcciones, mientras que de los incidentes propios del organismo solo se remiten metadatos, quedando el detalle bajo su control. El sistema, además, integra el envío al CCN de los incidentes de peligrosidad muy alta y crítica en cumplimiento de las obligaciones del ENS. Dicho de otro modo: la herramienta está construida para que la Administración central conozca la dimensión del problema sin acumular, por defecto, el contenido íntegro de los expedientes ajenos.
Para el perito, la conclusión operativa es directa. Cuando se investiga un incidente sufrido por una administración pública, existe casi con seguridad un ticket en LUCIA con su clasificación, su cronología y su historial de comunicaciones, y ese expediente es una fuente documental legítima que puede solicitarse por la vía procesal correspondiente. No sustituye al análisis técnico, aunque sí ofrece el andamiaje temporal sobre el que apoyarlo.
REYES: la memoria común de los indicadores
REYES responde a un problema distinto. Un atacante que hoy golpea a un ayuntamiento suele ser el mismo que la semana pasada golpeó a una universidad y el mes que viene golpeará a una consejería, con la misma infraestructura, los mismos dominios y las mismas herramientas. Compartir esos rastros técnicos entre organismos multiplica la capacidad defensiva de todos, y ese es el propósito de la plataforma.
Su núcleo se apoya en MISP, la Malware Information Sharing Platform, el estándar de facto en el intercambio de inteligencia de amenazas, enriquecido con fuentes públicas y privadas y federado con organismos internacionales. La versión 3.0, presentada en marzo de 2019, incorporó un motor de inteligencia y un grafo de asociación que permite al analista pivotar de un indicador a otro para valorar el alcance real de una amenaza. Las cifras que el CCN publicó en abril de 2024 daban idea de su uso: más de dos mil usuarios autorizados, más de ochocientas cuarenta mil alertas generadas y varias decenas de listas negras mantenidas.
El material con el que trabaja REYES son los indicadores de compromiso, los IoC: direcciones IP, dominios, resúmenes criptográficos de ficheros maliciosos, patrones de configuración. Tres guías del catálogo se ocupan de ese ciclo y conviene tenerlas localizadas: la CCN-STIC-423 explica cómo identificar indicadores y cómo prepararlos para compartirlos; la CCN-STIC-424 aborda el intercambio de información de ciberamenazas con los estándares del sector, STIX y TAXII, e incluye un caso práctico con la propia herramienta; y la CCN-STIC-425, que analizamos en su día en esta misma serie, sitúa todo ello dentro del ciclo de inteligencia y del análisis formal de intrusiones.
Aquí es obligado un aviso de cautela, porque es el punto donde más fácilmente se resbala. La coincidencia de un indicador vincula un incidente con una campaña conocida, y eso tiene un valor investigativo enorme; sin embargo, un IoC compartido no identifica a una persona. Las direcciones IP se alquilan, los servidores se comprometen y se reutilizan, y el propio ecosistema del cibercrimen funciona con infraestructuras compartidas entre grupos distintos. La jerarquía que la 425 popularizó bajo el nombre de Pirámide del Dolor explica bien por qué: los indicadores más fáciles de recolectar son también los más fáciles de cambiar para el adversario, mientras que las tácticas, técnicas y procedimientos, mucho más costosos de modificar, son los que de verdad permiten hablar de un patrón de comportamiento. Un informe pericial que salte del indicador a la autoría sin recorrer ese camino intermedio es un informe que se cae en la primera contradicción.
AMPARO e INES: acreditar que se hizo lo que había que hacer
Las tres herramientas anteriores miran al incidente. AMPARO mira a lo que había antes de él, que es justamente lo que se examina cuando se depuran responsabilidades.
AMPARO es la solución del CCN para la implantación y la adecuación al Esquema Nacional de Seguridad, regulado hoy por el Real Decreto 311/2022. Guía a la entidad a lo largo de todo el proceso mediante un asistente de implantación que señala los pasos, evalúa automáticamente la conformidad del sistema y detecta las carencias; permite obtener la Declaración de Conformidad para la categoría básica; pone a disposición del usuario los modelos de procedimientos y normativa necesarios para la adecuación; y gestiona la relación con la entidad auditora a lo largo del proceso de certificación. Junto a ella, INES recoge la información con la que se elabora el Informe Nacional del Estado de la Seguridad, la radiografía periódica del estado de la seguridad en el sector público español. Ambas forman la plataforma de gobernanza del CCN y fueron actualizadas en junio de 2025 con un rediseño de su interfaz. Para el mundo local existe además un camino específico, con la herramienta MARGA y el perfil de cumplimiento de requisitos esenciales de la guía CCN-STIC-890, pensado para entidades con recursos limitados.
El interés jurídico de todo esto es considerable y suele pasarse por alto. El artículo 32 del Reglamento General de Protección de Datos obliga a aplicar medidas técnicas y organizativas apropiadas al riesgo, y el principio de responsabilidad proactiva exige poder demostrarlo. Una Declaración de Conformidad con el ENS, con su fecha, su alcance definido y su respaldo documental, es exactamente esa clase de prueba: acredita que, en un momento determinado, un tercero independiente verificó que el sistema cumplía un catálogo de medidas reglado. En el debate posterior a una brecha, esa documentación no borra el daño, aunque sí desplaza la discusión desde el terreno resbaladizo de la negligencia presunta al terreno firme de lo verificado. La ausencia de ese respaldo, en cambio, deja a la organización explicando a posteriori por qué creía estar protegida.
Lo que estas herramientas no son
Llegados aquí conviene marcar los límites con claridad, porque el entusiasmo por el catálogo puede llevar a atribuirle capacidades que no tiene.
Ninguna de las cuatro es una herramienta de adquisición forense. No clonan discos, no capturan memoria volátil ni generan las imágenes bit a bit sobre las que trabaja un perito. La preservación de la evidencia sigue rigiéndose por lo que ya explicamos al hilo de la 817: el orden de volatilidad del RFC 3227, las funciones resumen para garantizar la integridad, los bloqueadores de escritura y el procedimiento sistematizado en la norma ISO/IEC 27037. LUCIA documenta la gestión del incidente; la custodia de la prueba es otra cosa y exige su propio método.
Tampoco son de acceso abierto. El SAT y REYES requieren adhesión al servicio y acreditación, la información que manejan tiene difusión restringida, y sus contenidos no se consultan como se consulta un registro público. Lo que sí es público es su documentación: las guías CCN-STIC que describen cada herramienta están disponibles para cualquiera, y eso basta para saber qué existe y qué se puede pedir.
Y no cubren al ciudadano ni a la empresa privada ordinaria. Quien sufre un ataque fuera del ámbito del ENS tiene su punto de referencia en el INCIBE-CERT, y su vía de denuncia en las unidades especializadas de la Policía Nacional y la Guardia Civil. El horizonte, en todo caso, se está desplazando: la transposición de la Directiva NIS2, que a mediados de 2026 seguía tramitándose en España a través del anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad, ampliará de forma notable el número de entidades obligadas a gestionar y notificar sus incidentes, con plazos más cortos y un mapa de autoridades más denso.
El resto del catálogo, brevemente
Alrededor de estas cuatro plataformas, el CCN mantiene una familia de soluciones que conviene al menos reconocer por su nombre. CARMEN analiza el tráfico interno y saliente de una organización para identificar amenazas persistentes avanzadas. CLAUDIA vigila el puesto de usuario en busca de comportamientos maliciosos, y su versión ligera, microCLAUDIA, despliega «vacunas» que impiden la ejecución de familias concretas de ransomware. GLORIA, cuyo nombre desarrolla la fórmula «gestor de logs para responder ante incidentes y amenazas», centraliza y correlaciona eventos de seguridad al modo de un SIEM, e integra información procedente de CARMEN, REYES y la propia LUCIA. CLARA audita la configuración de los sistemas frente a los requisitos del ENS y de las guías STIC. Y PILAR, la más veterana, aplica la metodología MAGERIT al análisis y la gestión de riesgos, que es el punto de partida formal de todo lo demás. Las cifras publicadas por el CCN en abril de 2024 hablaban de decenas de sondas de CARMEN desplegadas y de más de cien mil agentes de monitorización instalados, lo que da la medida del despliegue real de estas capacidades.
Cómo se ve todo esto desde un juzgado
Vale la pena reunir las piezas en un escenario. Una consejería autonómica sufre una intrusión que acaba en cifrado de servidores. La sonda del SAT desplegada en su perímetro registró, tres semanas antes, conexiones periódicas hacia un dominio poco habitual; nadie les prestó atención entonces, pero la alerta quedó anotada. El día del cifrado, el equipo de respuesta abre el ticket en LUCIA, lo clasifica como código dañino de peligrosidad muy alta y consigna el impacto, lo que dispara a la vez la notificación al CCN-CERT y el reloj de las setenta y dos horas ante la Agencia Española de Protección de Datos. El analista busca en REYES el dominio detectado por la sonda y descubre que forma parte de la infraestructura de una campaña documentada meses atrás contra otras administraciones, con lo que la investigación gana contexto y deja de partir de cero. Y cuando el asunto llega al juzgado, la defensa de la organización aporta su Declaración de Conformidad con el ENS, obtenida a través de AMPARO, para acreditar que el sistema estaba adecuado antes del ataque.
Cuatro registros distintos, generados por cuatro herramientas distintas, que juntos permiten responder a las cuatro preguntas que siempre acaban formulándose: cuándo empezó, qué se hizo, contra quién se estaba luchando y si se había hecho antes lo que había que hacer. Ninguno de ellos, por sí solo, sostiene un caso. Todos juntos, en cambio, componen el andamiaje documental sobre el que un perito puede construir un informe que resista el contraste.
Lo que queda por contar
Con este artículo cerramos la deuda que teníamos con los lectores desde enero, cuando anunciamos que analizaríamos estas herramientas en profundidad. El catálogo del Centro Criptológico Nacional sigue siendo, a nuestro juicio, uno de los cuerpos de conocimiento técnico más valiosos y peor aprovechados de la Administración española: gratuito, público, escrito en castellano y directamente aplicable al trabajo diario de quien investiga delitos informáticos o pericia sistemas.
La serie continúa. La CCN-STIC-834, dedicada a la protección y el análisis del código dañino, ya tiene su propio monográfico en estas páginas, publicado mientras este artículo esperaba turno, y en el taller quedan otros dos con espacio propio: el traslado del enfoque de preparación forense a los entornos Windows y de directorio activo, que son los que la mayoría de las organizaciones tienen en producción; y la CCN-STIC-496, sobre comunicaciones móviles y dispositivos personales, donde la cadena de custodia se juega su partida más difícil. Mientras tanto, queda una idea que resume bastante bien el sentido de todo lo anterior: en un ciberincidente, lo que no queda registrado en el momento resulta prácticamente imposible de reconstruir después, y las herramientas que hemos repasado existen precisamente para que ese registro no dependa de que alguien se acuerde de tomar notas en la peor noche del año.
Spain’s CCN toolkit: SAT, LUCIA, REYES and AMPARO, or how a cyberattack ends up on the record
We said we would, so here it is: an in-depth look at some of the most important tools the CCN runs.
When a cyberattack is over, what remains is the silence of the shut-down servers and something less visible: a file. Someone opened a ticket at a quarter past three in the morning, someone classified the incident, someone logged an IP address in a shared repository, someone sent a report to the relevant authority, and someone, months earlier, had signed a declaration of compliance. That chain of entries is created in specific tools, each with a name of its own, and it is the material from which events are later reconstructed before an auditor, before the Spanish Data Protection Agency or before a court. In the Spanish public sector, those tools are called SAT, LUCIA, REYES and AMPARO.
A debt incurred back in January
This series has worked through the catalogue of Spain’s National Cryptologic Centre: the map of how the collection is organised, a commented selection of the CCN-STIC guides useful in criminological and forensic investigation, a practical case of forensic readiness on a Linux server, and monographs on guide 425, devoted to the intelligence cycle and intrusion analysis, and on 817, the cyber incident management guide. In that commented selection a promise was made that ought to be honoured: to analyse the tools of the CCN ecosystem in depth. That is what we do here.
The step makes sense. A guide describes how something should be done; the tool is where that something actually happens, leaves a trace and acquires a date. For the forensic expert and the lawyer, the difference is substantial, because what is taken into proceedings is records rather than good intentions. Understanding what each platform logs, in how much detail and who may consult it makes it possible to know in advance what documentation can be requested, what it can prove and, above all, what it cannot.
Four names for the four phases of an attack
The four tools this article deals with do not compete with one another: they cover different moments of the same journey. The SAT, the Early Warning System, watches network traffic and raises the alarm when something starts to go wrong. LUCIA opens the incident file, classifies it according to the taxonomy of guide 817 and coordinates notification to the governmental CERT. REYES collects the technical indicators left behind by the attacker and shares them with other bodies, which is the foundation of any serious attempt at attribution. And AMPARO, alongside INES, handles the compliance side: demonstrating that the system had been brought into line with the National Security Framework before anything happened.
Detection, management, intelligence and compliance. The four verbs that run through the life cycle of a cyber incident as guide 817 itself describes it, each with its own platform.
One point about scope should be made clear from the outset. These solutions are designed for the public sector and for organisations of strategic interest that subscribe to CCN-CERT services; a small business or a private individual will not be installing LUCIA. The reason for knowing about them from outside the public sector is a different one, and it has two sides: any technology supplier serving a public body ends up dealing with these tools, because the National Security Framework extends contractually along the supply chain; and when litigating against an administration or examining its systems, knowing which records exist and how they are generated changes entirely the quality of the evidence that can be sought.
SAT: the sensors that watch the attack go by
The Early Warning System is the oldest of the four. CCN-CERT launched it in 2008 and it now runs in three variants matching three different environments: SAT-SARA, deployed over the network that interconnects Spanish public administrations; SAT-INET, aimed at the traffic flowing between a body’s internal network and the internet; and SAT-ICS, designed for industrial control and supervision networks, that is, for water management infrastructure, healthcare facilities, port environments and other systems whose disruption has immediate physical consequences.
The mechanism is simple to explain and subtle in its implications. The subscribing body installs a probe on its network. That probe observes traffic, applies detection rules matching known attack patterns, the behaviour of particular malicious code or unusual uses of an industrial system, and sends the central platform only the alerts it has generated, without dumping the content of communications there. The service’s public documentation insists on that nuance: detection rests on the analysis of traffic and flows, without focusing on their content.
The detail matters far more than it may appear, for two reasons. The first is legal. Analysing traffic metadata —who talks to whom, when, through which port and for how long— borders on the secrecy of communications protected by article 18.3 of the Spanish Constitution, and the service is designed precisely to operate at the level of flows rather than content, where the interference would be of an altogether different nature. The second is evidentiary. Flow records are a first-rate source of evidence in intrusion investigations, because they make it possible to place in time the first connection to the attacker’s infrastructure, measure the volume of exfiltrated data and reconstruct lateral movement inside the network, and all of it survives even where the attacker has wiped their tracks from the compromised machines.
As for its reach, the figures published by the CCN in April 2024 recorded 421 SAT-INET probes deployed across 414 bodies and 48 SAT-ICS probes across 38 subscribing organisations, with sustained year-on-year growth. These numbers outline a considerable observation capability over the digital perimeter of the Spanish public sector.
LUCIA: the official file on the incident
If the SAT is the sensor, LUCIA is the record. Its name stands for Listado Unificado de Coordinación de Incidentes y Amenazas (Unified List for the Coordination of Incidents and Threats), and its purpose is to give public bodies and CCN-CERT itself a shared platform for managing the life cycle of a cyber incident, from detection to closure.
Technically, LUCIA rests on two well-established pieces of open-source software widely used by the international incident-response community: the ticketing system Request Tracker (RT) and its specific extension for response teams, Request Tracker for Incident Response (RTIR). On that base, the CCN customised it to meet its own procedures and the requirements of the National Security Framework, aligning it with the methodology of guide 817, and distributes it to public bodies as a preconfigured virtual machine, with documentation gathered in the CCN-STIC-845 guides in their user, installation and administration variants. Being built on RTIR has a practical consequence any forensic expert will appreciate: the data model, the ticket states and the traceability of every action belong to a known and audited tool, far removed from any black box.
What LUCIA contributes on the legal plane is a common language. The classification of the incident, its dangerousness level and its impact are recorded using the taxonomy of guide 817, the same one that served as the basis for ENISA’s good-practice guide. When a public body states «malicious code, ransomware type, very high dangerousness», it is saying exactly what any other Spanish body would say, and that makes it possible to compare, aggregate statistics and, where necessary, argue in court about a regulated classification instead of about impressions.
The second contribution is the chronology. Every entry in the ticket is dated and attributed to a user; closures, reminders and notifications are automated; and the full history of the file allows one to reconstruct afterwards who knew what and when. That time axis is, in practice, the backbone of any discussion about due diligence: where the breach affected personal data, the seventy-two-hour window of article 33 of the General Data Protection Regulation starts running from the moment the organisation became aware of it, and proving when that awareness arose requires a record that does not depend on anybody’s memory.
The third element is federation, and it deserves a pause because it reveals a design decision with legal depth. A public body may deploy its own LUCIA instance and synchronise it with CCN-CERT’s central instance. In that synchronisation, according to the architecture described in the system’s public documentation, incidents originating from the SAT travel in full in both directions, whereas for the body’s own incidents only metadata are sent, with the detail remaining under its control. The system also integrates the transmission to the CCN of incidents rated very high and critical, in fulfilment of the obligations of the National Security Framework. Put differently: the tool is built so that central government learns the scale of the problem without accumulating, by default, the full content of other bodies’ files.
For the forensic expert, the operational conclusion is direct. When investigating an incident suffered by a public administration, there is almost certainly a LUCIA ticket with its classification, its chronology and its communications history, and that file is a legitimate documentary source that can be requested through the appropriate procedural channel. It does not replace technical analysis, though it does provide the temporal scaffolding on which to rest it.
REYES: the shared memory of indicators
REYES addresses a different problem. An attacker striking a town council today is often the same one that struck a university last week and will strike a regional ministry next month, using the same infrastructure, the same domains and the same tools. Sharing those technical traces among public bodies multiplies everyone’s defensive capability, and that is the platform’s purpose.
Its core rests on MISP, the Malware Information Sharing Platform, the de facto standard in threat intelligence exchange, enriched with public and private sources and federated with international organisations. Version 3.0, presented in March 2019, added an intelligence engine and an association graph allowing analysts to pivot from one indicator to another in order to assess the real scope of a threat. The figures the CCN published in April 2024 give a sense of its use: over two thousand authorised users, more than eight hundred and forty thousand alerts generated and several dozen blacklists maintained.
The material REYES works with is indicators of compromise, or IoCs: IP addresses, domains, cryptographic hashes of malicious files, configuration patterns. Three guides in the catalogue deal with that cycle and are worth locating: CCN-STIC-423 explains how to identify indicators and how to prepare them for sharing; CCN-STIC-424 covers cyber threat information exchange using the industry standards STIX and TAXII, and includes a practical case using the tool itself; and CCN-STIC-425, which we analysed in this very series, places all of it within the intelligence cycle and the formal analysis of intrusions.
A word of caution is essential here, because this is where it is easiest to slip. A matching indicator links an incident to a known campaign, and that has enormous investigative value; a shared IoC, however, does not identify a person. IP addresses are rented, servers are compromised and reused, and the cybercrime ecosystem itself runs on infrastructure shared between different groups. The hierarchy that guide 425 popularised under the name Pyramid of Pain explains why: the indicators easiest to collect are also the easiest for the adversary to change, whereas tactics, techniques and procedures, far costlier to alter, are what genuinely allow one to speak of a behavioural pattern. An expert report that leaps from indicator to authorship without travelling that middle road is a report that collapses at the first contradiction.
AMPARO and INES: evidencing that the right things were done
The three tools above look at the incident. AMPARO looks at what came before it, which is precisely what gets examined when liability is apportioned.
AMPARO is the CCN’s solution for implementing and complying with the National Security Framework, currently governed by Royal Decree 311/2022. It guides the entity through the whole process by means of an implementation assistant that sets out the steps, automatically assesses the system’s compliance and flags shortcomings; it allows the Declaration of Compliance for the basic category to be obtained; it provides users with the model procedures and policies required for compliance; and it manages the relationship with the auditing entity throughout the certification process. Alongside it, INES gathers the information used to prepare the National Report on the State of Security, the periodic X-ray of security in the Spanish public sector. Both make up the CCN’s governance platform and were updated in June 2025 with a redesigned interface. For local government there is also a specific route, with the MARGA tool and the essential-requirements compliance profile of guide CCN-STIC-890, designed for entities with limited resources.
The legal significance of all this is considerable and often overlooked. Article 32 of the General Data Protection Regulation requires technical and organisational measures appropriate to the risk, and the accountability principle requires being able to demonstrate them. A Declaration of Compliance with the National Security Framework, with its date, its defined scope and its documentary backing, is exactly that kind of proof: it certifies that, at a given moment, an independent third party verified that the system met a regulated catalogue of measures. In the debate following a breach, such documentation does not undo the harm, though it does shift the argument from the slippery ground of presumed negligence to the firm ground of what was verified. The absence of such backing, by contrast, leaves the organisation explaining after the fact why it believed itself to be protected.
What these tools are not
At this point the limits should be drawn clearly, because enthusiasm for the catalogue can lead to crediting it with capabilities it does not have.
None of the four is a forensic acquisition tool. They do not clone disks, capture volatile memory or generate the bit-by-bit images a forensic expert works on. Preserving evidence continues to be governed by what we explained when discussing guide 817: the order of volatility set out in RFC 3227, hash functions to guarantee integrity, write blockers and the procedure systematised in ISO/IEC 27037. LUCIA documents the management of the incident; custody of the evidence is another matter and demands its own method.
Nor are they openly accessible. The SAT and REYES require subscription and accreditation, the information they handle is restricted in its distribution, and their contents are not consulted the way a public register is. What is public is their documentation: the CCN-STIC guides describing each tool are available to anyone, and that is enough to know what exists and what may be requested.
And they do not cover the ordinary citizen or private company. Anyone attacked outside the scope of the National Security Framework has their point of reference in INCIBE-CERT, and their route to reporting a crime in the specialist units of the National Police and the Guardia Civil. The horizon is shifting, in any case: the transposition of the NIS2 Directive, which as of mid-2026 was still making its way through the Spanish legislature via the draft Cybersecurity Coordination and Governance Act, will considerably widen the number of entities obliged to manage and report their incidents, with shorter deadlines and a denser map of authorities.
The rest of the catalogue, briefly
Around these four platforms, the CCN maintains a family of solutions worth recognising at least by name. CARMEN analyses an organisation’s internal and outbound traffic to identify advanced persistent threats. CLAUDIA monitors user workstations for malicious behaviour, and its lightweight version, microCLAUDIA, deploys «vaccines» that prevent specific ransomware families from executing. GLORIA, whose name expands to «log manager for responding to incidents and threats», centralises and correlates security events in the manner of a SIEM, and integrates information from CARMEN, REYES and LUCIA itself. CLARA audits system configuration against the requirements of the National Security Framework and the STIC guides. And PILAR, the most venerable of them, applies the MAGERIT methodology to risk analysis and management, which is the formal starting point for everything else. Figures published by the CCN in April 2024 spoke of dozens of CARMEN probes deployed and more than a hundred thousand monitoring agents installed, which gives the measure of the real reach of these capabilities.
How all this looks from the bench
It is worth assembling the pieces into a scenario. A regional ministry suffers an intrusion that ends in its servers being encrypted. The SAT probe deployed on its perimeter recorded, three weeks earlier, periodic connections to an unusual domain; nobody paid attention at the time, but the alert was logged. On the day of the encryption, the response team opens the ticket in LUCIA, classifies it as malicious code of very high dangerousness and records the impact, which simultaneously triggers notification to CCN-CERT and the seventy-two-hour clock before the Spanish Data Protection Agency. The analyst looks up in REYES the domain flagged by the probe and finds that it belongs to the infrastructure of a campaign documented months earlier against other administrations, so the investigation gains context instead of starting from scratch. And when the matter reaches court, the organisation’s defence produces its Declaration of Compliance with the National Security Framework, obtained through AMPARO, to establish that the system had been brought into line before the attack.
Four different records, generated by four different tools, which together answer the four questions that always end up being asked: when it began, what was done, who was being fought, and whether what had to be done beforehand had actually been done. None of them, alone, sustains a case. Together, however, they form the documentary scaffolding on which a forensic expert can build a report that withstands scrutiny.
What is still to come
With this article we settle the debt we owed our readers since January, when we announced that we would analyse these tools in depth. The National Cryptologic Centre’s catalogue remains, in our view, one of the most valuable and least exploited bodies of technical knowledge in the Spanish public sector: free, public, written in Spanish and directly applicable to the daily work of anyone investigating computer crime or examining systems.
The series continues. CCN-STIC-834, devoted to protection against and analysis of malicious code, already has a monograph of its own in these pages, published while this article was waiting its turn, and two more are still on the workbench: the transfer of the forensic-readiness approach to Windows and Active Directory environments, which are the ones most organisations actually run; and CCN-STIC-496, on mobile communications and personal devices, where the chain of custody faces its hardest test. In the meantime, one idea sums up the point of everything above rather well: in a cyber incident, whatever is not recorded at the time is practically impossible to reconstruct afterwards, and the tools reviewed here exist precisely so that such a record does not depend on somebody remembering to take notes on the worst night of the year.
Referencias · References
Agencia Española de Protección de Datos. (s. f.). Notificación de brechas de seguridad de datos personales a la autoridad de control. AEPD. https://www.aepd.es/derechos-y-deberes/cumple-tus-deberes/medidas-de-cumplimiento/brechas-de-seguridad
Brezinski, D., & Killalea, T. (2002). Guidelines for evidence collection and archiving (RFC 3227). Internet Engineering Task Force. https://doi.org/10.17487/RFC3227
Centro Criptológico Nacional. (2015). CCN-STIC-424. Intercambio de información de ciberamenazas. STIX y TAXII [Guía de seguridad de las TIC]. CCN-CERT. https://www.ccn-cert.cni.es/
Centro Criptológico Nacional. (2019, 18 de marzo). Nueva versión de REYES, la solución del CCN-CERT para compartir información de ciberamenazas. CCN. https://www.ccn.cni.es/es/actualidad-ccn/384-nueva-version-de-reyes-la-solucion-del-ccn-cert-para-compartir-informacion-de-ciberamenazas
Centro Criptológico Nacional. (2020). CCN-STIC-817. Esquema Nacional de Seguridad. Gestión de ciberincidentes [Guía de seguridad de las TIC]. CCN-CERT. https://www.ccn-cert.cni.es/es/series-ccn-stic/800-guia-esquema-nacional-de-seguridad/988-ccn-stic-817-gestion-de-ciberincidentes
Centro Criptológico Nacional. (2022, 8 de junio). El Sistema de Alerta Temprana en Internet supera las 300 sondas desplegadas en 288 organismos. CCN. https://www.ccn.cni.es/es/actualidad-ccn/903-el-sistema-de-alerta-temprana-en-internet-supera-las-300-sondas-desplegadas-en-288-organismos
Centro Criptológico Nacional. (2023, 25 de octubre). Actualizada la guía CCN-STIC 1215 sobre el procedimiento de empleo seguro de GLORIA. CCN. https://www.ccn.cni.es/es/actualidad-ccn/1067-actualizada-la-guia-ccn-stic-1215-sobre-el-procedimiento-de-empleo-seguro-de-gloria
Centro Criptológico Nacional. (2024, 23 de abril). El Centro Criptológico Nacional ha gestionado más de 30.000 ciberincidentes de peligrosidad muy alta y crítica en sus 20 años de trayectoria. CCN. https://www.ccn.cni.es/es/actualidad-ccn/1146-el-centro-criptologico-nacional-ha-gestionado-mas-de-30-000-ciberincidentes-de-peligrosidad-muy-alta-y-critica-en-sus-20-anos-de-trayectoria
Centro Criptológico Nacional. (2025, 16 de junio). El Centro Criptológico Nacional actualiza las soluciones INÉS y AMPARO para optimizar la experiencia de los usuarios. CCN. https://www.ccn.cni.es/es/actualidad-ccn/1281-el-centro-criptologico-nacional-actualiza-las-soluciones-ines-y-amparo-para-optimizar-la-experiencia-de-los-usuarios
Centro Criptológico Nacional. (s. f.). CCN-STIC-423. Indicadores de compromiso (IoC) [Guía de seguridad de las TIC]. CCN-CERT. https://www.ccn-cert.cni.es/
Centro Criptológico Nacional. (s. f.). CCN-STIC-425. Ciclo de inteligencia y análisis de intrusiones [Guía de seguridad de las TIC]. CCN-CERT. https://www.ccn-cert.cni.es/
Centro Criptológico Nacional. (s. f.). CCN-STIC-845A. LUCIA. Manual de usuario [Guía de seguridad de las TIC]. CCN-CERT. https://www.ccn-cert.cni.es/
Centro Criptológico Nacional. (s. f.). CCN-STIC-890. Perfil de cumplimiento específico de requisitos esenciales de seguridad para entidades locales [Guía de seguridad de las TIC]. CCN-CERT. https://www.ccn-cert.cni.es/
Consejo de la Unión Europea & Parlamento Europeo. (2016). Reglamento (UE) 2016/679, de 27 de abril de 2016, relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales (Reglamento General de Protección de Datos). Diario Oficial de la Unión Europea, L 119. https://eur-lex.europa.eu/eli/reg/2016/679/oj
Organización Internacional de Normalización. (2012). ISO/IEC 27037:2012. Information technology — Security techniques — Guidelines for identification, collection, acquisition and preservation of digital evidence. ISO.
Parlamento Europeo & Consejo de la Unión Europea. (2022). Directiva (UE) 2022/2555, de 14 de diciembre de 2022, relativa a las medidas destinadas a garantizar un elevado nivel común de ciberseguridad en toda la Unión (Directiva NIS 2). Diario Oficial de la Unión Europea, L 333. https://eur-lex.europa.eu/eli/dir/2022/2555/oj
Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad. Boletín Oficial del Estado, 106, de 4 de mayo de 2022. https://www.boe.es/eli/es/rd/2022/05/03/311
Real Decreto 421/2004, de 12 de marzo, por el que se regula el Centro Criptológico Nacional. Boletín Oficial del Estado, 68, de 19 de marzo de 2004. https://www.boe.es/eli/es/rd/2004/03/12/421
Deja una respuesta