Security by Design: Warum sichere Software nicht erst vor dem Go-live entsteht

Key Takeaways

• Security by Design ist eine Eigenschaft des gesamten Entwicklungs- und Betriebsmodells.
• Threat Modeling verbindet Risiken mit Anforderungen, Designentscheidungen und Tests.
• Sichere Standardlösungen verhindern, dass jedes Team wiederkehrende Security-Probleme selbst lösen muss.
• NIS2 und der Cyber Resilience Act machen risikobasierte und dokumentierte Sicherheitsprozesse zunehmend zum regulatorischen Muss.
• Früh berücksichtigte Sicherheit macht Aufwände planbarer und besser skalierbar.

Security by Design ist eine Systementscheidung

In vielen Projekten stehen zunächst Funktionen, Termine und Budgets im Mittelpunkt. Sicherheitsanforderungen werden ergänzt, wenn wesentliche Produktentscheidungen bereits getroffen wurden. Scanner, Penetrationstests und Checklisten bleiben wichtig. Sie können jedoch nicht verhindern, dass Risiken bereits durch grundlegende Architektur- und Designentscheidungen entstanden sind.

Security by Design beginnt deshalb mit Fragen wie: Welche Daten und Funktionen müssen geschützt werden? Wer darf darauf zugreifen? Wo überschreiten Daten oder Aktionen eine Vertrauensgrenze? Welche Auswirkungen hätte der Missbrauch einer Funktion? Und welche Sicherheitseigenschaften müssen unabhängig von einzelnen Implementierungsdetails gelten?

Diese strukturierte Auseinandersetzung wird häufig als Threat Modeling bezeichnet. Entscheidend ist, relevante Risiken früh zu erkennen und daraus Anforderungen, Architekturentscheidungen und Tests abzuleiten.

Ein Beispiel ist die Trennung von Fähigkeiten: Ein Dienst, der sensible Daten lesen darf, benötigt nicht automatisch unbeschränkten Zugriff auf externe Systeme. Ein Datei-Upload benötigt keine Ausführungsrechte. Je klarer solche Grenzen im Design definiert werden, desto weniger hängt Sicherheit davon ab, dass jede Komponente in jeder Situation korrekt reagiert.

Wiederkehrende Security-Entscheidungen sollten außerdem nicht in jedem Projekt neu gelöst werden. Zentrale Lösungen für Authentifizierung, Secrets Management, Logging oder sichere CI/CD-Pipelines schaffen sogenannte Paved Roads oder Golden Paths. Verbesserungen an diesen Standardwegen kommen vielen Anwendungen gleichzeitig zugute.

Der sichere Weg muss dabei einfach und gut unterstützt sein. Ist er zu kompliziert oder zu langsam, entstehen individuelle Sonderlösungen und schlimmstenfalls eine Schatten-IT außerhalb der vorgesehenen Plattform- und Governance-Prozesse.

Frühzeitige Sicherheit macht Aufwand planbarer

Oft genannte Kostenfaktoren von zehn, dreißig oder sogar hundert greifen zu kurz. Entscheidend ist weniger ein pauschaler Multiplikator als die Größe der betroffenen Änderungsfläche. Diese fällt bei Security häufig besonders groß aus, weil Sicherheit Architektur, Datenflüsse, Berechtigungen, Schnittstellen, Tests und Betrieb zugleich betrifft.

Vor der Implementierung betrifft eine Entscheidung möglicherweise nur eine Anforderung oder ein Architekturdiagramm. Später können zusätzlich Code, Datenmodelle, Tests, Dokumentation und Deployment betroffen sein. Nach dem Go-live kommen Patch-Verteilung, Support, Incident Response und regulatorische Pflichten hinzu.

Security by Design macht sichere Entwicklung daher nicht kostenlos. Der Vorteil besteht darin, notwendige Aufwände planbar in die Entwicklung zu integrieren und durch wiederverwendbare Komponenten auf mehrere Anwendungen zu verteilen.

