Schwachstellenanalyse für Container und Cloud, Teil 2

Container-Sicherheit mit Twistlock

| Autor / Redakteur: Thomas Drilling / Stephan Augsten

Der überarbeitete Vulnerability Explorer von Twistlock 2.1 zeigt sämtliche Risiken in der eigenen Container-Umgebung.
Der überarbeitete Vulnerability Explorer von Twistlock 2.1 zeigt sämtliche Risiken in der eigenen Container-Umgebung. (Bild: Thomas Drilling / Twistlock)

Das Twistlock-Framework verspricht einen integrierten Ansatz, um Container-Sicherheit zu gewährleisten und zu überwachen. Denn im Gegensatz zum traditionellen Vorgehen klinkt sich Twistlock vollständig in die Continuous-Integration-Pipelines z. B. mit Jenkins ein und interagiert nativ mit Docker oder Kubernetes.

Das Unternehmen Twistlock ist mit der „Twistlock Container Security Suite“ seit 2015 präsent. Der Markt giert offenbar nach entsprechenden Lösungen: In vier Finanzierungrunden wurden 30 Millionen Dollar Risiko-Kapital eingesammelt. Inzwischen sitzen fünf Investoren im von Vice President Dima Stopel und CEO Ben Bernstein gegründeten Unternehmen, das heute rund 50 Mitarbeiter beschäftigt.

Das Twistlock-Framework versteht sich als Schwachstellen-Management-Suite für Container. Twistlock kümmert sich dabei nicht nur um das Härten von Containern und Images, sondern auch der Umgebung, in der die Container laufen. Konkret untersucht Twistlock Container auf Exploits sowie auf Anwendungs- oder Konfigurationsfehler und überwacht die Container-Aktivitäten. Dabei erkennt Twistlock Verstöße gegen Sicherheitsrichtlinien, meldet sie und greift bei Bedarf korrigierend ein.

Twistlock unter der Haube

Das Unternehmen Twistlock berät nicht nur Unternehmen beim Absichern ihrer Container-Umgebungen. Mit der Twistlock-Plattform steht auch eine Lösung bereit, die sich um Laufzeitschutz (Runtime Defense), Schwachstellen-Management (Vulnerability Management), Sicherheitsanalysen (Security Analytics), Zugriffskontrolle (Access Control) und vieles mehr kümmert.

Das Besondere dabei ist, dass Twistlock weder Hosts noch den Container Daemon oder die Anwendung selbst anfasst. Trotzdem erkennt Twistlock Schwachstellen auch innerhalb des Linux Distribution Layers, in Bibliotheken und laut Hersteller sogar in App Frameworks wie Node.js oder in selbstgebauten Applikationen. Zudem ergänzt Twistlock die eigene Container-Umgebung um Authentifizierungs- und Autorisierungsmechanismen.

Damit können Entwickler ihre Umgebung besser kontrollieren als mit den hauseigenen Möglichkeiten. Die Authentifizierungs- und Autorisierungsmechanismen integrieren sich auf Wunsch nahtlos mit Kerberos oder LDAP. Im Detail verwendet Twistlock Machine Learning, sodass sich Anwendungen in Echtzeit und automatisch kategorisieren lassen. Daraus generiert Twistlock dann ein Security-Modell, das auf von Twistlock gepflegten Whitelists basiert.

Continuous Delivery

Das Besondere an Twistlock ist, dass die Lösung den kompletten Entwicklungszyklus einer Continuous-Delivery-Pipeline „begleitet“, während beispielsweise Firewalls im Prinzip nur reine Operations-Werkzeuge sind. Statische Codescanner hingegen werden vorzugsweise nur von Entwicklern eingesetzt. Twistlock vereint alle Aspekte in einem Tool, indem es sich als Plug-in z. B. in die Pipeline von Jenkins einklinkt und so einem DevOps-Ansatz ermöglicht.

Twistlock ist in einer für bis zu zehn Repositories und zwei Hosts kostenlosen Developer- und in einer Enterprise-Edition verfügbar. Während sich Policies in der Developer-Edition nur manuell anlegen lassen, Integriert die hier beschriebene Enterprise Edition eine vollautomatische Absicherung via Machine Learning. Die neue Version 2.1 bringt unter anderem erstmals eine Cloud Native App Firewall mit.

