Der DevSecOps-Prozess

Es gibt verschiedene Praktiken, die in die DevSecOps-Umgebung und an strategischen Punkten entlang der Pipeline integriert werden müssen. Die für diese Praktiken definierten Prozesse müssen sicherstellen, dass Sicherheit von Anfang an in die Entwicklung eingebaut wird – so, dass sie Entwickler unterstützt und schnelle Deployments nicht behindert.

Reibungsverluste bei der Bereitstellung reduzieren

Ein Konzept, das aus dem Erfolg von Netflix hervorgegangen ist und zunehmend als Strategie für eine DevSecOps-Kultur übernommen wird, ist die „Paved Road“. Damit ist ein reibungsarmer Weg gemeint, auf dem Software vom Konzept bis zur Produktion gelangt. Entscheidungen, die diese Bereitstellungsprozesse beeinflussen könnten, sollten daher berücksichtigen, ob sie Entwickler unterstützen oder die Bereitstellung behindern. Letzteres sollte möglichst reduziert oder ganz vermieden werden.

Ein wichtiger Aspekt beim Aufbau einer DevSecOps-Kultur ist es, durch die Förderung von Empathie Reibungsverluste zwischen Teams zu beseitigen.

Dieser Ansatz erfordert die Unterstützung vieler Bereiche des Unternehmens, beginnt aber auf Führungsebene. Wenn die Unternehmensführung den Kulturwandel nicht vorantreibt, wird er schlicht nicht stattfinden. Die Führung von oben muss die Übernahme der Paved-Road-Prinzipien auf allen Unternehmensebenen fördern. Die Unternehmenswerte sollten klar vermitteln, dass alle dafür verantwortlich sind, sichere Produkte zügig an Kunden auszuliefern. Dadurch lassen sich Praktiken, die den Aufwand für die Softwarebereitstellung verringern, leichter priorisieren.

Threat Modeling

Der DevSecOps Insights Report 2020 zeigte, dass Threat Modeling das Vertrauen eines Teams in die Sicherheit seines Codes deutlich stärkt. Leider gilt Threat Modeling seit Langem als sehr arbeitsintensiv. Deshalb wird es bei der Umstellung von Unternehmen auf DevOps- oder DevSecOps-Ansätze oft aus den eingesetzten Sicherheitspraktiken ausgeschlossen. Die Auswirkungen von Threat Modeling auf die Entwicklung dürfen jedoch nicht unterschätzt werden. 

Im Kern soll Threat Modeling geplante Software daraufhin untersuchen, was schiefgehen könnte, wenn ein Angreifer sie ins Visier nähme. Ziel dieser Analyse ist es, dem Entwicklungsteam aufzuzeigen, welche Sicherheitskontrollen bei der Implementierung berücksichtigt werden sollten. Traditionell wurde Threat Modeling mit einem breiten Fokus auf den gesamten Anwendungskontext durchgeführt. Dabei kamen häufig Datenflussdiagramme, detaillierte Frameworks zur Bedrohungsanalyse und vorgeschriebene Methoden zur Priorisierung von Bedrohungen zum Einsatz.

In einem DevSecOps-Modell ist eine zeit- und ressourcenintensive Threat-Modeling-Methode jedoch hinderlich. Stattdessen lässt sich eine schlanke Vorgehensweise in die Pipeline integrieren. DevSecOps nutzt typischerweise Praktiken aus der agilen Entwicklung, etwa das Management des Produkt-Backlogs. Anstatt ein ganzes System zu entwerfen, werden neue Funktionen und Verbesserungen mithilfe von User Stories in das Backlog aufgenommen. Diese überschaubaren, unabhängigen Elemente bilden die Grundlage für eine schnelle Entwicklung. Unternehmen können beim Threat Modeling genauso vorgehen.

Anstatt Threat Modeling als Prozess zu betrachten, der auf eine monolithische Anwendung angewendet werden muss, lassen sich einfache Threat-Modeling-Praktiken direkt im Backlog umsetzen. Beim Verfassen einer neuen User Story sollte auch kurz beschrieben werden, welche Bedrohungen dadurch neu entstehen oder beeinflusst werden. Sensible Funktionen und Daten, die Teil der Story sind, sollten kenntlich gemacht werden. Mit diesen Informationen im Backlog können Entwickler Threat Modeling so einbeziehen, dass sich die Entwicklung jeder Story tatsächlich beschleunigen lässt.

Versionskontrolle, Metadaten und Orchestrierung

In einer automatisierten Welt ist Veränderung die einzige Konstante – und sie muss konsistent und nachvollziehbar sein. Damit alle Änderungen nachverfolgt werden können, muss DevSecOps eine geeignete, unveränderliche Versionierung sicherstellen. Wie Code muss auch jede Aktion versioniert werden, damit eine schnelle Wiederherstellung möglich ist. Als Metadaten erfasst, lassen sich Änderungen von Betriebsteams effizient nachverfolgen und auswerten.

