Sophos XDR Data Lake Search und Exporte prüfen

Data Lake Search unter Security Operations > Data Lake Search durchsucht die im Tenant aufgenommenen Ereignisse und Detections. Vor der ersten Abfrage werden die Untersuchungsfrage, die benötigte Quelle und das Zeitfenster festgelegt. Ein leeres Ergebnis ist erst dann aussagekräftig, wenn Datenaufnahme, Schema und Filter geprüft sind.

Diese Anleitung beschreibt die aktuelle Security-Operations-Oberfläche. Live Discover und Live Endpoint Search unterscheiden historische Daten von einer direkten Geräteabfrage und erhalten die abweichenden Classic-Verfahren. Die QL-Beispiele werden an das eigene Schema, Zeitfenster und die tatsächlichen Quellwerte angepasst.

Datenquelle und Suchmethode wählen

Vor der Suche wird unter Integrations > Configured Data Sources geprüft, dass die erwartete Quelle aktuelle Daten liefert und dem benötigten Schema zugeordnet wird. Eine grüne Verbindung allein genügt nicht. Integrationen abnehmen erklärt diesen Unterschied.

Data Lake Search bietet AI Search, Query Builder und Query Editor. AI Search erzeugt aus einer natürlichsprachlichen Frage einen Vorschlag. Dessen Schema, Bedingungen und Zeitraum werden vor der fachlichen Nutzung kontrolliert; die KI ersetzt keine Quellenabnahme. Query Builder bildet Bedingungen visuell ab, Query Editor verwendet die Advanced Search Query Language. Über das Pin-Symbol kann die bevorzugte Methode als Standard gewählt werden.

Man beginnt mit einer kleinen bekannten Quelle und einem kurzen Zeitraum. In Query Builder wird zuerst zwischen Detections und Events gewählt, bei Events anschliessend der Ereignistyp. Im Query Editor legt FROM das Schema fest. Detections und Events werden nicht in derselben Query vermischt.

Schema Library und logische Felder verstehen

Ein Schema ist die strukturierte Ereigniskategorie, beispielsweise auth, process oder netflow. Die Schema Library zeigt Schemas, suchbare Felder und Logical Types. Nicht jedes vom Parser befüllte Feld muss in der Suche verfügbar sein. Deshalb wird ein Mapping anhand tatsächlich suchbarer Felder geprüft, nicht nur anhand eines ähnlich benannten Herstellerfelds.

Logische Felder mit @, etwa @ip oder @user, fassen passende Felder verschiedener Schemas zusammen. Bei einer Mehrschema-Suche werden Ergebnisse je Schema zusammengeführt; eine Bedingung wirkt nur auf Schemas, die das Feld besitzen. Sie ist kein relationaler Join. Ein Filter auf Ereignisfelder in einer Detection-Suche benötigt das entsprechende Schemapräfix, etwa process.commandline.

Die folgende harmlose Vorlage zeigt eine kurze Suche im Authentifizierungsschema. example-user ist ein frei gewählter Platzhalter und muss durch eine zur Untersuchung freigegebene Identität ersetzt werden:

FROM auth WHERE @user CONTAINS 'example-user' earliest=-1h

CONTAINS ist eine Teilstringsuche, keine Zusage eines exakten Identitätstreffers. Wenn ein eindeutiger Kontonachweis benötigt wird, werden das tatsächliche Identitätsfeld, Vergleichsoperator und Quelle kontrolliert. Gleichnamige lokale und Domainkonten dürfen nicht ungeprüft zusammengezählt werden.

Zeitraum, Retention und Raw-Grenze auseinanderhalten

Für normalisierte Events erlaubt die Schemahilfe vom 2. Oktober 2026 ein Zeitfenster von höchstens 31 Tagen je Abfrage. Das Startdatum darf innerhalb tatsächlich aufbewahrter Daten liegen. Für längere Untersuchungen werden aufeinander abgestimmte Fenster mit dokumentierten Grenzen verwendet. Detections können für einen beliebigen Zeitraum gesucht werden; ihre vorhandene Historie und Berechtigungen bleiben trotzdem zu prüfen.

Diese 31 Tage sind keine Aufbewahrungsdauer. Next-Gen SIEM kann längere Retention bereitstellen, macht daraus aber keine unbegrenzt grosse Einzelabfrage.

Für @raw und original_data beschreibt der SQL-zu-QL-Leitfaden vom 15. September 2026 einen separaten Zugriff auf die letzten 20 Tage. Liegt die Raw-Anfrage ausserhalb dieses Umfangs, wird sie zurückgewiesen und nicht still gekürzt. Die ältere Query-Language-Seite nennt zusätzlich 20-Tage-Schritte. Daraus wird keine Zusage abgeleitet, dass ältere Raw-Daten nach Aufteilung verfügbar wären. Für eine historische Raw-Anforderung ausserhalb des dokumentierten Umfangs muss vor der Nachweiszusage ein bestätigter Produktweg vorliegen. Das ist weder eine allgemeine 20-Tage-Retention noch ein Beleg physischer Datenlöschung.

QL-Grenzen und Vergleichsfallen berücksichtigen

