Praxisleitfaden zu „Security by Design and Default“ für kleine und mittlere Unternehmen
ENISA: Security by Design and Default Playbook
Vils, 15.04.2026 (PresseBox) - Mit dem „Secure by Design and Default Playbook“ konkretisiert ENISA, die Agentur der Europäischen Union für Cybersicherheit, erstmals, wie Hersteller von Produkten mit digitalen Elementen die Anforderungen des Cyber Resilience Act (CRA) technisch und organisatorisch umsetzen können.
Der Praxisleitfaden ist insbesondere an Software- und IoT-Hersteller adressiert und verfolgt das Ziel, Cybersecurity systematisch über den gesamten Produktlebenszyklus zu verankern. In der Kurzinformation von IBF Solutions GmbH haben wir die wichtigsten Inhalte des Dokuments kompakt zusammengefasst.
Welche Ziele verfolgt das ENISA Playbook und wie ist es aufgebaut?
Der ENISA-Ansatz basiert auf der konsequenten Integration von Security bereits in frühen Entwicklungsphasen, die in der technischen Terminologie auch als „Shift Left“ bezeichnet wird. Sicherheitsanforderungen beginnen somit nicht erst bei Tests oder im Betrieb, sondern bereits bei der Anforderungsdefinition, dem Architekturdesign und der Technologieauswahl. Dieser lebenszyklusorientierte Ansatz umfasst die Phasen Entwicklung, Bereitstellung, Betrieb, Wartung und Außerbetriebnahme.
Das sogenannte „Playbook“ strukturiert die Anforderungen in 22 Prinzipien, die in die Kategorien „Secure by Design“ und „Secure by Default“ unterteilt sind. Diese werden durch konkrete technische Maßnahmen, Nachweisanforderungen und Freigabekriterien umgesetzt.
Zu den zentralen technischen Anforderungen zählen standardisierte Bedrohungsmodellierung, sichere Softwarearchitekturen nach etablierten Prinzipien (zum Beispiel Least Privilege, Defense-in-Depth), sichere Standardkonfigurationen sowie kontinuierliches Schwachstellenmanagement. Ergänzt werden diese durch Anforderungen an Monitoring, Incident Response (Reaktion auf Zwischenfälle) und Wiederherstellungsfähigkeit. Dadurch wird Resilienz als integraler Bestandteil des operativen Betriebs verstanden. Ein innovatives Element ist das „Machine-Readable Security Manifest“ (MRSM). Es ermöglicht die strukturierte, maschinenlesbare Dokumentation von Sicherheitsmaßnahmen und deren Nachweis. Dadurch wird Compliance automatisierbar und skalierbar, was einen entscheidenden Schritt für die regulatorische Nachweisführung darstellt.
Neben technischen Maßnahmen betont die ENISA auch organisatorische Aspekte wie klare Verantwortlichkeiten, die Integration von Security in Produktentscheidungen und die Absicherung von Lieferketten. Sicherheit wird somit als interdisziplinäre Aufgabe zwischen Entwicklung, Betrieb und Management positioniert.
Insgesamt markiert das Playbook einen Paradigmenwechsel: Cybersecurity entwickelt sich von einer nachgelagerten Zusatzfunktion zu einem integralen, überprüfbaren Bestandteil des gesamten Produktlebenszyklus. Für Hersteller bedeutet dies nicht nur erhöhte regulatorische Anforderungen, sondern auch die Notwendigkeit, ihre Entwicklungsprozesse grundlegend neu auszurichten.
Die Kernaussage lautet: Cybersecurity ist ein kontinuierlicher Prozess und kein einmaliges Feature.
Welcher Zielsetzung dienen die 22 Sicherheitsprinzipien (principles)?
Das Playbook definiert 22 konkrete Prinzipien, die auf übergeordneter Ebene in „Secure by Design“ (14 Prinzipien) und „Secure by Default“ (acht Prinzipien) unterteilt sind.
Jedes der 22 Prinzipien wird in Kapitel 4 des ENISA-Dokuments (welches den Titel “Playbook” trägt) anhand der Kriterien Zielsetzung, technische Umsetzungselemente, Evidence (Nachweisanforderungen) sowie Release-Kriterien (Freigabekriterien) näher erläutert.
Ziel dieses Playbooks ist es, Sicherheitsprinzipien von der konzeptionellen Ebene in konkret umsetzbare Engineering- und Betriebspraktiken zu überführen. Dazu werden für jedes Prinzip klare Umsetzungsschritte sowie überprüfbare und verbindliche Kriterien definiert, sodass Security als integraler Bestandteil des Entwicklungsprozesses messbar und auditierbar wird.
Die 22 Prinzipien sind einheitlich strukturiert, um eine standardisierte und wiederholbare Anwendung zu ermöglichen.
- Prinzip: Konkretes Sicherheitskonzept (z. B. Härtung, Zugriffskontrolle, Updatefähigkeit).
Ziel: Was das Prinzip erreichen soll und welche Fehlerquellen es reduziert.
Checkliste: Die Maßnahmen mit der größten Wirkung, die umgesetzt werden sollen (so konzipiert, dass sie in schlanken/ kleinen Teams umsetzbar sind).
Mindestnachweis: Konkrete Evidenzen (z. B. Konfigurationsstände, Logs, Testergebnisse, SBOMs), die die Umsetzung der Maßnahmen belegen.
Freigabe-Kriterien: Formalisierte „Pass/Fail“-Kriterien, die in Release-Prozessen automatisiert geprüft werden können, zur Sicherstellung der Einhaltung des unveränderten Sicherheitsniveaus.
Im OT-spezifischen Architektur- und Netzwerkdesign steht die konsequente Segmentierung industrieller Systeme im Vordergrund. Grundlage bildet ein an die Normenreihe IEC 62443 angelehntes Zonen- und Conduit-Modell, das Anlagen in klar abgegrenzte Sicherheitsbereiche unterteilt und die Kommunikationsbeziehungen zwischen diesen gezielt steuert. Ergänzend dazu ist eine strikte Trennung von IT- und OT-Netzwerken erforderlich, um Bewegungen von Angreifern zwischen den Netzwerken zu verhindern und die Auswirkungen von Sicherheitsvorfällen zu begrenzen.
Die häufig angenommene physische Trennung („Air Gap“) darf dabei nicht als Sicherheitsgarantie betrachtet werden. Stattdessen müssen reale, notwendige Verbindungen – etwa für Wartung, Monitoring oder Datenintegration – explizit identifiziert und durch kontrollierte Übergänge abgesichert werden. Dies umfasst insbesondere den Einsatz von Firewalls, Protokoll-Gateways und überwachten Schnittstellen.
Ein besonderer Fokus liegt zudem auf der Absicherung von Fernzugriffen, die in industriellen Umgebungen unvermeidbar sind. Diese sollten ausschließlich über gehärtete Zugangsmechanismen erfolgen, etwa durch den Einsatz von VPN-Verbindungen in Kombination mit Multi-Faktor-Authentifizierung sowie dedizierten *Jump Hosts, um direkte Zugriffe auf kritische Systeme zu vermeiden.
*Jump Host ist ein speziell gesicherter Rechner, der als zentraler, kontrollierter Zugangspunkt dient, um sicher aus einem externen Netzwerk (z.B. Internet) auf interne, geschützte Systeme zuzugreifen
Warum ist die Bedrohungsmodellierung ein Pflichtprozess in der OT?
In OT-Umgebungen muss die Bedrohungsmodellierung als verbindlicher Bestandteil des Engineering-Prozesses etabliert werden. Dabei müssen typische, für industrielle Systeme spezifische Angriffsszenarien systematisch berücksichtigt werden. Dazu zählt insbesondere die gezielte Manipulation der SPS-/PLC-Logik, durch die physische Prozesse direkt beeinflusst werden können. Ebenso sind Risiken durch unsichere oder fehlkonfigurierte industrielle Kommunikationsprotokolle wie Modbus oder OPC UA zu adressieren, da diese häufig unzureichende Sicherheitsmechanismen aufweisen.
Ein weiteres wesentliches Angriffsszenario ist die laterale Bewegung über Engineering-Workstations. Diese fungieren oft als Brückensysteme zwischen IT- und OT-Netzen und stellen daher ein attraktives Ziel für Angreifer dar. Darüber hinaus gewinnen Supply-Chain-Angriffe, insbesondere im Kontext kompromittierter Firmware oder manipulierter Update-Mechanismen, zunehmend an Bedeutung.
Zentral ist dabei die Anforderung, dass die Bedrohungsmodellierung in der OT über klassische IT-Sicherheitsbetrachtungen hinausgeht, da sie zwingend auch die Auswirkungen auf physische Prozesse sowie auf sicherheitsgerichtete Funktionen (Safety) einbeziehen muss. Nur so lässt sich das tatsächliche Risikoprofil industrieller Systeme realistisch bewerten und wirksam adressieren.
Welche Rolle spielen Risikomanagement und operative Sicherheit im Gesamtkontext?
Das Playbook definiert acht zentrale Aktivitäten im Bereich Risikomanagement und operative Sicherheit. Diese müssen als kontinuierliche Prozesse etabliert werden. Dazu gehören insbesondere ein systematisches Schwachstellenmanagement zur fortlaufenden Identifikation und Behebung von Sicherheitslücken, klar strukturierte Incident-Response-Prozesse zur schnellen und koordinierten Reaktion auf Sicherheitsvorfälle sowie belastbare Backup- und Wiederherstellungsstrategien, um die Betriebsfähigkeit im Störfall sicherzustellen. Ergänzend dazu sind umfassende Maßnahmen für das Sicherheitsmonitoring und Logging erforderlich, um Angriffe frühzeitig zu erkennen und nachvollziehbar zu analysieren.
Zentral ist dabei das zugrunde liegende Verständnis von Resilienz: Diese wird nicht als Ziel in der Systemarchitektur definiert, sondern als operative Fähigkeit verstanden, die im laufenden Betrieb aktiv umgesetzt, überprüft und kontinuierlich verbessert werden muss.
Was ist das Machine-Readable Security Manifest (MRSM) und wie wird es zur Nachweisbarkeit eingesetzt?
Ein zentraler, innovativer Bestandteil des Leitfadens ist das Konzept des „Machine-Readable Security Manifest“ (MRSM). Dabei handelt es sich um einen Ansatz zur strukturierten, maschinenlesbaren Abbildung von Sicherheitsnachweisen. Das Ziel besteht darin, Sicherheitsanforderungen systematisch und nachvollziehbar zu dokumentieren.
Im Kern verknüpft das MRSM deklarative Sicherheitszusagen (Security Claims) mit konkreten technischen Evidenzen wie Konfigurationsdaten, Testergebnissen oder Protokollen. Dadurch entsteht eine belastbare und zugleich automatisierbare Grundlage für die Bewertung des Sicherheitsniveaus eines Produkts.
Ein wesentlicher Mehrwert liegt in der Unterstützung automatisierter Compliance-Prüfungen, etwa im Rahmen von Audits. Damit adressiert das MRSM ein zentrales Problem regulatorischer Anforderungen: die Bereitstellung einer überprüfbaren und zugleich skalierbaren Compliance-Dokumentation, die über rein statische oder manuelle Nachweise hinausgeht.
Wie werden im Playbook die Vorgaben des Cyber Resilience Act (CRA) konkret umgesetzt?
Im Anhang C des Playbooks wird eine direkte Zuordnung der 22 Sicherheitsprinzipien zu den Anforderungen aus Anhang I des Cyber Resilience Act (CRA) bereitgestellt. Daraus ergeben sich für Hersteller klare Verpflichtungen: Sicherheitsmaßnahmen müssen über den gesamten Produktlebenszyklus hinweg nachweisbar umgesetzt werden, Schwachstellen sind aktiv zu managen und Sicherheitsupdates sind kontinuierlich bereitzustellen. Somit wird Cybersecurity zu einer verbindlichen regulatorischen Anforderung und ist nicht länger optional.
Fazit
Das „Secure by Design and Default“-Playbook der ENISA liefert einen praxisnahen und zugleich strukturierten Rahmen, um Cybersicherheit systematisch in den gesamten Produktlebenszyklus zu integrieren. Besonders hervorzuheben ist die konsequente praktische Umsetzung von Sicherheitsanforderungen. Anstelle abstrakter Leitlinien stehen konkrete Maßnahmen, überprüfbare Nachweise und klare Freigabekriterien im Mittelpunkt.
Für Hersteller – insbesondere im Kontext des Cyber Resilience Act – bedeutet dies einen deutlichen Paradigmenwechsel. Sicherheit wird nicht mehr als ergänzende Maßnahme, sondern als integraler Bestandteil von Entwicklung, Betrieb und Organisation verstanden. Durch die Einführung standardisierter Prozesse wie Bedrohungsmodellierung, kontinuierliches Schwachstellenmanagement und automatisierbare Compliance-Nachweise können sowohl das Sicherheitsniveau als auch die Nachvollziehbarkeit erhöht werden.
Insbesondere für industrielle und OT-Umgebungen bietet das Playbook einen wertvollen Orientierungsrahmen, da es regulatorische Anforderungen mit realistischen betrieblichen Bedingungen verbindet. Gleichzeitig erfordert die Umsetzung eine enge Verzahnung von Engineering, Betrieb und Organisation sowie eine Anpassung bestehender Entwicklungs- und Betriebsprozesse.
Insgesamt schafft das ENISA-Playbook somit eine belastbare Grundlage, um Cybersicherheit effizient, nachhaltig und überprüfbar umzusetzen und zu verankern.
Download des Playbook
Die Version 0.9 (final draft) des ENISA Security by Design and Default Playbook können Sie über folgenden Link öffnen und herunterladen: ENISA Security by Design and Default Playbook
