¿Qué exige realmente el ENS en materia de pentesting?

El Esquema Nacional de Seguridad aparece en cada vez más pliegos y, con él, una línea que casi nadie sabe de dónde sale: «se realizarán pruebas de penetración». Cuando preguntas por el código de medida, la conversación se para.

Así que hicimos lo único que sirve aquí: abrir el Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad (BOE-A-2022-7191), ir al Anexo II y buscar el término. Aparece dos veces. Las dos tienen código. Y ninguna de las dos es la medida que repite media internet española.

Este artículo dice cuáles son, a qué categoría se aplican, con qué frecuencia —el decreto no fija ninguna, y eso también hay que decirlo— y a qué empresas privadas alcanza el ENS de verdad. Todo citado por código de medida, para que puedas comprobarlo en el texto consolidado sin fiarte de nosotros.

Conviene que sepas cuál es nuestro interés antes de seguir: nosotros ejecutamos ese tipo de pruebas. Por eso hemos preferido citar el decreto a resumirlo, y decir con la misma claridad dónde el ENS no pide un pentest que dónde sí lo pide. Una página que solo encuentra obligaciones allí donde vende no es una lectura del decreto, es un folleto.

Dónde nombra el ENS las pruebas de penetración

Dos sitios, los dos en el Anexo II, que es donde viven las medidas de seguridad y su cláusula de aplicación por categoría.

1. op.mon.3, refuerzo R6: «Inspecciones de seguridad»

La medida op.mon.3 «Vigilancia» pertenece al marco operacional, al bloque de monitorización del sistema. Su refuerzo R6 dice, literalmente:

«Periódicamente, o tras incidentes que hayan desvelado vulnerabilidades del sistema nuevas o subestimadas, se realizarán las siguientes inspecciones: [op.mon.3.r6.1] Verificación de configuración. [op.mon.3.r6.2] Análisis de vulnerabilidades. [op.mon.3.r6.3] Pruebas de penetración.»

De esas cuatro líneas salen tres conclusiones que el mercado se salta con frecuencia.

R6 es un refuerzo, no la medida. La cláusula de aplicación de op.mon.3 suma refuerzos según la categoría del sistema: en BÁSICA aplica la medida base; en MEDIA, la medida más R1 y R2; en ALTA, la medida más R1 a R6. Como el punto r6.3 vive dentro de R6, solo se activa en categoría ALTA. Un sistema de categoría MEDIA no queda obligado a pruebas de penetración por esta vía, por mucho que un resumen diga lo contrario.

El orden de los tres puntos es una secuencia, no un menú. Verificación de configuración, después análisis de vulnerabilidades, después pruebas de penetración. Es exactamente el orden en el que un equipo técnico serio construye una campaña: primero se comprueba cómo está configurado el sistema, luego se identifica lo que está expuesto y, por último, se intenta explotarlo y encadenarlo. Si alguien te ofrece lo tercero sin haber hecho lo primero, te está vendiendo la parte vistosa del trabajo. Esa diferencia la desarrollamos en análisis de vulnerabilidades o pentest.

No hay frecuencia. «Periódicamente» no es un número, y el decreto no lo convierte en uno en ninguna parte. Lo que sí añade es un disparador concreto: los incidentes que hayan desvelado vulnerabilidades nuevas o subestimadas. Volvemos sobre esto más abajo, porque la pregunta «¿cada cuánto?» tiene respuesta práctica aunque no tenga respuesta literal.

2. op.nub.1.2 a): la puerta que casi nadie cita

La segunda aparición está en el bloque de servicios en la nube, y es la más interesante desde el punto de vista comercial porque no espera a la categoría ALTA.

Cuando una entidad usa un servicio en la nube prestado por un tercero que no acredita conformidad con el ENS, op.nub.1.2 exige que ese servicio cumpla los requisitos de la guía CCN-STIC aplicable en cuatro materias, y la primera de la lista es, literalmente: «a) Auditoría de pruebas de penetración (pentesting)». Las otras tres son transparencia, cifrado y gestión de claves, y jurisdicción de los datos.

Dos consecuencias que conviene tener claras.

La primera: esta exigencia se aplica desde categoría BÁSICA. Es decir, un sistema que no llega ni de lejos a ALTA puede acabar necesitando que su proveedor de nube aporte una prueba de penetración del servicio. La obligación recae sobre el servicio del tercero, no sobre la infraestructura propia de la entidad.

