Frederick Brooks hat vor vielen Jahren in seinem berühmten Artikel „No Silver Bullet“ [1] überzeugend darauf hingewiesen, dass das Entwerfen und Entwickeln von Software von Natur aus ein schwieriger Prozess ist. Die der Softwareentwicklung inhärente Komplexität lässt sich demzufolge, außer in Details, nicht vereinfachen. Mehrheitlich genießt dieser Standpunkt Akzeptanz: Falsche Hoffnungen, bahnbrechende Vereinfachungen der Abläufe durch eigenwillige, zeitweilig beliebte Ideen wie visuelle Programmierung, formale Verifikation und dergleichen zu erreichen, werden ad acta gelegt. Es gibt jedoch immer noch viele, die glauben, dass sie auf diesen Gebieten doch noch den Durchbruch erzielen könnten. Allerdings dauert es in der Regel nur wenige Jahre, bis die Praxis ihre Fantasien mit Fakten korrigiert, zum Beispiel dem Fortbestehen von Bugs, überzogenen Deadlines, technischen Unzulänglichkeiten und ähnlichem mehr. Brooks behält Recht: Es gibt kein und wird auch nie ein Wundermittel geben, um die oftmals quälende Komplexität in der Softwareentwicklung zu überwinden.

Wenn die Entwicklung von Software also ein im Wesentlichen schwieriger Prozess ist, dann ist die Entwicklung sicherer Software ein noch schwierigerer Prozess. Eine Tatsache, die die überwiegende Mehrheit der Ingenieure, Forscher, Manager und Wissenschaftler in der Industrie zweifellos bestätigt. Seit dem Aufkommen der Securityidee in der Softwareentwicklung ist die Gewährleistung der Sicherheit eines Systems immer eine der anspruchsvollsten Aufgaben. Es ist schwierig genug, sicherzustellen, dass die Software in jedem vorstellbaren Nutzungsszenario tatsächlich das tut, wofür sie entwickelt wurde. Noch anspruchsvoller ist es, dafür zu sorgen, dass sie darüber hinaus nichts anderes kann, als das, wofür sie konzipiert wurde. Doch trotz des hohen Anspruchs ist das die zentrale Aufgabe, vor der Entwickler und Unternehmen stehen, wenn sie eine sichere Software programmieren wollen.

Werden darüber hinaus die aktuellen Praktiken von DevOps und Continuous Integration/Continuous Delivery (CI/CD) in diese ohnehin schon herausfordernde Welt eingebracht, droht ein sicherheitsbewusster Softwareentwickler zu verzweifeln. Ist es überhaupt möglich, einen Entwicklungskontext, eine Kultur oder Prozesse zu etablieren, die uns ein hohes Maß an Vertrauen in die Sicherheit von Software geben, die in einer groß angelegten DevOps- und Continuous-Deployment-Umgebung hergestellt wird? Das ließe sich ein wenig mit einer Organisation vergleichen, die an dem Ausstoß hunderter Projekte gleichzeitig arbeitet, die sich zur selben Zeit kontinuierlich im Einsatz befinden oder befinden sollen. Außenstehende nähmen eine solche Organisation als reines Chaos wahr, bei dem eine sinnvolle Einbettung von Security schwer vorstellbar ist.

In den letzten Jahren konnte man viel darüber lesen, wie Automatisierung sowie organisatorische und kulturelle Transformation durch die Philosophie und die Prinzipien von Secure DevOps (oft auch SecDevOps oder DevSecOps) die Mittel bereitstellten, um eine sichere Systementwicklung zu ermöglichen. Obwohl diese Ideen und ihre Umsetzung keineswegs Wundermittel sind, haben sie die Sicherheit der Software, die in den Firmen entwickelt wurde, die sie vollständig und intelligent angenommen haben, nachweislich verbessert. Leider sind, wie in den meisten Lebensbereichen, signifikante Prozess- und kulturelle Veränderungen, wie sie von Secure DevOps gefordert werden, viel einfacher gesagt als getan. Die Herausforderung steckt oft in Details, die oft nicht diskutiert und in vielen Fällen nicht einmal verstanden werden, bis man versucht, eine solche Umwälzung umzusetzen.

