Das ENISA Secure by Design Playbook: Was es für Produktteams unter dem CRA bedeutet

Was ist das ENISA Secure by Design Playbook?

Am 19. März 2026 veröffentlichte die Europäische Agentur für Cybersicherheit (ENISA) das Security by Design and Default Playbook, Version 0.4, als Entwurf zur öffentlichen Konsultation.

Es ist die erste offizielle EU-Orientierungshilfe, die CRA-Sicherheitsanforderungen in konkrete Engineering-Checklisten für KMUs übersetzt. Das Dokument ist keine Rechtsberatung. Es bietet praktische, technisch fundierte Ansätze, die Produktteams in den Phasen Design, Entwicklung und Deployment anwenden können.

Das Playbook richtet sich an KMUs (definiert als Organisationen mit weniger als 250 Beschäftigten und einem Jahresumsatz unter 50 Millionen Euro), die Produkte mit digitalen Elementen herstellen. Dazu gehören eingebettete Software, IoT-Geräte, vernetzte Systeme, eigenständige Software und Hardware mit programmierbaren Komponenten.

ENISA hat das Playbook auf Basis einer Analyse bestehender Sicherheitsrahmenwerke entwickelt, die von ENISA und anderen EU-Cybersicherheitsbehörden sowie von NIST und OWASP veröffentlicht wurden. Gemeinsame Anforderungen und Implementierungsmuster wurden identifiziert und im Hinblick auf die Machbarkeit für KMUs bewertet.

Anhang C des Playbooks ordnet alle 22 Prinzipien direkt den wesentlichen Anforderungen aus CRA Anhang I zu und schafft damit eine nachvollziehbare Verbindung zwischen Engineering-Praktiken und regulatorischen Pflichten.

Für wen ist dieses Playbook gedacht?

Das Playbook identifiziert vier primäre Zielgruppen (Abschnitt 1.3):

• Softwareentwickler und Ingenieure: Personen, die Code schreiben und praktische Wege suchen, Sicherheit einzubauen, ohne die Liefergeschwindigkeit zu beeinträchtigen
• Technische Produktmanager: Personen, die Feature-Arbeit und Sicherheitsanforderungen gegeneinander abwägen und beides unter einen Hut bringen müssen
• KMU-Sicherheitsverantwortliche: Personen, die Enterprise-Rahmenwerke in etwas überführen, das mit begrenzten Budgets und kleinen Teams funktioniert
• Systemarchitekten: Personen, die Systeme entwerfen und Sicherheit von Anfang an integrieren wollen, nicht erst im Nachhinein

Die gemeinsame Herausforderung, die ENISA anerkennt: Die meisten KMUs haben kein dediziertes Sicherheitsteam, begrenztes Budget für Security-Werkzeuge, und Sicherheitsarbeit, die ständig mit der Feature-Entwicklung konkurriert.

Die Antwort des Playbooks: strukturierte Checklisten, die Teams dabei helfen, schnell umsetzbare Sicherheitsmaßnahmen zu identifizieren, sie realistisch zu implementieren und eine wiederholbare Baseline aufzubauen, die sie im Laufe der Zeit verbessern können.

Sicherheit entlang des Produktlebenszyklus

Sicherheit muss durchgängig berücksichtigt werden, unabhängig vom eingesetzten Produktionsmodell (V-Modell, Agile oder andere). Das Playbook definiert sechs Phasen, jede mit spezifischen Sicherheitsmaßnahmen und konkreten Lieferergebnissen.

Leitprinzipien aus dem Dokument:

• Kleine, wiederverwendbare Artefakte einsetzen (einseitige Kontextnotizen, einfache Diagramme, Checklisten)
• Automatisierte Kontrollen in CI/CD gegenüber manuellen Reviews bevorzugen, tiefgehende Reviews für risikoreiche Änderungen aufsparen
• Schnelle Sicherheits-Gates einführen, die auf bestehende agile Zeremonien abgestimmt sind (Definition of Ready/Done, PR-Checks, Release-Checkliste)

Jede Phase erzeugt ein konkretes Lieferergebnis. Das ist keine abstrakte Anleitung.

Welche Risikomanagement-Aktivitäten empfiehlt ENISA?

