Sophos NDR Integration Appliance und Sensor diagnostizieren

Dieses Runbook grenzt Störungen der NDR Integration Appliance und des NDR-Sensors ein. Es beginnt beim exakten Status in Sophos Fusion, ordnet die sichtbaren Status- und Messwerte ein und zeigt, wann Logs für Sophos Support gesammelt werden müssen.

Ein Status Connected oder Grün ist nur ein Zwischencheck. Er beweist weder vollständige Mirror-Abdeckung noch einen erfolgreichen Upload jedes Datensatzes oder eine funktionierende Ende-zu-Ende-Erkennung.

Schnellablauf

1. Appliance-Name, System ID, Fehlerbeginn mit Zeitzone und exakten Meldungstext erfassen.
2. In Sophos Fusion Farbe und Appliance-Zustand prüfen, aber noch nichts neu starten.
3. Im Appliance Manager Status, NDR, Integrations und Advanced lesen und Screenshots mit Zeitstempel erstellen.
4. Das Symptom einer Fehlerklasse zuordnen: Plattform/CPU, Egress/Upload, SPAN, Registrierung oder gemeinsame Ressourcen.
5. Nur eine reversible Korrektur innerhalb dieser Fehlerklasse durchführen.
6. Dieselben Messpunkte unter vergleichbarer Last erneut prüfen.
7. Bei widersprüchlichen Signalen, nicht betriebsbereiten Containern oder ausbleibender Wirkung Logs sammeln und eskalieren.

Symptom, Prüfung und nächster Schritt

Rot, Gelb und Grün korrekt lesen

Rot: Integration arbeitet nicht

Bei Rot ist die konkrete Meldung wichtiger als die Farbe:

• NDR containers not ready, <specific container names>. bedeutet, dass mindestens eine benötigte Anwendung nicht bereit ist. Ist dragonfly genannt oder im sichtbaren Zustand auffällig, beginnt die Prüfung bei CPU-Kompatibilität und Plattformvoraussetzungen.
• Upload to s3 failed. Request was received but an error code was returned. Error code: <S3 upload error> bedeutet, dass die Appliance über eine vorab signierte URL in einen S3-Bucket hochladen wollte und einen Fehlercode erhielt. Das ist primär eine Egress-/Proxy-Fehlerklasse.
• spanX: unhealthy span ordnet die Störung dem Eingang des genannten SPAN-Ports zu. Die sendende Netzwerkkomponente oder der virtuelle Mirror-Pfad ist zuerst zu prüfen.

Gelb: Integration arbeitet mit Fehlern

spanX: packets being dropped erscheint, wenn mehr als 10 % der Netzwerkpakete verworfen werden. Paketerfassung und -verarbeitung sind CPU-intensiv. Bei einer VM können zusätzliche vCPUs nötig sein; bei zertifizierter Hardware kann die Last nach freigegebenem Abdeckungsplan auf eine weitere Appliance verteilt werden. Gemeinsam betriebene Log Collectors können dieselben Ressourcen zusätzlich belasten.

Nur eine Kapazitätsänderung behebt jedoch keine überlappenden Mirror-Quellen, keinen überbuchten Zielpfad und keine falsche SPAN-Konfiguration. Vor dem Skalieren deshalb Traffic-Profil und Topologie vergleichen.

Grün: kein aktuell gemeldeter Integrationsfehler

Grün bedeutet, dass NDR SPAN-Traffic empfängt und Paketdaten ohne gemeldetes Problem verarbeitet. Der aktuelle Health-Klassifikator für einen gesunden SPAN-Port verlangt mindestens 2 % Unicast-Pakete. Das ist kein Beleg dafür, dass alle gewünschten VLANs, Standorte, Richtungen oder Zeitfenster erfasst werden. Die frühere Aussage, ein Port müsse 100 % Unicast zeigen, wird nicht verwendet.

Für die detaillierte Interpretation von Health- und Kapazitätssignalen siehe «Sophos NDR Health und Kapazität überwachen».

Bleiben trotz Grün erwartete Detections aus, führen Sie zuerst die sichere NDR-Test-Detection aus. Bleibt auch dieser Nachweis aus und besteht der Verdacht auf ein VLAN-Problem, sichern Sie Zeitfenster, SPAN-Port, ausgewähltes VLAN und den sichtbaren Appliance-Zustand für Sophos Support. VLAN Strip darf erst geändert werden, wenn die Auswertung bestätigt, dass am Sensor sowohl das ausgewählte VLAN als auch VLAN0 ankommt; andernfalls bleibt die Einstellung unverändert.

