In der heutigen Bedrohungslandschaft reicht es nicht mehr aus, Sicherheitsmaßnahmen nachträglich zu implementieren. Unternehmen und Softwareentwickler stehen vor der Herausforderung, IT-Systeme von Anfang an sicher zu gestalten. Dabei tauchen zwei Konzepte immer wieder auf: Security by Design und Security by Default. Beide Begriffe klingen ähnlich, verfolgen aber unterschiedliche Ansätze. Was genau steckt dahinter – und welches Konzept ist für die Praxis besser geeignet?
Was bedeutet „Security by Design“?
Security by Design bedeutet, dass Sicherheit von Anfang an als integraler Bestandteil in den Entwicklungsprozess eines Produkts, Systems oder einer Anwendung eingebaut wird. Sicherheitsanforderungen werden also nicht erst am Ende oder „on top“ bedacht, sondern fließen bereits in die Architektur und Planung ein.
Das bedeutet konkret:
- Risiken werden frühzeitig identifiziert (z. B. durch Bedrohungsmodellierung).
- Sicherheitsziele werden definiert und in Designentscheidungen umgesetzt.
- Es werden Mechanismen vorgesehen, die Missbrauch, Manipulation oder unbefugten Zugriff verhindern.
- Code wird sicher entwickelt, validiert und regelmäßig geprüft (z. B. durch Secure Coding Standards, automatisierte Tests, Penetrationstests etc.).
Beispiel: Eine Webanwendung wird so entworfen, dass sie Cross-Site-Scripting (XSS) und SQL-Injections von Beginn an verhindert, etwa durch konsequente Validierung und Escaping von Benutzereingaben.
Was bedeutet „Security by Default“?
Security by Default hingegen bezieht sich auf die Voreinstellungen eines Systems oder Produkts. Die Idee ist, dass ein System in der Standardkonfiguration bereits sicher ist, ohne dass der Benutzer selbst etwas anpassen oder konfigurieren muss.
Typische Prinzipien:
- Alle unnötigen Dienste sind deaktiviert.
- Zugriffsrechte sind restriktiv voreingestellt (z. B. „Least Privilege“).
- Kommunikationskanäle sind standardmäßig verschlüsselt.
- Unsichere Funktionen sind per Default deaktiviert.
Beispiel: Ein Router, der ab Werk mit deaktiviertem Fernzugriff, einem zufällig generierten Admin-Passwort und aktivierter Firewall ausgeliefert wird.
Gegensätze oder Ergänzung?
Auf den ersten Blick wirken die beiden Konzepte wie konkurrierende Ansätze. Tatsächlich ergänzen sie sich jedoch. Security by Design ist ein umfassender, strategischer Ansatz, der den gesamten Lebenszyklus eines Produkts oder Systems betrifft – vom Konzept bis zur Stilllegung. Security by Default ist ein operativer Aspekt davon: Es geht um die konkrete Umsetzung in Form sicherer Standardeinstellungen.
Man könnte sagen:
- Security by Design ist das „Warum“ und „Wie“.
- Security by Default ist das „Was“ – das sichtbare Ergebnis für den Nutzer.
Ein System, das Security by Design verfolgt, wird im Idealfall auch Security by Default umsetzen. Umgekehrt kann ein System mit sicheren Voreinstellungen aber trotzdem unsicher sein, wenn das zugrundeliegende Design Schwächen aufweist.
Was ist besser?
Diese Frage lässt sich nicht pauschal beantworten – es kommt auf den Kontext an. Dennoch lohnt sich ein Vergleich in mehreren Dimensionen:
| Kriterium | Security by Design | Security by Default |
|---|---|---|
| Zielgruppe | Entwickler, Architekten | Endnutzer, Admins |
| Zeitpunkt der Umsetzung | Früh im Entwicklungsprozess | Bei Auslieferung/Konfiguration |
| Flexibilität | Hohe Anpassungsfähigkeit | Eingeschränkte Wahlmöglichkeiten |
| Sicherheitswirkung | Strategisch, langfristig | Operativ, direkt sichtbar |
| Kosten/Nutzen-Verhältnis | Anfangs aufwendig, langfristig effektiv | Günstig implementierbar, aber begrenzt |
Fazit: Security by Design ist die Voraussetzung für nachhaltige Sicherheit. Security by Default ist ein praktischer Ausdruck davon – aber kein Ersatz.
Herausforderungen in der Praxis
Beide Konzepte klingen gut in der Theorie – doch in der Realität stoßen sie oft auf Widerstände:
1. Security by Design – zu teuer, zu komplex?
Entwickler stehen unter Zeitdruck, Budgets sind knapp, Sicherheitsanforderungen gelten als Hemmschuh für Innovation. Doch Sicherheitslücken im Nachhinein zu schließen ist meist teurer – und schadet dem Image.
Lösungsansatz: Agile Methoden wie „DevSecOps“ binden Sicherheitsaspekte frühzeitig in Entwicklungszyklen ein, ohne den Prozess zu verlangsamen.
2. Security by Default – zu benutzerunfreundlich?
Sichere Voreinstellungen sind nicht immer bequem. Ein System, das per Default alle Zugriffe blockiert, sorgt schnell für Frust. Viele Hersteller fürchten, dass zu restriktive Defaults Kunden abschrecken.
Lösungsansatz: Die Usability von Sicherheitsfunktionen muss verbessert werden. Nutzer sollten sicher agieren können, ohne technische Hürden überwinden zu müssen.
Rechtlicher Druck: Regulatorik setzt auf beide Konzepte
Mit dem Aufkommen von Regulierungen wie der EU NIS2-Richtlinie, der DSGVO oder dem geplanten Cyber Resilience Act der EU wird es für Hersteller und Betreiber immer wichtiger, beide Ansätze zu verfolgen.
- Die DSGVO schreibt etwa „Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen“ vor – was direkt Security by Design und by Default entspricht.
- Auch NIS2 fordert strukturelle Sicherheitsmaßnahmen, die frühzeitig in die Systeme eingebaut werden müssen.
Wer also nicht nur sicher, sondern auch compliant sein will, kommt an beiden Ansätzen nicht vorbei.
Fazit: Nicht entweder – sondern beides
Security by Design und Security by Default sind keine Alternativen, sondern zwei Seiten derselben Medaille. In der idealen Welt beginnt Sicherheit beim ersten Entwurf und setzt sich konsequent bis zum fertigen Produkt fort – mit Voreinstellungen, die auch ohne Expertenwissen schützen.
Unternehmen sollten daher:
- Sicherheit als Teil der Entwicklungsstrategie begreifen (Design),
- aber auch auf nutzerfreundliche und restriktive Standardeinstellungen setzen (Default).
Sicherheit ist keine Option – sie ist ein Gestaltungsprinzip.