Dennoch gibt es Lösungen, die sehr gut funktionieren. Tatsächlich lässt sich sogar feststellen, dass die Sicherheit von Software in der heutigen DevOps-Welt stärker sein kann als früher, als Programmierer mit dem Wasserfallmodell einen ausgezeichneten, organisierten Ansatz hatten. Es gibt eine Reihe von Elementen, die ineinandergreifen, um die Entwicklung sicherer Software zu ermöglichen, obwohl sie an jede Art von Umgebung angepasst werden müssen. Diese Elemente unterteilen sich in die Bereiche Menschen, Prozesse und Werkzeuge. Die grundlegendsten Teile der Lösung fallen in die Kategorien Menschen und Prozesse, während die technisch interessantesten in die Kategorie Werkzeuge fallen. Nachfolgend sollen allerdings die ersten beiden Themen betrachtet werden.

Der Kulturwandel der Softwareentwicklung
Die wichtigste Voraussetzung für Security in einer DevOps-Umgebung ist eine Kultur der Verantwortung und des Eigentums. Bei DevOps dreht sich alles darum, verantwortungsbewusst zu handeln und die künstlichen Grenzen zwischen Entwicklung und Geschäftsbetrieb zu durchbrechen. Das individuelle Team, das ein Softwareprodukt entwickelt, muss das Produkt von der Wiege bis zur Bahre vollständig besitzen. Sie müssen den Ideenprozess, das Design, die Implementierung, den Einsatz, den Betrieb und den Support kontrollieren, und außerdem – um DevSecOps gerecht zu werden – ebenfalls die Sicherheit des Produkts in ihrer Hand haben. DevOps funktioniert aufgrund dieser einfachen Tatsache: Die Menschen kümmern sich um die Dinge, für die sie verantwortlich sind. Wenn sie wissen, dass sie die Teilprojekteigentümer und für die Sicherheit ihrer Produkte verantwortlich sind, werden sie natürlich in den Schutz der Anwendungen investieren. Das ist keine reine Theorie, sondern eineruht auf Erfahrungswerten und einem Entwicklungskonzept, das sich seit fast zehn Jahren bewährt hat [2].

Das Vertrauen der Entwicklungsteams in die Sicherheit ihrer eigenen Produkte ist ein Schritt, den viele traditionelle Sicherheitsexperten jedoch nicht zu gehen bereit sind. Das ist vor allem darauf zurückzuführen, dass die meisten Sicherheitsexperten heute noch nach den alten Normen oder dem Prinzip „Sicherheit durch zentrale Kontrolle“ arbeiten. So wurden sie ausgebildet und in vielen Fällen ist es der natürliche Modus Operandi. Entwicklungsteams waren in der Vergangenheit bekanntermaßen nicht vertrauenswürdig; wenn es um die Sicherheit ging, sind diese Bedenken nicht gänzlich unbegründet.

Man konnte sich nicht darauf verlassen, dass die Programmierer ihre Systeme so entwerfen oder implementieren, dass sie einem Cyberangriff wirklich standhielten. Dafür gibt es zwei Hauptgründe. Erstens mussten sie nie vertrauenswürdig sein, denn das Securityteam war bislang dafür in der Verantwortung, dass die Produkte sicher waren, ebenso wie die Qualitätssicherung für die Qualität des Produkts sorgen muss. Diese Einstellung und die daraus resultierenden Auswirkungen auf die Software sind das grundlegende Thema, mit dem sich DevOps und DevSecOps befassen sollten und wollen. Zweitens, da Sicherheit nicht die Aufgabe der Entwicklung war, haben sich nur die Neugierigen unter ihnen intensiv mit diesem Aspekt beschäftigt. Ohne entsprechendes Wissen werden Entwickler oft unter dem Gesichtspunkt Sicherheit schlechte Designentscheidungen treffen.

