Tief im Rechenzentrumsnetz Encrypted Traffic Analytics (ETA) im Datacenter ersetzt Deep Packet Inspection

Die Ära der Netzwerküberwachung auf der Basis von Deep Packet Inspection neigt sich in Rechenzentren ihrem Ende zu. Encrypted Traffic Analytics, kurz ETA, füllt diese Lücke. Um die Gunst der IT-Entscheider buhlen neben dem Platzhirsch Cisco mit „Stealthwatch Enterprise“ auch zwei aufstrebende Spezialisten für das Maschinelle Lernen.

Anbieter zum Thema

Moxa Europe GmbH

Insider Research

TXOne Networks

Zwei relevante Neuentwicklungen haben der Deep Pocket Inspection in kürzester Zeit den Todesstoß versetzt: die Finalisierung von TLS 1.3 und das Inkrafttreten der DSGVO.

Ein Fluch und Segen

TLS 1.3 erreichte mit Draft 28 im März dieses Jahres den finalen Status und wurde von der IETF (Internet Engineering Task Force) zum Standard vorgeschlagen. Diese Entscheidung konnte für viele nicht schnell genug kommen. Denn alle älteren Versionen des Protokolls wurden bereits unzählige Male kompromittiert. Erstmals in der Geschichte des Protokolls behebt ein einziger Neuentwurf —TLS 1.3 eben —alle bekannten konzeptionellen Sicherheitslücken seiner Vorgänger.

Für Rechenzentren ist es ein Fluch und ein Segen zugleich. Datencenter-Betreiber werden nämlich nicht mehr in der Lage sein, TLS-Datenübertragung unter Verwendung des neuen Protokolls in Echtzeit zu entschlüsseln. Das Verfahren, bekannt als Deep Packet Inspection, hat es den Betreibern in der Vergangenheit ermöglicht, verschlüsselte Kommunikation durch Middleboxen auf bösartigen Code hin in Echtzeit zu überprüfen. Es ist und war ein sehr ressourcenintensives Unterfangen; seit TLS 1.2 kaum noch in (nahezu) Echtzeit machbar.

Die überwiegende Mehrheit der Rechenzentrumsbetreiber zeigt sich dennoch TLS 1.3 gegenüber sehr zurückhaltend; die Mehrheit der Unternehmen würde ihre Transportverschlüsselung vorzugsweise bei TLS 1.2 belassen. Diese Haltung ist überaus nachvollziehbar, hat jedoch zwei gravierende Nachteile.

Mit dem Rücken zur Wand

Mit dem Inkrafttreten der DSGVO ist für Rechenzentren das Festhalten an dem veralteten TLS-1.2-Standard erstmals nicht „nur“ technisch fragwürdig, sondern ganz nebenbei noch aus rein finanziellen Überlegungen nicht empfehlenswert (um das gelinde zu formulieren). Denn Cyber-Sicherheitseinbrüche können im Rahmen der DSGVO mit einer Strafe in Höhe von bis zu 4 Prozent des Vorjahresumsatzes oder 20 Millionen Euro geahndet werden, was auch immer höher ausfällt.

Der erste Nachteil besteht darin, dass sich das Deep-Packet-Inspection-Verfahren mit der DSGVO nicht verträgt.

Das Entschlüsseln von Datenpaketen kollidiert unter anderem mit der von Artikel 32 geforderten Integrität und Vertraulichkeit personenbezogener Daten. Das Rechenzentrum als ein Durchlaufposten der verschlüsselten Kommunikation mit Endanwendern kann sich mit der Deep Packet Inspection in eine juristische Schieflage hinein manövrieren.

Der DSGVO zufolge müssen personenbezogene Daten unbedingt auf eine Art und Weise verarbeitet werden, die einen angemessenen Schutz gewährleistet. Dies schließt den Schutz vor unbefugter und unrechtmäßiger Verarbeitung und vor unbeabsichtigtem Verlust, unbeabsichtigter Zerstörung oder Schädigung mit ein. Ein Rechenzentrum kann dem Gesetz de facto nur dann gewissenhaft Folge leisten, wenn es die Daten nicht unnötig entschlüsselt.

Ist ein Kommunikationsfluss erst einmal dekodiert beziehungsweise mit einer unsicheren Cipher wie RSA „herunterkodiert“, können sensible Daten sehr leicht auch unbefugten Dritten in die Hände fallen. Der Rechenzentrumsbetreiber könnte dann im Falle einer Cyber-Sicherheitspanne für den Verstoß gegen das Gebot der rechtmäßigen Datenverarbeitung gemäß Art. 5 Abs. 1 lit. a und Art. 6 der DSGVO haftbar gemacht werden.

Zur Einhaltung der DSGVO sind unbedingt passende technische und organisatorische Maßnahmen einzuleiten, welche vor allem in Art. 32 der Verordnung näher präzisiert werden.

