¿Deben mis proveedores estar certificados en el ENS?

Esta es una de las dudas más habituales cuando una organización comienza a implantar el Esquema Nacional de Seguridad (ENS). Existe la creencia de que todos sus proveedores deben estar igualmente certificados para mantener la conformidad. Sin embargo, el RD 311/2022 no establece esa obligación de forma general.

En mi experiencia profesional, además, observo que este es un aspecto que en ocasiones también se interpreta de forma excesivamente restrictiva durante algunas auditorías. No es raro encontrar auditorías en las que se solicita de forma sistemática la certificación ENS de determinados proveedores, sin justificar previamente por qué ese proveedor concreto debería estar sujeto a dicha exigencia o sin analizar si realmente se encuentra dentro de los supuestos previstos por la normativa. A mi juicio, la decisión de exigir una certificación no debería responder a un criterio genérico, sino apoyarse siempre en el ámbito de aplicación del ENS, en el análisis de riesgos y en las medidas específicas que resulten aplicables en cada caso.

La clave inicial está precisamente en el artículo 2 del RD 311/2022, que define el ámbito de aplicación del ENS. Antes de analizar si un proveedor debe estar certificado, lo primero que debemos determinar es qué tipo de organización pretende certificarse y en qué contexto presta o recibe los servicios objeto del análisis.

Organización	¿Debe exigir proveedores certificados ENS?
Administración Pública	Es decir cuando una empresa privada presta servicios o proporciona soluciones a una Administración Pública. Generalmente sí debe estar el proveedor certificado en ENS, cuando así lo establezcan los pliegos del contrato y resulte necesario para garantizar la conformidad del sistema. En ese caso, el propio artículo 2.3 del RD 311/2022 permite que los pliegos exijan la conformidad con el ENS y que dicha exigencia alcance, cuando sea necesario, a parte de la cadena de suministro.
Empresa privada	No existe una obligación general. La decisión dependerá del ámbito de aplicación del ENS, del contrato y del análisis de riesgos. Pero existen  casos particulares que sí lo exijen.

Cuando hablamos de una Administración Pública, el escenario es relativamente claro. El artículo 2 del RD 311/2022 establece que los contratos deberán incorporar los requisitos necesarios para garantizar la conformidad con el ENS. Esto permite exigir a los contratistas una Declaración o Certificación de Conformidad y, cuando el análisis de riesgos lo justifique, extender esa exigencia a determinados proveedores que formen parte de la cadena de suministro.

En cambio, si hablamos de una empresa privada que desarrolla su actividad exclusivamente en el sector privado, el planteamiento cambia por completo. El ENS no obliga a contratar únicamente proveedores certificados. La organización sigue siendo responsable de la seguridad de sus sistemas y debe demostrar que ha evaluado los riesgos asociados a sus terceros, que los controla mediante medidas contractuales y organizativas y que supervisa adecuadamente los servicios externalizados. La certificación del proveedor facilita esa labor, pero no sustituye la responsabilidad del titular del sistema.

Existe, sin embargo, un supuesto en el que la certificación deja de ser una buena práctica para convertirse en un requisito normativo: cuando el tercero suministra un producto o presta un servicio que forma parte de la arquitectura de seguridad del sistema.

¿Qué productos o servicios deben estar certificados?

La medida op.pl.5 Productos certificados no obliga a certificar cualquier software o servicio utilizado por la organización. Su alcance se limita a aquellos productos o servicios de seguridad que forman parte de la arquitectura de seguridad del sistema o que el propio ENS referencia expresamente. En estos casos, deberán seleccionarse preferentemente del Catálogo de Productos y Servicios de Seguridad TIC (CPSTIC) del CCN o, cuando no exista una alternativa disponible, utilizar productos certificados conforme al artículo 19 del RD 311/2022.

Entre los componentes que habitualmente entran dentro de este ámbito se encuentran:

• Firewalls y pasarelas de seguridad perimetral.
• Sistemas VPN y dispositivos para el establecimiento de comunicaciones seguras.
• Productos criptográficos, bibliotecas criptográficas y módulos HSM destinados a la gestión y protección de claves.
• Sistemas de autenticación fuerte, autenticación multifactor (MFA), gestores de identidad (IAM) y soluciones de control de acceso cuando constituyan un componente de seguridad del sistema.
• Autoridades de certificación, servicios de firma electrónica, sellado de tiempo y validación de certificados, cuando formen parte de la infraestructura de confianza.
• Herramientas de borrado seguro y destrucción lógica de soportes, para las que el propio ENS remite expresamente.
• Sistemas de detección y prevención de intrusiones (IDS/IPS) y otras soluciones específicamente destinadas a la protección de la infraestructura.
• Pasarelas seguras de correo electrónico, filtrado web o protección del tráfico cuando constituyan un elemento de la arquitectura de seguridad.
• Servicios de seguridad gestionados, como un SOC, servicios de monitorización de seguridad, gestión de eventos (SIEM), respuesta ante incidentes o gestión de vulnerabilidades, cuando el sistema suministre dichos servicios bajo el alcance del ENS, supuesto contemplado expresamente en op.pl.5.2.
• Servicios de seguridad en la nube (Cloud Security Services), tales comoWAF (Web Application Firewall), CASB, Secure Web Gateway (SWG), Cloud Access Security Broker, SASE, Security Service Edge (SSE), servicios gestionados de protección DDoS, gestión de claves (KMS), gestión de certificados, HSM as a Service, SIEM/SOC en la nube, plataformas EDR/XDR SaaS, gestión de vulnerabilidades o cualquier otro servicio cloud cuya finalidad principal sea proporcionar funciones de seguridad. En estos casos, el propio ENS establece expresamente que el servicio deberá estar certificado o soportado por productos certificados cuando resulte de aplicación