Risikomanagement-Aktivitäten bilden die Grundlage aller Secure-by-Design- und Secure-by-Default-Entscheidungen. Das Playbook schlägt kein schwerfälliges formales Rahmenwerk vor. Stattdessen definiert es einen Mindestsatz an Aktivitäten, die Sicherheitsentscheidungen treiben können, ohne aufwendige Prozesse zu erzeugen (Abschnitt 2.2).

Das Dokument definiert 8 Aktivitäten (Tabelle 2):

1. Produktkontext und Umfang: Beabsichtigten Verwendungszweck, Deployment-Umgebungen, Nutzer- und Administrationsrollen, Datentypen und -sensitivität sowie wesentliche externe Abhängigkeiten definieren. Lieferergebnis: 1-2-seitige "Product Security Context"-Notiz (Umfang, Annahmen, Abhängigkeiten).
2. Asset- und Schadensidentifikation: Wichtigste Daten-, Hardware- oder Funktions-Assets auflisten (Credentials, Kundendaten, personenbezogene Daten, Gerätekontrolle) sowie die wesentlichen Schadensszenarien (Datenschutzverletzung, Übernahme, Ausfall, Betrug, Sicherheitsauswirkungen). Lieferergebnis: Asset-Liste + "Top Harms"-Liste (eine Seite).
3. Leichtgewichtiges Threat Modelling: Siehe Abschnitt zu Threat Modelling weiter unten.
4. Risikoregister: 10-30 Risiken mit Eintrittswahrscheinlichkeit/Auswirkung (einfache Skala), Verantwortlichem, Behandlung und Status erfassen. Hochrisiken mit Backlog-Einträgen und Maßnahmen verknüpfen. Lieferergebnis: Lebendes Risikoregister (Tabellenkalkulation oder Ticket-Board).
5. Risikoakzeptanzkriterien: Einen Satz nicht verhandelbarer Risikobedingungen definieren. Beispiel: Missbrauch von Software-Updates, unbefugter Administratorzugriff oder Ausnutzung von Standard-Credentials ist NICHT akzeptabel. Kriterien für die Akzeptanz von Restrisiken festlegen, die die wesentlichen Cybersicherheitsanforderungen nicht untergraben dürfen. Lieferergebnis: 1-seitige Richtlinie zur Risikoakzeptanz und Ausnahmen.
6. Security-Requirements-Baseline: Top-Risiken in prüfbare "Must"-Anforderungen überführen (Authentifizierung/Autorisierung, sichere Defaults, Secrets, Verschlüsselung, Logging, Updates). Lieferergebnis: KMU-Security-Requirements-Checkliste (prüfbare Maßnahmen).
7. Release-Risk-Review-Gate: Formales Pre-Release-Gate: Checkliste erfüllt bestätigen, Defaults verifiziert, bekannte Schwachstellen triagiert, hohe Risiken behandelt oder mit Begründung akzeptiert. Go/No-Go-Entscheidung treffen. Lieferergebnis: Release-Security-Review-Protokoll + dokumentierte Ausnahmen.
8. Änderungsgetriggerte Neubewertung: Kontext/Threat/Risiko-Schritte erneut durchführen, wenn wesentliche Änderungen eintreten (Architektur, Auth-Modell, kritische Abhängigkeit/Lieferant, Deployment-Umgebung, nach Incidents). Lieferergebnis: Aktualisierte Kontextnotiz, Threat-Kurzliste und Risikoregistereinträge (mit Datum).

Wie sollten KMUs an Threat Modelling herangehen?

Das Playbook baut auf der STRIDE-Methodik (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) als Grundlage für die Bedrohungsidentifikation und -klassifizierung auf (Abschnitt 2.3).

Es warnt ausdrücklich vor verbreiteten Anti-Patterns: Threat Modelling als einmalige Compliance-Übung behandeln, Modelle übertechnisieren, die Design- oder Secure-by-Default-Entscheidungen nicht beeinflussen, und das Modell nach wesentlichen Produktänderungen oder Veränderungen in der Bedrohungslandschaft nicht zu überprüfen.

Für KMUs, insbesondere solche, die Produkte für unkritische oder risikoärmere Umgebungen entwickeln, ist das Ziel ein "Minimum Viable" Modell: schnell zu erstellen, einfach aufzufrischen und eng an die Lieferung gekoppelt (Architekturentscheidungen, Standard-Konfiguration und Release-Gates).