La segunda: si vendes software como servicio al sector público español, esta es la línea que te va a llegar en el cuestionario del cliente, y llegará antes de que nadie te hable de categorías. La respuesta útil es un informe con alcance definido, hallazgos reproducibles y verificación de las correcciones; para eso está nuestro test de intrusión de entornos cloud.

La cuarta materia, jurisdicción de los datos, merece una nota aparte: es la única de las cuatro que no se arregla con trabajo técnico, y es la que decide dónde puede alojarse el servicio. Para un proveedor establecido en la Unión Europea es una respuesta corta; para uno con matriz fuera del espacio europeo, no lo es.

La medida mp.s.3 y lo que el decreto dice de ella

Hay una afirmación que circula copiada en varias páginas españolas sobre ENS y pentesting, y que conviene reproducir tal cual, porque corregirla exige citarla:

«Medida mp.s.3 (“Pruebas de penetración”): medida de seguridad explícita en el marco del ENS — obligatoria para sistemas de categoría alta, recomendada para categoría media.»

No señalamos a nadie: lo que importa aquí es el texto del decreto, no quién lo parafraseó primero. Pero la frase contiene tres afirmaciones y el Real Decreto 311/2022 contradice las tres.

1. mp.s.3 existe, y es otra cosa.

En el Anexo II, mp.s.3 es «Protección de la navegación web». Aplica en categoría BÁSICA y en categoría MEDIA, y en ALTA suma un refuerzo. Trata de política de navegación, de concienciación y de protección de los protocolos que sostienen la navegación, DNS y TLS incluidos. No trata de pruebas técnicas ofensivas en absoluto. El prefijo ya lo anticipa: mp. es el bloque de medidas de protección, y mp.s. el de protección de los servicios; la monitorización y las inspecciones viven en op.mon., en el marco operacional.

2. No existe ninguna medida del ENS titulada «Pruebas de penetración».

La expresión aparece dos veces en todo el decreto y en ninguna de las dos es el título de una medida: es el punto 3 de un refuerzo (op.mon.3.r6.3) y es la primera letra de un requisito sobre servicios de terceros (op.nub.1.2 a). La diferencia no es formal. La tabla de aplicación del Anexo II se construye sobre medidas y refuerzos, y un punto hereda la aplicación del refuerzo que lo contiene. Quien busca «mp.s.3» en un pliego y compra a partir de ahí está presupuestando sobre un código que no existe con ese contenido.

3. El ENS no tiene medidas «recomendadas».

Esta es la parte que no es un error de código, sino de arquitectura. La tabla de aplicación del Anexo II dice, para cada medida y cada categoría, si aplica o no aplica, y qué refuerzos se suman. No hay un estado intermedio. No existe una columna de medidas sugeridas, ni un anexo de buenas prácticas opcionales dentro del cuadro de aplicación. Por eso «recomendada para categoría media» no es una lectura discutible del decreto: es una frase que el decreto no puede emitir.

El coste práctico de esto se ve en los dos sentidos. Presupuestar un pentest en un sistema de categoría MEDIA «porque lo exige mp.s.3» es comprar algo que el ENS no pide por esa vía. Y al revés: dar por hecho que un sistema MEDIA queda libre de pruebas técnicas también es equivocarse, porque puede entrarle la exigencia por op.nub.1.2 a) si hay nube de terceros de por medio, por las medidas de protección de las aplicaciones web, o simplemente porque el análisis de riesgos de la entidad lo concluya.

La regla de higiene que sale de aquí sirve para cualquier página de cumplimiento: cuando alguien cite una medida del ENS, busca el código en el Anexo II. Si el código no dice lo que la página dice que dice, el resto de esa página tampoco es fiable.

De dónde sale «ALTA»: dimensiones y categorías

Para saber si te aplica R6 hace falta saber la categoría del sistema, y la categoría no se elige: se deduce.

Los artículos 40 y 41 y el Anexo I construyen la categoría a partir de la valoración del impacto en cinco dimensiones de seguridad, cada una en nivel BAJO, MEDIO o ALTO.

Según el Anexo I, el sistema es de categoría ALTA cuando alguna de las cinco dimensiones alcanza nivel ALTO; de categoría MEDIA cuando alguna alcanza MEDIO y ninguna llega a ALTO; y de categoría BÁSICA cuando alguna alcanza BAJO y ninguna supera ese nivel. Basta una dimensión para arrastrar al conjunto, lo que explica por qué sistemas aparentemente modestos acaban en ALTA por disponibilidad o por trazabilidad, no por confidencialidad.

