Sophos EMS: Richtlinien konfigurieren und Befunde einordnen

Sophos Email Monitoring System (EMS) verwendet Email Security- und Data Control-Richtlinien, um zu zeigen, wie Sophos Email eine Nachricht bewertet hätte. Die konfigurierten Aktionen sind im EMS-Modus jedoch reine Berichtsergebnisse: Quarantine, Reject, Deliver oder eine andere gewählte Aktion verändert die tatsächliche Zustellung nicht.

Der wichtigste Konfigurationsgrundsatz lautet deshalb: Die Richtlinien sollen die heute produktiv verwendete E-Mail-Sicherheitsumgebung möglichst genau abbilden. Nur dann sind die EMS-Befunde ein sinnvoller Vergleich. Besonders bei DKIM und DMARC muss man berücksichtigen, dass eine vorgeschaltete Sicherheitslösung Nachrichten verändern kann.

Schnellweg: Unter My Products > Email Security > Policies > Email Security eine klar begrenzte Richtlinie anlegen oder bearbeiten, Benutzer, Gruppen oder Domains zuweisen und die Inbound- und Outbound-Einstellungen an die bestehende Umgebung angleichen. Innerhalb der geöffneten Richtlinie lautet der relative Pfad Email Security policy > Settings > Inbound > Authentication. Für Inhaltsregeln wählt man My Products > Email Security > Policies > Add Policy > Data Control. Danach werden gespeicherte Einstellungen und Zuweisungen kontrolliert und Befunde zunächst mit einem begrenzten Scope ausgewertet.

Wichtig: Eine in EMS konfigurierte Aktion ist kein Beleg dafür, dass die produktive Nachricht blockiert, abgelehnt, zugestellt oder quarantänisiert wurde. EMS simuliert den Sophos-Email-Verdict für die Berichterstattung.

Was diese EMS-Anleitung abgrenzt

Diese Seite ist der primäre Ablauf für die EMS-spezifische Zusammenschau: Sie zeigt, wie man bereits festgelegte Email-Security- und Data-Control-Regeln als reines Beobachtungsmodell abbildet und die daraus entstehenden simulierten Befunde gemeinsam einordnet. Sie ist bewusst kein viertes allgemeines Richtlinienhandbuch.

Scope, Priorität, Zuweisung, Klonen, Enforcement und der produktive Rollback einer Email Security Policy gehören zur Anleitung Sophos Email Security: Richtlinien erstellen und zuweisen.
Entwurf, Aktionen, Ausnahmen, Testfälle und produktiver Betrieb von Data-Control-Regeln gehören zu Sophos Email Data Control: DLP-Regeln sicher konfigurieren.
Failure-Typen, Aktionen, Reihenfolge und produktive Validierung von DMARC, SPF, DKIM und Sender Checks gehören zu Sophos Email: Absenderauthentifizierung und Smart Banners konfigurieren.

Die folgenden Schritte wiederholen deshalb nur die Felder, die für ein vergleichbares EMS-Bewertungsmodell nötig sind. Wenn eine Richtlinie neu entworfen, produktiv durchgesetzt oder grundsätzlich repariert werden soll, folgt man dem jeweils oben genannten Fachartikel und übernimmt danach dessen freigegebene Sollwerte in EMS.

Voraussetzungen, Lizenz und Rollen

Für diesen Ablauf muss EMS bereits Nachrichten aus der vorgesehenen E-Mail-Umgebung auswerten können. Zudem benötigt man Zugriff auf My Products > Email Security > Policies und eine dokumentierte Referenz der aktuell produktiven Schutzrichtlinien. Dazu gehören mindestens der betroffene Benutzer-, Gruppen- oder Domain-Scope sowie die heute verwendeten Inbound-, Outbound-, Authentifizierungs- und Inhaltsregeln.

Für das Bearbeiten dieser Richtlinien sind weder eine separate Rolle noch eine zusätzliche Lizenzstufe dokumentiert. Fehlt Policies oder lässt sich eine Einstellung nicht ändern, werden daher keine Rollen oder Lizenzen auf Verdacht angepasst. Stattdessen klärt man den vorgesehenen Zugriff mit dem zuständigen Sophos-Fusion-Administrator oder Partner.

