TLS-Verbindungen an Firewall aufbrechen, gute Idee?

[wznutzer 37]

Hallo zusammen,

 

bisher habe ich auf das Scannen von TLS-Verbindungen verzichtet. Die Reputation vom Ziel wurde geprüft, aber halt nicht der Inhalt. Ich/wir haben sogar aktiv die Nutzer geschult, wenn es einen Anlass gibt, das Zertifikat anzuschauen, ob ich wirklich da bin wo ich hin will. Das klappt natürlich nicht bei allen Anwendern. Künftig sähe man da immer das Zertifikat, das die Firewall ausliefert.

 

Gehört es zu den Sicherheits-Best-Practices TLS-Verbindungen aufzubrechen, um den Inhalt der Verbindung prüfen zu können?

 

Ich weiß nicht so recht, ob ich das gut finden soll.

 

Danke und Grüße

bearbeitet 23. April von wznutzer
Schreibfehler

[gaijin 20]

Hallo,

da wirst Du sicherlich vielfältige Meinungen erhalten, da es ein stark umstrittenes Thema ist.

Wir brechen bei unseren Kunden die Verbindungen in der Firewall auf und prüfen auf den Datenstrom auf Schadcode, Botnetz Kommunikation, etc. Das geht natürlich, wie Du schon richtig bemerkt hast, nicht mit allen Zielen und muss entsprechend mit Ausnahmen gepflegt werden.

 

Viele Grüße!

 

[cj_berlin 1.578]

Ich finde es immer lustig, solche Geschichten bei Banken & Co vorzufinden, deren eigene Websites und Apps durch die Bank mit Cert Pinning arbeiten, um zugelassen zu werden, und be TLS Inspection auf die Nase fallen würden...

 

Die Frage ist hier wie immer: und was macht dann wer mit dem Klartext? Neben dem Ausnahmen muss hier nämlich auch die Detection Engine gepflegt werden und auf Findings Aktivitäten folgen. Andernfalls ist es für die Füße und verbrennt nur unnötig Energie.

 

 

bearbeitet 23. April von cj_berlin

[gaijin 20]

vor 4 Minuten schrieb cj_berlin:

Ich finde es immer lustig, solche Geschichten bei Banken & Co vorzufinden, deren eigene Websites und Apps durch die Bank mit Cert Pinning arbeiten, um zugelassen zu werden, und be TLS Inspection auf die Nase fallen würden...

 

Die Frage ist hier wie immer: und was macht dann wer mit dem Klartext? Neben dem Ausnahmen muss hier nämlich auch die Detection Engine gepflegt werden und auf Findings Aktivitäten folgen. Andernfalls ist es für die Füße und verbrennt nur unnötig Energie.

 

 

 

Das ist absolut korrekt, Banking und auch Medizin, sowie Papa Staat sollten (müssen) bei der TLS Inspection als Ausnahme definiert werden. Das hier eine Pflege und Überwachung der Detections erfolgen muss versteht sich von selbst (dachte ich ).

[cj_berlin 1.578]

Wenn sich irgendwas in Cybersecurity von selbst verstehen würde, könnte ich endlich mit dem Schreinern anfangen...

[wznutzer 37]

vor 1 Stunde schrieb gaijin:

Das ist absolut korrekt, Banking und auch Medizin, sowie Papa Staat sollten (müssen) bei der TLS Inspection als Ausnahme definiert werden. Das hier eine Pflege und Überwachung der Detections erfolgen muss versteht sich von selbst (dachte ich ).

 Das ist mir klar. Das gilt aber auch bei allem anderen, was irgendwelche Alerts auslösen kann. Mir ging es eher um das Grundsätzliche, also, ob man das oft sieht, man eher machen sollte oder doch eher nicht.

[gaijin 20]

vor 2 Minuten schrieb wznutzer:

 Das ist mir klar. Das gilt aber auch bei allem anderen, was irgendwelche Alerts auslösen kann. Mir ging es eher um das Grundsätzliche, also, ob man das oft sieht, man eher machen sollte oder doch eher nicht.

 

