ENS para proveedores del sector público: plan de adecuación

Se identifican:

• Entidad pública cliente.
• Servicio y contrato.
• Sistemas y centros.
• Datos y comunicaciones.
• Personal con acceso.
• Nube y subcontratistas.
• Integraciones.
• Responsabilidades compartidas.

No toda la empresa tiene que entrar en el alcance si el servicio puede delimitarse, pero no se excluyen las dependencias críticas.

Si prefieres acompañamiento, nuestro servicio de adecuación al ENS cubre desde el alcance hasta la preparación de la conformidad.

El artículo 2.3 del Real Decreto 311/2022 es la base legal exacta de esta obligación: el ENS «también se aplica a los sistemas de información de las entidades del sector privado […] cuando, de acuerdo con la normativa aplicable y en virtud de una relación contractual, presten servicios o provean soluciones a las entidades del sector público para el ejercicio por estas de sus competencias y potestades administrativas». El mismo artículo extiende la cautela «también a la cadena de suministro de dichos contratistas, en la medida que sea necesario y de acuerdo con los resultados del correspondiente análisis de riesgos»: un subcontratista no queda fuera solo por no firmar directamente con la administración.

En la práctica, esto obliga a que los pliegos de contratación pública incorporen «todos aquellos requisitos necesarios para asegurar la conformidad con el ENS de los sistemas de información en los que se sustenten los servicios prestados por los contratistas, tales como la presentación de las correspondientes Declaraciones o Certificaciones de Conformidad con el ENS». Conviene revisar el pliego y el contrato antes de asumir que el ENS «no aplica» solo porque el servicio parece menor.

Las funciones deben estar formalizadas y evitar conflictos incompatibles entre sí.

Se valoran las dimensiones de seguridad previstas en el ENS: disponibilidad, autenticidad, integridad, confidencialidad y trazabilidad. El impacto determina la categoría básica, media o alta, siguiendo el procedimiento del anexo I del Real Decreto 311/2022. El artículo 41 reparte la responsabilidad: valorar el impacto corresponde al responsable o responsables de la información o los servicios afectados, y determinar la categoría final corresponde al responsable o responsables de la seguridad.

La categorización debe acordarse con el cliente cuando existan interdependencias. No se elige una categoría inferior por motivos de coste: el propio Real Decreto liga la categoría al mecanismo de conformidad exigible, así que rebajarla sin justificación técnica también rebaja indebidamente lo que hay que demostrar.

Para una primera estimación, usa el autodiagnóstico de categoría ENS.

La política define principios, organización, obligaciones, gestión de riesgos, incidentes, continuidad, personal y mejora continua. Se complementa con normativa y procedimientos operativos.

Debe reflejar el sistema real; una plantilla genérica no demuestra la implantación.

El análisis identifica activos, amenazas, vulnerabilidades, impacto, probabilidad y controles. Se actualiza ante cambios, incidentes y de forma periódica.

Debe incluir la cadena de suministro, la nube, los accesos remotos, el ransomware, la pérdida de claves y la continuidad del servicio. Un riesgo evaluado una sola vez, al arrancar el proyecto, no sirve de nada dos años después si el servicio ha cambiado de proveedor de nube, de personal o de arquitectura sin volver a pasar por el análisis.

Si ya tienes ISO 27001, mira cuánto se ahorra al implantar ENS e ISO 27001 juntos.

La Declaración de Aplicabilidad (DoA) recoge las medidas aplicables, su estado, la evidencia y la justificación. Si se utilizan medidas compensatorias, debe demostrarse una protección igual o superior conforme al marco y a las guías aplicables.

La DoA es un documento vivo y debe coincidir con lo verificado en la auditoría.

Las áreas clave son:

• Política y organización.
• Activos.
• Acceso.
• Explotación.
• Protección de las comunicaciones.
• Protección de la información.
• Servicios externos.
• Continuidad.
• Monitorización.
• Incidentes.

Se priorizan las medidas básicas de mayor impacto: inventario, MFA, gestión de parches, copias de seguridad, registros, segregación de funciones y capacidad de respuesta. Empezar por estas medidas antes que por las más sofisticadas suele reducir más riesgo por cada euro invertido, y es lo primero que revisa un auditor cuando el tiempo de la visita es limitado.

Los accesos administrativos usan cuentas nominativas, MFA, mínimo privilegio, un sistema bastión cuando proceda, registro y revisión periódica. Los accesos de soporte se habilitan de forma temporal.

No deben existir cuentas compartidas sin trazabilidad. Una cuenta de administración que no se ha revisado desde el alta del proyecto suele ser la primera evidencia que pide un auditor, precisamente porque es la más fácil de comprobar y la que con más frecuencia queda desactualizada.

Se revisan:

• Alcance de la certificación del proveedor.
• Responsabilidad compartida.
• Regiones.
• Subcontratistas.
• Cifrado y gestión de claves.
• Logs.
• Continuidad.
• Notificación.
• Salida (reversibilidad).

La certificación del proveedor cloud no certifica automáticamente la configuración del cliente: la responsabilidad compartida implica que la parte que corresponde al proveedor del servicio, es decir, al que contrata la nube para prestarlo a la administración, sigue dentro de su propio alcance de adecuación, aunque el proveedor de infraestructura tenga sus propias certificaciones en regla.

Si se desarrolla software, deben cubrirse:

