SSL-Verkehr
Vom Freund zum Feind
Fortsetzung des Artikels von Teil 1
Die Komplexität der Cloud
Traditionelle Rechenzentrumsumgebungen sind nicht der einzige Ort, an dem verschlüsselter Verkehr Visibility- und Security-Lösungen herausfordert. Da volumetrische Angriffe, die Internet-Pipes sättigen oder die Ressourcen von Rechenzentren erschöpfen, weiter auf dem Vormarsch sind, wenden sich viele Unternehmen cloudbasierten Mitigations-Lösungen zu.
Cloudbasierte Dienste variieren in ihren Möglichkeiten, erlauben aber generell dem Opfer eines Angriffs, sich auf wirksame Ressourcen außerhalb des eigenen Netzwerks zu verlassen, um den Verkehr zu säubern – meist Scrubbing Service genannt. Ein solcher Service überprüft den gesamten eingehenden Verkehr, eliminiert die zum Angriff gehörenden Pakete und leitet nur den legitimen Verkehr an das eigentliche Ziel weiter. Allerdings schafft die Umleitung von verschlüsseltem Verkehr zu einem Dritten eine neue Reihe von Herausforderungen im Zusammenhang mit der Koordination und der Verwaltung privater Schlüssel. Einerseits ist die Entschlüsselung durch den Cloud-DDoS-Provider notwendig, um Schutz vor verschlüsselten Bedrohungen zu bieten (einige Anbieter leiten verschlüsselten Datenverkehr einfach unberührt an den Kunden weiter). Auf der anderen Seite muss der Kunde sein gesamtes Zertifikat-Management mit dem Cloud-DDoS-Provider koordinieren. Zudem erfordert ein solches Arrangement natürlich ein hohes Maß an Vertrauenswürdigkeit, da potenziell Datenschutz und Vertraulichkeit beeinträchtigt werden.
Idealerweise sollte daher ein Provider solcher Scrubbing-Dienste Wildcard-Zertifikate unterstützen, die nicht mit den Serverzertifikaten übereinstimmen müssen. Das kann zwei Probleme lösen. Erstens eliminiert es die Notwendigkeit, private Schlüssel mit dem Cloud-DDoS-Anbieter zu teilen, was gegen die Sicherheitsrichtlinien der meisten Organisationen verstößt. Zweitens verringert es den administrativen Aufwand für die Koordinierung von Änderungen und Aktualisierungen der Serverzertifikate und hält zudem Serverzertifikate vom Perimeter fern.
Der Schlüssel zum Erfolg
SSL ist sowohl Fluch als auch Segen: Segen, weil es das Datenschutzproblem löst und die Kommunikation sensibler Informationen sichert; Fluch, weil es neue blinde Flecken und Schwachstellen in einer Enterprise-IT-Infrastruktur schafft. Bei der Entwicklung einer Strategie zum Schutz vor SSL-Attacken sollte man daher eine Reihe von Aspekten berücksichtigen.
- Sichtbarkeit oder Visibility: Ziel ist es, SSL-Sitzungen zu entschlüsseln und neu zu verschlüsseln, um sowohl klaren als auch verschlüsselten Verkehr inspizieren zu können und gleichzeitig die Vertraulichkeit der Inhalte unterwegs zu bewahren.
- Serviceverkettung (Service Chaining): Jede SSL-Inspektionslösung muss in der Lage sein, den Verkehr selektiv an eine oder mehrere Sicherheitslösungen weiterzuleiten.
- Flexibles Monitoring: Wie kann eine Lösung Effizienz bei der Inspektion von verschlüsseltem Verkehr unterstützen, der sich als unverschlüsselter Traffic maskiert? Sie muss dynamisch Filter definieren, die Verkehr abfangen und für die Inspektion öffnen - auch wenn der Traffic durch Nicht-Standard-Ports fließt, etwa HTTPS Port 443.
- Sicherheit: Um die SSL-Lösung nicht selbst in ein Ziel zu verwandeln, darf sie nicht wie ein Proxy funktionieren oder eine eigene IP-Adresse haben.
- Skalierbarkeit: Da das Verkehrsvolumen kontinuierlich wächst, müssen SSL-Lösungen nahtlos skalierbar sein, um die Notwendigkeit von Upgrades in großen Inkrementen zu reduzieren oder zu eliminieren.
- Hohe Verfügbarkeit: Um Ausfallzeiten aufgrund von Problemen in der Sicherheitslösung zu vermeiden, sollte die SSL-Lösung immer sicherstellen, dass der Verkehr an die am schnellsten antwortenden Sicherheitssysteme weitergeleitet wird, wobei ausgefallene Systeme automatisch umgangen werden.
SSL ist noch lange nicht tot
Aufgrund der inhärenten Unsicherheit von SSL orientieren sich Standardisierungs-Organisationen und Compliance-Programme zunehmend in Richtung TLS 1.2. Doch die Migration ist weder einfach noch kurzfristig zu schaffen, wie das Beispiel des PCI Councils zeigt. Ursprünglich sollte der Standard PCI DSS für Kartenzahlungen ab Juni 2016 den Einsatz von TLS vorschreiben, doch aufgrund vieler Probleme bei der Migration von SSL auf TLS wurde dieser Termin bereits auf Juni 2018 verschoben. Die gleichen Schwierigkeiten treten auch in anderen Einsatzbereichen auf, und so wird uns SSL noch eine ganze Weile erhalten bleiben – Grund genug, sich auch heute noch intensiv Gedanken über den sicheren Einsatz dieses Protokolls zu machen.
Georgeta Toth ist Regional Director DACH bei Radware
- Vom Freund zum Feind
- Die Komplexität der Cloud
Lesen Sie mehr zum Thema
