Lokale NDR-Daten in der Investigation Console untersuchen

Die NDR Investigation Console stellt die lokalen Daten der zugewiesenen NDR-Sensoren bereit – nicht nur jene Daten, die in den Sophos Data Lake übertragen werden. Dieses Runbook führt von einer Hypothese über Dashboard > Overview zu einer eingegrenzten ClickHouse-Abfrage unter Query. Alle beschriebenen Abfragen sind rein lesend.

Die Investigation Console ist nicht mit diesen Abfragewegen austauschbar:

Ein Resultat aus der Investigation Console ist noch kein bestätigter Incident. Übergib verdächtige Befunde gemäss dem geltenden SOC-, XDR- oder MDR-Prozess. Response-Massnahmen gehören nicht zu diesem Runbook.

Zugriff, Rollen und Untersuchungsauftrag

Verwende ein persönliches Konto mit den für den Auftrag nötigen Rechten. Das lokale Konto der Investigation Console ist von den Rollen in Sophos Fusion getrennt. Fehlt Query, ein benötigtes Schema oder eine Schaltfläche, lass das lokale Konto und die gewählte Konsole durch den zuständigen Administrator prüfen. Fehlt bereits der Einstieg aus Sophos Fusion oder ein späterer Cloud-Pivot, prüfe separat die Lizenz, die Fusion-Rolle und bei Custom Roles den Produktumfang. Erweitere keine Rolle auf Verdacht.

Vor der Untersuchung müssen diese Punkte feststehen:

• konkrete Hypothese, zum Beispiel die Kommunikation einer freigegebenen Ziel-IP über unerwartete Protokolle;
• betroffener Sensor beziehungsweise Netzwerkbereich und erwartete Quell- oder Zielsysteme;
• Start, Ende und Zeitzone des Ereignisses;
• Ticket oder Case für Notizen und die Person, die einen verdächtigen Befund übernimmt;
• zulässiger Umgang mit IP-Adressen, Hostnamen und exportierten Resultaten.

Die Konsole muss erreichbar sein und Daten von mindestens einer NDR Integration Appliance erhalten. Ein Login allein beweist weder aktuelle Sensordaten noch eine vollständige Spiegelabdeckung.

1. Zeitraum und betroffene Sensoren im Dashboard eingrenzen

Nach der Anmeldung öffnet die Konsole Dashboard > Overview. Die Seite zeigt Total Indicators, Network Traffic, Total Indicators By Severity, Total Indicators By Type, Geolocation Map und Recent flow detections. Back führt zurück zu Sophos Fusion. This Appliance zeigt Systemdetails und ist für diese Untersuchung nicht nötig.

1. Öffne unter Filters zuerst Time Range. Standard ist Last 1 hour.
2. Wähle für einen bekannten Vorfall Absolute time range und trage Start und Ende mit genügend Kontext vor und nach dem Ereignis ein. Für eine erste Übersicht kann eine quick range wie Last 7 days genügen. Bestätige mit Apply time range.
3. Beachte die Datengrenze: Die Konsole stellt nur die letzten 30 Tage bereit. Ein längerer Zeitraum liefert keine zusätzlichen lokalen Daten. Ein fehlender älterer Treffer ist deshalb keine Negativbestätigung.
4. Wähle unter Filters eine angebotene Datenbankspalte, den passenden Operator und einen Wert. Sophos nennt beispielsweise MasterProtocol, Equals und HTTP. Für numerische Spalten stehen Operatoren wie =, < oder >= zur Verfügung.
5. Füge nur Kriterien hinzu, die zur Hypothese gehören. Klicke nach jedem konfigurierten Kriterium zuerst auf Add, um es in den Filter aufzunehmen, und danach auf Apply. Prüfe, ob Diagramme und Tabelle nun den gewählten Zeitraum und die Filter widerspiegeln.
6. Verwende Save As nur für einen stabilen, verständlich benannten Filter. Das Save-Symbol überschreibt einen bestehenden Filter. Mit Clear entfernst du die aktuellen Filtereinstellungen.