Der Wechsel zu einem DevSecOps-Modell löst das Eigentumsproblem. Wenn ein Unternehmen jedoch diesen kulturellen Wandel durchläuft, muss es erkennen, dass ein tiefgehendes Wissen über Cybersicherheit eine Voraussetzung für die Produktentwicklung ist. Wenn das Team das Fachwissen nicht hat, kann niemand erwarten, dass es gute Entscheidungen trifft. Es reicht nicht aus, sie dafür verantwortlich zu machen, ohne ausreichend ausgebildete Sicherheitstechniker in jedes Team zu integrieren. Der Aufbau dieser Expertise ist keine triviale Angelegenheit.

Der Wandel in den Prozessen
Neben grundlegenden Veränderungen in der Entwicklungs- und Sicherheitskultur erfordert das Design sicherer Software auch eine Transformation der Prozesse. Sicherheit muss Teil des Software Development Lifecycles (SDLC) werden. Sie muss jedoch so implementiert werden, dass sie nicht zu einem Hindernis wird. Wenn Sicherheit für DevOps und Continuous Delivery and Deployment funktionieren soll, muss mit drastisch kürzeren Zyklen und drastisch erhöhter Bereitstellungsfrequenz gerecht werden. Vorbei sind die Tage der Reviewboards, die Stunden, Tage oder sogar Wochen für die Überprüfung benötigen, bevor sie einen Entwurf genehmigen. Das Produktteam kann nicht mehr auf die Sicherheit warten, um einen einwöchigen Penetrationstest durchzuführen, bevor es die Veröffentlichung der Software erlaubt. Diese langwierigen Prozesse haben keinen Platz mehr in der DevSecOps-Pipeline. Tatsächlich gibt es immer noch Platz für tiefgehende, zeitintensive Sicherheitsaktivitäten – aber nicht innerhalb der primären Pipeline, die das Rückgrat von CI/CD bildet.

Ein robuster, sicherer Entwicklungsprozess innerhalb eines DevSecOps-Kontexts wird mehrere wesentliche Elemente beinhalten. Diese Elemente sind notwendig, um einen effizienten und effektiven Prozess zu ermöglichen, ohne die Sicherheit zu beeinträchtigen:

1. extrem leichtgewichtige Design- und Architekturüberprüfungen in der Pre-Commit-Phase

2. Peer-Codereviews, die durch ein Automatisierungsframework durchgesetzt werden

3. automatisierte, statische Analyse, einschließlich Anwendung, Konfiguration, Infrastruktur und Build-/Deployment-Code

4. automatisierte Erkennung und Verfolgung von Schwachstellen in Open-Source-Software

5. Sicherheitstests, die vollständig in die entwicklerorientierte Struktur von Unit-, Integrations-, Akzeptanz- und Post-Deployment-Tests integriert sind

6. kontinuierliche und umfassende Überwachung der Produktion mit schneller Reaktionszeit

7. Out-of-Band-Tiefeninspektions- und Analyseprozesse, einschließlich Penetrationstests und periodischer, ganzheitlicher Überprüfungen

Einfaches Securitydesign und leichte Kontrollprozesse
Die Überprüfung der Software muss extrem unkompliziert sein und darf nicht länger als rund eine Stunde dauern. Eine Dokumentation sollte keine Voraussetzung sein, weil das einen übermäßigen Zeitaufwand bei der Vorbereitung erfordern würde. Eine solche Review wird sich auf relativ kleine Änderungen und Funktionen konzentrieren.