Die 5 Schritte (Tabelle 3)

1. Umfang, Annahmen und Sicherheitsziele definieren: Den Scoping-Schritt zeitlich begrenzen. Festhalten, was im und außerhalb des Scope liegt, den Deployment-Kontext und die zugrunde liegenden Annahmen (z.B. "das Kundennetzwerk ist nicht vertrauenswürdig", "Cloud-APIs sind internet-exponiert"). Die Sicherheitsziele benennen, die für dieses Produkt zählen (Vertraulichkeit, Integrität, Verfügbarkeit, sowie Datenschutz/Sicherheit falls relevant). Die "Kronjuwelen" identifizieren: was darf nicht versagen. Lieferergebnis: 1-seitiger "Threat Model Scope & Objectives".

2. Das System auf einem nützlichen Abstraktionsniveau modellieren: Ein einzelnes, einfaches Architektur- oder Datenflussdiagramm erstellen. Hauptkomponenten, externe Entitäten, Datenspeicher sowie die wichtigsten Einstiegspunkte und Datenflüsse darstellen. Ein DFD-ähnliches Diagramm ist der schnellste Ansatz mit hohem Erkenntnisgewinn. Das Dokument sagt "nicht zu viel darüber nachdenken". Lieferergebnis: Diagramm mit Hauptkomponenten, externen Entitäten, Datenspeichern, Einstiegspunkten.

3. Vertrauensgrenzen und privilegierte Pfade markieren, Schlüssel-Assets identifizieren: Das Diagramm mit Vertrauensgrenzen annotieren (Internet-Backend, Gerät-Cloud, Nutzer-Admin, Mandant-Mandant) sowie die höchstprivilegierten Operationen (Firmware/OTA-Update, Remote-Admin, Key Provisioning, Identity Issuance). Dieser Schritt wandelt "Architektur" in "sicherheitsrelevante Architektur" um. Lieferergebnis: Diagramm mit Vertrauensgrenzen, privilegierten Pfaden, Top-Assets.

4. Top-Bedrohungen identifizieren und priorisieren (5-10 Missbrauchsfälle): Eine kurze Liste realistischer Missbrauchsfälle erstellen, die Einstiegspunkten und Grenzen zugeordnet sind (z.B. "Credential Stuffing zu Account-Übernahme", "bösartiges Update", "API-Autorisierungs-Bypass", "MITM beim Onboarding"). Mit einem leichtgewichtigen Schema (Hoch/Mittel/Niedrig) nach Auswirkung und Plausibilität einordnen. OWASP beschreibt Bedrohungsidentifikation und -priorisierung als Kernschritt in den meisten Threat-Modelling-Ansätzen. Lieferergebnis: Top-Threats-Tabelle mit 5-10 Missbrauchsfällen, Auswirkung und Wahrscheinlichkeit, "Top-Risiken"-Liste.

5. Mitigationen, sichere Defaults und Verifikation definieren, Auffrischungsauslöser festlegen: Für jede Top-Bedrohung die Mitigationsstrategie, die erforderlichen Maßnahmen und die sichere Standardeinstellung festlegen, die ausgeliefert werden soll (z.B. "Admin-Interface standardmäßig deaktiviert", "keine Standard-Passwörter", "signierte Updates erzwungen", "Least-Privilege-Rollen", "Authentifizierungsversuche ratenlimitiert"). Jede Maßnahme einer Verifikationsmethode zuordnen (CI-Checks, Tests, Konfigurationsvalidierung, Release-Gate). Die Auslöser definieren, die eine Neuausführung des Modells erfordern (neue internet-exponierte Schnittstelle, Auth-Modell-Änderung, neue sensible Daten, neue kritische Abhängigkeit, wesentliche Architekturänderung). Lieferergebnis: Maßnahmen-, Defaults- und Verifikations-Checkliste.

Was sind die 22 Sicherheitsprinzipien?

