Annahme gefährlicher E-Mails durch Level-of-Trust

[MatthiasUe]

Hallo zusammen,

heute gab es bei uns einen sicherheitsrelevanten Vorfall im Zusammenhang mit dem NoSpamProxy, den ich gerne schildern und zur Diskussion stellen möchte.

Was ist passiert?
Ein E-Mail-Konto eines Partners wurde kompromittiert. Von dort aus wurden E-Mails mit vermeintlichen SharePoint-Freigaben an uns versendet. Sowohl 32Guards als auch der zusätzlich eingesetzte SpamAssassin haben die Nachricht korrekt erkannt – insgesamt wurde ein SCL-Wert von 5 vergeben.

Da es sich aber um einen langjährigen Partner mit hoher Kommunikationsfrequenz handelt, war der Level of Trust (LoT) entsprechend hoch. Das führte leider dazu, dass der NoSpamProxy alle E-Mails trotz des hohen SCLs angenommen hat.

Warum ist das problematisch?
Das ist natürlich hochgradig gefährlich – vermutlich auch nicht im Sinne des ursprünglichen Konzepts von LoT. Dass LoT effektiv zur Reduzierung von False Positives beiträgt, steht außer Frage. Aber in Fällen wie diesem – kompromittierter, "vertrauenswürdiger" Absender – ist die Mechanik schlicht kontraproduktiv.

Ich glaube, der ursprüngliche Gedanke hinter LoT war eher, harmlosen Spam von etablierten Kommunikationspartnern zu filtern – aber nicht gefährliche E-Mails, die über einen gehackten Absender hereinkommen, blind durchzuwinken.

Fragen an euch:
- Habt ihr ähnliche Erfahrungen gemacht?
- Wie habt ihr NoSpamProxy konfiguriert, um solche Fälle zu verhindern?
- Gibt es Best Practices, wie man den Einfluss des LoT in solchen Situationen sinnvoll begrenzen kann?

Meine Gedanken / mögliche Verbesserungen:
- Eine Option im Filter wie: "Ignoriere den LoT-Score, wenn der SCL einen bestimmten Schwellenwert überschreitet"
- Möglichkeit, den maximal möglichen LoT-Score global zu begrenzen (z. B. auf 30 statt 100)
- Den Gewichtungsfaktor für 32Guards deutlich erhöhen (derzeit bei uns auf 1), um dem mehr Durchschlagskraft zu geben

Ich bin gespannt auf eure Meinungen und Erfahrungen.

PS: Wir nutzen NSP On-Premise.

Viele Grüße
Matthias

 

[JanJäschke]

Guten Morgen Matthias,

könntest du dazu einen (gern auch geschwärzten) Messagetrack bereitstellen?
Mich würden die genauen Bewertungen nämlich interessieren.
Der Gedanke hinter Level of Trust ist zusätzlich auch, temporäre/unbeabsichtigte oder ungewollte Reputationsprobleme beim Partner zu korrigieren. Dein Szenario ist natürlich ein negativer Nebeneffekt wir mal schauen könnten was wir besser machen können.
Bei Aktionen wie dem Malware-Scanner wird LoT ja gänzlich umgangen um genau solche Fälle zu vermeiden.

Bin gespannt was z.B. der ein oder andere hier dazu sagt und wie die Nachricht verarbeitet wurde

Gruß
Jan

 

[Sören]

Was mich interessieren würde: war URL Safeguard aktiv und konnte der noch eingreifen beim Klicken des Users?

Zuletzt hatten wir das gesehen als Hafnium um sich Griff und Reply Chain Attacken gefahren wurden.

Eine Empfehlung wie man besser damit umgehen könnte, kann ich nicht bieten.

 

[MatthiasUe]

Guten Morgen Jan,
guten Morgen Sören,

es war ja gestern schon ein bisschen später und eigentlich bin ich auch im Urlaub, daher hatte ich mir den Screenshot vom Filter nur flüchtig angeschaut und muss ein paar Dinge richtig Stellen: SpamAssassin hat leider nichts gesehen, der Reputationsfilter hat einen 1 SCL vergeben.

Laut Anzeige soll das LoT-System 2 Minuspunkte vergeben haben, weiter oben steht dann aber -10 SCL. Das kann man auch im MessageTrack sehen. Den habe ich dir per PN geschickt, Jan.

Das die Aktionen immer das letzte Wort haben finde ich auch richtig und gut. Leider wissen die Angreifer ja aber auch das heutzutage viele Mailgateways genau diese Anhänge scannen und ggf. dadurch die E-Mail auch abgelehnt wird. Also werden nur noch html E-Mails geschickt mit einem Link wo man dann doch bitte die Datei herunterladen soll.

