Zum Inhalt springen
Avanet

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.

  1. Öffnen Sie in Sophos Fusion Threat Analysis Center > Live Discover > Switch.
  2. Wählen Sie eine integrierte Data Lake-Abfrage für Sophos Switch. Prüfen Sie ihren Zweck, die sichtbare Definition und die verlangten Parameter.
  3. Legen Sie, falls angeboten, unter Select a Time Period den Untersuchungszeitraum fest und führen Sie die Abfrage aus.
  4. Ordnen Sie die Resultate anhand von Switchidentität, type_of_data und den Zeitfeldern ein. Vergleichen Sie einen bekannten Switch oder Testclient mit den Daten in der Switch-Verwaltung.
  5. 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.
  6. Ö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.
  7. 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.
  8. 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.

FeldDokumentierte Bedeutung
message_identifierEindeutige ID, die von der Ingestion-Pipeline erzeugt wird
ingest_dateDatum, an dem die Daten aufgenommen wurden
ingestion_timestampAufnahmezeit als Epoch-Sekunden
schema_versionVersion des Data-Lake-Schemas
record_sizeGrösse der Daten
customer_idKunden-ID
type_of_dataArt der im Stream gesendeten Daten, beispielsweise Client- oder Logdaten
is_full_setGibt an, ob die Lieferung vollständig oder inkrementell ist
timestampZeitpunkt, zu dem das Ereignis erzeugt wurde
device_idEindeutige ID des Switches
device_nameName des Switches
device_modelModell des Switches
device_firmwareFirmwareversion des Switches
device_serial_idSeriennummer des Switches
client_macMAC-Adresse des verbundenen Geräts
client_ipIP-Adresse des verbundenen Geräts
client_hostnameHostname des verbundenen Geräts
client_event_timestampZeitpunkt, zu dem sich das Gerät verbunden hat
client_conn_statusVerbindungsstatus des Geräts
log_idLog-ID
log_subtypeLog-Subtyp
log_componentLog-Komponente
log_messageLogmeldung
log_severitySchweregrad der Logmeldung
device_ipIP-Adresse des Switches
device_portSwitchport, mit dem der Client verbunden ist
client_vlanVLAN, dem das verbundene Gerät zugewiesen ist
direct_end_deviceGibt 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

  • timestamp bezeichnet den Zeitpunkt, an dem das Ereignis erzeugt wurde.
  • client_event_timestamp bezeichnet den Zeitpunkt, an dem sich das Gerät verbunden hat.
  • ingestion_timestamp bezeichnet die Aufnahme in Epoch-Sekunden.
  • ingest_date ist 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_id und die Switchidentität zum richtigen Tenant und Zielgerät?
  • Passen type_of_data und 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_set berücksichtigt, falls Sie eine Aussage über Vollständigkeit treffen?
  • Stimmen bei einem bekannten Testclient MAC-Adresse, Port, VLAN und der Wert von direct_end_device mit 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.