Vor der Änderung hält man fest:

Name, Priorität, Status und Zuweisungen der bestehenden Richtlinien;
die aktuell produktiven Aktionen für dieselben Prüfungen;
betroffene interne und externe Benutzer, Gruppen oder Domains;
die gewünschten Inbound- und Outbound-Einstellungen;
einen kleinen Pilot-Scope, beispielsweise eine Testgruppe oder eine einzelne Domain;
die bisherige Konfiguration als Rückweg.

Bei externen Benutzern und Domains ist wichtig, dass Sophos für die Zuordnung die SMTP-Envelope-Adressen von Absender und Empfänger verwendet, nicht die sichtbaren From- und To-Header. Ein scheinbar passender sichtbarer Absender kann deshalb ausserhalb des erwarteten Policy-Scopes liegen.

Email-Security-Richtlinie an die bestehende Umgebung angleichen

Hier wird keine neue Schutzstrategie festgelegt. Die bereits freigegebene Richtlinie ist die Referenz; EMS bildet deren Scope und Einstellungen für den Vergleich nach. Die allgemeine Richtlinienzuweisung samt Priorität, Klonen und Enforcement bleibt im oben genannten Richtlinienartikel.

My Products > Email Security > Policies > Email Security öffnen.
Die vorhandene Email Security policy bearbeiten oder mit Add Policy eine benutzerdefinierte Richtlinie erstellen.
Einen eindeutigen policy name vergeben, beispielsweise EMS - Pilot - bestehende Schutzregeln. Der Name ist frei wählbar und sollte Scope und Zweck erkennen lassen.
Unter den internen Zuweisungen die vorgesehenen users, groups, or domains auswählen. Der Pilot-Scope sollte so klein sein, dass sich seine Nachrichten und Befunde eindeutig zuordnen lassen.
Falls die bestehende Umgebung Regeln für externe Absender oder Empfänger verwendet, im Tab External die entsprechenden Adressen oder Domains aufnehmen und bewusst ein- oder ausschliessen.
Die inbound settings und outbound settings so konfigurieren, dass sie den heute produktiv verwendeten Schutzregeln entsprechen.
Kontrollieren, dass die Richtlinie erzwungen und nicht Policy Bypassed ist, danach Save wählen.

Benutzerdefinierte Richtlinien gelten standardmässig nicht für Distribution Lists, Shared Mailboxes und Public Folders. Wenn solche Objekte zum beabsichtigten Scope gehören, muss die tenantweite Einstellung Apply custom policy to DL and shared mailbox bereits passend gesetzt sein. Diese Einstellung wird nicht nebenbei für einen EMS-Test geändert; ihre Auswirkung auf andere Richtlinien muss zuerst separat bewertet werden.

Die meisten Einstellungen der Email-Security-Richtlinie betreffen eingehende Nachrichten. Einzelne dokumentierte Ausnahmen können auch ausgehend gelten, etwa Enhanced content and file property scan, S/MIME oder ein Outbound Disclaimer. Man übernimmt deshalb nicht pauschal dieselben Werte für beide Richtungen, sondern gleicht jedes Feld mit der produktiven Referenz ab.

DMARC, SPF, DKIM und Sender Checks konfigurieren

Der vollständige Pfad lautet My Products > Email Security > Policies > Email Security > Settings > Inbound > Authentication; relativ zur bereits geöffneten Richtlinie ist es Email Security policy > Settings > Inbound > Authentication. Die Prüfungen werden immer ausgeführt; in der Richtlinie steuert man die Fehleraktion. Im EMS-Modus bleibt auch diese Aktion eine Simulation. Die allgemeine Wahl und Priorisierung der Failure-Aktionen ist Aufgabe der oben genannten Anleitung zur Absenderauthentifizierung; hier werden diese Sollwerte nur für EMS übernommen und ihre Befunde unter der EMS-spezifischen Mutationsgrenze interpretiert.

