Sophos Endpoint Data Collection i Live Discover

Data Collection and Investigation Policy steruje dwiema niezależnymi funkcjami: Live Response Connections i wysyłaniem telemetrii Endpoint do Sophos Data Lake. Live Discover używa aktualnych danych urządzenia albo historycznych danych Data Lake.

Funkcje wymagają Sophos EDR, XDR lub MDR. Live Response ma własne uprawnienia i jest opisany w artykule Response.

Skrócona procedura dla Classic: W obszarze Threat Analysis Center > Live Discover należy najpierw wybrać odpowiednią opcję Data source, a następnie Query category i Query. W przypadku zapytania Endpoint należy świadomie ograniczyć urządzenia docelowe w sekcji Devices, a następnie wybrać Run Query. Wynik jest wiarygodny dopiero wtedy, gdy wiersze wyników i dane Telemetry odpowiadają wybranemu źródłu, okresowi i oczekiwanym urządzeniom.

Przed zapytaniem sprawdzić, czy tenant korzysta z Threat Analysis Center, czy z Security Operations. Threat Analysis Center pozostaje dostępny jako Classic view. Security Operations oddziela Data Lake Search dla danych historycznych od Live Endpoint Search dla zapytań na połączonych urządzeniach. Poniższe kroki Live Discover, przykłady SQL, informacje o harmonogramach i limity interfejsu dotyczą Classic, chyba że wyraźnie wskazano inny interfejs. Aktualizacja tenanta nie unieważnia ich automatycznie ani nie tłumaczy na QL.

Security Operations: Data Lake Search

W Security Operations > Data Lake Search można przeszukiwać Detections i zdarzenia tenanta trzema metodami. Ten interfejs używa Advanced Search query language, czyli QL; nie należy kopiować do niego bez zmian zapytań SQL Data Lake z Classic.

• AI Search tłumaczy pytanie w języku naturalnym na zapytanie. Wpisz pytanie lub przygotowany prompt, wybierz Search i sprawdź wygenerowane zapytanie razem z wynikami. Browse Prompts lub View All otwiera prompty; Sophos Only, filtry kategorii i wyszukiwane hasło zawężają wybór. W razie potrzeby doprecyzuj prompt i wyszukaj ponownie.
• Query Builder tworzy zapytanie wizualnie z pól i operatorów. Ustaw datę i okres przed Search lub Shift + Enter. Do pierwszej kontroli użyj krótkiego okresu ze znanym zdarzeniem i sprawdź, czy źródło i filtry rzeczywiście je obejmują.
• Query Editor pozwala pisać własne zapytania QL. Basics przedstawia podstawy składni i przykłady, a Cheat Sheet operatory i funkcje. Search Help udostępnia kontekstową pomoc Build With Me dotyczącą schematów i pól. Tutaj również ustaw datę i okres przed Search lub Shift + Enter. Przykłady SQL z dalszych sekcji Classic nie są szablonami QL.

Przycisk przypinania obok nazwy metody ustawia preferowaną metodę wyszukiwania. Każde wykonane wyszukiwanie automatycznie trafia do historii wyszukiwania tenanta; nie jest więc tylko lokalnym szkicem. Ogranicz prompty i zapytania do pytania dotyczącego dochodzenia i nie wpisuj sekretów. Pusta tabela wyników ma znaczenie dopiero po sprawdzeniu okresu, źródła i filtrów; nie dowodzi braku incydentu.

Aby zapisać w AI Search i Query Editor, wybierz Save Query; w Query Builder najpierw wybierz Save Search. Podaj nazwę i kategorię, opcjonalnie dodaj opis i Bookmark this Query, a następnie zakończ przez Save Query. Otwórz ponownie zapisane zapytanie w Saved Queries i sprawdź je. Zakładka dodatkowo umieszcza je w My Bookmarked Queries.

Full Screen powiększa widok wyników. Menu nagłówka kolumny oferuje Pin, Autosize, Reset, Filter oraz pokazywanie i ukrywanie kolumn; kolejność można zmienić, przeciągając nagłówki. Przez Actions nad tabelą można eksportować wszystkie wyniki lub wybrany podzbiór. Następnie sprawdź stan eksportu i pobieranie na Data Exports. Nie dokumentuj filtrowanego widoku ani eksportu podzbioru jako pełnego zakresu dochodzenia.

Odróżniaj Live Endpoint Search od API danych historycznych