Das Dokument definiert 22 Sicherheitsprinzipien (Abschnitt 3), von denen jedes ein eigenes einseitiges Playbook in Abschnitt 4 erhält. Die Playbooks sind das Kernlieferergebnis des Dokuments. Jedes destilliert ein einzelnes Prinzip in einen umsetzungsorientierten Leitfaden mit Checkliste, Mindestnachweis und Release-Gate-Kriterien. Die Prinzipien sind in zwei Säulen gegliedert: Secure by Design (wie das System entwickelt wird, 14 Prinzipien) und Secure by Default (wie das Produkt beim ersten Einschalten geliefert wird und sich verhält, 8 Prinzipien). Jede Säule ist in zwei Gruppen unterteilt.

Architektonische Grundlagen (6 Prinzipien)

Diese befassen sich mit der strukturellen Gestaltung und dem Aufbau des Systems:

1. Vertrauensgrenzen und Threat Modelling: Vertrauen explizit machen. Definieren, wo Daten, Identitäten und Ausführungskontexte von vertrauenswürdigen in nicht-vertrauenswürdige Zonen wechseln. Threat Modelling einsetzen, um zu identifizieren, was an diesen Grenzen schiefgehen kann.
2. Least Privilege: Nur den minimal notwendigen Zugriff gewähren. Konsistent auf Benutzerkonten, Servicekonten, APIs und Administrationsrollen anwenden. Nur bei Bedarf und für die kürzestmögliche Dauer erhöhen.
3. Starke Identitäts- und Authentifizierungsarchitektur: Klarer Ansatz dafür, wie Identitäten für Nutzer, Geräte, Dienste und Administratoren erstellt, verifiziert und verwaltet werden. Widerstandsfähig gegen Credential Stuffing, Replay-Angriffe und Session Hijacking.
4. Angriffsfläche minimieren: Komplexität reduzieren. Standard-Accounts entfernen, nicht verwendete Pakete deinstallieren, nicht benötigte Ports schließen, exponierte Management-Interfaces einschränken. Fortlaufendes Schwachstellen-Scanning.
5. Defence in Depth: Geschichtete Maßnahmen, sodass ein Versagen einer Schicht nicht zum vollständigen Kompromittieren führt. Präventive, detektive und korrektive Maßnahmen. Divers und unabhängig, nicht alle auf dieselbe Technologie oder Vertrauensannahme gestützt.
6. Open Design (Vermeidung von Obfuskation): Nicht auf die Geheimhaltung des Designs als Schutz setzen. Gut untersuchte Algorithmen und Protokolle verwenden, klare Dokumentation und Entwürfe, die einer kritischen Prüfung standhalten. Sicherheit soll auf geschützten Schlüsseln, starker Authentifizierung und robuster Implementierung beruhen, nicht auf verborgenen Mechanismen.

Betriebliche Integrität (8 Prinzipien)

Diese befassen sich damit, wie das System verwaltet und gewartet wird:

1. Lifecycle-Management: Sicherheit endet nicht mit der Entwicklung. Kontrolliertes Warten, Aktualisieren und Außerbetriebnehmen. Secure by Design von der Entwicklung bis zur Außerbetriebnahme anwenden.
2. Nutzerzentriertes Design: Sicherheit muss für Alltagsnutzer bedienbar sein. Schlechte Usability führt zu unsicheren Workarounds. Einfaches Setup, automatische Verschlüsselung, geführte Abläufe.
3. Sichere Coding-Praktiken: Etablierten sicheren Coding-Standards folgen. SAST-Werkzeuge, SCA für Abhängigkeiten, DAST vor dem Deployment. Frühe Identifizierung, nicht erst nach dem Release.
4. Logging, Monitoring und Alerting: Sicherheitsrelevante Logs erzeugen, für einen definierten Zeitraum aufbewahren und vor Manipulation schützen. Verdächtiges Verhalten erkennen (fehlgeschlagene Authentifizierung, Privilege Escalation, unerwartete Konfigurationsänderungen).
5. Konfigurations- und Änderungsmanagement: Konfigurationen müssen kontrolliert, konsistent und nachvollziehbar sein. Baseline-Hardening, Infrastructure-as-Code, Änderungsprozess mit Review, Test, Freigabe und Rollback.
6. Incident Response und Recovery: Vorbereitung auf Schwachstellen, kompromittierten Code, bösartige Updates, Produktmissbrauch. Definierte Rollen, Eskalationspfade, dokumentierte Playbooks, Kundenkommunikation.
7. Schwachstellen- und Patch-Management: Praktisch, wiederholbar und nach Risiko priorisiert. Einfacher Eingangskanal (Security-E-Mail und Disclosure-Prozess), interner Triageprozess, klare SLAs.
8. Supply-Chain-Maßnahmen: Produktintegrität an den wirkungsstärksten Punkten schützen: Code-Repositories, Build-Systeme, Signing-Keys, Vertriebskanäle. Mindestens: eingeschränkter CI/CD-Zugriff, MFA, Peer-Review für sicherheitskritische Änderungen, SBOMs.

