Reifegrad der IT Security bestimmen DevSecOps-Maturity-Modell für mehr IT-Sicherheit

Das DevSecOps-Konzept, also die Verbindung aus Development, Security und IT-Operations, kann gefährliche Schwachstellen in Sicherheitsprozessen offenlegen. Vor der Einführung eignet sich ein Maturity-Modell zur Bestimmung des Status quo.

Das Konzept von DevOps, eine Wortzusammensetzung aus den Begriffen Development und IT Operations, soll im Sinne des Kundenerlebnisses die Geschwindigkeit und Qualität der Anwendungsentwicklung erhöhen. Doch mit wachsender Geschwindigkeit und Komplexität der Entwicklung entstehen auch neue Sicherheitsrisiken. DevOps-Teams entwickeln sich weiter und mit DevSecOps ist ein neuer Bereich entstanden, der bessere Sicherheitsmechanismen in den Software Developement Lifecycle (SDLC) integriert.

E-Book zum Thema

Das eBook „DevOps und Security“ erläutert die Unterschiede von DevSecOps, SecDevOps und DevOpsSec und befasst sich mit dem Warum und Wie.

eBook herunterladen

Obwohl DevSecOps die IT-Sicherheit erhöhen, ist ihre Einführung wenig bis gar nicht standardisiert. Hier kann das Maturity Model helfen, um Lücken in Sicherheitsprozessen zu identifizieren und DevSecOps im Unternehmen erfolgreich voranzutreiben.

Einblicke in Sicherheitsprozesse

Meine Erfahrung in der Entwicklung von DevOps- und nun eben auch DevSecOps-Praktiken hat ein paar grundlegende Erkenntnisse über den Security-Bereich zutage gefördert.

So kann Sicherheit schnell zu einem Engpass im Bereitstellungsprozess neuer Software werden, da DevOps-Teams meist schneller arbeiten als ihre Kollegen in der IT-Sicherheit. Bessere Sicherheitskontrollen sind daher bereits in der Entwicklung notwendig, um die Softwarebereitstellung zu beschleunigen und das Risiko von Anwendungsschwachstellen zu minimieren. Schon heute werden Sicherheits-Teams viel früher in den SDLC eingebunden als noch vor einigen Jahren.

Es bleibt jedoch das Problem, dass Sicherheitsteams oft isoliert sind. Sie verwenden häufig andere Tools, Prozesse und eine andere Terminologie als DevOps-Bereiche, was die Einbindung von Sicherheitspraktiken in bestehende Entwicklungsabläufe erschwert.

Ausgereifte DevOps-Praktiken beschleunigen die Bemühungen, DevSecOps voranzutreiben. Aber selbst Unternehmen, die bereits über einen hohen Reifegrad verfügen, finden immer wieder erhebliche Lücken in der Transparenz der Anwendungssicherheit, etwa einen Mangel an klar definierten Metriken, die in jedem Team zugänglich sind.

DevSecOps Kompetenzen

Folgende Kompetenzen sind von Bedeutung für den Aufbau von DevSecOps-Prozessen und der eigenen DevSecOps-Reife. Wenn Verantwortliche verstehen, wie sich diese Kompetenzen auf ihr Unternehmen und den SDLC auswirken, können sie den DevSecOps-Prozess entmystifizieren und die richtigen Schritte in Richtung organisatorischer Reife einleiten.

Kultur: Die Kultur eines Unternehmens ist ein wichtiger Bestandteil beim Aufbau ausgereifter DevSecOps-Prozesse. Hier sollte im Sinne der Kommunikation auf die Beseitigung von Silos gesetzt und eine regelmäßige Kommunikation zwischen den beteiligten Teams gefördert werden. Im Onboarding müssen Unternehmen zwingend darauf achten, dass neue Teammitglieder sich schnell in die Entwicklungsprozesse einarbeiten können. Die Verantwortlichen sollten zudem eine Kultur pflegen, die Teams ermutigt, transparent zu agieren und die Verantwortung für Entscheidungen zu übernehmen

Planung und Entwicklung: Die Idee von DevSecOps ist es, Sicherheitsüberlegungen in die Planungs- und Entwicklungsphasen des SDLC zu verlagern. So haben die Teams genügend Zeit, um angemessene Sicherheitsmaßnahmen zu implementieren und das Risiko zu verringern, dass Schwachstellen erst beim Kunden auftreten. Vor allem, da Sicherheitsschwachstellen in späteren Phasen des SDLC schwieriger zu beheben sind, da diese oft eine grundlegende Änderung der Anwendungsarchitektur erfordern, für die nicht genügend Zeit zur Verfügung steht.

E-Book zum Thema

Das eBook „DevOps und Security“ erläutert die Unterschiede von DevSecOps, SecDevOps und DevOpsSec und befasst sich mit dem Warum und Wie.

eBook herunterladen

Es gilt vor allem die Punkte Risikobewertung, Technical Dept Management, Priorisierung und Code-Validierung zu berücksichtigen. Unternehmen sollten beim Entwurf neuer Funktionen umfassende Risikobewertungen und Bedrohungsmodelle erstellen. Sie sollten Designentscheidungen treffen, die die möglichen Konsequenzen schlechter technischer Umsetzung von Software, man spricht von Technical Dept, minimieren. Das beinhaltet das Aufsetzen von Prozessen für die Priorisierung von Funktionen und Fehlern sowie eine regelmäßige Überprüfung der Qualität und Sicherheit von neuem Code durch Validierungsprüfungen, die in den Entwicklungsprozess integriert sind.

