Sophos XDR Custom Detection und Suppression Rules betreiben

Unter Security Operations > Rules lassen sich eigene Detection-Regeln und Suppression Rules betreiben. Detection-Regeln erzeugen aus normalisierten Ereignissen neue Detections; Suppression-Regeln kennzeichnen passende Detections früh als unterdrückt. Beides verändert den laufenden Untersuchungsprozess und benötigt eine genehmigte, eng begrenzte Bedingung sowie einen Verantwortlichen.

Die Cases- und Classic-Regelanleitung erklärt die weiterhin abweichende Classic-Ansicht. Deren Super-Admin-, Mengen- oder 20-Minuten-Angaben werden nicht auf Security Operations übertragen.

Vor einer eigenen Regel

Zuerst werden Zweck, Datenquelle, Schema, erwartete Treffer und bewusst ausgeschlossene Fälle festgelegt. Unter Data Lake Search wird mit passenden historischen Ereignissen geprüft, ob die Bedingung fachlich sinnvoll ist. Ein genehmigter Test verwendet ein dediziertes Konto oder andere freigegebene Testdaten; echte Schadaktivität wird nicht erzeugt.

Ein Treffer in einer historischen Suche beweist noch nicht die gleiche Wirkung in einer laufenden Regel. Such- und Regelengine unterscheiden sich; teils entstehen angereicherte Felder erst später. Deshalb gehören ein erwarteter Treffer und ein erwarteter Nichttreffer zur Abnahme. Vor einer Änderung werden Query, Name, Beschreibung, Severity, Aktivierungszustand und bisherige Treffer dokumentiert.

Custom Detection Rule erstellen

Für eine Detection-Regel erstellt man zunächst in Security Operations > Data Lake Search eine passende Advanced-Search-Query. Sie soll normalisierte Events eines geeigneten Schemas treffen. Anschliessend:

1. Den geprüften Query-Text kopieren und Security Operations > Rules öffnen.
2. Oberhalb der Custom Rules-Tabelle Create Rule wählen.
3. Unter Rule Criteria den Query-Text einsetzen.
4. Einen eindeutigen Name, passende Mitre Attack Categories und eine verständliche Description erfassen.
5. Die fachlich begründete Severity auswählen und mit Create Rule erstellen.

Eine neue Custom Rule ist nach der Erstellung eingeschaltet. Die Freigabe und der Verantwortliche müssen deshalb vorher stehen. Das ist ein anderer Default als bei einem neu angelegten Custom Parser. Keine unbeschränkte Suchbedingung zum Ausprobieren produktiv aktivieren.

Streaming ist keine gespeicherte Suche

Custom Rules arbeiten auf Streaming-Daten. Primitive Felder erhalten dort nicht automatisch die Defaultwerte, die später im Data Lake vorliegen können. NULL-Bedingungen müssen deshalb tatsächlich fehlende Werte berücksichtigen. Glob-Muster werden nicht unterstützt; Regex-Konstrukte wie Backreferences, rekursive Muster, Look-around-artige beliebige Zero-Width-Assertions und eingebetteter Code sind ebenfalls eingeschränkt. Ein funktionierender Search-Ausdruck wird nicht unverändert als garantiert funktionierende Regel verkauft.

Logische Felder wie @user können innerhalb des ausgewählten Schemas auf dessen Felder expandieren. Eine Regel matcht jedoch nur ein Schema. Bestimmte erst später ergänzte Felder sind nicht verfügbar: beispielsweise hostname, Geo-/Blacklist-Anreicherungen für auth/netflow/dns_query und WHOIS beim DNS-Schema. Die konkreten benötigten Felder werden im aktuellen Regelkontext geprüft, nicht durch ähnlich benannte Search-Felder ersetzt.

Circuit Breaker und Kundenverantwortung

Custom Rules dürfen höchstens 5'000 Detections je Stunde oder 100'000 innerhalb 24 Stunden erzeugen. Wird die Grenze überschritten, schaltet der Circuit Breaker die Regel aus und Sophos informiert den Regelautor per E-Mail. Danach wird der Scope enger gefasst; die Regel nicht unverändert wieder einschalten. Ein verschwundener Alarmstrom kann deshalb eine deaktivierte Regel bedeuten und ist kein Beweis behobener Risiken.

Automatisch aus Kundenregeln entstehende Cases sind customer-managed und lösen keine automatische MDR-Untersuchung aus. Zusätzlich beschreiben die Schemas Antivirus, Email, NIDS und Thirdparty die Markierung is_custom_alert=true: Solche Custom Alerts gehen zur Bearbeitung an den Tenant statt in die MDR-Servicequeue; ihre Severity wird dadurch nicht geändert. Daraus folgt kein pauschaler MDR-Ausschluss jedes Datensatzes eines Custom Parsers. Parser erstellen und validieren erklärt die vorgelagerte Normalisierung.

Suppression bewusst eng halten

Suppression ist für bestätigte, legitime Wiederholungen gedacht, nicht zum Verbergen ungeklärter Aktivität. Tenant-Regeln wirken nur im eigenen Tenant; Global-Regeln sind von Sophos verwaltet und schreibgeschützt. Bei Fragen zu einer globalen Regel werden deren Details dokumentiert und über den normalen Supportweg geklärt.

