Sophos XDR Cases und Detection Rules betreiben

Sophos XDR sammelt Detections und betroffene Entitäten zu untersuchbaren Fällen. Ein Case ist kein automatisch gelöster Incident, sondern der gemeinsame Arbeitsbereich für Evidenz, Verantwortlichkeit und Response.

Die bisherigen Abläufe dieses Artikels beschreiben den Case- und Detection-Rule-Betrieb im Threat Analysis Center, der weiterhin verfügbaren Classic view von Security Operations. Der gesonderte Abschnitt zu Security Operations erklärt die aktuellen MDR-Ownership- und Statusgrenzen. Vor einer Änderung prüfen, welche Ansicht der Tenant verwendet. Security Operations bietet ebenfalls Cases, Detections und Detectors; das ist kein Beleg, dass dort die gleichen Statuswerte, Rollen, Löschfristen oder Suppression-Regeln gelten. Insbesondere wird Detectors nicht mit den unten beschriebenen Classic-Detection Rules gleichgesetzt.

In Classic benötigen Cases EDR, XDR oder MDR. Sophos erzeugt bei einer High-Risk-Detection automatisch einen Case, sofern sie nicht bereits am selben Tag in einem passenden Case liegt. Spätere Detections desselben Typs können ergänzt werden.

Ein Sophos-managed Case auf Basis von MDR-Detections wird vom MDR-Team untersucht. Ein Self-managed Case aus XDR-Detections bleibt in der Verantwortung des Kunden und wird einem Administrator zugewiesen. Sophos erstellt ihn, untersucht ihn aber nicht automatisch.

Diese Eigentumsgrenze gilt auch für NDR-Signale und autorisierte NDR-Testtreffer: Die Quelle NDR überträgt einen Self-managed XDR-Case nicht automatisch an Sophos MDR. Der Kundenadministrator bleibt Owner, bis der Case gemäss dem eigenen Prozess abgeschlossen ist. Nur ein als Sophos-managed ausgewiesener Case auf Basis von MDR-Detections liegt beim MDR-Team. Wie ein Testtreffer eindeutig korreliert und aufgeräumt wird, beschreibt das Runbook zur NDR-Test-Detection.

Detection, Alert und Case in Classic

Mehrere Detections können zu derselben Angriffskette gehören. Umgekehrt kann eine einzelne auffällige Detection bereits eine Untersuchung rechtfertigen.

Bei Self-managed Cases bilden New, Investigating, On Hold und Resolved den vollständigen Statusablauf: neu angelegt, aktiv untersucht, vorübergehend pausiert oder abgeschlossen. Sophos-managed Cases verwenden dagegen Investigating, Action required und Resolved. Action required bedeutet, dass der Kunde handeln muss; Sophos benachrichtigt dafür die hinterlegten Kontakte.

Case in Classic bearbeiten

Der Einstieg liegt unter Threat Analysis Center > Cases. Ein automatisch erzeugter Self-managed Case wird über seine Case ID geöffnet. Auf Overview setzt man über das Menü neben dem Case-Namen den Schweregrad. Danach ändert man den Status von New auf Investigating und wählt unter Owner den zuständigen Administrator. Fehlt er in der Liste, lässt er sich dort über Add user anlegen. Der Owner kann auch später zugewiesen werden.

Ein manueller Self-managed Case entsteht auf zwei offiziell dokumentierten Wegen:

• Unter Threat Analysis Center > Cases > Create case > Self-managed case Name und Beschreibung eingeben, Severity, Status New und optional Assignee wählen und mit Create speichern. Anschliessend unter Threat Analysis Center > Detections die Treffer markieren und über Actions > Add to Case hinzufügen.
• Oder unter Threat Analysis Center > Detections zuerst die Treffer markieren und Actions > Create Case wählen. Weitere Detections werden später über Actions > Add to Case ergänzt.

Manuell erstellte Cases können nur Sophos-XDR-Detections enthalten, nicht MDR- oder Managed-Risk-Detections. Im Case-Namen empfiehlt Sophos ausschliesslich alphanumerische Zeichen, Leerzeichen und einfache Satzzeichen, weil APIs Sonderzeichen als Syntax interpretieren können.

Für die eigentliche Untersuchung gilt:

1. Zusammenfassung, Schweregrad und Zeitlinie lesen.
2. Betroffene Geräte, Benutzer, Prozesse, IPs und Dateien prüfen.
3. MITRE-ATT&CK-Techniken und Detection-Quelle einordnen.
4. Threat Graph, Live Discover und verfügbare Enrichments verwenden.
5. Eindämmung wie Isolation oder Live Response dokumentieren.
6. Ursache, Umfang und Abschlussentscheidung festhalten.

Bei einem Self-managed Case gehören die Untersuchungsnotizen auf den Tab Notebook. Damit bleibt der Evidenz- und Entscheidungsverlauf direkt am Case erhalten.

AI-generierte Zusammenfassungen können die Triage beschleunigen, werden aber gegen Rohdaten und Zeitlinie geprüft.

Detection Rules

