Medidas de protección del ENS: comunicaciones, aplicaciones e información

Tras el gobierno (marco organizativo) y la operación diaria (marco operacional), el tercer bloque del Anexo II del ENS es el escudo: las medidas de protección (mp). Ocho familias que protegen cada plano del sistema — las instalaciones, las personas, los equipos, las comunicaciones, los soportes, las aplicaciones, la información y los servicios. Es el bloque más «tangible» del esquema y, para quienes desarrollamos y operamos plataformas web, el que más directamente habla nuestro idioma. Estas medidas son el núcleo técnico de nuestros servicios de seguridad informática.

Cuarto capítulo de nuestra serie sobre el Esquema Nacional de Seguridad. Como en los anteriores, recorremos cada familia con su traducción práctica para un proveedor tecnológico en categoría media — la situación típica de quien presta servicios al sector público — y cerramos con las evidencias que pedirá el auditor y los errores que más se repiten.

1. Las medidas de protección en el mapa del ENS

Las mp.* completan las 73 medidas del RD 311/2022 junto al marco organizativo y al operacional. Si el operacional define procesos, las mp definen protecciones concretas sobre activos concretos. Muchas se refuerzan con la categoría y con las dimensiones afectadas: una medida puede aplicar «a partir de nivel medio en confidencialidad» o exigir refuerzo solo en categoría alta — la Declaración de Aplicabilidad es donde ese mapa queda fijado para tu sistema.

Para el lector que viene de la serie ISO 27001: este bloque solapa con los controles físicos y buena parte de los tecnológicos del Anexo A. Con una particularidad muy española: el peso de la firma electrónica y los sellos de tiempo, herencia del ADN administrativo del esquema.

2. mp.if — Instalaciones: el plano físico

Áreas separadas con control de acceso, identificación de personas, acondicionamiento de locales, energía eléctrica, protección frente a incendios e inundaciones, y registro de entrada/salida de equipamiento. Para un proveedor cloud-first, la mayor parte se hereda del datacenter del hyperscaler o del hosting: recopila sus certificaciones (el propio ENS del proveedor cloud, ISO 27001, informes de datacenter) y documenta la herencia en tu Declaración de Aplicabilidad. Lo que queda de tu lado: la oficina (control de acceso razonable, equipos no desatendidos) y el puesto remoto, que el ENS también contempla.

3. mp.per — Personal: el eslabón humano

Cuatro medidas: caracterización del puesto de trabajo (qué requisitos de seguridad tiene cada rol), deberes y obligaciones (aceptados y firmados — enlaza con la normativa org.2), concienciación y formación periódicas. La versión eficaz para un equipo técnico es la que defendimos en el capítulo organizativo de la ISO: contenido adaptado a la audiencia (typosquatting en npm y tokens filtrados, no «qué es el phishing»), cadencia ligera pero constante, y registro de asistencia como evidencia. En el ENS, además, el personal debe conocer específicamente sus deberes respecto al sistema del cliente público: confidencialidad, uso correcto y a quién reportar.

4. mp.eq — Equipos: el puesto de trabajo

Puesto de trabajo despejado, bloqueo de sesión por inactividad, protección de portátiles (cifrado de disco completo, inventario, borrado remoto si es posible) y medios alternativos ante fallo de equipos. Con una plantilla MDM básica —o simplemente configuración forzada por políticas del sistema— esta familia se cierra en una tarde. El matiz de teletrabajo: el puesto remoto cumple las mismas reglas, y la normativa debe decirlo explícitamente.

5. mp.com — Comunicaciones: el canal

Perímetro seguro (cortafuegos que separa el sistema del exterior), protección de la confidencialidad e integridad del canal (cifrado: TLS moderno en todo lo expuesto, VPN o equivalente para administración), autenticación mutua donde aplique y segregación de redes (producción separada de desarrollo y de la red de oficina; en cloud, VPCs y grupos de seguridad bien diseñados). En categoría media, el cifrado del canal es exigible con carácter general — en 2026, con TLS automatizado y mallas de servicio, no cumplirlo es ya una decisión activa de no hacerlo.

6. mp.si — Soportes de información: el ciclo de vida físico de los datos

Etiquetado de soportes según la calificación de la información, criptografía en soportes extraíbles y portátiles, custodia y transporte controlados, y —la medida que casi nadie tiene resuelta hasta que se la piden— borrado y destrucción certificada: cuando un disco, portátil o soporte sale de servicio, la información se destruye de forma verificable (borrado seguro o destrucción física, con registro). Para infraestructura cloud, la destrucción de soportes la hereda el hyperscaler; para tus equipos locales, define el proceso y guarda los certificados de destrucción.

7. mp.sw — Aplicaciones: desarrollo seguro, nuestro terreno

La familia estrella para una empresa de desarrollo, con dos medidas de peso:

