El playbook de ENISA Secure by Design & Default

Secure by design describe cómo se construye un sistema: las amenazas se modelan pronto, y los patrones de arquitectura, la criptografía contrastada y la gestión sistemática de vulnerabilidades se integran en el proceso de desarrollo en lugar de añadirse a posteriori. Secure by default describe cómo llega el producto al cliente: con la configuración más segura razonablemente posible de fábrica, sin exigir conocimientos expertos; las protecciones están activas y debilitarlas requiere una decisión deliberada. El playbook organiza los 14 principios de diseño en Architectural Foundations y Operational Integrity, y los 8 principios por defecto en Default Hardening y Guided Protection.

Architectural Foundations (6) abarca trust boundaries y threat modelling, mínimo privilegio, una arquitectura sólida de identidad y autenticación, la minimización de la superficie de ataque, la defensa en profundidad y el open design. Operational Integrity (8) añade la gestión del ciclo de vida, el diseño centrado en el usuario, la codificación segura y su verificación, el logging y la monitorización, la gestión de configuraciones y cambios, la respuesta a incidentes, la gestión de vulnerabilidades y parches, y los controles de la cadena de suministro, SBOM incluido. En el lado por defecto figuran la minimización de servicios por defecto, el acceso inicial restrictivo, la comunicación cifrada de fábrica e identidades únicas por dispositivo (Default Hardening), además del onboarding de seguridad obligatorio, las actualizaciones automáticas, una postura de seguridad transparente y procesos seguros de recuperación y transferencia de propiedad (Guided Protection).

Cada principio sigue el mismo formato de cinco bloques: principio, objetivo, una lista de verificación con las acciones de mayor impacto, evidencias mínimas –el conjunto más pequeño de artefactos que demuestra la implantación– y un release gate con criterios de aprobado/suspenso para las revisiones de release o la pipeline CI/CD. Las evidencias deben proceder de artefactos de ingeniería existentes (diagramas de arquitectura, logs de CI, tickets, SBOM) y pueden servir a varios playbooks a la vez; se permiten excepciones, pero solo documentadas con responsable y fecha de revisión. Para la adopción, ENISA propone tres etapas: aclarar primero el contexto y las prioridades; establecer después una base de ingeniería con codificación segura, logging, gestión de vulnerabilidades y controles de la cadena de suministro –complementada con los playbooks por defecto relevantes para el producto– y, por último, ampliar cobertura y automatización. Importante: este plan por etapas organiza el esfuerzo, no aplaza ninguna obligación legal.

En lugar de análisis pesados, el playbook recomienda un minimum viable threat model en torno a las cuatro preguntas del marco de Shostack: ¿en qué estamos trabajando? ¿Qué puede salir mal? ¿Qué vamos a hacer al respecto? ¿Lo hicimos suficientemente bien? El resultado cabe en una página: un diagrama con componentes, flujos de datos y trust boundaries, los cinco a diez escenarios de amenaza más relevantes, controles por escenario con ajustes secure-default y métodos de verificación, además de disparadores definidos para actualizar el modelo. ENISA señala expresamente los antipatrones típicos: el threat modelling como ejercicio puntual de cumplimiento, modelos sobredimensionados sin efecto en las decisiones de diseño y la falta de actualización tras cambios del producto. En productos con componentes de IA, la prompt injection, el envenenamiento de modelos y las entradas adversarias también forman parte del modelo.

La parte más visionaria del documento: las afirmaciones de seguridad salen de los PDF estáticos hacia artefactos estructurados y firmables (JSON/YAML) que conectan tres capas: objetivos de seguridad (control layer), controles implantados y su configuración (implementation layer) y resultados de verificación automatizados con hashes de evidencia (assessment and verification layer). Con el ejemplo desarrollado SafeGate-X1, un controlador industrial Linux, ENISA muestra cómo las amenazas se vuelven trazables desde los principios hasta release gates automáticos, del gate de escaneo Nmap a la prueba de sistema de archivos de solo lectura en la CI. ENISA no prescribe deliberadamente ningún esquema nuevo y remite a estándares existentes: NIST OSCAL, OWASP CycloneDX con CDXA y VEX, el perfil de seguridad de SPDX 3.0, proyectos de la OpenSSF como Scorecard y SLSA, además de in-toto y Sigstore. Y deja claro un punto: una atestación del fabricante no es una prueba; la verificación y la evaluación independiente siguen siendo pasos separados.

El anexo B del playbook recoge los requisitos esenciales de ciberseguridad del anexo I del Cyber Resilience Act; el anexo C asigna a ellos, de forma indicativa, cada uno de los 22 principios: las actualizaciones automáticas al anexo I parte I 2(c), los controles de la cadena de suministro a la obligación de SBOM de la parte II o el acceso inicial restrictivo a la configuración por defecto segura de la parte I 2(b). Eso convierte el documento en una puerta de entrada de ingeniería útil para las gap analysis del CRA: los equipos ven qué playbooks alimentan qué requisitos y recopilan pronto evidencias sólidas a través de los release gates. Al mismo tiempo, ENISA subraya que seguir el playbook no establece la conformidad con el CRA: la evaluación de la conformidad, las normas armonizadas y la documentación técnica exigida por el reglamento siguen siendo obligaciones independientes.