Orchestrierungssoftware ermöglicht nicht nur die wiederholbare Bereitstellung von Infrastruktur, sondern liefert auch umfangreiche Metadaten zu jeder Aufgabe. Diese Metadaten lassen sich nicht nur von der Orchestrierungssoftware selbst nutzen, sondern auch als maßgebliche Quelle für integrierte Tools. In Kombination mit Versionierung wird Orchestrierungssoftware zu einer wertvollen Informationsquelle für alle Betriebsteams.

Compliance

Compliance-Initiativen müssen keine papierbasierte Übung sein. Unternehmen können stattdessen Metadaten erstellen, die Compliance-Anforderungen abbilden, und diese direkt in ihre Assets integrieren. Auch die Automatisierung von Sicherheitsrichtlinien kann davon profitieren: Assets lassen sich kennzeichnen, damit anschließend die gewünschte Sicherheitsarchitektur umgesetzt werden kann, beispielsweise durch Zoneneinteilung.

Dieser Ansatz ermöglicht Compliance in großem Maßstab. So kann beispielsweise die Fähigkeit geschaffen werden, auf einen Sicherheitsvorfall gemäß den neuen DSGVO-Regeln innerhalb von 72 Stunden zu reagieren. Werden Compliance-Anforderungen im Rahmen von DevSecOps als Code umgesetzt, wird der Entwicklungsprozess zum Wegbereiter des Compliance-Programms.

Sicherheitsarchitektur

Die Sicherheitsarchitektur basiert auf einer Reihe von Grundsätzen, die für jedes Unternehmen spezifisch sind. Diese hängen von der Art der verarbeiteten Daten ab. Übergeordnete Grundsätze können jedoch als Leitfaden dienen, um die Softwarebereitstellung sicherer zu gestalten. Unternehmen, die ein DevSecOps-Modell einführen, müssen Prozesse einrichten, um diese Architekturen zu entwickeln und kontinuierlich zu aktualisieren. Das ermöglicht eine schnellere und sicherere Entwicklung.

Werden diese Grundsätze als Teil der DevSecOps-Kultur im Backlog festgehalten und bereitgestellt, können Produktmanager Sicherheit nahtlos in ihre Planung und die zugehörige Architektur einbeziehen. Abweichungen aufgrund von Geschäftsprozessen und/oder fehlenden Ressourcen werden dokumentiert und die damit verbundenen Risiken berücksichtigt. Solche Abweichungen lassen sich letztlich wie jeder andere Bug nachverfolgen, bis sie behoben sind.

Incident Management

Die Reaktion auf Sicherheitsvorfälle sollte weder improvisiert noch ungeplant erfolgen. Workflows, Aktionspläne, Playbooks und Runbooks müssen unbedingt im Voraus erstellt werden. So wird sichergestellt, dass die Reaktion auf Vorfälle konsistent, wiederholbar und messbar ist. Incident Management sollte Metadaten nutzen, um diesen Prozess zu vereinfachen. Dadurch können die Kennzahlen beispielsweise die Zeit bis zur erneuten Bereitstellung eines kompromittierten Assets erfassen. Die dafür entwickelten Playbooks sollten alle Arten von Vorfällen abdecken. So wie DevSecOps verschiedene Funktionen zusammenführt, sollten auch die zugehörigen Prozesse diese Verbindung widerspiegeln. Incident-Management-Prozesse sollten daher so abstrakt gestaltet sein, dass Betriebs- und Sicherheitsvorfälle nach demselben Framework behandelt werden. Dies ist ein weiterer wirksamer Schritt, um die Kultur geteilter Verantwortung zu stärken, die für DevSecOps entscheidend ist.

Sind die Playbooks einmal als Code umgesetzt, lassen sie sich in die CI/CD-Pipeline integrieren und automatisieren. In einer DevSecOps-Welt führen proaktive und vorbeugende Threat-Hunting-Maßnahmen sowie die kontinuierliche Erkennung und Abwehr von Bedrohungen und Schwachstellen zu weniger schwerwiegenden Vorfällen und mehr Gegenmaßnahmen. Penetrationstests, Red Teaming und Bug-Bounty-Programme bieten eine zusätzliche Schutzebene gegen das Risiko von Sicherheitsverletzungen. Kontinuierliche Erkennung ist zwar wertvoll, doch Unternehmen müssen eine Überlastung durch Warnmeldungen vermeiden. Dazu gehören Feedback-Schleifen, die eine kontinuierliche Verbesserung der Überwachung sowie eine stärkere Automatisierung bei der Bewertung und Bearbeitung von Warnmeldungen ermöglichen.