Cloud Native App Firewall

Traditionelle Web App Firewall (WAF) agieren stets von der eigentlichen Applikation separiert und „beanspruchen“ zudem immer mindestens zwei „menschliche Ressourcen“. Angenommen ein Entwickler betreibt „Wordpress“ auf Basis einer virtuellen Machine und möchte Traffic zur/von der VM filtern, muss er sein Security-Team bitten, dass dieses ihre WAF passend konfiguriert. Je nach Komplexität des Szenarios müssen gegebenenfalls Load Balancer angepasst werden – und möchte man eine andere VM konfigurieren, geht das Spiel von vorne los.

In einem Cloud-native-Szenario hingegen wird die entsprechende App von vornherein im Container entwickelt. Zusammen mit einem Orchestrator werden Annahmen wie die im Beispiel genannte aber zunehmen schwieriger zu verwalten. So hat die App im Container-Environment möglicherweise nicht immer die gleiche IP und hat der Nutzer selbst nicht die volle Kontrolle über die Routing-Topologie, lassen sich auch zugehörige Load Balancer oder Application Filter nicht anpassen. Hinzu kommt, dass sich jedes Mal, wenn eine neue App ausgerollt wird, erneut Operatoren, Entwickler und Security-Team „abstimmen“ müssen.

Die neue Cloud Native App Firewall in Twistlock 2.1.
Die neue Cloud Native App Firewall in Twistlock 2.1. (Bild: Thomas Drilling / Twistlock)

Da aber Twistlock sämtliche Apps auf den Container-Host und den Traffic zu sämtlichen Apps permanent „im Blick” hat, lässt sich der geschilderte Workflow dramatisch vereinfachen. Die neue „“Cloud Native App Firewall“ (CNAF) kombiniert dieses Wissen in Bezug auf Platzierung und Visibilität derart, dass sich Anwendungen mit einem Minimum menschlicher Interaktion automatisch schützen lassen.

Die Architektur des Twistlock Defenders.
Die Architektur des Twistlock Defenders. (Bild: Twistlock)

Aktiviert der Nutzer CNAF im oben skizzierten Wordpress-Beispiel, kennt Twistlock automatisch sämtliche „Ausführungsorte” und re-routet eingehenden Traffic zu diesen Containern automatisch über den „Twistlock-Defender“. Dieser weist dem Traffic einen hoch priorisierten applikationsspezifischen Layer-7-Filter zu, der dafür sorgt, dass nur „sauberer“ Traffic zum Container gelangt. Das funktioniert, laut Twistlock, ohne dass Entwickler irgendwelche Änderungen an ihren Images, Containern oder der Container-Architektur vornehmen müssen.

Die Wirksamkeit der CNAF im Twistlock-Monitor.
Die Wirksamkeit der CNAF im Twistlock-Monitor. (Bild: Thomas Drilling / Twistlock)

Twistlock lernt auf Basis seiner Machine-Learning-Engine dynamisch, wo die entsprechenden Filter anzuwenden sind, filtert den Applikations-Traffic transparent gegen verbreitete Angriffsmuster wie SQL Injection oder Cross Site Scripting, blockt ebenfalls transparent Anfragen von bösartigen Endpoints und stellt sicher, dass nur sauberer Traffic die Applikation erreicht. All das funktioniert, ohne irgendwelche externe Geräte konfigurieren oder IP-Adressen eintragen zu müssen. Das Ergebnis lässt sich in der Twistlock-GUI unter „Monitor / Runtime“ beobachten.

Der integrierte Secrets Manager

Viele Organisationen haben eine Enterprise-Secret-Management-Plattform wie z. B. HashiCorp Vault oder CyberArk Enterprise Password Vault im Einsatz, allerdings nicht in erster Linie für Secrets, die für Container bestimmt sind, aber durchaus für andere Anwendungsfälle. Da solche Lösungen ein sicheres zentrales Speichern von Secrets und ein komfortables Audit von deren Gebrauch erlauben, würden viele Unternehmen laut Twistlock gerne eine bestehende Lösung auf Container-Umgebungen erweitern.

