In einem klassischen Datacenter werden Firewalls meistens zum Schutz des Perimeters eingesetzt. Oft existiert auch noch eine DMZ, die man normalerweise mit einer inneren und einer äusseren Firewall schützt. Bei grösseren Firmen gibt es auch noch sogenannte Netzwerk-Zonen, die meistens auch durch Firewalls unterteilt sind (um damit einen höheren Sicherheitsbereich zu erstellen).

Wenn man sich aber innerhalb einer Zone bewegt, bleibt der Verkehr zwischen Servern (der sogenannte East-West Verkehr) offen und wird intern nicht durch Firewalls geschützt. Es wäre aber weder ökonomisch sinnvoll noch operationell vertretbar so viele Firewalls einzufügen, um diesen lokalen Verkehr auch noch zu schützen.

Wenn es sich um interne Webapplikationen (Intranet) handelt, wird dieser Webtraffic eventuell noch über interne Proxys gesteuert, aber diese folgen meistens dem Zonenkonzept und werden oft parallel zu den Firewalls installiert.

Was ist denn der eigentliche Nachteil solch eines Setups? Sollte es zu einem Breach kommen, dann kann der Attacker sich meistens innerhalb dieser Zone sehr frei bewegen, d.h. er kann diesen Teil des Netzwerks scannen und versuchen gezielt andere Server zu identifizieren und anzugreifen. Wenn er genügend Zeit hat, kann er sich auf sehr viele Server ausbreiten und versuchen auf «normalen» Traffic Huckepack zu spielen (piggybacking) und damit durch die Firewalls zu kommen.

Sich dagegen zu schützen ist in einem klassischen Datacenter mit vielen physischen Servern kein einfaches Unterfangen. Die Security Teams müssen z.B. den Netzwerkverkehr an neuralgischen Punkten scannen und sind auf Endpoint-Security angewiesen. Auch wenn die Server virtualisiert sind (z.B. VMware) ist es immer noch relativ aufwändig, erst bei einer Netzwerkvirtualisierung (wie z.B. NSX) würde es wesentlich einfacher werden.

Application Visibility

Jetzt gibt es Lösungen die eine sogenannte «Application visibility» erstellen, bzw. ermöglichen. D.h. sie zeigen auf, welche Server sich mit welchen anderen Servern verbinden und vor allem welche Applikationen überhaupt mit welchen anderen Applikationen kommunizieren (nebst den internen Services wie AD, SNMP monitoring etc.).

Application Visibility Lösungen installieren Sonden und überwachen die Server, Applikationen und das Netzwerk kontinuierlich. Viele können auch eine sogenannte Baseline erstellen, ein Grundverhalten, das aufzeigt, wie sich die Applikation normalerweise verhält, wie oft und wieviel diese mit anderen Servern kommuniziert. Anhand dieser Baseline kann man nämlich ein Monitoring aufsetzen, das aufschlägt, wenn eine Applikation anomalen Traffic verursacht, und das Ops-Team kann schnell nachforschen, was dahintersteckt.

Was hat das mit der Cloud zu tun?

Wenn man eine Übersicht der Applikationen und ihren gegenseitigen Abhängigkeiten und Verbindungen hat, erleichtert das die Migration in die Cloud enorm. Sogar bei einem einfachen «Lift & Shift» Approach (man bildet in der Cloud genau das ab, was man im Datacenter hat, einfach virtualisiert) kann man von diesen Informationen profitieren. Damit ist das Erstellen einer Mikrosegmentierung viel einfacher, denn man weiss jetzt welche Applikationen und Services «zusammengehören» und über welche Ports sie miteinander kommunizieren.

Wie funktioniert jetzt so eine Whitelisting policy? Indem sie alle Verbindungen blockt, ausser denen, die explizit erlaubt wurden. Und dank der Application Visibility Map, weiss man, welche Applikationen über welche Ports miteinander kommunizieren und kann diese Verbindungen explizit erlauben und alle anderen Verbindungen blockieren.

Und wie geht das bei Containern?