Default-Hardening (4 Prinzipien)

Diese stellen sicher, dass Produkte in einem sicheren und restriktiven Zustand starten:

1. Minimierung von Standard-Diensten: Nicht wesentliche Funktionen und Dienste standardmäßig deaktiviert. Nutzer muss sich explizit dafür entscheiden.
2. Restriktiver Erstzugriff: Universelle "admin/admin"-Credentials abschaffen. Eindeutige Passwörter und obligatorische Passwortänderung beim ersten Start erzwingen.
3. Sichere Kommunikation als Standard: Alle externen Kommunikationen ab der ersten Verbindung verschlüsselt und authentifiziert. TLS 1.3 oder SSH strikt durchsetzen. Keine HTTP/Telnet-Rückfalloptionen.
4. Eindeutige Geräteidentität und Secrets als Standard: Mit einzigartigen gerätespezifischen Credentials und kryptografischer Identität ausliefern. Keine geteilten Schlüssel oder Zertifikate über Produkte hinweg. Vor Extraktion geschützt.

Geführter Schutz (4 Prinzipien)

Diese unterstützen Nutzer dabei, Sicherheit nach dem Deployment aufrechtzuerhalten:

1. Obligatorisches Sicherheits-Onboarding: Kritische Sicherheitsfunktionen müssen Teil des initialen Setup-Assistenten sein (MFA, Verschlüsselungsschlüssel, Admin-Account-Setup). Nicht in Einstellungen verstecken. Betrieb bis zum Abschluss sperren.
2. Automatisierte Wartung und Updates: Automatische Sicherheitsupdates standardmäßig aktiviert. Sicherheitsupdates von Feature-Updates trennen. Kryptografisch verifiziert. Sichere Fehlermodi (Gerät nicht unbrauchbar machen). Nutzer benachrichtigen.
3. Transparenter Sicherheitsstatus: Aktuellen Sicherheitszustand klar anzeigen. Warnen, wenn Nutzer die Sicherheit reduziert. Auswirkungen in verständlicher Sprache erklären. Einen-Klick-Pfad zur Wiederherstellung der sicheren Baseline anbieten.
4. Sichere Wiederherstellung und Ownership-Lifecycle: Geführte Wiederherstellung (Credential-Reset, Account-Recovery, Werksreset, Eigentumsübertragung). Einfach für Nutzer, aber widerstandsfähig gegen Account-Übernahme und Social Engineering. Werksreset muss den vorherigen Nutzerzugriff vollständig entfernen.

CRA-Bezug: Anhang C des Playbooks ordnet jedes dieser 22 Prinzipien bestimmten wesentlichen Anforderungen aus CRA Anhang I zu und zeigt genau, welche Engineering-Praktiken welche rechtlichen Verpflichtungen unterstützen.

Wie funktionieren die Playbooks?

Das Playbook-Format

Abschnitt 4 ist der umfangreichste Teil des Dokuments. Er bietet KMUs einen praktischen, leichtgewichtigen Weg, Security by Design and Default zu implementieren, ohne eine schwerfällige Governance-Last zu erzeugen. Jedes Playbook destilliert ein einzelnes Sicherheitsprinzip in einen einseitigen, umsetzungsorientierten Leitfaden, den Teams wiederholbar über Releases und Produktlinien hinweg anwenden können (Abschnitt 4, S. 28).

Die Absicht: Sicherheitsprinzipien von abstrakten Bestrebungen in konkrete Engineering- und Betriebsmaßnahmen zu überführen, mit klaren Erwartungen, verifizierbaren Ergebnissen und einer konsistenten "Definition of Done" für Sicherheit. Jedes Playbook folgt demselben fünfteiligen Format:

