Das ENISA Secure by Design & Default Playbook

Secure by Design beschreibt, wie ein System gebaut ist: Bedrohungen werden früh modelliert, Architektur-Muster, geprüfte Kryptografie und systematisches Schwachstellenmanagement sind in den Entwicklungsprozess eingebettet statt nachgerüstet. Secure by Default beschreibt, wie das Produkt beim Kunden ankommt: mit der sichersten sinnvollen Konfiguration ab Werk, ohne dass Anwender Expertenwissen brauchen – Schutzmechanismen sind aktiv, und wer sie abschwächt, tut das bewusst. Das Playbook ordnet die 14 Design-Prinzipien den Gruppen Architectural Foundations und Operational Integrity zu, die 8 Default-Prinzipien den Gruppen Default Hardening und Guided Protection.

Architectural Foundations (6) umfasst Trust Boundaries & Threat Modelling, Least Privilege, eine starke Identitäts- und Authentifizierungsarchitektur, minimale Angriffsfläche, Defence in Depth und Open Design. Operational Integrity (8) ergänzt Lifecycle-Management, nutzerzentriertes Design, Secure Coding und Verifikation, Logging und Monitoring, Konfigurations- und Änderungsmanagement, Incident Response, Schwachstellen- und Patch-Management sowie Supply-Chain-Kontrollen inklusive SBOM. Auf der Default-Seite stehen minimale Default-Services, restriktiver Erstzugang, verschlüsselte Kommunikation ab Werk und einzigartige Geräteidentitäten (Default Hardening) sowie verpflichtendes Security-Onboarding, automatische Updates, transparente Sicherheitslage und sichere Recovery- und Besitzwechsel-Prozesse (Guided Protection).

Jedes Prinzip folgt demselben Fünf-Block-Format: Prinzip, Ziel, Checkliste mit den wirksamsten Aktionen, Minimum Evidence – die kleinste Menge an Artefakten, die die Umsetzung belegt – und ein Release-Gate mit Pass/Fail-Kriterien für Release-Reviews oder die CI/CD-Pipeline. Nachweise sollen aus vorhandenen Engineering-Artefakten bestehen (Architektur-Diagramme, CI-Logs, Tickets, SBOMs) und dürfen mehrere Playbooks gleichzeitig bedienen; Ausnahmen sind erlaubt, aber nur dokumentiert mit Verantwortlichem und Review-Datum. Für die Einführung empfiehlt ENISA drei Stufen: zuerst Kontext und Prioritäten klären, dann eine Engineering-Baseline aus Secure Coding, Logging, Schwachstellen-Management und Supply-Chain-Kontrollen etablieren – ergänzt um die produktrelevanten Default-Playbooks – und schließlich Abdeckung und Automatisierung ausbauen. Wichtig: Der Stufenplan organisiert Aufwand, verschiebt aber keine rechtlichen Pflichten.

Statt schwergewichtiger Analysen empfiehlt das Playbook ein Minimum Viable Threat Model entlang der vier Fragen von Shostacks Framework: Woran arbeiten wir? Was kann schiefgehen? Was tun wir dagegen? War es gut genug? Ergebnis ist eine Seite: ein Diagramm mit Komponenten, Datenflüssen und Trust Boundaries, die fünf bis zehn wichtigsten Bedrohungsszenarien, je Szenario Kontrollen samt Secure-Default-Einstellung und Verifikationsmethode – plus definierte Trigger, wann das Modell aktualisiert werden muss. ENISA benennt typische Anti-Pattern ausdrücklich: Threat Modelling als einmalige Compliance-Übung, überdetaillierte Modelle ohne Wirkung auf Designentscheidungen und fehlende Refreshs nach Produktänderungen. Für Produkte mit KI-Komponenten gehören auch Prompt Injection, Model Poisoning und Adversarial Inputs ins Modell.

Der visionärste Teil des Dokuments: Sicherheitsaussagen wandern aus statischen PDFs in strukturierte, signierbare Artefakte (JSON/YAML), die drei Schichten verbinden – Sicherheitsziele (Control Layer), implementierte Kontrollen samt Konfiguration (Implementation Layer) und automatisierte Prüf-Ergebnisse mit Evidence-Hashes (Assessment & Verification Layer). Am durchgerechneten Beispiel SafeGate-X1, einem Linux-Industriecontroller, zeigt ENISA, wie Bedrohungen über Prinzipien bis zu automatischen Release-Gates rückverfolgbar werden – vom Nmap-Scan-Gate bis zum Read-only-Dateisystem-Test in der CI. ENISA schreibt bewusst kein neues Schema vor, sondern verweist auf existierende Standards wie NIST OSCAL, OWASP CycloneDX mit CDXA und VEX, das SPDX-3.0-Security-Profile, OpenSSF-Projekte wie Scorecard und SLSA sowie in-toto und Sigstore. Klargestellt wird auch: Eine Hersteller-Attestierung ist kein Beweis – Verifikation und unabhängige Bewertung bleiben eigenständige Schritte.

Annex B des Playbooks listet die grundlegenden Cybersicherheitsanforderungen aus Anhang I des Cyber Resilience Act, Annex C mappt jedes der 22 Prinzipien indikativ darauf – etwa automatische Updates auf Anhang I Teil I 2(c), Supply-Chain-Kontrollen auf die SBOM-Pflicht in Teil II oder restriktiven Erstzugang auf die sichere Standardkonfiguration nach Teil I 2(b). Damit eignet sich das Dokument als Engineering-Einstieg in CRA-Gap-Analysen: Teams sehen, welche Playbooks auf welche Anforderungen einzahlen, und sammeln über die Release-Gates früh belastbare Nachweise. ENISA betont zugleich, dass die Befolgung des Playbooks keine CRA-Konformität begründet – Konformitätsbewertung, harmonisierte Normen und die technische Dokumentation nach der Verordnung bleiben eigenständige Pflichten.