Sophos NDR-Test-Detection sicher erzeugen und prüfen

Mit diesem kontrollierten Test lässt sich der Weg vom gespiegelten Netzwerkverkehr bis zu Threat Analysis Center > Detections prüfen. Der Test simuliert einen Download von einem Server mit auffälliger Domain und auffälligen Zertifikatsmerkmalen; er ist laut Sophos nicht bösartig. Trotzdem erzeugt er absichtlich eine High-Risk-Detection. Informiere deshalb vor dem Test das zuständige SOC beziehungsweise MDR-Team und führe ihn nur in einem freigegebenen Testfenster aus.

Dieses Runbook verwendet ausschliesslich Appliance Manager; dafür ist kein Client-Download erforderlich. Ein erfolgreicher Lauf liefert die Detection NDR-DET-TEST-IDS-SCORE. Das bestätigt den getesteten Erfassungs- und Detection-Pfad, aber weder die vollständige NDR-Abdeckung noch einen echten Security Incident.

Freigabe und Voraussetzungen

Halte vor der technischen Änderung in einem Change oder Test-Ticket fest:

verantwortliche Person, freigegebenes Quellgerät beziehungsweise Appliance und betroffener NDR-Sensor;
Start, geplantes Ende und Zeitzone des Testfensters;
erwarteter Detection-Name NDR-DET-TEST-IDS-SCORE und erwartete High-Risk-Einstufung;
zuständiger SOC-/MDR-Kontakt und die Vereinbarung, wie der bekannte Testtreffer dokumentiert wird;
Firewall-Regel, Regelverantwortlicher und konkreter Rückbauzeitpunkt.

Das SOC- oder MDR-Team muss den Start bestätigen. Eine blosse Kalendereinladung genügt nicht: Der Test darf keine unnötige Eskalation auslösen und darf gleichzeitig keine allgemeinen NDR-Regeln, Benachrichtigungen oder MDR-Überwachung ausser Kraft setzen. Markiere ausschliesslich den zeitlich und technisch zugeordneten Testtreffer als erwartet.

Zusätzlich müssen folgende Voraussetzungen erfüllt sein:

Die verwendete Appliance ist in Sophos Fusion konfiguriert und Appliance Manager ist erreichbar. Der Zugriff auf Appliance Manager erfolgt von einem Gerät im selben Netzwerk wie Sophos NDR.
Der zu prüfende Verkehr ist im aktuellen Port-Mirroring-Setup enthalten. Wähle also keine beliebige Quelle, sondern genau den freigegebenen Pfad, dessen Sichtbarkeit der Test belegen soll.
Das Konto zadmin und das zugehörige Kennwort für Appliance Manager sind verfügbar.
Für Threat Analysis Center > Detections ist im Tenant eine EDR-, XDR- oder MDR-Berechtigung bestätigt. Eine NDR-Berechtigung allein ist für diese Ansicht nicht als ausreichend dokumentiert.
Die prüfende Person besitzt eine Sophos-Fusion-Rolle, die Detections anzeigen darf. Welche vordefinierte oder benutzerdefinierte Rolle passt, hängt von Lizenz und Rollenkonfiguration ab; dieses Runbook setzt keine bestimmte Mindestrolle voraus.

Netzwerkfreigabe nur für die Appliance-Manager-Methode

Gib auf der Firewall nur für das Testfenster eine ausgehende Regel von der ausgewählten NDR-Appliance zum festen FQDN plrqkxqwvmtkm.xyz und zur dokumentierten IP 13.56.99.184 über TCP 2222 frei. Keine ganze Benutzerzone, kein Any-Ziel und keinen breiten Portbereich verwenden.

Diese feste Kombination gilt für den hier beschriebenen Appliance-Manager-Test. Öffne nicht zusätzlich regionsspezifische Ziele einer anderen Testmethode. Eine solche Methode braucht einen separat genehmigten Scope und ausschliesslich ihr aktuell dokumentiertes Ziel; beide Zielsets dürfen nur geöffnet werden, wenn beide Methoden getrennt genehmigt sind. Die Ziel-IP und Domain gehören zum offiziellen Sophos-Testdienst, sind aber trotzdem als temporäre Ausnahme zu behandeln. Falls die Firewall FQDN und IP nicht in derselben Regel abbildet, verwende getrennte, gleich eng begrenzte Regeln oder Objekte. Prüfe vor dem Lauf, dass die tatsächlich aufgelöste und konfigurierte Zieladresse vom genehmigten Scope erfasst wird. Entferne die Ausnahme nach dem Test auch dann, wenn keine Detection erscheint.