Lokale Ereignisse mit NDR Query eingrenzen

Wenn Capture und Upload getrennt geprüft werden müssen, kann NDR Query im Appliance Manager die lokale Ereignisebene zeigen. Die Abfrage läuft gegen die NDR-Ereignisdatenbank auf dieser Appliance-VM, nicht gegen den Sophos Data Lake. Sie ist klar von der separat bereitgestellten Investigation Console zu trennen, die Daten einer zugewiesenen NDR Appliance für Threat Hunting im lokalen Netzwerk bereitstellt.

1. Betroffene Appliance und Fehlerzeitfenster festhalten.
2. NDR Query öffnen und auf Query Example queries wählen.
3. Eine passende vordefinierte Abfrage mit Copy kopieren, in das Textfeld einfügen und mit Go ausführen.
4. Das Ergebnis unter Query Results mit Zeitstempel sichern; Spalten bei Bedarf per Drag-and-drop ordnen.
5. Das Resultat mit der Aktivität unter NDR und dem Fusion-Zustand desselben Zeitfensters vergleichen.

Der Appliance Manager unterstützt hier derzeit nur vordefinierte Abfragen. Keine eigene SQL-Abfrage und keine Abfrage aus der Investigation Console einsetzen. Ein lokales Ergebnis bei fehlenden Daten in Fusion lenkt die weitere Prüfung auf Upload und Egress. Ein leeres lokales Ergebnis lenkt sie zuerst auf SPAN-Eingang, Zeitfenster und Auswahl der vordefinierten Abfrage; es ist allein noch kein Fehlerbeweis.

Unerwartete Nmap-Detections einordnen

Treten in anderen Security-Produkten neu Nmap-basierte OS-Scans auf, unter Global NDR Settings den Zustand von OS Detection prüfen. Die standardmässig ausgeschaltete Option scannt nach dem Einschalten alle zwei Stunden jede interne IP-Adresse, die NDR gesehen hat. Dadurch können andere Security-Produkte Detections erzeugen.

Aktivierungszeitpunkt, betroffene Appliance, Ziel-IP-Adressen und Detection-Zeitstempel vergleichen. Ist die Aktivierung nicht freigegeben, sind Ziele unzulässig oder entstehen betriebliche Auswirkungen, OS Detection wieder ausschalten und den Zeitpunkt dokumentieren. Anschliessend überwachen, dass keine neuen, von dieser Funktion ausgelösten Scan-Ereignisse hinzukommen; bereits bestehende Meldungen gemäss dem Prozess des jeweiligen Tools bearbeiten. Keine Nmap-Kommandos manuell wiederholen und keine Ausnahmen in anderen Security-Produkten anlegen, nur um das Symptom zu verdecken. Soll die Funktion eingeschaltet bleiben, braucht es eine dokumentierte Freigabe der Netzwerk- und Security-Verantwortlichen sowie eine Validierung über mindestens ein vollständiges Zwei-Stunden-Intervall.

Container- und Dragonfly-Symptome ohne CLI eingrenzen

Dragonfly verarbeitet NDR-Daten. Zwei sichtbare Muster sind für die Diagnose relevant:

• Eine rote Meldung mit nicht betriebsbereiten Containern kann auftreten, wenn dragonfly in einer Neustartschleife hängt, weil erforderliche CPU-Instruktionen fehlen.
• Ist die Appliance in Fusion Connected, erreichen Daten den Data Lake aber nicht und Dragonfly steht unter Advanced auf Pending, muss bei einem VMware-EVC-Cluster der EVC-Modus geprüft werden. Sophos verlangt Skylake generation or later; Sandy Bridge wird nicht unterstützt.

Für NDR-VMs auf VMware ESXi oder Hyper-V müssen die CPU-Flags pdpe1gb und avx2 verfügbar sein. pdpe1gb wird für die Paketerfassung benötigt, avx2 für Machine-Learning-Funktionen. Mehr vCPUs kompensieren fehlende Flags nicht. Bei Hyper-V ist Processor Compatibility Mode nicht unterstützt. Bei ESXi gelten zusätzlich VM Hardware Version 11 oder neuer und die dokumentierten Plattformanforderungen.

Sichere Prüfung:

