Als weltweit tätiger DevOps-Experte für Splunk führe ich mit vielen verschiedenen Kunden Gespräche, bei denen es in der Regel in erster Linie um Probleme mit dem Planungsprozess, der Systemgenerierung und dem Release-Framework geht.
In jüngerer Zeit habe ich Kunden jedoch überraschen können, indem ich sie gefragt habe, wie sie es in ihrem SDLC-Prozess mit der Sicherheit halten und ob die Kommunikation mit ihrem Security Operations-Team positiv und offen abläuft.
In den meisten Fällen guckt mich der Kunde an, "wie die Kuh wenn‘s donnert“ und fragt mich dann, wie sich Sicherheit in die DevOps-Pipeline implementieren lässt, ohne dass jemand aufwendige Arbeiten erledigen muss. Hier sind die drei wichtigsten Punkte, die ich Kunden zur Absicherung eures SDLC-Prozesses empfehle.
Planung und Codeüberprüfung
Dies ist die erste wichtige Datenquelle, die die meisten Kunden übersehen, obwohl sie tatsächlich signifikante Anomalien erkennen könnten. Viele Kunden sind an herkömmliche ITIL-Prozesse gewöhnt, bei denen Änderungen in einem Datensystem dokumentiert werden, sodass alle Beteiligten Einblick in neue Tätigkeiten erhalten. Oftmals erkennen sie jedoch nicht, dass DevOps-Teams Datensysteme auch einsetzen können, um Änderungen und Aufgaben zu dokumentieren und allen Teams Einblick zu verschaffen. Indem sie eine Task-, EPIC- oder Print-ID mit einem Repository-Commit oder einer Änderungsanfrage korrelieren, können Sicherheitsteams erkennen, ob eine neue Entwicklung Teil einer geplanten Änderung ist oder ob eine nicht genehmigte Änderung bevorsteht.
Wenn sich Entwickler anschicken, Code an einen Master Branch zu übertragen, ist die gegenseitige Überprüfung, bevor ein Pull-Request entsteht, entscheidend und lässt sich problemlos in demselben Prozess dokumentieren. Indem Tickets mit Commits korreliert werden und indem diese Daten anschließend mit dem Build-System verbunden werden, erhalten Sie erstaunliche Einblicke, die dem Sicherheitsteam nutzen und das Geschäft insgesamt schützen.
Build Chain-Automatisierung
Auf dem weiteren Weg durch die Pipeline empfehle ich eine zweite Verteidigungslinie, um das zu schützen, was in Produktion geht. Durch mehrstufige Build-Pläne profitieren Entwicklungsteams nicht nur von einer besseren Organisation, sondern auch davon, dass jede einzelne Phase des Gesamtprozesses getestet wird. Grundlegende Tests wie Komponenten- und Funktionstests ermöglichen es den Teams, einfache Fehler in den Griff zu bekommen. Dank automatischer Code-Scanning-Tools lassen sich technischer Aufwand, Zeilenzahl und Komplexität besser beleuchten. Was aber wirklich einen Unterschied macht, ist die Verwendung von Tools, die Module scannen und auf Schwachstellen testen. Diese Tools überprüfen automatisch Unterschriften und CVE-Zuordnungen und können so feststellen, ob der freizugebende Code ein größeres Risiko für das Unternehmen darstellt.
Indem sie die Daten aus diesen verschiedenen Tools korrelieren, können Sicherheitsteams Key Security Indicators (KSIs) dokumentieren, sodass die mit dem Release-Vorgang betrauten Teams wissen, ob ein bestimmtes Artefakt für die Produktion bereit ist. Wenn diese Daten mit Daten aus dem Planungsprozess und dem Build-System korreliert werden, bedeutet das, dass Sicherheitsteams mehr Zeit mit Durchdringungstests und Compliance-Fragen zubringen können, während gleichzeitig eine reibungslose DevOps-Kultur ermöglicht wird.
Release und Überwachung
Die dritte – und hoffentlich letzte – Hauptverteidigungslinie ist die Automatisierung eurer Umgebung. Indem ihr das Konzept der Datenkorrelation aus euren Planungs-, SCM-, Build- und Testsystemen übernehmt, könnt ihr zudem sicherstellen, dass eure Konfigurationskataloge konsistent sind. Wenn ihr einen datengestützten Ansatz verwendet, um einen tieferen Einblick in eure Umgebung zu gewinnen, können eure Release-Teams neue Konfigurationen und Einstellungen ohne Sicherheitsbedenken und ohne unerwartete Überraschungen veröffentlichen.
Automatisierungs-Frameworks wie Puppet unterstützen euch z. B. nicht nur bei der Bewältigung eurer Arbeit, sondern sorgen zusätzlich für eine Compliance-Ebene. Wenn bei einer Konfiguration die Compliance nicht sichergestellt ist, könnt ihr z. B. allein aufgrund des Potenzials von Splunk in Verbindung mit der Puppet-Automatisierung und der Möglichkeit zur Generierung von KSI für euer gesamtes Team nachts ruhig schlafen. Dadurch können eure Entwickler sich auf die Optimierung eures Produkts konzentrieren und müssen nicht eine Verteidigungslinie nach der anderen aufbauen, was zur Erhöhung der Latenz und damit zu schlechteren Kundenerfahrungen führen würde.
DevSecOps in die Tat umsetzen
Wenn ihr euch eure DevOps-Pipeline anseht, wie sie sich heute darstellt, würdet ihr sagen, dass ihr insgesamt die richtigen Maßnahmen ergreift, um eure Teams und, was am wichtigsten ist, eure Kunden zu schützen? Wenn nicht, nehmt euch die Zeit, importiert eure Daten in Splunk und schaut euch an, was ihr alles zur Risikominimierung tun könnt. Manchmal dauert es nur 15 Minuten, eure Überlegungen auf einem Whiteboard festzuhalten und gemeinsam mit eurem Team darüber nachzudenken, wo die Probleme liegen. Lasst uns zusammenarbeiten, um die Welt der herkömmlichen IT zu verändern und die nächste DevSecOps-Generation voranzubringen.
----------------------------------------------------
Vielen Dank!
Domnick Eger
*Dieser Artikel wurde aus dem Englischen übersetzt und editiert. Den Originalblogpost findet ihr hier: Why DevSecOps is the Next Generation of IT