Test über Appliance Manager ausführen

Öffne in Sophos Fusion Threat Analysis Center > Integrations > Configured.
Wechsle zu Integration Appliances.
Suche die freigegebene Appliance, öffne in der rechten Spalte das Drei-Punkte-Menü und wähle Open Appliance Manager.
Bestätige den Dialog mit Open.
Melde dich mit dem Benutzernamen zadmin und dem Kennwort der Appliance an.
Wähle Generate Detections.
Klicke auf der Seite Generate NDR Detections auf Generate Detections.
Bestätige die Meldung, dass eine Detection erzeugt wird, mit OK. Notiere die genaue Startzeit und warte zehn Minuten, bevor du den Lauf als fehlgeschlagen bewertest.

Starte während dieser Wartezeit keinen zweiten Lauf. Sonst lassen sich Treffer, Netzwerkfluss und Change-Fenster schlechter eindeutig zuordnen.

Detection eindeutig validieren

Öffne nach der Wartezeit in Sophos Fusion Threat Analysis Center > Detections. Stelle den Zeitraum so ein, dass die notierte Startzeit enthalten ist, und suche nach NDR-DET-TEST-IDS-SCORE.

Prüfe nicht nur den Namen. Ein passender Testtreffer erfüllt diese Kriterien:

Er ist neu und zeitlich dem freigegebenen Lauf zuzuordnen.
Die Detection ist als High Risk eingestuft.
Description zeigt die erwartete Quell- und Zielkommunikation über TCP/TLS auf Port 2222.
IDS ist als Hauptbeitrag zur Detection ausgewiesen. In diesem Kontext bezieht sich IDS auf die Liste blockierter Zertifikate.
Unter Raw Data enthält flow_risk die Testmerkmale: bekanntes Protokoll auf einem nicht standardmässigen Port, selbstsigniertes Zertifikat, ungewöhnliche ALPN-Aushandlung, blocklistiertes Zertifikat, hohe Wahrscheinlichkeit einer algorithmisch erzeugten Domain und Hinweise auf die Familie Friendly Chameleon.

Dokumentiere Detection-Zeit, Detection-Link oder ID, beobachtete Quell- und Ziel-IP, Sensor beziehungsweise Appliance sowie das Prüfergebnis im Ticket. Sensible Rohdaten gehören nur in das dafür freigegebene Ticketsystem.

Detection ist nicht gleich Incident

NDR-DET-TEST-IDS-SCORE ist das erwartete Ergebnis einer autorisierten Simulation. Eine Detection ist ein untersuchungswürdiges Signal; sie bestätigt für sich allein weder eine Kompromittierung noch einen Incident. Ordne nur den exakt passenden Treffer dem Test zu. Zusätzliche Detections, abweichende Quellen, Ziele oder Zeitpunkte werden normal durch SOC beziehungsweise MDR triagiert und nicht pauschal als Testfolge geschlossen.

Nicht jede Detection erzeugt automatisch einen Case oder geht in die Verantwortung von Sophos MDR über. Ein aus XDR-Detections abgeleiteter Case ist Self-managed, bleibt in Kundenverantwortung und muss einem Kundenadministrator zugewiesen werden; Sophos untersucht ihn nicht. Sophos MDR übernimmt nur einen als Sophos-managed ausgewiesenen Case auf Basis von MDR-Detections. Welche Reaktion MDR ausführen darf, richtet sich zusätzlich nach dem konfigurierten Modus Authorize, Collaborate oder Notify Only. Kennzeichne oder schliesse deshalb nur den eindeutig korrelierten Testtreffer beziehungsweise Test-Case gemäss dem bereits geltenden XDR- oder MDR-Prozess. Dieses Runbook bestätigt lediglich Erzeugung und Inhalt des Testtreffers.

Wenn der Treffer fehlt oder nicht passt

