MatthiasUe
Active member
- Registriert
- 4 Juli 2023
- Beiträge
- 43
- Reaktionspunkte
- 12
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
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