1. Unter Advanced Status und sichtbaren Namen des betroffenen Containers dokumentieren.
2. Unter Status CPU-Auslastung, Memory, Root Disk und Data Disk erfassen.
3. Hypervisor, CPU-Modell, EVC- oder Compatibility-Einstellung und die der VM bereitgestellten Flags mit der freigegebenen Plattformdokumentation vergleichen.
4. Eine falsche Hypervisor-/CPU-Einstellung nur in einem geplanten Wartungsfenster korrigieren; vorher Ausgangswert und Rückweg festhalten.
5. Danach VM und Appliance-Zustand über die normalen Betriebsoberflächen validieren.
6. Bleibt dragonfly Pending, bleibt ein Container nicht bereit oder ist eine Neustartschleife sichtbar, Logbundle erstellen und eskalieren.

Die Plattformwerte und unterstützten CPU-Voraussetzungen sind in «Sophos NDR: Plattform wählen und Sensor richtig dimensionieren» zusammengefasst.

S3-Upload und ausgehende Verbindung prüfen

Ein S3-Uploadfehler bedeutet nicht, dass kein SPAN-Traffic ankommt. Capture und Upload sind zwei getrennte Stufen. Im Appliance Manager unter NDR deshalb Capture-/Flow-Aktivität und Uploaded für dasselbe Zeitfenster sichern.

Den Egress-Pfad in dieser Reihenfolge prüfen:

1. Stimmt die MGMT-IP-Konfiguration – DHCP oder manuell – mit dem Managementnetz überein?
2. Funktionieren DNS-Auflösung und NTP über die vorgesehenen Dienste?
3. Führt die Default Route über den vorgesehenen Internet- oder zentralen Egress-Pfad?
4. Erlauben Network ACL, Security Group beziehungsweise lokale Firewall ausgehenden HTTPS-Verkehr?
5. Lässt der Web Proxy die Appliance und die benötigten Ziele zu, ohne die vorab signierte S3-Anfrage zu verändern oder zu blockieren?
6. Stimmen die Regeln mit den aktuellen Port- und Domain-Ausnahmen von Sophos überein?

Die Liste der regionsabhängigen Domains ohne Wildcards wird nicht aus alten Tickets kopiert. Sie ist zum Prüfzeitpunkt gegen die aktuellen Appliance requirements abzugleichen. Eine temporäre breite Freigabe auf das gesamte Internet ist kein sicherer Test. Änderungen werden einzeln vorgenommen und nach jedem Schritt mit demselben Fehlerzeitfenster validiert.

Rollback: Eine testweise angepasste Proxy-, ACL- oder Firewall-Regel wird nach der Prüfung auf den Ausgangswert zurückgesetzt, sofern sie nicht dauerhaft erforderlich ist. Beim Zurücksetzen müssen die bisher funktionierenden Management- und Uploadpfade anderer Integrationen bestehen bleiben.

SPAN unhealthy, Packet Drops oder fehlende Flows

spanX: unhealthy span

Für genau den genannten Port prüfen:

• erwartete Mirror-Quelle und Richtung,
• dediziertes Zielinterface und physische Verkabelung,
• Zuordnung von Capture-NIC, Portgruppe oder vSwitch,
• bei ERSPAN Zieladresse, Routing, MTU sowie GRE- oder VXLAN-Werte,
• letzte Änderungen an VLAN, Trunk, Portgruppe, Hostplatzierung oder Mirror-Session,
• ob dasselbe Ziel versehentlich wieder als Quelle gespiegelt wird.

Mit einem Pilot-Host bekannten, harmlosen Unicast-Verkehr erzeugen und im selben Zeitfenster den vorgesehenen SPAN-Port sowie den Flow-Verlauf beobachten. Fehlt die Aktivität, bleibt die Diagnose bei Quelle, Richtung, Filter, Transport oder Capture-Zuordnung. Erst wenn der Eingang belegt ist, werden Verarbeitung und Upload beurteilt.

spanX: packets being dropped

Bei mehr als 10 % Drops werden zusätzlich erfasst:

• zugewiesene vCPUs und CPU je Kern,
• Bandbreite, Pakete/s und Flows/s,
• neu hinzugefügte oder überlappende Mirror-Quellen,
• Memory sowie Root- und Data-Disk-Trend,
• alle Log Collectors derselben Appliance mit Received, Filtered, Accepted und Uploaded.

