DevSecOps: Ein Plus an Sicherheit ist (k)eine Tool-Frage
Seit etwa zehn Jahren hat sich "DevOps" als Denkweise in agilen Umfeldern fest etabliert. Nun zieht der verhältnismäßig junge Begriff "DevSecOps" größere Kreise. Doch dabei handelt es sich um mehr als ein neues Schlagwort in der Softwareentwicklung. DevSecOps ist die zeitgemäße Antwort auf die aktuellen Security-Herausforderungen in agilen Entwicklungsumfeldern.
Die Vorteile des DevOps-Modells dürften inzwischen unbestritten sein. Unternehmen, die es geschafft haben, die Friktionen zwischen Development und Operations erfolgreich zu überwinden und deren Teilaufgaben in einen agilen Workflow zu transformieren, genießen die Vorteile, schneller auf die Anforderungen von Nutzerinnen und Nutzern respektive der Kundinnen und Kunden zu reagieren.
Data-Security wird immer schwerer zu erreichen
Dabei hat sich die agile Softwareentwicklung bisher auf die rasche Umsetzung fachlicher User Stories fokussiert. Der Gedanke an Datensicherheit spielt eine eher untergeordnete Rolle. Und dies in einem Umfeld, das von zwei Tendenzen beherrscht wird.
Die technische Komplexität von Infrastrukturen, Anwendungen und Workflows wächst, was sie unter Aspekten der Sicherheit anfälliger werden lässt. Bereits in kleineren und mittleren Unternehmen findet sich heute ein Mix aus physischen und virtuellen Server, Private Clouds und Public Clouds, SaaS-Lösungen und IoT-Devices. In größeren Organisationen (z. B. Versicherungen und Banken) kommt noch eine mehr oder wenigen große Zahl von Legacy-Anwendungen hinzu. Statt monolithischen Programmen werden auf Anwendungsebene Workflows in kleineren Einheiten entwickelt. Solche Microservices versprechen kürzere Entwicklungszeiten, häufigere Releases und korrespondieren so mit agilen Methoden.
Parallel zu dieser technologischen Entwicklung nehmen Angriffsversuche und die Zahl potenzieller Angriffsvektoren zu. So sieht Forrester in seinem Report "„The State Of Application Security" in Anwendungen nach wie vor eine der Hauptursachen für Probleme mit der Datensicherheit [1]. Die stärkere Verbreitung von Open-Source-Lösungen, der Einsatz von APIs und Containern erhöht demnach die Komplexität für Security-Teams.
So ist es nicht verwunderlich, dass immer mehr Unternehmen Opfer von Angriffen und gezielten Attacken – wie Erpressungsversuchen durch Ransomware – werden, was allein in der deutschen Wirtschaft Schäden von jährlich über 220 Mrd. Euro verursacht [2].
Sicherheit wird oft zu spät mitgedacht
Angesichts der wachsenden Bedrohungslage erscheint es unverständlich, dass in vielen Organisationen die Datensicherheit erst (zu) spät berücksichtigt wird. Spätestens seit den Arbeiten von Barry Boehm ist bekannt, dass die Kosten für die Behebung von Softwarefehlern exponentiell ansteigen können, je nachdem, an welcher Stelle in einem Produktionsprozess sie entdeckt werden. Fällt ein potenzieller Fehler noch während der Design- und Konzeptionsphase auf, verursacht seine Behebung weniger Aufwand, als ihn in einem Produktionssystem zu isolieren und zu beheben.
Die Folgen, die sich aus Problemen mit der Datensicherheit für Unternehmen ergeben können, sind immens. Finanzielle Einbußen durch Stillstände, Reputationsverluste bei Kundinnen und Kunden und mögliche Bußgelder, die Folge von nachgewiesener Fahrlässigkeit sein können, sind nur einige Beispiele. Sie können die Zukunft eines bisher gesunden Unternehmens potenziell schwer gefährden.
Je nach Branchenzugehörigkeit sind bereits während des Entwicklungsprozesses regulatorische Vorgaben einzuhalten. So schreibt die BaFin in Deutschland in ihren "Bankaufsichtlichen Anforderungen an die IT" (BAIT) und deren Entsprechung für das Versicherungswesen (VAIT) vor, dass der Schutzbedarf von Daten definiert und eingehalten werden muss. Als Schutzziele werden explizit die "Integrität", "Verfügbarkeit", "Vertraulichkeit" und "Authentizität" benannt. Dieser Schutzbedarf setzt auch den Rahmen für die Anwendungsentwicklung. Er ist nicht nur während der Entwicklung, sondern auch nach der Produktivsetzung einer Software zu berücksichtigen.
Es ist erstaunlich, dass Praktiken, die auf die Erreichung von mehr Sicherheit einzahlen, während des Entwicklungsprozesses häufig keine Rolle spielen. In einer Stichprobe ergab sich folgendes Bild [3]:
- Nur 33 Prozent der Unternehmen führen in der Entwurfsphase für jeden neuen Dienst eine Risikobewertung durch oder erstellen ein Bedrohungsmodell.
- Lediglich 50 Prozent führen während der Entwicklungsphase eine statische Codeanalyse durch, um die Übertragung von anfälligem Code zu verhindern.
- Gerade einmal 35 Prozent nutzen die Möglichkeit eines dynamischen Code-Scannings (z. B. Dynamic Application Security Testing) für festgeschriebenen Code, um das Deployment von anfälligem Code zu verhindern.
Diese Zahlen sind nicht die Ergebnisse einer empirischen Studie, aber als Stimmungsbild aus Unternehmen dennoch eindrucksvoll. Die aktuelle Bedrohungslage und eine zunehmende Verlagerung von Angriffsversuchen auf die Anwendungsebene unterstreichen die Notwendigkeit, DevOps in Richtung DevSecOps weiterzuentwickeln, um den Sicherheitsaspekt bereits während der Entwicklung zu berücksichtigen.
DevSecOps ist eine Reise
Ein Blick auf Portale und in Fachmedien zeigt, dass sich beim Thema DevSecOps gerade eine falsche Vorstellung davon manifestiert, worum es sich dabei handelt. Hier wiederholt sich ein Missverständnis, das bereits die Adaption von DevOps behinderte. Denn schnell nach der ersten Vorstellung des Konzepts versprachen Softwarehersteller und Lösungsanbieter den Unternehmen, dass bereits die Anschaffung einer Software genüge, um den Pfad von DevOps erfolgreich zu beschreiten. Es gehört ohne Zweifel zum Erfolg von DevOps, dass es durch eine hochgradige Automatisierung den Menschen als Fehlerquelle möglichst ausschließen will. Der Einsatz von Containern und Kubernetes ermöglicht heute den On-Demand-Aufbau einer kompletten Infrastruktur, inklusive Netzwerk und Speicher. Da sie stets neu aufgesetzt werden, veralten sie nicht so schnell und dank der textlichen Beschreibung der Bausteine sind Umgebungen versionierbar. DevOps und DevSecOps wird inzwischen synonym für Automatisierung, beschleunigte Releases und somit mehr Agilität verwendet. So weit so gut: Der massive Einsatz von Tools geht aber am Grundgedanken von DevOps und damit auch DevSecOps vorbei.
Denn es geht hier in erster Linie um das Aufbrechen vom Denken in Silos und erst danach um Werkzeuge. DevSecOps ist eine Frage von Haltung und Bewusstsein, also das, was heute als "Mindset" bezeichnet wird. Es dreht sich um Kommunikation und um Menschen. Erst danach kommen Werkzeuge ins Spiel.
Im Rahmen des Wandels in Richtung DevOps haben sich Entwickler zunehmend auch um die Fragen des Betriebs kümmern müssen. Die vorherrschenden Abteilungs- und Teamgrenzen fingen an zu verschwimmen. Die Kommunikation und Motivation jedes Einzelnen ist ein wichtiger Teil des Prozesses. Und dieser Wandel erweitert sich nun um das Expertenwissen rund um das Thema Datensicherheit. Ohne den aktiven Willen zur Zusammenarbeit und zwischen verschiedenen Teams werden die besten Tools ins Leere laufen.
DevSecOps verschiebt das Ziel eines Releases von "funktionierende" in Richtung "sichere und funktionierende" Software – und dies von Anfang an. Dieses Ziel liegt am Ende einer Reise und eines Wandels, ist also das Ergebnis eines länger dauernden Prozesses. Und der beginnt mit kleinen Schritten in Richtung eines immer höheren Reifegrads bei DevSecOps.
Es gilt, sechs Kernbereiche zu entwickeln
Sechs Bereiche müssen in einer Organisation in Richtung von DevSecOps entwickelt werden.
- People & Culture: Der Bereich bildet die Basis und umfasst die Organisationsstruktur, Kommunikation und Kommunikationsstile, Anreize und Werte. Der Weg der Reise reicht hier von funktionierenden Teams, die sich aber in Silos befinden, bis zu funktionsübergreifenden Einheiten, die konsequent auf Produkte und Services ausgerichtet sind.
- Plan & Develop: Hier geht es um die Frage, wie die Arbeit geplant und priorisiert wird, aber auch wie stark bereits Risikobewertung und Code-Validierung eine Rolle spielen. Zu Beginn werden Risiken und Sicherheit kaum beachtet und auch eine Validierung des Codes selten vorgenommen. Im höchsten Reifegrad einer Organisation wird sämtlicher Code automatisch geprüft und die Betrachtung von Risiken und Bedrohungen findet bereits zu Beginn Eingang in den Entwicklungsprozess.
- Build & Test: Wie sind Testprozesse und Qualitätssicherung organisiert? Wie stark wird dabei auf die Automatisierung gesetzt? Setzt das Unternehmen überhaupt Techniken für die statische Code-Analyse (Codescanning) ein? Werden Builds validiert? Organisationen, die sich noch am Anfang ihrer Reise befinden, werden auf manuelles Testen setzen, wahrscheinlich den Code nicht automatisiert überprüfen und sich auf begrenzte Tests von Kernfunktionalitäten beschränken. Dagegen setzen Firmen, die DevSecOps weitreichend umgesetzt haben, auf vollständige Testautomatisierung, umfassendes und dynamisches Codescanning und umfassende Tests von Kernfunktionen.
- Release & Deploy: Dieser Kompetenzbereich konzentriert sich auf Bereitstellungsstrategien, die Häufigkeit von Freigaben und die Automatisierung von Bereitstellungsprozessen. Den Beginn der Entwicklung stellen manuelle Deployments mit großen und eher seltenen Releases dar. Beim Deployment sind noch keine Sicherheitsaspekte berücksichtigt. Gereifte Firmen werden dagegen das Deployment vollständig automatisiert haben, sind in der Lage mehrere Releases am Tag auszurollen und damit die Datensicherheit zu berücksichtigen.
- Operate: In diesem Kompetenzbereich spielen Kapazitätsplanung, Skalierung und Zuverlässigkeit, aber auch Patching und Notfallwiederherstellung eine Rolle. Zu Anfang werden Firmen manuelle Konfiguration und Provisionierung betreiben und noch keine Disaster-Recovery-Strategie entwickelt haben. Voll gereifte Unternehmen haben alle Konfigurationen von Infrastrukturen als Code umgesetzt, durch den Einsatz von Multi-Cloud-Strukturen erreichen sie eine hohe Verfügbarkeit und verfügen über bereits mehrfach getestete Strategien für Disaster-Recovery.
- Observe & Respond: Die Kernkompetenz beschreibt die Fähigkeiten rund um das Monitoring von Lösungen, wie das Scanning nach Schwachstellen oder fehlerhaften Konfigurationen, Überwachung auf Angriffe und Anomalien, aber auch das Monitoring der User Experience. In Firmen, die sich erst dem Thema öffnen, sind keine Metriken im Bereich Datensicherheit definiert, die Telemetrie ist in Silos eingesperrt, es finden keine regelmäßigen Scans auf Schwachstellen statt. Gereifte Organisationen dagegen verfügen über definierte Sicherheitsmetriken, haben die vollständige User Experience im Blick und stellen die Ergebnisse des Monitorings aus den verschiedenen Bereichen zentral zur Verfügung und haben die Silos überwunden.
Datadog hat ein kleines Self-Assessment-Center entwickelt, das allen Nutzerinnen und Nutzern Hinweise liefert, um den eigenen Reifegrad von DevSecOps in der eigenen Organisation zu überprüfen [3].
Die Reise zu DevSecOps beginnen
Wenn DevSecOps aber weniger eine Frage der Tools, sondern des Mindsets ist, stellt sich die berechtigte Frage, wie Unternehmen damit beginnen sollten, um die Strategie zu implementieren.
Leider gibt es dafür kein Patentrezept, weil die Umsetzung stark vom Reifegrad der Organisation abhängt. So könnten Unternehmen, die noch am Anfang stehen, damit beginnen, Sicherheitsexperten zu Teambesprechungen von DevOps einzuladen, um darüber Input und andere Sichtweisen zu erhalten. Das gegenseitige Verständnis wird wachsen, wenn in solchen Besprechungen auch konkrete Probleme oder Projektverzögerungen zur Sprache kommen, in denen Sicherheitsaspekte eine Rolle gespielt hatten.
Eine leicht und mit eher geringem Aufwand umzusetzende Ausgangsbasis ist die Einbeziehung von Sicherheitsexpertise in den Entwicklungsprozess. Beim "Shifting Left" finden Sicherheitskontrollen und das Fachwissen der Experten früher Eingang in den Entwicklungsprozess. Das tut nicht nur der Qualität und der Sicherheit der Anwendungen gut (Motto: Vorbeugen ist besser als heilen), sondern stärkt auch die Bedeutung des Security-Gedankens in den Köpfen der Mitarbeitenden. Die Datensicherheit wird so immer mehr zu einer Priorität für jedes Team-Mitglied.
DevSecOps braucht die passenden Werkzeuge
Unternehmen, die den Ansatz von DevSecOps verinnerlichen, beschreiten einen Weg, der zur Verbesserung der Qualität und der Sicherheit ihrer Anwendungen und Infrastruktur beiträgt. Die Security bereits bei der Bereitstellung von Services und der Entwicklung von Anwendungen zu berücksichtigen, hilft effektiv dabei, Angriffsvektoren gar nicht erst entstehen zu lassen. Wie jeder Wandel verursacht auch die Umsetzung einer DevSecOps-Strategie Kosten. Diese liegen aber deutlich unter denen, die durch einen erfolgreichen Cyberangriff entstehen, wenn etwa für mehrere Stunden oder gar Tage alle Systeme stillstehen, weil ein Angriff mit Ransomware erfolgreich war.
Klassisches Application-Performance-Monitoring oder Infrastruktur-Monitoring müssen in einer zunehmend komplexen IT-Struktur zwangsläufig an ihre Grenzen stoßen. Und der Gedanke von DevSecOps lässt sich nur schwer mit isolierten Tools und Prozessen umsetzen. Die von Unternehmen genutzten Monitoring-Tools müssen dieses Konzept unterstützen, damit alle beteiligten Personen genau die Informationen erhalten, die für ihre Kernaufgaben von Bedeutung sind. DevSecOps ist in diesem Zusammenhang dann doch auch eine Tool-Frage.
Daten und Metriken aus Infrastruktur, Netzwerk, Anwendungen und IT-Security-Lösungen sollten idealerweise an einer zentralen Stelle zusammenlaufen. DevSecOps benötigt eine "Single Source of Truth", die einen möglichst einfachen Zugang zu erhobenen Werten und Prognosen bietet. Die mit Security-Fragen beschäftigten Mitarbeitenden müssen sich genauso schnell einen Überblick verschaffen können, wie Operations und Development. Dazu muss die Monitoring-Anwendung ein gemeinsames Datenmodell unterstützen.
Ein umfassendes Monitoring, das dem Anspruch von DevSecOps gerecht wird, bietet nicht nur die Möglichkeit, mit wenig Aufwand Testszenarien zu entwickeln, um diese automatisiert ablaufen zu lassen. Sie spielen das Ergebnis der Tests auch direkt in das Monitoring zurück, um so etwa Auswirkungen auf die Performance entdecken zu können. Es geht ja nicht nur um sichere, sondern auch um funktionierende und belastbare Anwendungen. Um alle Mitarbeitenden schnell und umfassend zu informieren, ist auch eine grafische Aufbereitung von Ergebnissen und mittels KI angereicherter Prognosen alternativlos.
Operative Kennzahlen (Work Metrics) und Werte, die die Ressourcen betreffen (Resource Metrics), fließen in einem solchen System zusammen. Und das ist letztlich auch gut für das Geschäft. Denn in Zeiten, in denen Services und Anwendungen auf dem Smartphone der Kundschaft nur einen Fingertip von den Lösungen der Mitbewerber entfernt ist, muss auch die User-Journey vollständig betrachtet werden. Die Trennung vieler Monitoring-Lösungen in das Real User Monitoring und Application Performance Monitoring sollte aufgehoben werden. Das spart die isolierte Betrachtung in mehreren Arbeitsabläufen zur Behebung von Fehlern und entspricht der Philosophie von DevSecOps.
Fazit
DevSecOps ist ein zeitgemäßer Ansatz, der auf die Herausforderungen in aktuellen IT-Strukturen, Agilität und datenzentriertes Arbeiten eingeht. Dabei geht es in erster Linie um Personen und die Entwicklung des passenden Mindsets. DevSecOps stärkt die Sicherheit von Unternehmen, Anwendungen und damit letztlich auch der Kundinnen und Kunden.
- Forrester: The State Of Application Security
- Bitkom: Angriffsziel deutsche Wirtschaft: mehr als 220 Milliarden Euro Schaden pro Jahr
- Datadog: Measure your DevSecOps maturity with Datadog's self-assessment
