Sophos Email Security: Richtlinien erstellen und zuweisen

Eine Email Security Policy schützt ausgewählte Mailboxen vor Spam, Malware, Phishing und weiteren E-Mail-Bedrohungen. Entscheidend ist nicht nur, welche Prüfungen aktiviert sind: Der interne und externe Scope, die Reihenfolge und der Enforcement-Status bestimmen, für welche Nachrichten eine benutzerdefinierte Richtlinie tatsächlich gilt.

Schnellweg: Unter My Products > Email Security > Policies eine Email Security Policy hinzufügen, einen eindeutigen Namen vergeben, interne Benutzer, Gruppen oder Domains auswählen und optional den externen Scope eingrenzen. Danach Einstellungen und Aktionen prüfen, die Richtlinie speichern, an der richtigen Stelle einordnen und auf Policy is enforced setzen. Abschliessend kontrollierte Nachrichten an einen Empfänger im Scope und einen Vergleichsempfänger ausserhalb des Scopes senden und die beobachtbaren Resultate in Message History dokumentieren.

Vor der Änderung Scope und Rückweg festhalten

Man benötigt eine aktuelle Liste der geschützten Mailboxen und Domains sowie der bekannten geschäftlichen Ausnahmen. Vor der ersten Änderung hält man in einem Change oder Ticket fest:

Name, Zweck und Owner der neuen Richtlinie;
interne Benutzer, Gruppen und Domains, die sie erhalten sollen;
externe Adressen oder Domains, die ein- oder ausgeschlossen werden sollen;
erwartete Richtung und die beabsichtigten Aktionen;
heutige Reihenfolge, Enforcement-Status und relevante Einstellungen der betroffenen Policies;
Abnahmekriterien, Testsender und Testempfänger;
Rückweg: neue Policy auf Policy Bypassed setzen und vorherige Reihenfolge beziehungsweise Einstellungen wiederherstellen.

Unter Policies stehen drei Familien für unterschiedliche Aufgaben. Email Security behandelt Bedrohungen, Data Control kontrolliert sensible Informationen und Secure Message verschlüsselt Nachrichten. Für den hier beschriebenen Schutz vor Spam, Malware, Phishing und Absender-Manipulation wählt man Email Security; eine ähnlich benannte Policy aus einer anderen Familie ersetzt sie nicht.

⚠️ Eine Ausnahme darf niemals den Malware-Scan deaktivieren. Wenn eine legitime Nachricht falsch klassifiziert wird, grenzt man zuerst die betroffene Prüfung, den Scope und die Reihenfolge ein. Eine möglichst enge Korrektur ist sicherer als eine pauschale Ausnahme für einen Absender oder eine Domain.

Im EMS mode kann man Email Security Policies konfigurieren, ihre Aktionen werden jedoch nur für das Reporting ausgewertet und nicht auf Nachrichten angewendet. Die Richtlinien sollten trotzdem die aktuelle Mailumgebung abbilden, damit die angezeigten Verdicts aussagekräftig sind. Ein Treffer in EMS belegt daher keine Blockierung oder Quarantäne.

So wertet Sophos den Policy-Scope aus

Eine benutzerdefinierte Richtlinie kann internen Benutzern, Gruppen oder Domains zugewiesen werden. Ein Eintrag in einer dieser internen Listen genügt für den internen Teil des Scopes. Mit External kann man einzelne externe E-Mail-Adressen oder ganze Domains hinzufügen, aus einer Datei importieren und in den Scope ein- oder ausschliessen. Die Richtlinie gilt dann für Nachrichten zwischen dem internen Scope und dem definierten externen Scope, eingehend oder ausgehend, soweit die jeweilige Einstellung diese Richtung unterstützt.

Sophos wertet dafür die SMTP-Envelope-Adressen von Absender und Empfänger aus, nicht bloss die sichtbaren From- und To-Header. Das ist besonders bei Weiterleitungen, Aliasen oder abweichenden Return-Path-Adressen wichtig. Bei einem unerwarteten Match prüft man deshalb zuerst den Envelope-Sender und Envelope-Empfänger in den Nachrichtendetails beziehungsweise Roh-Headern.

Plus-Adressen wie accounts+test1234@example.com behandelt Sophos wie E-Mail-Aliase. Dieser Schutz für Plus-Adressierung wird nur bei eingehenden Nachrichten unterstützt.

Verteilerlisten und Shared Mailboxes bewusst behandeln

Benutzerdefinierte Policies gelten standardmässig nicht für Distribution Lists (DLs), Shared Mailboxes und Public Folders. Soll eine ausgewählte DL oder Shared Mailbox die benutzerdefinierte Policy erhalten, aktiviert man Apply custom policy to DL and shared mailbox. Bleibt die Option aus, greift dort nur die Base Policy, selbst wenn das Objekt in der benutzerdefinierten Richtlinie ausgewählt wurde. Public Folders bleiben ausserhalb dieser Umschaltung; man darf sie nicht stillschweigend wie eine Shared Mailbox behandeln.