Es läuft mir persönlich sehr häufig über den Weg. Meine Meinung dazu: Man sollte heutzutage TLS Inspection betreiben.

[NorbertFe 2.401]

vor 32 Minuten schrieb gaijin:

Meine Meinung dazu: Man sollte heutzutage TLS Inspection betreiben.

Was mich bei dem Thema ja immer mal wirklich interessieren würde: Warum? Also gibts wirklich irgendwo mal "belastbare" Zahlen (aus der Praxis und nicht von den Firewallherstellern), in denen man sehen kann, dass dort wirklich effektiv ein Threat unterbunden wurde?

Ich kenne das eher so: Wir aktivieren das mal, weil dann der Traffic gescannt wird. An dieser Stelle endet dann die Argumentation in fast allen Fällen.

 

Für mich als halbwegs technisch versierten Anwender bringt TLS Inspection vor allem zwei Dinge:

1. Nervereien, weil ich selbst die Zertifikate nicht prüfen kann (und mir dann immer einen Host ohne TLS Inspection suchen muss um mal ne Aussage zum Problem treffen zu können.

2. Datenschutzüberlegungen, weil mein Traffic eben für verschiedenste Teilnehmer auf einmal sichtbar wird. Kann man mit "Firmenpolicy" wegargumentieren, aber deswegen muss es mir ja nicht gefallen.

 

Bye

Norbert 

[gaijin 20]

vor 17 Minuten schrieb NorbertFe:

Ich kenne das eher so: Wir aktivieren das mal, weil dann der Traffic gescannt wird. An dieser Stelle endet dann die Argumentation in fast allen Fällen.

Für mich als halbwegs technisch versierten Anwender bringt TLS Inspection vor allem zwei Dinge:

1. Nervereien, weil ich selbst die Zertifikate nicht prüfen kann (und mir dann immer einen Host ohne TLS Inspection suchen muss um mal ne Aussage zum Problem treffen zu können.

2. Datenschutzüberlegungen, weil mein Traffic eben für verschiedenste Teilnehmer auf einmal sichtbar wird. Kann man mit "Firmenpolicy" wegargumentieren, aber deswegen muss es mir ja nicht gefallen.

 

Wir betreiben das bei unseren Kunden (natürlich nach Rücksprache und unter Beachtung der Datenschutzrichtlinien) in Verbindung mit einer Thread-Detection und einem Alerting. Als kritisch eingestufte Threads isolieren automatisch den Host. Das geht natürlich etwas über die reine TLS-Inspection hinaus.
Wir haben tatsächlich immer wieder Erkennungen, die von der Firewall durch die TLS-Inspection unterbunden wurden. Der Ansatz ist für uns; wenn der AV-Client auf dem Endpunkt anschlägt, haben wir im Vorfeld an der Eingangstür etwas nicht beachtet.

Zu 1.: Da ja für spezifische Ziele Ausnahmen definiert werden müssen, gibt es hier auch kein Hickhack mit den Zertifikaten, da diese ja eine direkte Verbindung aufbauen. Aber auch hier gibt es verschiedene Ansätze, z.B. kann man Regeln für die spezifischen Ziele oberhalb der TLS-Inspection Policy ansiedeln, dann passiert da erstmal nix und man muss keine Ausnahme in der Inspection definieren.
Zu 2.: Vollkommen korrekt, dass muss natürlich im Vorfeld geklärt und absolut offen und transparent besprochen werden.

Zusammenfassend kann ich sagen, tatsächlich ist TLS-Inspection alleine kein Allheilmittel. In Verbindung mit weiteren Diensten ist es (meiner Meinung nach) ein durchaus nicht zu unterschätzender Benefit. Aber wie ich schon Anfangs erwähnt hatte, die Meinungen gehen in der Thematik berechtigterweise durchaus auseinander.

[mwiederkehr 419]

vor 56 Minuten schrieb NorbertFe:

Ich kenne das eher so: Wir aktivieren das mal, weil dann der Traffic gescannt wird. An dieser Stelle endet dann die Argumentation in fast allen Fällen.

Ich kenne es als "wieso konntest du die EICAR.COM downloaden, wo wir doch extra die AV-Lizenz für die Firewall gekauft haben?" 

 

Man muss den Traffic lesen können, um ihn filtern zu können. Die Filterung nach Zertifikat (oder SNI bei TLS 1.3) funktioniert im Zeitalter der Cloud nicht zuverlässig. OneDrive ist einer der grössten Malware-Hoster.

 

Neben der Sicherheit gibt es Anforderungen zur Filterung nach Inhaltskategorien. Ein Kunde wollte Facebook erlauben (weil die Mitarbeiter "Content" produzieren sollten), aber den Facebook Chat deaktiviert haben.

[zahni 597]

Ich bin der Meinung, dass TLS-Inspection UNBEDINGT notwendig ist. 

Wichtiger ist aber ein funktionierender Inhaltsfilter um wirklich jeden ausführbaren Code herauszufiltern, auch weil mittlerweile jede Website SSL benutzt. 

Der Virenscanner am Proxy soll zusätzlich in der Lage sein, als HTML kodierte Viren zu erkennen.

Das ist die 1. Bastion gegen Malware. 

Die letzte Bastion ist dann der Applocker auf dem Windows-Client. 

 

Man kommt dann leider nicht darum herum, kleinteilig Ausnahmen zu definieren, sei es für Anwendungen, die das Zertifikat vom Proxy nicht akzeptieren oder man tatsächlich einen Binär-Download braucht. Das Ganze kann man dann noch mit einem Proxy-SSO ergänzen, um bestimmten Benutzern andere Richtlinien zuzuweisen. Und natürlich kann man den Abfluss von Daten eindämmen, wenn man sog. "Online-Festplatten" verbietet. Ok, dazu braucht man kein TLS Inspection. 

 

 

bearbeitet 24. April von zahni

[NilsK 3.140]

Moin,

 

vor 18 Stunden schrieb NorbertFe:

An dieser Stelle endet dann die Argumentation in fast allen Fällen.

 

das ist ja ein häufiger Effekt, auch bei vielen anderen Themen. Am Ende ist es "hamwa schon imma so jemacht, hamwa noch nie so jemacht, könnte jajeder komm".

 

vor 18 Stunden schrieb gaijin:

unter Beachtung der Datenschutzrichtlinien

 

Das ist quasi das Gegenstück dazu. Was heißt das denn in dem Fall? Ihr inspiziert, und wenn etwas drin ist, was nach personenbezogenen Daten aussieht, dann schaut ihr schnell weg? Eher nicht, oder?

 

Gruß, Nils

 

bearbeitet 24. April von NilsK

[gaijin 20]

vor 51 Minuten schrieb NilsK:

Das ist quasi das Gegenstück dazu. Was heißt das denn in dem Fall? Ihr inspiziert, und wenn etwas drin ist, was nach personenbezogenen Daten aussieht, dann schaut ihr schnell weg? Eher nicht, oder?

 

 

Das bedeutet, dass wir dem Kunden im Vorfeld erklären, was wir dort tun. Es geht hier ja weniger darum personenbezogene Daten auszuwerten, sondern nach unserem Verständnis die Transparenz zu schaffen, was möglich wäre und wie damit umgegangen wird. Dazu gehört z.B.; wir zeichnen Daten auf (Verbindungsdaten, Firewall-Logging) und müssen dafür Sorge tragen, dass diese entsprechend geschützt sind.

Und ja, natürlich sollte das selbstverständlich sein. Ist es aber nach meiner Erfahrung bei weitem nicht.

 

[NilsK 3.140]

Moin,

 

vor 20 Minuten schrieb gaijin:

Das bedeutet, dass

 

öhem, sorry, das klang, als wollte ich dich bloßstellen. Wollte ich nicht, das war eher ein allgemeiner Punkt.

 

Was du an Aufklärung des Kunden beschreibst, ist angemessen.

 

Gruß, Nils