Zur Analyse der Sicherheit eines Systems aus Sicht eines Angreifers sollte ein Ansatz zur Bedrohungsmodellierung verwendet werden. Bei richtiger Anwendung müsste dies im Vergleich zu anderen Analysemethoden recht effizient sein. Es gibt eine Reihe von verschiedenen Ansätzen zur Bedrohungsmodellierung, wie zum Beispiel der assetzentrierte Ansatz. Der versucht, Bedrohungsakteure durch Angriffsvektoranalysen mit Assets zu verbinden. Die fünf Elemente in dieser Form der Bedrohungsmodellierung sind Vermögenswerte, Bedrohungsakteure, Bereiche des Vertrauens, Angriffsvektoren und Sicherheitskontrollen. Alternativ bietet Microsoft ein kostenloses Tool zur Bedrohungsmodellierung an. Dieses Werkzeug verfolgt einen ganz anderen Ansatz und verwendet Microsofts bekanntes STRIDE-Modell zur Analyse und Klassifizierung. Oftmals sind der Microsoft-Prozess und das Microsoft-Tool ein wenig zu kompliziert, um in dieser Phase des Prozesses komfortabel zu sein.

Peer-Reviews
Erfahrene Entwickler haben bereits von den Tugenden der Peer-Reviews gehört, die ihnen oft gepredigt wurden. Der Grund dafür ist einfach: Sie funktionieren. Trotz ihrer Einschränkungen sind sie eine der besten Methoden, um Fehler zu erkennen, vorausgesetzt, der Kollege, der die Überprüfung durchführt, ist ausreichend qualifiziert und motiviert.

In der DevSecOps-Welt sollen diese Sicherheitskontrollen allerdings durch automatisierte Mechanismen innerhalb der Pipeline ersetzt werden. Wir können die Qualität einer Überprüfung nicht über die Durchführung hinaus bestimmen. Allerdings können wir mit den richtigen Tools durchsetzen, dass der gesamte eingereichte Code von einem anderen Entwickler vor der Verwendung kontrolliert wird. Das hat Vorteile, die über die Sicherheit hinausgehen. Es kann auch zur Unterstützung von Audit- und Compliancefunktionen verwendet werden, um ein wirksames Äquivalent zur traditionellen Aufgabentrennung nachzuweisen. Wenn es richtig gemacht wird, wäre selbst im Rahmen von Continuous Deployment kein einzelner Entwickler in der Lage, eine Änderung der Produktion selbstständig voranzutreiben.

Automatisierte, statische Analysen
Die automatisierte, statische Analysen von Quellcode ist seit über einem Jahrzehnt ein Grundpfeiler der Softwaresicherheit und hat sich unabhängig von DevOps zu einer etablierten Best Practice entwickelt. Es wäre heutzutage grob fahrlässig, keine statische Codeanalyse einzusetzen, um Software vor der Verteilung zu überprüfen.

Innerhalb von DevSecOps gibt es einige Besonderheiten, die hervorgehoben werden müssen. Erstens muss die statische Analyse sehr schnell ablaufen. Ein gutes Ziel wären Zeiten unter zehn Minuten. Das Zeitlimit hängt im Einzelfall jedoch von der Toleranzstufe des Entwicklungsteams ab. Im Allgemeinen tolerieren die meisten DevSecOps-Teams keine lange andauernden Aufgabe innerhalb des Prozesses, da Builds den ganzen Tag über häufig vorkommen. Um sicherzustellen, dass die statische Analyse nicht über einen längeren Zeitraum läuft, ist eine sorgfältige Konfiguration und Abstimmung des Projekts innerhalb des Analysetools selbst erforderlich. Für die Fälle, in denen die Codebasis einfach zu groß oder komplex ist, sollten Out-of-Band-Analyseaufträge ausgeführt werden, die die Pipeline nicht von innen blockieren und den aktuellsten Status überprüfen.

