Undersök lokala NDR-data i Investigation Console

NDR Investigation Console tillhandahåller lokala data från tilldelade NDR-sensorer – inte bara de data som överförs till Sophos Data Lake. Den här runbook-artikeln leder från en hypotes via Dashboard > Overview till en avgränsad ClickHouse-fråga under Query. Samtliga frågor som beskrivs är skrivskyddade.

Investigation Console kan inte ersätta följande frågevägar:

Ett resultat från Investigation Console är ännu ingen bekräftad incident. Överlämna misstänkta fynd enligt gällande SOC-, XDR- eller MDR-process. Responsåtgärder ingår inte i den här runbook-artikeln.

Åtkomst, roller och undersökningsuppdrag

Använd ett personligt konto med de rättigheter som uppdraget kräver. Det lokala kontot i Investigation Console är separat från rollerna i Sophos Fusion. Om Query, ett nödvändigt schema eller en knapp saknas ska ansvarig administratör kontrollera det lokala kontot och vald konsol. Om redan ingången från Sophos Fusion eller en senare molnpivot saknas kontrollerar du licensen, Fusion-rollen och produktomfattningen för eventuella Custom Roles separat. Utöka ingen roll på måfå.

Följande måste vara fastställt före undersökningen:

• en konkret hypotes, exempelvis att en godkänd mål-IP kommunicerar över oväntade protokoll;
• berörd sensor eller nätverksdel samt förväntade käll- eller målsystem;
• händelsens start, slut och tidszon;
• ärende eller Case för anteckningar och vem som tar över ett misstänkt fynd;
• tillåten hantering av IP-adresser, värdnamn och exporterade resultat.

Konsolen måste vara nåbar och ta emot data från minst en NDR Integration Appliance. En lyckad inloggning bevisar varken att sensordata är aktuella eller att speglingstäckningen är fullständig.

1. Avgränsa tidsperiod och berörda sensorer på instrumentpanelen

Efter inloggning öppnar konsolen Dashboard > Overview. Sidan visar Total Indicators, Network Traffic, Total Indicators By Severity, Total Indicators By Type, Geolocation Map och Recent flow detections. Back återgår till Sophos Fusion. This Appliance visar systeminformation och behövs inte för den här undersökningen.

1. Öppna först Time Range under Filters. Standardvärdet är Last 1 hour.
2. Välj Absolute time range för en känd händelse och ange start och slut med tillräckligt sammanhang före och efter händelsen. För en första överblick kan ett quick range som Last 7 days räcka. Bekräfta med Apply time range.
3. Beakta datagränsen: konsolen tillhandahåller endast de senaste 30 dagarna. Ett längre intervall ger inga ytterligare lokala data. Att en äldre träff saknas är därför ingen negativ bekräftelse.
4. Välj under Filters en tillgänglig databaskolumn, lämplig operator och ett värde. Sophos anger exempelvis MasterProtocol, Equals och HTTP. För numeriska kolumner finns operatorer som =, < och >=.
5. Lägg endast till kriterier som hör till hypotesen. Klicka efter varje konfigurerat kriterium först på Add för att lägga till filtret och därefter på Apply. Kontrollera att diagram och tabell återspeglar vald period och valda filter.
6. Använd Save As endast för ett stabilt filter med ett begripligt namn. Spara-symbolen skriver över ett befintligt filter. Clear tar bort de aktuella filterinställningarna.

Anteckna filtren samt period och tidszon. Jämför därefter minst två oberoende vyer:

• Total Indicators visar IoC:er av typerna DGA, IDS, EPA och SRA. Ett klick på en typ visar eller döljer den i stapeldiagrammet. Håll pekaren över en stapel för tidpunkt och värde.
• Network Traffic visar datahastighet i Mbit/s, paket per sekund och flöden per sekund. När pekaren hålls över diagrammet visas skickad och mottagen datamängd i gigabyte.
• Total Indicators By Severity grupperar efter Critical, High, Medium, Low och Info. Total Indicators By Type visar samma IoC-typer i ett ringdiagram.
• Geolocation Map bygger på IP-grupperingar. En region ger en utgångspunkt för undersökningen men bevisar varken en värds faktiska plats eller att den är skadlig.
• Recent flow detections visar misstänkta nätverksflöden. Kontrollera tillgängliga flödesdetaljer och bekräfta fältnamn och innebörd mot aktuellt schema i stället för att enbart utgå från en topp i ett diagram.