Arbeite vom engsten Fehlerbereich nach aussen und ändere nicht mehrere Komponenten gleichzeitig:

Appliance Manager bestätigt den Start nicht

Prüfe, ob die richtige Appliance gewählt wurde, Appliance Manager vom lokalen Netz erreichbar ist und die zadmin-Anmeldung funktioniert. Ohne Startbestätigung gibt es noch keinen belastbaren NDR-Testlauf. Ändere deshalb weder Port Mirroring noch Detection-Einstellungen, sondern stelle zuerst den Appliance-Manager-Zugriff wieder her oder eskaliere den Appliance-Fehler.

Der Test startet, aber keine Detection erscheint

Warte die dokumentierten zehn Minuten ab und kontrolliere Zeitraum, Filter und Schreibweise in Threat Analysis Center > Detections.
Prüfe in den Firewall-Logs für die notierte Startzeit, ob die freigegebene Quelle tatsächlich eine TCP-Verbindung zum genehmigten Testziel auf Port 2222 aufgebaut hat. Ein Deny oder fehlender Verbindungsversuch grenzt den Fehler auf Regel, Routing, DNS oder Teststart ein.
Ist die Verbindung sichtbar, kontrolliere, ob genau dieser Quellverkehr am überwachten Switch-Port gespiegelt und dem richtigen NDR-Sensor zugeführt wird. Erweitere die Firewall-Regel nicht auf Any, nur um einen Treffer zu erzwingen.
Prüfe den Betriebszustand der betroffenen Integration Appliance und des NDR-Sensors. Eine gesunde Appliance allein beweist noch nicht, dass der Testfluss am Sensor ankommt.
Wiederhole den Test höchstens nach einer konkreten Korrektur und mit erneut festgehaltener Startzeit. Bleibt der Treffer aus, übergib Ticket, Zeitstempel, Firewall-Beobachtung, Testquelle, Ziel und betroffenen Sensor an den zuständigen Sophos-Supportweg.

Eine Detection erscheint, aber die Merkmale weichen ab

Vergleiche zuerst Zeit, Quelle, Ziel und Port. Fehlt diese eindeutige Zuordnung, behandle den Treffer nicht als erfolgreichen Test. Übergib eine unerwartete Detection dem SOC/MDR-Team zur normalen Triage. Verändere oder schliesse sie nicht allein aufgrund eines ähnlichen Namens.

Aufräumen und Rückweg

Der Rückbau gehört zum Test und erfolgt unabhängig vom Ergebnis:

Deaktiviere oder lösche die temporäre ausgehende Firewall-Regel für TCP 2222 zum Testziel. Entferne auch eigens dafür erstellte Host-, FQDN- oder Serviceobjekte, sofern sie von keiner anderen genehmigten Konfiguration verwendet werden.
Prüfe in der aktiven Firewall-Konfiguration, dass von der Testquelle keine entsprechende Freigabe mehr besteht. Ein Kommentar oder ein geschlossenes Change-Ticket ersetzt diesen technischen Post-Check nicht.
Informiere SOC beziehungsweise MDR über das Testende und über Detection-ID, Ergebnis und Rückbau. Lass nur den eindeutig korrelierten Testtreffer als autorisierte Simulation dokumentieren.
Kennzeichne oder schliesse die korrelierte Test-Detection und einen daraus entstandenen Case ausschliesslich nach dem bestehenden, zutreffenden XDR- beziehungsweise MDR-Prozess. Ein Self-managed XDR-Case bleibt beim zugewiesenen Kundenadministrator; ein Sophos-managed MDR-Case bleibt im MDR-Workflow und unterliegt dem vereinbarten Response-Modus.
Schliesse das Ticket erst, wenn der Regelrückbau geprüft, das Ergebnis festgehalten, das Testartefakt nach dem zutreffenden Prozess behandelt und eine unerwartete Detection einer verantwortlichen Person zugewiesen wurde.

Ein fehlgeschlagener Test wird durch denselben Rückbau beendet. Die temporäre Freigabe bleibt nicht für eine spätere Fehlersuche offen; für einen neuen Lauf braucht es ein neues oder ausdrücklich verlängertes, bestätigtes Testfenster.