Notiere die Filter sowie Zeitraum und Zeitzone. Vergleiche danach mindestens zwei unabhängige Darstellungen:

• Total Indicators zeigt IoCs der Typen DGA, IDS, EPA und SRA. Ein Klick auf einen Typ blendet ihn im Balkendiagramm ein oder aus. Wenn du den Mauszeiger über einen Balken bewegst, erscheinen Zeitpunkt und Wert.
• Network Traffic zeigt Datenrate in Mbit/s, Pakete pro Sekunde und Flows pro Sekunde. Wenn du den Mauszeiger über das Diagramm bewegst, siehst du das gesendete und empfangene Datenvolumen in Gigabyte.
• Total Indicators By Severity gruppiert nach Critical, High, Medium, Low und Info. Total Indicators By Type zeigt dieselben IoC-Typen als Donut-Diagramm.
• Geolocation Map basiert auf IP-Gruppierungen. Eine Region bietet einen Ansatzpunkt für die Untersuchung, belegt aber weder den tatsächlichen Standort noch die Bösartigkeit eines Hosts.
• Recent flow detections zeigt verdächtige Netzwerk-Flows. Prüfe die vorhandenen Flow-Details und bestätige Feldnamen und Bedeutung anhand des aktuellen Schemas, statt nur eine Diagrammspitze zu übernehmen.

Passen Dashboard und Tabelle für denselben Zeitraum nicht zusammen, verkleinere das Zeitfenster und prüfe die aktiven Filter. Starte erst danach eine freie Abfrage.

2. Mit einer vorbereiteten Abfrage beginnen

Öffne Query und bleibe zunächst im Tab Library. Verwende für dieses Runbook ausschliesslich einzelne, rein lesende SELECT-Abfragen. Für angepasste oder eigene Abfragen sind Kenntnisse in ClickHouse SQL erforderlich. Befehle, die Daten, Tabellen, Schemas, Benutzer, Berechtigungen oder Servereinstellungen verändern, sind ausgeschlossen.

Beginne mit einer vorkonfigurierten Abfrage, die zu deiner Hypothese passt:

1. Klappe in Library die passende Kategorie auf und öffne die Abfrage.
2. Lies den vollständigen Text. Prüfe Tabellen, Felder, Zeitbedingung, Gruppierung, Sortierung und eine vorhandene Resultatbegrenzung anhand deiner Hypothese.
3. Wechsle zu Schema. Klappe den Schemanamen auf und bestätige für jede verwendete Tabelle Feldnamen und Feldtypen. Übernimm keine Feldnamen aus Data-Lake- oder Appliance-Manager-Beispielen.
4. Begrenze das SELECT anhand des aktuellen Schemas auf den benötigten Zeitraum und möglichst einen einzelnen Indikator, Host, eine Quell- oder Ziel-IP beziehungsweise ein Protokoll. Ändere eine vorkonfigurierte Zeitbedingung nur, wenn Feld und ClickHouse-Syntax eindeutig sind.
5. Klicke einmal auf Run. Die Resultate erscheinen unterhalb der Abfrage. Wiederholtes Klicken beschleunigt den Lauf nicht und erschwert die Zuordnung in History.
6. Erweitere den Untersuchungsrahmen erst, wenn die erste Ausführung erfolgreich und das Resultat plausibel sowie überschaubar ist.

Variablen und Beispiele sicher verwenden

Enthält eine vorbereitete Abfrage eine Variable wie @DestIp, erscheint links daneben ein Eingabefeld. Protocols For Destination IP ist ein dokumentiertes Beispiel. Verwende dieses Feld und ändere nicht gleichzeitig die Variablenersetzung, Tabelle und Filterlogik.

Nutze für einen reinen Syntax- oder Ablaufcheck nur eine dafür freigegebene Adresse. 192.0.2.10 stammt aus einem für Dokumentation reservierten Netz und dient hier ausschliesslich als Formatbeispiel. Die Adresse liefert nicht zwingend Resultate und ist kein produktiver Indikator. Echte IP-Adressen, Domains und Hostnamen stammen aus dem autorisierten Ticket, nicht aus beliebigen Beispielen.