Live Endpoint Search nadal wykonuje zapytania SQL w stylu osquery na aktualnych, połączonych endpointach. Migracja Live Discover z REST do GraphQL dotyczy tej ścieżki na żywo, a nie historycznych zapytań Data Lake. To, że katalog LES może wyświetlać zapisane zapytania ze źródłem dataLake, nie potwierdza wykonywania zapytań Data Lake przez LES. Dlatego nie należy migrować istniejącej integracji API danych historycznych wyłącznie na podstawie tego przewodnika.

Od 12 października 2026 r. opublikowane jest Search GraphQL API v1 do historycznych wyszukiwań QL w Data Lake Fusion. Proces obejmuje uruchomienie, kontrolę statusu i stronicowane pobieranie wyników; jest odrębny od LES i jego SQL na żywo w stylu osquery. Runbook Search GraphQL wyjaśnia żądania, Search-URN, wyniki częściowe, kursory, wygaśnięcie i porównanie dotychczasowego klienta SQL. Data Lake Search pozostaje ścieżką interaktywną, a XDR Query API nadal jest dostępne. Ani ta publikacja, ani przewodnik migracji LES nie tłumaczy automatycznie SQL Classic na QL ani nie wymaga natychmiastowego przełączenia API.

Istniejące klienty REST i opcjonalne przełączenie na LES

Live Discover REST jest wyraźnie wyłączony z wycofywania Classic Cases/Detections APIs. Istniejącego klienta nie trzeba migrować wyłącznie z powodu tej zapowiedzi. Dla nowego klienta Live Endpoint lub świadomie zaplanowanej zmiany LES należy ocenić oddzielnie; historyczny XDR Query API i zachowane powyżej zapytania SQL Classic pozostają od tego niezależne.

LES przypisuje urządzenia docelowe do sesji przed uruchomieniem zapytania: najpierw wykonaj createLiveDiscoverSession, zachowaj zwróconą nazwę sesji, a następnie przypisz wybrane urządzenia do sesji za pomocą endpointSessions. Dopiero potem uruchom runLiveDiscoverQuery z tą nazwą jako sessionId oraz nadal wymaganym matchEndpoints: { all: false }. Nie używaj bezpośrednich filtrów w matchEndpoints jako skrótu, nawet jeśli schemat na to pozwala: przewodnik migracji wskazuje wyłącznie proces oparty na sesji jako obsługiwaną ścieżkę integracji. Zacznij od jednego zatwierdzonego urządzenia pilotażowego i wąsko ograniczonego zapytania SQL tylko do odczytu; uzgodnij przypisanie celu, status wykonania, wiersze wyników i dane Telemetry.

Przed przełączeniem sprawdź możliwość przeniesienia zapisanych identyfikatorów zapytań i kategorii; przewodnik nie potwierdza ich przejęcia bez zmian. Z osobą odpowiedzialną za API należy też ustalić retencję wyników i późniejszą dostępność zakończonych wykonań oraz rozwiązanie zastępujące dotychczasowe zarządzanie Enrichment Pivots. LES przyjmuje tylko jedną grupę filtrów na wywołanie wyboru; nie wolno zgadywać znaczenia wielu dotychczasowych grup filtrów REST. tamperProtectionEnabled zmienia się w tamperProtection w postaci listy, a luźne filtry String/JSON wymagają osobnej weryfikacji wartości.

Paginację wykonań, katalogu i wyników należy zaimplementować oddzielnie. Wyniki zawierają kolumny wyjściowe SQL jako ciąg zakodowany w JSON w additionalColumns; metadata.columns opisuje nazwy i typy. Dla kolejnych stron przekazuj otrzymany pages.nextKey bez zmian jako params.pageFromKey. HTTP 200 nie wystarcza: sprawdzaj również tablicę GraphQL errors i rzeczywisty status wykonania oraz endpointu. LES współdzieli z zaplanowanymi zapytaniami limit 1'000 wykonań dziennie i 10 na minutę; REST API podaje natomiast 500 wykonań dziennie i 10 na minutę. Te wartości właściwe dla poszczególnych API nie zastępują zbiorczo opisanych poniżej limitów interfejsu Classic. W pilotażu nadal należy uwzględniać zakres danych, Device Watchdog i limity wyników.

Live Endpoint czy Data Lake

Live Endpoint Queries bazują na osquery i są wykonywane na urządzeniach. Data Lake Queries działają na wysłanej telemetrii, mogą być planowane i obejmują do 30 lub 90 dni zależnie od licencji.