IT-Sicherheit in der Industrie 4.0

Tipps zur Risikominimierung: Sicherheitskonzepte fürs IIoT

Erstellen und Testen: Neue Funktionen können während der Code-Feinabstimmung längere Zeit in der Erstellungs- und Testphase verbringen, um Bugs und Probleme mit der Benutzerfreundlichkeit zu beheben. DevSecOps-Praktiken definieren in dieser Phase, wie Sicherheitsschwachstellen oder Designmängel behandelt werden und ihnen entsprechende Priorität eingeräumt wird. Um die eigene DevSecOps-Reife abzuleiten, sollte in diesem Bereich die Qualitätssicherung und Testautomatisierung unter die Lupe genommen werden. Überprüfen routinemäßig verschiedene Arten von automatisierten Tests die Funktionalität? Gibt es ein regelmäßiges Code-Scanning, um Schwachstellen und andere damit verbundene Probleme aufzudecken? Wie sieht es mit der Build-Validierung aus? Werden neue Builds anhand von Sicherheits- und Entwicklungsrichtlinien verifiziert?

Release und Bereitstellung: Eine Bereitstellungsstrategie sollte dabei helfen, Code mit weniger Zwischenfällen oder Konfigurationsfehlern freizugeben und gleichzeitig schnell auf Probleme zu reagieren, die im Rahmen einer Freigabe auftreten. Das DevSecOps Maturity Model empfiehlt die Überprüfung der folgenden Bereiche, um festzustellen, wie gut Ihre Teams die Bereitstellung verwalten: Bereitstellungsautomatisierung von Code in der entsprechenden Umgebung, um Benutzerfehler oder Fehlkonfigurationen zu minimieren; Durchführung von Sicherheits- und anderen Validierungsprüfungen vor einer neuen Bereitstellung; Automatische Rücknahme von Code-Änderungen, die die Funktionalität beeinträchtigen oder eine Sicherheitsschwachstelle aufdecken

Operativer Betrieb: Die folgenden Aspekte stellen sicher, dass die richtige Infrastruktur für eine Anwendungen gewählt wurde. Im Plattformmanagement sollte die Nutzung von Infrastructure as Code zur automatischen Verwaltung von Sicherheitskonfigurationen und -ressourcen zum Tragen kommen. Ressourcenkapazitäten sollten auf den täglichen Ausgaben und dem saisonalen Wachstum geplant werden und eine automatische Skalierung der Ressourcen sollte möglich sein, um schwankende Nachfragen abzudecken und Angriffe, zum Beispiel DDoS-Attacken, problemlos abzufangen.

Im Sinne der Zuverlässigkeit sollten Ressourcen in mehreren Verfügbarkeitszonen und Regionen gehostet sein. Regelmäßige Ausfallsicherheitstests mit automatisierten Chaostests überprüfen die Infrastruktur, während ein automatisierter Patching-Prozesses Schwachstellen identifiziert und hilft, diese zu beheben. Und letztlich braucht es einen Disaster Recovery-Plan für die Wiederherstellung von Infrastrukturressourcen im Ernstfall.

Beobachten und Reagieren: In den letzten Phasen des SDLC müssen Unternehmen in der Lage sein, Probleme wie neue Schwachstellen und Bedrohungen nach der Bereitstellung in der Produktion zu überwachen und zu beheben. Hier sollten Unternehmen entsprechende Service Level Objectives (SLOs) und Fehlerbudgets verwenden, um technische Entscheidungen zu treffen und die Zuverlässigkeit ihrer Dienste zu messen. Sie sollten in der Lage sein, ihre Infrastruktur regelmäßig zu scannen, um Schwachstellen und Fehlkonfigurationen von Diensten aufzudecken. Das beinhaltet auch eine Überwachung von Sicherheits-KPIs, die dienstübergreifend messbar sind. Ebenso sollten Benutzerfreundlichkeit und Performance der Anwendung im Blick behalten werden. Den Abschluss macht das Incident Management und Postmortems. Hier gilt es eine umfassende Ursachenanalyse mit detaillierten Runbooks für das Management von Incidents zu fördern.

Lücken erkennen

Sind DevSecOps-Praktiken erst ausgereift, ziehen sie eine erhebliche Verbesserung der allgemeinen Sicherheitslage und eine beschleunigte Produktentwicklung nach sich. Die hier genannten Themenfelder sind Best Practices für die Einführung von DevSecOps. Die Bewertung des aktuellen Stands in jeder dieser Bereiche ermöglicht Unternehmen den Übergang von DevOps-Methoden zu ausgereifteren DevSecOps-Verfahren. So können Lücken identifiziert und die notwendigen Pläne zur Weiterentwicklung in jedem dieser Zweige umgesetzt werden, etwa die Einführung neuer Tools, Schulungen und Teams zur Unterstützung des Übergangs.

E-Book zum Thema

DevOps und Security

Sicherheit sollte eng mit den DevOps-Prozessen integriert und gleich zu Beginn der Entwicklung berücksichtigt werden. Die Frage lautet, wie man eine Veränderung am besten umsetzt, die Organisation und die Unternehmenskultur betrifft.

Dieses eBook umfasst die folgenden Themen:

• Wozu DevOps um Security erweitern?
• DevSecOps, SecDevOps und DevOpsSec
• DevSecOps: So geht es in der Praxis

eBook „DevOps und Security“ herunterladen

(ID:47918617)