Dos consecuencias operativas:

• La categoría es del sistema, no de la organización. Una misma entidad puede tener un sistema BÁSICA, otro MEDIA y otro ALTA, y R6 solo cuelga del tercero. La pregunta correcta en un proyecto nunca es «¿qué categoría tenéis?», sino «¿qué categoría tiene este sistema y quién la ha determinado?».
• La categoría se revisa. El decreto obliga a reevaluarla anualmente o ante cambios significativos. Un sistema que sube a ALTA hereda R6 desde ese momento, y con él las tres inspecciones del refuerzo.

El artículo 31: la auditoría, cada dos años, y qué reinicia el reloj

Aquí está el plazo que el mercado sí conoce, aunque a menudo lo confunda con el pentest.

El art. 31.1 somete los sistemas incluidos en el ámbito de aplicación a «una auditoría regular ordinaria, al menos cada dos años» que verifique el cumplimiento del ENS. Junto a ella, una auditoría extraordinaria es obligatoria cuando se produce una modificación sustancial que afecte a las medidas de seguridad exigidas, y esa auditoría extraordinaria reinicia el cómputo de los dos años. El plazo solo puede ampliarse tres meses por causa de fuerza mayor no atribuible a la entidad.

El resto del artículo 31 añade cuatro cosas que conviene tener presentes:

• Art. 31.2: la auditoría se realiza en función de la categoría del sistema y del perfil de cumplimiento aplicable (Anexos I y III) y conforme a la Instrucción Técnica de Seguridad de Auditoría.
• Art. 31.3: la auditoría se apoya en «criterios, métodos de trabajo y de conducta generalmente reconocidos», además de normativa nacional e internacional aplicable. El artículo no exige acreditación a quien la realiza, que es una diferencia sustancial respecto de la certificación del art. 38 y la desarrollamos en quién puede auditar el ENS.
• Art. 31.6: en sistemas de categoría ALTA, ante deficiencias graves el responsable del sistema puede acordar la suspensión del tratamiento de la información o la del servicio.
• Art. 31.7: los informes de auditoría pueden ser requeridos por los responsables de seguridad de la entidad y por el CCN.

La confusión que más caro sale es esta: la auditoría del art. 31 y la prueba de penetración de op.mon.3.r6.3 no son la misma cosa y no las hace necesariamente el mismo actor. La auditoría verifica cumplimiento del esquema, revisa documentación, organización y evidencias. La prueba de penetración es una de las comprobaciones técnicas que alimentan esa verificación con evidencia real. Un informe de pentest no es un informe de auditoría del ENS, y ningún proveedor técnico puede convertirlo en uno. Si lo que necesitas es la revisión de cumplimiento, eso es una auditoría de ciberseguridad; si lo que necesitas es la evidencia técnica que se le pone delante, eso es un test de intrusión.

El artículo 38: certificación o autoevaluación

El art. 38.1 separa las dos vías de conformidad sin ambigüedad. Los sistemas de categoría MEDIA o ALTA «precisarán de una auditoría para la certificación de su conformidad». Los de categoría BÁSICA «solo requerirán de una autoevaluación para su declaración de la conformidad», sin perjuicio de que puedan someterse voluntariamente a una auditoría de certificación. El art. 38.2 obliga a publicar la declaración o la certificación en el sitio web o en la sede electrónica de la entidad.

Quién firma cada cosa no es elección de las partes. La Instrucción Técnica de Seguridad de Conformidad con el ENS (Resolución de 13 de octubre de 2016, BOE-A-2016-10109), en su apartado VI.1, exige que la entidad certificadora esté acreditada por la Entidad Nacional de Acreditación (ENAC) conforme a la norma UNE-EN ISO/IEC 17065:2012. El apartado VI.4 contempla una excepción para entidades del sector público cuya norma de creación les atribuya competencia de auditoría de sistemas de información y en las que quede garantizada la debida imparcialidad.

Dicho en corto, y porque es la pregunta que nos llega por correo cada pocas semanas: ningún proveedor de servicios técnicos de seguridad ofensiva puede certificarte el ENS, tenga la nacionalidad que tenga. Esa firma pertenece a un tipo de entidad distinto, con un régimen de acreditación propio. Lo que sí puede hacer un proveedor técnico es producir la evidencia que la auditoría necesita.

¿A qué empresas privadas alcanza el ENS?

