Przejdz do tresci
Avanet

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.

  1. W Sophos Fusion otwórz Threat Analysis Center > Live Discover > Switch.
  2. Wybierz wbudowane zapytanie Data Lake dla Sophos Switch. Sprawdź jego przeznaczenie, widoczną definicję i wymagane parametry.
  3. Jeśli ta opcja jest dostępna, ustaw okres badania w polu Select a Time Period, a następnie uruchom zapytanie.
  4. Zinterpretuj wyniki na podstawie tożsamości switcha, type_of_data i pól czasu. Porównaj znany switch lub klienta testowego z danymi w systemie zarządzania switchami.
  5. 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.
  6. 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.
  7. 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.
  8. 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.

PoleUdokumentowane znaczenie
message_identifierUnikatowy ID generowany przez potok pozyskiwania
ingest_dateData pozyskania danych
ingestion_timestampCzas pozyskania w sekundach epoki
schema_versionWersja schematu Data Lake
record_sizeRozmiar danych
customer_idID klienta
type_of_dataTyp danych wysyłanych w strumieniu, na przykład dane klienta lub logu
is_full_setWskazuje, czy dostarczenie jest pełne, czy przyrostowe
timestampCzas wygenerowania zdarzenia
device_idUnikatowy ID switcha
device_nameNazwa switcha
device_modelModel switcha
device_firmwareWersja oprogramowania układowego switcha
device_serial_idNumer seryjny switcha
client_macAdres MAC połączonego urządzenia
client_ipAdres IP połączonego urządzenia
client_hostnameNazwa hosta połączonego urządzenia
client_event_timestampCzas nawiązania połączenia przez urządzenie
client_conn_statusStan połączenia urządzenia
log_idID logu
log_subtypePodtyp logu
log_componentKomponent logu
log_messageKomunikat logu
log_severityPoziom istotności komunikatu logu
device_ipAdres IP switcha
device_portPort switcha, z którym połączony jest klient
client_vlanVLAN przypisany do połączonego urządzenia
direct_end_deviceWskazuje, 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

  • timestamp oznacza czas wygenerowania zdarzenia.
  • client_event_timestamp oznacza czas nawiązania połączenia przez urządzenie.
  • ingestion_timestamp oznacza czas pozyskania w sekundach epoki.
  • ingest_date to 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_id i tożsamość switcha należą do właściwego tenantu i urządzenia docelowego?
  • Czy type_of_data i 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_device odpowiadają 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.