Ein Plädoyer für Containersicherheit

Statt Containersicherheit auf die lange Bank zu schieben, sollten Unternehmen diese wichtige Aufgabe zu einer Priorität machen – fordert Palo Alto Networks. Zuletzt wurde eine kritische Schwachstelle gemeldet, die Runc betrifft.

Dies ist die Runtime-Umgebung, die Docker, Kubernetes (k8s) und viele andere verwandte Dienste unterstützt. Die Auswirkungen einer derartigen Schwachstelle können nach Meinung von Palo Alto Networks gravierend sein, denn sie ermöglicht den Breakout von Containern. Unternehmen mit einem umfassenden Cloud-Sicherheitsprogramm sind jedoch gut aufgestellt, um dieser Bedrohung zu trotzen.

Best Practices reduzieren das Risiko

Der Breakout von Containern bereitet vielen Sicherheitsteams seit langem Sorge. Im Falle der spezifischen aktuellen Schwachstelle können die Risiken jedoch durch die Einhaltung von Best Practices wie den Benchmarks des Center for Internet Security (CIS) für Docker und k8s reduziert werden (siehe Abschnitte 4.1 bzw. 1.7.2). Was diese Schwachstelle einzigartig macht, ist, dass nur Container betroffen sind, die als „Root“ laufen, d.h. „privilegierte Container“.

Entsprechend der „Container Security Triade“ von Palo Alto Networks hätte eine starke Deployment-Sicherheit bei der die Einhaltung von Standards wie denen der CIS diese Schwachstelle sicherlich abgeschwächt, was für künftige Bedrohungen dieser Art ebenso gelten dürfte. Die Containersicherheitstriade besteht aus drei Schritten mit jeweiligen Maßnahmen: „Build“, „Deploy“ und „Run“.

1. Build

• Erkennung und Behebung von Schwachstellen und Malware und Gewährleistung der Code-Sicherheit
• Identifizierung von Schwachstellen in Image-Registrys

2. Deploy

• Gewährleistung sicherer Orchestrator-Konfigurationen
• Überprüfung mittels Standards
• Im regulären Betrieb darf nur „Gutes“ gesendet werden.

3. Run

• Alle Container müssen bekannt sein.
• Identifizierung neuer Schwachstellen
• Aufspüren von bösartigen/anomalen Ereignissen

Leider geben viele populäre Images in der DockerHub-Registry keinen Nicht-Root-Benutzer an. Dadurch führt die Docker-Engine diese Container standardmäßig als Root aus. Das Ausführen von Containern als Nicht-Root erfordert in der Regel zusätzliche Schritte, die viele Docker-Image-Autoren nicht durchführen. Dies unterstreicht den Bedarf für mehr Sicherheit und eine oder mehrere vertrauenswürdige Container-Registrierungsstellen im Unternehmen. Diese ermöglichen es Sicherheitsteams, Images (die oft aus DockerHub stammen) vor der Bereitstellung auf Schwachstellen und Malware zu überprüfen.

Gefährliche Images

Die Zusammenstellung von Containern, die als Root ausgeführt werden, bezeichnet den Umstand, dass Entwickler oft bestehende Docker-Images „erweitern“, um von Bibliotheken anderer Anbieter zu profitieren. „Docker Image Poisoning“ ist noch kein bekannter Angriff, aber es ist nur eine Frage der Zeit, bis mehr bösartige Docker-Images von Drittanbietern auftauchen werden. Im Jahr 2018 entdeckte RedLock eine Möglichkeit für einen Exploit bei dieser Docker-Nutzung. Gefährliche Docker-Images können jedoch sowohl mit Prozessen als auch mit Technologien erkannt werden, die sowohl normale Aktivitäten als auch Abweichungen von ihren digital signierten Vorgängern voraussetzen.

Umfassende Cloud-Sicherheit gewinnt immer

Software-Schwachstellen wird es immer geben, so Palo Alto Networks. Unternehmen mit einer umfassenden Cloud-Sicherheitsstrategie, einschließlich der Containersicherheitstriade, sind jedoch gut positioniert, um diese Art von Schwachstellen in Zukunft zu beheben, ohne ein weiteres punktuelles Sicherheitsprodukt ergänzen zu müssen. Angesichts von über 80 Milliarden Container-Downloads aus der DockerHub-Registry wären Sicherheitsabteilungen gut beraten, die Containersicherheit zum Top-Thema ihrer nächsten Teambesprechung zu machen. Ganz zu schweigen davon, dass der jüngste Exploit-Code für diesen CVE-Fall (Common Vulnerabilities and Exposures) am 18. Februar 2019 veröffentlicht wurde. 

www.paloaltonetworks.com