Die folgenden Regeln gelten für die Classic-Ansicht unter Threat Analysis Center > Detection rules, nicht pauschal für Security Operations. Classic-Detection-Rules können derzeit ausschliesslich unerwünschte Detections unterdrücken und benötigen einen Super Admin. Eine Regel verhindert, dass eine passende Detection in der Detection-Liste erscheint und einen Self-managed-XDR-Case erzeugt. MDR-Cases lassen sich damit nicht unterdrücken.

Regeln werden aus einer vorhandenen Detection erstellt: Threat Analysis Center > Detections, Drei-Punkte-Menü neben dem Detection-Namen, Add detection rule. Unter Rule Details werden Name und Beschreibung erfasst; die Regel ist standardmässig aktiviert. Unter Actions steht derzeit nur Suppress zur Verfügung. Unter Conditions wählt man die Merkmale des vorhandenen Treffers, die die Regel auslösen sollen, und speichert mit Save. Pro Tenant sind höchstens 25 Detection Rules möglich.

Bevor die standardmässig aktivierte Regel gespeichert wird, werden Regelname, Zweck, Datenquelle, erwartete Häufigkeit, Owner und Review-Termin dokumentiert. Bedingungen sollten nur den bestätigten legitimen Auslöser erfassen, nicht bloss Schweregrad oder ein weit gefasstes Prozessmerkmal.

Eine neue Regel kann bis zu 20 Minuten benötigen und wirkt nur auf Detections, die nach ihrer Erstellung entstehen. Bedingungen sind case-sensitive: Windows und windows können unterschiedlich behandelt werden.

Bestehende Regeln verwaltet man unter Threat Analysis Center > Detection rules. Eine Regel kann aktiviert, deaktiviert, dupliziert oder gelöscht, aber nicht direkt bearbeitet werden. Für eine Änderung wird sie über das Drei-Punkte-Menü dupliziert und angepasst; nach kontrollierter Ablösung wird das Original deaktiviert oder entfernt.

Suppression kontrollieren

Suppression reduziert bekannte, erwartete Treffer. Sie ist keine Bereinigung und darf keine echte Aktivität unsichtbar machen. Jede Unterdrückung braucht:

• genaue Bedingung statt breiter Muster,
• dokumentierten legitimen Auslöser,
• Owner und Review-Datum,
• Prüfung der bereits unterdrückten Detections.

Eine ruhige Konsole ist kein Qualitätsmerkmal, wenn Regeln zu breit unterdrückt werden.

Zur Kontrolle blendet man unter Threat Analysis Center > Detections > Show filters im Bereich Detection Visibility die Option Hide Suppressed Detections aus und klickt Apply. So lässt sich prüfen, was eine Regel tatsächlich erfasst. Da Regeln nicht rückwirkend gelten, ist diese Ansicht zugleich die bessere Grundlage für den nächsten Review als eine blosse Abnahme der sichtbaren Trefferzahl.

Security Operations: Cases und MDR-Verantwortung

Dieser Abschnitt gilt für Security Operations, nicht für die vorstehenden Classic-Status und -Regeln. Unter Security Operations > Cases öffnet ein Klick auf den Case-Namen zunächst die Zusammenfassung. Über das New Tab-Symbol gelangt man auf die vollständige Detailseite. Dort stehen Overview, Evidence, Response, History und Enrichment zur Verfügung. Kommentare lassen sich in der Zusammenfassung lesen, aber nur auf der vollständigen Detailseite hinzufügen.

Managed By vor der Bestätigung entscheiden

Bei aktuellen MDR-Cases legt Managed By fest, wer den Case führt: Self bedeutet Kundenverantwortung; Sophos MDR bedeutet Verwaltung durch das MDR-Team. Assignee bezeichnet dagegen den Benutzer oder die Gruppe für die nächste Aktion. Ein Assignee-Wechsel überträgt die Case-Verantwortung nicht.

Auf der vollständigen Detailseite unter Manage Case > Managed By die angebotene Zuständigkeit auswählen und erst nach der obigen Prüfung bestätigen. Danach den angezeigten Wert kontrollieren. Self ist nur für die MDR-Case-Typen Investigation und Other auswählbar; Threat Hunt, Health Check und Incident sind Sophos-managed. Ein Incident wird nicht vom Kunden erstellt. Bei manueller Erstellung wird Managed By bereits beim Anlegen festgelegt. Bei automatisch aus Sophos-Regeln erzeugten Cases muss es vor Nutzung der Manage Case-Steuerung gesetzt werden. Bei Cases aus Kundenregeln ist es automatisch Self.

Ein Self-managed Case wird vom eigenen Team untersucht; verfügbare Änderungen, Response-Aktionen sowie Split/Merge hängen zusätzlich von Case-Typ und Berechtigungen ab. Bei Sophos-managed Cases kann man Details lesen, kommentieren, an Sophos zuweisen und bei verfügbarer Abschlussaktion schliessen. Das ist keine Berechtigung, Status beliebig zu ändern, Key Findings zu bearbeiten, zusätzliche Events oder Detections als Evidenz hinzuzufügen oder den Case zu teilen beziehungsweise zusammenzuführen.

