Sophos Switch: odpytywanie danych urządzeń i klientów za pomocą Live Discover
Za pomocą Live Discover można odpytywać telemetrię urządzeń Sophos Switch zarządzanych w Sophos Fusion. Dane Data Lake pomagają na przykład badać urządzenia, które były połączone z określonym switchem. Nie stanowią jednak bieżącego widoku aktualnego stanu switcha.
Wymagania
Potrzebny jest co najmniej jeden Sophos Switch zarządzany w Sophos Fusion oraz dostęp do właściwego tenantu i do Threat Analysis Center > Live Discover. Live Discover wymaga licencji Sophos EDR, XDR lub MDR. Poza tym dokumentacja nie wskazuje konkretnego pakietu licencyjnego Switch ani określonej roli administratora. Jeśli brakuje funkcji Live Discover, Switch lub funkcji edycji, należy zatem zlecić sprawdzenie przypisania licencji, swoich uprawnień dostępu i aktywacji funkcji w danym tenancie.
Należy wcześniej określić cel badania. Odpowiednimi punktami odniesienia są na przykład ID switcha, nazwa urządzenia, numer seryjny, adres MAC klienta, port, VLAN i okres. Designer Mode jest potrzebny tylko do edytowania lub tworzenia zapytania.
Odpytywanie danych switcha
Najpierw należy użyć wbudowanego zapytania dotyczącego switcha. Pozwala to uzyskać wynik porównawczy i przejść do projektanta tylko wtedy, gdy istniejące zapytanie nie odpowiada na dane pytanie.
- W Sophos Fusion otwórz Threat Analysis Center > Live Discover > Switch.
- Wybierz wbudowane zapytanie Data Lake dla Sophos Switch. Sprawdź jego przeznaczenie, widoczną definicję i wymagane parametry.
- Jeśli ta opcja jest dostępna, ustaw okres badania w polu Select a Time Period, a następnie uruchom zapytanie.
- Zinterpretuj wyniki na podstawie tożsamości switcha,
type_of_datai pól czasu. Porównaj znany switch lub klienta testowego z danymi w systemie zarządzania switchami. - Jeśli wbudowane zapytanie jest wystarczające, udokumentuj zapytanie, parametry, przedział czasu i wynik. W przeciwnym razie włącz Designer Mode i wybierz jedną z następujących metod:
- Dostosowanie istniejącego zapytania: wybierz zapytanie w obszarze Query i kliknij Edit. Przed wprowadzeniem zmian zapisz pierwotną definicję.
- Utworzenie nowego zapytania: w obszarze Query kliknij Create new query i wybierz Data Lake jako Source.
- W oknie dialogowym SQL otwórz Schema w prawym górnym rogu. Schema Viewer otworzy się w nowej karcie. Wybierz NSG Cswitch > nsg_cswitch_data i sprawdź dostępne kolumny oraz typy danych.
- Używaj tylko tabel, pól i wartości widocznych w aktualnym Schema Viewer lub wbudowanym zapytaniu. Za każdym razem zmieniaj tylko jeden powiązany element, na przykład wybór pól lub filtr dla znanego switcha.
- Najpierw uruchom dostosowane zapytanie dla ściśle ograniczonego, znanego switcha lub klienta. Porównaj wynik z niezmienionym zapytaniem wbudowanym oraz znanymi danymi inwentarzowymi lub dotyczącymi połączenia.
Aby wyszukać klientów określonego switcha, należy jednoznacznie wskazać urządzenie docelowe za pomocą device_id lub numeru seryjnego. Następnie trzeba łącznie ocenić adres MAC klienta, device_port, client_vlan, stan połączenia i pola czasu. Takie ograniczenie zapobiega pomyłkom, ale nie dowodzi jeszcze kompletności listy klientów; zgodne muszą być również okres i is_full_set.
Wybór przedziału czasu
Opcja Select a Time Period jest opcjonalna w zapytaniach Data Lake. Jeśli nie dokonano wyboru, stosowany jest okres ostatnich 7 dni. Jedno zapytanie może obejmować maksymalnie 30 dni.
W przypadku dłuższych badań należy uruchomić kilka zapytań z oddzielnymi przedziałami czasu. Dla 90 dni Sophos podaje na przykład 0–30, 31–60 i 61–90 dni. Każdy przedział należy udokumentować oddzielnie, a podczas porównania pozostawić bez zmian switch, typ danych i inne filtry.
Pola w schemacie switcha
Schemat obejmuje tożsamość switcha, połączonych klientów i logi. type_of_data oznacza typ wysłanych danych, na przykład dane klienta lub logu. Dlatego nie każdy wiersz zawiera jednocześnie wszystkie pola klienta i logu.
| Pole | Udokumentowane znaczenie |
|---|---|
message_identifier | Unikatowy ID generowany przez potok pozyskiwania |
ingest_date | Data pozyskania danych |
ingestion_timestamp | Czas pozyskania w sekundach epoki |
schema_version | Wersja schematu Data Lake |
record_size | Rozmiar danych |
customer_id | ID klienta |
type_of_data | Typ danych wysyłanych w strumieniu, na przykład dane klienta lub logu |
is_full_set | Wskazuje, czy dostarczenie jest pełne, czy przyrostowe |
timestamp | Czas wygenerowania zdarzenia |
device_id | Unikatowy ID switcha |
device_name | Nazwa switcha |
device_model | Model switcha |
device_firmware | Wersja oprogramowania układowego switcha |
device_serial_id | Numer seryjny switcha |
client_mac | Adres MAC połączonego urządzenia |
client_ip | Adres IP połączonego urządzenia |
client_hostname | Nazwa hosta połączonego urządzenia |
client_event_timestamp | Czas nawiązania połączenia przez urządzenie |
client_conn_status | Stan połączenia urządzenia |
log_id | ID logu |
log_subtype | Podtyp logu |
log_component | Komponent logu |
log_message | Komunikat logu |
log_severity | Poziom istotności komunikatu logu |
device_ip | Adres IP switcha |
device_port | Port switcha, z którym połączony jest klient |
client_vlan | VLAN przypisany do połączonego urządzenia |
direct_end_device | Wskazuje, czy urządzenie jest bezpośrednio połączone ze switchem |
Wartości stanu, podtypu i poziomu istotności mogą się różnić zależnie od wyświetlanych danych. Należy przyjąć ich dokładną pisownię i znaczenie z aktualnego schematu oraz wyniku zapytania.
Prawidłowa interpretacja wyników
Nieprzetworzony wiersz Data Lake jest początkowo wynikiem zapytania. To, czy zawiera dane klienta, czy logu, wynika z type_of_data i wypełnionych pól. Jeśli zapytanie SQL łączy kilka rekordów, wiersz wyniku jest obliczonym podsumowaniem, a nie pojedynczym zdarzeniem sieciowym. Nie należy zatem bez sprawdzenia przenosić znaczenia timestamp na agregat.
Tożsamość i tenant
device_id jest unikatowym ID switcha. Z urządzeniem docelowym należy również porównać co najmniej jeden dodatkowy punkt odniesienia, taki jak device_serial_id, device_name, device_model lub device_ip. Nazwy i adresy IP mogą się zmieniać lub być ponownie używane. customer_id przypisuje dane do tenantu i nie jest identyfikatorem switcha, numeru seryjnego ani klienta.
Czas zdarzenia i pozyskania
timestampoznacza czas wygenerowania zdarzenia.client_event_timestampoznacza czas nawiązania połączenia przez urządzenie.ingestion_timestampoznacza czas pozyskania w sekundach epoki.ingest_dateto data pozyskania.
Późniejsze pozyskanie nie oznacza automatycznie późniejszego zdarzenia sieciowego. W przypadku szeregów czasowych należy również sprawdzić konwersję czasu epoki i strefę czasową używanego środowiska zapytań.
Dane pełne i przyrostowe
is_full_set wskazuje, czy dostarczenie danych jest pełne, czy przyrostowe. Przyrostowego zestawu danych nie należy traktować jako pełnego spisu klientów. Nawet dostarczenie oznaczone jako pełne samo w sobie nie gwarantuje, że każdy oczekiwany klient pojawi się w badanym okresie.
Klienci i logi
device_port i client_vlan wiążą klienta z portem i siecią VLAN. To, czy jest on połączony bezpośrednio, wynika wyłącznie z wartości direct_end_device, a nie z samej obecności pola. Adres IP i nazwa hosta mogą być nieobecne lub się zmieniać; do przypisania należy dodatkowo użyć client_mac i pól czasu. Rekord telemetrii jest ponadto tylko obserwacją dotyczącą określonego czasu, a nie dowodem aktualnego stanu ani kompletnej historii połączeń.
W przypadku danych logu kontekst tworzą log_id, log_subtype, log_component, log_message i log_severity. Sam poziom istotności nie dowodzi ani przyczyny, ani skutku problemu sieciowego.
Weryfikacja wyniku
Przed użyciem wyniku należy odpowiedzieć na następujące pytania:
- Czy
customer_idi tożsamość switcha należą do właściwego tenantu i urządzenia docelowego? - Czy
type_of_datai faktycznie wypełnione pola klienta lub logu odpowiadają badanemu zagadnieniu? - Czy czas zdarzenia, klienta i pozyskania mieści się w oczekiwanym przedziale i czy każdy z nich został zinterpretowany oddzielnie?
- Czy uwzględniono
is_full_set, jeśli formułowane jest stwierdzenie dotyczące kompletności? - Czy dla znanego klienta testowego adres MAC, port, VLAN i wartość
direct_end_deviceodpowiadają oczekiwanemu połączeniu? - Czy wbudowane zapytanie zwraca wiarygodny wynik porównawczy dla tego samego celu i przedziału czasu?
Brak rekordu oznacza jedynie, że w wybranych warunkach brakuje dowodu. Nie dowodzi ani nieistnienia switcha lub klienta, ani sam w sobie błędu telemetrii.
Lokalizowanie problemów
Brak zapytań dotyczących switcha lub funkcji edycji
Jeśli brakuje sekcji Switch, najpierw należy sprawdzić właściwy tenant Fusion, switch zarządzany przez Fusion i przypisanie licencji Sophos EDR, XDR lub MDR. Następnie należy zlecić kontrolę swoich praw dostępu i aktywacji funkcji w tenancie. Dla opcji Edit i Create new query musi być dodatkowo włączony Designer Mode.
Brak schematu lub tabeli
Schema Viewer można otworzyć z okna dialogowego SQL edytowanego lub nowego zapytania. W przypadku nowego zapytania musi być wybrane Source: Data Lake. Do telemetrii switcha należy używać wyłącznie ścieżki NSG Cswitch > nsg_cswitch_data widocznej w viewerze oraz jej aktualnych pól.
Zapytanie nie zwraca żadnych wierszy
Najpierw należy przetestować wbudowane zapytanie dla znanego switcha. Trzeba zanotować tenant, filtr switcha, oczekiwany rekord testowy i przedział czasu. Następnie należy pojedynczo wycofywać własne filtry i porównywać nazwy pól ze schematem.
Jeśli nie wybrano własnego okresu, należy uwzględnić domyślny zakres 7 dni. Przy niezmienionych pozostałych warunkach należy stopniowo rozszerzać przedział do maksymalnie 30 dni. W dłuższych badaniach trzeba używać oddzielnych, udokumentowanych przedziałów. Należy również porównać czas zdarzenia i pozyskania oraz sprawdzić type_of_data i is_full_set. Wynik trzeba zapisać jako „brak wierszy w wybranych warunkach zapytania i w wybranym okresie”.
Stan działania i synchronizacji urządzenia docelowego można dodatkowo sprawdzić za pomocą podręcznika Zarządzanie flotą Sophos Switch.
Wiersze są obecne, ale brakuje danych klientów
Wiersz logu nie musi zawierać pól klienta. Dlatego najpierw należy sprawdzić type_of_data i is_full_set, a następnie ocenić łącznie client_mac, client_ip, client_hostname, client_event_timestamp i client_conn_status. Brakujących wartości nie należy uzupełniać na podstawie inwentarza ani konwencji nazewnictwa.
Szereg czasowy wydaje się niespójny
Należy oddzielnie porównać czas zdarzenia i pozyskania oraz sprawdzić konwersję czasu epoki i strefę czasową. Opóźnione pozyskanie nie oznacza automatycznie drugiego zdarzenia sieciowego. Do deduplikacji można użyć message_identifier, ale jego unikatowość jest udokumentowana tylko w obrębie potoku pozyskiwania.
Wycofywanie zmian i ochrona danych
Zapytanie zmienia swoją definicję lub wybór SQL, a nie konfigurację switcha. Jeśli dostosowane zapytanie jest niewiarygodne, nie należy go dalej używać i trzeba wrócić do niezmienionego zapytania wbudowanego. W razie potrzeby można przywrócić wcześniej zapisaną definicję lub odrzucić nowy wariant za pomocą funkcji dostępnej w interfejsie. Następnie trzeba użyć wbudowanego zapytania, aby potwierdzić, że normalny proces nadal działa.
Wyeksportowane wyniki mogą zawierać identyfikatory klientów, numery seryjne, adresy IP i MAC, nazwy hostów, porty, sieci VLAN i komunikaty logu. Eksporty, zrzuty ekranu i notatki należy chronić i usuwać zgodnie z wymaganiami dotyczącymi przechowywania i ochrony danych. Wycofanie zapytania nie usuwa zapisanych już kopii; trzeba je obsłużyć w odpowiednich miejscach przechowywania.