Banner Aktuelle IT-Sicherheit Online-Schulungen Rabatt
Mit <kes>+ lesen

DevSecOps (1)

Softwareentwicklung und IT-Betrieb profitieren seit einiger Zeit vom gemeinsamen DevOps-Ansatz. Die Sicherheit blieb jedoch dabei oft außen vor – DevSecOps ändert das und bezieht nun auch die Security integral mit ein. Der vorliegende Artikel zeigt, mit welchen Strategien und automatisierten Tools man Software auf Fehler und Schwachstellenprüfen kann und wie Unternehmen Sicherheitsprüfungen optimal integrieren können.

Lesezeit 18 Min.

Von Evren Eren, Bremen

Natürlich, hier ist der formatierte Text ohne Code-Formatierung:

Die Zusammenarbeit zwischen Softwareentwicklung und IT-Betrieb im Sinne von DevOps hat nachweislich positive Auswirkungen auf die Effizienz beider Bereiche. Viele Unternehmen profitieren durch höhere Qualität von IT-Anwendungen sowie kürzere Entwicklungszyklen. Ein wichtiger Faktor bleibt jedoch mitunter auf der Strecke: die IT-Sicherheit (vgl. [1,2]). Angesichts der zunehmenden Akzeptanz von DevOps ist es ein logischer nächster Schritt, diese Praktiken auf den Bereich des Sicherheitsmanagements anzuwenden. Aus diesem Grund etabliert sich aktuell der Ansatz DevSecOps, der das Prinzip erweitert und konsequent weiterdenkt.

Rekapitulation: DevOps

Der gemeinsame Ansatz von Development und Operations bildet als DevOps die Brücke zwischen der Softwareentwicklung und der Bereitstellung von Anwendungen [3] – mit dem Fokus auf einer engeren und ganzheitlichen Zusammenarbeit der doch unterschiedlich ausgeprägten Disziplinen. Der Hashtag #devops erschien auf Twitter im Juni 2009 von Evren Eren, Bremen.

Softwareentwicklung und IT-Betrieb profitieren seit einiger Zeit vom gemeinsamen DevOps-Ansatz. Die Sicherheit blieb jedoch dabei oft außen vor – DevSecOps ändert das und bezieht nun auch die Security integral mit ein. Der vorliegende Artikel zeigt, mit welchen Strategien und automatisierten Tools man Software auf Fehler und Schwachstellen prüfen kann und wie Unternehmen Sicherheitsprüfungen optimal integrieren können.

Und wurde als Begriff durch die von Patrick Debois initiierten DevOpsDays geprägt. Bislang gibt es keine einheitliche Begriffsdefinition, der konzeptionelle Rahmen wird jedoch angelehnt an Jez Humble im CALMS-Model zusammengefasst [4]. Das Akronym setzt sich dabei aus den folgenden Prinzipien zusammen:

  • Culture betont die nahtlose Zusammenarbeit, allem voran zwischen Entwicklung und Betrieb: Sie ist auf Geschwindigkeitsoptimierung ausgerichtet, sodass dem Kunden kontinuierlich qualitativ hochwertige Softwarekomponenten durch schnelle, inkrementelle Deployments ausgeliefert werden sollen (Continuous Delivery, [5]). Dies wird unter anderem durch den Wechsel von funktions- zu produktbasierten Teams erreicht.
  • Automation beruht auf dem ersten Prinzip des „Agilen Manifests“: Demnach ist es von höchster Priorität, „den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufriedenzustellen“ [6]. Umgesetzt wird diese Anforderung unter anderem durch die Automatisierung diverser Prozesse – Konzepte wie Continuous Integration, Continuous Deployment und Continuous Delivery stellen hierfür die entscheidenden Grundlagen bereit.
  • Lean fokussiert die Kernaussagen des Toyota Production Systems (TPS, [7]): beispielsweise die Einführung unkomplizierter Entscheidungsprozesse, kontinuierlicher Messungen, Arbeitsvisualisierungen sowie das Setzen von Work-in-Process-Grenzen, um Arbeitsprozesse optimal aufeinander abzustimmen und unnötige Anteile zu eliminieren.
  • Measurement definiert den Einsatz von Key-Performance-Indicators (KPIs), um Erfolge, Stagnationen und Misserfolge zu visualisieren.
  • Sharing beschreibt, dass IT-Entwicklung und -Betrieb über den gesamten Lebenszyklus einer Anwendung Informationen, Vorgehensweisen und Best Practices miteinander teilen und eine gemeinsame Fehlerkultur entwickeln, um sich – gemäß des Continuous Improvements – gemeinsam kontinuierlich weiterzuentwickeln.