• Prinzipname: Das umzusetzende Sicherheitskonzept
• Ziel: Was das Prinzip erreichen soll und welche Ausfallmodi es reduziert
• Checkliste: Die Maßnahmen mit dem höchsten Wirkungsgrad (so gestaltet, dass sie von schlanken Teams umgesetzt werden können)
• Mindestnachweis: Der kleinste Satz von Artefakten, Logs oder Konfigurationen, der belegt, dass die Checkliste umgesetzt wurde
• Release-Gate: Ein Copy-Paste-Set von Bestanden/Nicht-bestanden-Kriterien, das in einem Release-Review oder in CI/CD eingesetzt werden kann, um Regressionen zu verhindern

Die Playbooks in der Praxis

• Das Release-Gate jedes Playbooks als festen Tagesordnungspunkt bei Release-Readiness-Reviews behandeln
• Den Mindestnachweis wo immer möglich als Repository-Artefakte und CI-Ausgaben implementieren
• Ausnahmen nur mit dokumentierter Begründung, Verantwortlichem und Überprüfungsdatum zulassen
• Playbooks regelmäßig auf Basis von Incident-Erkenntnissen, Schwachstellentrends und Produktänderungen auffrischen
• Die Inhalte sind als Baseline zu betrachten, nicht als Endzustand. Bei der Produktentwicklung überprüfen und aktualisieren.

Alle 22 Playbooks auf einen Blick

Architektonische Grundlagen:

Betriebliche Integrität:

Default-Hardening:

Geführter Schutz:

Praxisbeispiel: Playbook 4.13, Schwachstellen- und Patch-Management

Um die praktische Tiefe des Formats zu verdeutlichen, hier Playbook 4.13 in voller Detailliertheit wie im Dokument:

Prinzip: Schwachstellen- und Patch-Management soll praktisch, wiederholbar und nach Risiko priorisiert sein. Hersteller brauchen einen einfachen Weg, damit Kunden und Forscher Probleme melden können, sowie einen internen Prozess, um Befunde schnell zu triagieren und über dringende Maßnahmen zu entscheiden.

Ziel: Schwachstellen schnell genug identifizieren, priorisieren und beheben, um die reale Exposition zu reduzieren, über den eigenen Code, Abhängigkeiten, Infrastruktur und (falls zutreffend) Geräte/Firmware. Der Fokus liegt auf einem einfachen Intake-to-Fix-Workflow, klaren SLAs und einem Update-Mechanismus, der Patching zuverlässig macht.

Checkliste:

Mindestnachweis:

• Schwachstellen-Tracking-Board/Register: Problem, Schweregrad, betroffene Komponenten/Versionen, Verantwortlicher, Status, Zieldatum
• Definierte SLAs (Beispiel): Kritische Triage innerhalb von 48 Stunden, Behebung/Release-Ziel innerhalb von X Tagen (an die eigene Realität angepasst)
• Scanning-Nachweis: CI-Ausgaben für Abhängigkeits-Scanning und SAST (und DAST, falls zutreffend)
• Proaktive Abhängigkeits-Patches: SBOM oder Abhängigkeitsinventar je Release (mindestens für ausgelieferte Artefakte)
• Patch-Release-Protokoll: Verknüpfung vom Schwachstellen-Ticket zu PR(s) zu Tests zu Release-Version zu Rollout-Bestätigung
• Ausnahmen-Log: Akzeptierte Risiken haben Verantwortlichen, Ablaufzeit/Überprüfungsdatum und kompensierende Maßnahmen (falls vorhanden)

Release-Gate:

• Abhängigkeits- und SAST-Scans für das Release durchgeführt, kritische/hohe Befunde behoben oder dokumentierte Ausnahme (Verantwortlicher und Ablaufzeit)
• SBOM (oder Abhängigkeitsinventar) für das Release erstellt/aktualisiert und gespeichert
• Bekannte Schwachstellen in ausgelieferten Komponenten triagiert mit Schweregrad, Verantwortlichem und Zieldatum
• Patch-Prozess validiert: Fix reviewed, Tests bestanden, Release-Notes bei Bedarf aktualisiert
• Für internet-exponierte Komponenten: Mitigationen oder Patches für kritische/hohe Befunde vor dem Release vorhanden
• OTA/Update (falls zutreffend) auf sichere Auslieferung validiert, Rollback/Recovery dokumentiert
• Akzeptiertes Restrisiko ist zeitgebunden und bis zur Schließung oder zum Überprüfungsdatum nachverfolgt