Die führenden Container-Orchestrierungs-Plattformen Docker Swarm und Kubernetes bieten von sich aus nativen Support für solche Secret-Distributionen. Dies erlaubt Nutzern das sichere, zentralisierte Speichern und Verwalten von Secrets wie Private Keys, Passwörtern oder Connection Strings. Von dort aus stehen sie z. B. Containern auf Abruf zur Verfügung, damit die sensiblen Informationen nicht in Images eingebettet werden müssen. So können Nutzer beispielsweise ein Docker-Compose- oder Kubernetes-Deployment-File erstellen, das ein solches Secret referenziert.

Bisher bestand eine Einschränkung von Swarm und Kubernetes allerdings darin, dass alle Secrets im Orchestrator selbst gespeichert werden. Twistlock 2.1 bringt nun erstmals einen eigenen „Secrets Manager“ mit. Dieser ermöglicht eine Integration von Twistlock mit HashiCorp und CyberArk, sodass Twistlock das sichere Verteilen von Secrets für die vom Nutzer angegebenen Container erlaubt.

Der neue Secrets Manager erlaubt das Erstellen von Secrets Rules.
Der neue Secrets Manager erlaubt das Erstellen von Secrets Rules. (Bild: Thomas Drilling / Twistlock)

Da Twistlock die Secrets nie außerhalb solcher Lösungen speichert, mussten die Twistlock-Entwickler ein Verfahren ersinnen, das nahtlos mit den Access-Control- und Key-Rotation-Verfahren beider Lösungen integriert. Daher ist es mit Twistlock 2.1 nun möglich, dass Nutzer ihre existierende Secrets-Management Platform mit der eigenen Container-Plattform verknüpfen, um Secrets für jede gewünschte Applikation sicher bereitzustellen. Praktisch erfolgt dies über das Definieren von Secret Rules im Secrets Manager.

Bemerkenswert an dieser Herangehensweise ist, dass das Secrets-Management nicht in Twistlock selbst passiert. In ähnlicher Weise, wie die Twistlock-Entwickler bereits einige Authorization- und Security-Features für Docker und OpenShift beigetragen hatten, ist das offenbar auch beim Secrets-Management gelaufen. Die Implementation in Twistlock 2.1 setzt auf einem Open-Source-Backend auf, das Twistlock zum Docker-Projekt beigesteuert hat, um den Secrets Manager von Docker Swarm „pluggable“ zu machen.

Andere Hersteller können damit nun ihre eigenen Provider für dieses Plug-in entwickeln, damit Secrets auf sichere Weise von jedem denkbaren Secrets Manager empfangen und sicher in die gewünschten Container injiziert werden können, indem dazu die neue native Fähigkeit von Docker Swarm verwendet wird. Laut Aussage von Twistlock nutzt die Implementation in Twistlock 2.1 das gleiche Framework für das Verbinden von „HashiCorp“ und „CyberArk“ mit „Swarm“ oder „Kubernetes“.

Vulnerability Explorer

Die meisten Container-Vulnerability-Management-Tools finden und zeigen Nutzern eine Liste der Schwachstellen in ihren Images. Die Twistlock-Entwickler weisen seit geraumer Zeit nicht nur darauf hin, was daran falsch ist, sondern liefern auch die Werkzeuge, um das Problem „von ganz vorne“ anzugehen, etwa mit der Fähigkeit, zum Beispiel „Jenkins“-Builds ganz zu verhindern und Container damit vor der Ausführung zu schützen, wenn bestimme Vulnerability-Schwellwerte überschritten sind.

Der überarbeitete Vulnerability Explorer in Twistlock 2.1.
Der überarbeitete Vulnerability Explorer in Twistlock 2.1. (Bild: Thomas Drilling / Twistlock)

