REDPIXEL - stock.adobe.com
DevSecOps: Mehr Sicherheit für die Applikations-Entwicklung
Viele Unternehmen setzen bei der Entwicklung eigener Anwendungen auf DevOps. Damit aber nicht die Sicherheit auf der Strecke bleibt, empfiehlt sich ein Umstieg auf DevSecOps.
Softwareentwickler müssen sich mit vielen Themen beschäftigen, wenn es darum geht, ihre Fähigkeiten und Kenntnisse auf dem aktuellen Stand zu halten. Immer wieder werden integrierte Entwicklungsplattformen um neue Funktionen erweitert. Programmiersprachen entwickeln sich ebenso wie die dabei verwendeten Methoden weiter.
Ein Beispiel dafür ist etwa der sogenannte Wasserfall. Bei diesem linearen Modell erfolgt die Entwicklung in direkt aufeinander folgenden Projektphasen. Aber das ist noch nicht alles. Neben der Auffrischung und Erweiterung ihrer Kenntnisse müssen Programmierer natürlich auch noch ihre eigentlichen Aufgaben erfüllen und ihre Projekte rechtzeitig und innerhalb der vorgegebenen Budgets abliefern. Außerdem müssen sie nicht nur sicheren Code erstellen, sondern sich auch an zahlreiche Vorgaben halten.
Viele Entwickler verwenden mittlerweile das DevOps-Modell, bei dem die Programmierung und der Betrieb von Anwendungen unter einem gemeinsamen, automatisierten Dach untergebracht werden. Dadurch erfolgen neue Releases weit häufiger und zugleich regelmäßiger als früher.
Außerdem wird die Stabilität der erzeugten Anwendungen erhöht. Auf der anderen Seite wird es dadurch für Security und Compliance Monitoring Tools schwieriger, alle Änderungen zu kontrollieren. In der Regel wurden sie nicht darauf ausgelegt, neuen Code in der Geschwindigkeit zu testen, wie es mit DevOps nötig ist. Security gilt deswegen als eines der größten Hindernisse für eine beschleunigte Entwicklung von Anwendungen. Das hat leider auch dazu geführt, dass dem Thema Sicherheit in DevOps-Umgebungen nicht immer ausreichend Aufmerksamkeit geschenkt wurde. Dieses Denken ändert sich nun aber langsam.
Anwendungen von Anfang an sicher konzipieren
Auf lange Sicht gesehen, sind Anwendungen erheblich widerstandsfähiger gegen Angriffe, wenn sie bereits von Anfang an mit dem Fokus auf ihre Sicherheit hin entwickelt wurden. Damit lassen sich aber auch potentiell verheerende Auswirkungen auf die täglichen Abläufe leichter verhindern. Das ist der Grund, warum die noch relativ junge DevSecOps-Bewegung so wichtig ist. Entwickler müssen verstehen, wie bedeutend sie für ihre Arbeit ist und wie sie damit ihre Produkte verbessern können.
Ryan O'Leary, früherer Chief Security Research Officer bei WhiteHat Security, formuliert es so: „Ein typischer Kunde benötigt 174 Tage, um eine Schwachstelle zu reparieren, die bei einer dynamischen Analyse der Produktionssysteme gefunden wurde. Wenn er jedoch bereits DevSecOps eingeführt hat, sinkt diese Zeit auf durchschnittlich nur noch 92 Tage.“ O’Leary ergänzt weiter: „Wenn wir uns Schwachstellen ansehen, die mit Hilfe einer statischen Analyse während der Entwicklung einer Software gefunden wurden, dann benötigt ein durchschnittliches Unternehmen zur Behebung 113 Tage, während DevSecOps-Firmen nur 51 Tage brauchen.“ Das entspricht einer Reduzierung um mehr als die Hälfte.
Beim DevSecOps-Konzept wird davon ausgegangen, dass jeder für Security verantwortlich ist. Bei der klassischen Incident Response sieht das noch anders aus, hier wird oft erst am Ende ein dediziertes Security-Team eingeschaltet. Wenn jedoch von Anfang auf Aspekte wie Automatisierung gesetzt wird, dann sinkt damit zum Beispiel auch die Chance von fehlerhaften Konfigurationen. Automatisierte Sicherheitsfunktionen wie Identity and Access Management (IAM), Abgrenzungen durch Firewalls und der regelmäßige Einsatz von Schwachstellenscannern können im gesamten DevOps-Lifecycle genutzt werden.
Mit dem Thema Sicherheit befasste IT-Verantwortliche sollten sich außerdem mit der kollaborativen Seite von DevOps befassen, um in Zukunft einen nahtlosen und zugleich transparenten Entwicklungsprozess zu erreichen. Um das sicherzustellen, müssen sich auch die Entwickler zunehmend mit dem Thema Sicherheit in allen ihren Entscheidungen und im gesamten Lebenszyklus der von ihren produzierten Anwendungen auseinandersetzen.
Programmierer müssen Sicherheitsprozesse verstehen
Aber das ist keine Einbahnstraße. Programmierer müssen aktuelle und auch künftig benötigte Sicherheitsprozesse verstehen und im gesamten Lifecycle nutzen. Dazu zählt natürlich auch, sich zu überlegen, welche Nachteile durch die zusätzlichen Sicherheitsaufwendungen entstehen.
Darüber hinaus muss überprüft werden, welche Maßnahmen bereits getroffen wurden, um für mehr Sicherheit bei der Entwicklung von Anwendungen zu sorgen. Dazu gehört auch die Frage, welche Werkzeuge und Fähigkeiten wirklich erforderlich sind oder noch hinzugefügt werden müssen? Beispielsweise muss untersucht werden, ob Entwickler spezielle Tools bereits während der von ihnen lokal durchgeführten Build-Prozesse einsetzen können, um nach Schwachstellen zu suchen, oder ob dieser Schritt erst während der Continuous Integration beziehungsweise dem Continuous Delivery Process erfolgen soll? Auch ist zu prüfen, ob bereits während jedem der Build-Schritte ein Sicherheits-Check durchgeführt werden kann?
Die meisten Unternehmen haben klare Vorstellungen von den Risiken, denen sie ausgesetzt sind – oder glauben das zumindest. Daraus ergeben sich Sicherheitsrichtlinien, die sie in der Regel bereits in der Vergangenheit entwickelt haben. Neu ist allerdings, dass diese Sicherheitsrichtlinien jetzt auch in die DevOps-Schritte eingeführt werden können, um den Übergang zu DevSecOps bewältigen zu können.
Aus diesen Gründen ist es nötig, die Teams für Entwicklung, Security und den Betrieb der Infrastruktur enger zusammenzuführen, um die Kommunikation zwischen ihnen zu erleichtern und um eventuell auftretende frühzeitig Schwierigkeiten aufzuräumen. Darüber hinaus ist es nötig, die gemeinsame Verantwortung für die IT-Sicherheit herauszuarbeiten und deutlich zu betonen.
Die Zeitspanne, die benötigt wird, um eine Schwachstelle zu beheben, ist ein gutes Maß, um die Effektivität Ihrer DevSecOps-Maßnahmen zu bewerten. Damit können Sie auch feststellen, wie agil das Security-Team vorgeht, wie es auf sicherheitsrelevante Vorfälle reagiert und welche Prioritäten dabei gesetzt werden.