Was sind Machine-Readable Security Manifests?

Abschnitt 5 des Playbooks führt ein neues Konzept ein: den Übergang von statischer, dokumentenintensiver Konformität zu maschinenlesbaren, verifizierbaren Sicherheits-Attestierungen.

Eine maschinenlesbare Sicherheits-Attestierung ist ein digitaler Anspruch in JSON oder YAML, der bestätigt, dass eine bestimmte Sicherheitsmaßnahme, ein Prozess oder eine Eigenschaft erfüllt wurde. Anders als statische PDF-Berichte können diese Attestierungen von automatisierten Systemen erzeugt und verarbeitet werden, was häufige Updates und automatisierte Validierung ermöglicht. In die Entwicklungspipeline eingebettet wird Sicherheit zum festen Bestandteil, kein nachträglicher Haken.

Vier Kerneigenschaften

• Demonstrierbarkeit: Proaktive Fähigkeit, maschinenlesbare Nachweise zu liefern, dass Sicherheitsanforderungen umgesetzt wurden, ein Übergang von "behaupten" zu "belegen"
• Verifizierbarkeit: Eine unabhängige Partei kann die Integrität von Sicherheitsansprüchen programmatisch authentifizieren und validieren, transparent, manipulationsresistent und an eine anerkannte Vertrauenswurzel gebunden
• Wiederverwendbarkeit: Bestehende Attestierungen als Grundlage nutzen, in den Entwicklungszyklus integrieren und in agile Qualitätsgates einbinden
• Zuverlässigkeit: Attestierungen für Third-Party-Due-Diligence nutzen und damit Supply-Chain-Vertrauen vereinfachen

Das Vier-Schichten-Modell

Das Playbook illustriert ein hierarchisches Datenmodell, bei dem jeder übergeordnete Sicherheitsanspruch durch granulare technische Nachweise unterlegt ist:

1. Metadaten und Attestierung (Identitätsdomäne): Produktidentität, Versionierung, kryptografische Signatur des Herstellers
2. Control Layer (Governance-Domäne): Strukturierte Sicherheitsziele, ausgerichtet an Anforderungen, Prinzipien und Vorschriften
3. Implementation Layer / Threat-Mitigation-Map (Betriebsdomäne): Ordnet spezifische Bedrohungen den umgesetzten Mitigationen, Design-Prinzipien, Standard-Einstellungen und menschenlesbaren Beschreibungen zu
4. Assessment und Verification Layer (Nachweisdomäne): Maschinenlesbare Bestanden/Nicht-bestanden-Ergebnisse aus automatisierten Gates mit Links zu SBOMs

Das Dokument beschreibt auch Zugriffskontrollschichten: ein Public-Facing JSON mit übergeordneten Ansprüchen und ein Restricted Technical Overlay mit verschlüsselten detaillierten Werkzeugkonfigurationen und Test-Telemetriedaten.

Bestehendes Ökosystem

Das Playbook ordnet MRSM in die bestehende Normenlandschaft ein:

• OSCAL (NIST): "Compliance as Code", standardisierte Sicherheitskontroll-Kataloge, System-Sicherheitspläne, Bewertungsergebnisse
• CycloneDX CDXA (OWASP/ECMA-424): Ursprünglich ein SBOM-Format, erweitert zu einem vollständigen Transparenzstandard. CDXA-Attestierungen für Sicherheitsansprüche, VEX für Ausnutzbarkeit, CBOM für kryptografische Assets
• OpenSSF: Security Insights (maschinenlesbare Sicherheitsfakten in YAML), Scorecard (automatisierte Best-Practice-Bewertung)
• OWASP ASVS: Application Security Verification Standard, zugrunde liegende Anforderungen. MLSVS als Erweiterung auf KI/ML
• TC54 (Ecma International): Transparency Exchange API, standardisiert die Auffindung und den Austausch von SBOMs und Attestierungen

Das SafeGate-X1-Praxisbeispiel

