Sophos Endpoint Data Collection und Live Discover

Die Data Collection and Investigation Policy steuert zwei voneinander unabhängige Funktionen: Live-Response-Verbindungen und den Upload von Endpoint-Telemetrie in den Sophos Data Lake. Live Discover verwendet anschliessend entweder aktuelle Daten eines verbundenen Geräts oder historische Daten aus dem Data Lake.

Die Funktionen benötigen Sophos EDR, XDR oder MDR. Live Response besitzt eigene Rechte und wird zusätzlich im separaten Response-Artikel behandelt.

Kurzablauf für Classic: Unter Threat Analysis Center > Live Discover zuerst die passende Data source wählen, dann Query category und Query festlegen. Bei einer Endpoint-Abfrage die Zielgeräte unter Devices bewusst eingrenzen und anschliessend Run Query wählen. Das Resultat ist erst belastbar, wenn Ergebniszeilen und Telemetry zur gewählten Quelle, zum Zeitraum und zu den erwarteten Geräten passen.

Vor der Abfrage prüfen, ob der Tenant Threat Analysis Center oder Security Operations verwendet. Das Threat Analysis Center bleibt als Classic view verfügbar. Security Operations trennt Data Lake Search für historische Daten von Live Endpoint Search für Abfragen auf verbundenen Geräten. Die vorhandenen Live-Discover-Schritte, SQL-Beispiele, Planungsangaben und UI-Limits unten beschreiben Classic, sofern keine andere Oberfläche ausdrücklich genannt wird. Ein Tenant-Upgrade macht sie nicht automatisch ungültig und übersetzt sie nicht automatisch in QL.

Security Operations: Data Lake Search

Unter Security Operations > Data Lake Search lassen sich Detections und Ereignisse des Tenants mit drei Methoden durchsuchen. Diese Oberfläche verwendet Advanced Search query language beziehungsweise QL; Classic-Data-Lake-SQL wird nicht unverändert hineinkopiert.

• AI Search übersetzt eine natürlich formulierte Frage in eine Abfrage. Frage oder vorbereiteten Prompt eingeben, Search wählen und die generierte Abfrage zusammen mit den Ergebnissen prüfen. Browse Prompts oder View All öffnen die Prompts; Sophos Only, Kategorie-Chips und Suchbegriff grenzen die Auswahl ein. Bei Bedarf Prompt verfeinern und erneut suchen.
• Query Builder erstellt die Abfrage visuell aus Feldern und Operatoren. Vor Search oder Shift + Enter Datum und Zeitraum festlegen. Für eine erste Prüfung einen kurzen Zeitraum mit einem bekannten Ereignis verwenden und kontrollieren, ob Quelle und Filter dieses Ereignis tatsächlich erfassen.
• Query Editor erlaubt eigene QL-Abfragen. Basics zeigt Syntaxgrundlagen und Beispiele, Cheat Sheet Operatoren und Funktionen. Über Search Help steht kontextbezogene Build With Me-Hilfe für Schemas und Felder bereit. Auch hier vor Search oder Shift + Enter Datum und Zeitraum festlegen. SQL-Beispiele aus den späteren Classic-Abschnitten sind keine QL-Vorlagen.

Die Pin-Schaltfläche neben dem Methodennamen setzt die bevorzugte Suchmethode. Jede ausgeführte Suche landet automatisch in der Suchhistorie des Tenants; eine ausgeführte Suche ist deshalb nicht nur ein lokaler Entwurf. Prompts und Abfragen auf die Untersuchungsfrage begrenzen und keine Geheimnisse eingeben. Eine leere Ergebnistabelle ist erst nach Prüfung von Zeitraum, Quelle und Filtern aussagekräftig; sie beweist keine Abwesenheit eines Incidents.

Zum Speichern bei AI Search und Query Editor Save Query wählen, im Query Builder zunächst Save Search. Name und Kategorie erfassen, optional Beschreibung und Bookmark this Query ergänzen und mit Save Query abschliessen. Unter Saved Queries die gespeicherte Abfrage wieder öffnen und prüfen. Ein Bookmark ordnet sie zusätzlich My Bookmarked Queries zu.