• Desarrollo de aplicaciones: metodología de desarrollo seguro — seguridad desde el diseño, gestión de vulnerabilidades en el ciclo de vida, control de versiones y separación de entornos, datos de prueba protegidos (nada de copias de producción sin anonimizar en staging) y pruebas de seguridad antes de producción. Todo lo que desarrollamos en el capítulo de controles técnicos y SDLC seguro de la ISO aplica aquí literalmente — con el OWASP como referencia natural para los requisitos, igual que en nuestro repaso del OWASP Top 10.
• Aceptación y puesta en servicio: antes de que una aplicación entre en producción para el cliente público, se verifica que cumple los criterios de seguridad — análisis de vulnerabilidades, pruebas y aprobación formal (el enganche con el proceso de autorización org.4). En la práctica: una release checklist con puertas de seguridad y una aprobación registrada.

Si tu pipeline ya integra revisión de código, escaneo de dependencias y de secretos, y despliegues aprobados, esta familia es de las que salen gratis: documentar el flujo y señalar dónde queda cada evidencia.

8. mp.info — Información: el activo final

La familia que protege el dato en sí: calificación de la información conforme a su valoración (el etiquetado práctico de niveles que definiste al categorizar), cifrado en reposo cuando la confidencialidad lo exige, firma electrónica y sellos de tiempo para autenticidad e integridad de la información que lo requiera (aquí el ENS es mucho más exigente que la ISO: en la administración electrónica la validez jurídica depende de ello — si tu plataforma tramita actos administrativos, la integración con firma es requisito de primera clase), limpieza de documentos (metadatos fuera antes de publicar o compartir) y copias de seguridad — con la misma regla de oro de siempre: 3-2-1, una copia inmutable y restauraciones probadas con acta, como venimos machacando desde la guía del ransomware.

9. mp.s — Servicios: lo que el usuario toca

Cierra el catálogo la protección de los servicios expuestos: correo electrónico (SPF, DKIM y DMARC bien configurados, filtrado anti-phishing — el vector de entrada número uno sigue siendo un email), servicios y aplicaciones web (las protecciones frente al catálogo de ataques web: WAF, cabeceras de seguridad, gestión de sesiones — el terreno que cubrimos en la guía de seguridad WordPress para ese CMS concreto) y protección frente a denegación de servicio: capacidad de absorber o mitigar DoS/DDoS, típicamente heredada en parte del CDN/cloud y complementada con rate limiting propio.

10. Caso aterrizado: las mp.* de un proveedor cloud-first

El mismo SaaS de 20 personas del capítulo anterior, ahora con su capa de protección en categoría media:

• mp.if: herencia documentada del hyperscaler (certificados archivados) + control de acceso de la oficina y política de puesto remoto.
• mp.per: deberes firmados en onboarding, píldora de concienciación trimestral y formación técnica anual, con registros.
• mp.eq: MDM ligero: disco cifrado, bloqueo a 5 minutos, inventario de portátiles y borrado remoto.
• mp.com: TLS 1.3 en todo, administración por VPN con MFA, VPCs segregadas por entorno.
• mp.si: soportes extraíbles prohibidos por normativa (excepción autorizada y cifrada), destrucción certificada de equipos al final de vida.
• mp.sw: SDLC documentado sobre su flujo real de PRs + release checklist con escaneo y aprobación registrada.
• mp.info: datos calificados en dos niveles, cifrado en reposo en base de datos y backups, integración de firma delegada en la plataforma estatal que usa su cliente, limpieza de metadatos en los PDF generados, backups 3-2-1 con restauración trimestral.
• mp.s: DMARC en enforcement, WAF gestionado + rate limiting, protección DDoS del CDN documentada como herencia.

Tiempo de adecuación de este bloque partiendo de una base técnica sana: tres a cuatro semanas de trabajo repartido, la mitad de él pura documentación de lo que ya existía.

11. Por dónde empezar: las mp.* ordenadas por retorno

Si tu adecuación parte de cero en este bloque, este es el orden que recomendamos — máxima reducción de riesgo real por hora invertida:

• Semana 1 — mp.com y mp.s básico: TLS moderno verificado en todo lo expuesto, administración solo por canal cifrado con MFA, DMARC de monitorización a enforcement en un mes, WAF delante de lo público. Es lo que un atacante toca primero.
• Semana 2 — mp.info crítico: cifrado en reposo donde viven los datos calificados, backups 3-2-1 con copia inmutable y primera restauración de prueba con acta.
• Semana 3 — mp.eq y mp.per: flota cifrada e inventariada (MDM o políticas forzadas), deberes firmados y primera píldora de concienciación con registro.
• Semana 4 — mp.sw formal: documentar el SDLC sobre tu flujo real, añadir la release checklist con puertas de seguridad y limpiar staging de datos reales.
• Semanas 5-6 — el resto con criterio: herencias de mp.if documentadas, proceso de soportes y destrucción, limpieza de metadatos automatizada, y la integración de firma/sellos si tu servicio tramita — esta última es la única que puede ser un proyecto en sí misma: dimensiónala aparte.

Al final de las seis semanas, cada medida debe poder responder a la pregunta de siempre: ¿dónde está la evidencia? Si la respuesta es «en el flujo normal del equipo», vas bien.