DMARC check, SPF check und DKIM check entsprechend der dokumentierten Referenz einstellen.
Mit Add Rule die benötigten Fehlertypen und die zugehörige Aktion erfassen.
Bedingungen in die beabsichtigte Reihenfolge bringen. Sophos prüft sie von oben nach unten und verwendet den ersten Treffer.
Die Richtlinie speichern.

Der dokumentierte Ausgangswert für DMARC ist DMARC check: on mit Hard failure: Conform to sender policy. Diesen Wert sollte man nicht allein deshalb ändern, weil eine strengere Aktion sicherer klingt. Für einen aussagekräftigen EMS-Vergleich muss die Auswahl zur heutigen E-Mail-Umgebung passen.

Die Resultate bedeuten:

SPF vergleicht die sendende IP-Adresse mit den autorisierten Hosts, IP-Adressen oder Netzen im SPF-Record.
DKIM validiert die digitale Signatur mit dem im DNS veröffentlichten öffentlichen Schlüssel und vergleicht den berechneten Hash.
DMARC benötigt einen gültigen DMARC-Record und einen erfolgreichen, ausgerichteten SPF- oder DKIM-Pfad. Bei SPF wird die Envelope-From-Domain mit der sichtbaren From-Domain verglichen; bei DKIM die d=-Domain der Signatur mit der sichtbaren From-Domain.
Header anomaly erkennt Nachrichten, die als Absender die eigene Domain verwenden, aber von einer externen Domain stammen.
Domain anomaly erkennt Absenderdomains ohne MX- oder A-Record.

Zu den konfigurierbaren Fehlerklassen gehören je nach Prüfung Hard failure, Soft failure, Neutral, Unsupported, Temporary failure und Permanent failure. Nicht jede Klasse gilt für jede Prüfung oder jeden Betriebsmodus. Ein Temporary failure kann sich ohne Eingriff auflösen; ein Permanent failure weist dagegen auf einen nicht korrekt interpretierbaren DNS-Record hin, den der Domain-Owner korrigieren muss.

Die Oberfläche bietet Aktionen wie Conform to sender policy, Tag subject line, Quarantine, Reject und Deliver. In EMS beschreiben sie ausschliesslich, was Sophos Email unter der abgebildeten Richtlinie getan hätte. Sie führen nicht zu dieser Zustellaktion.

Wer die DNS-Seite von DMARC sowie die legitimen Sender einer eigenen Domain verwalten möchte, findet den getrennten Ablauf unter Sophos Email DMARC Manager einrichten. Der vorliegende Artikel behandelt dagegen die Auswertung eingehender Nachrichten in EMS und dupliziert keine DNS-Einrichtung.

Data-Control-Richtlinie als Beobachtungsmodell einrichten

Data Control prüft Inhalte ein- oder ausgehender E-Mails. Auch hier sind die gewählten Aktionen in EMS nur für die Berichterstattung bestimmt. Die Regeln sollten daher die aktive E-Mail-Umgebung nachbilden und nicht als neue produktive Durchsetzung geplant werden. Welche Erkennung, Aktion, Ausnahme und Testmatrix fachlich geeignet ist, entscheidet der oben genannte Data-Control-Leitfaden; dieser Abschnitt übernimmt ausschliesslich das freigegebene Ergebnis in das EMS-Beobachtungsmodell.

My Products > Email Security > Policies > Add Policy > Data Control öffnen und Continue wählen.
Einen eindeutigen policy name eintragen.
Interne users, groups, or domains zuweisen. Bei Bedarf zusätzlich externe Benutzer oder Domains aufnehmen.
Settings öffnen. Eine neue Data-Control-Richtlinie enthält zunächst keine Regeln.
Regeln mit den benötigten rule conditions und actions erstellen. Möglich sind Sophos-Templates oder eigene Bedingungen auf Basis von Content Control Lists, Keywords und Phrasen.
Reihenfolge und Status der Regeln kontrollieren. Sophos prüft von oben nach unten und verwendet die erste passende Regel.
Richtlinie speichern und sicherstellen, dass sie nicht Policy Bypassed ist.