Zakres czasu Data Lake w Live Discover określa odpytywany okres historyczny. Nie jest harmonogramem wykonania. Pojedyncza Query może obejmować najwyżej 30 dni. Dla 90 dni używa się kilku oddzielnie ograniczonych zapytań.

Wybór i testowanie Query

W obszarze Threat Analysis Center > Live Discover dostępne są przygotowane Endpoint i Data Lake Queries. Procedura celowo rozdziela źródło, zapytanie i cel:

1. W sekcji Data source należy wybrać Endpoint, aby sprawdzić aktualny stan połączonych urządzeń, albo Data Lake, aby przeszukać przesłaną wcześniej telemetrię historyczną.
2. W sekcji Query category należy wybrać kategorię, a w sekcji Query odpowiednie zapytanie. W szczegółach Query trzeba sprawdzić obsługiwane systemy operacyjne i wartość System Impact podaną przez Sophos.
3. W przypadku Endpoint Query należy najpierw wybrać jedno urządzenie pilotażowe w sekcji Devices. W razie potrzeby użyć opcji Show filters, a następnie odświeżyć listę wybranych urządzeń. W przypadku Data Lake Query należy zamiast tego ustawić krótki, znany przedział czasu.
4. Wybrać Run Query i poczekać na wynik.

Nowe lub zmienione zapytanie należy najpierw przetestować na jednym urządzeniu pilotażowym albo w krótkim przedziale czasu Data Lake. Oczekiwane są wiersze wyników odpowiadające wybranemu urządzeniu lub okresowi. W sekcji Telemetry należy też sprawdzić, czy urządzenie docelowe odpowiedziało, jaka była wartość System Impact i ile danych przesłano. Jeśli wynik pozostaje pusty, należy najpierw sprawdzić Data source, przedział czasu, obsługiwany system operacyjny, a w przypadku Endpoint Query — stan połączenia urządzenia. W przypadku Data Lake Query należy ponadto sprawdzić, czy przesyłanie jest włączone w My Products > Endpoint > Policies > Data Collection and Investigation, a dla serwerów w My Products > Server.

Designer Mode umożliwia tworzenie własnych zapytań osquery lub SQL. Sophos Support pomaga w zakresie przygotowanych Sophos Queries i ścieżki danych, ale nie w specjalistycznym tworzeniu dowolnych Custom Queries. W tym celu dostępne są Community i Professional Services.

Wyniki Query oferują Pivots, Enrichments i Actions. Podejrzany SHA-256 można w ten sposób przekazać do kolejnej Query, kontroli Intelix lub VirusTotal, Threat Graph albo Live Response.

W przypadku odpytywania danych DNS Protection wybór DNS Protection, odpowiedni schemat Data Lake i kontrole właściwe dla DNS opisano w artykule Analizowanie raportów Sophos DNS Protection i Live Discover.

Sterowanie przesyłaniem danych do Data Lake

Przesyłanie danych jest domyślnie aktywne dla Endpoint Protection. W My Products > Endpoint > Policies > Data Collection and Investigation można je ograniczyć dla grup.

Wyłączenie zmniejsza liczbę dostępnych detekcji i możliwości analizy historycznej. Wyjątek dotyczący zbierania zdarzeń stosuje się tylko na polecenie Sophos Support, ponieważ redukuje telemetrię, a tym samym możliwości wykrywania lub prowadzenia analizy.

Po aktywacji ruch sieciowy może chwilowo wzrosnąć. W przypadku łączy o małej przepustowości lub wrażliwych segmentów zmianę należy obserwować w grupie pilotażowej.

Event Journals na urządzeniu

Sophos zapisuje Event Journals lokalnie w systemach Windows, macOS i Linux. Dostarczają one danych dla zapytań do urządzeń końcowych. Nie mają stałego okresu przechowywania; zależy on od platformy, aktywności i skonfigurowanej przestrzeni dyskowej.

W Global Settings > Products and Services > Endpoint and Server > Event Journals można ustawić maksymalny rozmiar od 300 do 30'000 MB. Wartość domyślna wynosi 5'250 MB. Opcjonalnie można dodatkowo ograniczyć procent dysku. Gdy obowiązują oba limity, Sophos używa niższej wartości.

Centralna konfiguracja tych limitów jest dostępna tylko z licencją XDR, MDR lub MDR Plus. Lokalne Event Journals nadal istnieją na chronionych urządzeniach Windows, macOS i Linux, ale bez odpowiedniej licencji nie można zmieniać ich progów w skali całego tenantu.