Der URL Safeguard ist leider nicht aktiv, wir hatten ihn an aber leider war der Gegenwind dermaßen stark das wir ihn wieder ausschalten mussten.

Viele Grüße
Matthias

 

[MatthiasUe]

Moin Jan,

konntest du dir die Messagetrack Datei schon anschauen?

Es würde mich freuen wenn noch andere ihre Erfahrungen teilen könnten, gerne auch wenn man dieses Phänomen noch nicht beobachten konnte. Ich finde schon das es sich hier um ein wichtiges Thema handelt wenn solche E-Mails angenommen werden.

Viele Grüße
Matthias

 

[Fabian]

Hallo Matthias,

wir hatten das Vergnügen mit kompromittierten Partner auch schon - dann wurden im Nachgang die Mails zurück geholt und der Partner vorerst gesperrt.

Da wir (du und ich) den URL-SafeGuard nicht aktiv haben (Bei mir zwecks Vorzug für SafeLinks wegen MS Teams) werden wir wohl nicht rausfinden ob der in diesem Falle geholfen hätte - zumal dieser für mich als letzte Bastion gilt, ein wegfiltern durch 32 Guards auf der GW Ebene wäre wesentlich wünschenswerter als erst wenn der User auf den Link klickt.

Zu deinem Gedanken und die Verbesserungsvorschläge:
- Eine Option im Filter wie: "Ignoriere den LoT-Score, wenn der SCL einen bestimmten Schwellenwert überschreitet"
sowie
-Möglichkeit, den maximal möglichen LoT-Score global zu begrenzen (z. B. auf 30 statt 100)
Würde ich am ehesten noch sehen. Meinetwegen auch gerne in einer XML-Steuerdatei anstatt in der GUI.

- Den Gewichtungsfaktor für 32Guards deutlich erhöhen (derzeit bei uns auf 1), um dem mehr Durchschlagskraft zu geben
Dies kann bekannter weiße zu vermehrten FalsePositives führen.

Letztendlich macht das LoT genau, dass was es soll, mit seinen Vor- sowie in diesen Fall Nachteilen.

LG
Fabian

 

[mabu]

Zur Gewichtung von 32Guards hatte ich vor einigen Monaten schon einmal eine Diskussion. Aufgrund der Rückmeldungen damals hatte ich den Faktor tatsächlich auf 2 erhöht. Das hat zu Beginn auch scheinbar super funktioniert. Nur muss es dann irgendwann gekippt sein, so dass wir immer mehr erwünschte Mails abgelehnt hatten.

Ich hatte dann vor kurzem einen neuen Beitrag hier im Forum und da hieß es dann, dass der Faktor bei 32Guards bei 1 bleiben sollte, um genau solche Nebenwirkungen zu vermeiden. Dies hat das Problem der False-positives dann wieder verbessert. Dafür kommen aber auch wieder mehr unerwünschte Mails durch.

An URL SafeGuard haben wir uns auch noch nicht rangetraut.

 

[MatthiasUe]

Guten Morgen,
dann werden wir 32Guards auch nicht anpassen. Den Multiplikator kann ich nur anpassen wenn dadurch die False-Positive Rate nicht steigt.

Bedeutet zusammengefasst: LoT-System verbessert die False-Positive Rate begünstig dadurch aber natürlich die Annahme von Mails gehackter Partner und 32Guards können wir nicht zu 100% vertrauen da dieser selbst False-Positive produziert.

Das ist eher eine schlechte Kombination und ich hoffe das dort auf Seiten des Herstellers Lösungen gefunden werden, sonst sehe ich den langfristigen Einsatz von NSP bei uns eher kaum gegeben. Natürlich hat NSP auch viele Vorteile, dass möchte ich gar nicht bestreiten und ich nutze die Software wirklich sehr gerne. In erster Linie soll diese Lösung aber Spam und gefährliche E-Mails abwehren und wenn diese Grundfunktion irgendwann bei anderen Anbietern besser umgesetzt ist, werden die Stimmen sich diese mal anzuschauen natürlich auch lauter.

Viele Grüße
Matthias

 

[mabu]

Morgen.

Aber das Problem bei gehackten Accounts hat man bei der Mailannahme doch immer - egal welche Security-Lösung dort eingesetzt wird.