Für eine gemeinsam genutzte Appliance beginnt die Dimensionierung bei NDR; danach wird die Collector-Last berücksichtigt. Als zusätzliche Grenzsignale gelten applianceweit höchstens 8'000 Collector-Events pro Sekunde und bei 16 GB RAM höchstens 2 GB für Log Collectors. Selbst von NDR beanspruchte CPU-Kerne können durch andere Integrationen mitbenutzt werden und dadurch die NDR-Kapazität beeinflussen. Muss Collector-Last verteilt werden, zuerst Zuständigkeit und Ziel-Appliance festlegen und die generische Integrationsanleitung verwenden; dieses Runbook ändert keine herstellerspezifischen Syslog-Quellen.

Bei 4 vCPUs bleibt durch DPDK typischerweise ein Kern bei 100 %, bei 8 vCPUs bleiben zwei Kerne bei 100 %. Das allein ist normal. Eine Kapazitätsstörung wird durch die Kombination mit Drops, weiteren ausgelasteten Kernen, sinkendem Upload oder einem veränderten Flow-Verlauf belegt.

Die Mirror-Kette, Pilotvalidierung und ein begrenzter Rückweg sind unter «Traffic Mirroring für Sophos NDR planen und validieren» beschrieben.

Registrierung und Connected diagnostizieren

Eine neue Appliance erscheint zunächst als Waiting for deployment. Nach erfolgreichem Bootstrap und Managementpfad wechselt der Status dieser Appliance unter Threat Analysis Center > Integrations > Configured > Integration Appliances auf Connected.

Bleibt dieser Wechsel aus:

1. richtige Appliance anhand Name, Plattform und erzeugtem Image beziehungsweise Seed identifizieren,
2. VM-Boot auf dauernde Fehler- oder Neustartschleifen prüfen,
3. MGMT-IP, VLAN, DHCP oder manuelle Werte, Gateway und DNS kontrollieren,
4. NTP und erforderlichen Egress gegen die aktuellen Appliance-Anforderungen prüfen,
5. Bei ESXi die aus Fusion erzeugte OVA nur für einen Deployment-Versuch verwenden. Bei anderen Plattformen den jeweils aktuellen Deployment-Ablauf prüfen.
6. Zeitpunkt, sichtbaren Zustand und letzte Bootstrap-Ausgabe ohne Secrets dokumentieren.

Die Appliance weder löschen noch neu installieren. Dieses Runbook enthält bewusst keinen Teardown- oder Ersatzablauf. Connected bestätigt die zentrale Verbindung und Zuordnung, nicht SPAN-Coverage, Upload oder Detection.

War die Appliance bereits Connected und verliert diesen Zustand, werden zuerst Managementpfad, Egress und Appliance-Verfügbarkeit geprüft. Mirror-Einstellungen sind dafür nicht der erste Ansatz, weil SPAN und Management getrennte Pfade sind.

Appliance-Manager-Zugang statt Sensorfehler prüfen

Öffnet sich Open Appliance Manager, aber die Anmeldung mit zadmin scheitert, ist dies zunächst ein Anmeldeproblem und kein SPAN-, Upload- oder Dragonfly-Nachweis. Bei einem vergessenen Kennwort im Bestätigungsdialog von Open Appliance Manager den Link reset it verwenden und ein neues Kennwort setzen. Das neue Kennwort direkt im Passwortsystem ablegen; weder altes noch neues Kennwort gehört in Screenshot, Betriebsprotokoll oder Support Case.

Wurde das Konto durch zu viele falsche Kennworteingaben gesperrt, ist der dokumentierte alternative Weg die Webkonsole des Hypervisors, der die Appliance hostet: Dort in der Weblink interface Unlock Account wählen. Dieser Fallback setzt einen bereits autorisierten Zugriff auf diese Hypervisor-Webkonsole voraus; dieses Runbook ergänzt keine Shell-, SSH- oder Konsolenbefehle und leitet daraus keinen anderen Zugangsweg ab. Danach die Anmeldung einmal mit dem sicher gespeicherten Kennwort prüfen. Bleibt sie gesperrt, keine weiteren Kennwörter versuchen, sondern Zeitpunkt und sichtbare Meldung dokumentieren und Sophos Support einschalten.

Offline-Managementkonfiguration als letzter lokaler Recovery-Schritt

