Idioma / Language: Español · English
Dos catálogos de bastionado, dos formas de responder a la misma pregunta
Dos catálogos de bastionado nacidos de tradiciones distintas —el consenso de una comunidad técnica internacional y la autoridad de un organismo de Estado— examinan la misma máquina y no siempre dicen lo mismo. Comparamos su arquitectura, su alcance y, sobre todo, lo que cada uno puede sostener en un procedimiento judicial.
Dos maneras de escribir la misma frase
Un perito recibe la imagen de un servidor comprometido y una pregunta que parece sencilla: ¿estaba bien configurada esa máquina el día del ataque? La respuesta depende por completo del catálogo con el que se compare. Si el informe se apoya en los CIS Benchmarks, el resultado será una puntuación de conformidad sobre varios centenares de comprobaciones automatizadas, con su porcentaje y su listado de desviaciones. Si se apoya en las guías CCN-STIC, el resultado será un juicio sobre el cumplimiento de una norma jurídica española, el Esquema Nacional de Seguridad, con consecuencias administrativas concretas. Las dos respuestas pueden ser correctas y llegar a conclusiones distintas sobre la misma máquina.
Esa divergencia tiene poco de anecdótico. En la práctica pericial española conviven ambos marcos: el sector público está obligado por el Esquema Nacional de Seguridad y trabaja con las guías del Centro Criptológico Nacional, mientras que buena parte del tejido empresarial privado —sobre todo el que opera con matriz internacional, proveedores cloud o certificaciones de mercado— configura sus sistemas siguiendo los CIS Benchmarks porque son el lenguaje que entienden sus auditores. Cuando un incidente acaba en un juzgado, ambos catálogos comparecen, y quien tiene que explicar sus diferencias al tribunal es el perito.
Este artículo continúa la serie que Actum Forense Press dedica a las guías del CCN y cumple un compromiso adquirido en la entrega dedicada a la preparación forense de servidores Linux, donde se anunció esta comparativa. El objetivo es doble: describir con precisión cómo está construido cada modelo y ofrecer criterios para decidir cuál invocar, cuándo y con qué alcance probatorio.
Genealogía de dos catálogos
El Center for Internet Security es una organización estadounidense sin ánimo de lucro constituida en el año 2000. Su producto más conocido, los CIS Benchmarks, es una colección de documentos de configuración segura elaborados por comunidades de voluntarios —administradores de sistemas, auditores, fabricantes, investigadores— que trabajan sobre plataformas concretas y publican sus recomendaciones tras un proceso de consenso. La organización mantiene además los CIS Critical Security Controls, un marco de salvaguardas de alto nivel cuya versión 8.1 se publicó en junio de 2024 con alineación explícita al NIST Cybersecurity Framework 2.0.
El Centro Criptológico Nacional pertenece a otra tradición por completo. Adscrito al Centro Nacional de Inteligencia, fue creado por la Ley 11/2002, de 6 de mayo, reguladora del CNI, y su régimen se desarrolló por el Real Decreto 421/2004, de 12 de marzo. La serie CCN-STIC —Seguridad de las Tecnologías de Información y Comunicaciones— es el instrumento con el que ese organismo ejerce una función que la ley le atribuye: elaborar y difundir normas, instrucciones, guías y recomendaciones para garantizar la seguridad de los sistemas de las tecnologías de la información de la Administración.
La diferencia de origen determina casi todo lo demás. Un CIS Benchmark nace de la conversación entre profesionales que aportan su experiencia sobre un producto concreto, y su autoridad procede de la calidad técnica y de la aceptación del mercado. Una guía CCN-STIC nace de un organismo con potestad normativa delegada, y su autoridad procede de la ley. El primero convence; la segunda obliga a quien está dentro de su ámbito.
Conviene añadir un matiz que se olvida a menudo. La obligatoriedad de las guías CCN-STIC no es genérica: deriva del Real Decreto 311/2022, de 3 de mayo, que regula el Esquema Nacional de Seguridad. Ese texto vincula al sector público y, por extensión contractual, a los proveedores privados que le prestan servicios; para el resto de las empresas españolas, una guía CCN-STIC es exactamente lo que su nombre indica, una recomendación técnica de alta calidad, con el mismo estatuto voluntario que un CIS Benchmark.
El vecindario internacional de los dos catálogos
Ninguno de los dos modelos es una rareza aislada, y situarlos en el mapa comparado ayuda a entender por qué están construidos como están.
El pariente más cercano de las guías CCN-STIC no es el CIS Benchmark, sino las STIG del Departamento de Defensa de los Estados Unidos, elaboradas por la Defense Information Systems Agency. Comparten la lógica esencial: un organismo estatal con competencia sobre unos sistemas concretos publica configuraciones exigibles, con auditoría reglada y consecuencias para quien no las cumple. La coincidencia llega al punto de que varios CIS Benchmarks incluyen un perfil alineado con la STIG correspondiente, precisamente para servir a las organizaciones que trabajan con la Administración estadounidense.
En el plano de los catálogos de controles, el equivalente funcional del Anexo II del Esquema Nacional de Seguridad es la publicación NIST SP 800-53, que enumera controles de seguridad y privacidad para los sistemas federales estadounidenses, con su propia graduación por líneas base. Y en el terreno de la certificación voluntaria de mercado, la referencia sigue siendo la familia ISO/IEC 27000, con la norma 27001 como sistema de gestión certificable y la 27002 como catálogo de controles.
Europa aporta sus propias tradiciones nacionales. Alemania mantiene el IT-Grundschutz de la Oficina Federal de Seguridad de la Información, un cuerpo doctrinal extenso que combina metodología de riesgos y módulos de configuración. Francia publica a través de la ANSSI guías de bastionado técnicas de calidad notable y de acceso libre. Ambas comparten con el modelo español la característica decisiva: una autoridad pública que escribe y actualiza, con un ámbito de obligatoriedad definido por su ordenamiento.
Lo que distingue al modelo CIS en ese panorama es su carácter transnacional y su desvinculación de cualquier ordenamiento concreto. Esa aparente debilidad es su mayor fortaleza operativa, porque le permite ser adoptado como referencia común por organizaciones que operan en varias jurisdicciones a la vez, y explica por qué una empresa española con filiales en tres países acaba trabajando con CIS aunque su matriz de cumplimiento mencione el ENS o la ISO 27001.
Quién escribe la regla y quién responde de ella
El proceso de elaboración de un CIS Benchmark es abierto y trazable. Las comunidades de trabajo discuten cada recomendación en foros públicos, se somete a un periodo de consenso y el documento resultante se publica con número de versión y fecha. Cada control incorpora una estructura estable que resulta muy útil en peritaje: descripción, justificación técnica del porqué, procedimiento de auditoría paso a paso, procedimiento de remediación e impacto previsible de aplicarlo. Ese último campo, el impacto, es una de las aportaciones más honestas del modelo, porque reconoce por escrito que endurecer un sistema tiene coste operativo.
Las guías CCN-STIC siguen una lógica editorial distinta. Se elaboran internamente, con la participación de organismos y empresas cuando procede, y se publican bajo la clasificación que corresponda; buena parte del catálogo es de acceso público y otra parte está reservada a las administraciones. La redacción es la propia de un documento normativo: describe el mecanismo, fija la configuración exigida y remite a la medida del Anexo II del Esquema Nacional de Seguridad que se está satisfaciendo. La trazabilidad es hacia la norma, más que hacia la discusión técnica que produjo la regla.
Esa asimetría tiene una consecuencia directa en sede judicial. Ante una pregunta del tipo «¿por qué había que desactivar ese servicio?», un CIS Benchmark ofrece un razonamiento técnico documentado que el perito puede leer en voz alta y que el tribunal entiende sin conocimientos previos. Una guía CCN-STIC ofrece algo distinto y, a menudo, más poderoso: la constatación de que esa configuración era exigible por una norma reglamentaria española en vigor. El primero explica; la segunda imputa.
El mapa de cada catálogo
Quien se acerca por primera vez a la serie CCN-STIC descubre una organización por bloques numéricos que responde a la naturaleza del documento antes que a la tecnología: la serie 000 recoge políticas; la 100, procedimientos; la 200, normas; la 300, instrucciones técnicas; la 400, guías generales; la 500, entornos Windows; la 600, otros entornos, entre ellos Linux, Unix y bases de datos; la 800, el desarrollo del Esquema Nacional de Seguridad; la 900, informes técnicos; la 1000, empleo seguro de productos; y la 2000, la actividad del Organismo de Certificación. Un profesional que busca cómo bastionar una distribución concreta tiene que localizar la guía de la serie 600 que le corresponda y comprobar si existe para su versión.
El catálogo de CIS está organizado exclusivamente por tecnología. Hay familias para sistemas operativos, para proveedores de nube, para software de servidor, para dispositivos de red, para navegadores y aplicaciones de escritorio, para herramientas de contenedores y canalizaciones de despliegue, y para plataformas móviles. Cada documento se identifica por producto y versión —por ejemplo, el CIS Ubuntu Linux 24.04 LTS Benchmark v1.0.0, publicado el 26 de agosto de 2024— y se estructura internamente en secciones funcionales que se repiten de una plataforma a otra: configuración inicial, servicios, red, registro y auditoría, control de acceso y autenticación, y mantenimiento del sistema.
La comparación de cobertura arroja un resultado incómodo para quien trabaja en España. El catálogo del CCN es excelente en el eje normativo y desigual en el eje tecnológico: hay guías magníficas para los entornos que la Administración usa de forma masiva y huecos notables o versiones desactualizadas en tecnologías de adopción reciente. El catálogo de CIS es al revés: cubre una superficie tecnológica muy amplia, con actualizaciones rápidas ligadas al ciclo de vida de cada producto, y carece por completo de anclaje jurídico español.
El envejecimiento de un catálogo
Hay un problema que la literatura comercial de ambos modelos suele pasar por alto y que en peritaje resulta central: los documentos de bastionado envejecen a la velocidad a la que cambia el producto que describen, y esa velocidad rara vez coincide con la del organismo que los publica.
El modelo CIS ata cada documento a una versión concreta del producto y lo versiona de forma independiente. Cuando aparece una nueva versión mayor del sistema operativo, la comunidad correspondiente trabaja en un benchmark nuevo, que convive durante un tiempo con el anterior. El resultado es un catálogo con un número elevado de documentos vivos y una trazabilidad clara: se sabe siempre qué versión del benchmark aplica a qué versión del producto y cuándo se publicó cada una.
El catálogo del CCN presenta un panorama más desigual. Hay guías de bastionado plenamente vigentes y otras que se escribieron para versiones de producto que hoy están fuera de soporte del fabricante. Es una consecuencia inevitable del tamaño del catálogo y de los recursos de cualquier organismo público, y el propio CCN lo ha ido corrigiendo: la actualización de la herramienta CLARA incorporó la comprobación del ciclo de vida del sistema operativo y el reporte de su fin de soporte en los informes técnico y ejecutivo, junto con nuevas guías de la serie 500 para entornos Windows.
La situación práctica que se produce con frecuencia es la siguiente: hay que bastionar o auditar una versión de producto para la que existe guía CCN-STIC de una versión anterior y CIS Benchmark de la versión exacta. La salida profesional pasa por aplicar la guía española en todo lo que siga siendo aplicable, completar con el benchmark actualizado lo que la versión nueva haya cambiado y dejar constancia escrita y motivada de esa decisión. Lo que nunca debería hacerse es aplicar mecánicamente una guía escrita para otra versión sin verificar qué parámetros han cambiado de nombre, de ubicación o de comportamiento por defecto, porque el resultado puede ser una configuración que parece endurecida y no lo está.
Para el trabajo pericial, la fecha del documento de referencia es un dato del informe, con la misma dignidad que la fecha de adquisición de la evidencia. Comparar la configuración de un servidor de 2026 con una guía de 2019 sin advertirlo es una debilidad metodológica que la parte contraria localizará sin esfuerzo.
Perfiles, grupos y categorías: tres formas de graduar el rigor
Ninguno de los dos modelos aplica la misma exigencia a todos los sistemas, y ahí es donde las equivalencias se vuelven traicioneras, porque ambos gradúan pero miden cosas diferentes.
Los CIS Benchmarks distinguen dos perfiles de configuración. El nivel 1 agrupa las medidas de bastionado básico que se pueden aplicar en prácticamente cualquier entorno con un impacto operativo reducido. El nivel 2 añade defensa en profundidad para escenarios de alta seguridad, asumiendo de forma explícita que puede degradar funcionalidades o exigir una gestión más costosa. Muchos benchmarks añaden además una separación por rol —servidor o estación de trabajo— y algunos incorporan perfiles alineados con las guías STIG del Departamento de Defensa estadounidense.
Los CIS Controls, que operan en el plano de la gestión y no en el de la configuración, gradúan mediante grupos de implantación. El IG1 reúne 56 salvaguardas de higiene cibernética esencial que cualquier organización debería aplicar; el IG2 añade 74 más para entornos con mayor complejidad; el IG3 completa las 153 salvaguardas de la versión 8.1 para organizaciones expuestas a adversarios sofisticados. Los grupos son acumulativos y se asignan según el perfil de riesgo y los recursos de la entidad.
El Esquema Nacional de Seguridad utiliza dos ejes simultáneos que a menudo se confunden entre sí. El primero es la categoría del sistema —básica, media o alta—, que se determina valorando el impacto de un incidente sobre cinco dimensiones de seguridad: disponibilidad, integridad, confidencialidad, autenticidad y trazabilidad. Esa categoría decide qué medidas del Anexo II son exigibles y con qué refuerzos. El segundo eje es el nivel de madurez con el que cada medida se implanta, expresado en la escala L0 a L5 heredada de los modelos de capacidad, que evalúa si el control existe, está documentado, se aplica de forma repetible, se mide y se mejora.
La consecuencia práctica merece subrayarse. Un sistema puede superar con holgura un CIS Benchmark de nivel 2 y suspender una auditoría del Esquema Nacional de Seguridad, porque el ENS pregunta por documentación, responsabilidades, análisis de riesgos y procedimientos de los que un benchmark de configuración no se ocupa en absoluto. Y a la inversa: un sistema puede tener toda la documentación del ENS impecable y una configuración técnica mediocre que un escaneo con CIS-CAT dejaría en evidencia en cuestión de minutos.
Del documento a la máquina: la cadena de automatización
La utilidad real de un catálogo de bastionado depende de que alguien pueda comprobar automáticamente si una máquina lo cumple. Los dos modelos han resuelto ese problema, con arquitecturas muy distintas.
CIS se apoya en el ecosistema SCAP, el protocolo de automatización de contenidos de seguridad que mantiene el NIST estadounidense. SCAP es un conjunto de especificaciones interoperables que incluye, entre otras, XCCDF para expresar listas de comprobación y sus resultados, OVAL para describir cómo se verifica técnicamente cada comprobación en el sistema, CCE para enumerar configuraciones, CPE para identificar plataformas, CVE para vulnerabilidades y CVSS para puntuarlas. Sobre esa base, la organización distribuye CIS-CAT Pro Assessor, que evalúa un sistema contra el benchmark correspondiente y genera un informe de conformidad; los CIS Build Kits, que aplican la configuración mediante scripts o directivas de grupo; y las CIS Hardened Images, imágenes de máquina virtual ya bastionadas disponibles en los mercados de los proveedores de nube. El acceso a las herramientas avanzadas se articula mediante la suscripción CIS SecureSuite, mientras que los documentos de los benchmarks se descargan gratuitamente previo registro.
El CCN ha construido su propio ecosistema, orientado a la verificación del Esquema Nacional de Seguridad más que a la configuración pura. CLARA audita la configuración de seguridad de sistemas Windows y Linux midiendo el grado de cumplimiento de las guías CCN-STIC aplicables, y emite dos informes: uno técnico con el detalle de controles y brechas, y otro ejecutivo para la dirección del organismo. AMPARO automatiza la implantación y el seguimiento del cumplimiento del ENS. INES recoge el estado de la seguridad de las entidades públicas para el informe nacional. A su lado conviven ROCÍO para la configuración de dispositivos de red, PILAR para el análisis de riesgos y una familia de herramientas de detección y respuesta que quedan fuera de esta comparación.
La diferencia decisiva está en la forma en que cada ecosistema entrega el contenido. El modelo SCAP produce ficheros legibles por máquina que cualquier herramienta compatible puede consumir, lo que permite integrar la comprobación en canalizaciones de despliegue continuo y en sistemas de gestión de configuración de terceros. El modelo del CCN entrega herramientas cerradas, propias, distribuidas a los organismos con licencia, que producen informes concebidos para el expediente administrativo y la auditoría reglada. El primero es un formato; el segundo, un producto.
La trampa del porcentaje de cumplimiento
Toda herramienta de evaluación automática termina produciendo una cifra, y esa cifra tiene una capacidad notable para desactivar el pensamiento crítico de quien la lee. Un informe que anuncia un 92 % de conformidad transmite una sensación de solidez que el dato, por sí solo, no respalda en absoluto.
La razón es sencilla de explicar y difícil de asumir para quien gestiona por indicadores: los controles no pesan lo mismo. Un sistema puede superar centenares de comprobaciones menores y suspender exactamente aquella que permitió la intrusión, y su porcentaje seguirá siendo excelente. La aritmética de la conformidad y la del riesgo real no se parecen, porque la primera cuenta reglas y la segunda depende de la exposición concreta de esa máquina, de los datos que trata y del adversario que tiene enfrente.
A esa distorsión se añade la de las excepciones. Toda organización acaba declarando controles no aplicables o aceptando desviaciones por razones operativas legítimas, y ambas cosas son correctas siempre que estén documentadas y aprobadas por quien tiene competencia para hacerlo. El problema aparece cuando la excepción se convierte en un modo silencioso de subir la nota: se declaran inaplicables los controles que resultan incómodos y el porcentaje mejora sin que la seguridad se mueva un milímetro. En una revisión pericial, el registro de excepciones suele ser el documento más informativo de todo el expediente, porque enseña dónde decidió la organización mirar hacia otro lado y con qué justificación.
Fenz, Heurix, Neubauer y Pechstein (2014) identificaron entre los problemas persistentes de la gestión de la seguridad la dificultad de conectar los inventarios de controles con una estimación defendible del riesgo, y esa desconexión es exactamente la que produce el espejismo del porcentaje. La lectura profesional de un informe de conformidad exige mirar qué falla, no cuánto falla: qué controles concretos están abiertos, sobre qué activos, con qué exposición y desde cuándo.
Ese «desde cuándo» merece un apunte propio. Una evaluación de conformidad es una fotografía del estado de la máquina en un instante. Para el peritaje, lo relevante casi nunca es el estado actual, sino el estado en la fecha del incidente, y eso solo puede reconstruirse a partir de los registros del sistema, de las copias de seguridad de la configuración y de la gestión de cambios. Una herramienta de escaneo ejecutada tres meses después del ataque no acredita cómo estaba configurado el servidor la noche de autos, y presentarla como si lo hiciera es un error metodológico serio.
Quién puede usar cada herramienta y a qué precio
La cuestión del acceso parece administrativa y tiene consecuencias periciales de primer orden.
Los documentos de los CIS Benchmarks se descargan de manera gratuita previo registro, con condiciones de uso que permiten su empleo interno. Las herramientas avanzadas —CIS-CAT Pro Assessor, los Build Kits y las funciones de personalización— se articulan a través de la suscripción CIS SecureSuite, que es de pago para las organizaciones comerciales. Existen además evaluadores libres compatibles con el formato SCAP que permiten ejecutar contenido de conformidad sin depender de la herramienta del propio CIS, lo que amplía notablemente las opciones de quien necesita reproducir una evaluación.
En el lado español, una parte relevante del catálogo CCN-STIC es de acceso público y se descarga sin restricción desde el portal del organismo, mientras que otra parte está reservada a las entidades del ámbito de aplicación. Las herramientas del ecosistema —CLARA, AMPARO, PILAR, ROCÍO y las demás— se licencian a los organismos de la Administración pública, que las obtienen dirigiéndose al Centro Criptológico Nacional.
Un perito de parte que trabaja para una empresa privada o para la defensa de un particular puede encontrarse, por tanto, con que la herramienta oficial con la que se elaboró el informe contrario no está a su alcance. Esa circunstancia no invalida nada por sí sola, y conviene decirlo con claridad para no alimentar impugnaciones frívolas. Lo que sí exige es que el informe que se apoya en una herramienta de acceso restringido documente con detalle qué se comprobó y cómo, de modo que un tercero pueda verificar la conclusión por otros medios: qué guía y versión se aplicó, qué controles concretos resultaron incumplidos, qué evidencia del sistema sostiene cada incumplimiento. Un dictamen que se limite a adjuntar el informe generado por la herramienta, sin ese desglose, se apoya en una caja negra y queda expuesto en el interrogatorio.
El mismo control, dos redacciones
Conviene bajar al detalle con un ejemplo que cualquier profesional reconoce: el acceso remoto por SSH a un servidor Linux, la autenticación de los usuarios y el registro de lo que ocurre en la máquina. Ambos catálogos se ocupan de ello y llegan a configuraciones muy parecidas por caminos muy distintos.
El CIS Benchmark correspondiente a la distribución concreta dedica a este asunto varias decenas de recomendaciones agrupadas en sus secciones de control de acceso y de registro y auditoría. Cada una identifica el fichero y el parámetro exactos, el valor esperado, el comando que permite auditarlo, el comando que permite corregirlo y el perfil —nivel 1 o nivel 2— en el que resulta exigible. El documento es autosuficiente: se puede aplicar sin conocer nada del contexto normativo de la organización.
La guía CCN-STIC de bastionado de la distribución equivalente cubre el mismo terreno, pero cada configuración aparece justificada por su relación con las medidas del Anexo II del Esquema Nacional de Seguridad. El control de acceso remoto conecta con las medidas de control de acceso y con las de protección de las comunicaciones; el registro de actividad conecta con las de trazabilidad y con la exigencia de registro de la actividad de los usuarios, cuyo refuerzo depende de la categoría del sistema. La guía no se limita a decir qué hay que configurar; dice de qué obligación legal se está respondiendo al configurarlo.
| Asunto | Cómo lo formula un CIS Benchmark | Cómo lo formula una guía CCN-STIC |
|---|---|---|
| Acceso remoto por SSH | ||
| Acceso directo de la cuenta de administración | Recomendación con el parámetro exacto, su valor esperado y los comandos de auditoría y corrección; perfil de nivel 1 | Configuración exigida y vinculada a las medidas de control de acceso del Anexo II |
| Segundo factor de autenticación | Habitualmente nivel 2, con el impacto operativo documentado | Exigible en función de la categoría del sistema, con refuerzo en categoría alta |
| Algoritmos y parámetros criptográficos | Lista de cifrados y funciones admitidos para la versión concreta del producto | Remisión a los criterios criptográficos del CCN y a la protección de las comunicaciones |
| Autenticación de los usuarios | ||
| Política de contraseñas | Longitud, complejidad y caducidad con valores concretos y comprobables | Requisitos graduados por categoría, ligados al mecanismo de autenticación elegido |
| Bloqueo por intentos fallidos | Umbral y parámetros recomendados, en perfil de nivel 1 | Medida de control de acceso, con refuerzo según la categoría |
| Registro de actividad y trazabilidad | ||
| Subsistema de auditoría del sistema | Activación, reglas mínimas e inmutabilidad de la configuración | Medida de registro de la actividad; la trazabilidad es una de las cinco dimensiones |
| Centralización de los registros | Envío a un servidor remoto y protección del canal de transporte | Exigida con refuerzos crecientes en las categorías media y alta |
| Sincronización horaria | Servicio y fuentes de tiempo recomendadas para la plataforma | Marcas de tiempo fiables, con valor directo para la prueba |
| Retención de los registros | Periodo recomendado según el perfil aplicado | Periodo vinculado a la categoría y a la necesidad probatoria del organismo |
| Qué aporta cada catálogo sobre el mismo control | ||
| Justificación de la regla | Razonamiento técnico y estimación del impacto previsible de aplicarla | Identificación de la obligación jurídica que se está satisfaciendo |
| Verificación | Comando de auditoría que cualquiera puede repetir y contrastar | Informe de la herramienta oficial, con destino al expediente administrativo |
Un perito atento observará algo relevante en esa tabla. Las configuraciones técnicas coinciden casi por completo, cosa esperable porque ambos catálogos parten del mismo conocimiento profesional acumulado. La divergencia está en la envoltura: dónde encaja cada control, qué lo hace exigible y qué ocurre si falta. Y ahí es donde el trabajo pericial se juega la solidez de sus conclusiones.
Un ayuntamiento, un servidor y dos informes
Para ver el efecto de todo lo anterior conviene trabajar sobre un supuesto. El que sigue es un caso construido con fines docentes, sin correspondencia con ningún expediente real, aunque reúne situaciones que cualquiera que haya trabajado en este terreno reconocerá.
Un ayuntamiento de tamaño medio sufre el cifrado de varios servidores por un ataque de ransomware. Uno de ellos aloja la sede electrónica y trata datos personales de la ciudadanía; el sistema está categorizado como de categoría media conforme al Esquema Nacional de Seguridad. La entrada se produjo a través de un servicio de acceso remoto expuesto a Internet, con autenticación de un solo factor y una contraseña débil de una cuenta de servicio que nadie había revisado en años. La Agencia Española de Protección de Datos abre expediente, el ayuntamiento reclama a su proveedor de servicios gestionados y el asunto acaba en un juzgado de lo contencioso y en un procedimiento civil paralelo.
El informe elaborado desde la perspectiva del Esquema Nacional de Seguridad sitúa el problema en el plano normativo. Comprueba si el sistema estaba correctamente categorizado, si existía declaración de aplicabilidad, si las medidas del Anexo II exigibles a un sistema de categoría media estaban implantadas y con qué madurez, si se había realizado el preceptivo análisis de riesgos y si la auditoría bienal se había pasado y con qué resultado. Sus conclusiones se formulan en términos de medidas concretas incumplidas, con la consecuencia directa de que la entidad no puede acreditar la diligencia que le exigen el propio Esquema y el artículo 32 del Reglamento General de Protección de Datos.
El informe elaborado desde la perspectiva de los CIS Benchmarks trabaja sobre la máquina. Reconstruye la configuración del servidor a partir de la imagen forense y de las copias de la configuración anteriores al incidente, la evalúa contra el benchmark de la versión exacta del sistema operativo y produce un listado de desviaciones con su nivel, su justificación técnica y su procedimiento de comprobación. Sus conclusiones se formulan en términos de apartamiento de la práctica profesional aceptada, con el detalle preciso de qué parámetros estaban mal y desde cuándo puede acreditarse que lo estaban.
El valor conjunto de ambos análisis es mayor que el de cualquiera de los dos por separado. El primero establece la obligación; el segundo, el hecho técnico y su gravedad. El primero responde a la pregunta de si la entidad debía tener aquello configurado de otro modo; el segundo, a la de si un profesional razonable lo habría configurado así y qué consecuencia previsible tenía hacerlo. Cuando el letrado pregunta al perito si el ataque era evitable, la respuesta sólida se apoya en las dos piernas a la vez.
Hay un tercer plano que ninguno de los dos informes cubre y que suele decidir el reparto de responsabilidades entre la entidad y su proveedor: qué decía el contrato, qué obligaciones de seguridad se habían trasladado por escrito y quién tenía atribuida la gestión de aquella cuenta de servicio. Los catálogos técnicos de bastionado dicen cómo debía estar la máquina; el expediente contractual dice a quién correspondía dejarla así.
Qué sostiene cada modelo ante un tribunal
Un informe pericial que afirme que un sistema «no estaba bien configurado» necesita un patrón de comparación explícito y defendible. La elección de ese patrón condiciona el tipo de conclusión que se puede alcanzar.
Cuando el patrón es una guía CCN-STIC y la entidad pertenece al ámbito del Esquema Nacional de Seguridad, la conclusión pericial puede formularse en términos de incumplimiento de una norma reglamentaria vigente. Eso tiene efectos que trascienden lo técnico: alimenta el juicio sobre la diligencia debida de la organización, encaja con el artículo 32 del Reglamento General de Protección de Datos —que exige medidas técnicas y organizativas apropiadas al riesgo— y proporciona a la Agencia Española de Protección de Datos o al juzgado un asidero normativo concreto para valorar la conducta de la entidad.
Cuando el patrón es un CIS Benchmark, la conclusión se mueve en el terreno de la lex artis: el sistema se apartaba de las prácticas de configuración segura generalmente aceptadas por la comunidad profesional internacional. Es un argumento más débil en términos de imputación normativa y, a la vez, sorprendentemente robusto en términos probatorios, porque el catálogo es público, versionado, reproducible y verificable por la parte contraria con la misma herramienta. Cualquier perito de la defensa puede descargar el mismo documento, ejecutar el mismo escaneo y contrastar los resultados.
Merece la pena detenerse en esa última idea, porque es la principal ventaja procesal del modelo CIS. Un informe basado en un benchmark público y en una herramienta de evaluación identificada por versión permite reproducir el experimento. La reproducibilidad es la mejor defensa frente a una impugnación por falta de método. En cambio, un informe elaborado con una herramienta distribuida bajo licencia restringida a organismos públicos puede resultar difícil de replicar por un perito de parte, lo que abre una vía de ataque a la contradicción de la prueba que conviene anticipar en la redacción del informe.
La recomendación práctica que se deduce de todo esto es la de trabajar con ambos patrones y separarlos con nitidez en el dictamen. Un apartado establece el incumplimiento normativo cuando procede, con la guía CCN-STIC y la medida del ENS correspondiente; otro apartado establece la desviación técnica respecto de las buenas prácticas internacionales, con el benchmark, la versión y el registro completo de la evaluación. Las dos conclusiones se refuerzan mutuamente y cubren los dos frentes por los que un informe suele ser atacado.
Donde se solapan, donde se ignoran y donde chocan
El solapamiento entre ambos modelos es amplio en el plano de la configuración técnica de sistemas operativos, servidores web, bases de datos y dispositivos de red. En ese terreno, aplicar un CIS Benchmark de nivel 1 cubre una parte sustancial de las medidas de operación del Anexo II del ENS, aunque nunca de manera automática ni completa.
Los huecos son igual de reveladores. Los CIS Benchmarks no dicen absolutamente nada sobre la organización de la seguridad, la política de seguridad de la información, el análisis de riesgos, la clasificación de la información, la gestión del personal, la continuidad de la actividad, la relación con proveedores o la notificación de incidentes a la autoridad competente. Todo eso está en el marco organizativo del ENS y en las guías de la serie 800, y ninguna herramienta de escaneo lo detecta. En el otro sentido, el catálogo del CCN no cubre con la misma profundidad ni la misma frecuencia de actualización las plataformas de nube pública, los orquestadores de contenedores, las canalizaciones de integración continua o las aplicaciones de escritorio de uso masivo, terrenos en los que CIS mantiene documentos vivos.
Los conflictos existen y conviene documentarlos cuando aparecen. Se producen sobre todo en parámetros criptográficos, en políticas de contraseñas y en periodos de retención de registros, donde cada catálogo puede fijar umbrales distintos por razones perfectamente legítimas. La regla de resolución para una entidad sujeta al ENS es sencilla de enunciar: prevalece la guía CCN-STIC porque es la que responde a una obligación jurídica, y la divergencia con el benchmark se documenta como decisión razonada en el expediente. En una entidad privada no sujeta al ENS, la elección es libre y lo importante es dejar constancia escrita del criterio adoptado y de su motivo.
| Ámbito | CIS Benchmarks y CIS Controls | CCN-STIC y ENS |
|---|---|---|
| Configuración técnica | ||
| Sistemas operativos de servidor y puesto | Cobertura amplia y detallada, por versión de producto | Series 500 y 600, con cobertura desigual y guías de distinta antigüedad |
| Nube pública, contenedores y canalizaciones | Catálogo amplio y de actualización rápida | Cobertura parcial |
| Dispositivos de red | Familias específicas por fabricante | Guías propias y herramienta ROCÍO |
| Marco organizativo | ||
| Política de seguridad y organización | Fuera de su alcance | Núcleo del marco organizativo del ENS y de la serie 800 |
| Análisis y gestión de riesgos | Fuera de su alcance | MAGERIT como metodología y PILAR como herramienta |
| Clasificación de la información | Fuera de su alcance | Determina la categoría del sistema y las medidas exigibles |
| Continuidad de la actividad | Fuera de su alcance | Medidas propias, reforzadas en categoría alta |
| Operación y control | ||
| Gestión y notificación de incidentes | Solo en los CIS Controls, en el plano de gestión | Guía 817 y obligaciones de notificación al CCN-CERT |
| Automatización de la verificación | Formato SCAP abierto, consumible por terceros | Herramientas propias licenciadas a las administraciones |
| Auditoría reglada y conformidad | Evaluación técnica voluntaria, sin efectos jurídicos | Auditoría periódica y declaración o certificación de conformidad |
| Valor ante la Administración española | Indirecto, como acreditación de buena práctica | Directo, por ser la norma aplicable al sistema |
Una estrategia de convivencia
De la comparación se desprende un modelo de trabajo por capas que resulta aplicable tanto a la implantación como a la revisión pericial.
La capa de gobierno la fija siempre el marco jurídico aplicable a la entidad. Para el sector público español y sus proveedores, el Esquema Nacional de Seguridad y las guías de la serie 800. Para una empresa privada, el marco que le corresponda por su actividad y por sus compromisos contractuales, con la Directiva NIS2 en el horizonte inmediato: España aprobó el anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad el 14 de enero de 2025 y, a la fecha de redacción de este artículo, la norma sigue pendiente de publicación en el BOE, con el país ya incumpliendo el plazo de transposición y con un dictamen motivado de la Comisión Europea de por medio.
La capa de configuración técnica se resuelve con la guía CCN-STIC de la plataforma cuando existe y está vigente para la versión que se opera, y con el CIS Benchmark correspondiente cuando no existe, cuando está desactualizada o cuando la tecnología queda fuera del catálogo del CCN. Este criterio, aplicado con honestidad, cubre los huecos sin inventarse nada.
La capa de verificación se apoya en CLARA y AMPARO para la evidencia que va al expediente administrativo, y en CIS-CAT o en cualquier evaluador compatible con SCAP para la comprobación continua y para la evidencia reproducible que sostiene un dictamen. Ambas verificaciones deben quedar fechadas, firmadas y conservadas, porque su valor probatorio depende de que se pueda acreditar cuándo se hicieron.
La capa de riesgo, que ninguno de los dos catálogos resuelve, corresponde a la metodología de análisis y gestión de riesgos, terreno que en España ocupan MAGERIT y la herramienta PILAR y al que dedicaremos la próxima entrega de esta serie.
El bastionado como fuente de evidencia
Hay una dimensión de esta comparación que interesa de manera particular a quien trabaja en ciencias forenses y que rara vez aparece en la literatura de cumplimiento: una parte sustancial de los controles de ambos catálogos no previene ataques, sino que genera el rastro con el que después se investigan.
Las secciones de registro y auditoría de un CIS Benchmark y las medidas de trazabilidad del Anexo II del Esquema Nacional de Seguridad describen, en el fondo, la infraestructura probatoria del sistema. La activación del subsistema de auditoría del núcleo, la centralización de los registros en un servidor remoto, la sincronización horaria fiable, la retención durante un periodo suficiente y la protección de los propios registros frente a manipulación son las condiciones que hacen posible reconstruir después qué ocurrió y cuándo. Un servidor sin esos controles puede sobrevivir a un ataque y, aun así, dejar a la organización sin capacidad alguna de acreditar el alcance de la brecha, lo que en materia de protección de datos se traduce en la imposibilidad de valorar el riesgo para los afectados y de notificar con la precisión que exige la norma.
De ahí que la elección del nivel de bastionado tenga una lectura forense que conviene incorporar a las decisiones técnicas. Ciertas medidas de endurecimiento reducen la superficie de ataque a costa de reducir también el rastro disponible: acortar la retención de registros para ahorrar almacenamiento, desactivar históricos de comandos o limitar el detalle de la auditoría alivian la carga del sistema y empobrecen la investigación posterior. La decisión correcta depende del papel de esa máquina y del tipo de incidentes que se consideren verosímiles, y debería tomarse de forma consciente y documentada, con la participación de quien vaya a tener que investigar si algo sale mal.
Este enfoque es el que la serie CCN-STIC recoge bajo la idea de preparación forense y el que desarrollamos en la entrega dedicada al servidor Linux. Los dos catálogos comparados aquí lo sirven razonablemente bien, con una diferencia de énfasis: el modelo español, al estar concebido para un entorno donde la auditoría reglada y la eventual revisión judicial forman parte del ciclo de vida normal del sistema, cuida especialmente la trazabilidad y su valor probatorio; el modelo CIS aborda la cuestión desde la operación y la detección, con un detalle técnico a menudo superior en la configuración concreta de cada mecanismo.
El coste que nadie apunta en el acta
Queda una advertencia que conviene hacer con franqueza, porque afecta a la utilidad real de cualquiera de los dos catálogos.
Endurecer un sistema tiene un precio operativo, y ese precio lo pagan personas. Beautement, Sasse y Wonham (2008) describieron hace casi dos décadas lo que llamaron el presupuesto de cumplimiento: la capacidad de una organización y de sus empleados para absorber medidas de seguridad es finita, y cuando se agota, las medidas se eluden. Un estudio posterior con administradores de sistemas documentó que las configuraciones erróneas rara vez proceden del desconocimiento; nacen de la presión temporal, de la complejidad de las plataformas y de la falta de retroalimentación sobre las consecuencias de cada ajuste (Dietrich et al., 2018). Aplicar un perfil de nivel 2 completo sobre un sistema en producción sin medir su impacto es la forma más rápida de conseguir que alguien lo desactive por completo tres semanas después.
Los CIS Benchmarks tienen aquí una virtud que conviene reconocer: documentan el impacto previsible de cada recomendación, lo que permite decidir con información. Las guías del CCN, al estar ancladas en una categorización previa del sistema, resuelven el problema por otra vía, graduando la exigencia según el riesgo declarado. Ambas soluciones son razonables y ninguna evita la conversación incómoda con quien tiene que operar la máquina el lunes por la mañana.
Dos mapas, un solo terreno
La comparación entre los CIS Benchmarks y las guías CCN-STIC no admite un ganador, porque responden a preguntas distintas. Uno pregunta cómo se configura correctamente una tecnología según el mejor conocimiento profesional disponible; el otro pregunta qué exige el ordenamiento jurídico español a un sistema de información público. Trabajar solo con el primero deja a una entidad obligada expuesta a un incumplimiento normativo; trabajar solo con el segundo deja huecos técnicos en todo lo que el catálogo español no cubre con la velocidad a la que cambia la tecnología.
Para el profesional de la criminología y de las ciencias forenses hay una lección que trasciende lo técnico. La configuración de un sistema es un hecho comprobable y fechable, y ambos catálogos convierten ese hecho en un enunciado defendible. La diferencia está en qué tipo de enunciado se obtiene: una desviación respecto de la práctica profesional aceptada, o un incumplimiento de una norma reglamentaria. Saber cuál de los dos se está afirmando, y con qué respaldo documental, es lo que separa un informe que resiste el interrogatorio de otro que se deshace en la primera pregunta de la parte contraria.
En la próxima entrega de esta serie entramos en el terreno que ninguno de estos dos catálogos cubre: el análisis y la gestión de riesgos con MAGERIT y PILAR, la metodología y la herramienta que el Esquema Nacional de Seguridad presupone y que rara vez se explican con el detalle que merecen.
The Same Server, Two Verdicts: CIS Benchmarks and the CCN-STIC Guides Compared
Two hardening catalogues born of different traditions —the consensus of an international technical community and the authority of a State agency— examine the same machine and do not always reach the same conclusion. We compare their architecture, their scope and, above all, what each one can sustain in court.
Two ways of saying the same thing
A forensic examiner receives the image of a compromised server together with a deceptively simple question: was that machine properly configured on the day of the attack? The answer depends entirely on the catalogue used for comparison. If the report relies on the CIS Benchmarks, the outcome will be a conformity score across several hundred automated checks, with its percentage and its list of deviations. If it relies on the CCN-STIC guides, the outcome will be a judgement about compliance with a Spanish legal instrument, the National Security Framework, carrying specific administrative consequences. Both answers may be correct and still reach different conclusions about the same machine.
That divergence is anything but anecdotal. Spanish forensic practice lives with both frameworks: the public sector is bound by the National Security Framework and works with the guides issued by the National Cryptologic Centre, while a large part of the private sector —particularly companies with international parent groups, cloud providers or market certifications— configures its systems according to the CIS Benchmarks because that is the language their auditors speak. When an incident reaches a court, both catalogues appear, and it falls to the expert witness to explain their differences to the bench.
This article continues the series that Actum Forense Press devotes to the CCN guides and honours a commitment made in the instalment on forensic readiness for Linux servers, where this comparison was announced. The aim is twofold: to describe precisely how each model is built, and to offer criteria for deciding which one to invoke, when, and with what evidentiary reach.
The lineage of two catalogues
The Center for Internet Security is a United States non-profit organisation established in 2000. Its best-known product, the CIS Benchmarks, is a collection of secure configuration documents produced by volunteer communities —system administrators, auditors, vendors, researchers— who work on specific platforms and publish their recommendations after a consensus process. The organisation also maintains the CIS Critical Security Controls, a high-level framework of safeguards whose version 8.1 was released in June 2024 with explicit alignment to the NIST Cybersecurity Framework 2.0.
The National Cryptologic Centre belongs to an entirely different tradition. Attached to the Spanish National Intelligence Centre, it was created by Act 11/2002 of 6 May, which regulates the CNI, and its regime was developed by Royal Decree 421/2004 of 12 March. The CCN-STIC series —Security of Information and Communication Technologies— is the instrument through which that agency exercises a function conferred on it by law: to produce and disseminate standards, instructions, guides and recommendations to secure the information systems of the Spanish public administration.
The difference in origin determines almost everything else. A CIS Benchmark emerges from a conversation among professionals who contribute their experience with a specific product, and its authority derives from technical quality and market acceptance. A CCN-STIC guide emerges from a body with delegated regulatory power, and its authority derives from the law. The former persuades; the latter binds those within its scope.
One nuance is frequently overlooked. The binding force of the CCN-STIC guides is not general: it flows from Royal Decree 311/2022 of 3 May, which governs the National Security Framework. That text binds the public sector and, by contractual extension, the private suppliers who serve it; for every other Spanish company, a CCN-STIC guide is exactly what its name suggests, a high-quality technical recommendation with the same voluntary status as a CIS Benchmark.
The international neighbourhood of both catalogues
Neither model is an isolated curiosity, and placing them on the comparative map helps explain why they are built the way they are.
The closest relative of the CCN-STIC guides is not the CIS Benchmark but the STIGs of the United States Department of Defense, produced by the Defense Information Systems Agency. They share the essential logic: a State body with authority over particular systems publishes enforceable configurations, with regulated audit and consequences for non-compliance. The resemblance goes so far that several CIS Benchmarks include a profile aligned with the corresponding STIG, precisely to serve organisations working with the US administration.
In the realm of control catalogues, the functional equivalent of Annex II of the Spanish National Security Framework is NIST Special Publication 800-53, which enumerates security and privacy controls for federal systems, with its own graduation into baselines. In the field of voluntary market certification, the reference remains the ISO/IEC 27000 family, with 27001 as the certifiable management system and 27002 as the control catalogue.
Europe contributes its own national traditions. Germany maintains the IT-Grundschutz corpus of the Federal Office for Information Security, combining risk methodology with configuration modules. France publishes technical hardening guides of notable quality through ANSSI, freely available. Both share the decisive feature of the Spanish model: a public authority that writes and updates, with a scope of obligation defined by its own legal order.
What sets the CIS model apart in that landscape is its transnational character and its detachment from any particular legal system. That apparent weakness is its greatest operational strength, because it allows the catalogue to be adopted as a common reference by organisations operating across several jurisdictions, and it explains why a Spanish company with subsidiaries in three countries ends up working with CIS even when its compliance matrix mentions the National Security Framework or ISO 27001.
Who writes the rule and who answers for it
The process behind a CIS Benchmark is open and traceable. Working communities discuss each recommendation in public forums, the draft goes through a consensus period, and the resulting document is published with a version number and a date. Every control follows a stable structure that proves extremely useful in forensic work: description, technical rationale, step-by-step audit procedure, remediation procedure and expected impact of applying it. That last field is one of the model’s most honest contributions, because it acknowledges in writing that hardening a system has an operational cost.
The CCN-STIC guides follow a different editorial logic. They are produced internally, with the participation of agencies and companies where appropriate, and published under the applicable classification; a large part of the catalogue is publicly accessible and another part is restricted to public bodies. The drafting style is that of a regulatory document: it describes the mechanism, sets the required configuration and refers to the measure in Annex II of the National Security Framework being satisfied. Traceability points towards the rule rather than towards the technical discussion that produced it.
That asymmetry has a direct consequence in court. Faced with a question such as «why did that service have to be disabled?», a CIS Benchmark offers documented technical reasoning that the expert can read aloud and that a bench understands without prior knowledge. A CCN-STIC guide offers something different and often more powerful: proof that the configuration in question was required by a Spanish regulation in force. The first explains; the second imputes.
The map of each catalogue
Anyone approaching the CCN-STIC series for the first time discovers an organisation by numbered blocks that reflects the nature of the document rather than the technology: series 000 covers policies; 100, procedures; 200, standards; 300, technical instructions; 400, general guides; 500, Windows environments; 600, other environments, including Linux, Unix and databases; 800, the development of the National Security Framework; 900, technical reports; 1000, secure use of products; and 2000, the work of the Certification Body. A professional looking for guidance on hardening a specific distribution must locate the relevant guide in series 600 and check whether one exists for that version.
The CIS catalogue is organised exclusively by technology. There are families for operating systems, cloud providers, server software, network devices, browsers and desktop applications, container tooling and deployment pipelines, and mobile platforms. Each document is identified by product and version —for instance, the CIS Ubuntu Linux 24.04 LTS Benchmark v1.0.0, released on 26 August 2024— and is internally structured into functional sections that recur across platforms: initial setup, services, network, logging and auditing, access control and authentication, and system maintenance.
The coverage comparison yields an uncomfortable result for anyone working in Spain. The CCN catalogue is excellent along the regulatory axis and uneven along the technological one: there are superb guides for the environments the administration uses massively, and notable gaps or outdated versions for recently adopted technologies. The CIS catalogue is the reverse: it covers a very wide technological surface, with fast updates tied to each product’s life cycle, and it has no Spanish legal anchoring whatsoever.
How a catalogue ages
There is a problem that the promotional literature of both models tends to skip and that is central to forensic work: hardening documents age at the speed of the product they describe, and that speed rarely matches the publishing rhythm of the issuing body.
The CIS model ties each document to a specific product version and versions it independently. When a new major release of an operating system appears, the relevant community works on a new benchmark, which coexists with the previous one for a time. The result is a catalogue with a high number of live documents and clear traceability: it is always known which benchmark version applies to which product version and when each was published.
The CCN catalogue presents an uneven picture. Some hardening guides are fully current and others were written for product versions that are now out of vendor support. That is an inevitable consequence of catalogue size and of the resources of any public body, and the CCN has been correcting it: the update to the CLARA tool added verification of the operating system life cycle and reporting of its end of support in both the technical and the executive reports, alongside new series 500 guides for Windows environments.
The practical situation that arises frequently is this: a product version has to be hardened or audited for which a CCN-STIC guide exists for an earlier release and a CIS Benchmark exists for the exact one. The professional way out is to apply the Spanish guide wherever it remains applicable, complete it with the updated benchmark for whatever the new version changed, and record that decision in writing with its reasons. What should never be done is to apply a guide written for another version mechanically, without checking which parameters have changed name, location or default behaviour, because the result may be a configuration that looks hardened and is not.
For forensic work, the date of the reference document is a data point of the report, as important as the date of evidence acquisition. Comparing the configuration of a 2026 server against a 2019 guide without saying so is a methodological weakness that opposing counsel will find effortlessly.
Profiles, groups and categories: three ways of grading rigour
Neither model applies the same demands to every system, and this is where equivalences become treacherous, because both grade but measure different things.
The CIS Benchmarks distinguish two configuration profiles. Level 1 groups basic hardening measures applicable in practically any environment with limited operational impact. Level 2 adds defence in depth for high-security scenarios, explicitly accepting that it may degrade functionality or demand more costly management. Many benchmarks also separate by role —server or workstation— and some include profiles aligned with the US Department of Defense STIGs.
The CIS Controls, which operate in the management plane rather than the configuration plane, grade through implementation groups. IG1 gathers 56 safeguards of essential cyber hygiene that any organisation should apply; IG2 adds 74 more for environments of greater complexity; IG3 completes the 153 safeguards of version 8.1 for organisations exposed to sophisticated adversaries. The groups are cumulative and are assigned according to the entity’s risk profile and resources.
The Spanish National Security Framework uses two simultaneous axes that are often confused with one another. The first is the system category —basic, medium or high— determined by assessing the impact of an incident across five security dimensions: availability, integrity, confidentiality, authenticity and traceability. That category decides which Annex II measures are required and with what reinforcements. The second axis is the maturity level at which each measure is implemented, expressed on the L0 to L5 scale inherited from capability models, which assesses whether the control exists, is documented, is applied repeatably, is measured and is improved.
The practical consequence deserves emphasis. A system may comfortably pass a Level 2 CIS Benchmark and fail a National Security Framework audit, because the Framework asks about documentation, responsibilities, risk analysis and procedures that a configuration benchmark does not address at all. And conversely: a system may have impeccable Framework documentation and a mediocre technical configuration that a CIS-CAT scan would expose within minutes.
From document to machine: the automation chain
The real usefulness of a hardening catalogue depends on someone being able to check automatically whether a machine complies with it. Both models have solved that problem, with very different architectures.
CIS relies on the SCAP ecosystem, the security content automation protocol maintained by the US NIST. SCAP is a suite of interoperable specifications including, among others, XCCDF for expressing checklists and their results, OVAL for describing how each check is technically verified on the system, CCE for enumerating configurations, CPE for identifying platforms, CVE for vulnerabilities and CVSS for scoring them. On that basis, the organisation distributes CIS-CAT Pro Assessor, which evaluates a system against the corresponding benchmark and produces a conformity report; the CIS Build Kits, which apply the configuration through scripts or group policies; and the CIS Hardened Images, pre-hardened virtual machine images available in cloud provider marketplaces. Access to advanced tooling runs through the CIS SecureSuite membership, while the benchmark documents themselves are downloaded free of charge after registration.
The CCN has built its own ecosystem, oriented towards verifying the National Security Framework rather than pure configuration. CLARA audits the security configuration of Windows and Linux systems, measuring the degree of compliance with the applicable CCN-STIC guides, and issues two reports: a technical one detailing controls and gaps, and an executive one for the organisation’s management. AMPARO automates the implementation and monitoring of Framework compliance. INES collects the security status of public entities for the national report. Alongside them sit ROCÍO for network device configuration, PILAR for risk analysis and a family of detection and response tools that fall outside this comparison.
The decisive difference lies in how each ecosystem delivers its content. The SCAP model produces machine-readable files that any compatible tool can consume, allowing checks to be embedded in continuous delivery pipelines and third-party configuration management systems. The CCN model delivers closed, proprietary tools, licensed to public bodies, producing reports designed for the administrative file and the regulated audit. The first is a format; the second, a product.
The compliance-percentage trap
Every automated assessment tool ends up producing a number, and that number has a remarkable capacity to switch off the critical thinking of whoever reads it. A report announcing 92 % conformity conveys a sense of solidity that the figure alone does not support at all.
The reason is easy to state and hard to accept for anyone managing by indicators: controls do not carry equal weight. A system may pass hundreds of minor checks and fail precisely the one that enabled the intrusion, and its percentage will still look excellent. The arithmetic of conformity and the arithmetic of real risk bear no resemblance, because the first counts rules and the second depends on the specific exposure of that machine, the data it handles and the adversary it faces.
To that distortion one must add the matter of exceptions. Every organisation eventually declares controls not applicable or accepts deviations for legitimate operational reasons, and both are perfectly correct provided they are documented and approved by whoever has authority to do so. The problem arises when the exception becomes a quiet way of improving the score: the inconvenient controls are declared inapplicable and the percentage rises without security moving an inch. In a forensic review, the exceptions register is often the most informative document in the whole file, because it shows where the organisation chose to look away, and on what grounds.
Fenz, Heurix, Neubauer and Pechstein (2014) identified, among the persistent problems of security management, the difficulty of connecting control inventories with a defensible estimate of risk, and that disconnection is exactly what produces the mirage of the percentage. A professional reading of a conformity report requires looking at what fails, not at how much fails: which specific controls are open, on which assets, with what exposure and since when.
That «since when» deserves a note of its own. A conformity assessment is a snapshot of the machine at one instant. For forensic purposes, what matters is almost never the current state but the state on the date of the incident, and that can only be reconstructed from system logs, configuration backups and change management records. A scan run three months after the attack does not establish how the server was configured on the night in question, and presenting it as though it did is a serious methodological error.
Who may use each tool, and at what price
The question of access looks administrative and carries first-order forensic consequences.
The CIS Benchmark documents are downloaded free of charge after registration, under terms of use that permit internal use. The advanced tooling —CIS-CAT Pro Assessor, the Build Kits and the customisation features— runs through the CIS SecureSuite membership, which is chargeable for commercial organisations. There are also free assessors compatible with the SCAP format that allow conformity content to be executed without depending on the CIS tool itself, which considerably widens the options for anyone needing to reproduce an assessment.
On the Spanish side, a substantial part of the CCN-STIC catalogue is publicly accessible and can be downloaded without restriction from the agency’s portal, while another part is reserved for entities within its scope. The ecosystem tools —CLARA, AMPARO, PILAR, ROCÍO and the rest— are licensed to public administration bodies, which obtain them by applying to the National Cryptologic Centre.
An expert instructed by a private company or by the defence of an individual may therefore find that the official tool used to produce the opposing report is beyond their reach. That circumstance does not, in itself, invalidate anything, and this should be said plainly so as not to encourage frivolous challenges. What it does require is that a report relying on a restricted tool document in detail what was checked and how, so that a third party can verify the conclusion by other means: which guide and version were applied, which specific controls were breached, and which system evidence supports each breach. A report that merely attaches the tool’s output, without that breakdown, rests on a black box and is exposed under cross-examination.
The same control, two wordings
It is worth descending into detail with an example any professional will recognise: remote SSH access to a Linux server, user authentication and the recording of what happens on the machine. Both catalogues address these matters and arrive at very similar configurations by very different routes.
The CIS Benchmark for the specific distribution devotes several dozen recommendations to this area, grouped in its access control and its logging and auditing sections. Each one identifies the exact file and parameter, the expected value, the command to audit it, the command to remediate it and the profile —Level 1 or Level 2— in which it is required. The document is self-sufficient: it can be applied without knowing anything about the organisation’s regulatory context.
The CCN-STIC hardening guide for the equivalent distribution covers the same ground, but each configuration is justified by its relationship with the measures in Annex II of the National Security Framework. Remote access control connects with access control measures and with communications protection; activity logging connects with traceability requirements and with the obligation to record user activity, whose reinforcement depends on the system category. The guide does not merely state what must be configured; it states which legal obligation is being met by configuring it.
| Matter | How a CIS Benchmark frames it | How a CCN-STIC guide frames it |
|---|---|---|
| Remote access over SSH | ||
| Direct login of the administrative account | Recommendation with the exact parameter, its expected value and both audit and remediation commands; Level 1 profile | Required configuration, tied to the access control measures of Annex II |
| Second authentication factor | Usually Level 2, with the operational impact documented | Required depending on the system category, reinforced for high category |
| Cryptographic algorithms and parameters | List of ciphers and functions accepted for the specific product version | Reference to the CCN cryptographic criteria and to communications protection |
| User authentication | ||
| Password policy | Length, complexity and expiry with concrete, checkable values | Requirements graded by category, tied to the chosen authentication mechanism |
| Lockout after failed attempts | Recommended threshold and parameters, Level 1 profile | Access control measure, reinforced according to category |
| Activity logging and traceability | ||
| System audit subsystem | Enablement, minimum rules and immutability of the configuration | Activity logging measure; traceability is one of the five dimensions |
| Centralised logging | Forwarding to a remote server and protection of the transport channel | Required with increasing reinforcement for medium and high categories |
| Time synchronisation | Recommended service and time sources for the platform | Reliable timestamps, with direct evidentiary value |
| Log retention | Period recommended according to the applied profile | Period tied to the category and to the evidentiary needs of the entity |
| What each catalogue adds to the same control | ||
| Rationale for the rule | Technical reasoning and estimate of the expected impact of applying it | Identification of the legal obligation being satisfied |
| Verification | Audit command that anyone can repeat and contrast | Report from the official tool, destined for the administrative file |
An attentive examiner will notice something relevant in that table. The technical configurations coincide almost entirely, which is to be expected because both catalogues draw on the same accumulated professional knowledge. The divergence lies in the wrapping: where each control fits, what makes it enforceable and what happens if it is missing. And that is where forensic work stakes the soundness of its conclusions.
A town council, a server and two reports
To see the effect of all the above, a worked scenario helps. What follows is a case constructed for teaching purposes, with no correspondence to any real file, although it assembles situations that anyone who has worked in this field will recognise.
A medium-sized town council suffers the encryption of several servers in a ransomware attack. One of them hosts the electronic administrative portal and processes citizens’ personal data; the system is classified as medium category under the National Security Framework. Entry occurred through a remote access service exposed to the Internet, with single-factor authentication and a weak password on a service account nobody had reviewed in years. The Spanish Data Protection Agency opens proceedings, the council brings a claim against its managed services provider, and the matter ends up before an administrative court and in a parallel civil action.
The report written from the perspective of the National Security Framework places the problem in the regulatory plane. It checks whether the system was correctly categorised, whether a statement of applicability existed, whether the Annex II measures required of a medium category system were implemented and with what maturity, whether the mandatory risk analysis had been carried out and whether the biennial audit had been passed and with what result. Its conclusions are framed in terms of specific measures breached, with the direct consequence that the entity cannot demonstrate the diligence required of it by the Framework itself and by Article 32 of the General Data Protection Regulation.
The report written from the perspective of the CIS Benchmarks works on the machine. It reconstructs the server’s configuration from the forensic image and from configuration backups predating the incident, evaluates it against the benchmark for the exact operating system version and produces a list of deviations with their level, their technical rationale and their verification procedure. Its conclusions are framed in terms of departure from accepted professional practice, with precise detail of which parameters were wrong and since when that can be established.
The joint value of both analyses exceeds that of either taken separately. The first establishes the obligation; the second, the technical fact and its gravity. The first answers whether the entity should have configured that differently; the second, whether a reasonable professional would have configured it that way and what foreseeable consequence followed. When counsel asks the expert whether the attack was avoidable, the solid answer stands on both legs at once.
There is a third plane that neither report covers and that usually decides the allocation of liability between the entity and its provider: what the contract said, which security obligations had been transferred in writing and who had been assigned the management of that service account. Technical hardening catalogues state how the machine should have been; the contractual file states whose job it was to leave it that way.
What each model can sustain in court
An expert report asserting that a system «was not properly configured» needs an explicit and defensible standard of comparison. The choice of that standard conditions the type of conclusion that can be reached.
When the standard is a CCN-STIC guide and the entity falls within the scope of the National Security Framework, the expert conclusion can be framed as breach of a regulation in force. That has effects beyond the technical: it feeds the assessment of the organisation’s due diligence, fits with Article 32 of the General Data Protection Regulation —which requires technical and organisational measures appropriate to the risk— and gives the Data Protection Agency or the court a concrete normative anchor for assessing the entity’s conduct.
When the standard is a CIS Benchmark, the conclusion moves into the territory of professional standards of care: the system departed from secure configuration practices generally accepted by the international professional community. It is a weaker argument in terms of regulatory imputation and, at the same time, surprisingly robust in evidentiary terms, because the catalogue is public, versioned, reproducible and verifiable by the opposing party with the same tool. Any expert for the defence can download the same document, run the same scan and contrast the results.
That last idea deserves a pause, because it is the main procedural advantage of the CIS model. A report based on a public benchmark and on an assessment tool identified by version allows the experiment to be reproduced. Reproducibility is the best defence against a challenge for lack of method. By contrast, a report produced with a tool licensed only to public bodies may prove difficult for an opposing expert to replicate, which opens a line of attack on the adversarial testing of the evidence that is best anticipated when drafting.
The practical recommendation that follows is to work with both standards and to separate them clearly in the report. One section establishes regulatory breach where applicable, with the CCN-STIC guide and the corresponding Framework measure; another establishes technical deviation from international good practice, with the benchmark, its version and the full record of the assessment. The two conclusions reinforce each other and cover the two fronts on which a report is usually attacked.
Where they overlap, where they look away and where they clash
The overlap between the two models is broad in the technical configuration of operating systems, web servers, databases and network devices. On that ground, applying a Level 1 CIS Benchmark covers a substantial part of the operational measures in Annex II of the Framework, though never automatically or completely.
The gaps are equally revealing. The CIS Benchmarks say nothing whatsoever about security governance, information security policy, risk analysis, information classification, personnel management, business continuity, supplier relationships or incident notification to the competent authority. All of that sits in the organisational framework of the Spanish scheme and in the series 800 guides, and no scanning tool detects it. In the other direction, the CCN catalogue does not cover with the same depth or update frequency the public cloud platforms, container orchestrators, continuous integration pipelines or mass-market desktop applications for which CIS maintains living documents.
Conflicts do occur and should be documented when they appear. They arise mainly in cryptographic parameters, password policies and log retention periods, where each catalogue may set different thresholds for perfectly legitimate reasons. The resolution rule for an entity subject to the Spanish Framework is simple to state: the CCN-STIC guide prevails because it answers a legal obligation, and the divergence from the benchmark is documented as a reasoned decision in the file. In a private entity outside the Framework, the choice is free and what matters is leaving a written record of the criterion adopted and its rationale.
| Scope | CIS Benchmarks and CIS Controls | CCN-STIC and the Spanish Framework |
|---|---|---|
| Technical configuration | ||
| Server and workstation operating systems | Broad, detailed coverage, by product version | Series 500 and 600, with uneven coverage and guides of differing vintage |
| Public cloud, containers and pipelines | Broad catalogue with fast updates | Partial coverage |
| Network devices | Vendor-specific families | Own guides and the ROCÍO tool |
| Organisational framework | ||
| Security policy and governance | Out of scope | Core of the Framework’s organisational layer and of the series 800 guides |
| Risk analysis and management | Out of scope | MAGERIT as methodology and PILAR as tool |
| Information classification | Out of scope | Determines the system category and the required measures |
| Business continuity | Out of scope | Specific measures, reinforced for high category |
| Operation and control | ||
| Incident management and notification | Only in the CIS Controls, at management level | Guide 817 and notification duties towards CCN-CERT |
| Verification automation | Open SCAP format, consumable by third parties | Proprietary tools licensed to public administrations |
| Regulated audit and conformity | Voluntary technical assessment, with no legal effect | Periodic audit and declaration or certification of conformity |
| Value before the Spanish administration | Indirect, as evidence of good practice | Direct, being the rule applicable to the system |
A strategy for living with both
The comparison suggests a layered working model applicable both to implementation and to forensic review.
The governance layer is always set by the legal framework applicable to the entity. For the Spanish public sector and its suppliers, the National Security Framework and the series 800 guides. For a private company, whichever framework corresponds to its activity and contractual commitments, with the NIS2 Directive on the immediate horizon: Spain approved the draft Cybersecurity Coordination and Governance Act on 14 January 2025 and, at the time of writing, the instrument is still pending publication in the Official State Gazette, with the country already in breach of the transposition deadline and a reasoned opinion from the European Commission on the table.
The technical configuration layer is resolved with the CCN-STIC guide for the platform where one exists and is current for the version in operation, and with the corresponding CIS Benchmark where it does not exist, is outdated or the technology falls outside the CCN catalogue. Applied honestly, this criterion fills the gaps without inventing anything.
The verification layer relies on CLARA and AMPARO for the evidence that goes into the administrative file, and on CIS-CAT or any SCAP-compatible assessor for continuous checking and for the reproducible evidence that sustains an expert opinion. Both verifications must be dated, signed and preserved, because their evidentiary value depends on being able to establish when they were performed.
The risk layer, which neither catalogue resolves, belongs to risk analysis and management methodology, ground occupied in Spain by MAGERIT and the PILAR tool, to which we devote the next instalment of this series.
Hardening as a source of evidence
There is a dimension of this comparison of particular interest to forensic science practitioners and rarely present in compliance literature: a substantial part of the controls in both catalogues does not prevent attacks but generates the trail with which attacks are later investigated.
The logging and auditing sections of a CIS Benchmark and the traceability measures of Annex II of the Spanish Framework describe, in essence, the evidentiary infrastructure of the system. Enabling the kernel audit subsystem, centralising logs on a remote server, reliable time synchronisation, retention for a sufficient period and protection of the logs themselves against tampering are the conditions that make it possible to reconstruct afterwards what happened and when. A server without those controls may survive an attack and still leave the organisation unable to establish the scope of the breach, which in data protection terms translates into an inability to assess the risk to data subjects and to notify with the precision the law requires.
Hence the choice of hardening level carries a forensic reading worth incorporating into technical decisions. Certain hardening measures reduce the attack surface at the cost of also reducing the available trail: shortening log retention to save storage, disabling command histories or limiting audit detail eases the load on the system and impoverishes the subsequent investigation. The right decision depends on the role of that machine and on the kinds of incident considered plausible, and it should be taken consciously and documented, with the involvement of whoever will have to investigate if something goes wrong.
This is the approach the CCN-STIC series captures under the notion of forensic readiness and the one we developed in the instalment devoted to the Linux server. Both catalogues compared here serve it reasonably well, with a difference of emphasis: the Spanish model, designed for an environment where regulated audit and eventual judicial review form part of the normal life cycle of a system, takes particular care with traceability and its evidentiary value; the CIS model approaches the question from operations and detection, often with superior technical detail in the specific configuration of each mechanism.
The cost nobody records in the minutes
One warning remains, and it should be made frankly, because it affects the real usefulness of either catalogue.
Hardening a system has an operational price, and that price is paid by people. Beautement, Sasse and Wonham (2008) described almost two decades ago what they called the compliance budget: the capacity of an organisation and its employees to absorb security measures is finite, and once exhausted, the measures are circumvented. A later study with system administrators documented that misconfigurations rarely stem from ignorance; they arise from time pressure, platform complexity and the absence of feedback about the consequences of each adjustment (Dietrich et al., 2018). Applying a full Level 2 profile to a production system without measuring its impact is the fastest way to ensure somebody disables it entirely three weeks later.
The CIS Benchmarks have a virtue here worth acknowledging: they document the expected impact of each recommendation, which allows decisions to be made with information. The CCN guides, anchored in a prior categorisation of the system, solve the problem by another route, grading the requirement according to the declared risk. Both solutions are reasonable and neither spares anyone the awkward conversation with the person who has to operate the machine on Monday morning.
Two maps, one territory
The comparison between the CIS Benchmarks and the CCN-STIC guides admits no winner, because they answer different questions. One asks how a technology is correctly configured according to the best available professional knowledge; the other asks what the Spanish legal order requires of a public information system. Working only with the first leaves a bound entity exposed to regulatory breach; working only with the second leaves technical gaps across everything the Spanish catalogue does not cover at the speed technology changes.
For criminology and forensic science practitioners there is a lesson that goes beyond the technical. The configuration of a system is a verifiable, datable fact, and both catalogues turn that fact into a defensible statement. The difference lies in which kind of statement is obtained: a deviation from accepted professional practice, or breach of a regulation. Knowing which of the two is being asserted, and with what documentary support, is what separates a report that withstands cross-examination from one that falls apart at opposing counsel’s first question.
In the next instalment of this series we enter the ground neither of these catalogues covers: risk analysis and management with MAGERIT and PILAR, the methodology and the tool that the National Security Framework presupposes and that are seldom explained in the detail they deserve.
Bibliografía y fuentes · References
Beautement, A., Sasse, M. A., & Wonham, M. (2008). The compliance budget: Managing security behaviour in organisations. En Proceedings of the 2008 New Security Paradigms Workshop (NSPW ’08) (pp. 47-58). ACM. https://doi.org/10.1145/1595676.1595684
Center for Internet Security. (2024). CIS Critical Security Controls, version 8.1. CIS. https://www.cisecurity.org/controls/v8-1
Center for Internet Security. (2024). CIS Ubuntu Linux 24.04 LTS Benchmark, v1.0.0. CIS. https://www.cisecurity.org/benchmark/ubuntu_linux
Centro Criptológico Nacional. (2025). El CCN actualiza su herramienta CLARA de auditoría para el ENS y para Sistemas Clasificados. CCN-CERT. https://www.ccn-cert.cni.es
Centro Criptológico Nacional. (s. f.). Series CCN-STIC. Guías de acceso público. CCN-CERT. https://www.ccn-cert.cni.es/es/series-ccn-stic
Dietrich, C., Krombholz, K., Borgolte, K., & Fiebig, T. (2018). Investigating system operators’ perspective on security misconfigurations. En Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security (CCS ’18) (pp. 1272-1289). ACM. https://doi.org/10.1145/3243734.3243794
Fenz, S., Heurix, J., Neubauer, T., & Pechstein, F. (2014). Current challenges in information security risk management. Information Management & Computer Security, 22(5), 410-430. https://doi.org/10.1108/IMCS-07-2013-0053
Ley 11/2002, de 6 de mayo, reguladora del Centro Nacional de Inteligencia. Boletín Oficial del Estado, 109, de 7 de mayo de 2002.
National Institute of Standards and Technology. (s. f.). Security Content Automation Protocol (SCAP). NIST Computer Security Resource Center. https://csrc.nist.gov/projects/security-content-automation-protocol
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.
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.
Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo, 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 y a la libre circulación de estos datos (RGPD). Diario Oficial de la Unión Europea, L 119, de 4 de mayo de 2016.
Directiva (UE) 2022/2555 del Parlamento Europeo y del Consejo, 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 NIS2). Diario Oficial de la Unión Europea, L 333, de 27 de diciembre de 2022.
Shameli-Sendi, A., Aghababaei-Barzegar, R., & Cheriet, M. (2016). Taxonomy of information security risk assessment (ISRA). Computers & Security, 57, 14-30. https://doi.org/10.1016/j.cose.2015.11.001
Créditos de las imágenes
Todos los esquemas y la imagen de portada de este artículo son de elaboración propia para Actum Forense Press, realizados a partir de la documentación pública citada en la bibliografía. Se publican bajo la misma licencia que el resto de los contenidos originales de la revista.
Nota sobre la fecha de las fuentes: la información sobre versiones de documentos, herramientas y estado de la tramitación normativa está referida a agosto de 2026. Los catálogos comparados se actualizan de forma continua, por lo que conviene verificar la vigencia de cada referencia antes de emplearla en un informe.
Deja una respuesta