Ustawienie obowiązuje wszystkie objęte nim urządzenia i nie można określić innej wartości dla poszczególnych urządzeń końcowych. Zmniejszenie może spowodować odrzucenie istniejących danych dzienników i skrócić okres analizy.

Okres przechowywania i limity przestrzeni dyskowej

XDR przechowuje dane Data Lake do 90 dni, a EDR do 30 dni. Opcjonalny pakiet Central Data Storage – 1 yr rozszerza okres do jednego roku. Jest to maksimum; po wyczerpaniu puli przestrzeni dyskowej starsze dane są usuwane wcześniej.

Każde urządzenie może wysłać najwyżej 2 GB dziennie. Po osiągnięciu limitu przesyłanie zostaje wstrzymane do jego zresetowania. W systemie Windows limit resetuje się o północy czasu lokalnego, a w systemie Linux co 24 godziny od uruchomienia agenta XDR. Niewysłane dane nie są później uzupełniane, ale nadal są dostępne dla bezpośredniego zapytania do urządzenia końcowego.

Pula dla urządzeń końcowych wynosi średnio 20 MB na licencję dziennie. Trwałe przekroczenie skraca faktycznie dostępną historię; tenant z formalnymi 90 dniami może mieć mniej danych możliwych do przeszukania.

Znalezienie przyczyny dziennego limitu przesyłania

Zdarzenie Data Lake uploads stopped because the daily limit reached pojawia się na Endpointach Windows oraz serwerach Windows lub Linux. Zaplanowane Hydration Queries danego urządzenia generują te wysyłki. XDR i MDR mają limit 2 GB dziennie na urządzenie. Po jego osiągnięciu do następnego dnia nie są wysyłane dalsze dane Hydration Query; limit resetuje się, a Queries wznawiają pracę do końca dnia lub kolejnego osiągnięcia limitu.

Aby znaleźć Hydration Query o największym wolumenie przesyłanych danych, należy zalogować się do Sophos Fusion (dawniej Sophos Central) i przejść do Threat Analysis Center > Live Discover. Włączyć Designer Mode, wybrać Create a new query, nadać nazwę i ustawić Source na Data Lake. W Show variable editor nadać opisowe nazwy i dodać typy Device Name oraz Date. Wprowadzić urządzenie i datę YYYY-MM-DD, a następnie uruchomić:

SELECT
  query_name,
  sum(upload_size) / (1000.0 * 1000) AS total_upload_size_bytes_mb
FROM xdr_data
WHERE date_trunc('day', ingestion_timestamp) = date (from_unixtime($$date$$))
  AND meta_hostname = '$$hostname$$'
GROUP BY query_name, date_trunc('day', ingestion_timestamp)
ORDER BY total_upload_size_bytes_mb DESC

Alternatywnie ta Query bez zmiennych szereguje wszystkie urządzenia i Queries według dnia; przed uruchomieniem należy zastąpić przykładową datę:

SELECT
  query_name,
  meta_hostname,
  date_trunc('day', ingestion_timestamp) AS date,
  sum(upload_size) / (1000.0 * 1000) AS total_upload_size_bytes_mb
FROM xdr_data
WHERE date_trunc('day', ingestion_timestamp) >= date '2021-09-17'
GROUP BY query_name, meta_hostname, date_trunc('day', ingestion_timestamp)
ORDER BY total_upload_size_bytes_mb DESC

Największy wynik wskazuje Hydration Query do zbadania, a nie automatycznie proces, który należy zablokować. W aktualnym Sophos Data Lake Schema Viewer sprawdzić zapełniane kolumny i pogrupować po użytecznej kolumnie. Jeśli dominuje running_processes_windows_sophos, rozbić dane według ścieżki:

SELECT
  path,
  sum(upload_size) / (1000.0 * 1000) AS total_upload_size_bytes_mb
FROM xdr_data
WHERE date_trunc('day', ingestion_timestamp) = date '$$date$$'
  AND meta_hostname = '$$hostname$$'
  AND query_name = 'running_processes_windows_sophos'
GROUP BY path, date_trunc('day', ingestion_timestamp)
ORDER BY total_upload_size_bytes_mb DESC

W przykładzie Sophos zapytanie generowało około 72 MB, a jedna ścieżka uruchomionego procesu odpowiadała za ponad 50 procent dziennego przesyłania; nazwy procesów ukryto jako specyficzne dla środowiska. Gdy dominujące działanie jest znane, można dodać ograniczenia albo zbadać inne wypełnione kolumny, takie jak Command Line, User Name lub Parent Process, aby znaleźć zmianę zmniejszającą wolumen wyników. Przed zmianą lub blokadą należy zbadać przyczynę, zasadność działania i możliwą błędną konfigurację.