12. Mini-FAQ de las medidas de protección

Somos 100% remoto: ¿cómo cumplimos mp.if sin oficina?

Documentando la herencia del datacenter (tu cloud) y trasladando el foco al puesto remoto: equipos cifrados, bloqueo, red doméstica con condiciones mínimas en la normativa y, si manejas información sensible, pantalla de privacidad y reglas de espacio de trabajo. Las certificadoras lo auditan con total normalidad.

¿La firma electrónica nos aplica si solo hacemos la web informativa?

Probablemente no: firma y sellos aplican donde la autenticidad e integridad de la información lo exigen — tramitación, actos administrativos, documentos con validez jurídica. Una web informativa municipal difícilmente lo requiere; una plataforma de expedientes, siempre. La Declaración de Aplicabilidad es donde se justifica una cosa u otra.

¿Vale mi antivirus corporativo de siempre para mp?

La protección frente a código dañino vive en el marco operacional (op.exp), pero la pregunta de fondo es la misma: un EDR moderno gestionado aporta detección y evidencia; un antivirus de firmas sin consola centralizada aporta poco más que la casilla marcada. En categoría media, apunta a lo primero.

¿Quién decide la calificación de la información (mp.info)?

El responsable de la información — que en la relación con la administración suele ser tu cliente público. Tu papel como proveedor: proponer el esquema de calificación, implementar el etiquetado y las protecciones asociadas, y dejar la decisión firmada en el reparto de responsabilidades del contrato.

13. Qué muestrea el auditor en las mp.*

• «Certificados de vuestro datacenter/cloud y qué heredáis exactamente» — mp.if, herencia negro sobre blanco.
• «La última formación: contenido, fecha y asistentes» — mp.per.
• «Este portátil: ¿está cifrado? Enséñamelo» — mp.eq, verificación en vivo.
• «Informe TLS de vuestros dominios y diagrama de segregación de redes» — mp.com.
• «El último equipo dado de baja: ¿dónde está el certificado de destrucción?» — mp.si.
• «Una release reciente: pruebas de seguridad y aprobación de puesta en servicio» — mp.sw.
• «¿Cómo firmáis/sellláis los documentos que emite la plataforma?» — mp.info, si aplica tramitación.
• «Vuestro DMARC y qué pasó en el último intento de phishing» — mp.s.

14. Errores típicos de las medidas de protección

• Herencia sin papeles: «eso lo cubre el datacenter» sin certificado archivado ni mención en la Declaración de Aplicabilidad.
• El portátil sin cifrar del comercial: la flota de desarrollo impecable y un equipo fuera de inventario con acceso al CRM. El muestreo los encuentra.
• Staging con datos reales: el clásico que une mp.sw y RGPD en una sola no conformidad. Anonimiza o genera datos sintéticos.
• Firma electrónica «pendiente de integrar»: si tu servicio tramita actos con validez jurídica, la firma no es un nice-to-have — dimensiona su integración desde el diseño.
• DMARC en p=none eterno: monitorizar sin pasar nunca a enforcement es quedarse a medio camino de la protección del correo.
• Metadatos delatores: PDFs publicados con autores, rutas internas y versiones de software. La limpieza de documentos existe como medida por algo.

15. Las mp.* y tu Declaración de Aplicabilidad: la trazabilidad final

Un apunte de método para cerrar el bloque: cada familia mp que actives (o excluyas) debe quedar trazada en la Declaración de Aplicabilidad con tres datos — si aplica y con qué refuerzo según tu categoría y dimensiones, cómo la implementas (o de quién la heredas), y dónde vive su evidencia. Esa tabla de tres columnas es el documento que convierte este capítulo en tu checklist personalizado, y el primero que el auditor pondrá al lado de la realidad.

Y si estás construyendo el sistema dual ENS + ISO 27001 que recomendamos en la guía central, añade una cuarta columna con el control equivalente del Anexo A: mp.com ↔ criptografía y redes, mp.sw ↔ desarrollo seguro 8.25-8.31, mp.info ↔ cifrado y backups, mp.per ↔ controles de personas. Cada evidencia que generes alimentará los dos certificados a la vez — la mitad del coste de mantenimiento, exactamente como prometimos.

Conclusión: el escudo se hereda, se configura y se demuestra

Las medidas de protección cierran el recorrido por el Anexo II con una lección clara para proveedores cloud-first: buena parte del escudo físico se hereda (documentándolo), el escudo técnico se configura sobre herramientas que ya tienes, y el diferencial español —firma, sellos, calificación— se diseña una vez y se integra en la plataforma. Nada exige heroísmo; todo exige rastro.

Con los tres marcos recorridos —organizativo, operacional y de protección— ya tienes el Anexo II completo bajo control. Los próximos capítulos de la serie cambian de plano: la guía específica para proveedores tecnológicos que quieren vender al sector público, y el cara a cara ENS vs ISO 27001. Si llegas nuevo, empieza por la guía completa del ENS.