So hat man in Version 2.1 weiter daran gearbeitet, dem Nutzer nicht nur eine einfache Vulnerability-Liste zu präsentieren, sondern eine Stack-gruppierte Baumansicht sämtlicher Risiken in der eigenen Umgebung. Auch das funktioniert wiederum, weil Twistlock aufgrund seiner ML-basierten Arbeitsweise sämtliche Container der Nutzer „kennt“ und dieses Wissen für die Risikobewertung einsetzt. Die Ansicht findet sich unter „Monitor / Vulnerabilities“:

Dazu ein Beispiel: Angenommen, zwei Images hätten mehrere mit „high“ eingestufte Vulnerabilities. Eines der Images fungierte als Frontend für eine öffentlich zugängliche Web-Anwendung und das Andere als Caching-Layer, der nicht im Netzwerk in Erscheinung tritt. Twistlock „wüsste“ wiederum, welche Images mit root-Berechtigung liefen, welchen Images Mandatory Security Profiles fehlten, welche Images Ports nach außen zugänglichen machten oder welche Images Traffic aus dem Internet empfingen.

Eine kontinuierliche, hierarchische Risikobewertung für alle identifizierten Anfälligkeiten.
Eine kontinuierliche, hierarchische Risikobewertung für alle identifizierten Anfälligkeiten. (Bild: Thomas Drilling / Twistlock)

Twistlock zeigt aber nicht einfach nur beide Images als Liste, sondern kalkuliert eine Risikobewertung für jedes Image, deren Score jeweils exakt davon abhängt, wie der Nutzer die Images deployed hat. Twistlock visualisiert die Risikobewertung in der grafischen Oberfläche im Vulnerability Explorer, sodass der Nutzer jede vorstellbare Anfälligkeit intuitiv erfasst.

Da Twistlock auch „weiß“, welche Anfälligkeit welches Packet betrifft, welches Paket in welchem Image steckt, welches Image welchem Container zugrunde liegt und welche Hosts die Container ausführen, erfasst der Nutzer mit einem Klick den gesamten Impakt über sämtliche Objekte. Die Abbildung zeigt die Images-View mit der entsprechenden Risiko-Bewertung als Baum-Hierarchie.

Vulnerability Push Alerts

Auch das Alerting wurde in Version 2.1 deutlich verbessert.
Auch das Alerting wurde in Version 2.1 deutlich verbessert. (Bild: Thomas Drilling / Twistlock)

Schon länger unterstützt Twistlock Push-Alarme für Events. Nutzer können dazu an zentraler Stelle Alert-Profiles erstellen, die etwa E-Mail-Adressen oder andere Kanäle bedienen. In Version 2.1 wurde das Feature laut Twistlock deutlich erweitert, zum Beispiel um Rich-HTML-basierte Email-Alarme für die Vulnerability-Erkennung quer durch das Container-Environment.

Alarme sind konfigurierbar, so dass Nutzer beispielsweise spezifische Alarme für ausgewählte Images definieren können, die dann z. B. nur an die Team-Manager gehen, die für diese Images verantwortlich sind, was eine weitgehenden Automatisierung des Prozesses erlaubt. So könnten etwa Development-Teams Push-Benachrichtigungen über neu gefundene Vulnerabilities in Apps erhalten, ohne dass diese selbst etwaige manuelle Scans an der Konsole auslösen müssten.

Fazit

Twistlock ist als Intrusion- und Vulnerability-Scanner sowie als Analytics- und Überwachungs-Tool für Container- und Cloud-Umgebungen in seiner Arbeitsweise bisher einzigartig und ähnelt einer Kombination etwa von „vRealize Operations Manager“ und „vRealize LogInsight“ bei „VMware vSphere“. Allerdings stellen Container deutlich höhere Anforderung an eine solche Lösung, wie virtuelle Maschinen.

Machine Learning macht´s möglich, insofern ist vor allem die Enterprise-Version von Twistlock für alle Unternehmen interessant, die Container produktiv einsetzen. Es dürfen sich also für viele Unternehmen lohnen, eine Testversion der Enterprise-Edition 30 Tage auszuprobieren.

*Thomas Drilling ist freier Autor und IT-Berater. Auf DataCenter-Insider schreibt er seinen eignen Blog:Drillings Open-Source-Eck

Was meinen Sie zu diesem Thema?

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44961934 / Software)