Full Screen vergrössert die Ergebnisansicht. Das Menü im Spaltenkopf bietet Pin, Autosize, Reset, Filter und Ein-/Ausblenden von Spalten; die Reihenfolge lässt sich durch Ziehen der Spaltenköpfe ändern. Über Actions oberhalb der Tabelle können alle Resultate oder eine gewählte Teilmenge exportiert werden. Exportstatus und Download anschliessend auf Data Exports kontrollieren. Eine gefilterte Ansicht oder ein Teilmengenexport wird nicht als vollständiger Untersuchungsumfang dokumentiert.

Live Endpoint Search und historische APIs auseinanderhalten

Live Endpoint Search führt weiterhin osquery-artige SQL-Abfragen auf aktuellen, verbundenen Endpoints aus. Die Live-Discover-REST-zu-GraphQL-Migration betrifft diesen Live-Pfad, nicht historische Data-Lake-Abfragen. Dass der LES-Katalog gespeicherte Queries mit der Quelle dataLake auflisten kann, belegt keine Data-Lake-Ausführung über LES. Eine bestehende historische API-Integration wird daher nicht allein aufgrund dieses Migrationsleitfadens umgestellt.

Seit 12. Oktober 2026 ist die Search GraphQL API v1 für historische Fusion-Data-Lake-Suchen mit QL veröffentlicht. Der Ablauf besteht aus Suchstart, Statusprüfung und paginiertem Ergebnisabruf; er ist getrennt von LES und dessen osquery-artigem Live-SQL. Das Search-GraphQL-Runbook erklärt Requests, Search-URN, Teilergebnisse, Cursor, Ablaufzeit und den Vergleich eines bisherigen SQL-Clients. Data Lake Search bleibt der interaktive Weg und die XDR Query API weiterhin verfügbar. Weder diese Freigabe noch der LES-Migrationsleitfaden übersetzt Classic-SQL automatisch in QL oder verlangt einen sofortigen API-Cutover.

Bestehende REST-Clients und ein optionaler LES-Cutover

Live Discover REST ist ausdrücklich von der Abkündigung der Classic Cases/Detections APIs ausgenommen. Ein bestehender Client muss nicht allein wegen dieser Ankündigung umgestellt werden. Für einen neuen Live-Endpoint-Client oder einen bewusst geplanten Wechsel wird LES separat geprüft; die historische XDR Query API und die oben erhaltenen Classic-SQL-Abfragen bleiben davon getrennt.

LES bindet die Zielgeräte vor dem Query-Start an eine Session: zuerst createLiveDiscoverSession ausführen, den zurückgegebenen Session-Namen sichern, dann die ausgewählten Geräte mit endpointSessions der Session zuweisen. Erst danach runLiveDiscoverQuery mit diesem Namen als sessionId und dem weiterhin erforderlichen matchEndpoints: { all: false } starten. Keine direkten Filter in matchEndpoints als Abkürzung verwenden, auch wenn das Schema sie zulässt: Der Migrationsleitfaden nennt nur den Session-Ablauf als unterstützten Integrationsweg. Mit einem einzelnen genehmigten Pilotgerät und einer eng begrenzten lesenden SQL-Abfrage beginnen; Zielzuordnung, Run-Status, Ergebniszeilen und Telemetry abgleichen.

Vor dem Cutover werden gespeicherte Query- und Kategorie-IDs auf Portabilität geprüft; der Leitfaden bestätigt deren unveränderte Übernahme nicht. Ebenso sind Ergebnisaufbewahrung und spätere Verfügbarkeit fertiger Runs sowie ein Ersatz für die bisherige Enrichment-Pivot-Verwaltung mit dem API-Verantwortlichen zu klären. LES nimmt nur eine Filtergruppe pro Auswahlaufruf an; die Bedeutung mehrerer bisheriger REST-Filtergruppen darf nicht geraten werden. tamperProtectionEnabled wird zu tamperProtection als Liste, und lose String-/JSON-Filter benötigen eine eigene Werteprüfung.