Wenn von einem unserer Dienstleister auf einmal unerwünschte Mails kommen (also wirklich von deren erlaubten Mailservern), dann können wir nur nach internen Hinweisen auf merkwürdige Mails oder auf Hinweise des Dienstleisters selbst, diese Domäne mit in die Blockregel packen. So haben wir dies zumindest bisher gehandhabt (kam aber in 5 Jahren auch weniger als 5x vor, meine ich).

Wenn ich sehe, was von z.B. Google-Accounts an Mist durchgeht, weil die Mail technisch absolut perfekt ist (besser als von vielen Unternehmen), nur der Empfänger am Text eindeutig merkt, dass die Mail nicht erwünscht ist (oft auch ohne Link drin), muss aus meiner Sicht irgendwie die Bewertung des Inhalts der Mail irgendwie mit einbezogen werden. Wortfilterlisten helfen da nur bedingt - zumindest bei uns so.

Und irgendwie vermute ich, dass dies ohne den Einsatz von KI, die den Inhalt der Mail bewertet, auf lange Sicht nicht mehr machbar sein wird.

 

[MatthiasUe]

Hallo Martin,

genauso sehe ich es auch, es muss KI zum Einsatz kommen die den Inhalt von E-Mails bewertet. Diese würde dann auch die E-Mails von gehackten Accounts erkennen und blocken.

 

[JanJäschke]

Hallo zusammen,

danke für den regen Austausch und sry @MatthiasUe das ich erst jetzt dazu komme mich wieder zu melden.
Der MSG Track ist in Ordnung, die Kalkulation ist laut Entwicklung korrekt.

Das wir im Bereich der Auswertung des E-Mail Body etwas tun müssen steht auch für mich außer Frage. Dies wollen wir auch angehen (gewünscht früher als später )
Wie in einem anderen Thread schon angerissen ist KI ein möglicher Weg, einer den wir auch betrachten, KI birgt aber auch Risiken in sich.
Zudem skaliert eine aktiv lernende KI natürlich je nach Größe des Unternehmens unterschiedliche und eine reine Cloud Lösung wird denke ich von den Server Kunden auch keiner begrüßen, denn dann sehen wir als Hersteller den kompletten E-Mail Verkehr (etwas überspitzt aber je nach Umsetzung nicht ausgeschlossen)

Ich möchte aber viel mehr darauf hinweisen, dass eine KI ebenfalls nicht sicher sagen können wird ob ein kompromittiertes Konto vom Kommunikationspartner nun eine legitime E-Mail verschickt hat oder nicht. Natürlich gibt es die offensichtlichen Fälle, aber was ist mit dem Fall, dass das Rechnungswesen kompromittiert ist? Die Rechnungen kommen dann ja immer noch vom korrekten Absender, der Inhalt wird auch recht passend sein, da wird der Angreifer dann drauf achten.
Ich möchte damit aufzeigen, dass es das Problem auch nicht gänzlich löst, denn es gibt keine 100% Lösung für einen solchen Fall, ebenso wenig gibt es 100% Sicherheit - das ist ausgeschlossen.

Level of Trust ist in diesem Fall eine Erleichterung gewesen um die E-Mail durchzubekommen, es ist aber auch niemand gezwungen dies zu verwenden. Schaltet es ab und ihr habt eine härtere Durchsetzung und ein etwas sichereres System.
Im Umkehrschluss werden aber die False-Positives (FP) bei regelmäßiger Kommunikation steigen, da viele Unternehmen keine sauberen E-Mails verschicken, mabu hat es schon gut geschildert:

Wenn ich sehe, was von z.B. Google-Accounts an Mist durchgeht, weil die Mail technisch absolut perfekt ist (besser als von vielen Unternehmen)

Und das kann keiner von uns ändern außer durch hartes Durchsetzung von RFCs und Sicherheitsmaßnahmen, was wieder kein Unternehmen möchte da es teils auch geschäftsschädigend sein kann.
Und hier schließt sich der kreis wieder zum Level of Trust, diese Lücke der FPs soll zum aufrecht halten der Kommunikation geschlossen werden.
Brecht den Teufelskreis, haut den anderen auf die Finger und härtet die Konfiguration und die Chance, dass schlechte E-Mails rein kommen sinkt weiter (wäre hier im Beispiel ja sogar passend gewesen).


Das soll nun keine Ausrede oder ähnlich sein, wir als Hersteller sind daran interessiert unser Produkt sicherer und besser zu machen. Das Katz- und Mausspiel ist in der Sicherheitsbranche mehr als bekannt, aber wir sind ebenso daran interessiert, dass der Kunde ein Produkt im Einsatz hat mit dem er im Umgang und Flexibilität zufrieden ist. Daher versuchen wir immer einen konfigurierbaren Kompromiss zu schaffen

