Verschlüsselung
SSL-Decryption – Fluch oder Segen?
Fortsetzung des Artikels von Teil 1
Bevorzugtes Ziel
Man sollte sich ebenfalls darüber im Klaren sein, dass eine Firewall mit SSL-Decrytion zu einem sogenannten High Value Target wird, da sich hier sämtliche Daten unverschlüsselt abgreifen lassen. Eine schlechte oder nachlässige Implementierung führt nur zu noch größeren Problemen, da man von ihren Auswirkungen erst erfährt, wenn es unter Umständen schon zu spät ist. Lässt man all die technischen Gefahren wie unvollständige Prüfung des Upstream-Zertifikats, Überfrachtung des CN-Feldes und nur ein ROOT CA für alle Client-Verbindungen einmal außer Acht, gibt es unter Umständen auch rechtliche Probleme. Die Entschlüsselung zur Inspektion der eigentlich SSL-geschützten Daten kann nach §202a StGB ein Ausspähen von Daten, eine Verletzung des Post- oder Fernmeldegeheimnisses nach §206 StGB und ein Datenschutzverstoß beziehungsweise eine Ordnungswidrigkeit nach §43 BDSG darstellen. Dies sollte man individuell durch den firmeneigenen Justiziar prüfen lassen.
Einige der genannten Nachteile kann man mit einer guten Implementierung umschiffen. So sollte sie in der Lage sein, Dinge wie zum Beispiel abgelaufene Zertifikate zu blockieren. Sie sollte Zertifikate via OCSP oder CRLs abfragen und überprüfen können. Zertifikate von unbekannten oder von als nicht vertrauenswürdig markierten Instanzen müssen blockiert werden. Ferner sollte sie nicht unterstützte Versionen beziehungsweise Cipher zulassen. Sie muss die Möglichkeit bieten, zu entscheiden, welche SSL-Version man überhaupt zulassen will, etwa TLS 1.2 only. Einstellungen bezüglich des Key Exchange Algorithm (RSA, DHE, ECDHE), des Encryption Algorithm (RC4, 3DES, AES-CBC,AES-GCM) und des Authentication Algorithm (MD5, SHA1, SHA256, SHA384) aber auch die Begrenzung der Zertifikats-Erweiterungen im dynamisch erzeugten Server-Zertifikat müssen festgelegt werden. Des Weiteren sollte es möglich sein, Web-seiten zu exkludieren. Dies kann über sogenannte „exclude lists“ geschehen oder basierend auf IP-/URL-Listen. Hat man all diese Dinge berücksichtigt, kann man seine Implementierung übrigens online unter https://badssl.com/dashboard prüfen.
Wo ist SSL-Decryption sinnvoll und wo nicht?
SSL-Decryption gehört de facto nicht auf Core-Systeme eines ISP und sollte nicht zum Überwachen oder Ausspähen dienen. Dennoch ist ihre Nutzung in Zeiten von WannaCry und immer besser werdender Malware aus Sicht von Unternehmen unerlässlich. Sie sollte jedoch an ganz klare Regeln geknüpft sein. Wenn alle rechtlichen Grundlagen geschaffen sind, bedeutet SSL-Decryption für ein Unternehmen eine signifikante Steigerung der Sicherheit. Sie ermöglicht einen ganzheitlichen Ansatz – Stichwort SIEM, DLP und andere Security-Mechanismen. Man muss sich jedoch auch der Nachteile bewusst sein, wie des erhöhten administrativen Aufwands und der deutlich höheren Komplexität. Außerdem ist SSL-Decryption kein Allheilmittel und wird immer nur ein Rädchen im großen Ganzen eines Security-Konzepts sein. Am Ende muss man jede Implementierung individuell betrachten und sich überlegen, ob der Zugewinn an Sicherheit den Aufwand in Planung und Umsetzung rechtfertigt.
Verfolgt man einen ganzheitlichen Security-Ansatz, ist eine Implementierung von SSL-Decryption/Interception eine wertvolle Ergänzung, man sollte sich jedoch stets aller damit verbundenen Risiken und Probleme bewusst sein.
Ist SSL-Decryption nun ein Fluch oder ein Segen? Sie kann ein Segen sein, wenn sie richtig implementiert und betrieben wird. Sie kann sich aber auch zu einem Fluch entwickeln, wenn sie schlecht oder unzureichend geplant wurde.
Michael Ibe ist Teamleiter SOC bei Noris Network
- SSL-Decryption – Fluch oder Segen?
- Bevorzugtes Ziel
Lesen Sie mehr zum Thema