Die Run-, Katalog- und Ergebnis-Pagination werden jeweils getrennt implementiert. Ergebnisse enthalten die SQL-Ausgabespalten als JSON-kodierten String additionalColumns; metadata.columns beschreibt Namen und Typen. Für Folgeseiten den gelieferten pages.nextKey unverändert als params.pageFromKey zurückgeben. HTTP 200 reicht nicht: Auch das GraphQL-errors-Array und den tatsächlichen Run-/Endpoint-Status prüfen. LES teilt die Grenze von 1'000 Runs pro Tag und 10 pro Minute mit geplanten Queries; die REST-API nennt dagegen 500 Runs pro Tag und 10 pro Minute. Diese API-spezifischen Werte ersetzen nicht pauschal die weiter unten beschriebenen Classic-UI-Grenzen. Datenumfang, Device-Watchdog und Ergebnislimits bleiben beim Pilot zu berücksichtigen.

Live Endpoint oder Data Lake

Live-Endpoint-Abfragen basieren auf osquery und werden direkt auf den Zielgeräten ausgeführt. Data-Lake-Abfragen laufen gegen die von den Geräten hochgeladene Telemetrie, können geplant werden und greifen je nach Lizenz auf bis zu 30 beziehungsweise 90 Tage Daten zu.

Eine Data-Lake-Zeitspanne in Live Discover bestimmt den abgefragten historischen Bereich. Sie ist kein Ausführungsplan. Eine einzelne Query kann höchstens 30 Tage umfassen. Für 90 Tage werden mehrere abgegrenzte Abfragen verwendet.

Query auswählen und testen

Unter Threat Analysis Center > Live Discover stehen vorbereitete Endpoint- und Data-Lake-Queries bereit. Der Ablauf trennt dabei bewusst Quelle, Abfrage und Ziel:

1. Unter Data source entweder Endpoint für den aktuellen Zustand verbundener Geräte oder Data Lake für bereits hochgeladene historische Telemetrie wählen.
2. Unter Query category eine Kategorie und unter Query die gewünschte Abfrage auswählen. In den Query-Details prüfen, welche Betriebssysteme unterstützt werden und welchen System Impact Sophos für die Abfrage ausweist.
3. Bei einer Endpoint-Abfrage unter Devices zunächst ein einzelnes Pilotgerät auswählen. Falls nötig, Show filters verwenden und danach die Liste der ausgewählten Geräte aktualisieren. Bei einer Data-Lake-Abfrage stattdessen einen kurzen, bekannten Zeitraum festlegen.
4. Run Query wählen und das Ergebnis abwarten.

Eine neue oder geänderte Abfrage wird zuerst auf einem einzelnen Pilotgerät beziehungsweise einem kurzen Data-Lake-Zeitraum getestet. Erwartet werden Ergebniszeilen, die zum gewählten Gerät oder Zeitraum passen. Unter Telemetry wird zusätzlich kontrolliert, ob das Ziel geantwortet hat, wie hoch System Impact war und welches Datenvolumen übertragen wurde. Bleibt das Resultat leer, zuerst Data source, Zeitraum, unterstütztes Betriebssystem und bei Endpoint-Abfragen den Verbindungsstatus des Geräts prüfen. Bei einer Data-Lake-Abfrage zusätzlich kontrollieren, ob der Upload über My Products > Endpoint > Policies > Data Collection and Investigation beziehungsweise bei Servern über My Products > Server aktiviert ist.

Designer Mode erlaubt eigene osquery- beziehungsweise SQL-Abfragen. Sophos Support unterstützt vorgefertigte Sophos-Queries und den Datenpfad, aber nicht die fachliche Entwicklung beliebiger Custom Queries. Dafür stehen Community und Professional Services zur Verfügung.

Die Query-Ergebnisse bieten Pivots, Enrichments und Actions. Ein verdächtiger SHA-256 kann so in eine weitere Abfrage, eine Intelix- beziehungsweise VirusTotal-Prüfung, einen Threat Graph oder Live Response übergehen.