Die davon abhängige Kontoeinstellung Treat a DL as a mailbox ist nur verfügbar, wenn Apply custom policy to DL and shared mailbox aktiviert ist. Ist sie ausgewählt, behandelt Sophos eine gewählte DL als einzelne Mailboxadresse: Die benutzerdefinierte Policy gilt nur für die DL-Adresse, nicht für ihre Mitglieder. Soll die DL stattdessen als Gruppe behandelt werden, deaktiviert man Treat a DL as a mailbox. DLs erscheinen weiterhin auf der Registerkarte Groups der Policy. Auf per AD Sync synchronisierte DLs hat die Einstellung keine Wirkung; diese werden immer als Gruppen behandelt.

Vor dem Aktivieren vergleicht man eine repräsentative persönliche Mailbox, eine DL und eine Shared Mailbox. So wird sichtbar, ob ein scheinbares Zuweisungsproblem in Wahrheit durch diese tenantweite Behandlung benutzerdefinierter Policies entsteht.

Email Security Policy erstellen und priorisieren

Öffne My Products > Email Security > Policies.
Klicke auf Add Policy und wähle die Familie Email Security. Um eine vorhandene Richtlinie anzupassen, öffnet man stattdessen deren Eintrag.
Vergib einen eindeutigen Namen, zum Beispiel ES-Inbound-Finance-Strict. Der Name beschreibt Richtung, Zielgruppe und Zweck; Neue Policy hilft später weder in der Reihenfolge noch bei einem Incident.
Füge unter Internal die vorgesehenen Benutzer, Gruppen oder Domains hinzu. Beim Überfahren eines internen Benutzernamens zeigt Sophos dessen E-Mail-Adresse an; damit lässt sich eine gleichnamige Person vor dem Speichern verifizieren.
Falls die Policy nur für bestimmte Kommunikationspartner gelten soll, öffne External. Füge Adressen oder Domains manuell beziehungsweise per Datei hinzu und prüfe bewusst, ob die Liste ein- oder ausgeschlossen wird.
Prüfe unter Settings die benötigten Schutzfunktionen und deren Aktionen. Dokumentiere insbesondere die gewünschte Richtung, die Aktionen für Treffer, SPF-, DKIM- und DMARC-Prüfungen sowie die Reihenfolge der Absenderprüfungen. Die meisten Einstellungen gelten nur eingehend. Ausnahmen sind unter anderem Enhanced content and file property scan, das auch ein- und ausgehend gelten kann, S/MIME mit wählbarer Richtung und der ausgehende Disclaimer.
Wenn die Prüfung New domain/sender verwendet wird, dokumentiere ihre konfigurierte Aktion und teste sie mit einer kontrollierten externen Domain oder einem Absender, die beziehungsweise der für den Tenant tatsächlich neu ist. Tenantweite Einstellungen werden separat erfasst; sie gehören nicht zu dieser empfängerbezogenen Policy-Zuweisung und dürfen nicht daraus abgeleitet werden.
Prüfe bei DLs und Shared Mailboxes die Option Apply custom policy to DL and shared mailbox und vergleiche die Auswahl mit der vorbereiteten Soll-Liste.
Stelle sicher, dass die Richtlinie gespeichert und auf Policy is enforced gesetzt ist. Ist eine Option gesperrt, stammt die globale Vorgabe vom Partner- oder Enterprise-Administrator; sie wird nicht lokal umgangen.
Ordne die Policy entsprechend dem dokumentierten Ziel ein. Enge Ausnahmen und spezielle Zielgruppen gehören vor breitere Regeln; die Base Policy bildet den Rückhalt. Nach jeder Verschiebung kontrolliert man, ob nicht eine andere Policy nun zuerst für denselben Scope greift.
Klicke auf Save und protokolliere Namen, Scope, Reihenfolge und Enforcement-Status.

Ändert man gleichzeitig Scope, Reihenfolge und viele Aktionen, ist die Ursache eines unerwarteten Resultats schwer zu erkennen. In produktiven Tenants arbeitet man deshalb mit einer kleinen Pilotgruppe, prüft die Wirkung und erweitert den Scope erst danach.

Eine Policy sicher klonen

Klonen eignet sich, wenn eine bestehende Konfiguration als geprüfter Ausgangspunkt für eine ähnliche Zielgruppe dienen soll:

Öffne My Products > Email Security > Policies und wähle die Ausgangs-Policy.
Klicke auf Clone.
Passe in Clone Policy den Namen an und klicke auf Continue.
Wenn die Base Policy geklont wurde, füge Benutzer, Gruppen oder Domains hinzu; ein Klon der Base Policy enthält zunächst keinen solchen Scope.
Klicke auf Save und vergleiche Einstellungen, Aktionen, Scope und Richtung mit dem Change.
Der Klon steht zunächst auf Policy Bypassed. Erst nach der Kontrolle schaltet man über Policy Bypassed > Policy is enforced scharf.
Ein Klon erhält standardmässig eine höhere Priorität als die Ausgangs-Policy. Prüfe und korrigiere deshalb die Reihenfolge, bevor der Pilot beginnt.