Aquí es donde la versión abreviada que circula —«todo proveedor de la Administración necesita ENS»— se aleja más del texto. El art. 2.3 dice que el real decreto se aplica también 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.»

Léelo despacio, porque son tres condiciones acumulativas y la tercera es la que desaparece en casi todos los resúmenes:

1. Que exista una relación contractual.

No basta con orbitar alrededor del sector público. Hace falta contrato.

2. Que se presten servicios o se provean soluciones a entidades del sector público.

El perímetro del sector público es el del art. 2 de la Ley 40/2015, no una intuición.

3. Que sea «para el ejercicio por estas de sus competencias y potestades administrativas».

Esta es la bisagra. No toda venta a una Administración sirve al ejercicio de una potestad administrativa. Un sistema con el que un ayuntamiento tramita expedientes y dicta resoluciones está dentro de esa frase. El mantenimiento de la climatización de sus oficinas no lo está, por mucho que el contrato sea público y el cliente sea el mismo.

El mecanismo es el pliego. El propio art. 2.3 exige que los pliegos de la contratación incorporen los requisitos de conformidad con el ENS, mediante Declaración o Certificación de Conformidad según el caso. Por eso la pregunta operativa para una empresa privada nunca es «¿me aplica el ENS?», en abstracto, sino «¿qué me está pidiendo este pliego, y con qué categoría?».

La cadena de suministro no se activa sola. La exigencia se extiende a la cadena del contratista solo «en la medida que sea necesario y de acuerdo con los resultados del correspondiente análisis de riesgos». No es automática, no es universal, y el análisis de riesgos que la justifica es un documento que puedes pedir.

Un apunte de calendario que ahorra discusiones: el ENS vigente está en vigor desde el 5 de mayo de 2022 y el periodo de adecuación de su disposición transitoria única hace tiempo que venció. Quien siga trabajando con el esquema anterior no está en un periodo de gracia.

Si tu duda es cómo se sostiene todo esto cuando el proveedor técnico no está establecido en España, lo tratamos aparte en contratar una empresa de pentesting no española.

Dos medidas más que empujan hacia la prueba técnica sin llamarla así

Quedarse solo en op.mon.3.r6.3 deja fuera una parte del trabajo que el ENS sí reclama, aunque use otro vocabulario.

La medida mp.s.2 incorpora refuerzos que piden auditoría de seguridad de las aplicaciones web: R1 en modalidad de caja negra, durante el desarrollo y antes de pasar a producción, con la frecuencia que fije el procedimiento de auditoría de la entidad; y R2 en modalidad de caja blanca durante el desarrollo, con metodologías definidas y herramientas automatizadas de detección de vulnerabilidades. Los hallazgos se corrigen por la vía que el propio decreto señala, en op.exp.5.

Dicho de otro modo: el decreto no llama «pruebas de penetración» a esa actividad, pero está describiendo trabajo de pentesting de aplicaciones web en el ciclo de desarrollo. Y el criterio de caja negra frente a caja blanca coincide con lo que cualquier equipo técnico decidiría por su cuenta: la primera mide lo que ve un atacante sin información; la segunda encuentra más, más rápido y más barato. Nuestras metodologías de testing están publicadas precisamente para que puedas contrastar qué se hace en cada modalidad.

Entonces, ¿cada cuánto hay que hacer un pentest bajo el ENS?

La respuesta honesta en dos partes.

Lo que dice el decreto: para op.mon.3.r6.3, nada. «Periódicamente», más el disparador de los incidentes que desvelen vulnerabilidades nuevas o subestimadas. No hay meses, no hay años, no hay número.

Lo que da ritmo en la práctica: el resto del esquema. El ciclo bienal del art. 31 marca el compás de la auditoría; las modificaciones sustanciales abren auditorías extraordinarias y reinician el plazo; la categoría se revisa anualmente; y el análisis de riesgos de la entidad puede pedir más.

Nuestro criterio profesional, dicho como lo que es —criterio, no obligación legal—: en un sistema de categoría ALTA, una campaña anual más una repetición tras cada cambio sustancial es la cadencia que un auditor entiende sin discusión, porque encaja con el ciclo del art. 31 en lugar de correr por detrás de él. Si el presupuesto no da para eso, es mejor una campaña bien delimitada al año que tres superficiales. Lo que cuesta cada opción lo desglosamos en cuánto cuesta un pentest en España.

Cómo leer un pliego que menciona el ENS