Doch damit nicht genug. Deep Packet Inspection hat ja noch einen weiteren Nachteil, nämlich die zeitlich unbefristete Bindung an das betagte und im Vergleich zur Version 1.3 unsichere TLS 1.2-Protokoll.

Viele Angriffe gegen TLS bis einschließlich der Version 1.2 machen den Einsatz des Protokolls zu einem wahren Roulette. Um die gravierende Bedrohungslage einmal zu veranschaulichen, anbei eine kurze Liste von Angriffsvektoren bzw. wirksamen Exploits gegen TLS:

• POODLE, LOGJAM, FREAK, SMACK,

• LUCKY13, SWEET32, 3SHAKE,

• TLS Renego MITM,

• BEAST (Browser Exploit Against SSL/TLS),

• TIME, HEIST,

• SLOTH,

• DROWN,

• ROBOT (Return of Bleichenbacher’s Oracle Attack), ...

(Die Liste ist keinesfalls vollständig.)

Bedenklich: TLS 1.2

Der Einsatz des TLS-1.2-Protokolls ist mittlerweile sowohl aus datenschutzrechtlicher als auch aus technischer Sicht äußerst bedenklich. Bei seiner Vorstellung im Jahre 2008 mag TLS 1.2 einen angemessenen Schutz geboten haben; doch über ein Jahrzehnt später ist es längst nicht mehr der Fall. Da die heutige Unternehmenskommunikation und Transaktionsabwicklung fast ausschließlich online ablaufen, können sich TLS-Verwundbarkeiten für eine Organisation viel schneller als je zuvor als existenzbedrohend erweisen.

Je mehr Unternehmen ihre Geschäftsmodelle digitalisieren, desto mehr Dienste und Applikationen nutzen die TLS-Datenverschlüsselung als die primäre Methode zur Datensicherung. Laut Gartner ist der verschlüsselte Datenverkehr dieses Jahr im Vergleich zum Vorjahreszeitraum um satte 90 Prozent gestiegen. Für das kommende Jahr (2019) soll die Verschlüsselungsrate weltweit sogar die 80-Prozent-Marke erreichen.

Der rasante Anstieg des verschlüsselten Datenverkehrs verändert auch die Bedrohungslandschaft. Leider ziehen nicht nur die legitimen Datacenter-Anwender einen Nutzen aus TLS. Auch Cyber-Kriminelle bedienen sich der Transportverschlüsselung, um Eindringlingserkennungssysteme hinters Licht zu führen.

Encrypted Traffic Analytics

Die Betreiber von Rechenzentren stehen angesichts der vielen gravierenden Cyber-Sicherheitslücken des TLS-Protokolls und der Datenschutzauflagen der DSGVO mit dem Rücken zur Wand. Lösungen rund um Encrypted Traffic Analytics — also solche Analyse-Tools, welche die Verschlüsselung respektieren — können hier Abhilfe schaffen.

In diese Kategorie fallen unter anderem Cisco Stealthwatch Enterprise, „Darktrace“ des gleichnamigen Anbieters und „Plixer Scrutinizer“.

Cisco Stealthwatch bietet eine kontinuierliche Echtzeit-Überwachung und einen umfassenden Einblick in den gesamten Netzwerkverkehr. Es verbessert die Sichtbarkeit des erweiterten Rechenzentrumsnetzwerks und beschleunigt die Antwortzeiten für verdächtige Vorfälle.

Es erstellt eine Baseline der normalen Web- und Netzwerkaktivität für jeden Netzwerkhost und wendet eine kontextsensitive KI-Analyse an, um anomale Verhaltensweisen automatisch als solche zu erkennen. Stealthwatch kann unter anderem Malware, Zero-Day-Exploits, Distributed Denial-of-Service-(DDoS)-Attacken, erweiterten persistenten Bedrohungen (Advanced Persistent Threats, kurz: APTs) und böswilligen Insidern auf die Spur kommen (die sogenannte ATP, Advanced Threat Protection).

Plixer Scrutinizer

Plixer Scrutinizer ist ein verteiltes und skalierbares Analysesystem für den Netzwerkverkehr im Rechenzentrum. Es verwendet verhaltensbasierte Sicherheitsalgorithmen, um den Datenverkehr durch das Rechenzentrum nach Hinweisen auf Einbruchsversuche zu untersuchen, ohne die Datenpakete zu entschlüsseln.

Die verteilte Architektur der Datenerfassung aus Netzwerkgeräten minimiert die Angriffsfläche und verbessert das Reaktionsvermögen. In Zusammenarbeit mit „Flowpro Defender“ kann Scrutinizer unter anderem DNS-Tunneling, Botnets und Low-und-Slow-Datendiebstähle aufspüren.

