IT-StrategieDevSecOps – Die logische Weiterentwicklung der DevOps Kultur

Dieser Artikel erklärt die Entwicklung von der DevOps Kultur zur DevSecOps Kultur und zeigt dabei abstrakt auf, wie IT-Security in eine agile Organisation eingebunden werden kann. Dies ermöglicht es, die typischen Geschwindigkeitsvorteile von agilen Methoden auch unter Berücksichtigung von Security Themen effektiv zu nutzen und weiterentwickeln zu können.

Darüber hinaus beinhaltet dieser Artikel auch ein konkretes Beispiel für eine technische Einbindung von Security Tools in DevOps Prozesse. Er umfasst damit unsere Datadrivers Best Practices, die wir in Kundenprojekten sammeln und anwenden konnten.

Während das Thema DevOps in der IT vielerorts schon allgegenwärtig ist, trifft man auf das Wort DevSecOps recht selten, obwohl dieses eine naheliegende Weiterentwicklung der DevOps Kultur beschreibt. DevOps und DevSecOps sind Kofferwörter und haben die Eigenschaft, komplizierte Sachverhalte in ihrer kurzen und prägnanten Art und Weise allgemein verständlich wiederzugeben.

DevOps steht für den fachlichen Zusammenschluss von Development (engl. für Entwicklung) und Operations (engl. für Betrieb). Der Begriff soll zeigen, dass die klassische IT Vorgehensweise von „Plan – Build – Run“ nicht mit disziplinarisch getrennten Rollen umgesetzt werden kann, sondern interdisziplinarisch und fachbereichsübergreifend verstanden werden muss. Es handelt sich um einen kulturellen, fachlichen und organisatorischen Zusammenschluss, um auf die schnell wechselnden Anforderungen des Business und flankierenden IT-Services adäquat reagieren zu können.

Für die Entstehung eines Produkts stellen DevOps Engineers Automatisierungstools sowie grundlegende Services zur Verfügung, die für die Entwicklung notwendig sind. [1] [2] Um die Geschwindigkeit und die Dynamik von neuen Technologien nutzen zu können (z. B. Cloud, „Infrastructure as Code“ (IaC), etc.), werden Automatisierungs- und Provisionierungstools als Kernkomponenten für den DevOps Ansatz gesehen.

Abbildung 1 zeigt den organisatorischen DevOps Ansatz anhand eines immer wiederkehrenden Zyklus, in dem kulturelle, organisatorische und technische Faktoren ineinandergreifen.

Die Einbindung von sicherheitsrelevanten Tools wird hier nur rudimentär oder nur insoweit technisch und organisatorisch betrachtet, wie es dem allgemeinen Automatisierungsgedanken dienlich erscheint. Der Fokus liegt aus der DevOps Sicht auf dem zeitnahen und schnellen Provisionieren von Umgebungen. Eine vollumfängliche Sicherheitsbetrachtung, wie beispielsweise eine Bedrohungsanalyse der Services, wird aus der DevOps Sicht nicht erbracht. Dazu bedarf es der Einführung einer weiteren Perspektive, welche es erlaubt, das Sicherheitsbefinden zu schulen – die Perspektive der Security Engineers.

Für die Integration der Security Perspektive in DevOps Prozesse ist es nicht nur mit einer Einführung von neuen Security Techniken und Tools getan. Wie bei der Ein- und Umgewöhnung von der klassischen Software Entwicklung hin zu den agilen Methoden, muss der kulturelle und organisatorische Wandel vor der Technik stehen. Zuweilen können diese Änderungen aber auch simultan geschehen, wenn DevOps oder andere Methoden wie BizDevOps erfolgreich etabliert
und gelebt werden. [3]

Der Bedarf, Kollegen der Security konkret mit einzubinden, ergibt sich aus der Notwendigkeit des Wissenstransfers. Nur durch das kontinuierliche Einbeziehen der Security Engineers  kann das Wissen aus den Bereichen Security und Development & Operations barrierefrei ausgetauscht werden. Security Engineers werden dafür nicht nur bei der Sprint Planung oder beim Daily Stand-Up mit eingebunden, stattdessen nehmen sie in einem Team eine beratende und operative Rolle ein und unterstützen die DevOps Kollegen in Fragen der Security.

Daraus ergibt sich, dass nun Security Engineers mit speziellen Fähigkeiten benötigt werden. Sie müssen Sicherheitssysteme wie Next Generation Firewalls administrieren können und damit den klassischen Security Stack beherrschen, weiterhin aber auch Code, welcher ganze Infrastrukturen in Cloud Umgebungen beschreibt (Beispiel Terraform), lesen und verstehen können. Außerdem sollen sie Konfigurations-, Deployment- und Orchestrierungs-Sprachen verwenden können. Hier rücken die DevOps Engineers und Security Engineers vom technischen Spektrum und von den Kompetenzen her enger zusammen und ergeben zusammen eine neue Schnittmenge: DevSecOps Engineers.