Eine unterdrückte Detection wird früh auf den entsprechenden Status gesetzt, bevor sie nachgelagerte automatisierte Response auslösen kann. Dadurch können beispielsweise Playbooks oder Host-Isolation ausbleiben. Vor der Freigabe muss deshalb feststehen, welche legitime Aktivität getroffen wird und welche Sicherheitsreaktion dadurch bewusst entfällt.

Suppression über Query erstellen

1. In Data Lake Search die Bedingung an vorhandenen Detections prüfen.
2. Unter Security Operations > Rules > Suppression Rules Create Rule wählen.
3. Die Bedingung in Rule Criteria eintragen.
4. See potential matches with current data als Plausibilitätsvorschau nutzen.
5. Name, Beschreibung und den vorgesehenen Resolution-Status setzen und mit Create Rule erstellen.

Neue Suppression-Regeln sind ebenfalls standardmässig eingeschaltet. Scope, Genehmigung und Rückweg müssen deshalb vor Create Rule feststehen.

Alternativ öffnet man eine konkrete Detection und Actions > Create Suppression Rule. Vorgefüllte Entities werden bewusst ausgewählt; mehrere Bedingungen werden mit AND kombiniert. Beim manuellen Eintragen von Regex-Sonderzeichen müssen diese passend escaped werden. Keine universelle Suppression aus einem einzigen erwarteten Treffer ableiten.

Warum Vorschau und laufende Regel abweichen können

Die Vorschau verwendet Advanced Search auf fertigen, angereicherten Detections. Suppression läuft dagegen während ihrer Entstehung. Felder wie enrichment_details, status und case sind nicht verfügbar; für Drittanbieterwerte ist das thirdparty-Eventschema statt third_party_details vorgesehen. Alle Kriterien müssen im Suppression-Zeitpunkt gemeinsam zutreffen. Ein fertiger Datensatz kann Bedingungen zusammenführen, die früher nur getrennt wahr waren.

Deshalb ist See potential matches keine Wirkungsgarantie. Nach Erstellen, Bearbeiten, Aktivieren oder Deaktivieren einer Suppression-Regel wartet man mindestens zehn Minuten, bevor das Ergebnis beurteilt wird. Kurz nach dem Change erzeugte Detections sind kein verlässlicher Test des neuen Zustands.

IPv4-CIDR ist in Suppression möglich, obwohl Detection Search selbst keine CIDR-Suche unterstützt. Die Query wird zunächst ohne Bereich geprüft und erst danach für die Regel angepasst. IPv6-Adressen können normalisiert verglichen werden; IPv6-CIDR und IPv4-mapped IPv6 sind für Suppression derzeit nicht unterstützt. Keine Firewall-Netzbereichssyntax ungeprüft übernehmen.

Wirkung prüfen, dokumentieren und zurücknehmen

Ein Klick auf den Regelnamen zeigt Kriterien und Details. Falls in den letzten sieben Tagen Treffer vorliegen, erscheinen Anzahl, letzter Treffer und Verlauf. Bei Suppression steht im History-Tab zusätzlich die Änderungshistorie. Ein fehlender Verlauf kann auch bedeuten, dass das passende Ereignis nicht aufgetreten ist.

Detections aus Custom Rules werden über Custom Detections in der Detection-Liste einbezogen. Unterdrückte, bereits triagierte Detections werden mit Triaged Detections sichtbar; aus den Regeldetails kann eine passende Suche geöffnet werden. Die Kontrolle umfasst erwartete Treffer, erwartete Nichttreffer, Schema/Quelle und ausgebliebene beziehungsweise gewünschte Response.

Der Schalter Enabled schaltet eine Regel ein oder aus. Archive schaltet sie ab und entfernt sie aus der Standardliste. Über Showing Archived Rules lässt sich eine archivierte Regel öffnen; Restore bringt sie deaktiviert zurück. Eine wiederhergestellte Regel wird nicht ohne erneute Abnahme aktiviert. Bei Suppression bleibt die dokumentierte Wirksamkeitsverzögerung auch beim Abschalten zu berücksichtigen.

Scheitert die Abnahme, wird nur die eigene betroffene Regel ausgeschaltet und der vorher dokumentierte Zustand kontrolliert. Bereits entstandene Cases, Exporte oder unterdrückte Detections verschwinden dadurch nicht automatisch. Suppressed-Detections können bei Bedarf in Cases aufgenommen und ihre Kennzeichnung geändert werden. Keine globale Schutzfunktion oder fremde Regel abschalten, um den eigenen Test passend zu machen.

Zur Betriebsübergabe gehören Quelle/Schema, Kriterien und Version, Autor, Genehmigung, Treffer-/Nichttreffernachweise, Severity/Resolution, Aktivierungszustand, Monitoring des Circuit Breakers und ein Review-Termin. Die Integrationsabnahme bleibt Voraussetzung: Eine schweigende Regel heilt keine fehlende Datenquelle.