DevSecOps ist eine Weiterentwicklung des DevOps-Ansatzes und hat sich als eine effektive Methode etabliert, um die Sicherheit in den Entwicklungs- und Betriebsphasen von Softwareprojekten zu integrieren. Während DevOps und SecOps ähnliche Ziele verfolgen – schnellere Bereitstellung, kontinuierliche Integration und Verbesserung der Qualität – gibt es bestimmte Unterschiede in ihren Erwartungshaltungen, insbesondere in Bezug auf die *Day-2 Operations. In diesem Blog-Post von f5 werden wir uns mit den Herausforderungen und den unterschiedlichen Erwartungshaltungen von DevOps und SecOps im Bereich Web Application Firewall Policy Management befassen und wie diese erfolgreich miteinander verbunden werden können.
DevOps vs. SecOps – Was sind die Erwartungshaltungen?
- DevOps: DevOps-Teams haben traditionell den Fokus auf die schnelle Bereitstellung von Software und kontinuierliche Verbesserung gelegt. Ihre Hauptziele umfassen die Automatisierung von Bereitstellungen, die kontinuierliche Integration und Bereitstellung (CI/CD), die Skalierbarkeit und Verfügbarkeit von Anwendungen sowie die Zusammenarbeit zwischen Entwicklung und Betrieb. DevOps-Teams erwarten, dass Day-2 Operations reibungslos ablaufen, ohne dabei die Geschwindigkeit der Bereitstellung zu beeinträchtigen. Sie möchten Fehler schnell beheben, die Benutzererfahrung optimieren und kontinuierlich neue Funktionen bereitstellen.
- SecOps: SecOps-Teams sind für die Sicherheit der IT-Infrastruktur und Anwendungen verantwortlich. Ihr Hauptziel besteht darin, Bedrohungen zu erkennen, Risiken zu minimieren und Sicherheitsvorfälle zu verhindern. Die Erwartungshaltung von SecOps umfasst die Identifizierung und Behebung von Schwachstellen, die Überwachung der Sicherheitssysteme, die Einhaltung von Richtlinien und Standards sowie die Zusammenarbeit mit Compliance-Teams. SecOps-Teams erwarten, dass Day-2 Operations die Sicherheit gewährleisten, Bedrohungen schnell erkennen und darauf reagieren, potenzielle Sicherheitslücken schließen und Sicherheitsrichtlinien durchsetzen.
Die Herausforderungen der Day-2 Operations in DevSecOps:
Die unterschiedlichen Erwartungshaltungen von DevOps und SecOps können zu Spannungen und Herausforderungen in den Day-2 Operations führen. DevOps-Teams konzentrieren sich oft auf die Funktionalität und die Erfüllung von Geschäftsanforderungen, während SecOps-Teams sich auf die Sicherheit und Risikominimierung konzentrieren. Aus unserer Erfahrung treffen wir dabei oft auf unterschiedliche Erwartungshaltungen – gerade in Bezug auf das Management der Security Policy, dem False Positive Management und dem Bereitstellen eines Log-Analyse Tools.
Ein Kernproblem – „wo sind wir gestartet“:
Während DevOps-Teams wenig Berührungsängste mit Verfahren und Tools wie Git, Grafana, Scripting und JSON/YAML-Konfigurationen haben, um die Sicherheits-CI/CD-Pipeline eigenständig zu erstellen, sehen wir viele SecOps-Teams mit einer anderen Erwartungshaltung. Sie möchten eine Lösung, die das Betreiben der Web Application Firewall (WAF) ermöglicht, ohne dass SecOps hier noch zusätzliche Aufgaben „bauen“ muss.
Historisch gesehen bieten viele WAF-Hersteller genau solche Tools an. Diese ermöglichen es, aus einem gemeldeten Vorfall die entsprechenden Logs zu finden, diese zu analysieren und gegebenenfalls Ausnahmen zu definieren.
„GREP doch einfach nach „/var/log/waf.log“ und suche den false positive. Die Policy liegt dann auf einem GIT-Repository – einfach WAF_policy.yaml editieren“ Viele SecOps-Administratoren fühlen sich durch diesen Satz wie in die Vergangenheit versetzt, etwa um 20 Jahre zurück. In der Tat waren die Bemühungen von Enterprise WAFs darauf ausgerichtet, potenzielle Angriffe zu stoppen und gleichzeitig sicherzustellen, dass die WAF einfach zu betreiben ist. Das oben zitierte übertriebene Beispiel kann oft der Beginn vom Ende eines solchen Projekts sein. DevOps versteht oft nicht, warum man nicht einfach ein Dashboard erstellen kann. SecOps hat jedoch keine Zeit, sich mit Dingen auseinanderzusetzen, die bisher als Standard galten. In der Regel wird dies erst in der Day-2-Phase deutlich. Während der Projektphase lässt sich eine Standardrichtlinie schnell erstellen. Das Betreiben dieser Richtlinie wird dann zu einem (organisatorischen) Problem.
Die Brücke zwischen DevOps und SecOps:
Um Day-2 Operations in DevSecOps erfolgreich umzusetzen, ist eine enge Zusammenarbeit zwischen DevOps- und SecOps-Teams unerlässlich. Beide Seiten sollten ihre Erwartungshaltungen klar kommunizieren und gemeinsame Ziele definieren. Das Einbeziehen von Sicherheitsaspekten bereits in den frühen Phasen des Entwicklungsprozesses hilft dabei, potenzielle Schwachstellen frühzeitig zu identifizieren und zu beheben. Aus unserer Erfahrung heraus ist ein „Mehr-Schicht-Ansatz“ sinnvoll und ratsam, bei dem eine WAF-Policy von SecOps mit generischen Regeln verwaltet wird und das Applikationsteam eine spezifische Policy verwaltet.
Unabhängig von der organisatorischen Aufstellung müssen im Projekt jedoch auch Aspekte wie das Log-Policy Management berücksichtigt werden – gerade hier sehen wir viele Diskussionen – zum Teil aus Unverständnis der Erwartungshaltungen. Es sollten Verfahren entwickelt werden, um Policies aus einem Ereignis zu erstellen, ohne dass der SecOps-Administrator auf das Git zugreifen und Policies manuell bearbeiten muss (was auch fehleranfällig sein kann).
Gerne möchten wir dieses Policy Management anhand eines Beispiels verdeutlichen. Wir bei NGINX verwenden dabei eine Web Application Firewall, welche auf dem Ingress Controller installiert ist, und die Web Applikationen in einer Kubernetes Umgebung absichert.
NGINX Ingress Controller + WAF + Tools
Anhand des Beispiels des NGINX Ingress Controllers (OpenSource) mit der NGINX WAF (Enterprise Add-On) wird auf dem F5/NGINX Community Git [1] sehr gut erklärt, welche Schritte erforderlich sind, um dieses Problem zu lösen.
In diesem Beispiel sind die Network-Access-Protection-Instanzen, die auf Kubernetes/Docker/VMs ausgeführt werden, so konfiguriert, dass sie ihre Logs an Logstash senden. Logstash transformiert die empfangenen Protokolle und speichert sie in Elasticsearch-Indizes. Dadurch können nun SecOps-Teams z.B. Grafana-Dashboards nutzen, um eine konsolidierte Ansicht aller NAP-Ereignisse zu erhalten und mögliche Bedrohungen sowie falsch positive Ergebnisse zu identifizieren.
Die Dashboards, welche über das GIT bereitgestellt werden, richten sich dabei nach den Bedürfnissen / Erfahrungen der der Sec-Admins. Dabei sind verschiedene Sichtweisen relvant. Von einer schnellen Übersicht über die „allgemeine Sicherheitslage“ bis hin zu einem einzigen gemeldeten Event mit Kontextinformationen wer, wann was, …
Hier fragt Grafana Elasticsearch nach den relevanten Daten ab, die auf den Dashboards visualisiert werden. Mit dieser Grundlage ist SecOps in der Lage, sich einen schnellen Überblick zu verschaffen und Log Analysen zu betreiben (sei es um die Sicherheitslage zu beurteilen – oder um False-Positives zu verifizieren). Das Logging / die Visualisierung ist aber nicht die einzige Herausforderung. Die WAF Policy, wenn auf GIT gespeichert, folgt einer json/yaml Syntax (Security-as-a-Code).
Wieder ein Zeitsprung nach „früher: Vorher war alles strukturiert innerhalb einer UI gelöst – jetzt muss es „geschrieben“ werden. Eine simple WAF Policy (default – ohne Einträge) sieht in unserem Beispiel etwa so aus.
{
"policy": {
"name": "policy_name",
"template": {
"name": "POLICY_TEMPLATE_NGINX_BASE"
},
"applicationLanguage": "utf-8",
"enforcementMode": "blocking"
}
}
Soll etwas editiert werden, bedeutet dies, dass die Syntax aus der Dokumentation geholt wird, 2] um den jeweiligen „Absatz“ im json/yaml zu editieren. Bei einem manuellen Prozess ist dies nicht nur aufwändig, sondern auch fehleranfällig.
Zwar ist Automatisierung das moderne „42“ [3] – aber in einer dynamischeren Umgebung nicht frei von Fehlern. Zwar kann man die Policy in Pre-Production hoch- und runter testen – aber in so einem semi-automatisierten Prozess fällt dies schwerer (WAF, gerade wenn diese nicht eine fixe API mit API Spec absichert, kann dynamischer sein).
Idealerweise sind Tools und Prozesse installiert, die das erlauben. SecOps nutzen und bearbeiten über das Policy-Management-Tool ihre WAF-Richtlinien entweder manuell oder anhand der blockierten und/oder alarmierten Ereignisse. Das Policy-Management-Tool spiegelt die Änderungen, die vom SecOps-Team an den JSON/YAML-Richtlinien vorgenommen wurden, im Git-Repository wieder. Danach benachrichtigt Git das CI/CD-Tool über die Änderungen in den Repository-Dateien. Das CI/CD-Tool erhält eine Kopie der neuen Richtlinien und führt die entsprechende Pipeline aus. Nach erfolgreichem Abschluss der Pipeline wird die neue Konfiguration auf die NGINX NAP-Instanzen übertragen.
Hier setzt das „NAP False Positive Management“ bzw. der „NAP False Positive Manager“ an. Auch dieses Tool stellen wir über Git [1] frei zur Verfügung. Dieses Projekt verfügt über eine einfache Benutzeroberfläche, die in PHP entwickelt wurde. Diese ruft den Sicherheitsverstoß aus Elasticsearch, basierend auf der angeforderten Support-ID (UID für die NGINX WAF Events) ab und präsentiert dem Benutzer eine Zusammenfassung des Ereignisses. Abhängig von den Verstößen, die identifiziert wurden, bietet das Tool dem Benutzer vordefinierte Aktionen zum deaktivieren dieser Verstöße an. Zum Beispiel, „Signatur deaktivieren“ oder „Signatur für URL deaktivieren“. Sobald der Benutzer die Details bestätigt und das Tool so konfiguriert ist, dass es die aktuelle Richtlinie von GitLab abruft, werden die erforderlichen Änderungen an der YAML/JSON-Datei der Richtlinie vorgenommen und in GitLab gespeichert.
In der Beta-Phase befindet sich die Weiterentwicklung von dem o.g. Prozess. Möglicherweise muss die Policy außerhalb von Signaturen editiert werden. Dazu wurde der „NAP Policy Editor“ entwickelt. Ähnlich wie bei FPM bietet das Policy-Editor-Projekt eine einfache Benutzeroberfläche, die ebenfalls in PHP entwickelt wurde. Diese Benutzeroberfläche ruft NAP-Richtlinien aus Git-Repositories ab, analysiert sie und stellt sie dem Benutzer zur Verfügung, um eine Übersicht über alle Einstellungen, Funktionen und Verstöße zu erhalten, die von jeder Richtlinie aktiviert wurden. Der Benutzer kann durch die verschiedenen Konfigurationsabschnitte der Richtlinie navigieren und die gewünschten Änderungen vornehmen. Die Änderungen werden durch den Konfigurations Analysator geprüft und bei erfolgreicher Überprüfung wieder in das ursprüngliche Git-Repository übertragen.
SecOps ist nun in der Lage, Logs zu analysieren, sie zu bewerten (False-Positive: Ja/Nein) und sie dann in die Richtlinie zu integrieren.
Das Fazit:
Day-2 Operations spielen eine wichtige Rolle in der DevSecOps-Praxis, da sie die Erwartungen von DevOps und SecOps in Einklang bringen müssen. Eine effektive Zusammenarbeit, klare Kommunikation und die Integration von Sicherheitsaspekten von Anfang an sind entscheidend für eine erfolgreiche Implementierung von DevSecOps. Es ist wichtig, die Erwartungen beider Teams zu berücksichtigen. Während eine vollständige Automatisierung der WAF-Policy in Test- und Entwicklungsumgebungen mit definierten APIs relativ einfach möglich ist, stellt das tägliche Management von Webseiten, die möglicherweise keine API mit definierten Aufrufen haben, eine Herausforderung dar. Daher ist es wichtig, eine leichtgewichtige parallele Automatisierung anzubieten, beispielsweise für das Management von WAF-Richtlinien und Logs. Dies ist eine Funktion, die jede „traditionelle“ (Enterprise-) WAF bietet, jedoch im Rahmen von DevSecOps neu interpretiert, definiert und erstellt werden muss.
Es mag zunächst paradox erscheinen, dass wir etwas entwickeln, was bereits existiert. Allerdings geht NGINX in diesem Fall weg von der proprietären Software der jeweiligen WAF-Hersteller und migriert stattdessen zu „DevOps“-Tools wie Git, Elastic und Grafana. Es ist jedoch von entscheidender Bedeutung, diese Funktionen dem SecOps-Team zur Verfügung zu stellen, da es sich auf ihre tägliche Arbeitsweise ausrichtet.
In den genannten Projekten hat NGINX die Erfahrung gemacht, dass dieser Ansatz relevant ist und hat beschlossen, diese Tools der Community zur Verfügung zu stellen.
Ab von der präsentierten Lösung basierend auf der NGINX WAF – ist es jedoch wichtig zu beachten, dass dieser Prozess ganzheitlich betrachtet werden sollte und mehr umfasst als nur das Speichern einer JSON-Datei auf einem GIT-Repository mit ARGO CD im Hintergrund. Existieren solche Tools nicht, müssen diese im Projekt entwickelt werden und SecOps „enabled“ werden, um in dem DevOps Tools-Set ihre Bedürfnisse und Anforderungen widerzuspiegeln.
*Day-2 Operations – Definition: Day 2 bezeichnet eigentlich eine Phase aus dem Softwarelebenszyklus und gehört zur DevOps-Welt. Hier bezeichnet er den Moment, in dem die Verantwortung für eine spezielle Version vom Entwicklungs- auf das Betriebsteam übergeht. Quelle: Data Center Insider
[1] https://github.com/f5devcentral/nap-policy-management
[2] https://docs.nginx.com/nginx-app-protect-waf/declarative-policy/policy/
Über den Autor
Martin Petersen – Sr. Solution Engineer bei f5
Seit 2016 für f5 als Solution Engineer tätig. Bis Anfang 2021 als Gebiets-SE in Norddeutschland – und dann in eine übergeordnete SE-Rolle für moderne App-Lösungen in der CEE-Region (Zentral- & Osteuropa) gewechselt. Hauptfokus auf f5 k8s Lösungen, f5 distributed cloud (multi-cloud) und public clouds im Allgemeinen. Vor f5 arbeitete Martin Petersen als Security Engineer / Security Consultant für verschiedene Service Provider mit dem Schwerpunkt Netzwerksicherheitslösungen.