Aktuelle MDR-Status und Kundenaktionen

Aktuelle MDR-Cases verwenden je nach Typ New, In Progress, Customer Action Required, Awaiting Sophos Assignment und Closed. Diese Werte werden weder mit den Classic-Status noch mit den allgemeinen XDR-Status Open, Active, Awaiting Action, Suspended und Closed gleichgesetzt. Awaiting Sophos Assignment bedeutet, dass die interne Zuweisung beim MDR-Team aussteht; Customer Action Required verlangt dagegen eine Aktion der Organisation.

Setzt das MDR-Team einen Sophos-managed Case auf Customer Action Required, beginnt der Inaktivitätszähler. Ohne Kundenaktion folgt alle 24 Stunden eine E-Mail-Erinnerung; nach fünf Tagen Inaktivität wird der Case automatisch geschlossen. Ein Kommentar, eine Response-Aktion, ein Assignee-Wechsel oder ein neuer Link beziehungsweise Anhang setzt den Zähler zurück. Das ersetzt nicht die angeforderte fachliche Arbeit: Eine Rückfrage wird mit dem MDR-Team geklärt, statt den Zähler nur durch formale Änderungen am Laufen zu halten. Response-Aktionen werden niemals allein zum Zurücksetzen des Zählers ausgeführt.

Auf der vollständigen Detailseite öffnet das Kommentar-Symbol rechts Comments. Im Feld Comment die benötigten Angaben erfassen und mit Save speichern. @sophos benachrichtigt das MDR-Team. Nach dem Speichern prüfen, ob der Kommentar am richtigen Case steht. Die MDR-Kontakte und Reaktionsbefugnisse werden vor einem Vorfall eingerichtet, nicht erst bei der ersten verpassten Rückfrage.

Das Schliessen setzt auch die zugehörigen Detections auf aufgelöst und kennzeichnet sie entsprechend dem gewählten Verdict. Für MDR stehen True Positive – Benign, True Positive – Malicious, Inconclusive und False Positive zur Verfügung; bei Inconclusive lautet das Detection-Label Not Actionable. Ein geschlossener Case ist kein technischer Bereinigungsnachweis. Vor dem Schliessen werden Untersuchungsergebnis und ausstehende Kundenaufgaben geprüft.

Innerhalb von 30 Tagen nach dem Schliessen lässt sich ein Sophos-managed MDR-Case über einen Kommentar mit @sophos wieder aufgreifen; bei einem customer-managed Case wird der Status von Closed geändert. Nach diesen 30 Tagen ist ein neuer Case nötig. Diese Wiedereröffnungsgrenze ist keine Aussage zur Löschung oder Aufbewahrung der aktuellen MDR-Cases; die oben beziehungsweise unten genannten Classic-Fristen bleiben auf Classic beschränkt.

Rules statt Classic-Suppress-only

Unter Security Operations > Rules gibt es zwei getrennte Arten von Customization Rules: Custom detection rules erzeugen aus normalisierten Ereignissen anhand einer erweiterten Suchabfrage neue Detections. Detection suppression rules lösen passende Detections bei der Erstellung als unterdrückt auf, sodass sie standardmässig nicht in der Detection-Liste erscheinen. Detectors ist nicht derselbe Verwaltungsbereich wie diese Regeln.

Automatisch aus Kundenregeln entstehende Cases sind customer-managed und lösen keine automatische MDR-Untersuchung aus. Die Classic-Grenzen von 25 Regeln, Super-Admin-Pflicht, 20 Minuten Wartezeit sowie Duplizieren statt Bearbeiten werden nicht auf diese neue Oberfläche übertragen. Dieser Abschnitt beschreibt die Einordnung, nicht eine vollständige Custom-Rule-Erstellung. Vor einer Suppression bleibt die legitime Ursache zu bestätigen und der Verlust an Sichtbarkeit zu bewerten.

Abschluss und Lessons Learned in Classic

Ein Case wird geschlossen, wenn Umfang, Ursache, Eindämmung, Bereinigung und Wiederherstellung dokumentiert sind. Anschliessend werden Detection-Regeln, Policies, Ausnahmen und Runbooks angepasst, wenn die Untersuchung eine Lücke gezeigt hat.

Ein Self-managed Case wird mit dem Status Resolved geschlossen. Er bleibt danach 30 Tage in der Liste und wird anschliessend von Sophos gelöscht. Partner Super Admins und Enterprise Super Admins können Cases weder schliessen noch entfernen; diese Rollengrenze wird vor der Übergabe des Owners berücksichtigt.

Die zugrunde liegende Telemetrie und Abfragearbeit erklärt Sophos XDR Data Collection und Live Discover.

Häufige Fragen

Den vollständigen aktuellen Ablauf unter Security Operations > Rules erklärt Custom Detection und Suppression Rules betreiben. Dort werden Streaming-Bedingungen, Circuit Breaker, Vorschaugrenzen und Rückbau getrennt von den hier erhaltenen Classic-Regeln behandelt.