Conviene recordar que la exigencia recae sobre el producto o servicio de seguridad, no necesariamente sobre la empresa fabricante o integradora. No obstante, cuando una organización contrata un servicio de seguridad (por ejemplo, un SOC, un servicio de monitorización o una plataforma de protección gestionada), disponer de una Declaración o Certificación de Conformidad con el ENS del prestador constituye la forma más sencilla de demostrar el cumplimiento durante una auditoría, aunque la organización siempre podrá justificar el uso de medidas compensatorias cuando la normativa lo permita.

¿Los servicios cloud deben estar certificados?

La certificación del servicio o del producto, únicamente resulta aplicable cuando el servicio cloud proporciona funciones de seguridad. Sin embargo, esto no significa que el resto de servicios cloud queden fuera del ENS.

Cuando una organización utilice servicios cloud suministrados por terceros, estos deberán ser conformes con el ENS o cumplir los requisitos establecidos en las correspondientes guías CCN-STIC. Entre otros aspectos, el proveedor deberá demostrar que dispone de controles adecuados sobre:

• Pruebas periódicas de penetración (pentesting) y evaluación de la seguridad de la plataforma.
• Transparencia, proporcionando información suficiente sobre la arquitectura del servicio, sus controles de seguridad y los resultados de auditorías o certificaciones relevantes.
• Cifrado y gestión de claves, garantizando la protección de la información tanto en tránsito como en reposo y definiendo claramente el modelo de gestión y custodia de las claves criptográficas.
• Jurisdicción y ubicación de los datos, identificando dónde se almacenan y procesan, qué legislación les resulta aplicable y cómo se gestionan las posibles transferencias internacionales.

Por tanto, aunque un servicio SaaS, PaaS o IaaS no sea un servicio de seguridad, el proveedor deberá poder demostrar durante una auditoría del ENS que cumple estos requisitos y cualquier otro establecido en las guías CCN-STIC aplicables a su modelo de servicio.

Este aspecto tiene una consecuencia muy interesante para las organizaciones que desarrollan y comercializan soluciones cloud. La medida Protección de servicios (op.nub.1) debe interpretarse en dos direcciones.

• Por un lado y el más importante, como proveedor cloud, la organización deberá acreditar durante la auditoría que su plataforma cumple estos mismos requisitos y, además, proporcionar a sus propios clientes la información y evidencias necesarias para que puedan incorporar el servicio dentro de sus análisis de riesgos y demostrar, a su vez, el cumplimiento del ENS.
• Por un lado, como cliente, la organización debe evaluar que los servicios cloud de terceros (sus proveedores) que utiliza cumplen los requisitos del ENS y solicitar las evidencias necesarias para demostrarlo.

En otras palabras, una empresa SaaS certificada en el ENS no solo debe ser capaz de cumplir estos requisitos, sino también de demostrar de forma transparente ese cumplimiento a sus clientes mediante documentación técnica, informes de auditoría, certificaciones, resultados de pruebas de seguridad, información sobre la gestión del cifrado, la ubicación de los datos y cualquier otra evidencia que permita integrar el servicio dentro del modelo de seguridad del cliente.

¿Qué ocurre si el producto o servicio de seguridad no está certificado?

La respuesta corta es: no significa automáticamente que no pueda utilizarse.

Lo primero que debe determinar la organización es si ese producto o servicio está realmente sujeto a la medida op.pl.5. Es decir, si forma parte de la arquitectura de seguridad del sistema o si el ENS exige expresamente que esté certificado.

Si la respuesta es afirmativa y el fabricante o proveedor no dispone de una certificación reconocida o de un producto incluido en el CPSTIC, la organización no debería limitarse a aceptar esa situación sin más. Lo recomendable es disponer de un procedimiento interno para la adquisición y evaluación de productos y servicios de seguridad, que permita justificar técnicamente la decisión adoptada.

Este procedimiento podría contemplar, entre otros, los siguientes aspectos:

• Identificar si el producto o servicio está afectado por la medida op.pl.5.
• Verificar si existe una alternativa equivalente incluida en el CPSTIC o con certificación reconocida.
• Solicitar al fabricante o proveedor toda la documentación técnica disponible: arquitectura, funcionalidades de seguridad, resultados de auditorías independientes, certificaciones (ISO 27001, Common Criteria, FIPS 140-3, SOC 2, etc.), informes de penetración, procesos de desarrollo seguro, gestión de vulnerabilidades y soporte.
• Realizar una evaluación técnica de seguridad del producto o servicio para comprobar que satisface los requisitos funcionales y el nivel de protección requerido.
• Analizar el riesgo residual que supone utilizar un producto no certificado frente al impacto que tendría sustituirlo.
• Definir, cuando sea necesario, medidas compensatorias que reduzcan ese riesgo hasta un nivel aceptable.
• Documentar toda la decisión dentro del análisis de riesgos y de la Declaración de Aplicabilidad (SoA).

En otras palabras, la organización debe poder demostrar que ha tomado una decisión consciente, basada en riesgos y suficientemente justificada, y no simplemente que ha aceptado un producto porque «es el que había».

El papel de las medidas compensatorias

El propio ENS contempla la posibilidad de implantar medidas compensatorias cuando una medida no pueda aplicarse exactamente en los términos previstos. La Guía CCN-STIC 819 establece que estas medidas deben proporcionar un nivel de protección equivalente o superior al de la medida original y quedar debidamente documentadas, justificadas y posteriormente verificadas durante la auditoría.