Der zweite Punkt bei der statischen Analyse innerhalb der DevSecOps-Pipeline ist, dass für die Analyseergebnisse ein Risikoschwellenwert festgelegt werden muss, der bestimmt, ob die Pipeline fortgesetzt werden darf. Das ist notwendig, um sicherzustellen, dass die Ergebnisse der statischen Analyse nicht ignoriert werden können. Eine sehr einfache und übliche Schwelle ist, dass keine neuen, schwerwiegenden Probleme gefunden werden dürfen. Mit anderen Worten: Wenn eine neue Schwachstelle vom statischen Analysetool entdeckt wird, wird der Build gezwungen, abzubrechen und zu pausieren. Natürlich erfordert die Festlegung eines solchen Schwellenwerts, dass zuerst das Tool und der Vorgang angepasst werden, um sicherzustellen, dass False Positives auf ein Minimum reduziert und im Idealfall ausgeschlossen werden. Niemand will Builds aufgrund von False Positives neu aufrollen.

Ein dritter und letzter Punkt ist, dass die statische Analyse für den gesamten Code gelten sollte, nicht nur für den Anwendungscode. Das kann Infrastrukturcode (wenn das Konzept von Infrastructure as Code verwendet wird), Konfigurationscode und sogar den Code hinter der Build and Deploy Pipeline beinhalten. Es ist wahrscheinlich, dass mehr als ein statisches Analysetool benötigt wird, um jede Codeart abzudecken.

Open-Source-Schwachstellenverfolgung
Manche mögen argumentieren, dass dieses Thema Teil der statischen Analyse sein sollte, da die Open-Source-Software-(OSS-)Schwachstellenüberprüfung gegen eine statische Codebasis durchgeführt wird. Es sollte allerdings aus zwei Gründen getrennt voneinander betrachtet werden: Einerseits wird für die Analyse in der Regel ein eigenes Werkzeugt benötigt und andererseits ist die Bedeutung der OSS-Sicherheit aufgrund der großen Menge OSS in heutigen Softwaresystemen gestiegen. Die meisten Softwaresysteme, die von Unternehmen entwickelt und eingesetzt werden, enthalten heute einen achtzigprozentigen OSS-Anteil.

Sicherheitstests
Sicherheitstests müssen Teil der Entwicklung von Software werden, so wie Funktionstests seit vielen Jahren etabliert sind. Die Sicherheitstests müssen deshalb zu den Produktentwicklungsteams gehören, statt eigene, externe Einheiten zu bilden. Sicherheitstests sollten genauso behandelt werden wie Funktionstests, sodass nur die genaue Testart unterschiedlich ist. Spezifische Unit-Tests, Abuse-Case-Tests und End-to-End-Abnahmetests sollten von den Entwicklern in Zusammenarbeit mit den eingebundenen Sicherheitsingenieuren geschrieben werden, wobei der Schwerpunkt auf Sicherheitsfragen und nicht auf dem Erfolg liegt, die Funktionen tatsächlich zu erfüllen. Diese Tests sollten sicherstellen, dass Sicherheitskontrollen vorhanden sind und ordnungsgemäß funktionieren. Sie müssen gewährleisten, dass bekannte Schwachstellen nicht vorhanden sind und dass die spezifischen Bedrohungsszenarien, die sich aus der früheren Modellierung von Bedrohungen ergeben haben, durch die im System entwickelten und eingebauten Abwehrsysteme und Kontrollen bedacht werden.

Einige automatisierte Schwachstellenscans können zu diesem Zeitpunkt ebenfalls durchgeführt werden. Sie müssen jedoch sehr zielgerichtet sein und dürfen keine manuellen Eingriffe erfordern, um ordnungsgemäß ausgeführt zu werden. Intelligente und präzise Fuzzing-Tests für APIs sind ein möglicher Einsatzfall dieser Technologie in dieser Phase der Pipeline.

