Sophos Switch: Geräte- und Clientdaten mit Live Discover abfragen
Mit Live Discover fragen Sie Telemetrie von Sophos Switches ab, die in Sophos Fusion verwaltet werden. Die Data-Lake-Daten helfen beispielsweise dabei, Geräte zu untersuchen, die mit einem bestimmten Switch verbunden waren. Sie sind jedoch keine Live-Ansicht des aktuellen Switchzustands.
Voraussetzungen
Sie benötigen mindestens einen in Sophos Fusion verwalteten Sophos Switch und Zugriff auf den richtigen Tenant sowie auf Threat Analysis Center > Live Discover. Live Discover setzt eine Lizenz für Sophos EDR, XDR oder MDR voraus. Die Dokumentation nennt darüber hinaus weder ein bestimmtes Switch-Lizenzpaket noch eine bestimmte Administratorrolle. Falls Live Discover, Switch oder eine Bearbeitungsfunktion fehlt, lassen Sie deshalb die Lizenzzuweisung, Ihre Zugriffsrechte und die Freischaltung im betroffenen Tenant prüfen.
Legen Sie vorab das Untersuchungsziel fest. Geeignete Bezugspunkte sind etwa Switch-ID, Gerätename, Seriennummer, Client-MAC-Adresse, Port, VLAN und Zeitraum. Designer Mode benötigen Sie nur, wenn Sie eine Abfrage bearbeiten oder neu erstellen.
Switch-Daten abfragen
Beginnen Sie mit einer integrierten Switch-Abfrage. So erhalten Sie zuerst ein Vergleichsresultat und müssen nur dann in den Designer wechseln, wenn die bestehende Abfrage Ihre Frage nicht beantwortet.
- Öffnen Sie in Sophos Fusion Threat Analysis Center > Live Discover > Switch.
- Wählen Sie eine integrierte Data Lake-Abfrage für Sophos Switch. Prüfen Sie ihren Zweck, die sichtbare Definition und die verlangten Parameter.
- Legen Sie, falls angeboten, unter Select a Time Period den Untersuchungszeitraum fest und führen Sie die Abfrage aus.
- Ordnen Sie die Resultate anhand von Switchidentität,
type_of_dataund den Zeitfeldern ein. Vergleichen Sie einen bekannten Switch oder Testclient mit den Daten in der Switch-Verwaltung. - Reicht die integrierte Abfrage aus, dokumentieren Sie Abfrage, Parameter, Zeitfenster und Ergebnis. Andernfalls schalten Sie Designer Mode ein und wählen einen dieser Wege:
- Bestehende Abfrage anpassen: Wählen Sie die Abfrage unter Query und klicken Sie auf Edit. Sichern Sie die ursprüngliche Definition, bevor Sie sie ändern.
- Neue Abfrage erstellen: Klicken Sie unter Query auf Create new query und wählen Sie Data Lake als Source.
- Öffnen Sie im SQL-Dialog oben rechts Schema. Der Schema Viewer erscheint in einem neuen Tab. Wählen Sie dort NSG Cswitch > nsg_cswitch_data und prüfen Sie die verfügbaren Spalten und Datentypen.
- Verwenden Sie nur Tabellen, Felder und Werte, die der aktuelle Schema Viewer oder die integrierte Abfrage zeigt. Ändern Sie jeweils nur einen zusammengehörigen Teil, etwa die Feldauswahl oder den Filter für einen bekannten Switch.
- Führen Sie die angepasste Abfrage zuerst mit einem eng begrenzten, bekannten Switch oder Client aus. Vergleichen Sie das Resultat mit der unveränderten integrierten Abfrage und den bekannten Inventar- oder Verbindungsdaten.
Für die Suche nach Clients eines bestimmten Switches bestimmen Sie das Zielgerät eindeutig über device_id oder die Seriennummer. Werten Sie danach Client-MAC-Adresse, device_port, client_vlan, Verbindungsstatus und Zeitfelder gemeinsam aus. Eine solche Eingrenzung verhindert Verwechslungen, beweist aber noch keine vollständige Clientliste; dafür müssen auch Zeitraum und is_full_set passen.
Zeitfenster wählen
Select a Time Period ist bei Data-Lake-Abfragen optional. Ohne eigene Auswahl gelten die vergangenen 7 Tage. Eine einzelne Abfrage kann höchstens 30 Tage abdecken.
Für längere Untersuchungen führen Sie mehrere Abfragen mit getrennten Zeitfenstern aus. Sophos nennt für 90 Tage beispielsweise 0–30, 31–60 und 61–90 Tage. Dokumentieren Sie jedes Fenster einzeln und lassen Sie Switch, Datenart und andere Filter beim Vergleich unverändert.
Felder im Switch-Schema
Das Schema umfasst Switchidentität, verbundene Clients und Logs. type_of_data bezeichnet die Art der gesendeten Daten, beispielsweise Client- oder Logdaten. Deshalb enthält nicht jede Zeile zugleich alle Client- und Logfelder.
| Feld | Dokumentierte Bedeutung |
|---|---|
message_identifier | Eindeutige ID, die von der Ingestion-Pipeline erzeugt wird |
ingest_date | Datum, an dem die Daten aufgenommen wurden |
ingestion_timestamp | Aufnahmezeit als Epoch-Sekunden |
schema_version | Version des Data-Lake-Schemas |
record_size | Grösse der Daten |
customer_id | Kunden-ID |
type_of_data | Art der im Stream gesendeten Daten, beispielsweise Client- oder Logdaten |
is_full_set | Gibt an, ob die Lieferung vollständig oder inkrementell ist |
timestamp | Zeitpunkt, zu dem das Ereignis erzeugt wurde |
device_id | Eindeutige ID des Switches |
device_name | Name des Switches |
device_model | Modell des Switches |
device_firmware | Firmwareversion des Switches |
device_serial_id | Seriennummer des Switches |
client_mac | MAC-Adresse des verbundenen Geräts |
client_ip | IP-Adresse des verbundenen Geräts |
client_hostname | Hostname des verbundenen Geräts |
client_event_timestamp | Zeitpunkt, zu dem sich das Gerät verbunden hat |
client_conn_status | Verbindungsstatus des Geräts |
log_id | Log-ID |
log_subtype | Log-Subtyp |
log_component | Log-Komponente |
log_message | Logmeldung |
log_severity | Schweregrad der Logmeldung |
device_ip | IP-Adresse des Switches |
device_port | Switchport, mit dem der Client verbunden ist |
client_vlan | VLAN, dem das verbundene Gerät zugewiesen ist |
direct_end_device | Gibt an, ob das Gerät direkt mit dem Switch verbunden ist |
Status-, Subtyp- und Schweregradwerte können je nach angezeigten Daten variieren. Übernehmen Sie deren genaue Schreibweise und Bedeutung aus dem aktuellen Schema und dem Abfrageresultat.
Resultate richtig einordnen
Eine rohe Data-Lake-Zeile ist zunächst ein Abfrageresultat. Ob sie Client- oder Logdaten enthält, ergibt sich aus type_of_data und den vorhandenen Feldern. Fasst die SQL-Abfrage mehrere Datensätze zusammen, ist die Ergebniszeile eine berechnete Zusammenfassung und kein einzelnes Netzwerkereignis. Übertragen Sie die Bedeutung von timestamp daher nicht ungeprüft auf ein Aggregat.
Identität und Tenant
device_id ist die eindeutige Switch-ID. Vergleichen Sie zusätzlich mindestens einen weiteren Bezugspunkt wie device_serial_id, device_name, device_model oder device_ip mit dem Zielgerät. Namen und IP-Adressen können sich ändern oder wiederverwendet werden. customer_id ordnet die Daten dem Tenant zu und ist keine Switch-, Serien- oder Client-ID.
Ereignis- und Aufnahmezeit
timestampbezeichnet den Zeitpunkt, an dem das Ereignis erzeugt wurde.client_event_timestampbezeichnet den Zeitpunkt, an dem sich das Gerät verbunden hat.ingestion_timestampbezeichnet die Aufnahme in Epoch-Sekunden.ingest_dateist das Aufnahmedatum.
Eine spätere Aufnahme ist nicht automatisch ein späteres Netzwerkereignis. Prüfen Sie bei Zeitreihen auch die Epoch-Umrechnung und die Zeitzone der verwendeten Abfrageumgebung.
Vollständige und inkrementelle Daten
is_full_set zeigt, ob eine Lieferung vollständig oder inkrementell ist. Behandeln Sie einen inkrementellen Datensatz nicht als vollständiges Clientinventar. Auch eine als vollständig gekennzeichnete Lieferung garantiert für sich allein nicht, dass jeder erwartete Client im untersuchten Zeitraum erscheint.
Clients und Logs
device_port und client_vlan beziehen einen Client auf Port und VLAN. Ob er direkt angeschlossen ist, ergibt sich erst aus dem Wert von direct_end_device, nicht aus der blossen Existenz des Felds. IP-Adresse und Hostname können fehlen oder wechseln; ziehen Sie für die Zuordnung zusätzlich client_mac und die Zeitfelder heran. Ein Telemetriedatensatz ist zudem nur eine zeitbezogene Beobachtung und kein Beleg für den aktuellen Zustand oder eine lückenlose Verbindungshistorie.
Bei Logdaten bilden log_id, log_subtype, log_component, log_message und log_severity den Zusammenhang. Der Schweregrad allein beweist weder Ursache noch Auswirkung eines Netzproblems.
Ergebnis prüfen
Bevor Sie das Resultat verwenden, beantworten Sie diese Fragen:
- Gehören
customer_idund die Switchidentität zum richtigen Tenant und Zielgerät? - Passen
type_of_dataund die tatsächlich gefüllten Client- oder Logfelder zur Untersuchungsfrage? - Liegen Ereignis-, Client- und Aufnahmezeit im erwarteten Fenster, und wurden sie getrennt interpretiert?
- Wurde
is_full_setberücksichtigt, falls Sie eine Aussage über Vollständigkeit treffen? - Stimmen bei einem bekannten Testclient MAC-Adresse, Port, VLAN und der Wert von
direct_end_devicemit der erwarteten Verbindung überein? - Liefert die integrierte Abfrage für dasselbe Ziel und Zeitfenster ein plausibles Vergleichsresultat?
Ein fehlender Datensatz ist nur ein fehlender Nachweis unter den gewählten Bedingungen. Er beweist weder, dass der Switch oder Client nicht existiert, noch für sich allein einen Telemetriefehler.
Probleme eingrenzen
Switch-Abfragen oder Bearbeitungsfunktionen fehlen
Fehlt der Bereich Switch, prüfen Sie zuerst den richtigen Fusion-Tenant, einen durch Fusion verwalteten Switch und die Lizenzzuweisung für Sophos EDR, XDR oder MDR. Lassen Sie anschliessend Ihre Zugriffsrechte und die Freischaltung im Tenant kontrollieren. Für Edit und Create new query muss zusätzlich Designer Mode eingeschaltet sein.
Schema oder Tabelle fehlt
Der Schema Viewer lässt sich aus dem SQL-Dialog einer bearbeiteten oder neuen Abfrage öffnen. Bei einer neuen Abfrage muss Source: Data Lake gewählt sein. Für Switch-Telemetrie verwenden Sie ausschliesslich den im Viewer angezeigten Pfad NSG Cswitch > nsg_cswitch_data und dessen aktuelle Felder.
Die Abfrage liefert keine Zeilen
Testen Sie zunächst eine integrierte Switch-Abfrage für einen bekannten Switch. Notieren Sie Tenant, Switchfilter, erwarteten Testdatensatz und Zeitfenster. Nehmen Sie eigene Filter danach einzeln zurück und gleichen Sie die Feldnamen mit dem Schema ab.
Berücksichtigen Sie ohne eigene Zeitauswahl den Standard von 7 Tagen. Erweitern Sie das Fenster bei unveränderten übrigen Bedingungen schrittweise bis höchstens 30 Tage. Für längere Untersuchungen verwenden Sie getrennte, dokumentierte Fenster. Vergleichen Sie ausserdem Ereignis- und Aufnahmezeit und prüfen Sie type_of_data sowie is_full_set. Halten Sie das Resultat als «keine Zeilen unter den gewählten Abfragebedingungen und im gewählten Zeitraum» fest.
Den Betriebs- und Synchronisierungszustand des Zielgeräts können Sie zusätzlich mit dem Runbook Sophos-Switch-Flotte betreiben prüfen.
Zeilen sind vorhanden, aber Clientdaten fehlen
Eine Logzeile muss keine Clientfelder enthalten. Prüfen Sie deshalb zuerst type_of_data und is_full_set, danach client_mac, client_ip, client_hostname, client_event_timestamp und client_conn_status im Zusammenhang. Ergänzen Sie fehlende Werte nicht aus dem Inventar oder aus Namenskonventionen.
Die Zeitreihe wirkt widersprüchlich
Vergleichen Sie Ereignis- und Aufnahmezeit getrennt und kontrollieren Sie Epoch-Umrechnung sowie Zeitzone. Eine verzögerte Aufnahme ist nicht automatisch ein zweites Netzwerkereignis. Für die Deduplizierung können Sie message_identifier heranziehen; dokumentiert ist dessen Eindeutigkeit jedoch nur innerhalb der Ingestion-Pipeline.
Änderungen zurücknehmen und Daten schützen
Eine Abfrage ändert ihre SQL-Definition oder Auswahl, nicht die Switchkonfiguration. Wenn eine angepasste Abfrage unzuverlässig ist, verwenden Sie sie nicht weiter und kehren Sie zur unveränderten integrierten Abfrage zurück. Stellen Sie bei Bedarf die zuvor gesicherte Definition wieder her oder verwerfen Sie die neue Variante mit der in Ihrer Oberfläche angebotenen Funktion. Kontrollieren Sie danach mit der integrierten Abfrage, dass der normale Ablauf weiterhin funktioniert.
Exportierte Resultate können Kunden-IDs, Seriennummern, IP- und MAC-Adressen, Hostnamen, Ports, VLANs und Logmeldungen enthalten. Schützen und löschen Sie Exporte, Screenshots und Notizen gemäss Ihren Aufbewahrungs- und Datenschutzvorgaben. Das Zurücknehmen einer Abfrage entfernt bereits gespeicherte Kopien nicht; diese müssen an ihren jeweiligen Ablageorten behandelt werden.