Sophos Switch: fråga efter enhets- och klientdata med Live Discover

Med Live Discover kan du fråga efter telemetri från Sophos Switch-enheter som hanteras i Sophos Fusion. Data Lake-data kan till exempel hjälpa dig att undersöka enheter som var anslutna till en viss switch. Dessa data är dock inte en realtidsvy över switchens aktuella tillstånd.

Förutsättningar

Du behöver minst en Sophos Switch som hanteras i Sophos Fusion samt åtkomst till rätt klientorganisation och till Threat Analysis Center > Live Discover. Live Discover kräver en licens för Sophos EDR, XDR eller MDR. Dokumentationen anger därutöver varken ett särskilt Switch-licenspaket eller en viss administratörsroll. Om Live Discover, Switch eller en redigeringsfunktion saknas bör därför licenstilldelningen, dina åtkomsträttigheter och funktionens aktivering i den berörda klientorganisationen kontrolleras.

Bestäm undersökningens mål i förväg. Lämpliga referenspunkter är exempelvis switch-ID, enhetsnamn, serienummer, klientens MAC-adress, port, VLAN och tidsperiod. Du behöver bara Designer Mode om du ska redigera eller skapa en fråga.

Fråga efter switchdata

Börja med en inbyggd switchfråga. Då får du först ett jämförelseresultat och behöver bara byta till designern om den befintliga frågan inte besvarar din fråga.

1. Öppna Threat Analysis Center > Live Discover > Switch i Sophos Fusion.
2. Välj en inbyggd Data Lake-fråga för Sophos Switch. Kontrollera dess syfte, den synliga definitionen och de parametrar som krävs.
3. Ange undersökningsperioden under Select a Time Period, om alternativet erbjuds, och kör frågan.
4. Tolka resultaten med hjälp av switchens identitet, type_of_data och tidsfälten. Jämför en känd switch eller testklient med uppgifterna i switchhanteringen.
5. Om den inbyggda frågan räcker dokumenterar du frågan, parametrarna, tidsfönstret och resultatet. Annars aktiverar du Designer Mode och väljer ett av följande alternativ:
   • Anpassa en befintlig fråga: välj frågan under Query och klicka på Edit. Spara den ursprungliga definitionen innan du ändrar den.
   • Skapa en ny fråga: klicka på Create new query under Query och välj Data Lake som Source.
6. Öppna Schema längst upp till höger i SQL-dialogrutan. Schema Viewer öppnas på en ny flik. Välj NSG Cswitch > nsg_cswitch_data och kontrollera tillgängliga kolumner och datatyper.
7. Använd endast tabeller, fält och värden som visas i aktuell Schema Viewer eller i den inbyggda frågan. Ändra endast en sammanhängande del åt gången, till exempel fältvalet eller filtret för en känd switch.
8. Kör först den anpassade frågan med en snävt avgränsad, känd switch eller klient. Jämför resultatet med den oförändrade inbyggda frågan och kända inventerings- eller anslutningsdata.

När du söker efter klienter till en viss switch ska du identifiera målenheten entydigt med device_id eller serienumret. Utvärdera sedan klientens MAC-adress, device_port, client_vlan, anslutningsstatus och tidsfält tillsammans. En sådan avgränsning förhindrar sammanblandningar, men bevisar ännu inte att klientlistan är fullständig. Även tidsperioden och is_full_set måste stämma.

Välja tidsfönster

Select a Time Period är valfritt för Data Lake-frågor. Om du inte gör något eget val används de senaste 7 dagarna. En enskild fråga kan omfatta högst 30 dagar.

För längre undersökningar kör du flera frågor med separata tidsfönster. För 90 dagar anger Sophos exempelvis 0–30, 31–60 och 61–90 dagar. Dokumentera varje fönster separat och behåll samma switch, datatyp och övriga filter vid jämförelsen.

Fält i switchschemat

Schemat omfattar switchidentitet, anslutna klienter och loggar. type_of_data anger typen av data som skickats, exempelvis klient- eller loggdata. Därför innehåller inte varje rad alla klient- och loggfält samtidigt.

Värden för status, undertyp och allvarlighetsgrad kan variera beroende på visade data. Använd den exakta stavningen och betydelsen från det aktuella schemat och frågeresultatet.

Tolka resultaten rätt

En obearbetad Data Lake-rad är till att börja med ett frågeresultat. type_of_data och de ifyllda fälten visar om den innehåller klient- eller loggdata. Om SQL-frågan slår ihop flera poster är resultatraden en beräknad sammanfattning och inte en enskild nätverkshändelse. Överför därför inte betydelsen av timestamp till ett aggregat utan att kontrollera den.

Identitet och klientorganisation

device_id är switchens unika ID. Jämför även minst en annan referenspunkt, till exempel device_serial_id, device_name, device_model eller device_ip, med målenheten. Namn och IP-adresser kan ändras eller återanvändas. customer_id kopplar data till klientorganisationen och är inte ett switch-, serie- eller klient-ID.

Händelse- och inläsningstid

• timestamp anger tidpunkten då händelsen genererades.
• client_event_timestamp anger tidpunkten då enheten anslöt.
• ingestion_timestamp anger inläsningstiden i epoch-sekunder.
• ingest_date är inläsningsdatumet.

