Umstellung auf DevSecOps
5. April 2019
Die schnelle Einführung von Containern im Unternehmen sind eine interessante Gelegenheit dar, die generelle Sicherheitsstrategie zu verändern. Container stellen eine gute Möglichkeit dar, die Kluft zwischen Entwicklungs- und Sicherheitsteams zu überbrücken. Davon ist Palo Alto Networks überzeugt – dabei dreht sich alles um die Frage: Ist es möglich, dass Container das Unternehmen einen Schritt näher an DevSecOps heranbringen?
Der Computing-Bereich hat mehrere Entwicklungen durchlaufen. Die erste Welle war der Client-Server, der auf Bare Metal mit einem einzigen Betriebssystem und typischerweise einer Anwendung läuft. Die zweite Welle kam, als VMware 2001 mit der Virtualisierungs-Technologie in den Servermarkt einstieg. Dies läutete das Zeitalter des virtualisierten Computings ein. Die dritte Welle kommt mit dem Einsatz von Containern. Die Einführung dieser Technologie steht für die Geschwindigkeit von DevOps und den Wunsch, Anwendungen mobil zu machen. Derzeit noch nicht weit verbreitet im Unternehmen ist die vierte Evolution: Serverless oder Function as a Service (FaaS). Dies stellt eine vollständige Abstraktion des Computings dar, wobei der Verbraucher hardware- und betriebssystemunabhängig ist. Die beiden bekanntesten Implementierungen von FaaS sind Google Cloud Functions und AWS Lambda.
Sicherheit in die Container-Build-Phase zu bringen, bedeutet aber auch, sich auf die physische Konstruktion zu konzentrieren. In Sachen Container-Sicherheit sollte man sich auf die Beseitigung von Schwachstellen, Malware und unsicherem Code konzentrieren. Da Container aus Bibliotheken, Binärdateien und Anwendungscode bestehen, ist es wichtig, dass Unternehmen ein offizielles Container-Register einrichten, wenn es nicht bereits existiert. Es ist die Aufgabe des Sicherheitsteams, hier Sicherheitsstandards umzusetzen.
Images und die Vertrauenswürdigkeit
Das Hauptziel der Identifizierung und Erstellung einer Standard-Container-Registry ist die Erstellung vertrauenswürdiger Images. Ein Prozess muss festgelegt und automatisch durchgesetzt werden, dass kein Container aus einer nicht-vertrauenswürdigen Registry bereitgestellt wird. Mit über zwei Millionen Dockerized-Anwendungen ist Docker Hub wahrscheinlich das bekannteste Container-Register. Das bedeutet, dass es auch eine ideale Basis ist, um ein Gespräch mit den Entwicklern zu beginnen.
In der Bereitstellungsphase verlagert sich der Fokus darauf, dass die Teams die Dinge richtig zusammenstellen. Es kann ein Image vorliegen, das zwar keine Schwachstellen aufweist, aber wenn es auf einem unsicher konfigurierten Kubernetes-Pod bereitgestellt wird, ist das Container-Risiko nicht ausreichend berücksichtigt. Ein Beispiel dafür ist dieser Fall: Die Bedrohungsforschung von Palo Alto Networks ergab, dass 46 Prozent der Unternehmen den Traffic zu Kubernetes-Pods von jeder Quelle akzeptieren.
In der On-Prem-Welt ist dies gleichbedeutend mit der Bereitstellung eines Servers und dem anschließenden Offenlassen des Servers für das Internet. Unternehmen würden dies vor Ort nicht tolerieren, warum aber machen genau das fast die Hälfte der Unternehmen in der Public Cloud? Die Bereitstellung einer sicheren Konfiguration kann durch die Annahme eines Sicherheitsstandards sowohl für die Orchestrierung als auch für die Container-Engine der Wahl erreicht werden. Nicht zu vergessen ist, die notwendigen Prozesse und Tools für die Automatisierung und Überwachung zu installieren. Das Center for Internet Security (CIS) hat hier hervorragende Arbeit geleistet, um Sicherheitsstandards für Docker und Kubernetes zu schaffen, was sich als Ausgangspunkt anbietet. Wenn die Sicherheit richtig umgesetzt ist, sollte nur das „Gute“ es in die Runtime schaffen.
Runtime Security im Fokus
Bei der Laufzeitsicherheit geht es darum, neue Schwachstellen in laufenden Containern zu identifizieren und zu wissen, wie der Normalzustand aussieht. Dazu gehört auch die Untersuchung verdächtiger/anomaler Aktivitäten, die auf Zero-Day-Angriffe hinweisen könnten. Wenn das Sicherheitsteam von Anfang an dabei war (Build-Phase), ist es weitaus weniger komplex, Runtime-Sicherheit umzusetzen, anderenfalls ist es am besten, rückwärts zu arbeiten. Es ist wichtig, zu gewährleisten, dass der Endzustand sicher ist. Wenn man sich aber nur auf die Laufzeit konzentriert, werden die gleichen Probleme wahrscheinlich immer wieder auftreten. Interessanterweise stellte das IBM Systems Sciences Institute fest, dass die Kosten für die Behebung eines Fehlers während der Wartungsphase (d.h. der Laufzeit) 100-mal höher sind als bei der Konstruktion.
Die schnelle Einführung von Containern im Unternehmen stellt nach Meinung von Palo Alto Networks eine einzigartige Möglichkeit dar, die Sicherheit zu verändern. Wenn Sicherheit von Anfang an in den Entwicklungszyklus integriert wird, werden sowohl das Sicherheitsteam als auch die Entwicklungsabteilung ein erhöhtes Verantwortungsbewusstsein spüren. Unternehmen können dies erreichen, indem sie ihre Sicherheitsbemühungen auf die Container-Sicherheitstriade Build, Deployment und Run konzentrieren. Sicherheitsteams, die dies im Rahmen einer ganzheitlichen Cloud-Sicherheitsstrategie umsetzen, werden feststellen, dass Container genau das sind, was sie brauchen, um DevSecOps einen Schritt näher zu kommen. (rhh)