Om instrumentpanelen och tabellen inte stämmer överens för samma period minskar du tidsfönstret och kontrollerar aktiva filter. Starta en fri fråga först därefter.

2. Börja med en förberedd fråga

Öppna Query och stanna först på fliken Library. Använd i den här runbook-artikeln endast enskilda, skrivskyddade SELECT-frågor. Anpassade eller egna frågor kräver kunskaper i ClickHouse SQL. Kommandon som ändrar data, tabeller, scheman, användare, behörigheter eller serverinställningar är uteslutna.

Börja med en förkonfigurerad fråga som passar hypotesen:

1. Fäll ut lämplig kategori under Library och öppna frågan.
2. Läs hela texten. Kontrollera tabeller, fält, tidsvillkor, gruppering, sortering och eventuell resultatbegränsning mot hypotesen.
3. Växla till Schema. Fäll ut schemanamnet och bekräfta fältnamn och fälttyper för varje tabell som används. Hämta inte fältnamn från exempel för Data Lake eller Appliance Manager.
4. Begränsa SELECT med hjälp av aktuellt schema till nödvändig period och om möjligt en enskild indikator, värd, käll- eller mål-IP eller ett protokoll. Ändra endast ett förkonfigurerat tidsvillkor om fältet och ClickHouse-syntaxen är entydiga.
5. Klicka en gång på Run. Resultaten visas under frågan. Upprepade klick påskyndar inte körningen och gör det svårare att koppla rätt post i History.
6. Utöka undersökningsomfattningen först när den första körningen lyckats och resultatet är rimligt och överskådligt.

Använd variabler och exempel säkert

Om en förberedd fråga innehåller en variabel som @DestIp visas ett inmatningsfält till vänster. Protocols For Destination IP är ett dokumenterat exempel. Använd fältet och ändra inte samtidigt variabelersättningen, tabellen och filterlogiken.

Använd endast en adress som har godkänts för ett rent syntax- eller flödestest. 192.0.2.10 kommer från ett nät som är reserverat för dokumentation och används här endast som formatexempel. Adressen ger inte nödvändigtvis något resultat och är ingen produktionsindikator. Verkliga IP-adresser, domäner och värdnamn ska komma från det godkända ärendet, inte från godtyckliga exempel.

När en fråga sparas kan konsolen skriva in variabelvärdet i frågetexten. @DestIp kan exempelvis ersättas med den angivna adressen. Kontrollera därför texten före nästa körning. Spara en anpassad variant med Save As under ett namn som beskriver syfte och omfattning; skriv inte över den förkonfigurerade ursprungsfrågan. Eftersom sparade frågor kan innehålla känsliga indikatorer gäller den lokala dataklassificeringen.

Skapa en egen kategori genom att klicka på plus-symbolen uppe till höger under Library, ange namn och beskrivning och bekräfta med Create. För en ny fråga skriver du den kontrollerade SELECT-texten till höger, testar med Run och väljer Save As. Välj kategori, ange ett namn och bekräfta med Create. Spara endast återanvändbara, verifierade frågor.

Konsolen delar resurser mellan lokal datalagring och visning. Filtrera därför tidigt på tid och ett selektivt fält. Begränsa resultatet med en metod som redan används i Library och har verifierats för ClickHouse; ta inte bort en befintlig begränsning i det första testet. Kontrollera aktuellt Schema före JOIN, underfrågor, breda grupperingar eller sorteringar och testa med ett litet tidsfönster. Kopiera ingen Data Lake SQL-fråga till konsolen. Läs frågor från ärenden, chattar eller offentliga exempel fullständigt före körning och jämför dem med Schema.

3. Validera resultat

En fråga som körts utan fel är inte automatiskt korrekt i sak. Kontrollera resultatet i denna ordning:

1. Undersökningsomfattning: Täcker tidsfönster, tidszon, berörda sensorer och filter exakt uppdraget? Ligger händelsen inom de 30 dagar som finns lokalt?
2. Schema: Stämmer fälttyper och innebörd med Schema? Kontrollera särskilt att IP-adresser, tidsvärden och antal tolkas korrekt.
3. Kontrollträff: Sök efter ett känt, förväntat flöde under samma snäva period. Om även det saknas är ett tomt resultat inte tillförlitligt.
4. Jämförelse med instrumentpanelen: Stämmer storleksordning och tidsförlopp med Network Traffic, IoC:er eller Recent flow detections? Aggregeringar och enskilda rader behöver inte vara identiska, men motsägelser kräver en förklaring.
5. Motprov: Ta bort exakt ett snävt filter eller flytta tidsfönstret kontrollerat. En rimlig skillnad visar att villkoret fungerar. Ändra aldrig flera villkor samtidigt.
6. Dokumentation: Spara frågans namn eller text, variabler, period med tidszon, körningstid, antal resultat och relevanta rader i ärendet. Behandla resultaten som potentiellt känsliga nätverksdata.