Die Abbildung 2 zeigt ein recht komplexes Bild dieser Schnittmenge und verdeutlicht dennoch klar, dass  Security zu einem integralen Bestandteil in einer Organisationsstruktur wird, die auf Flexibilität und Dynamik (im Sinne von Time to Market) sowie auf Agilität (hinsichtlich Planbarkeit von operativen Tasks) setzt. Dennoch wird zugleich nicht auf Robustheit und Betriebsstabilität verzichtet.

In der Abbildung befinden sich die beiden Kästen „[SEC] Layer“ und „Automatisierte Security Tools“. Während der „[SEC] Layer“ den aufbauenden Teil der DevSecOps wie Code Review, System- und Application-Test beschreibt, verdeutlicht der Kasten „Automatisierte Security Tools“ den betrieblichen und operativen Bereich wie Überwachung und Scannen nach Schwachstellen der Umgebung. Mit diesem Modell können alltägliche sicherheitsrelevante Tätigkeiten durchgeführt und die Innovationskraft vorangetrieben werden.

Abbildung 2 – DevSecOps Ansatz – eigene Darstellung

Wenn die kulturellen und organisatorischen Machbarkeiten erkannt und mittels organisatorischer Methoden umgesetzt wurden, können auch technische Lösungen umgesetzt werden.

Enterprise Architekturen, die auf Microservices aufbauen und Container Technologien, welche komplette Laufzeitumgebungen schnell und effektiv zur Verfügung stellen, müssen nun technologisch überwacht werden. Dabei werden die etablierten OSI Schicht Architekturen und ihre klassischen Einsatzgebiete auf eine abstrakte Ebene gebracht, die Security als „Software-Defined“ bestimmen kann. Logische Entitäten kommunizieren über virtuelle und virtualisierte Kommunikationswege und verlassen somit die klassischen Absicherungsbereiche.

Auf der Applikationsebene werden Security Groups oder Security Endpoints mittels Programmcode („IaC“) und „Configuration as Code (CaC)“ spezifiziert und definiert. Diese können beispielsweise bei einem nächsten Release Zyklus ausgerollt und wirksam werden. Somit können Zugriffe zwischen Netzwerken ersetzt oder aufgehoben werden.

Wenn man nun also die Security als Fachabteilung aktiv mittels DevSecOps einbinden kann, erhält diese wieder mehr Kontrolle. Die Security wird zu einem zusätzlichen aktiven Akteur in der Release Pipeline (Stichwort Code-Review, Code-Scan, organisatorische Abstimmung, etc.). Mit den notwendigen Werkzeugen ausgestattet, agiert sie proaktiv (Stichwort selbständiger Pen-Test, Vulnerability Scan, Docker-Image Scan, Einhaltung von Policies, Sicherung von Kommunikationswegen, etc.), statt reaktiv.

Die Abbildung 3 zeigt eine mögliche aktive Einbindung von Security Engineers in einem DevOps Prozess mittels technischer Werkzeuge.

Im DevOps Prozess können unter der Verwendung von Containern logische Entitäten zeitnah provisioniert, kommissioniert und orchestriert werden, um damit einen Service anbieten zu können. Genauso schnell kann man diesen Service auch wieder deprovisionieren und dekommissionieren. Für beide Aktivitäten stellt sich die Frage, wie sie sicher und nachvollziehbar gestaltet werden  können.

Genau da setzt der DevSecOps Ansatz an. Selbst Security Engineers, die noch keine Erfahrungen im Code-Review haben und sich eher auf Auditing oder Compliance Tätigkeiten verstehen, können durch Third-Party Tools aktiv in einem DevOps Team mitwirken. Ohne vertiefte Kenntnisse von CI/CD Mechanismen und die Nutzung von Release Pipelines zu besitzen, können Security Engineers ihre neuen Aufgaben innerhalb eines Teams wahrnehmen.

Open Source Tools, wie beispielsweise Grafeas und Kritis, ermöglichen integrale Aufgaben, um Computer-Ressourcen autorisiert und automatisiert bereitzustellen und diese nach erledigter Zielerfüllung wieder nachvollziehbar für weitere Verwendungen freizugeben. So können beispielsweise DevOps-Engineers nur Docker Images aus einer lokalen Registry nutzen, die vom Security Engineer verifiziert wurden. Somit werden nur Docker Images der CI/CD Pipeline zur Verfügung gestellt, die klaren Image Policies unterstehen.

