El ENS en un software de avisos
Por qué el ENS alcanza a un software que desarrolla un proveedor
El Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad, no se aplica solo a los sistemas que la administración opera con sus propios medios. Su artículo 2.3 lo extiende a los sistemas de información de las entidades del sector privado cuando, en virtud de un contrato, «presten servicios o provean soluciones a las entidades del sector público». Y añade dos cosas que importan a quien redacta un pliego: que los pliegos deben recoger los requisitos necesarios para asegurar la conformidad con el ENS, como las declaraciones o certificaciones de conformidad, y que esa exigencia puede extenderse a la cadena de suministro del contratista según el análisis de riesgos.
Un software de avisos críticos que una administración contrata para activar a su retén o avisar a su población es, por tanto, un sistema de información del sector público a efectos del ENS, lo opere quien lo opere. Y como la disposición transitoria única dice que «los nuevos sistemas de información aplicarán lo establecido en este real decreto desde su concepción», no vale adecuarlo después: tiene que haber nacido así.
Lo que el ENS mira es el sistema completo: lo que el cliente ya tiene (Directorio Activo, centralita, contrato de SMS, dominio de correo, sensores y CAP hacia el 112), las tres piezas y los canales por los que sale el aviso:
Qué categoría le corresponde
El ENS no tiene una regla específica para «software de notificación». La categoría (básica, media o alta) la fija el responsable del sistema, es decir, el organismo, en función del impacto que tendría un incidente sobre cinco dimensiones: disponibilidad, autenticidad, integridad, confidencialidad y trazabilidad (artículo 40 y Anexo I). El proveedor no la elige; el pliego la declara.
Un sistema que activa retenes de emergencia y avisa a población en riesgo vital puntúa alto en disponibilidad (si cae, nadie se entera), en autenticidad (un aviso falso es un incidente grave), en integridad (el texto no puede cambiar por el camino) y en trazabilidad (hay que demostrar después qué se avisó). Difícilmente baja de media. Y la categoría tiene una consecuencia administrativa inmediata, fijada en el artículo 38.1: los sistemas de categoría media o alta requieren una auditoría de certificación de su conformidad; los de categoría básica se conforman con una autoevaluación.
De ahí que el dato relevante de un proveedor no sea la frase genérica «cumple el ENS», que no significa nada por sí sola, sino dos cosas verificables: si la empresa tiene certificación ENS vigente y de qué categoría, y si el sistema concreto está diseñado para acreditar conformidad en la categoría que el pliego declara.
La medida mp.sw.1, punto por punto
El Anexo II del RD 311/2022 agrupa las medidas de seguridad en marcos. Dentro del marco de protección, el apartado mp.sw trata la protección de las aplicaciones informáticas y tiene dos medidas. La primera, mp.sw.1 Desarrollo de aplicaciones, no se aplica en categoría básica; en media y alta exige el requisito base más cuatro refuerzos. Es la medida que separa un software hecho para el sector público de uno adaptado después.
| Requisito de mp.sw.1 | Lo que dice el ENS | Qué pedir al proveedor |
|---|---|---|
| Base: entornos separados | «El desarrollo de aplicaciones se realizará sobre un sistema diferente y separado del de producción», sin herramientas ni datos de desarrollo en producción ni datos de producción en desarrollo | Cuántos entornos tiene, cómo se promueve el código entre ellos y quién puede acceder a cada uno |
| R1: mínimo privilegio | «Las aplicaciones se desarrollarán respetando el principio de mínimo privilegio»: acceden solo a los recursos imprescindibles | Permisos por servicio: qué puede hacer el componente que envía SMS, el que consulta el directorio, el que escribe el libro |
| R2: metodología de desarrollo seguro | Una metodología reconocida que considere la seguridad en todo el ciclo de vida, con normas de programación segura, tratamiento específico de los datos de prueba e inspección del código fuente | Qué metodología (por ejemplo OWASP ASVS para la aplicación web y MASVS para la móvil), revisión por pares, análisis estático en la integración continua |
| R3: seguridad desde el diseño | Identificación y autenticación, protección de la información tratada y generación de pistas de auditoría como parte integral del diseño | Doble factor, control de acceso por roles y registro de auditoría inmutable diseñados desde el principio, no añadidos |
| R4: datos de pruebas | Las pruebas «no se realizarán con datos reales»; si fuera imprescindible, con el mismo nivel de seguridad | Simuladores y datos sintéticos; nunca el censo real de vecinos ni el directorio real de personal en un entorno de pruebas |
| R5: lista de componentes | Relación formal y actualizada de los componentes de terceros, con histórico por versión, cuyo contenido mínimo fija una guía CCN-STIC | Inventario de dependencias (el llamado SBOM) con monitorización de vulnerabilidades |
Una nota de lectura: el refuerzo R5 está definido en la medida, pero no figura en la tabla de aplicación por categorías del Anexo II. Pedirlo en el pliego es una decisión del organismo, y una decisión razonable para un sistema que envía mensajes a la población.
mp.sw.2: aceptación y puesta en servicio
La segunda medida, mp.sw.2 Aceptación y puesta en servicio, sí aplica en todas las categorías. El requisito base exige comprobar, antes de pasar a producción, que la aplicación funciona correctamente, que se cumplen los criterios de aceptación en materia de seguridad y que no se deteriora la seguridad de otros componentes del servicio. En categoría media y alta se añade el refuerzo R1: las pruebas se realizan «en un entorno aislado (preproducción)». El refuerzo R2, auditoría de código fuente, queda disponible para quien quiera exigirlo.
Traducido a un proyecto de implantación: tiene que existir un entorno de preproducción equivalente al de producción, una lista de criterios de aceptación pactada por escrito y una prueba formal antes de la puesta en servicio. En la práctica de Alertadia esa prueba se llama simulacro de aceptación y sus criterios son numéricos: tiempo hasta el primer acuse, porcentaje de confirmaciones, comportamiento de la cadena cuando nadie responde.
op.exp.8: el registro de actividad que sostiene el libro de transmisiones
Hay una tercera medida que no está en mp.sw pero que un software de avisos no puede ignorar: op.exp.8 Registro de la actividad, en la dimensión de trazabilidad. El requisito base es que «se generará un registro de auditoría» que incluya, al menos, el identificador del usuario, la fecha y hora, la información afectada, el tipo de evento y su resultado. En nivel medio se añaden la revisión periódica, la sincronización del reloj con una referencia de tiempo protegida, la retención documentada de los registros y el control de acceso a ellos.
Para una sala de emergencias esto no es burocracia. Es exactamente lo que hace falta para que el libro de registro de transmisiones sirva como prueba: sello de tiempo fiable, constancia de quién emitió cada aviso y de quién cambió una prioridad, y garantía de que nadie puede borrar una línea. La página de avisos a la población describe cómo se construye ese libro sobre el registro de auditoría.
Así se lee una entrada de ese libro: hora de detección y de emisión, emisor, receptor, canal, prioridad, acuse, sello de la pasarela y hash del mensaje:
Libro de registro de transmisiones
| Suceso | Detección → emisión | Emisor → receptor | Canal · prioridad | Acuse · sello |
|---|---|---|---|---|
| S-0042a94f…c21e | 04:12:08→ 04:12:11 | sala→ técnico de guardia 3 | pushcrítica | 04:13:02 sello 04:12:12 |
| S-0042a94f…c21e | 04:12:08→ 04:12:11 | sala→ técnico de guardia 7 | pushcrítica | sin acuse sello 04:12:12 |
| S-00423b7c…9e10 | 04:12:08→ 04:22:00 | motor→ técnico de guardia 7 | SMScrítica | sin acuse sello 04:22:03 |
| S-0042c012…77ab | 04:12:08→ 04:14:08 | motor→ escalado por silencio → 1.º suplente | push + SMScrítica | 04:15:20 sello 04:14:09 |
Cómo lo traduce Alertadia
CEDESA DIGITAL, S.L., la empresa que desarrolla Alertadia, tiene certificación ENS de nivel medio vigente. La plataforma se diseña para acreditar conformidad con el ENS de categoría media, y la medida mp.sw se aplica entera:
- Cuatro entornos separados: desarrollo, integración, preproducción y producción.
- Mínimo privilegio por servicio, con los secretos en un gestor especializado.
- OWASP ASVS y MASVS como metodología, con revisión por pares y análisis estático en la integración continua.
- Identificación con SSO sobre el Directorio Activo del organismo (SAML 2.0 u OpenID Connect), doble factor TOTP (RFC 6238) y control de acceso por roles, todo en el diseño.
- Pruebas solo con datos sintéticos y simuladores propios que no consumen las infraestructuras del cliente.
- Inventario de componentes de terceros con monitorización de vulnerabilidades, alineado con las guías CCN-STIC.
La pantalla de sala, con el semáforo por terminal, es una de las pistas de auditoría que el refuerzo R3 pide desde el diseño: cada estado y cada acuse quedan registrados con su hora.
Pantalla de sala
El detalle, con la tabla requisito por requisito, está en la página de seguridad.
Qué poner en el pliego
Si estás redactando los requisitos de un sistema de avisos, estas cláusulas convierten el ENS en algo comprobable:
- Declarar la categoría del sistema (media, salvo que el análisis de riesgos diga otra cosa) y exigir que la solución esté diseñada para acreditar conformidad en esa categoría, con auditoría de certificación conforme al artículo 38.
- Exigir certificación ENS vigente de la empresa adjudicataria, indicando la categoría.
- Pedir la descripción de los entornos (mp.sw.1 base), la metodología de desarrollo seguro (R2) y la política de datos de prueba (R4).
- Pedir la relación de componentes de terceros y su procedimiento de actualización (R5).
- Exigir un entorno de preproducción y un procedimiento formal de aceptación con criterios de seguridad (mp.sw.2 y R1).
- Exigir registro de auditoría inmutable con sincronización horaria, retención definida y control de acceso (op.exp.8 y sus refuerzos).
- Recordar que, si el proveedor usa subcontratistas para algún canal, la exigencia se extiende a la cadena de suministro (artículo 2.3).
Preguntas frecuentes sobre el ENS y el software de avisos
¿Basta con que el proveedor tenga el certificado ENS?
No. El certificado de la empresa acredita que su organización y los sistemas incluidos en el alcance cumplen; el sistema concreto que contratas tiene que estar diseñado para acreditar conformidad en la categoría del pliego y, en media o alta, someterse a auditoría de certificación. Las dos cosas son necesarias.
¿Quién decide si el sistema es de categoría media o alta?
El organismo, como responsable del sistema, valorando el impacto de un incidente en disponibilidad, autenticidad, integridad, confidencialidad y trazabilidad (artículo 40 y Anexo I). El proveedor aporta información, pero no decide.
¿Se puede probar el sistema con el censo real de vecinos?
El refuerzo R4 de mp.sw.1 dice que las pruebas no se realizarán con datos reales, y solo admite excepciones con el mismo nivel de seguridad. La vía razonable son datos sintéticos y simuladores de canal. Si tienes dudas sobre cómo hacerlo en tu caso, consúltanos.
¿El ENS obliga a que los datos estén en España o en la Unión Europea?
El ENS regula medidas de seguridad; la residencia del dato la determinan el Reglamento (UE) 2016/679 y la decisión del responsable. En Alertadia los datos, el portal y las copias están en centros de datos de la Unión Europea o en la infraestructura del propio cliente.