Die Query-Language-Hilfe nennt 100 gleichzeitig laufende Query Units pro Tenant und eine Scan-Grenze von 10 TB je Query. Eine Suche kann mehrere Query Units belegen; hundert Benutzer erhalten nicht jeweils hundert parallele Suchen. Breite logische Suchen und grosse Zeiträume werden deshalb eingegrenzt. Eine fehlgeschlagene oder begrenzte Suche darf nicht als null Ereignisse ausgewertet werden.

Reguläre Ausdrücke für Events verwenden eine Java-kompatible Engine, Detection-Suchen eine Lucene-basierte Engine. Ein gespeicherter Ausdruck wird deshalb nicht blind zwischen beiden Wegen kopiert. Hostname-Auflösung ist zusätzlich ein Sonderfall mit case-sensitivem Literalvergleich und begrenzten Operatoren.

Bei Arrays können Bedingungen auf unterschiedliche Einträge desselben Ereignisses passen. Ein Match auf Headername und Headerwert beweist beispielsweise nicht, dass beide zum selben Header-Eintrag gehören. Wenn diese Zuordnung für den Befund entscheidend ist, müssen die zugrunde liegenden Daten einzeln geprüft werden.

Ergebnisse prüfen und Suche speichern

Nach Auswahl des Zeitraums wird mit Search beziehungsweise Shift + Enter ausgeführt. Full Screen vergrössert die Ergebnissicht. Über das Menü eines Spaltenkopfs lassen sich Felder filtern, ein-/ausblenden, anheften oder skalieren; Spalten werden per Drag-and-drop angeordnet.

Für einen belastbaren Befund werden repräsentative Zeilen auf richtigen Tenant, Quelle, Ereigniszeit mit Zeitzone, Identität und Aktion geprüft. Die Zahl sichtbarer Zeilen oder eine positive Detection ersetzt diese Feldkontrolle nicht. Bei einem Quelltest wird das Ereignis mit dem Originalnachweis verglichen.

Bei AI Search und Query Editor öffnet Save Query den Speicherdialog. Im Query Builder wählt man zunächst Save Search. Danach werden Name, Kategorie und optionale Beschreibung erfasst und mit Save Query gespeichert; Bookmark this Query nimmt sie in die eigenen Lesezeichen auf. Ein verständlicher Name benennt Zweck und Quelle, ohne Secrets oder personenbezogene Rohdaten aufzunehmen. Suchen werden in der Tenant-Suchhistorie erfasst. Ein gespeicherter Query-Text ist kein dauerhaft gespeichertes Ergebnisarchiv.

Exporte vollständig und rechtzeitig sichern

Im Actions-Menü über der Ergebnistabelle wird der vollständige Ergebnissatz oder eine bewusst ausgewählte Teilmenge exportiert. Danach öffnet man Security Operations > Data Exports. Der dortige Status ist getrennt von der erfolgreichen Suchausführung zu prüfen:

• Processing: Export läuft noch.
• Completed: Datei kann heruntergeladen werden.
• Errored: Fehler prüfen und bei geeigneter Ursache über das Drei-Punkte-Menü Retry verwenden.
• Cancelled: Export wurde abgebrochen, kein vollständiger Nachweis.

Exportdateien sind auf 100'000 Zeilen je Datei begrenzt. Für grössere Mengen werden Zeitfenster, Filter oder Suchparameter sinnvoll aufgeteilt und mehrere Requests dokumentiert. Anzahl und Abdeckung der Teildateien müssen zusammen zum gewünschten Untersuchungsumfang passen. Eine heruntergeladene Datei ist kein Vollständigkeitsbeweis für eine grössere Suche.

File Expiration zeigt den Ablauf der Datei. Ein Export wird vor diesem Zeitpunkt über Download in den freigegebenen Ablageort gesichert. Es wird keine pauschale feste TTL aus einem Beispiel erfunden. Cancel beendet einen laufenden Export; Delete löscht den Export unwiederbringlich. Keine dieser Aktionen ist eine Bestätigung, dass die ursprüngliche Telemetrie aus dem Data Lake gelöscht wurde.

Zum Exportnachweis gehören Query, explizite Zeitgrenzen und Zeitzone, ausgewählte Quellen/Schemas, Exportumfang, Status, Zeilenzahl und Aufbewahrung im Zielsystem. Zugang und Weitergabe sensibler Telemetrie werden vorher geregelt. Für einen eigenen vollständig paginierten Client erklärt das Search-GraphQL-Runbook Search-URN, Teilausfälle, Cursor und Ablaufzeit.

Unerwartete Resultate eingrenzen

Fehlen Treffer, werden zuerst Tenant, Datenquelle, Schema, Zeitfenster und Bedingungen kontrolliert. Bei einem Raw-Fehler wird nicht durch immer neue Zeitfenster eine ältere Verfügbarkeit unterstellt. Bei einer Scan-/Parallelitätsgrenze reduziert man die Anfrage und dokumentiert die Aufteilung, statt eine Serie unkontrollierter Wiederholungen zu starten.

Stimmt die Suchvorschau, aber eine laufende Detection- oder Suppression-Regel reagiert anders, ist der aktuelle Regelbetrieb zu prüfen. Streaming- und Suppression-Engines verarbeiten Daten zu anderen Zeitpunkten und mit anderen Grenzen als eine historische Suche.