Siete preguntas. Con las respuestas en la mano, el alcance se escribe solo y el presupuesto deja de ser una adivinanza.

1. ¿Qué categoría tiene el sistema y quién la ha determinado?

Sin categoría no hay conversación posible sobre R6. Y la categoría la fija el responsable del sistema, no el proveedor.

2. ¿Qué dimensiones están en nivel ALTO?

Saber si lo que arrastra al sistema es disponibilidad o confidencialidad cambia por completo qué merece la pena atacar primero.

3. ¿Pide Declaración o Certificación de Conformidad?

Declaración apunta a BÁSICA y autoevaluación; Certificación apunta a MEDIA o ALTA y a una entidad certificadora acreditada. Son dos proyectos distintos y dos calendarios distintos.

4. ¿Cita un código de medida, o solo la palabra «pentesting»?

Si no hay código, pídelo por escrito. Es legítimo y es rápido: la respuesta debería ser op.mon.3 R6, op.nub.1.2 a), o una exigencia contractual propia del órgano de contratación que no nace del ENS. Las tres son válidas, pero se presupuestan de forma diferente.

5. ¿Hay servicios en la nube de terceros dentro del alcance?

Si los hay y no acreditan conformidad con el ENS, entra op.nub.1.2 y la exigencia llega desde categoría BÁSICA. Es el supuesto que más veces se descubre tarde.

6. ¿Hasta dónde baja la exigencia en la cadena de suministro?

Y sobre todo: ¿con qué análisis de riesgos se justifica? Es un documento que puedes pedir, y su ausencia es una respuesta en sí misma.

7. ¿El pliego exige verificación posterior de las correcciones?

Si no la exige, pídela igualmente en el contrato. Un informe sin retest documenta un problema, no una corrección, y la corrección es lo que la auditoría va a querer ver.

Qué hacemos y qué no

Lo decimos sin rodeos, porque en una página sobre cumplimiento la ambigüedad cuesta más que cualquier limitación declarada.

• Ejecutamos la prueba técnica. La que el decreto nombra en [op.mon.3.r6.3] y la que op.nub.1.2 a) exige del servicio en la nube, junto con la verificación de configuración y el análisis de vulnerabilidades que el mismo refuerzo coloca delante de ella. Entregamos informe con alcance, hallazgos priorizados, prueba de concepto reproducible por hallazgo y verificación posterior de las correcciones.
• No certificamos. Haxoris no es entidad de certificación acreditada por ENAC y no expide certificaciones ni declaraciones de conformidad con el ENS. Esa firma corresponde a una entidad certificadora acreditada conforme a UNE-EN ISO/IEC 17065:2012, según el apartado VI.1 de la ITS de Conformidad (BOE-A-2016-10109).
• Y decimos por qué, sin adornarlo. El esquema de conformidad del ENS es específico de España, y la propia Instrucción Técnica nombra a ENAC como entidad de acreditación del esquema. No es una barrera que podamos rodear con argumentos comerciales, así que no lo intentamos: trabajamos junto a la entidad certificadora que elija cada cliente, no en su lugar.
• Somos un proveedor europeo. Haxoris está establecida en la Unión Europea, con oficinas en Bratislava y Praga. Los datos y los informes se quedan en territorio de la Unión, el RGPD se aplica directamente y no hay transferencia internacional del capítulo V del RGPD ni cláusulas contractuales tipo que negociar. Para la cuarta materia de op.nub.1.2 —jurisdicción de los datos— eso es una respuesta corta y verificable.
• Trabajamos siempre con autorización escrita y alcance definido por contrato. En España, la frontera entre una prueba de seguridad y un delito informático es exactamente esa: los artículos 197 bis, 197 ter, 264 y 264 bis del Código Penal castigan las conductas realizadas «sin estar debidamente autorizado» o «sin autorización».

Preguntas frecuentes

¿Tienes delante un pliego con ENS y no queda claro qué medida está detrás de la línea del pentest? Escríbenos con el código de medida, la categoría del sistema y el alcance previsto: te respondemos por escrito, y también cuando la respuesta sea que el decreto no pide lo que el pliego parece pedir. Solicita tu presupuesto o empieza por nuestra página de pentesting y test de intrusión.

Nuestros servicios relacionados: pentesting y tests de intrusión de tus aplicaciones e infraestructuras · auditoría de ciberseguridad de tu entorno tecnológico · análisis de vulnerabilidades de tus sistemas y aplicaciones · auditoría de entornos cloud en AWS, Azure y GCP