Weiterhin sind Monitoring Mechanismen wie Security Scanner und QA Testing ein fester Bestandteil der technischen Lösung, um den kontinuierlichen Deployment Prozess aus Security Sicht zu unterstützen.

Gerade der kulturelle und organisatorische Aspekt ist hinsichtlich Aufwand und Implementierung nicht zu unterschätzen. Es muss zuerst eine Affinität geschaffen werden, so dass man die Notwendigkeit von DevSecOps als solche versteht. Das bedeutet auch, dass ein veränderter Arbeitsmodus, welcher auf proaktive und interagierende Mitarbeit abzielt, benötigt wird. Soziale Kompetenzen sind dabei genauso und ggf. noch wichtiger als fachliche Kompetenzen und sollten deshalb vorausgesetzt werden.

Dort, wo sich ein lösungsorientiertes und gemeinschaftliches Vorgehen abzeichnet, kann sich ein progressives Verhältnis von innovativen versus operativen Tätigkeiten einstellen, welches sich nicht nur ausschließlich quantifizierbar messbar macht.

Die konkrete Einbeziehung von DevSecOps lässt sich erfahrungsgemäß auf einzelne Bereiche sowie auf kleine Teams anwenden, die mittels funktionsübergreifenden Teamtätigkeiten auf organisatorischer Ebene festgelegte Tasks autonom erledigen. [5] In solchen Squads ist die Umsetzung von DevSecOps Tätigkeiten mittels klaren Aufgaben (Squad-Mission) möglich.

Es zeichnet sich somit die Erkenntnis ab, dass man zuerst die Kultur und die Organisation auf einen höheren Entwicklungsstand bringen sollte, damit man den anvisierten höheren Wirkungsgrad (z. B. Zeitersparnis beim Deployment, IT Robustheit, etc.) mittels Tools erreichen kann. Gerade an full-managed Cloud-Anwendungen sowie Self-Service Umgebungen wird die Erwartung gestellt, dass diese nicht nur schnell und on-demand zur Verfügung gestellt werden, sondern auch über eine sichere sowie klare Schnittstelle orchestriert und verwaltet werden können. Das verlangt nach einer lösungsorientierten Methode, die es ermöglicht, Verantwortungen an funktionalen Rollen zu binden, anstatt konkrete Zuweisungen an eine reine Berufsbeschreibung.

DevSecOps ist keine künstliche Weiterentwicklung einer etablierten DevOps Methode, sondern kann als eine natürliche Weiterentwicklung des DevOps Modells angesehen werden. Bei DevSecOps liegt der Fokus darauf, Software unter Berücksichtigung von IT-Security Themen kontinuierlich und in kurzen Iterationen zu entwickeln und sie mittels Services (im speziellen, aber nicht ausschließlich, Cloud-Services), schnell und sicher bereitzustellen, um sie mit ökonomischem Mehrwert zeitnah und zielgerichtet einzusetzen.

Das DevSecOps Modell ermöglicht es, Produktanforderungen wie „secure by default / secure by design“, zu realisieren, da die Security direkt bei der Entwicklung von neuen Produkten eingebunden wird (Stichwort: Security Development Lifecycle).

DevSecOps hilft dabei, sicheren Code und Software zu erstellen. [6] Dabei erhöht aber allein der Einsatz von Technik nicht den ökonomischen Wert. Auch eine organisatorische Umstrukturierung bringt nicht allein eine Veränderung, wenn kulturelle Verständnisfragen noch nicht geklärt sind. Hier sollte man Kultur vor Organisation sehen, um sie später mit der richtigen Technik zu beschleunigen.

[1]  Stricharan Vadapall, Hands-on DevOps, Verlag: Pack Publishing, eISBN: 978-1-78847-118-3, S. 15 ff

[2] Andreas Slogar, Die agile Organisation: Wie Mitarbeiter und Führungskräfte begeistern? Wie Strukturen und Strategien anpassen? Verlag: Carl Hanser Verlag GmbH & Co. KG, Hanser Verlag, eISBN 978-3-446-45615-0, S. 412 ff

[3] Quelle: Internet, https://www.dev-insider.de/software-entwicklung-mit-bizdevops-a-672211/, letzter Zugriff: Sonntag, 21. Oktober 2018 CET

[4] Anlehnung an Grafeas / Kritis ist OpenSource Software – GitHub project: https://github.com/grafeas | https://github.com/grafeas/kritis

[5] Quelle: Internet, https://www.informatik-aktuell.de/entwicklung/methoden/das-dasa-devops-prinzip-4-cross-functional-autonomous-teams.html, letzter Zugriff: Sonntag, 21. Oktober 2018 CET

[6] Quelle: Internet, http://www.devsecops.org/, letzter Zugriff: Sonntag, 21. Oktober 2018 CET