Wer DNS-Protection-Daten abfragt, findet die Auswahl DNS Protection, das zugehörige Data-Lake-Schema und die DNS-spezifische Prüfung in Sophos DNS Protection Reports und Live Discover auswerten.

Data-Lake-Upload steuern

Der Upload ist für Endpoint Protection standardmässig aktiviert. Unter My Products > Endpoint > Policies > Data Collection and Investigation kann er für Gruppen eingeschränkt werden.

Ein Abschalten reduziert verfügbare Detections und historische Investigation. Eine Event-Collection-Ausnahme wird nur auf Anweisung von Sophos Support verwendet, weil sie Telemetrie und damit Erkennungs- oder Untersuchungsmöglichkeiten reduziert.

Nach der Aktivierung kann der Netzwerkverkehr vorübergehend steigen. Für kleine Leitungen oder sensible Segmente wird die Änderung deshalb in einer Pilotgruppe beobachtet.

Event Journals auf dem Gerät

Sophos speichert Event Journals lokal auf Windows-, macOS- und Linux-Geräten. Sie liefern Daten für Endpoint-Queries. Eine feste Aufbewahrungsdauer gibt es nicht; sie hängt von Plattform, Aktivität und konfiguriertem Speicher ab.

Unter Global Settings > Products and Services > Endpoint and Server > Event Journals kann die maximale Grösse zwischen 300 und 30'000 MB festgelegt werden. Standard sind 5'250 MB. Optional lässt sich zusätzlich ein Prozentsatz des Datenträgers begrenzen. Gilt beides, verwendet Sophos den kleineren Wert.

Die zentrale Konfiguration dieser Grössenlimits steht nur mit einer XDR-, MDR- oder MDR-Plus-Lizenz zur Verfügung. Die lokalen Event Journals existieren trotzdem auf geschützten Windows-, macOS- und Linux-Geräten; ohne passende Lizenz lassen sich ihre Grenzwerte jedoch nicht tenantweit anpassen.

Die Einstellung gilt für alle betroffenen Geräte und lässt sich nicht pro Endpoint abweichend setzen. Eine Reduktion verwirft möglicherweise vorhandene Journal-Daten und verkürzt den Untersuchungszeitraum.

Aufbewahrung und Speicherlimits

XDR speichert Data-Lake-Daten bis zu 90 Tage, EDR bis zu 30 Tage. Das optionale Paket Central Data Storage – 1 yr erweitert auf ein Jahr. Die Zeit ist ein Maximum; bei ausgeschöpftem Speicherpool werden ältere Daten früher entfernt.

Pro Gerät können höchstens 2 GB pro Tag hochgeladen werden. Ist das Limit erreicht, pausiert der Upload bis zum Reset. Unter Windows erfolgt dieser um Mitternacht lokaler Zeit, unter Linux alle 24 Stunden nach dem Start des XDR-Agenten. Nicht hochgeladene Daten werden später nicht nachgeliefert, bleiben aber für eine direkte Endpoint-Abfrage verfügbar.

Der Endpoint-Pool umfasst durchschnittlich 20 MB pro Lizenz und Tag. Bei dauerhafter Überschreitung sinkt die praktisch verfügbare Historie. Ein Tenant mit formal 90 Tagen kann daher weniger abfragbare Daten besitzen.

Verursacher eines täglichen Upload-Limits finden

Das Ereignis Data Lake uploads stopped because the daily limit reached erscheint auf Windows-Endpoints sowie Windows- oder Linux-Servern. Geplante Hydration Queries auf dem einzelnen Gerät erzeugen diese Uploads. Für XDR und MDR gilt jeweils ein Tageslimit von 2 GB pro Gerät. Nach Erreichen des Limits werden bis zum nächsten Tag keine weiteren Hydration-Query-Daten hochgeladen; dann wird das Kontingent zurückgesetzt und die geplanten Queries laufen bis zum Tagesende oder bis zum erneuten Erreichen des Limits weiter.