Und damit wünsche ich erstmal ein schönes Wochenende

 

[MatthiasUe]

Hallo @JanJäschke ,

vielen Dank für deine Rückmeldung und die ausführliche Einschätzung zu dem Thema.

Natürlich ist KI nicht das Allheilmittel – da gebe ich dir vollkommen recht. Aber ich bin überzeugt, dass sie in Zukunft ein wichtiger Baustein zur Erkennung komplexer Angriffsmuster sein wird, auch wenn sie nicht jede Situation zuverlässig abdecken kann.

Auch das vollständige Abschalten des Level of Trust sehe ich eher kritisch. Wie du schon sagst, ist es ein wertvoller Mechanismus, um die Kommunikation aufrechtzuerhalten und False Positives zu vermeiden.

Vielleicht lässt sich ja dennoch die ursprüngliche Idee nochmal intern diskutieren:
Eine Filter-Option à la „LoT ignorieren, wenn SCL > X“ – als konfigurierbarer Schwellwert. Ich weiß, das wird nicht alle Fälle lösen, aber es könnte zumindest in genau solchen Grenzfällen wie dem hier geschilderten einen sinnvollen Ausgleich schaffen.

Insgesamt bleibt es, wie du treffend sagst, ein Katz-und-Maus-Spiel. Umso wichtiger finde ich die Möglichkeit, auf Konfigurations- und Erkennungsebene flexibel zu bleiben.

Viele Grüße
Matthias

 

[Sören]

Vielleicht lässt sich ja dennoch die ursprüngliche Idee nochmal intern diskutieren:
Eine Filter-Option à la „LoT ignorieren, wenn SCL > X“ – als konfigurierbarer Schwellwert. Ich weiß, das wird nicht alle Fälle lösen, aber es könnte zumindest in genau solchen Grenzfällen wie dem hier geschilderten einen sinnvollen Ausgleich schaffen.

..und würde deutlich mehr neue Probleme offerieren, wäre ich kein Fan davon.

Was man machen könnte so als Hirnfurz: Man könnte das gewünschte: SCL bei vorhanden -SCL ans Greylisting koppeln. Aber dann hast du wieder User auf der Matte stehen, die sich beschweren warum die Mails so zeitverzögert rein kommen.

 

[MatthiasUe]

Das mit dem Greylisting in Kombination mit SCL-Kopplung habe ich letzte Woche mal aktiviert – schauen wir mal, was es bringt

@Sören: An welche konkreten Probleme denkst du bei einer zusätzlichen Option wie „LoT ignorieren, wenn SCL > X“?

Wenn eine E-Mail reinkommt, bei der mehrere Filter anschlagen und sie z. B. mit einem SCL von 8 bewertet wird – warum sollte ich diese überhaupt noch durchlassen wollen? Das ist doch in der Regel mehr als nur eine fehlerhafte Konfiguration beim Absender. In so einem Fall liegt sehr wahrscheinlich ein akutes Problem vor – etwa ein kompromittiertes Konto beim Partner.

Mir geht’s ja gar nicht darum, so eine Option standardmäßig zu aktivieren, sondern einfach darum, sie als konfigurierbare Möglichkeit zu haben. Ich denke, das könnte in Einzelfällen helfen – gerade bei solchen Grenzbereichen zwischen Vertrauen und technischer Erkennung.

Am Ende will ich ja nur mithelfen, den NSP noch besser und flexibler zu machen

Viele Grüße
Matthias

 

[Sören]

An welche konkreten Probleme denkst du bei einer zusätzlichen Option wie „LoT ignorieren, wenn SCL > X“?

Naja genau das, was Jan auch schon beschrieben hat Dann hast du wieder mehr false positive bei legit Mails nur weil der Partner mal Mist baut

Wie gesagt, für mich ist das nicht die Lösung... der SCL ist ja auch nur dazu da, die Wahrscheinlichkeit zu berechnen und ist kein harter Filter (Aktion) wie Malwarescan, URL Safeguard usw... in deinem Fall gab es ja von den Filtern auch keine explizite Aussage sondern lediglich die Wahrscheinlichkeitsrechnung das dies Murks sein könnte.

Deswegen den LoT auszuhebeln ergibt für mich wenig Sinn. Aber ich lass euch da gerne diskutieren Mal schauen was andere dazu sagen.