Security by Design: Vom Nice-to-have zum Must-have
Die Anforderungen an die Cybersecurity waren nie höher. Es reicht daher nicht mehr aus, die Anwendungssicherheit als notwendiges Übel abzuhaken und irgendwo zwischen Entwicklung und Deployment anzusiedeln – Unternehmen brauchen eine Security-by-Design-Strategie. Cycode nennt die vier maßgeblichen Stufen auf dem Weg in den Sicherheitsolymp.
Der EU Cyber Resilience Act (CRA) und die EU Product Liability Directive, unter die mittlerweile auch Software fällt, zwingen Unternehmen, Anwendungssicherheit zur höchsten Priorität zu machen. Ein Security-by-Design-Ansatz ist somit kein Nice-to-have mehr, sondern ein Must-have. Das gelingt am besten in vier Schritten, wie Cycode im Folgenden zeigt:
1. Anwendungssicherheit als Grundprinzip definieren
Die Verantwortung für die Application Security (AppSec) allein auf die Schultern der Entwickler abzuladen, ist längst nicht mehr gangbar. Zeit- und Anforderungsdruck sind in Zeiten sich ständig verändernder Märkte enorm hoch, was die Entwicklungsabteilung oft dazu zwingt, den Sicherheitsaspekt stärker zu vernachlässigen als ihr lieb ist. Unternehmen müssen die Anwendungssicherheit daher als Grundprinzip festlegen. Das erfordert einen kulturellen Wandel, der nicht nur den Entwicklern mehr Sorgfaltspflicht vorschreibt, sondern auch die Anforderungen an die anderen Abteilungen verändert. Möglichst schnell und viele neue Funktionen zu erhalten, darf nicht mehr oberste Prämisse bei der Produktion von Software sein. Das ist das oberste Gebot eines Security-by-Design-Ansatzes: an erster Stelle steht AppSec.
2. Cross-Team-Kollaboration etablieren
Der zweite Schritt zu Security by Design ist ebenfalls in der Unternehmenskultur zu verorten. Während viele Abteilungen zentralisiert arbeiten, sind Entwicklerteams oft die verteiltesten überhaupt: Beschäftigt ein Unternehmen 100 Entwickler kommt es nicht selten vor, dass sie in 20 oder 30 verschiedenen Teams arbeiten. Es ist daher unabdingbar, dass die Cross-Team-Kollaboration sowie die abteilungs- und teamübergreifende Kommunikation einwandfrei funktionieren. Silos führen zu Fehlern und je später sie im Software Development Lifecycle (SDLC) entdeckt werden, desto teurer und aufwendiger ist es, sie zu beheben.
3. Compliance-Monitoring aufbauen und automatisieren
Um Security by Design erfolgreich umzusetzen, benötigen Unternehmen auch passende Richtlinien. Es ist ein hehrer Wunsch, Anwendungssicherheit zum Fundament des SDLC zu machen. Doch erst Compliance-Vorgaben und die möglichst automatisierte Überwachung, ob alle Stakeholder sie auch über den gesamten Prozess vom Schreiben der ersten Code-Zeile bis zum Live-Betrieb einhalten, ist essenziell. Entsprechende Richtlinien aufzustellen, sollte ein gemeinsames Bestreben der beteiligten Abteilungen sein. Dafür sind einerseits eine funktionale Kommunikation und die teamübergreifende Kollaborationsbereitschaft Grundvoraussetzung. Andererseits müssen die Stakeholder auch über die aktuell geltenden gesetzlichen Regelungen bestens Bescheid wissen.
4. Einblicke in die Sicherheitslage in Echtzeit erhalten
Wie es um die Anwendungssicherheit bestellt ist, können Unternehmen nur einschätzen, wenn sie ein komplettes Bild bekommen – und zwar bestenfalls in Echtzeit. Obwohl Security by Design in erster Linie einen kulturellen und regulatorischen Hintergrund hat, benötigen Unternehmen Sicherheitssoftware, um den Ansatz in die Praxis umzusetzen. Doch genau hier gibt es oft ein anderes Problem: Es sind oft schon zu viele Tools im Einsatz, die unabhängig voneinander betrieben und betrachtet werden. Eine ASPM (Application Security Posture Management)-Lösung hilft dabei, diese zusammenzuführen. Sie zeigt beispielsweise, welche Tools bereits im Einsatz sind, und stellt fehlende Funktionalität bereit. Gleichzeitig laufen in einer ASPM-Plattform alle relevanten Informationen in Echtzeit zusammen. Dadurch gelingt es Unternehmen leichter, Schwachstellen im Code nicht nur zu identifizieren, sondern diese kontextualisiert zu priorisieren. Gerade die Triage von Schwachstellen ist wichtig, denn nicht jeder Fehler im Code ist kritisch und nicht jeder kritische Fehler muss sofort behoben werden.