Um die Hydration Query mit dem grössten Upload-Volumen zu finden, meldet man sich bei Sophos Fusion (ehemals Sophos Central) an und öffnet Threat Analysis Center > Live Discover. Designer Mode einschalten, Create a new query wählen, einen Namen eingeben und Data Lake als Source setzen. Unter Show variable editor erhalten die Variablen beschreibende Namen und die Typen Device Name und Date. Als Werte dienen der betroffene Gerätename und das Untersuchungsdatum im Format YYYY-MM-DD; danach wird diese Query ausgeführt:

SELECT
  query_name,
  sum(upload_size) / (1000.0 * 1000) AS total_upload_size_bytes_mb
FROM xdr_data
WHERE date_trunc('day', ingestion_timestamp) = date (from_unixtime($$date$$))
  AND meta_hostname = '$$hostname$$'
GROUP BY query_name, date_trunc('day', ingestion_timestamp)
ORDER BY total_upload_size_bytes_mb DESC

Alternativ ordnet diese Query ohne Variablen alle hochladenden Geräte und Queries pro Tag. Das Beispieldatum wird vor der Ausführung ersetzt:

SELECT
  query_name,
  meta_hostname,
  date_trunc('day', ingestion_timestamp) AS date,
  sum(upload_size) / (1000.0 * 1000) AS total_upload_size_bytes_mb
FROM xdr_data
WHERE date_trunc('day', ingestion_timestamp) >= date '2021-09-17'
GROUP BY query_name, meta_hostname, date_trunc('day', ingestion_timestamp)
ORDER BY total_upload_size_bytes_mb DESC

Das grösste Resultat zeigt die zu untersuchende Hydration Query, nicht automatisch einen zu blockierenden Prozess. Im aktuellen Sophos Data Lake Schema Viewer wird geprüft, welche Resultatspalten diese Query befüllt; danach wird nach einer geeigneten Spalte gruppiert. Ist beispielsweise running_processes_windows_sophos am grössten, lässt sich ihr Volumen nach Prozesspfad aufschlüsseln:

SELECT
  path,
  sum(upload_size) / (1000.0 * 1000) AS total_upload_size_bytes_mb
FROM xdr_data
WHERE date_trunc('day', ingestion_timestamp) = date '$$date$$'
  AND meta_hostname = '$$hostname$$'
  AND query_name = 'running_processes_windows_sophos'
GROUP BY path, date_trunc('day', ingestion_timestamp)
ORDER BY total_upload_size_bytes_mb DESC

Im Sophos-Beispiel lieferte diese Hydration Query etwa 72 MB; ein gestarteter Prozesspfad verursachte mehr als 50 Prozent ihres täglichen Uploads. Die konkreten Prozessnamen waren ausgeblendet, weil sie umgebungsspezifisch sind. Ist die dominante Aktion bekannt, können Constraints ergänzt oder weitere befüllte Spalten wie Command Line, Benutzername oder Parent Process untersucht werden. So lässt sich eine Änderung oder Korrektur zur Reduktion des Resultatvolumens finden. Vor Änderungen oder Blockierungen werden Ursache, Legitimität und mögliche Fehlkonfiguration geprüft.

Guardrails

Sophos begrenzt Queries, um Endpoints und Tenant zu schützen:

• UI: höchstens 15 Queries pro Minute,
• geplante und API-Queries zusammen: 1'000 pro Tag und 10 pro Minute,
• Endpoint-Watchdog: Abbruch bei mehr als 30 Prozent CPU für 12 Sekunden oder mehr als 256 MB RAM,
• maximal 10 MB Antwortdaten pro Gerät und Query,
• maximal 1 MB pro Zeile,
• maximal 100'000 Zeilen aus allen antwortenden Geräten.

Ein leeres Resultat kann deshalb auch durch eine überschrittene Zeilengrösse entstehen. Telemetry unter dem Query-Ergebnis zeigt Status, System Impact und übertragenes Datenvolumen pro Gerät.