Beim Speichern kann die Konsole den Variablenwert in den Abfragetext übernehmen. Aus @DestIp wird dann beispielsweise die eingesetzte Adresse. Prüfe deshalb den Text vor dem nächsten Lauf. Speichere eine angepasste Variante über Save As unter einem Namen, der Zweck und Umfang beschreibt, und überschreibe nicht die vorkonfigurierte Ausgangsabfrage. Da gespeicherte Abfragen vertrauliche Indikatoren enthalten können, gilt die lokale Datenklassifizierung.

Um eine eigene Kategorie anzulegen, klicke oben rechts in Library auf das Plus-Symbol, gib Name und Beschreibung ein und bestätige mit Create. Für eine neue Abfrage gib den geprüften SELECT-Text rechts ein, teste ihn mit Run und wähle Save As. Wähle die Kategorie, gib einen Namen ein und bestätige mit Create. Speichere nur wiederverwendbare, geprüfte Abfragen.

Die Konsole teilt Ressourcen mit der lokalen Datenspeicherung und Darstellung. Filtere deshalb früh nach Zeit und einem selektiven Feld. Begrenze Resultate nach einer bereits in Library verwendeten und für ClickHouse geprüften Methode; entferne beim ersten Test keine vorhandene Begrenzung. Prüfe vor JOIN, Unterabfragen, breiten Gruppierungen oder Sortierungen das aktuelle Schema und teste mit einem kleinen Zeitfenster. Kopiere keine Data-Lake-SQL-Abfrage in die Konsole. Lies Abfragen aus Tickets, Chats oder öffentlichen Beispielen vor der Ausführung vollständig und gleiche sie mit Schema ab.

3. Resultate validieren

Eine erfolgreich ausgeführte Abfrage ist nicht automatisch inhaltlich korrekt. Prüfe das Resultat in dieser Reihenfolge:

1. Untersuchungsrahmen: Decken Zeitfenster, Zeitzone, betroffene Sensoren und Filter genau den Auftrag ab? Liegt das Ereignis innerhalb der lokal verfügbaren 30 Tage?
2. Schema: Stimmen Feldtypen und Bedeutung mit Schema überein? Prüfe insbesondere, ob IP-Adressen, Zeitwerte und Anzahlen korrekt interpretiert werden.
3. Kontrolltreffer: Suche nach einem bekannten, erwarteten Flow im gleichen engen Zeitraum. Fehlt auch dieser, ist ein leeres Resultat nicht belastbar.
4. Dashboard-Abgleich: Stimmen Grössenordnung und zeitlicher Verlauf mit Network Traffic, IoCs oder Recent flow detections überein? Dashboard-Aggregate und einzelne Zeilen müssen nicht identisch sein, Widersprüche brauchen aber eine Erklärung.
5. Gegenprobe: Entferne genau einen engen Filter oder verschiebe das Zeitfenster kontrolliert. Ein plausibler Unterschied zeigt, dass die Bedingung wirkt. Ändere nie mehrere Bedingungen gleichzeitig.
6. Dokumentation: Halte Name oder Text der Abfrage, Variablen, Zeitraum mit Zeitzone, Ausführungszeit, Resultatanzahl und relevante Zeilen im Ticket fest. Behandle Resultate als potenziell sensible Netzwerkdaten.

Öffne danach History. Dort zeigt die Konsole den Benutzertyp, Datum und Uhrzeit, die Resultatanzahl sowie successful oder failed. Ordne den Eintrag deiner Ausführung zu. History belegt die Ausführung, aber weder Vollständigkeit noch Richtigkeit der Abfrage.

Fehler eingrenzen und sicher zurückkehren

Dashboard ist leer

Prüfe Time Range, aktive Saved Filters und Filters. Wähle einen kurzen Zeitraum mit erwartetem Netzwerkverkehr und entferne die Filter mit Clear. Bleibt auch Network Traffic leer, liegt das Problem nicht an einer freien Abfrage. Kontrolliere, ob die richtige Konsole geöffnet ist und ob der erwartete Sensor beziehungsweise die zuständige Appliance Daten liefert. Ein grüner Appliance-Status beweist keine vollständige Spiegelabdeckung. Übergib Zeitraum, erwarteten Flow, Konsole und betroffenen Sensor an den Betriebs- oder Supportprozess, statt den Zeitraum über 30 Tage auszudehnen.