Das Dokument enthält ein vollständiges Szenario (Seiten 56-61), das zeigt, wie ein fiktiver Hardware-Controller-Hersteller MRSM implementieren würde: ein Threat Model mit 5 Bedrohungen (RCE über Web-API, Privilege Escalation, Port-Scanning, Credential Stuffing, Binary Tampering), Maßnahmen den Prinzipien zugeordnet, und ein JSON-Manifest, das zeigt, wie jede threat_id einem Prinzip, mitigation_control, secure_by_default_setting und verification_gate mit evidence_hash zugeordnet ist. Es enthält auch eine Third-Party-Verifikationstabelle, die zeigt, was Prüfer stichprobenartig überprüfen können.

Wie ordnen sich die Prinzipien den CRA-Anforderungen zu?

Anhang C des Playbooks stellt ein vollständiges Mapping aller 22 Prinzipien zu bestimmten wesentlichen Anforderungen aus CRA Anhang I bereit. Dies ist die Engineering-Brücke zwischen der Orientierungshilfe des Playbooks und den rechtlichen Verpflichtungen.

CRA Anhang I ist in zwei Teile gegliedert:

• Teil 1 (ANNEX-1.PT1): Produkt-Sicherheitsanforderungen, umfasst 14 Anforderungen: Cybersicherheits-Risikobewertung, sichere Defaults, Updates, Zugriffskontrolle, Datenschutz, Integrität, Datensparsamkeit, Verfügbarkeit, Angriffsflächen-Begrenzung, Incident-Mitigation, Logging und sichere Datenlöschung
• Teil 2 (ANNEX-1.PT2): Schwachstellen-Handhabungsanforderungen, umfasst 8 Anforderungen: SBOM, zeitnahe Behebung, Testen, Offenlegung, koordinierter VDP, Schwachstellen-Eingang, sichere Verteilung von Fixes und zeitnahe Weitergabe

Jedes Prinzip ordnet sich mehreren CRA-Anforderungen zu. Hier ausgewählte Beispiele aus Anhang C:

CRA-Bezug: Das Playbook ist keine rechtliche Compliance-Checkliste, aber es bietet die Engineering-Brücke zu CRA Anhang I. Wer die Einhaltung dieser 22 Prinzipien nachweisen kann, hat wesentliche Belege für die CRA-Konformitätsbewertung.

Was sollte man als nächstes tun?

1. Mit Abschnitt 2 beginnen: Die aktuelle Lifecycle-Phase identifizieren und die Lieferergebnisse aus Tabelle 1 erstellen. Schon eine einseitige Security-Kontextnotiz und ein grundlegendes Architekturdiagramm bringen mehr als die meisten Teams vorweisen können.

2. Die 8 Risikomanagement-Aktivitäten durchlaufen (Tabelle 2): Die meisten KMUs können die Ergebnisse in 1-2 konzentrierten Tagen erarbeiten. Mit Produktkontext, Asset/Schadensidentifikation und den Risikoakzeptanzkriterien beginnen.

3. Ein leichtgewichtiges Threat Model erstellen (Tabelle 3): Schon 2 Stunden mit dem Team, einem Whiteboard und STRIDE liefern umsetzbare Ergebnisse. Auf die 5-10 Missbrauchsfälle fokussieren, die am stärksten ins Gewicht fallen.

4. Die 3-5 Playbooks auswählen, die für das nächste Release am relevantesten sind und die Checklisten nutzen. Häufige Einstiegspunkte: 4.9 (Secure Coding), 4.13 (Schwachstellen-Management), 4.2 (Least Privilege), 4.16 (Restriktiver Erstzugriff).

5. Die Release-Gate-Kriterien als Agenda des Pre-Release-Security-Reviews nutzen. Das ist der schnellste Weg von "kein Security-Review-Prozess" zu "dokumentierten, wiederholbaren Security-Gates".

6. Das vollständige ENISA-Playbook herunterladen: Dies ist ein v0.4-Entwurf. Feedback während der Konsultationsphase einreichen.

Offizielle Quellen

• ENISA Security by Design and Default Playbook v0.4 (PDF)

Weiterführende Leitfäden

• CRA Product Classification Guide
• SBOM Requirements Under the CRA
• CRA Technical File (Annex VII) Guide
• CRA Vulnerability Reporting: The 24-Hour Rule
• CRA Conformity Assessment Decision Guide

Dieser Artikel dient ausschließlich Informationszwecken und stellt keine Rechtsberatung dar. Für spezifische Compliance-Beratung wenden Sie sich an qualifizierte Rechtsexperten.