Als zentraler Ansatz für die Bereitstellung des gesamten Lebenszyklus der Softwareentwicklung vereint DevOps die Berufsfelder der Softwareentwicklung und des IT-Betriebs [8]. Beide Bereiche sind für den Lebenszyklus einer Software elementar, umfassen jedoch verschiedene Arbeitsansätze und Kulturen, weshalb häufig eine Kluft zwischen beiden Berufsgruppen besteht [9]. Während der traditionelle Ansatz darauf basiert, Software von der Entstehung über die Entwicklung bis hin zur Wartung durch verschiedene voneinander abgegrenzte Abteilungen laufen zu lassen, fokussiert DevOps die Unternehmenskultur mit dem Ziel, die Zusammenarbeit zwischen der IT-Entwicklung und dem IT-Betrieb zu optimieren. Hierzu wird eine Sammlung praxiserprobter und funktioneller Lösungsansätze vorgehalten. Zur angewandten DevOps-Technologie zählen insbesondere Automatisierungstools, orchestrierte Containerisierung sowie Cloudnutzung.

Um in kurzer Folge stets verbesserte Software-Releases bereitzustellen, ist das Kernziel von DevOps die Automatisierung sich wiederholender Aufgaben sowie die Bereitstellung von Infrastructure as Code (IaC). Letzteres ist eine Automatisierungstechnik zum Einrichten und Verwalten von IT-Infrastrukturen, bei der die Infrastruktur selbst durch Code bereitgestellt wird, wobei man Zielsysteme wie eine eigenständige Software behandelt [9]. Dieses Konzept wurde ursprünglich eingeführt, um die Verwaltung der Laufzeitinfrastruktur in lokalen Rechenzentren zu verwalten. Tools wie Ansible (www.ansible.com), Chef (www.chef.io) und Puppet (https://puppet.com) ermöglichen die Konfiguration und Bereitstellung von Stacks (Betriebssystem, VMs, Netzwerk- und Datenbankkonfiguration) als Code. Durch die Beschreibung von Infrastruktur durch Skripte oder Programmfiles entfallen weitgehend manuelle Konfigurationsarbeiten. Mit dem Effekt einer Entkopplung von Infrastruktur und Anwendung lässt sich ein zuverlässiges und wiederholbares Deployment von Umgebungen erzielen – Systeme lassen sich einfacher und mit weniger Aufwand entfernen, erneuern und einrichten.

Da sich in den letzten Jahren in die IT-Landschaft zunehmend cloudnative Verfahren wie Container und Microservices – als integraler Bestandteil vieler DevOps-Initiativen – etabliert haben, ist jedoch auch die Anpassung der Sicherheit vonnöten: Container und Clouds ermöglichen hohe Skalierung sowie verteilte und dynamische Infrastrukturen. Container beschleunigen Arbeitsabläufe, Test, Testbetrieb, Rollout und Produktivbetrieb und haben die geschäftlichen Abläufe vieler Unternehmen stark verändert. Statische Sicherheitsrichtlinien sind hierbei ungeeignet, da Sicherheitsmaßnahmen entlang des Lebenszyklus von Anwendungen und Infrastrukturen kontinuierlich adaptiert werden müssen.

Immer kürzer werdende Updatezyklen bedingen, dass Softwarecode entsprechend viele Qualitätskontrollen und Sicherheitstests durchlaufen muss. Um solche Release-Zyklen realisieren zu können, setzt sich Code in der agilen Softwareentwicklung aus zunehmend kleinen, auf verteilten IT-Infrastrukturen voneinander unabhängig laufenden Prozesse zusammen. Containertechnologie, Microservices und Clouds sowie Tools zur Automatisierung werden unverzichtbarere Bestandteile. In diesem Kontext erfolgt die Provisionierung und Skalierung zunehmend durch die Entwickler selbst. Deployment-Prozesse können durch große Cloud-Provider mittels Programmierschnittstellen (APIs) und Konfigurationswerkzeugen unterstützt werden – auch IaC wird beispielsweise durch Deployment-Templates ermöglicht.

DevOps und Sicherheit

DevOps verfolgt das vorrangige Ziel, die Softwareentwicklung innovativ, agil und schnell zu gestalten – mit dem Fokus auf Geschwindigkeit wird jedoch die Sicherheit oft vernachlässigt. Angesichts der drastischen Zunahme von Cyberangriffen können die Risiken und Folgen, die mit fehlerhaftem Code und fehlerhafter Infrastruktur und Infrastrukturkonfiguration verbunden sind, schwerwiegend sein.

In Cloud-Umgebungen arbeiten heute zahlreiche kleine Teams unabhängig voneinander, entwickeln Services und stellen diese über APIs bereit. Viele Unternehmen nutzen APIs und Web-Technologie, um ihre Softwareprodukte zur Verfügung zu stellen. APIs kommen häufig in Verbindung mit neueren Verfahren der Softwareentwicklung- und Bereitstellung zum Einsatz, darunter Microservices, Container und Software-as-a-Service-(SaaS)-Tools, was die Perimeter-Sicherheit aufweicht. Während interne APIs in der Regel für den Zugriff auf eigene Microservices, Partner- und SaaS-APIs für das Beziehen von Informationen das Ausführen von Workflows genutzt werden, stellen externe APIs spezifische Funktionen bereit. Interne und externe APIs dienen Unternehmen in Kombination dazu, neue Produkte zu erstellen sowie für externe Entwickler und Kunden zur Verfügung zu stellen.

Viele APIs bieten – teilweise große – Angriffsflächen: Zu den üblichen Sicherheitsrisiken gehören Lücken in der Authentifizierung und Zugriffskontrolle. Eine Vielzahl von APIs und Anwendungen von Drittanbietern werden mithilfe von Frameworks und Libraries erstellt, was die Entwicklungszeit immens beschleunigt. Vor diesem Hintergrund sind Frameworks oft Angriffen ausgesetzt, zumal sie nicht überwacht werden.

Installation, Konfiguration, Härten und Administration von On-Premises-Container-Clustern bindet Ressourcen und kann Kosten und Sicherheitsrisiken verursachen. Aus diesem Grund geht der Trend zu Container as a Service (CaaS). CaaS-Plattformen, wie z.B. Google Kubernetes Engine, Amazon Elastic Container Service, Azure Kubernetes Service und Red Hat OpenShift, abstrahieren die Provisionierung und den Betrieb.

Doch mit der zunehmenden Verlagerung von IT-Infrastruktur in die Cloud vollzieht sich ein Wandel bei der Entwicklung und Bereitstellung von Systemen – besonders hinsichtlich der Sicherheit: Systeme werden von der zugrunde liegenden Hardware und dem Netzwerk abstrahiert. Die Infrastruktur wird durch IaC definiert und der Betrieb erfolgt über Cloud-Service-APIs. Durch die Verlagerung kommen für Sicherheitsteams neue Aufgaben, wie Monitoring und Sicherheitsüberprüfungen von Laufzeitumgebungen in der Cloud, hinzu. Bereitstellung und Betrieb von Diensten in einer cloudnativen Umgebung setzt genaue Kenntnisse des Codes voraus, der Betriebsfunktionen durch Dienste und API-Aufrufe abstrahiert. Die Entwicklung von qualitativ hochwertigem Code erstreckt sich von der Softwareentwicklung bis hin zur System- und Netzwerktechnik – Sicherheits- und Konformitätsrichtlinien im Code, Reviews, Scans, Tests und Monitoring sind dabei essenzielle Bestandteile.

Erweiterung: DevSecOps

Vor diesem Hintergrund ist ein wesentliches Ziel von DevSecOps, IT-Sicherheitsaspekte sehr früh in den Lebenszyklus der Applikationsentwicklung zu integrieren, um somit potenzielle Schwachstellen zu eliminieren. Eine frühe Verankerung von Sicherheitsmechanismen im Sinne des Security by Design (auch „Shift-Left“-Ansatz genannt) und damit die Verlagerung der Sicherheitsverantwortung zum Entwicklungsteam bedingen eine hohe Automatisierung zwischen Softwareentwicklung und Security. Mit dem kontinuierlichen Testen entsteht sogar der „Shift-Left/Test-Everywhere“-Ansatz einher, der einen tiefgreifenden Wandel im Ansatz zur Sicherung digitaler Assets darstellt.

Elemente einer DevOps-Strategie
Nach [10] setzt sich eine erfolgreiche DevSecOps-Strategie aus vier Phasen zusammen:

  • Der Prozess beginnt mit dem Code, aus dem die einzelnen Anwendungen bestehen, gefolgt von Infrastrukturkonfigurationen, Abhängigkeiten zwischen Anwendungen und den Sicherheitsrichtlinien des Unternehmens selbst. In der Entwicklungsphase wird Code erstellt und an die zentrale Ablage übergeben.
  • Es folgt die Phase der Continuous Integration (CI), in der die CI-Pipeline automatisch ausgeführt wird und Skripte die Anwendung zusammensetzen – Funktionstests, eine statische Code-Analyse und Security-Unit-Tests folgen unmittelbar.
  • In der Phase des Continuous Deployment (CD), die nach Abschluss der Tests beginnt, wird die Anwendung gepackt und automatisch in der Produktionsumgebung bereitgestellt.
  • Selbstverständlich muss die neue Version der Anwendung in der Produktionsumgebung mittels Monitoring überwacht werden, um eine Fehlerfreiheit und den Funktionsumfang sicherzustellen.

In diesen Phasen sollten DevSecOps-Teams automatisierte Tests auf den Code mit kürzestmöglichen Durchläufen anwenden, um diesen (vor allem) gegen neue Schwachstellen schützen zu können. DevOps-Praktiken helfen im Allgemeinen nur bei der Infrastruktur-Automatisierung. Die Bereitstellung von Infrastruktur bis hin zu ganzen IT-Service-Umgebungen, einschließlich der Provisionierung von Umgebungen mit Betriebssystemen und deren Security-Patches, Datenbanken, Netzwerkeinstellungen, Speicherplatz, Systemkonfigurationen und Nutzerberechtigungen kann mithilfe von Automatisierungswerkzeugen mit minimalem Aufwand erfolgen [9].

Mit dem Ziel der sogenannten Agile Security als neues Paradigma im Information-Security-Management sollen auch im Informationssicherheitsmanagement manuelle Prozesse durch automatisierte ersetzt werden. Bei der agilen Sicherheit geht es darum, einen dynamischen Informationsaustausch innerhalb der Organisation herzustellen: Sicherheitskritische Informationen sind unmittelbar an entsprechende, potenziell gefährdete Funktionen weiterzugeben, sobald Bedrohungen erkannt sind. Das benötigt in den Funktionen der Prozesse selbst integrierte Sicherheitsfunktionen, um schnell reagieren zu können.

Im Idealfall umfasst DevSecOps Prozesse und Tools, die auch Compliance-Tests abdecken: Manuelle Checklisten und Audits sind ebenfalls durch automatisierte Tests und Überprüfungen zu ersetzen, da sich Code und Infrastruktur täglich ändern können. Das automatische Ausführen von Tests bei jeder Code-Änderung hat sich in der Softwareentwicklung bewährt. Security-Teams automatisieren Teile des Code-Reviews (White-Box-Testing) mit Tools für Code-Qualität, statischer Code-Analyse, Dynamic Application-Security-Testing, Container-Scans, Compliance-Prüfungen, Fuzzing et cetera. Mittels DevSecOps-Security-Testing können Entwickler auch in die Pipelines für Continuous Integration und Continuous Deployment (CI/CD) integriert werden, sodass sie Tests und eventuelle Nacharbeiten selbst erledigen können. Sicherheit und Qualitätssicherung laufen somit nicht mehr getrennt von der Software-Entwicklung ab.

Shift Left, Test Everywhere

Sicherheitsmängel sind teuer, aber auch die Beseitigung dieser Mängel ist kostspielig – gerade dann, wenn man sie auf der „rechten Seite“ des Bereitstellungszyklus oder gar erst am Ende entdeckt. In der konventionellen Entwicklungspipeline wird beim Testen von Anwendungssicherheit fast immer die rechte Seite der Entwicklungspipeline (Deployment) bevorzugt (siehe innere Pipeline) – viele andere Punkte sind jedoch in der Pipeline für Sicherheitsanalysen gegeben. Abbildung 1 zeigt Möglichkeiten der Positionierung von Sicherheitstests – rote Kästen verdeutlichen Punkte mit essenziellen Sicherheitstests, graue können sich entweder auf die Security auswirken oder auch nicht.

Grundvoraussetzung sollte eine initiale Sicherheitsanalyse sein, gefolgt von einem soliden Testplan. Darin müssen nicht nur die Verantwortlichkeiten, Assets, Schritte und Zyklen beschrieben sein, sondern auch die Archivierung der Ergebnisse festgeschrieben werden. Die Verwaltung dieser Informationen in einem Repository, wie beispielsweise GitHub, sollte selbstverständlich sein.

Scan-Werkzeuge können mit Code-Reviews die Code-Basis kontinuierlich verbessern und Schwachstellen frühzeitig identifizieren – in diesem Kontext spielen Static Application Security Testing (SAST) und Dynamic Application Security Testing (DAST) eine gewichtige Rolle: SAST-Tools analysieren nicht-kompilierten Quellcode, Bytecode und Binärdateien auf Codierungs- und Designbedingungen, um daraus Schwachstellen ableiten zu können (z. B. Pufferüber- oder -unterläufe, Sicherheitsschwachstellen, Zeigerfehler, Freisetzung von Nicht-Heap-Speicher, Speicherlecks, Timing-Anomalien, eingebettete Secrets, tote oder ungenutzte Quellcode-Segmente). Die vorrangig programmiersprachenspezifische Analyse erfolgt in der nicht-laufenden Anwendung. Zu den sprachunabhängigen SAST-Tools gehören beispielsweise Sonarqube (www.sonarqube.org), Sentry (https://sentry.io), Coverity (www.synopsys.com/software-integrity/security-testing/static-analysis-sast.html), Checkmarx (https://info.checkmarx.com) und Veracode (https://info.veracode.com). High-Level-Open-Source Frameworks wie semgrep (https://semgrep.dev) und CodeQL (https://securitylab.github.com/tools/codeql/) unterstützen das Erstellen benutzerdefinierter Regeln für individuelle Prüfungen. Im Code oder in Repositories eingebettete Credentials lassen sich durch Tools wie OWASP Sedated (https://owasp.org/www-project-sedated), git-secret (https://git-secret.io) und truffleHog (https://github.com/topics/trufflehog) detektieren.

Anders als bei SAST vermögen DAST-Verfahren eine laufende Anwendung zu analysieren: Sie ermöglichen dynamische Scans von Webanwendungen und APIs in späteren Phasen in der CI/CD-Pipeline, nachdem der Code erstellt und das System für Funktionstests, Integrationstests und Abnahmetests zur Verfügung gestellt wurde. Beispielsweise können Bedingungen, die auf eine Sicherheitslücke hindeuten, Probleme bezüglich der Authentifizierung und Autorisierung, clientseitige Angriffe, SQL-Injection sowie Schnittstellen und API-Endpunkte simuliert und erkannt werden. Während die meisten DAST-Lösungen nur exponierte HTTP-, HTML-, REST- und SOAP-Schnittstellen webfähiger Anwendungen verarbeiten, lassen sich auch solche finden, die speziell für Fehlfunktionen von Nicht-Web-Protokollen wie RPC und Callbacks konzipiert sind. Bekannte Vertreter wären beispielsweise: Metasploit/Rapid7 (www.rapid7.com/de/products/metasploit/), die Burp Suite (https://portswigger.net/burp), Nikto2 (https://cirt.net/nikto2), Arachni (www.arachni-scanner.com), das OWASP ZAProxy (www.zaproxy.org), SQLMap (https://sqlmap.org), Lynis (https://cisofy.com/lynis/) sowie Accunetix (https://www.acunetix.com/).

Der Vollständigkeit halber ist an dieser Stelle auch Interactive Application Security Test (IAST) genannt, wobei man Code interaktiv analysiert – entweder automatisiert durch ein spezielles IAST-Tool oder manuell durch einen Menschen.

Darüber hinaus machen im Allgemeinen sogenannte Unit Tests den größten Teil der Prüfungen in einer automatisierten Testsuite aus: Das sind automatisierte Tests, die von Entwicklern geschrieben werden, um die Logik des Codes zu prüfen. Sie spielen eine wichtige Rolle und sollten Aspekte der Authentifizierung, Verschlüsselung, Protokollierung und allem voran die Zugriffskontrolle und Berechtigungen, die von der Geschäftslogik und der Organisationsstruktur abhängen, berücksichtigen.

Sicherheit der Entwicklungs-Pipeline

Jedoch ist der Fokus nicht alleinig auf den Test von Anwendungen entlang der Pipeline zu legen – schließlich sind sie selbst sowie ihre Umgebung genauso wichtig: Automatisierte Build- und Deployment-Pipelines bieten einen direkten Weg von der Entwicklung zur Produktion, was sie zu einem interessanten Ziel für Angreifer macht. Repositories oder die Build-Chain könnten kompromittiert werden. Einschleusen von Malware in den Produktionsprozess wäre ohne ein Eindringen möglich. Ein Beispiel ist der Angriff auf SolarWinds, wobei im Jahre 2020 Angreifer die Malware „Sunburst“ auf Systeme von bis zu 18 000 Nutzern der Netzwerkmanagement-Plattform SolarWinds Orion eingeschleust hatten.

Um das Einschleusen von bösartigem Code in die CI/CD-Umgebung zu verhindern, ist jeder Teil der Pipeline von Bedeutung: Quellcode- und Artefakt-Repositories, CI/CD-Toolchain-Konfiguration und -Laufzeit, verwendete Schlüssel und andere Credentials sowie die Infrastruktur für die Ausführung von Services. Deshalb ist anzuraten, Penetrationstests und Scans der Pipeline-Tools selbst durchzuführen. Hier können Tools wie Tenable Nessus (www.tenable.com), Qualys (www.qualys.com) oder Rapid7 nexpose (www.rapid7.com/try/nexpose/) interessant sein. Es ist anzumerken, dass Sicherheitstests naturgemäß keine Fehlerfreiheit garantieren – sie sind vielmehr ein Mittel, um allen am Prozess Beteiligten auf mehreren Ebenen eine Einschätzung der Softwarequalität zu geben und diese zu erhöhen.

Abbildung 1

Abbildung 1: Mögliche Sicherheitstests entlang der Pipeline (nach [11])

Cloud-Dienste und Bereitstellung per IaC

Auch der Einsatz von heterogenen Cloud-Umgebungen ist mit Risiken verbunden. Vor diesem Hintergrund müssen sich Sicherheitsteams mit verschiedenen Sicherheits- und Datenschutzmodellen, Identitätsmanagement, Zugriffskontrollsystemen, Datenspeicherung, Verschlüsselung, Überwachung, Konfigurationssprachen, Compliance- und Sicherheitsrichtlinien und APIs auseinandersetzen, um die Plattformen der Anbieter (z. B. Amazon Web Services, Microsoft Azure und Google Cloud Platform) genau zu kennen [12]. Nicht selten entsteht ein Mix aus in der Cloud gehosteten virtuellen Maschinen, gehosteten Containern und serverlosen Plattformen – die damit einhergehende Komplexität in Sachen Sicherheit und Compliance wächst enorm, besonders wenn mehrere verschiedene Cloud-Anbieter gleichzeitig genutzt werden. Sicherheit in Multicloud-Umgebungen ist kein einfaches Unterfangen, eine Orientierung könnte das SANS Whitepaper „Top 5 Considerations for Multicloud Security“ [13] geben.

Bei VMs sind Betrieb, Sicherheit und Konfigurationsmanagement Anwendersache. Die durch den Cloud-Anbieter zur Verfügung gestellten automatischen Standard-Netzwerk- und Firewall-Regeln können unbeabsichtigt Ressourcen freigeben – diese Regeln muss der Anwender vorsorglich überprüfen. Bei Containern ist es eher unkritisch, da das Patchen von VMs und das Härten der Container-Laufzeitumgebung Aufgaben des Anbieters sind, sodass sich der Anwender auf die Anwendungen und ihre Build-/Laufzeitabhängigkeiten der Container-Images konzentrieren kann. Dennoch ist zu empfehlen, Container-Plattformen auf Fehlkonfigurationen, Default-Einstellungen sowie unnötige Berechtigungen zu prüfen. Anbieter scannen in Cloud-Registries verwaltete Container-Images nicht automatisch auf Schwachstellen – das Erkennen und Reagieren auf Bedrohungen und Angriffe ist mit entsprechenden Systemen und Tools eine Aufgabe des Anwenders. Bei serverlosen Plattformen ist für das Härten der Container-Images und das Patchen der zugrunde liegenden Laufzeitumgebung hingegen der Anbieter verantwortlich. So kann sich der Anwender auf die Entwicklung, das Berechtigungskonzept und das Testen der Anwendung konzentrieren. Schutzmechanismen wie Cloud Workload Protection Platforms (CWPPs) und andere Systeme zum Schutz der Laufzeitumgebung sollten hierbei Berücksichtigung finden.

Des Weiteren ist in diesem Kontext der Einsatz von Network-Detection-and-Response (NDR) sowie Network-Traffic-Analysis (NTA) nennenswert, um die Netzwerkkommunikation in hybriden Cloud-Architekturen und containerbasierten Microservices zu beobachten. Sie bieten einen tieferen Einblick in den Netzwerkverkehr und nutzen maschinelles Lernen, um Bedrohungen und Angriffe in Echtzeit zu erkennen.

Mit IaC können DevOps-Teams ihre eigene ITInfrastruktur bereitstellen, ohne Details der zugrunde liegenden Technik (d. h. Server, Speicher und Netzwerk) verstehen und betreiben zu müssen. Konfigurationen von Cloud-Infrastrukturen durch Code ermöglichen Kontrollstrukturen für Sicherheit und Compliance. Konfigurationsänderungen können in die Versionskontrolle
eingespeist, automatisch gescannt und getestet werden, um Konfigurationsfehler zu erkennen. Die damit erzielte Transparenz der Laufzeitarchitektur und -konfiguration trägt zu einem besseren Verständnis von Risiken bei.

Deklarative Konfigurationssprachen und Cloud-Sicherheit

Deklarative Konfigurationssprachen wie AWS CloudFormation (https://aws.amazon.com/de/cloudformation/), Azure Resource Manager (https://docs.microsoft.com/de-de/azure/azure-resource-manager/management/overview) und Google Deploy Manager (https://cloud.google.com/deployment-manager/docs?hl=de) sowie plattformübergreifende Tools wie Terraform (www.terraform.io) unterstützen die Modellierung, Konfiguration und Bereitstellung – mit iterativen und inkrementellen Änderungen in Laufzeitkonfigurationen [12].

In diesen Umgebungen können auch statische Analysetools Einsatz finden, um zum Zeitpunkt der Erstellung Inkonsistenzen oder Probleme in Cloud-Konfigurationen zu detektieren. Mit Scan-Tools lassen sich nicht nur Syntax und Semantik, sondern auch Sicherheitslücken und Schwachstellen sowie Konfigurationen zur Einhaltung von Compliance-Richtlinien überprüfen. Zu den bekannten Open-Source-Tools zählen terrascan (https://github.com/accurics/terrascan), checkov (https://github.com/bridgecrewio/checkov), tfsec (https://github.com/tfsec/tfsec), cfn_nag (https://github.com/stelligent/cfn_nag) und kics (https://github.com/Checkmarx/kics).

Eine kontinuierliche Überwachung von Cloud-Infrastrukturen auf Lücken in der Durchsetzung von Sicherheitsrichtlinien ist mittels Cloud-Security-Posture-Management (CSPM) möglich. Dieser von Gartner geprägte Begriff beschreibt Lösungen zur Automation der Sicherheit und der Compliance in der Cloud. CSPM-Tools untersuchen und überwachen eine Cloud-Umgebung anhand eines definierten Satzes von Best Practices und bekannten Sicherheitsrisiken (vgl. etwa [14]). Sie scannen Cloud-Instanzen automatisch, um häufige Konfigurationsfehler und bekannte Bedrohungen zu erkennen und um Sicherheits- und Compliance-Richtlinien durchzusetzen. Open-Source-Beispiele sind unter anderem Cloud Custodian (https://github.com/cloud-custodian/cloud-custodian), Prowler (https://github.com/toniblyx/prowler) und Cloudsploit (https://github.com/aquasecurity/cloudsploit).

Wenn es um den Schutz von Laufzeitumgebungen für Container und Cloud-Instanzen geht, kommen CWPP ins Spiel: Sie umfassen Dienste mit unterschiedlichen Stufen und Arten, einschließlich Netzwerksegmentierung, Systemintegritätsschutz, Anwendungskontrolle, Whitelisting, Verhaltensüberwachung, hostbasierte Intrusion-Prevention-Systeme (IPS) und optional Malwareschutz. Vertreter im Open-Source-Bereich sind Falco (https://github.com/falcosecurity/falco) und sysdig (https://github.com/draios/sysdig).

Mit der Migration zur Cloud muss sich die Softwareentwicklung zwangsweise auch mit neuen Programmiersprachen und Tools beschäftigen. Skriptsprachen wie Javascript und Python bergen das Risiko von unsicherem Code, da sie in hohem Grade Open-Source Softwarepakete wie beispielsweise pip (https://pip.pypa.io/en/stable/) und npm (https://www.npmjs.com) nutzen – so entstehen neue Klassen von Verwundbarkeiten.

Security-Aspekte der Schnittstellen

API-Sicherheit sollte eine ganzheitliche Betrachtung von Sicherheitsrisiken auf Netzwerk- und Systemebene, Nachrichten- und Transportsicherheit, Authentifizierungs- und Autorisierungsprotokolle unter Einbindung von Schwachstellentests [15] umfassen. Folgende wesentliche Bereiche sollten abgedeckt sein:

  • Anwendungssicherheit: Vermeiden von Sicherheitslücken im Anwendungscode
  • Systemsicherheit: Zugriffskontrolle auf Ressourcen wie Daten und Betriebssystemdateien
  • Netzwerksicherheit: Verhinderung und Überwachung von unbefugtem Zugriff, Missbrauch, Datenveränderung und Zugriffskontrolle auf das Unternehmensnetzwerk sowie Ressourcen darin.

Der zweite Teil dieses Beitrags mit Aspekten und Hinweisen zur Umsetzung von DevSecOps erscheint in der folgenden kes 2022#1

Prof. Dr. Evren Eren lehrt an der City University of Applied Sciences Bremen und forscht zu Mobile sowie IT-Security, Virtualisierung und Clouds.

Literatur

[1] Dr. Stefan Beißel, DevOps aus Sicherheitsperspektive, <kes> 2014#6, S. 6
[2] Lücken zwischen DevOps und Security, Meldung auf Basis des Application Security and DevOps Report 2016 von Hewlett Packard Enterprise (HPE), <kes> 2016#6, S. 76
[3] Joakim Verona, Practical DevOps, Packt Publishing, Mai 2018, ISBN 978-1-78839-257-0
[4] Gene Kim, Jez Humble, Patrick Debois, John Willis, Das DevOps-Handbuch, Teams, Tools und Infrastrukturen erfolgreich umgestalten, O‘Reilly, Juli 2017, ISBN 978-3-96009-047-2
[5] David Farley, Jez Humble, Continuous delivery, A handbook for building, deploying, testing and releasing software, Addison-Wesley, Juli 2010, ISBN 978-0-321-67025-0
[6] Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas, Prinzipien hinter dem Agilen Manifest, 2001, https://agilemanifesto.org/iso/de/principles.html
[7] Toyota Motor Corporation, Toyota Production System, https://global.toyota/en/company/vision-and-philosophy/production-system/
[8] Sricharan Vadapalli, DevOps: Continuous Delivery, Integration, and Deployment with DevOps, Packt Publishing, März 2018, ISBN 978-1-78913-299-1
[9] Jürgen Halstenberg, Bernd Pfitzinger, Thomas Jestädt, DevOps, Ein Überblick, Springer, Oktober 2020, ISBN 978-3-658-31404-0
[10] Rohde & Schwarz, DevSecOps vs. DevOps: Der Hauptunterschied, www.rohde-schwarz.com/de/loesungen/cybersicherheit/devsecops/devsecops-uebersicht_253772.html
[11] Tom Porter, DevSecOps – A New Chance for Security, DZone, Mai 2018, https://dzone.com/articles/shiftingleft-devsecops
[12] Jim Bird, Eric Johnson, Frank Kim, Rethinking the Sec in DevSecOps: Security as Code, A SANS Survey, Juni
2021, erhältlich über https://info.veracode.com/sans-survey-rethinking-the-sec-in-devsecops.html (Registrierung
erforderlich)
[13] Brandon Evans, Top 5 Considerations for Multicloud Security, SANS/GIAC Whitepapter, April 2020, https://sansorg.egnyte.com/dl/qEe8zHKbkd/
[14] Alexander S. Gillis, Cloud Security Posture Management, Definition und Überblick, ComputerWeekly, www.computerweekly.com/de/definition/Cloud-SecurityPosture-Management-CSPM
[15] 42Crunch, API Security in the Enterprise – How a DevSecOps Approach Delivers Reliable API Security, Whitepaper, 2021, https://42crunch.com/white-paperapi-security-enterprise/ (Registrierung erforderlich)

Diesen Beitrag teilen: