Sophos Email Data Control: DLP-Regeln sicher konfigurieren

Sophos Email nennt den Schutz vor Datenverlust im E-Mail-Verkehr Data Control. Eine Regel definiert, welche Daten Sophos in Betreff, Nachricht und Anhängen sucht, für welche Richtung und externen Adressen sie gilt und welche Aktion bei einem Treffer folgt. Das ist nicht dieselbe Richtlinie wie Endpoint-DLP: Data Control prüft E-Mails, während Data Loss Prevention Rules (DLP) andere Datenabflüsse auf Endpoints kontrollieren.

Sicherer Schnellweg: Zuerst einen kleinen Pilot-Scope festlegen, eine Sophos-Vorlage oder wenige passende CCLs wählen, die Regel mit Log oder Quarantine beginnen lassen und sie oberhalb breiterer Regeln platzieren. Danach mit einem positiven, einem ähnlichen negativen und einem erlaubten Geschäftsvorgang testen. Erst wenn Data Control summary und Message History richtige Treffer und Nichttreffer zeigen, wird die endgültige Aktion aktiviert.

Scope, Verantwortung und Rückweg vorbereiten

Vor der Konfiguration bestimmt der fachliche Data Owner, was geschützt wird und was bei einem Treffer geschehen darf. Der Admin übersetzt diese Entscheidung in eine technische Regel. Mindestens diese Angaben gehören ins Change:

• Richtung Inbound oder Outbound;
• interne Benutzer, Gruppen oder Domains und gegebenenfalls externe Adressen oder Domains;
• zu erkennendes Datenmuster, erlaubter Geschäftsvorgang und verantwortlicher Owner;
• gewünschte Aktion, Benachrichtigungsempfänger und Eskalationsweg;
• je ein kontrolliertes positives und negatives Testbeispiel;
• bisheriger Richtlinienzustand, Regelposition und Rollback-Kriterium.

In einer Data-Control-Richtlinie sind bis zu 25 Regeln möglich. Sophos wertet sie von oben nach unten aus und wendet die erste passende Regel an. Eine enge Ausnahme gehört deshalb vor die allgemeine Schutzregel; eine spezifische Sperre gehört vor eine breitere Protokollierungsregel. Continue processing ist eine bewusste Ausnahme von diesem Modell: Wenn die gewählte Aktion die Option unterstützt und man sie einschaltet, prüft Sophos nach der Aktion die nächste Regel weiter. Man verwendet sie nur, wenn die Kombination der Aktionen im Test eindeutig belegt wurde.

Policies und Regeln haben getrennte externe Scopes. Auf Policy-Ebene legt man den grundsätzlichen externen Adressraum fest; auf Regel-Ebene verengt man ihn mit External senders bei Inbound oder External recipients bei Outbound weiter. Include all, Include list und Exclude list beziehen sich auf SMTP-Envelope-Adressen, nicht auf die sichtbaren From- und To-Header. Beim Import muss die Datei CSV oder TXT sein, einen Eintrag pro Zeile enthalten und darf zusammen mit bestehenden Einträgen höchstens 100 Einträge umfassen. Replace all existing entries with this import ersetzt die vorhandene Liste vollständig.

Ausnahmen nie nur nach Anzeigenamen oder sichtbarem From-Header bauen. Eine Domain-Ausnahme kann alle Empfänger oder Absender dieser Domain erfassen und damit mehr Datenverkehr freigeben als beabsichtigt. Für wiederkehrende legitime Vorgänge ist eine Pilotgruppe oder eine exakt begrenzte Envelope-Adresse sicherer. Die Ausnahme erhält einen Owner, einen Ablauf- oder Review-Termin und einen eigenen Positiv- und Negativtest.

Falls mehrere Sophos-Email-Policies dieselben Benutzer betreffen, muss zusätzlich die Policy-Zuweisung stimmen. Der Ablauf unter Sophos Email Security: Richtlinien gezielt zuweisen erklärt Scope und Priorität auf Policy-Ebene.

Data-Control-Richtlinie und Regel anlegen

1. In Sophos Fusion (ehemals Sophos Central) My Products > Email Security > Policies öffnen.
2. Add Policy, danach Data Control und Continue wählen.
3. Einen eindeutigen Namen vergeben, beispielsweise DLP-Outbound-Finance-Pilot.
4. Unter Internal nur die Pilotbenutzer, -gruppe oder -domain hinzufügen. External nur setzen, wenn die ganze Policy auf bestimmte externe Ziele begrenzt werden soll.
5. Settings öffnen und für die Regel Inbound oder Outbound wählen.
6. Add rule anklicken, Name und Beschreibung eintragen und den passenden Rule type auswählen.
7. Unter Add items Erkennungslisten und unter Search in die benötigten Orte festlegen: Subject, Body, Attachment Name und/oder Attachment Content.
8. Unter Message Attributes bei Bedarf zusätzliche Bedingungen für Header, Quelle oder Grösse setzen.
9. External senders beziehungsweise External recipients eng begrenzen.
10. Unter Choose action die Pilotaktion und Benachrichtigungen wählen. Continue processing nur für eine absichtlich getestete Regelkette aktivieren.
11. Filter messages with this rule einschalten und Save wählen.

Eine neu erstellte Policy enthält noch keine Regeln. Eine geklonte Policy steht zunächst auf Policy Bypassed, enthält keine Benutzer, Gruppen oder Domains und hat standardmässig höhere Priorität als das Original. Vor Policy is enforced kontrolliert man daher Zuweisung, Regeln und Priorität. Im EMS mode kann man Data Control zwar konfigurieren, die Aktionen werden aber nur als erwartetes Ergebnis gemeldet und nicht auf Nachrichten angewendet.

Den passenden Erkennungstyp wählen

Vorlagen für typische sensible Daten

Die Vorlagen Financial information (FI), Confidential information (CI), Health information (HI) und Personally identifiable information (PII) verwenden von Sophos ausgewählte Content Control Lists. FI zielt beispielsweise auf Konto- oder Kreditkartendaten, HI auf medizinische beziehungsweise Patientendaten und PII auf nationale ID- oder Passnummern. Als Ausgangspunkt verwendet man Use Sophos list und wählt nur die benötigten Suchorte.

Use custom list lädt zunächst die für die Vorlage empfohlenen CCLs. Danach kann man CCLs hinzufügen oder entfernen und Match-Schwellen ändern. Das ist keine harmlose Feinabstimmung: Entfernte empfohlene CCLs verringern möglicherweise die Abdeckung, unpassende zusätzliche CCLs erhöhen Fehlalarme. Eine Anpassung braucht deshalb reale, anonymisierte Datenmuster des Owners und erneute Positiv- und Negativtests.

Eigene CCL-Regel

Eine benutzerdefinierte Content control lists (CCLs)-Regel passt, wenn eine bestimmte regionale oder fachliche Kennung erkannt werden soll. Man filtert die Auswahl nach Region und Datentyp, liest die Erklärung am Information-Symbol und wählt nicht pauschal alle Listen. Der Filter RECOMMENDED zeigt regionsbezogene Empfehlungen; ohne Regionsfilter soll man nicht einfach alle angezeigten CCLs aktivieren. Veraltete Listen findet man gegebenenfalls nur ungefiltert oder unter Deprecated. Bestehende Regeln zeigen sie weiterhin, sie sollten aber im Review durch unterstützte Alternativen ersetzt werden.

Bei Number of matches gilt:

• Ein höherer Wert macht die einzelne CCL strenger und reduziert typischerweise False Positives, kann aber echte Treffer übersehen.
• Ein niedrigerer Wert macht sie empfindlicher und reduziert typischerweise False Negatives, kann aber mehr legitime E-Mails treffen.
• Trigger this rule by number of CCL matches entscheidet zusätzlich, wie viele ausgewählte CCLs zutreffen müssen; alternativ verlangt All the CCLs must match jede ausgewählte CCL.

Diese beiden Schwellen lösen unterschiedliche Fragen. Beispielsweise kann eine CCL intern zwei Kartennummern verlangen, während die Regel nur eine von drei ausgewählten CCLs benötigt. Standardwerte ändert man nur, wenn Testfälle die fachliche Notwendigkeit belegen.

Keywords und reguläre Ausdrücke

Keywords (KW) sucht Wörter, Phrasen, Unicode-Zeichen oder reguläre Ausdrücke in den gewählten Suchorten. Reguläre Ausdrücke dürfen höchstens 50 Zeichen lang sein, müssen der Perl-Syntax der Boost-Bibliothek entsprechen und dürfen aus Performancegründen keine Gruppen in Klammern enthalten.

Keyword- und Regex-Matching funktioniert nur bei UTF-8-codiertem Nachrichteninhalt. Bleibt ein offensichtlicher Treffer aus, prüft man deshalb die tatsächliche Content-Transfer- und Zeichenkodierung statt den Ausdruck sofort breiter zu machen. Für strukturierte Ausweis-, Konto- oder Kartendaten ist eine passende CCL meist robuster als ein allgemeines Wort wie confidential.

Dateitypen und Dateiinhalt

Attachment file types (AFT) kann nach Dateiendungen oder nach erkannten Dateigruppen beziehungsweise True File Type filtern. In einer benutzerdefinierten AFT-Regel lässt sich beides nicht kombinieren. Benötigt man beide Methoden, erstellt man zwei getrennte Regeln und testet deren Reihenfolge.

Für Endungen gilt die Syntax ohne Leerzeichen, mit führendem Punkt und Kommas, zum Beispiel:

.doc,.docx,.pdf,.zip

Die Eingabe darf höchstens 1.000 Zeichen umfassen. Eine Endungsregel lässt sich durch Umbenennen täuschen; eine Dateigruppenregel prüft den erkannten Typ. Die Sophos list kombiniert dokumentierte Endungssperren mit True-File-Type-Erkennung unter anderem für ausführbare Formate, Office-Dateien mit Makros, verschleierte Skripte und WebAssembly.

Attachment Content bedeutet nicht, dass jedes sichtbare Element jeder Datei gleich ausgewertet wird. Sophos extrahiert je nach Format unterschiedliche Inhalte und Metadaten: bei PDF beispielsweise Text-Streams und Dokumentmetadaten, bei Word auch Header, Footer, Textfelder, Tabellenzellen und nicht sichtbare Kommentare, bei Excel Blattnamen sowie Text- und Zahlenzellen. Ein gescanntes Bild in einer PDF ohne extrahierbaren Text ist daher kein verlässlicher CCL-Test. Für die Abnahme verwendet man unterstützte, textbasierte Beispieldateien und prüft separat, ob Metadaten unbeabsichtigt einen Treffer erzeugen.

Message Attributes sinnvoll verknüpfen

Message Attributes (MA) filtert nach Header, Source oder Size. Headerbedingungen können einen regulären Ausdruck, Teilstring, exakten Wert oder die Existenz beziehungsweise Abwesenheit eines Headers prüfen. Für mehrere Attribute bestimmt Match for: Any oder All, ob eines oder alle zutreffen müssen. Kombiniert man Message Attributes mit einem anderen Rule type, müssen beide Typen matchen.

Grössenbedingungen verwenden bei Anhängen die MIME-codierte Grösse jedes einzelnen Anhangs, nicht die Summe und nicht die Rohdateigrösse. Base64 kann bis zu etwa 37 % aufschlagen; eine binäre Rohdatei mit 20 MB kann daher codiert 28 MB überschreiten. Sophos Email verarbeitet Nachrichten bis 50 MB. Schwellen werden mit echten MIME-Nachrichten getestet und nicht aus der Dateigrösse im Explorer abgeleitet.

Aktion passend zum Risiko auswählen

Die verfügbaren Aktionen hängen von Richtung und Rule type ab. Für einen Pilot sind Log oder Quarantine meist kontrollierbarer als Delete. Die wichtigsten Auswirkungen sind:

• Quarantine: hält die Nachricht zur Prüfung zurück.
• Encrypt: verschlüsselt ausgehende Treffer. Standardmässig gilt die Methode der Secure Message policy des Benutzers; die Regel kann sie übersteuern. Die Policy bleibt für weitere Defaults wie die Sprache der Registrierungsnachricht erforderlich.
• Strip attachments: quarantänisiert das Original und stellt eine Kopie ohne Anhang zu.
• Modify Address: nur CC/BCC ergänzt die Originalempfänger; ein gesetztes To ersetzt die Originalempfänger. Envelope only ändert die MIME-Header nicht.
• Redirect message: leitet die Originalnachricht als Anhang an die Umleitungsadresse weiter.
• Reroute message: routet an IP/FQDN und Port, gilt aber nur für Gateway. Im Mailflow-Modus wird Routing in Microsoft 365 konfiguriert.
• Bounce: informiert den Absender über die Nichtzustellung und ist für Inbound nicht verfügbar.
• Modify Header: fügt einen Header hinzu, ersetzt den ersten Wert oder entfernt alle passenden Header.
• Delete: löscht die Nachricht; diese Aktion erst nach freigegebenem Test und dokumentiertem Incident-Prozess verwenden.
• Log, Tag a subject line und Benachrichtigungen dokumentieren oder markieren einen Treffer, verhindern allein aber keinen Datenabfluss.

Notify others erlaubt bis zu fünf Mailboxen oder Verteilerlisten aus den eigenen E-Mail-Domains. Benachrichtigungen dürfen selbst keine unnötigen sensiblen Inhalte verteilen. Data-Control-Ereignisse erscheinen nicht in Quarantäne-Zusammenfassungen; die Ereignisbenachrichtigung geht direkt an Administratoren.

Verschlüsselungs-Header exakt setzen und kontrolliert testen

Eine passende Data-Control-Regel kann mit Modify Header einen Verschlüsselungs-Header hinzufügen oder ändern. Für diese Konfiguration werden genau die folgenden Header und Werte unterstützt; Schreibweise und Gross-/Kleinschreibung der Werte dürfen nicht verändert werden:

Diese Funktion ist möglicherweise noch nicht für alle Kunden verfügbar. X-SophosEmailEncrypt-NoAuth und X-SophosEmailEncrypt-VerificationCode erfordern das Portal Encryption Add-on; diese Add-on-Grenze gilt nicht pauschal für die anderen drei Header. Eine Verschlüsselungsaktion ist zudem erst betriebsbereit, wenn Lizenz, Secure Message policy, gewählte Methode und Empfängerablauf getestet sind. Die Wirkung der Werte und den Portal-/Push-Ablauf beschreibt Sophos Email Portal- und Push-Verschlüsselung betreiben; hier wird dieser Ablauf nicht dupliziert.

Für die Freigabe wird eine ausgehende Pilotregel nur auf Testabsender und -empfänger begrenzt. Mit Modify Header fügt man zunächst genau einen Header mit einem zulässigen Wert hinzu oder ersetzt dessen vorhandenen Wert. Danach sendet man eine harmlose Portal-Testnachricht und, wenn der Header für diesen Ablauf relevant ist, eine harmlose Push-Testnachricht. In Data Control summary und Message History müssen die erwartete Regel und die Aktion Modify Header erscheinen; zusätzlich wird beim Empfänger oder Absender das erwartete Ergebnis des gesetzten Werts geprüft. Erst danach testet man den nächsten Wert oder erweitert den Scope. Ein Regelmatch allein beweist nicht, dass Verschlüsselung, Ablaufzeit oder Benachrichtigung wie vorgesehen wirksam waren.

Praxisbeispiel: Finanzdaten nach extern

Für eine Pilotgruppe im Rechnungswesen soll eine ausgehende Nachricht mit echten Finanzmustern an externe Empfänger zunächst quarantänisiert werden:

1. Policy DLP-Outbound-Finance-Pilot, Internal: nur die Pilotgruppe, Richtung Outbound.
2. Rule type Financial information (FI) mit Use Sophos list.
3. Search in: Body und Attachment Content. Attachment Name bleibt aus, wenn Dateinamen fachlich kein Signal sind.
4. External recipients: Include all oder eine begrenzte Testdomain. Eine genehmigte Partneradresse wird nur dann als enge Ausnahme darüber platziert, wenn der Data Owner diesen Vorgang freigegeben hat.
5. Aktion Quarantine, Benachrichtigung an das zuständige DLP-Team; kein Continue processing.
6. Positivtest mit einem freigegebenen Testmuster in einer textbasierten DOCX- oder PDF-Datei. Negativtest mit ähnlich formatierten, aber ungültigen Nummern. Geschäftstest mit einem normalen Beleg ohne sensibles Muster.

Erzeugt das normale Belegformat False Positives, wird nicht sofort die ganze Partnerdomain ausgeschlossen. Zuerst klärt man, welche CCL ausgelöst hat, ob Metadaten oder Nachrichtentext den Treffer erzeugten und ob die Standard-Matchzahl fachlich angepasst werden kann. Eine Ausnahme ist die letzte, nicht die erste Korrektur.

Validieren, ausrollen und betreiben

Für jeden Test hält man UTC-Zeit, Richtung, Envelope-Absender und -Empfänger, Betreff, Message-ID, Beispieldatei, erwartete Regel und erwartete Aktion fest. Nach dem Versand prüft man Data Control summary und die Details in Message History. Bestanden ist die Regel nur, wenn:

1. der positive Test die erwartete Data-Control-Kategorie, Regel und Aktion zeigt;
2. der ähnliche negative Test und der normale Geschäftsvorgang nicht matchen;
3. eine definierte Ausnahme nur für ihren exakten Scope greift;
4. andere ein- und ausgehende Nachrichten weiterhin von der vorgesehenen Policy verarbeitet werden;
5. Benachrichtigungen nur an die genehmigten Empfänger gehen.

Anschliessend erweitert man den Scope stufenweise und beobachtet False Positives, False Negatives, Quarantänevolumen und Ausnahmen. CCLs, Match-Schwellen und Ausnahmen erhalten einen regelmässigen Review. Das ist besonders wichtig für Einträge unter Deprecated und für temporäre Partnerausnahmen.

Im Microsoft-365-Mailflow-Modus kann eine Microsoft-Purview-DLP-Regel beim Hin- und Rückweg doppelte Benachrichtigungen erzeugen. Das ist keine Sophos-Data-Control-Regelreihenfolge. Die eng begrenzte Microsoft-Ausnahme und die Prüfung auf echte Routing-Schleifen beschreibt Sophos Email Mailflow: Microsoft 365 systematisch reparieren.

Fehlersuche nach Symptom

Eine erwartete Regel löst nicht aus

1. Policy-Zuweisung, Inbound/Outbound und Envelope-Adressen prüfen.
2. Kontrollieren, ob eine höher platzierte Regel zuerst matcht oder die Regel nicht mit Filter messages with this rule aktiviert ist.
3. Bei kombiniertem MA- und Inhaltstyp prüfen, ob wirklich beide Typen matchen; bei mehreren Attributen Any/All kontrollieren.
4. Suchort prüfen: Ein Treffer in Attachment Content entsteht nicht, wenn nur Attachment Name gewählt wurde.
5. Bei Keywords oder Regex die UTF-8-Kodierung, 50-Zeichen-Grenze und verbotene Gruppen prüfen.
6. Bei Anhängen bestätigen, dass der Dateityp extrahierbaren Inhalt enthält. Danach einen kleinen, belegten Testfall erneut senden.

Zu viele legitime Nachrichten matchen

In Message History zuerst Regel, Kategorie und Aktion identifizieren. Danach nur eine Variable ändern: unpassende Suchorte entfernen, CCL-Auswahl korrigieren oder nach belegten Tests die Matchzahl erhöhen. Eine breite Exclude list oder direkte Umstellung auf Zustellung versteckt das Symptom, behebt aber die Erkennung nicht.

Dateityp- oder Grössenregel wirkt falsch

Bei AFT klären, ob die Regel Endungen oder True File Type verwendet; beide Methoden brauchen getrennte Regeln. Bei Size die MIME-Grösse des einzelnen Anhangs statt der Rohdatei vergleichen und den Base64-Aufschlag berücksichtigen. Erreicht die gesamte Nachricht 50 MB, liegt zusätzlich die Verarbeitungsgrenze vor.

Verschlüsselung, Umleitung oder Benachrichtigung fehlt

Prüfen, ob die Aktion für Richtung und Rule type verfügbar ist. Bei Encrypt zusätzlich Benutzerzuweisung, Secure Message policy, Lizenz und gewählte Methode kontrollieren. Reroute message funktioniert nicht im Mailflow-Modus. Bei Benachrichtigungen muss das Ziel zu einer Account-Domain gehören und eine gelöschte Zielmailbox ersetzt oder die Benachrichtigung abgeschaltet werden.

Sicherer Rollback

Bei unerwarteten Treffern stellt man nicht die gesamte Data-Control-Funktion ab. Man setzt die neue Regel auf Log, deaktiviert gezielt Filter messages with this rule oder setzt die zuvor dokumentierte Scope-, Reihenfolge- und Aktionskonfiguration zurück. Welche Variante passt, hängt vom Risiko ab: Bei möglichem Datenabfluss bleibt Quarantäne aktiv, bis der Owner entschieden hat; bei reinem Pilot-Logging kann man die Pilotregel deaktivieren.

Danach sendet man erneut einen normalen und einen positiven kontrollierten Test und bestätigt in Message History, dass wieder die vorherige Regel greift. Neu angelegte Ausnahmen werden entfernt, temporäre Benachrichtigungsziele bereinigt und Policy-Priorität sowie Continue processing auf den Ausgangswert gesetzt. Für eine Eskalation sammelt man Message-IDs, UTC-Zeiten, Richtung, Envelope-Adressen, Policy- und Regelnamen, Regelreihenfolge, Kategorie, Aktion, Kodierung sowie eine anonymisierte Testdatei. Sensible Originaldaten gehören nicht unkontrolliert in ein Support-Ticket.