Der sichere Rückweg ist damit einfach: Bleibt das Original unverändert, setzt man den Klon bei unerwarteter Wirkung wieder auf Policy Bypassed und stellt die vorherige Reihenfolge her. Man löscht den Klon nicht, bevor Message History und das Change-Protokoll ausgewertet sind.

Wirkung mit Message History prüfen

Für die Abnahme verwendet man einen dedizierten Empfänger innerhalb des neuen Policy-Scopes und einen vergleichbaren Kontroll-Empfänger ausserhalb. An beide sendet man dieselben kontrollierten Nachrichten, ohne während des Tests eine andere Policy oder tenantweite Einstellung zu ändern. Dazu gehören mindestens:

eine normale erwartbar zulässige Nachricht;
eine autorisierte, harmlose Testnachricht, die gezielt eine konfigurierte Bedrohungskategorie oder Aktion auslöst;
eine Nachricht mit einem bekannten SPF-, DKIM- oder DMARC-Testergebnis;
bei externem Scope je einen passenden und einen nicht passenden Kommunikationspartner;
bei Bedarf je eine Nachricht an eine persönliche Mailbox und eine Shared Mailbox;
wenn eine DL zum Policy-Scope gehört, getrennte Nachrichten an die DL-Adresse und an mindestens einen Mitgliedsempfänger, damit der beabsichtigte Mailbox- oder Gruppen-Scope nachgewiesen wird.

In Message History sucht man nach Zeitpunkt, Envelope-Sender und Envelope-Empfänger. Für jede Nachricht an den Empfänger im Scope und den Kontroll-Empfänger dokumentiert man Message-ID, Zeitstempel, Envelope-Adressen, Kategorie beziehungsweise Authentifizierungsergebnis und Aktion. Bei EMS erwartet man nur das berichtete Resultat; bei einer erzwungenen Policy hält man zusätzlich die ausgeführte Aktion fest.

Kategorie, Authentifizierungsergebnis und Aktion zeigen, wie Sophos die Nachricht verarbeitet hat; sie benennen oder beweisen nicht, welche Policy wirksam war. Die Zuweisung wird nur abgenommen, wenn dokumentierter Scope, Reihenfolge und Enforcement-Status zusammen mit dem empfängerbezogenen Vergleich und dessen festgehaltenen beobachtbaren Resultaten dem Testplan entsprechen. Eine einzelne Zustellung oder Quarantäne genügt nicht als Nachweis.

Fehler systematisch eingrenzen

Die neue Policy greift nicht

Prüfe nacheinander Policy is enforced, internen Scope, externen Include-/Exclude-Scope und Reihenfolge. Bei einer DL oder Shared Mailbox kontrolliert man zusätzlich Apply custom policy to DL and shared mailbox. Bei einem Base-Policy-Klon fehlt möglicherweise die Zuweisung vollständig. In EMS sind nicht ausgeführte Aktionen erwartetes Verhalten.

Die falsche Policy oder Aktion greift

Vergleiche die Scopes überlappender Policies und deren Reihenfolge. Danach prüft man in den Details die SMTP-Envelope-Adressen statt nur From und To. Erst wenn das Policy-Match stimmt, untersucht man die konfigurierte Aktion und die Abfolge von SPF-, DKIM-, DMARC- und weiteren Sender-Checks.

Eine legitime Nachricht wird blockiert oder quarantänisiert

Halte Message-ID, Zeit, Envelope-Adressen, Kategorie, Aktion und Sender-Check-Details fest. Analysiere die Roh-Header auf Weiterleitung, abweichenden Envelope-Sender und die tatsächlichen Authentifizierungsergebnisse. Korrigiere zuerst Reihenfolge, Scope oder die konkret falsch positive Prüfung. Deaktiviere nicht den Malware-Scan und erstelle keine breite Allow-Ausnahme, nur um den Einzelfall schnell zuzustellen.

Neue Absender verhalten sich unerwartet

Prüfe die unter New domain/sender konfigurierte Aktion und ob die Test-Domain beziehungsweise der Test-Absender für den Tenant tatsächlich neu war. Wiederhole den empfängerbezogenen Test mit einer kontrollierten neuen externen Domain oder einem Absender und dokumentiere die beobachtbaren Resultate in Message History. Tenantweite Einstellungen werden separat geprüft, statt ihre Wirkung der zugewiesenen Policy zuzuschreiben.

Wenn die Ursache nach diesen Schritten offen bleibt, lässt man die neue Policy auf Policy Bypassed beziehungsweise stellt den vorherigen Enforcement-Status und die Reihenfolge wieder her. Für die Eskalation sammelt man Policy-Namen, Scope, Reihenfolge, Message-IDs, Zeitstempel, Roh-Header und Screenshots der Sender-Check-Details. So kann Sophos oder der betreuende Partner den Match- und Prüfpfad nachvollziehen, ohne dass der Tenant mit riskanten Ausnahmen weiter verändert wird.