Actions > Settings > Management im Appliance Manager darf lokal nur geändert werden, wenn die VM keine Netzwerkverbindung hat. Besteht Konnektivität, gehört die Änderung nach Sophos Fusion. Dass die VM offline ist, schafft selbst keinen neuen Zugang: Die lokale Korrektur setzt ein bereits vorhandenes und freigegebenes Recovery-Verfahren voraus. Ohne diesen Zugang werden die aktuelle MGMT-IP, der letzte bekannte Fusion-Zustand und die Plattformdaten gesichert und eskaliert.

Vor Save alte und neue Werte für IP Assignment, IPv4/Netmask, Gateway IP, DNS, DNS 2 sowie gegebenenfalls Enable Web Proxy, Web Proxy Type, Proxy URL und Port Number vergleichen. Proxy-Credentials bleiben im Passwortsystem. Nur den nachweislich falschen Wert ändern. Fordert die Oberfläche eine Bestätigung für einen Neustart, ist dies ein Restart der Appliance: NDR und alle Log Collectors werden unterbrochen. Deshalb zuerst gemeinsame Arbeitslasten, Wartungsfenster, erwartete neue IP-Adresse und Rückweg dokumentieren.

Nach Wirksamwerden die Erreichbarkeit an der neuen IP-Adresse, den Fusion-Zustand, NDR-Capture und -Upload sowie alle Log Collectors prüfen. Ist der freigegebene Recovery-Zugang weiterhin verfügbar und scheitert die Prüfung, genau die letzte Änderung auf die erfassten Ausgangswerte zurücksetzen. Ist die Oberfläche nicht mehr erreichbar, keine Adressen oder Proxy-Werte raten; mit Baseline, Zeitpunkt und Auswirkung eskalieren. Der vollständige Precheck und Postcheck steht in «Sophos NDR Appliance und Sensor sicher betreiben».

Gemeinsame Appliance: andere Integrationen schützen

Vor jedem Restart oder jeder Ressourcenänderung in Fusion den Pfeil neben dem Appliance-Namen öffnen und alle auf derselben Appliance betriebenen Integrationen erfassen. Im Appliance Manager zeigt Integrations deren Status, letzten Neustart sowie Syslog-Zähler.

• Ein einzelner Log Collector kann über Restart unabhängig neu gestartet werden; NDR und andere Integrationen bleiben aktiv.
• Restart All betrifft alle Log Collectors, aber nicht NDR.
• Restart NDR betrifft den NDR-Sensor, nicht die Log Collectors.
• Actions > Restart betrifft die ganze VM und unterbricht NDR sowie alle Log Collectors.
• Actions > Shutdown stoppt die ganze VM und alle Integrationen; ein separat geprüfter Power-on-Pfad ist erforderlich.

Ein breiter VM-Restart ist kein erster Diagnoseschritt. Zuerst die Status- und Messwerte erfassen und die kleinste betroffene Komponente bestimmen. Auswirkungen und sichere Betriebsfolge beschreibt «Sophos NDR Appliance und Sensor sicher betreiben».

Diagnosedaten und Logs sammeln

Basispaket

Vor einer Änderung erfassen:

• Appliance-Name, System ID, Version, K3S Helm Chart version und Uptime,
• Fusion-Zustand und exakter Fehlertext,
• Beginn, Reproduktionszeitpunkt und Zeitzone,
• unter Status CPU je Kern, Memory, Root Disk und Data Disk,
• unter NDR Capture je konfiguriertem SPAN-Port, Uploaded und Flow-Verlauf,
• unter Integrations alle auf derselben Appliance betriebenen Log Collectors samt Status und Zählern,
• unter Advanced sichtbarer Containerstatus und letzter sichtbarer Neustartzeitpunkt,
• Plattform, VM-Ressourcen, Traffic-Profil und letzte Änderungen,
• erwartetes Ergebnis, tatsächliches Ergebnis und Business Impact.

Wenn kein Appliance-Manager-Zugriff möglich ist

1. In Fusion Threat Analysis Center > Integrations > Configured > Integration Appliances öffnen.
2. Im Drei-Punkte-Menü der betroffenen Appliance Collect logs wählen.
3. In der Spalte Log requested den Informationshinweis öffnen und den dort angezeigten Dateinamen notieren.
4. Diesen Dateinamen mit Appliance, Zeitfenster und Fehlertext an Sophos Support übergeben.

Wenn Appliance Manager erreichbar ist

1. Im Drei-Punkte-Menü Open Appliance Manager und danach Open wählen.
2. Im Appliance Manager Actions > Download Log File wählen.
3. Das Logarchiv nur über den vereinbarten Supportkanal zum bestehenden Case übermitteln.