En senare inläsning innebär inte automatiskt en senare nätverkshändelse. Kontrollera även epoch-konverteringen och tidszonen i den frågemiljö som används för tidsserier.

Fullständiga och inkrementella data

is_full_set anger om en leverans är fullständig eller inkrementell. Behandla inte en inkrementell datauppsättning som en fullständig klientinventering. Inte ens en leverans som är markerad som fullständig garanterar i sig att varje förväntad klient visas under den undersökta perioden.

Klienter och loggar

device_port och client_vlan kopplar en klient till en port och ett VLAN. Om den är direkt ansluten framgår endast av värdet för direct_end_device, inte av att fältet finns. IP-adress och värdnamn kan saknas eller ändras. Använd även client_mac och tidsfälten för tilldelningen. En telemetripost är dessutom bara en observation vid en viss tidpunkt och inte ett bevis på aktuellt tillstånd eller en komplett anslutningshistorik.

För loggdata ger log_id, log_subtype, log_component, log_message och log_severity sammanhanget. Enbart allvarlighetsgraden bevisar varken orsaken till eller effekten av ett nätverksproblem.

Verifiera resultatet

Besvara följande frågor innan du använder resultatet:

• Tillhör customer_id och switchidentiteten rätt klientorganisation och målenhet?
• Motsvarar type_of_data och de klient- eller loggfält som faktiskt är ifyllda undersökningsfrågan?
• Ligger händelse-, klient- och inläsningstiderna inom det förväntade fönstret, och har de tolkats separat?
• Har is_full_set beaktats om du gör ett påstående om fullständighet?
• Stämmer MAC-adress, port, VLAN och värdet för direct_end_device med den förväntade anslutningen för en känd testklient?
• Ger den inbyggda frågan ett rimligt jämförelseresultat för samma mål och tidsfönster?

En post som saknas innebär bara att det saknas belägg under de valda villkoren. Den bevisar varken att switchen eller klienten inte finns eller i sig att det finns ett telemetrifel.

Avgränsa problem

Switchfrågor eller redigeringsfunktioner saknas

Om avsnittet Switch saknas ska du först kontrollera rätt Fusion-klientorganisation, en switch som hanteras via Fusion och licenstilldelningen för Sophos EDR, XDR eller MDR. Låt sedan kontrollera dina åtkomsträttigheter och funktionens aktivering i klientorganisationen. För Edit och Create new query måste dessutom Designer Mode vara aktiverat.

Schema eller tabell saknas

Schema Viewer kan öppnas från SQL-dialogrutan för en redigerad eller ny fråga. För en ny fråga måste Source: Data Lake vara valt. För switchtelemetri ska du endast använda sökvägen NSG Cswitch > nsg_cswitch_data som visas i visningsprogrammet och dess aktuella fält.

Frågan returnerar inga rader

Testa först en inbyggd switchfråga för en känd switch. Anteckna klientorganisation, switchfilter, förväntad testpost och tidsfönster. Ta sedan bort dina egna filter ett i taget och jämför fältnamnen med schemat.

Ta hänsyn till standardvärdet på 7 dagar om du inte har gjort ett eget tidsval. Utöka fönstret stegvis till högst 30 dagar med övriga villkor oförändrade. Använd separata, dokumenterade fönster för längre undersökningar. Jämför även händelse- och inläsningstid och kontrollera type_of_data och is_full_set. Dokumentera resultatet som ”inga rader under de valda frågevillkoren och under den valda perioden”.

Du kan även kontrollera målenhetens drift- och synkroniseringsstatus med runbooken Hantera en Sophos Switch-flotta.

Det finns rader, men klientdata saknas

En loggrad behöver inte innehålla klientfält. Kontrollera därför först type_of_data och is_full_set och utvärdera sedan client_mac, client_ip, client_hostname, client_event_timestamp och client_conn_status tillsammans. Fyll inte i värden som saknas från inventeringen eller namnkonventioner.

Tidsserien verkar motsägelsefull

Jämför händelse- och inläsningstid separat och kontrollera epoch-konverteringen och tidszonen. En fördröjd inläsning är inte automatiskt en andra nätverkshändelse. Du kan använda message_identifier för deduplicering, men dess unikhet är endast dokumenterad inom inläsningspipelinen.

Återställa ändringar och skydda data

En fråga ändrar sin SQL-definition eller sitt urval, inte switchkonfigurationen. Om en anpassad fråga är otillförlitlig ska du sluta använda den och återgå till den oförändrade inbyggda frågan. Återställ vid behov den tidigare sparade definitionen eller ta bort den nya varianten med den funktion som erbjuds i ditt gränssnitt. Kontrollera sedan med den inbyggda frågan att den normala processen fortfarande fungerar.

Exporterade resultat kan innehålla kund-ID:n, serienummer, IP- och MAC-adresser, värdnamn, portar, VLAN och loggmeddelanden. Skydda och radera exporter, skärmbilder och anteckningar enligt dina krav på lagring och dataskydd. När en fråga återställs tas inte redan sparade kopior bort. De måste hanteras på respektive lagringsplats.