Abfrage liefert null Zeilen

Bestätige Zeitraum und Zeitzone. Prüfe in Schema, ob Tabelle, Feldname und Typ aktuell sind. Entferne danach genau den engsten fachlichen Filter und führe die Abfrage einmal erneut aus. Teste ausserdem einen bekannten erwarteten Wert im selben Zeitfenster. Liefert auch eine unveränderte vorkonfigurierte Abfrage keine erwarteten Daten, prüfe Datenpfad und betroffene Sensoren. Das leere Resultat beweist nicht, dass die Aktivität fehlt.

Abfrage ist failed

Suche den passenden Eintrag in History und dokumentiere Status, Abfragetext und Ausführungszeit in deinen Arbeitsnotizen. Kontrolliere Syntax, Feldnamen und Feldtypen anhand von Schema. Öffne die letzte unveränderte, zuvor funktionierende Abfrage aus Library, begrenze deren SELECT auf den kleinsten sinnvollen Zeitraum und setze nur einen validierten Variablenwert. Starte genau einen neuen Lauf. Bleibt die vorkonfigurierte Abfrage failed, dokumentiere den Fehler und eskaliere ihn. Umgehe ihn nicht mit Schreibbefehlen, Schemaänderungen oder Servereinstellungen.

Abfrage läuft ungewöhnlich lange oder belastet die Konsole

Klicke Run nicht erneut. Notiere Startzeit, Benutzer und den Namen der Abfrage. Starte keine weitere breite Abfrage. Prüfe nach Abschluss in History, ob der Lauf successful oder failed war und wie viele Resultate entstanden. Bleibt die Oberfläche langsam, beende die Abfragearbeit und übergib die Beobachtung an den Betrieb der Konsole. Ein Neustart oder Shutdown gehört nicht zu diesem Runbook.

Zu einer funktionierenden Query zurückkehren

1. Stoppe weitere Ausführungen derselben Variante. Starte weder hektische Wiederholungen noch eine weitere breite Kontrollabfrage.
2. Kopiere, sofern die Oberfläche reagiert, den Abfragetext und dokumentiere Startzeit, Filter, Variablen und den zugehörigen History-Eintrag. Speichere die fehlerhafte Variante nicht als neue Standardabfrage.
3. Öffne die ursprüngliche vorkonfigurierte Abfrage erneut aus Library. Prüfe, dass keine eingesetzten Variablenwerte oder ungespeicherten Änderungen übernommen wurden.
4. Begrenze das SELECT anhand des bestätigten Schemas auf einen kurzen Zeitraum, einen validierten Wert und eine kleine Resultatmenge. Prüfe Tabellen und Felder erneut unter Schema.
5. Führe einen einzelnen, bereits erfolgreich ausgeführten Lesetest aus. Kontrolliere Resultat und History.
6. Scheitert auch dieser Test oder bleibt die Konsole beeinträchtigt, beende die Untersuchung und eskaliere mit den gesicherten Informationen. Verwende keine Datenbank-Reparatur-, Lösch- oder Teardown-Befehle.

Abschluss und Übergabe

Dokumentiere zum Abschluss die Hypothese, die verwendete Konsole, die betroffenen Sensoren, das Zeitfenster mit Zeitzone, die Dashboard-Filter, die ausgeführte Abfrage, Variablen, History-Status und Resultatanzahl. Übergib positive Befunde über den bestehenden SOC-, XDR- oder MDR-Prozess. Ein negatives Resultat bedeutet nur, dass im dokumentierten lokalen Untersuchungsrahmen nichts gefunden wurde. Es beweist nicht, dass die Aktivität im gesamten Netzwerk fehlt.

Entferne sensible Beispielwerte aus einer nur vorübergehend benötigten Abfragedefinition oder kläre deren zulässige Aufbewahrung mit der verantwortlichen Person für Library.

Häufige Fragen