Logarchive können IP-Adressen, Hostnamen und andere vertrauliche Betriebsdaten enthalten. zadmin-Kennwort, Tokens, private Schlüssel, Proxy-Credentials und andere Secrets gehören nie in Ticket, Screenshot oder Anhang.

Remote Assistance kontrolliert freigeben

Remote Assistance erst für einen konkreten Supportfall aktivieren. Die Appliance muss online sein.

1. In Fusion Threat Analysis Center > Integrations > Configured > Integration Appliances öffnen.
2. Im Drei-Punkte-Menü Remote Assistance wählen.
3. Im Dialog Enable aktivieren.
4. Die Bestätigung zur Sophos Group Privacy Notice setzen und Save wählen.
5. Warten, bis eine Access ID angezeigt wird.
6. Nur diese Access ID über den vereinbarten Kanal an Sophos Support senden.

Die Freigabe endet automatisch nach spätestens sieben Tagen. Wenn die Analyse früher abgeschlossen ist, im selben Dialog Enable deaktivieren und das Ende dokumentieren. Remote Assistance ersetzt weder einen Support Case noch das Diagnosepaket.

Korrektur sicher validieren und zurückrollen

Pro Durchlauf nur eine Hypothese ändern. Vorher Ausgangswert, verantwortliche Person, Wartungsfenster und Rückweg festhalten. Danach unter vergleichbarer Last prüfen:

• vorherige rote oder gelbe Meldung tritt nicht erneut auf,
• der erwartete Appliance-Zustand und der Managementpfad sind stabil,
• jeder vorgesehene SPAN-Port zeigt zum Pilotverkehr passende Aktivität,
• Flow-Verlauf und Upload bleiben über ein aussagekräftiges Zeitfenster stabil,
• keine Meldung für mehr als 10 % Drops kehrt zurück,
• CPU ausserhalb der erwarteten DPDK-Kerne, Memory und Storage zeigen genügend Spielraum,
• alle auf derselben Appliance betriebenen Log Collectors verarbeiten weiterhin Daten,
• eine Plattformänderung stellt die erforderlichen CPU-Flags und den unterstützten Modus bereit.

Scheitert die Nachprüfung oder entstehen neue Auswirkungen, genau die zuletzt vorgenommene Änderung zurücknehmen. Kann der Ausgangszustand nicht wiederhergestellt werden, keine weiteren Änderungen vornehmen, Diagnosedaten sammeln und einen Fall bei Sophos Support eröffnen.

Eine grüne Integration ist nach der technischen Korrektur weiterhin kein Detection-Nachweis. Erst nach stabiler Mirror- und Upload-Kette «Sichere Sophos NDR Test-Detection erzeugen und prüfen» verwenden.

An Sophos Support eskalieren

Einen Fall bei Sophos Support eröffnen, wenn:

• NDR containers not ready bestehen bleibt oder dragonfly sichtbar in Pending beziehungsweise einer Neustartschleife bleibt,
• erforderliche CPU-Flags trotz korrekter Plattform nicht verfügbar sind,
• ein S3-Uploadfehler trotz bestätigtem DNS-, Proxy-, Firewall- und Egress-Pfad bleibt,
• spanX: unhealthy span trotz verifizierter Quelle, Richtung und Zielzuordnung bleibt,
• Packet Drops nach passender Kapazitäts- oder Lastverteilung wiederkehren,
• Connected, lokaler Upload und Data-Lake-Empfang einander widersprechen,
• der Bootstrap keine Registrierung erreicht oder die Appliance unerwartet zwischen Zuständen wechselt,
• eine sichere Korrektur niedrigstufige Container-, Kubernetes- oder Dragonfly-Eingriffe verlangen würde.

Im Case das Basispaket, den Logdateinamen oder das Logarchiv, exakte Schritte und messbare Resultate mitsenden. Bereits verworfene Hypothesen klar nennen. Sophos Support übernimmt Produktprobleme bei Installation, Administration und Betrieb; der Case ist kein Auftrag zur Untersuchung einer Detection.

Eine XDR-basierte, selbst verwaltete Detection bleibt beim Kunden. Nur ein von Sophos verwalteter MDR-Case wird durch Sophos MDR untersucht und beantwortet. Für die Case-Erstellung und Eskalation siehe «Sophos Supportticket mit Support Assistant eröffnen».