Proaktive Sicherheitsbewertungen

Unabhängig davon, wie ausgereift die DevSecOps-Methodik eines Unternehmens ist: Schwachstellen müssen aktiv identifiziert werden.  Der Begriff Penetrationstest bezeichnet häufig Maßnahmen, mit denen Schwachstellen innerhalb eines festgelegten Umfangs umfassend ermittelt werden. Red Teaming unterscheidet sich dadurch, dass dabei meist die Beweggründe und Taktiken eines Angreifers nachgeahmt werden. Ein Penetrationstest könnte beispielsweise darauf abzielen, alle Seiten einer Anwendung zu finden, die für einen SQL-Injection-Angriff anfällig sind. Bei einem Red-Team-Assessment würden möglicherweise nur ein oder zwei anfällige Seiten identifiziert und die Schwachstellen genutzt, um die Anwendung weiter zu kompromittieren.

Penetrationstests

Penetrationstests sind häufig der erste Reifegradschritt beim Schwachstellenmanagement in Anwendungen. Ziel dieser Tests ist es, Bereiche einer Anwendung zu identifizieren, die für bestimmte Angriffe anfällig sein könnten. Im Idealfall bieten solche Assessments einen umfassenden Einblick in die allgemeine Sicherheitslage und ermöglichen die Behebung risikoreicher Schwachstellen. Eine vollständige Übersicht über die Schwachstellen einer Anwendung zu erstellen, kann jedoch zeitaufwendig sein. Daher werden Penetrationstests in DevSecOps zwar als grundlegende Maßnahme der Sicherheitshygiene angesehen, aber typischerweise erst nach der Produktion durchgeführt.

Red Teaming

Red-Team-Assessments sind typischerweise in Unternehmen mit einem hohen Reifegrad anzutreffen und ergänzen Penetrationstests. Dabei geht es nicht darum, möglichst viele Schwachstellen zu identifizieren. Stattdessen verfolgt dieser Ansatz konkrete Ziele und ähnelt stärker dem Vorgehen eines Angreifers. Der Umfang beschränkt sich in der Regel nicht auf eine einzelne Anwendung, sondern erstreckt sich auf alle Systeme in der Umgebung. So können Unternehmen nachvollziehen, wie sich Schwachstellen in mehreren Systemen kombinieren lassen, um einen Angriff durchzuführen. Das vermittelt ein besseres Verständnis für die möglichen Auswirkungen eines erfolgreichen Angriffs. Daher erfordern solche Assessments mehr Erfahrung und vielfältigere Kompetenzen als herkömmliche Penetrationstests. Mit zunehmender Reife ihres DevSecOps-Ansatzes können Unternehmen Red-Team-Einsätze als Teil ihrer regelmäßigen Sicherheitshygiene in Betracht ziehen.

Bug-Bounty-Programme

Bug-Bounty-Programme haben in den vergangenen Jahren viel Aufmerksamkeit erhalten, nicht zuletzt dank der verfügbaren Crowd-Bug-Bounty-Programme. Sie legen Umfang, Meldeanforderungen und Meldewege fest, damit externe Hacker Schwachstellen in der Umgebung eines Unternehmens aufspüren können. Wenn sich Hacker an diese Regeln halten, erhalten sie für gemeldete Schwachstellen eine „Prämie“.

Bug-Bounty-Programme motivieren externe Personen dazu, Schwachstellen verantwortungsvoll offenzulegen, und bieten eine zusätzliche Möglichkeit, Schwachstellen zu identifizieren. Sie sollten jedoch Penetrationstests nicht ersetzen. Sicherheitsforscher, die an Bug-Bounty-Programmen teilnehmen, handeln in der Regel nicht im besten Interesse des Unternehmens. Sie versuchen nicht, alle Schwachstellen umfassend zu ermitteln. Die meisten suchen lediglich nach den schwerwiegendsten Funden, für die sie die höchste Prämie erhalten.

Threat Intelligence

Je mehr Komponenten der Umgebung als Code definiert und dokumentiert werden, desto besser wird auch die Transparenz im Bereich Threat Intelligence. Vielen Unternehmen fällt es schwer, ihre IT-Assets so zu erfassen, dass sich eingehende Threat Intelligence gezielt mit den Assets in ihrer Umgebung verknüpfen lässt. Werden Prozesse eingerichtet, die Metadaten aus der DevSecOps-Pipeline an Threat-Intelligence-Funktionen weitergeben, kann das Unternehmen sicherstellen, dass die richtigen Informationen erfasst, risikobasiert priorisiert und angemessen umgesetzt werden.