Eine kontinuierliche und umfassende Überwachung
Eine der Säulen der Sicherheit in einer DevOps-Umgebung ist die kontinuierliche, umfassende Überwachung, die eine schnelle Erkennung und Reaktion auf neue Schwachstellen und aktive Angriffe ermöglicht. DevOps/DevSecOps-Organisationen stellen typischerweise mehrmals täglich neuen Code bereit, wenn auch mit einem etwas geringeren Sicherheitsaspekt, in Bezug auf Designreviews und Deep-dive-Sicherheitstests. Bei diesem Ansatz ist es wichtig, dass die Organisation in der Lage ist, anomales Verhalten innerhalb des Systems sofort zu erkennen und extrem schnell darauf zu reagieren. Das ist Teil der Strategie des Verteidigungsbereichs und einer der Aspekte von DevSecOps, der es den Unternehmen, die nach einem echten DevSecOps-Modell arbeiten, ermöglicht, legitimiert zu behaupten, dass ihre Systeme sicherer sind als beim Vorgehen beim traditionellen Wasserfallansatz.

Eine Studie von WhiteHat Security aus dem Jahr 2015 kam zu dem Schluss, dass die durchschnittliche Zeit, die Unternehmen zur Behebung schwerer Schwachstellen benötigen, 193 Tage beträgt [3]. Das bedeutet, dass das Zeitfenster für den Missbrauch von Schwachstellen auch nach der Entdeckung recht groß ist. DevSecOps verkürzt diesen Zeitraum drastisch, denn DevSecOps-Organisationen sind geübt darin, Änderungen in der Produktion sehr schnell umzusetzen.

Out-of-Band-Tiefenanalyse
Schließlich bleibt in DevSecOps ein Platz für die langwierigen Analyseaufgaben. Penetrationstests sind beispielsweise eine ressourcen- und zeitintensive Tätigkeit, die nicht für jedes Release durchgeführt werden kann. Vor allem, wenn sie täglich oder sogar mehrmals täglich freigegeben werden sollen. Die Rolle des Penetrationstests kann jedoch auch nicht durch die anderen Sicherheitsmechanismen und -prozesse innerhalb der Pipeline ersetzt werden. Daher ist die beste Strategie, Penetrationstests regelmäßig außerhalb des Pipelineflusses durchzuführen, ausgelöst durch ein steigendes Risikoniveau, das durch verschiedene Mittel bestimmt werden kann, wie z. B. kumulative Codeänderungen, architektonische und große Designänderungen oder signifikante Veränderungen in der Bedrohungslandschaft, die eine Bewertung aus einer neuen Perspektive erfordern.

Fazit
Es besteht kein Zweifel daran, dass die DevOps-Welt eine Reihe neuer, spannender Herausforderungen für die Sicherheit darstellt. Wenn man die Herausforderung jedoch mit einem offenen Geist annimmt und alle Optionen ganzheitlich aus einem risikobasierten Ansatz heraus bewertet, kommt man zu dem Schluss, dass es nicht nur Herausforderungen, sondern auch Chancen gibt. Softwaresysteme können gründlicher und robuster abgesichert werden als je zuvor. Die motivierende Kraft des Eigentums an der Produktsicherheit, die Leistungsfähigkeit der Automatisierung durch die DevSecOps Pipeline und eine Kultur, die die Fähigkeit zur schnellen Erkennung und Reaktion erfordert, sind vielversprechend für die Sicherung unserer Systeme, wenn wir sie richtig und in vollem Umfang nutzen.

Links & Literatur
[1] Brooks, Frederick P. Jr.: „No Silver Bullet“: http://faculty.salisbury.edu/~xswang/Research/Papers/SERelated/no-silver-bullet.pdf
[2] Puppet: „State of DevOps Report“: https://puppet.com/resources/whitepaper/state-of-devops-report
[3] WhiteHat Security: „Website Security Statistics Report“: https://info.whitehatsec.com/rs/whitehatsecurity/images/2015-Stats-Report.pdf