• Requisitos de seguridad.
• Repositorios y ramas.
• Revisión de código.
• Gestión de dependencias.
• Gestión de secretos.
• Pruebas.
• Entornos separados.
• Aprobación y capacidad de rollback.

Cada cambio relevante debe actualizar el análisis de riesgos y la evidencia correspondiente.

El procedimiento define detección, clasificación, contención, comunicación, recuperación y lecciones aprendidas. Los plazos contractuales deben permitir al organismo público cumplir los suyos.

Se ensayan escenarios de ransomware, fuga de información, caída del servicio y compromiso de un proveedor.

Se establecen RTO/RPO, copias de seguridad, redundancia, personal y comunicación. La restauración se prueba de forma efectiva: una copia sin capacidad de recuperación no demuestra continuidad.

El artículo 38.1 del Real Decreto 311/2022 fija el mecanismo según la categoría: los sistemas de categoría BÁSICA «solo requerirán de una autoevaluación para su declaración de la conformidad», mientras que los de categoría MEDIA y ALTA «precisarán de una auditoría para la certificación de su conformidad». El mismo artículo aclara que la auditoría de seguridad prevista en el artículo 31 puede servir también para los fines de esa certificación, de modo que no siempre hace falta duplicar el trabajo.

Según la FAQ oficial del CCN, la Declaración de Conformidad se basa en autoevaluación y se verifica al menos cada dos años; la Certificación de Conformidad exige una auditoría formal por una entidad acreditada y tiene una validez de dos años. Ambas deben mostrarse mediante los distintivos oficiales de conformidad en la web de la organización. Durante la transición desde la norma anterior, el procedimiento de certificación previo pudo seguir usándose hasta el 5 de mayo de 2024, fecha en la que esos certificados vencieron; la certificación bajo el nuevo ENS pudo empezar a partir del 1 de diciembre de 2022.

Debe consultarse el portal ENS del CCN y el organismo certificador antes de anunciar cualquier estado. No se comunica «certificado» antes de obtenerlo ni fuera del alcance auditado.

La disposición transitoria única del Real Decreto 311/2022 concedió a los sistemas preexistentes, incluidos los de contratistas privados, veinticuatro meses para adecuarse. Ese plazo terminó el 5 de mayo de 2024: hoy cualquier sistema dentro del ámbito debe estar ya adecuado, y los nuevos deben aplicar el ENS «desde su concepción».

Para un proveedor que hereda un contrato o un sistema ya en marcha, esto significa que no hay margen que esperar: conviene fechar cuanto antes el análisis de brecha y regularizar la situación, porque el plazo no vuelve a contar desde que el proveedor decide ocuparse del sistema.

El propio portal ENS del CCN detalla el requisito de acreditación: para sistemas clasificados en grado de difusión limitada o equivalente, la entidad certificadora «debe estar acreditada por ENAC en el ámbito de aplicación del Esquema Nacional de Seguridad conforme a la norma UNE-EN ISO/IEC 17065:2012», y, cuando además se certifican requisitos STIC en sistemas de difusión limitada, sus auditores deben disponer de habilitación de seguridad de empresa (HSEM) en vigor.

El listado del CCN recoge 35 entidades: 20 acreditadas por ENAC, 6 en proceso de acreditación y el resto órganos de auditoría técnica públicos o entidades acreditadas solo para requisitos STIC. Antes de contratar una auditoría conviene comprobar en ese listado que la entidad elegida está acreditada para el alcance y la categoría concretos del sistema, no solo que dice certificar «ENS» de forma genérica.

El CCN pone a disposición de los organismos las «Herramientas de Gobernanza de la Ciberseguridad Nacional»: INES, AMPARO y PILAR con carácter general, e INES, AMPARO y MARGA para entidades locales. El catálogo de guías CCN-STIC, en particular la serie 800, dedicada específicamente a facilitar la implantación del ENS, ofrece plantillas y buenas prácticas para la documentación de conformidad. Deben utilizarse según el alcance del sistema y nunca como sustituto del juicio profesional ni de la auditoría correspondiente.

Días 1-30

Alcance, roles, categoría y análisis de brecha.

Días 31-60

Riesgos, DoA, políticas y medidas prioritarias.

Días 61-90

Implantación, pruebas, incidentes y continuidad.

Días 91-120

Auditoría interna, correcciones y conformidad.

• Alcance y arquitectura.
• Categorización.
• Riesgos.
• Política y DoA.
• Inventario.
• Accesos.
• Parches.
• Copias y restauración.
• Logs.
• Incidentes.
• Proveedores.
• Formación.
• Auditorías.

1. Empezar por comprar tecnología.
2. No delimitar el sistema.
3. Elegir la categoría por presupuesto.
4. Copiar una declaración de aplicabilidad ajena.
5. Confiar solo en el certificado del proveedor cloud.
6. Compartir cuentas de acceso.
7. No probar la restauración de las copias.
8. Ignorar a los subcontratistas.
9. Auditar antes de implantar.
10. Comunicar el certificado fuera de alcance.
11. Dar por válida una autoevaluación en un sistema de categoría MEDIA o ALTA.
12. No comprobar la acreditación ENAC concreta del organismo certificador.

• Alcance contractual definido.
• Roles formalizados.
• Categoría aprobada.
• Riesgos actualizados.
• Política y DoA aprobadas.
• Medidas y evidencias reunidas.
• Nube y cadena de suministro revisadas.
• Incidentes y continuidad probados.
• Auditoría interna realizada.
• Conformidad aplicable obtenida.