New Africa - stock.adobe.com
Mit Egress-Richtlinien die Lieferkettensicherheit optimieren
Hintertüren in der Software von Drittanbietern und daraus resultierende Supply-Chain-Angriffe stellen für Unternehmen ein hohes, schwer zu kontrollierendes Sicherheitsrisiko dar.
Die Bedeutung der Sicherheit von Lieferketten hat der SolarWinds-Angriff einmal mehr deutlich gemacht. Zwar lässt sich die Sicherheit der Lieferkette niemals gänzlich kontrollieren, und noch wurde keine probate Security-Lösung gefunden, um Attacken über Drittanbieter umfassend zu verhindern. Dennoch können Unternehmen auch heute schon Maßnahmen ergreifen, um Angriffe dieser Art einzudämmen.
Ein wirksames Mittel ist etwa das Einschränken des Egress-Traffics durch Segmentierung. Automatisch erlernte Egress-Richtlinien versprechen dabei besonders hohe Effektivität.
Warum Egress-Richtlinien so selten umgesetzt werden
Obwohl Egress-Traffic, das heißt Datenverkehr, der in einem Computernetzwerk seinen Ursprung hat und dieses verlässt, relativ einfach eingeschränkt werden kann, ist dieses Vorgehen nur bei wenigen Unternehmen tatsächlich gängige Praxis.
Wenn eine Firewall ein großes Subnetz absichert, ist es verständlicherweise sehr schwierig, den ausgehenden Datenverkehr einzuschränken. Dies liegt vor allem daran, dass es viele Server auf der internen Seite der Firewall gibt, die versuchen, sich mit vielen anderen Endpunkten auf der anderen Seite zu verbinden. Für einen Sicherheitsmanager wäre es demnach äußerst schwierig, alle Verbindungen, die durch die Firewall kommen, zu bewerten und zu bestimmen, welche notwendig sind und welche blockiert werden sollten.
Die Erstellung und Verwaltung einer Liste von erlaubten Ziel-IP-Adressen scheint auf den ersten Blick eine Lösung für dieses Problem zu sein, ist aber schon aufgrund der dynamischen Natur des Content Delivery Networks (CDN) nicht umsetzbar. Und selbst die Verwaltung nach dem Fully-Qualified Host Name (das heißt dem DNS-Namen) wäre schwierig, da Sicherheitsverantwortliche dann eine umfassende Liste aller zugelassenen Endpunkte, die von ihren eigenen Anwendungen benötigt werden, definieren müssten.
Zwei weitere Möglichkeiten, die von Seiten verschiedener Security-Anbieter immer wieder vorgeschlagen werden, um Traffic zu kontrollieren, sind Sperrlisten sowie der Einsatz von Malware-Erkennung der nächsten Generation. Beide Ansätze können komplexe Probleme letztlich jedoch nicht verhindern:
So mag die Idee, die hinter definierten Sperrlisten (Deny List) von IP-Adressen oder DNS-Namen steckt, eine gute sein. Das Problem dieser Listen ist jedoch, dass Hacker diese umgehen können, indem sie IPs und DNS-Namen fortlaufend ändern.
Und selbst wenn die Anbieter die Listen über eine zentrale Ebene, zum Beispiel eine Malware Information Sharing Platform (MISP) ständig aktualisieren, stehen sie Zero-Day-Schwachstelle dennoch machtlos gegenüber. Ähnlich ist es beim Einsatz von Next Generation Malware Detection. Fortschrittliche Schadsoftwareerkennung funktioniert nur bis zu einem gewissen Grad. Denn Hacker setzen immer bessere Verschleierungstechniken ein, um ihre illegalen Verbindungen als legitime zu tarnen. Auch der Einsatz einer anspruchsvollen Firewall ist deshalb keine Garantie dafür, dass schädliche Verbindungen tatsächlich identifiziert und blockiert werden.
Erschwerend kommt hinzu, dass, selbst wenn jemand in der Lage wäre, die Liste der zulässigen Egress-Endpunkte zu definieren, diese schnell veraltet wäre, da die Anwendungen ständig mit neuen Funktionen und Endpunktabhängigkeiten weiterentwickelt werden.
Das Problem liegt also eher in der Richtlinienverwaltung als in der Durchsetzung: Stellt sich also die Frage, wie Sicherheitsteams eine Liste zulässiger Egress-DNS-Namen sinnvoll und ohne extremen Aufwand definieren können?
Sicherheitsrichtlinien automatisieren
Um Egress-Traffic effektiv zu kontrollieren, muss man beim Security Policy Management verstärkt auf Automatisierung setzen.
Hierfür muss man zunächst einmal den Scope reduzieren. Denn während es unmöglich ist, eine Egress-Richtlinie für ein ganzes VLAN zu definieren, ist es für einen einzelnen Server oder – noch besser – einen einzelnen Workload doch recht einfach.
Microservice-Architekturen wie Kubernetes und Serverless sind hierfür ideal. In einem zweiten Schritt ist es wichtig zu verstehen, dass Security Policies niemals von Hand geschrieben werden sollten. Zum einen wäre die Aktualisierung viel zu kompliziert, zum anderen würden sie sich nicht den häufigen Änderungen anpassen, die Anwendungen ständig durchlaufen. Anstatt Richtlinien manuell zu schreiben, sollten sie automatisch erlernt werden, indem das Verhalten der Anwendung ständig beobachtet wird.
Wie man das Erlernen schlechter Verbindungen vermeidet
Wie so oft gibt es jedoch auch hier einen Haken. Denn wenn der Workload, dessen Datenverkehr beobachtet wird, um automatisch Richtlinien zu erstellen, bereits kompromittiert ist, könnten schädliche Verbindungen „gelernt“ werden, die dann in die Policies einfließen.
Um dieses Problem zu vermeiden, ist es wichtig, dass Sicherheitsrichtlinien schon früh im Entwicklungsprozess automatisch erlernt werden, zum Beispiel während der Durchführung von Integrationstests. Diese Richtlinien sollten aus einer relativ kleinen Liste von erlaubten Egress-Endpunkten bestehen, damit sie leicht von den Entwicklern und Sicherheitsteams überprüft werden können.
Um das Erlernen schlechter Muster zu vermeiden, muss hierbei sichergestellt werden, dass Penetrationstests oder ähnliche Aktivitäten von den Lernmustern ausgeschlossen werden.
„Während es unmöglich ist, eine Egress-Richtlinie für ein ganzes VLAN zu definieren, ist es für einen einzelnen Server oder – noch besser – einen einzelnen Workload doch recht einfach.“
Thorsten Geissel, Tufin Technologies
Software von Drittanbietern sollte dabei ebenfalls mit einer solchen Policy ausgestattet sein, die auf die gleiche Weise vom Softwarehersteller erstellt werden kann. Man spricht hier auch von „Immutable Policies“. Sie werden in der Produktion nie geändert, sondern nur automatisch bei jeder Änderung der Anwendung generiert und dann als Ganzes in die Produktion übernommen. Diese Richtlinien sind ein integraler Bestandteil der Software und sollten für jede Anwendung obligatorisch sein.
Extremfälle in der Supply Chain-Sicherheit
In extremen Fällen, wie dem von Solarwinds, wurde der Code selbst von den Angreifern modifiziert, so dass sogar die automatisch generierten Richtlinien die böswilligen Egress-Verbindungen miteinbezogen hätten. Doch auch für Fälle wie diese gibt es Lösungen.
Denn wenn der Scope des geschützten Assets klein ist, ist es einfach, jede Egress-Verbindung aus einem Workload zu überprüfen und zu genehmigen, genau wie beim Durchführen von Code-Reviews (man denke etwa an Policy-as-Code). Im Falle einer infizierten Binärdatei lässt sich dann einen Unterschied in der Egress-Richtlinie erkennen. Es würde eine neue Verbindung auftauchen und der Prüfer sollte sie leicht als verdächtige Verbindung erkennen können.
Schlussfolgerungen
Definieren Sie Egress-Richtlinien, die nur auf essenzielle und verifizierte Ziele Zugriff erlauben: Diese Richtlinien sollten auf sehr granularen Ebenen wie Kubernetes-Workloads basieren. Da jeder Workload einen relativ kleinen Scope an externen Verbindungen hat, ist die Definition von Egress-Beschränkungen viel einfacher und nachhaltiger.
Setzen Sie auf Automatisierung, um Richtlinien zu lernen: Erlernen Sie Application Connections, um eine Richtlinie mit gültigen Ingress- und Egress-Verbindungen für jeden Kubernetes-Dienst zu erstellen.
Erlernen Sie die Richtlinien so früh wie möglich im Entwicklungszyklus: Die Application Policies sollten bereits während der Anwendungstests gelernt werden, um eine Richtliniendefinition zu generieren, die in Ihr Code-Repository übertragen werden kann. Dieser Code kann dann als Teil der CI/CD-Pipeline in der Produktion bereitgestellt werden.
Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder.