Query cancelled systematisch eingrenzen

Query cancelled ist kein HAFNIUM-spezifischer Fehler. Unter Windows kann eine Live Query wegen des Arbeitsspeicher-Watchdogs abbrechen. Im SophosLiveQueryService.log wird zuerst der Query-Name und der eigentliche Ressourcenfehler ermittelt. Danach reduziert man den abgefragten Zeitraum, beispielsweise von 15 auf 7 Tage, und testet erneut auf einem einzelnen Gerät. Bleibt der Fehler bestehen, wird der Zeitraum weiter verkürzt oder die Query fachlich enger gefiltert.

Nach einem Downgrade von Sophos Core Agent 2025.2 auf eine ältere LTS- oder FTS-Version kann SophosOsquery.exe wegen geänderter File Attestation nicht starten. Das Log enthält dann Exception whilst running LiveQueryRunner. In diesem klar abgegrenzten Fall ist ein Neustart des Geräts erforderlich; ein Umschreiben der Query behebt die Versionsgrenze nicht.

AI Search

In der Classic-Ansicht unter Threat Analysis Center > AI Search erzeugt AI Search Data-Lake-Abfragen aus natürlicher Sprache. Detections und Windows-Endpoint-Daten können ohne eigene SQL-Syntax durchsucht werden. Die Ergebnistabelle zeigt höchstens 1'000 Treffer. Diese Plattform- und Ergebnisgrenzen werden nicht auf die oben beschriebene neue Data Lake Search übertragen.

Auch hier beginnt die Suche mit wenigen Stunden oder einem Tag. Grosse Zeitbereiche können langsam werden oder abbrechen. Die generierte SQL-Abfrage wird kontrolliert, bevor das Ergebnis als vollständig bewertet wird.

Eigene Kategorien und geplante Abfragen

Wiederverwendbare Queries werden in klar benannte eigene Kategorien eingeordnet. Beschreibung, unterstützte Betriebssysteme, Datenquelle, Variablen und erwartete Ausgabe gehören zur Query-Dokumentation. Eine kopierte Abfrage wird nicht als vertrauenswürdig betrachtet, nur weil sie SQL syntaktisch korrekt ausführt. Sophos rollt eigene Kategorien schrittweise aus; die Funktion ist daher möglicherweise noch nicht in jedem Tenant sichtbar.

Geplante Queries eignen sich für wiederkehrende Hypothesen und Kontrollen und stehen nur für Data-Lake-Queries zur Verfügung. Frequenz, Tag, Enddatum und abgefragter Zeitraum werden bewusst gesetzt. Pro Admin können höchstens 100 Queries beziehungsweise Berichte dieses gemeinsamen Formats aktiv geplant sein. Zu breite oder sehr häufige Queries können zusätzlich die allgemeinen Query-Limits erreichen und grosse Mengen personenbezogener Telemetrie erzeugen.

Betrieb und Datenschutz

Data-Lake-Telemetrie und Live Discover können Prozessnamen, Kommandozeilen, Benutzer, Datei-Hashes, IP-Adressen und weitere Betriebsdaten enthalten. Rollen, Zweck, Aufbewahrung und Export werden deshalb dokumentiert.

Query-Kategorien ordnen häufig verwendete Abfragen. Das Löschen einer eigenen Kategorie löscht die enthaltenen Queries nicht; sie bleiben unter All Queries beziehungsweise weiteren Kategorien verfügbar.

Verwandte Artikel

Isolation und Live Response erklärt Sophos Endpoint isolieren und mit Live Response prüfen. Die anschliessende Bewertung von Detections und Threat Graphs behandelt Sophos Endpoint XDR: Investigation und Threat Graph.

Häufige Fragen

Für die aktuelle Security-Operations-Oberfläche erklärt Data Lake Search und Export die Schemawahl, 31-Tage-Eventfenster, getrennte Raw-Grenze und aktuelle Exporte. Die oben erhaltenen Classic-Grenzen werden nicht auf diese Oberfläche übertragen.