Anfällige Dinge, die in Containern ausgeführt werden, sind immer noch anfällige Dinge

Es heißt – und nicht nur von mir – dass verschlüsselter Schadcode immer noch Schadcode ist. Daran ändert auch die Verschlüsselung nichts, außer dass sie möglicherweise die Sicherheit und App-Infrastruktur beim Transport durch das Netzwerk behindert .

Das Gleiche gilt für Apps und Plattformen, die in Containern laufen. Wenn die App anfällig ist, ist sie anfällig, unabhängig davon, ob sie auf einem Betriebssystem, in einer virtuellen Maschine oder – heutzutage – in einem Container ausgeführt wird. Wenn die App im Rechenzentrum anfällig ist, ist sie es auch in der Cloud. Und umgekehrt.

Container sind nicht dafür konzipiert, Anwendungen auf magische Weise zu schützen. Sie bieten eine gewisse grundlegende Sicherheit auf Netzwerkebene, aber das Netzwerk ist nicht die Anwendung. Anwendungen haben ihre Angriffsfläche, bestehend aus ihrem Code und ihren Schnittstellen (APIs) sowie den Protokollen (HTTP, TCP) und dem benötigten App-Stack. Nichts davon ändert sich, wenn einer IP-Tabelle ein Eintrag hinzugefügt wird oder die eingehenden Anfragen anderweitig auf diejenigen beschränkt werden, die vom Eingang zur Containerumgebung kommen.

Der Grund, warum ich dies anspreche, ist die DevSecOps-Umfrage 2017 von Sonatype. Darin stimmten 88 % der über 2.200 Befragten zu, dass Containersicherheit wichtig sei, aber nur 53 % nutzten Sicherheitsprodukte, um anfällige Anwendungen/Betriebssysteme/Konfigurationen in Containern zu identifizieren.

Die ersten beiden Teile dieser Statistik – Anwendungen und Betriebssystem – sind mir ins Auge gesprungen, weil sie zwei der Komponenten eines vollständig realisierten App-Stacks sind, die sich nicht unbedingt je nach Standort oder Betriebsmodell (Cloud, Container, Virtualisierung usw.) ändern. Eine App oder API mit einer SQLi- oder XSS-Schwachstelle ist beim Wechsel zwischen Modellen nicht auf magische Weise geschützt. Diese Schwachstelle liegt im Code. Dasselbe gilt für Plattformen, die unbestreitbar Teil des App-Sicherheits-Stacks sind. Eine Sicherheitslücke bei der Handhabung von HTTP-Headern in Apache unter Linux bleibt auch dann bestehen, wenn die App von einem herkömmlichen, betriebssystembasierten Modell auf ein containerisiertes Modell umgestellt wird.

Es ist wichtig – sogar zwingend erforderlich –, dass wir weiterhin Schwachstellen im gesamten App-Stack identifizieren , unabhängig davon, wo oder in welcher Form die App bereitgestellt wird.

Darüber hinaus ist es ebenso wichtig, beim Wechsel zu Containern die App-Schutzmaßnahmen beizubehalten, die bereits für herkömmliche Apps eingesetzt werden. Eine Web Application Firewall ist für in Containern bereitgestellte Apps ebenso vorteilhaft wie für in der Cloud bereitgestellte Apps und für in herkömmlichen Umgebungen bereitgestellte Apps.

Dies gilt auch für andere Sicherheitstools, die die Befragten laut Umfrage nutzen, wie etwa statische und Echtzeit-Scanlösungen ( SAST, DAST, IAST und RASP ). Während die Verwendung von Web Application Firewalls (WAF) die anderer Tools übersteigt, sind auch SAST und SCA (Source Code Analysis) weit verbreitet. SCA ist ein statisches Mittel zur Beseitigung von Problemen vor der Auslieferung. Ich verrate hier mein Alter und stelle fest, dass Tools wie Lint in die Kategorie der SCA-Tools fallen. Diese decken zwar keine Schwachstellen auf, die sich aus der Interaktion des Codes (und mit Benutzern) in Echtzeit ergeben, sie können jedoch einige der häufigsten Fehler der Entwickler aufdecken, die zu Speicherlecks, Abstürzen oder dem berüchtigten Pufferüberlauf führen.

Ich weiß, was Sie denken. Sie denken: „Lori, ich habe gerade die Ergebnisse der Entwicklerumfrage 2017 von Stack Overflow gelesen, und JavaScript ist mit Abstand die von Entwicklern bevorzugte Sprache. Und JavaScript wird interpretiert, also sind all diese Pufferüberläufe und Speicherlecks nur schlimme Erinnerungen an die alten Zeiten, als Sie noch in C/C++ programmiert haben.“

Außer dass JavaScript – und andere moderne, interpretierte Sprachen – letztendlich in einer Sprache implementiert wird, die näher an der Leiterplatte ist, wie etwa C/C++. Und wie die Vergangenheit gezeigt hat , kann man diese Tatsache ausnutzen, um das System auszunutzen, wenn man clever genug ist.

Und selbst wenn dies kein Grund zur Sorge ist, gibt es in jedem Code zahlreiche andere Schwachstellen, die auf verwendeten Bibliotheken oder einem falsch verwendeten Systemaufruf beruhen und die Sicherheit auf der Serverseite verletzen. Aktuelle Umfragen gehen davon aus, dass 80 % der Apps aus Open-Source-Komponenten bestehen. Die Sonatype-Umfrage ergab außerdem, dass es zwischen 2014 und 2017 zu einem Anstieg der bestätigten oder vermuteten Sicherheitsverletzungen im Zusammenhang mit Open-Source-Komponenten um 50 % kam. Viele davon sind in Sprachen geschrieben, in denen die Wahrscheinlichkeit spektakulärer Fehler steigt, weil sie weniger kontrolliert werden und weil es immer weniger Entwickler gibt, die diese Sprachen beherrschen. 

Der Punkt ist, dass jeder Code anfällig für Schwachstellen ist. Und da Code der Baustein von Apps ist, die heute das Aushängeschild jedes Unternehmens sind, ist es wichtig, sie zu scannen und zu schützen, unabhängig davon, wo und wie sie bereitgestellt werden.

Container oder Cloud. Traditionell oder virtuell. Alle Anwendungen sollten auf Schwachstellen überprüft und vor Plattform- und Protokoll-Exploits geschützt werden. Zeitraum.

Apps sollten während der Entwicklung gründlich geprüft und getestet und dann in der Produktion erneut getestet werden. Beides ist notwendig, da der Trugschluss der Zerlegung besagt, dass die Einführung neuer Komponenten die Grundlinie verändert. Neue Interaktionen können bisher unentdeckte Schwachstellen ans Licht bringen.

Beachten Sie zum Schutz von Apps Folgendes:

• Setzen Sie bei der Entwicklung Code- und App-Analysetools ein. Bauen Sie sie nach Möglichkeit in die CI/CD-Pipeline ein.
• Falls bei der Interaktion mit anderen Komponenten/Apps Probleme auftreten, testen Sie erneut in der Produktion.
• Achten Sie auf Protokoll- und Plattformschwachstellen sowie auf Schwachstellen in von Ihnen genutzten Drittanbieterbibliotheken.
• Integrieren Sie eine Web-App-Firewall in Ihre Architektur. Auch wenn Sie es nicht im Blockierungsmodus verwenden, ist es eine unschätzbar wertvolle Ressource, falls eine Zero-Day-Sicherheitslücke in einem Protokoll/einer Plattform oder einer Bibliothek entdeckt wird.

Bleib sicher!