Mechanizmy ochronne

Sophos ogranicza zapytania, aby chronić urządzenia końcowe i tenant:

• interfejs użytkownika: maksymalnie 15 zapytań na minutę;
• zapytania zaplanowane i wysyłane przez API łącznie: 1'000 dziennie i 10 na minutę;
• Watchdog: przerwanie powyżej 30% CPU przez 12 sekund lub 256 MB RAM;
• maksymalnie 10 MB odpowiedzi na urządzenie i zapytanie;
• maksymalnie 1 MB na wiersz;
• maksymalnie 100'000 wierszy ze wszystkich urządzeń.

Pusty wynik może wynikać z przekroczonego rozmiaru wiersza. Sekcja Telemetry pod wynikiem pokazuje stan, System Impact i ilość danych przesłanych przez każde urządzenie.

Systematyczne zawężanie Query cancelled

Query cancelled nie jest błędem specyficznym dla HAFNIUM. W Windows Memory Watchdog może przerwać Live Query. W SophosLiveQueryService.log ustala się Query Name i rzeczywisty Resource Error, zmniejsza okres, na przykład z 15 do 7 dni, i ponawia test na jednym urządzeniu. Jeśli problem trwa, okres skraca się dalej lub zawęża Query.

Po Downgrade Sophos Core Agent 2025.2 do starszej wersji LTS lub FTS SophosOsquery.exe może nie startować przez zmianę File Attestation. Log zawiera wtedy Exception whilst running LiveQueryRunner. W tym konkretnym przypadku trzeba zrestartować urządzenie; zmiana Query nie rozwiązuje granicy wersji.

AI Search

W widoku Classic w Threat Analysis Center > AI Search AI Search tworzy zapytania Data Lake na podstawie języka naturalnego. Detections i dane endpointów Windows można przeszukiwać bez pisania składni SQL. Tabela pokazuje najwyżej 1'000 wyników. Nie należy automatycznie przenosić tych ograniczeń platformy i wyników na opisaną wyżej nową Data Lake Search.

Wyszukiwanie zaczyna się od kilku godzin lub dnia. Duże zakresy mogą być wolne lub przerwane. Wygenerowany SQL jest kontrolowany przed uznaniem wyniku za kompletny.

Własne kategorie i zaplanowane zapytania

Zapytania przeznaczone do ponownego użycia należy umieszczać w jednoznacznie nazwanych własnych kategoriach. Dokumentacja zapytania obejmuje opis, obsługiwane systemy operacyjne, źródło danych, zmienne i oczekiwany wynik. Skopiowane zapytanie nie jest wiarygodne tylko dlatego, że jego SQL wykonuje się poprawnie. Sophos udostępnia własne kategorie stopniowo, dlatego funkcja może nie być jeszcze widoczna w każdym tenancie.

Zaplanowane zapytania nadają się do powtarzalnych hipotez i kontroli i są dostępne wyłącznie dla zapytań Data Lake. Częstotliwość, dzień, datę zakończenia i odpytywany okres należy ustawić świadomie. Każdy administrator może mieć najwyżej 100 aktywnie zaplanowanych zapytań lub raportów korzystających z tego wspólnego formatu. Zbyt szerokie lub częste zapytania mogą też osiągać ogólne limity i tworzyć duże ilości telemetrii zawierającej dane osobowe.

Eksploatacja i ochrona prywatności

Telemetria Data Lake i Live Discover może zawierać nazwy procesów, wiersze poleceń, nazwy użytkowników, skróty plików, adresy IP i inne dane operacyjne. Dlatego dokumentuje się role, cel, okres przechowywania i eksport.

Query Categories porządkują często używane zapytania. Usunięcie własnej kategorii nie usuwa zawartych w niej Queries; pozostają one dostępne w All Queries lub w innych kategoriach.

Powiązane artykuły

Isolation i Live Response: Izolowanie Sophos Endpoint i Live Response. Sophos Endpoint XDR: Investigation i Threat Graph opisuje późniejszą ocenę Detections i Threat Graphs.

Częste pytania

Dla obecnego interfejsu Security Operations Data Lake Search i eksport wyjaśnia schematy, 31-dniowe okna zdarzeń, osobny limit Raw i aktualne eksporty. Zachowane wyżej limity Classic nie są przenoszone na ten interfejs.