Die Software nutzt unter anderem die Network-Protokolle „Netflow“ in der Version 9 (von Cisco) und „IPFIX“ (IP flow information export, ein IETF-Standard), um Flussinformationen von gängigen Switches und Routern, zum Beispiel von Cisco, Brocade, Juniper, Extreme und HPE, Firewalls, wie Cisco ASA, Palo Alto und Fortinet, sowie anderen Netzwerkgeräten, etwa von Ixia und Gigamon, einzusammeln.

Scrutinizer eignet sich für den Einsatz in einer Vielzahl von Datacenter-Umgebungen, einschließlich „VMware NSX“, „Cisco ACI“, Hypervisor-basierter Virtualisierung wie Plixer verweist mittlerweile auf 3.000 Kunden in 108 Ländern und hat eine dicke Kapitaldecke für weiteres Wachstum. Plixer wurde im März 2018 von der Investmentfirma Battery Ventures übernommen und hat mit Jeff Lindholm einen erfahrenen Industrie-Veteranen als CEO ins Boot geholt. Jeff Lindholm war zuletzt SVP bei Brocade und zuvor unter anderem SVP Worldwide Sales & CMO bei Juniper Networks.

In Zusammenarbeit mit Flowpro Defender kann Scrutinizer beispielweise DNS-Tunneling, Botnets & Low-&-Slow-Datendiebstähle erkennen. Der größte Schwachpunkt von Plixer Scrutinizer offenbart sich bei dem Versuch, ein konsolidiertes Reporting und Flow-Maps über mehrere Plixer-Kollektoren hinweg zu erfassen. Es geht zwar, aber leider nicht automatisch, sondern erfordert erst eine mühsame und zeitraubende manuelle Konfiguration.

Darktrace Enterprise, eine KI-Cyber-Sicherheitslösung des britischen Cyber-Sicherheitsspezialisten Darktrace, hat sich auf die ML-basierte Eindringlingserkennung nach dem Vorbild des menschlichen Immunsystems spezialisiert. Mit dem „Threat Visualizer“ kann das System Anomalien entdecken, Attack-Szenarien in Echtzeit visualisieren und nachträglich abspielen. Das Unternehmen rühmt sich 5.000 aktiver Deployments in 97 Ländern, darunter bei Ebay und T-Mobile, und soll eigenen Angaben zufolge in Rechenzentren 63.500 ernsthafte Sicherheitsvorfälle aufgedeckt haben.

Vor- und Nachteile der ETA-Tools

Was Darktrace wie auch Plixer Scrutinizer fehlt ist die Fähigkeit, Telemetriedaten aus Cisco-Netzwerkhardware auszulesen. Von den drei Lösungen kann nur Stealthwatch diese Informationen in die Analyse mit einbeziehen. Darktrace und Plixer Scrutinizer arbeiten sich um diese Hürde mit Cisco Netflow v9, IPFIX und fortgeschrittener künstlicher Intelligenz herum.

Der IETF-Standard IPFIX ist kompatibel mit Netflow v9, bietet jedoch zusätzliche Features, die über den dokumentierten Funktionsumfang von Ciscos proprietärem Protokoll hinausgehen. Während NetFlow v9 „nur“ 79 Feldtypen bietet, hat IPFIX ganze 238 im Köcher. Die ersten 79 decken sich aus Kompatibilitätsgründen mit den Feldtypen von Netflow v9; die übrigen 159 verleihen dem IPIX-Protokoll zusätzliche fortgeschrittene Fähigkeiten.

Cisco Stealthwatch Enterprise hat zwar nur einen einzigen, dafür aber einen gravierenden Schwachpunkt, nämlich das verzweifelte Erzeugen von sogenannten „Suspect Data Loss“-Alarmen für Hosts, ohne jegliche Fähigkeit, sinnvolle Gegenmaßnahmen einzuleiten. Diese Alarme signalisieren ungewöhnlich hohe Datenverluste aufgrund der so genannten Daten-Exfiltrationsangriffe (data exfiltration attacks), denen Stealthwatch keine Abwehrmechanismen entgegen zu setzen hat. Hier besteht deutlicher Nachholbedarf.

Darktrace hat es ja vorgemacht. Bei einem Cyber-Angriff auf das SCADA-Energienetzwerk im Mittleren Osten hat Darktrace einen internen Server identifizieren können, der kompromittiert worden war und enorme Datenmengen nach außen hin über äußerst ungewöhnliche ICMP-Verbindungen schicken wollte. Darktrace hat die Attacke aufgedeckt und konnte das Ausspähen der Daten unterbinden.

*Das Autoren-Duo

Die Autoren des Artikels, Filipe Pereira Martins und Anna Kobylinska arbeiten für McKinley Denali Inc. (USA).

(ID:45404672)