Thought Leadership
Es ist bereits zehn Jahre her, dass Entwickler anfingen, DevOps-Praktiken in ihre Arbeitsprozesse zu integrieren, um im Sinne des Kundenerlebnisses die Geschwindigkeit und Qualität der Anwendungsentwicklung zu erhöhen. Seitdem ist viel passiert.
Entwicklungsprozesse werden immer schneller und komplexer, und es entstehen immer neue Sicherheitsrisiken. Mittlerweile lautete die Frage nicht mehr, ob, sondern wann man Opfer einer Cyberattacke wird. Das Sicherheitsrisiko ist real, egal ob für Unternehmen oder Verbraucher. Jede Schwäche in der Anwendungsarchitektur oder Entwicklungsprozessen wird ausgenutzt. Die Lösung, um diesen Gefahren immer einen Schritt voraus zu sein, heißt DevSecOps.
Mit DevSecOps sind neue Prozesse entstanden, die bessere Sicherheitsmechanismen in den Software Development Lifecycle (SDLC) integrieren. Die Einführung dieser Prozesse ist bisher leider wenig bis gar nicht standardisiert, daher ist es hilfreich, einen Blick auf die DevSecOps-Basic zu werfen.
Selbsteinschätzung ist der Schlüssel
Teil dieser Basics sind Kernkompetenzen, die entscheidend für die Entwicklung der DevSecOps-Reife eines Unternehmens sind. Verantwortliche müssen begreifen, wie sich diese Kompetenzen auf ihr Unternehmen und den SDLC auswirken, und bewerten, wie stark diese im eigenen Unternehmen bereits ausgeprägt sind. Erst wenn sie DevSecOps im Kern verstehen, können sie beginnen, die richtigen Schritte zu dessen Einführung in die Wege zu leiten.
Silos aufbrechen und Zusammenarbeit stärken
DevOps-Teams arbeiten oft schneller als die Kollegen in der IT-Sicherheit, was schnell dazu führen kann, dass Sicherheit zu einem Engpass im Bereitstellungsprozess neuer Software wird. Sicherheits-Teams werden daher schon viel früher in den SDLC eingebunden als es noch vor ein paar Jahren üblich war, doch oft arbeiten sie noch immer sehr isoliert. Sie verwenden andere Tool, Prozessen und eine andere Terminologie als ihre DevOps-Kollegen, was die Einführung neuer Sicherheitspraktiken deutlich erschwert.
Eine regelmäßige Kommunikation zwischen den Teams muss gefördert und Sicherheitsmetriken definiert werden, die allen Beteiligten zugänglich sind. Unternehmen sollten eine Kultur pflegen, die Teams ermutigt, transparent zu agieren und Verantwortung für Entscheidungen zu übernehmen, und die es neuen Teammitgliedern ermöglicht, sich schnell in die Entwicklungsprozesse einarbeiten zu können.
Früh getestet ist halb gewonnen
Ein wichtiges Ziel von DevSecOps ist es zu verhindern, dass mögliche Fehler und Schwachstellen von Anwendungen zu spät erkannt werden. Um das zu verhindern, sollten Sicherheitsüberlegungen und -tests in die Planungs- und Entwicklungsphasen, also an den Anfang des SDLC verlagert werden. So bleibt den Teams ausreichend Zeit, angemessene Sicherheitsmaßnahmen zu implementieren. In späteren Phasen sind Sicherheitsprobleme oft deutlich schwieriger zu beheben, da dafür häufig eine grundlegende Änderung der Anwendungsarchitektur erforderlich ist.
In den frühen Entwicklungsphasen gilt es besonders die Risikobewertung neuer Funktionen, Technical Dept Management, die Priorisierung von Funktionen und Fehlern sowie die regelmäßige Überprüfung der Qualität und Sicherheit von neuem Code zu berücksichtigen. Um Bugs und Probleme mit der Benutzerfreundlichkeit zu beheben, können neue Funktionen während der Code-Feinabstimmung auch längere Zeit in der Erstellungs- und Testphase verbringen, wo anhand von DevSecOps-Praktiken definiert wird, mit welcher Priorität Sicherheitsschwachstellen oder Designmängel behoben werden.
Durch wiederholtes Code-Scanning können Schwachstellen und damit zusammenhängende Probleme ausfindig gemacht und schnell behoben werden. Auch neue Builds sollten stets durch Sicherheits- und Entwicklungsrichtlinien verifiziert werden. Um Benutzerfehler oder Fehlkonfigurationen zu minimieren, sollte der Code im Rahmen einer Freigabe automatisch in der Produktivumgebung bereitgestellt werden. Etwaige fehlerhafte Änderungen müssen automatisch überarbeitet werden, und vor jeder Bereitstellung muss eine erneute Prüfung erfolgen. So steht der Freigabe von qualitativ hochwertigem und sicherem Code nichts mehr im Wege.
Sicher von Anfang bis Ende
Die Basis für eine sichere, zuverlässige Anwendung ist eine durchdachte, stabile Infrastruktur. Diese muss angemessene Sicherheitsmaßnahmen enthalten, wie ein Plattformmanagement, das Infrastructure-as-Code zur automatischen Verwaltung von Sicherheitskonfigurationen und -ressourcen nutzt. Ressourcenkapazitäten sollten anhand der täglichen Ausgaben und des saisonalen Wachstums geplant werden und eine automatische Skalierung der Ressourcen sollte möglich sein, um schwankende Nachfragen abdecken und mögliche Angriffe wie DDos-Attacken problemlos abfangen zu können.
Um zuverlässiges Arbeiten gewährleisten zu können, sollten Ressourcen in mehreren Verfügbarkeitszonen und -regionen gehostet werden, und die Ausfallsicherheit der Infrastruktur muss regelmäßig durch automatisierte Chaostests überprüft werden. Ein automatisierter Patching-Prozess hilft dabei, Schwachstellen zu identifizieren und zu beheben, und schlussendlich muss ein Disaster Recovery-Plan erstellt werden, um im Ernstfall die Wiederherstellung von Infrastrukturressourcen zu gewährleisten.
Nach der Bereitstellung muss der Code weiterhin konstant überwacht werden, denn es können immer neue Probleme auftreten. Dienstübergreifend messbare Sicherheits-KPIs, eine zentrale Plattform zur Überwachung von Leistung und Benutzerfreundlichkeit, sowie umfassende Problem- und Ursachenanalysen helfen beim Incident Management, sowohl bei aktuellen als auch bei zukünftigen Projekten.
Die Einführung von DevSecOps und das kontinuierliche Arbeiten an internen Prozessen sorgt nicht nur dafür, dass sich die allgemeine Sicherheitslage in Unternehmen verbessert und hochwertigere Anwendungen entwickelt werden. Auch der Zusammenhalt der Teams sowie transparentes Arbeiten werden gefördert. Unternehmen verschaffen sich einen Wettbewerbsvorteil gegenüber der Konkurrenz und können ihren Kunden einen größeren Mehrwert, mehr Zuverlässigkeit und noch höhere Sicherheitsstandards bieten, als es schon vorher der Fall war.