Eine Data-Control-Richtlinie kann bis zu 25 Regeln enthalten; für eine eigene Keyword- oder Phrasenliste sind bis zu 200 Einträge möglich, ohne Unterscheidung von Gross- und Kleinschreibung. Diese Grenzen sind kein Grund, den Pilot unnötig breit zu bauen. Für die erste Abnahme genügt eine kleine, eindeutig erkennbare Testbedingung, die der bestehenden Umgebung entspricht.

Auch bei Data Control analysiert Sophos SMTP-Envelope-Adressen. Eine Regel für externe Empfänger sollte deshalb gegen den tatsächlichen Envelope-Recipient und nicht nur gegen die sichtbare To-Zeile geplant werden.

Validierung und Befunde einordnen

Zuerst wird die Konfiguration selbst geprüft:

richtiger policy name und vorgesehener Status;
korrekte assigned users/groups/domains;
passend gesetzte Inbound- und Outbound-Einstellungen;
erwartete Reihenfolge der Authentifizierungs- beziehungsweise Data-Control-Regeln;
aktivierte DMARC check, SPF check, DKIM check, Header anomaly und Domain anomaly nur dort, wo sie zur Referenzumgebung gehören;
zu jeder Bedingung die beabsichtigte simulierte Aktion.

Danach sendet man mit dem begrenzten Pilot-Scope repräsentative Nachrichten. Für die Authentifizierung eignen sich legitime externe Absender mit bekannten SPF-, DKIM- und DMARC-Eigenschaften. Für Data Control wird eine freigegebene Testnachricht verwendet, die genau eine eindeutig zuordenbare Regel erfüllt. Echte vertrauliche, finanzielle oder personenbezogene Daten gehören nicht in den Test.

Erwartet wird, dass EMS die Nachricht gemäss der zugewiesenen Richtlinie bewertet und die konfigurierte Aktion als Befund abbildet. Die produktive Nachricht bleibt von dieser EMS-Aktion unbeeinflusst. Ist kein passender Befund erkennbar, prüft man als Nächstes Policy-Zuweisung, Envelope-Absender und -Empfänger, Regelreihenfolge und den Status der Richtlinie. Für diesen Richtlinienschritt ist kein eigener Menüpfad zu den Befunden dokumentiert. Die Prüfung beschränkt sich deshalb auf die im Tenant verfügbaren EMS-Befunde.

Ein einzelnes DKIM fail oder fehlendes DMARC alignment ist hinter einer vorgeschalteten E-Mail-Sicherheitslösung noch kein Beweis für eine gefährliche Nachricht. Für die Einordnung werden mindestens sichtbare From-Domain, Envelope-From, DKIM-d=-Domain, Ergebnis der Signaturprüfung und ein möglicher vorgelagerter Verarbeitungsschritt gemeinsam betrachtet.

Troubleshooting nach Symptom

DKIM schlägt bei legitimen Nachrichten fehl

Prüfen, ob die primäre E-Mail-Sicherheitslösung Header oder signierte Nachrichtenteile verändert hat, bevor die Journal-Kopie EMS erreichte. DKIM vergleicht den aus der empfangenen Nachricht berechneten Hash mit der entschlüsselten Signatur. Nach einer Änderung können die Werte auseinanderfallen. Der Befund wird deshalb mit einer unveränderten Referenznachricht und dem bekannten Zustellpfad verglichen, statt die Nachricht allein aufgrund des EMS-Ergebnisses als bösartig einzustufen.

DMARC Alignment fehlt trotz bekannter Domain

Envelope-From, sichtbare From-Domain und DKIM-d=-Domain getrennt prüfen. DMARC besteht, wenn SPF oder DKIM sowohl validiert als auch zur sichtbaren From-Domain ausgerichtet ist. Eine vorgeschaltete Änderung kann besonders DKIM und damit den DMARC-Pfad beeinträchtigen. Der genaue DNS- und Senderzustand lässt sich bei eigenen Domains mit dem verlinkten DMARC-Manager-Ablauf untersuchen.

Nur die falsche oder gar keine Richtlinie scheint zu greifen