Wenn man einmal die Abhängigkeiten der eigenen Applikationen kennt, ist das Unabhängig von der Form, wie sie deployed werden (als VM, als Docker-Container, über Kubernetes oder als Serverless Funktionen). Idealerweise hat man eine Policy, die für die gesamte Infrastruktur gilt. Zum Beispiel dürfen Front-End Server nur über den Port 3306 mit Datenbanken kommunizieren. Dies sollte in VM-Umgebungen genau gleich gelten wie in einer Container-Umgebung.

Die Umsetzung solch einer Policy ist bei Container-Lösungen, vor allem bei Kubernetes, besonders einfach, denn man arbeitet mit sogenannten Tags. Ein Datenbank Server oder Service wird als solcher klassifiziert (ge-tagged) und ein Front-End Webserver wird ebenfalls ge-tagged. Damit kann man abstrakte Policies schreiben (Front-End Server dürfen nur über Port 3306 mit Datenbanken kommunizieren). Solange ein neuer Server richtig ge-tagged wird, dann wird er automatisch von dieser Policy abgedeckt.

Wenn z.B. fünf neue Front-End Server automatisch zu den bestehenden hochgefahren werden, wenn der Load ansteigt, dann werden sie automatisch durch die gleiche Policy abgedeckt, wie die bestehenden Front-End-Server, weil sie über den Tag als solche identifiziert wurden.

Das Interessante daran ist, dass die Entwickler oder das DevOps Team sich nicht explizit um die Policy der neuen Server kümmern müssen, sondern dies geschieht automatisch, beim deployen wird der richtige Tag hinzugefügt.

Und bei Serverless Funktionen?

Funktionen (FaaS) sind einfach kleine Programme oder kurze Scripts. Sie werden meistens durch einen Event aufgerufen, führen eine Funktion aus (einen Algorithmus) und werden nach der Durchführung wieder geschlossen. Diese Funktionen kann man sich als einen Container vorstellen, der hochgefahren wird, etwas ausführt und gleich wieder heruntergefahren wird. Dementsprechend kann man solch eine Funktion auch taggen und in eine Policy einbetten. Man macht das technisch anders, als bei einem Container, aber die grundlegende Idee ist die gleiche.

Und wenn ein VM eine unerlaubte Verbindung erstellt?

Sollte ein Front-End-Server versuchen sich z.B. über den Port 22 (SSH) mit einer Datenbank zu verbinden, dann wird dies über die Policy geblockt, denn Port 22 ist in diesem Beispiel nicht in der Whitelisting Policy erlaubt. Dieser Versuch wird aber geloggt und führt zu einem Alert für das Security oder DevSecOps Team.

Uns sollte jetzt plötzlich eine Datenbank viel mehr Daten von einem Webserver bekommen, als üblich (dies wird ja über die Baseline verfolgt und ge-monitored), dann wird das als eine Anomalie identifiziert, ge-loggt und führt ebenfalls zu einem Alert für das Security Team.

Es ist auch möglich Automatismen zu programmieren und Policies automatisch durchzusetzen (ein sogenanntes «automatic enforcement»). Wenn eine VM oder ein Container unerlaubte Verbindungen aufzubauen versucht, dann kann man dieses Verdächtige Element sofort vom Netzwerk isolieren (Quarantäne) oder man schliesst die VM und killt den Container und fährt automatisch eine neue (saubere) VM bzw. einen neuen Container hoch. Das DevSecOps team erhält einen Alert und kann verifizieren ob eine Vulnerability im Code vorhanden ist. Wie viel man automatisieren will und kann, hängt vor allem von der Maturität der eigenen Applikationen und von der Erfahrung des DevSevOps-Teams ab.

TLDR*: Application Visibility Lösungen helfen aufzuzeigen, welche Applikationen mit welchen anderen Applikationen oder Services kommunizieren. Basierend auf diesen Daten kann dann eine Mikrosegmentierung mit Whitelisting erstellt werden. Die Application Visbility Platform kann auch kontinuierlich überwachen und Anomalien identifizieren und alarmieren.