Die Wirksamkeit solcher Investitionen sollte anhand von Ergebnissen bewertet werden. Die Anzahl von Scans, Reviews oder Threat Models zeigt zunächst nur Aktivität. Aussagekräftiger ist, ob relevante Risiken früher erkannt, unsichere Lösungen ersetzt und ganze Fehlerklassen reduziert wurden.

Vom Best Practice zum regulatorischen Muss

Security by Design ist längst nicht mehr nur eine freiwillige Best Practice. NIS2 verlangt von betroffenen Organisationen angemessene Maßnahmen zum Umgang mit Cyberrisiken. Dazu gehören Risikoanalysen, Sicherheit bei Beschaffung, Entwicklung und Wartung sowie Verfahren zur Bewertung der Wirksamkeit getroffener Maßnahmen.

Threat-Modeling-Ansätze wie STRIDE oder PASTA helfen, Risiken zu identifizieren, Maßnahmen abzuleiten und Entscheidungen nachvollziehbar zu dokumentieren. Werden Entwicklungs-, Freigabe- und Nachweisprozesse im unternehmensweiten ISMS verankert, lassen sich Verantwortlichkeiten und Risikoakzeptanzen konsistent steuern. Ein ISMS ersetzt jedoch nicht die produktbezogene Risikobewertung, sondern schafft den organisatorischen Rahmen für ihre Umsetzung.

Für Hersteller von Produkten mit digitalen Elementen wird der Cyber Resilience Act konkreter: Er fordert eine produktbezogene Cybersecurity-Risikobewertung über den gesamten Lebenszyklus und verlangt, dass die daraus abgeleiteten Maßnahmen nachvollziehbar umgesetzt und dokumentiert werden.

Damit verändert sich die Rolle der Dokumentation. Organisationen müssen zeigen können, welche Risiken sie identifiziert, welche Entscheidungen sie daraus abgeleitet und wie sie die Wirksamkeit der Maßnahmen geprüft haben.

Frameworks und Leitfäden helfen, diese Elemente in strukturierte Prozesse zu überführen. Der BSI IT-Grundschutz enthält mit CON.8 „Software-Entwicklung“ konkrete Anforderungen; die BSI TR-03185 ergänzt diese um Vorgaben für einen sicheren Software-Lebenszyklus. OWASP SAMM und das NIST Secure Software Development Framework unterstützen die organisatorische Ausgestaltung eines Secure Development Lifecycle. Welche Referenz sinnvoll ist, hängt vom Produkt und Einsatzgebiet ab; die Auseinandersetzung mit den tatsächlichen Risiken ersetzt sie nicht.

Auditfähigkeit entsteht daher nicht durch eine Dokumentationskampagne kurz vor einer Prüfung oder Markteinführung. Sie entsteht als Ergebnis eines konsequent angewandten Entwicklungsprozesses.

Sicherheit endet nicht mit dem Go-live

Auch eine sicher entwickelte Anwendung bleibt nicht automatisch sicher. Komponenten erhalten neue Schwachstellenmeldungen, Bedrohungen verändern sich und Systeme werden erweitert oder anders genutzt als ursprünglich geplant.

Security by Design muss deshalb mit sicherem Betrieb verbunden werden. Dazu gehören Patch- und Vulnerability-Management, Monitoring, Backup und Recovery, Incident Response sowie regelmäßige Überprüfungen der ursprünglichen Sicherheitsannahmen. Auch zentrale Plattformen, Libraries und Infrastrukturvorlagen müssen kontinuierlich gepflegt werden.

Ziel ist nicht nur eine Anwendung, die am Tag ihrer Einführung sicher ist, sondern ein Entwicklungs- und Betriebsmodell, das Sicherheit über den gesamten Lebenszyklus erhält.

Fazit: Sichere Entscheidungen müssen skalierbar werden

Security by Design bedeutet, Produkte, Plattformen und Prozesse so zu gestalten, dass sichere Entscheidungen zuverlässig und wiederholbar getroffen werden. Sichere Software entsteht nicht durch einen einzelnen Test kurz vor dem Go-live, sondern durch ein Entwicklungsmodell, in dem der sichere Weg zum normalen Weg wird und Entscheidungen nachvollziehbar belegt werden können.