Die assigned users/groups/domains, externe Ein- oder Ausschlüsse und SMTP-Envelope-Adressen kontrollieren. Danach Priorität und Status der Richtlinie prüfen. Bei Data Control zusätzlich die Reihenfolge beachten: Es gilt die erste passende Regel. Bei einer geklonten Richtlinie kontrollieren, ob Zuweisungen ergänzt und Policy Bypassed auf den erzwungenen Zustand umgestellt wurden.

Ein erwarteter Authentifizierungscheck fehlt

Die Checks werden in ihrer angezeigten Reihenfolge ausgeführt. Scheitert eine Nachricht bereits an der ersten Message-Authentication-Prüfung, werden die folgenden Authentifizierungen nicht mehr ausgeführt. Die fehlende Folgeprüfung ist dann kein Konfigurationsbeweis; zuerst wird der vorangehende Befund erklärt.

Data Control liefert unerwartete Treffer

Zuerst Pilot-Scope, Envelope-Absender und -Empfänger sowie die oberste treffende Regel prüfen. Danach Template, Content Control List, Keywords oder Phrasen mit der Testnachricht abgleichen. Bei mehreren möglichen Treffern ist die Regelreihenfolge entscheidend. Regeln werden nicht breiter gemacht, bevor der konkrete Treffer nachvollzogen ist.

Sicherer Rückweg und Ausserbetriebnahme

Ein vollständiger EMS-Deaktivierungsprozess und ein separater Löschablauf für diese Richtlinien sind nicht dokumentiert. Deshalb sollte man Richtlinien nicht auf Verdacht löschen.

Für einen sicheren Rückweg geht man so vor:

Vor der Änderung den bisherigen Status, die Zuweisungen, Regelreihenfolge, Bedingungen und Aktionen sichern.
Bei unerwarteten Befunden den Geltungsbereich nicht erweitern und die simulierte Aktion nicht verschärfen.
Die Richtlinie erneut öffnen, die dokumentierten vorherigen Werte wiederherstellen und speichern.
Mit demselben Pilotfall kontrollieren, dass die ursprüngliche Bewertung wieder erscheint.
Soll die Richtlinie dauerhaft ausser Betrieb gehen, zuerst ihre Zuweisungen und mögliche Abhängigkeiten klären. Der eigentliche Deaktivierungs- oder Löschschritt folgt dem im eigenen Tenant freigegebenen Änderungsprozess. Ohne einen dokumentierten Ablauf werden keine zusätzlichen Deaktivierungs- oder Löschschritte ausgeführt.

Da EMS die Aktionen nicht auf die Zustellung anwendet, stellt dieser Rückweg das Bewertungsmodell wieder her. Er ist kein Rückbau des Journalings und keine Änderung am produktiven Mailflow.

Betrieb, Überprüfung und Lebenszyklus

Richtlinien und Befunde werden regelmässig mit der produktiven E-Mail-Sicherheitsumgebung verglichen. Eine Überprüfung ist besonders nach Änderungen an vorgelagerten Filtern, Absenderdomains, SPF-, DKIM- oder DMARC-Konfigurationen, Benutzer- und Gruppenzuweisungen sowie Data-Control-Regeln nötig. Nach jeder Anpassung wird derselbe begrenzte Pilot erneut ausgeführt.

Für den Betrieb dokumentiert man Richtlinienverantwortliche, Geltungsbereich, Regelreihenfolge, Referenzkonfiguration und bekannte legitime Abweichungen durch vorgelagerte Nachrichtenverarbeitung. So bleibt erkennbar, ob sich ein EMS-Befund wegen einer echten Absenderänderung, einer Richtlinienabweichung oder einer Mutation auf dem Zustellweg geändert hat.

Die aktuellen Hilfeseiten für diesen Ablauf nennen keinen eigenen EOL-, Migrations- oder Abschalttermin. Solche Termine werden deshalb nicht aus älteren Ankündigungen abgeleitet. Bei Produktänderungen werden die sichtbaren Felder und das simulierte Verhalten erneut gegen die aktuelle Sophos-Hilfe geprüft, bevor Richtlinien oder Auswertungsregeln angepasst werden.