Öppna därefter History. Där visas användartyp, datum och tid, antal resultat samt successful eller failed. Koppla posten till din körning. History styrker att frågan kördes, men varken dess fullständighet eller riktighet.

Avgränsa fel och återgå säkert

Instrumentpanelen är tom

Kontrollera Time Range, aktiva Saved Filters och Filters. Välj en kort period med förväntad nätverkstrafik och ta bort filtren med Clear. Om även Network Traffic förblir tom ligger problemet inte i en fri fråga. Kontrollera att rätt konsol är öppen och att förväntad sensor eller ansvarig appliance levererar data. Grön appliance-status bevisar inte fullständig speglingstäckning. Överlämna period, förväntat flöde, konsol och berörd sensor till drift- eller supportprocessen i stället för att utöka perioden utöver 30 dagar.

Frågan ger noll rader

Bekräfta period och tidszon. Kontrollera under Schema att tabell, fältnamn och typ är aktuella. Ta därefter bort exakt det snävaste sakfiltret och kör frågan en gång till. Testa även ett känt, förväntat värde i samma tidsfönster. Om en oförändrad förkonfigurerad fråga inte heller ger förväntade data kontrollerar du datavägen och berörda sensorer. Ett tomt resultat bevisar inte att aktiviteten saknas.

Frågan är failed

Leta upp rätt post i History och dokumentera status, frågetext och körningstid i arbetsanteckningarna. Kontrollera syntax, fältnamn och fälttyper mot Schema. Öppna den senaste oförändrade fråga från Library som tidigare fungerade, begränsa dess SELECT till minsta rimliga period och ange endast ett validerat variabelvärde. Starta exakt en ny körning. Om den förkonfigurerade frågan fortfarande är failed dokumenterar och eskalerar du felet. Försök inte kringgå det med skrivkommandon, schemaändringar eller serverinställningar.

Frågan kör ovanligt länge eller belastar konsolen

Klicka inte på Run igen. Anteckna starttid, användare och frågans namn. Starta ingen ytterligare bred fråga. Kontrollera efter avslut i History om körningen var successful eller failed och hur många resultat som skapades. Om gränssnittet förblir långsamt avslutar du frågearbetet och överlämnar observationen till konsoldriften. Omstart eller Shutdown ingår inte i den här runbook-artikeln.

Återgå till en fungerande Query

1. Stoppa ytterligare körningar av samma variant. Starta varken upprepade försök i hast eller en ny bred kontrollfråga.
2. Om gränssnittet svarar kopierar du frågetexten och dokumenterar starttid, filter, variabler och motsvarande post i History. Spara inte den felaktiga varianten som ny standardfråga.
3. Öppna den ursprungliga förkonfigurerade frågan på nytt från Library. Kontrollera att inga införda variabelvärden eller osparade ändringar har följt med.
4. Begränsa SELECT utifrån bekräftat schema till en kort period, ett validerat värde och en liten resultatmängd. Kontrollera tabeller och fält på nytt under Schema.
5. Kör ett enda skrivskyddat test som redan har lyckats. Kontrollera resultat och History.
6. Om även testet misslyckas eller konsolen förblir påverkad avslutar du undersökningen och eskalerar med den sparade informationen. Använd inga kommandon för databasreparation, radering eller nedmontering.

Avslut och överlämning

Dokumentera slutligen hypotes, använd konsol, berörda sensorer, tidsfönster med tidszon, instrumentpanelsfilter, körd fråga, variabler, status i History och antal resultat. Överlämna positiva fynd genom den befintliga SOC-, XDR- eller MDR-processen. Ett negativt resultat betyder endast att inget hittades inom den dokumenterade lokala undersökningsomfattningen. Det bevisar inte att aktiviteten saknas i hela nätverket.

Ta bort känsliga exempelvärden ur en frågedefinition som bara behövdes tillfälligt eller klarlägg tillåten lagring med den som ansvarar för Library.

Vanliga frågor