Sophos Next-Gen SIEM: ocena możliwości i planowanie retencji

Sophos Next-Gen SIEM to opcjonalny dodatek do Sophos XDR Powered by Secureworks i Sophos MDR. Przed jego użyciem konto musi zostać zaktualizowane do Sophos Fusion. Techniczna pomoc administracyjna opisuje standardowo 13 miesięcy przechowywania danych oraz możliwość wydłużenia tego okresu do 10 lat. Do tego dochodzą telemetria zagrożeń i zgodności oraz integracje niestandardowe uzupełniające gotowe integracje XDR/MDR. Ta ocena odpowiada stanowi weryfikacji na 28 października 2026 r.; odmienna informacja o jednym roku na stronie produktu jest poniżej omówiona w kontekście zakupu.

Przed podjęciem decyzji należy najpierw spisać potrzebne źródła danych i okresy przechowywania. Następnie trzeba uzyskać potwierdzenie konkretnego zakresu dodatku dla własnej dzierżawy i na niewielkim źródle pilotażowym sprawdzić, czy przewidziane zdarzenia są rzeczywiście pobierane i można je ponownie odnaleźć. Sama istniejąca licencja XDR lub MDR nie dowodzi, że opcjonalny dodatek został włączony.

Kiedy Next-Gen SIEM odpowiada potrzebom

SIEM oznacza Security Information and Event Management: dane zdarzeń są zbierane centralnie i udostępniane do analizy. Next-Gen SIEM rozszerza wspólną architekturę danych XDR/MDR o dłuższe przechowywanie i analizy zgodności. Warto go rozważyć zwłaszcza wtedy, gdy potrzebne są zdarzenia historyczne z dłuższych okresów lub dane ze źródła mają być pobierane przez własną integrację.

Jeśli pierwszym zadaniem jest skonfigurowanie istniejącej integracji produktu, należy zacząć od artykułu o integracjach MDR i XDR w Sophos Fusion. Wyjaśnia on przepływ danych i kontrole operacyjne. Połączenie Sophos Firewall z syslog dotyczy przesyłania logów firewalla do odbiorcy. Nie określa, jaki zakres Next-Gen SIEM został zakupiony lub aktywowany dla źródła.

Sophos XDR pozostaje główną platformą wykrywania, prowadzenia dochodzeń, reagowania i automatyzacji. Next-Gen SIEM uzupełnia te procesy o zbieranie danych na potrzeby zgodności, dowody historyczne i dłuższe przechowywanie. Dodatek SIEM nie jest więc ogólnym warunkiem korzystania z funkcji wykrywania lub reagowania XDR, na które już posiadana jest licencja; z kolei samo XDR nie udostępnia dodatkowych usług SIEM.

Avanet zaleca, aby nie wybierać dodatku wyłącznie ze względu na możliwie długą retencję. Retencja oznacza tutaj przechowywanie danych. Decydujące jest to, jakie zdarzenia będą później potrzebne, na jakie pytania mają odpowiadać, kto będzie je analizować i jak długo powinny pozostawać dostępne. Dłuższe przechowywanie niewiele daje, jeśli wymagana kategoria zdarzeń nie jest dostarczana lub brakuje istotnych pól.

Sophos opisuje również gotowe dashboardy zgodności. Takie analizy wspierają gromadzenie dowodów, ale nie zastępują sprawdzenia zakresu dostępnych danych, oceny prawnej ani certyfikacji. Z samego dodatku nie wynika automatyczne spełnienie wymagań zgodności.

Ustalenie dzierżawy i oferty przed wdrożeniem

Przed zakupem należy udokumentować właściwą dzierżawę, używany produkt XDR/MDR i rzeczywisty stan aktualizacji do Fusion. Zapowiedź lub planowany termin aktualizacji nie wystarczają do zatwierdzenia użycia operacyjnego. Następnie trzeba uzyskać od partnera Sophos potwierdzenie, czy Next-Gen SIEM jest dostępny dla tego konta oraz jakie okresy przechowywania i usługi integracyjne obejmuje konkretna oferta.

Sophos opisuje model cenowy oparty na użytkownikach i serwerach, bez opłat za ingestowanie, czyli bez opłaty zależnej od ilości pobranych danych. Jest to opis modelu cenowego, a nie oferta cenowa ani gwarancja nieograniczonej wydajności technicznej. Przed zamówieniem trzeba wyjaśnić sposób zliczania, czas trwania umowy, pożądane wydłużenie retencji, zakres integracji i ewentualne wymagania produktu innego dostawcy. W szczególności z tego opisu nie można wywodzić bezpłatnych licencji innych dostawców ani gwarantowanych limitów przepustowości lub liczby zdarzeń.

W przypadku integracji niestandardowych potwierdzono możliwość tworzenia własnych integracji danych. Nie oznacza to jednak, że istnieje zweryfikowana procedura konfiguracji dla każdego źródła. Dlatego przed pilotażem potrzebny jest opis dostosowany do konkretnego źródła, obejmujący transmisję, uwierzytelnianie, format zdarzeń, mapowanie pól i obsługiwane analizy. Nie wolno bez sprawdzenia przenosić menu ani zapytań istniejących konektorów do integracji niestandardowej. Sposób otwarcia dashboardu opisano poniżej; nie wynika z niego uniwersalna procedura konfiguracji każdego źródła niestandardowego.

Wyraźne potwierdzenie liczby licencji i ścieżki kolektora

Next-Gen SIEM nie jest dostępny do zakupu jako samodzielny produkt. Liczba jego subskrypcji musi odpowiadać łącznej liczbie licencjonowanych użytkowników i serwerów XDR oraz MDR; nie wolno pomijać serwerów przy ustalaniu liczby. Uzgodnij z partnerem rzeczywisty stan i ofertę, zamiast przyjmować jako liczbę licencji wyłącznie grupę pilotażową lub wolumen danych. Oprócz standardowych 13 miesięcy rozszerzenia retencji do trzech, pięciu, siedmiu lub 10 lat są opcjami do zakupu, a nie funkcjami automatycznie włączanymi przez istniejącą licencję XDR/MDR. Nie odtwarzają historii, której okres przechowywania upłynął, i nie potwierdzają zgodności z wymaganiami prawnymi.

Wytyczne licencyjne obowiązujące od 16 października 2026 r. podają dodatkowo limit 1 GB surowych danych przyjmowanych dziennie, łącznie ze wszystkich źródeł. Tabela licencjonuje według użytkowników i serwerów, ale zdanie o wolumenie nie określa wyraźnie, czy ilość przypada na subskrypcję, czy tenant. Nie należy więc liczyć 1 GB × użytkownicy i serwery ani zakładać stałego limitu 1 GB na tenant. Przed wymiarowaniem lub zamówieniem konieczne jest wiążące potwierdzenie jednostki odniesienia, agregacji i zachowania po przekroczeniu limitu. Cena bez opłaty za ingestion zależnej od wolumenu nie oznacza nieograniczonego użycia.

Liczba subskrypcji Retention Add-on musi również odpowiadać całkowitej liczbie subskrypcji NG-SIEM. Nie wynika z tego przedłużona retencja dla dowolnie wybranego podzbioru lub jednego źródła.

W integracjach Syslog stare Sophos Log Collectors nie obsługują pełnego zakresu retencji Next-Gen SIEM. W tym celu Sophos zaleca przejście na XDR Data Collectors; istniejący runbook migracji kolektora wyjaśnia przygotowanie zasobów, wdrożenie, przełączenie źródeł i odbiór. Istniejące integracje API nie wymagają ponownej konfiguracji wyłącznie z powodu tej zmiany kolektora. Na współdzielonej SVA NDR pozostaje odrębnym obciążeniem i nie może zostać przypadkowo wyłączony podczas przełączenia Syslog. Nowy kolektor nie zastępuje weryfikacji uprawnień do dodatku, formatu źródła i rzeczywiście obowiązującej retencji.

Nowy hub SIEM porządkuje istniejące instrukcje według planowania, pobierania źródeł, transportu i kontroli parserów. Przykład HTTP i parsera łączy te kroki z syntetycznym źródłem laboratoryjnym; jego praktyczny odbiór w tenancie pozostaje otwarty.

Dane niestandardowe: oddzielić transport, normalizację i wykrywanie

Custom Integration przesyła do XDR dane ze źródła, którego Sophos nie zoptymalizował. Nie potwierdza to jeszcze obsługi normalizacji, wyszukiwania ani wykrywania dla tego źródła. Custom Parsers przypisują pola logów do obsługiwanych, ustandaryzowanych schematów zdarzeń XDR. Dopiero wtedy można sprawdzić, czy obecne są pola wymagane do zamierzonego wyszukiwania, działania Detektora lub Custom Detection Rule.

Custom Parsers wymagają subskrypcji Next-Gen SIEM. Mogą nimi zarządzać role Admin i Super Admin; pozostałe role mogą jedynie wyświetlać listę skonfigurowanych parserów. Wiadomości, do których nie pasuje żaden parser, korzystają ze schematu generic. Mogą dostarczać kontekst dla Cases i Custom Rules, ale pojawiają się w wynikach wyszukiwania wyłącznie przy użyciu zaawansowanych parametrów wyszukiwania. Brak wyniku w prostym wyszukiwaniu nie dowodzi więc, że nie pobrano danych.

Nawet prawidłowo znormalizowane dane nie uruchamiają automatycznie każdego Detektora pasującego do schematu. Sophos wskazuje określone obsługiwane ścieżki Detektorów wraz z wymaganymi polami; działanie pozostałych Detektorów nie jest gwarantowane. Dlatego zamierzone wykrywanie podlega osobnemu odbiorowi z odpowiednimi zdarzeniami testowymi. Reklamowane wsparcie AI nie zastępuje tej kontroli.

Nowo utworzony Custom Parser jest domyślnie wyłączony. Jest wielokrotnie testowany na różnych przykładowych wiadomościach, zapisywany i dopiero potem osobno włączany. Zmiany już aktywnego parsera zaczynają natomiast działać natychmiast po zapisaniu; dlatego przed zapisaniem należy je dokładnie przetestować. Nakładające się Confirm Strings mogą przypisywać wiadomości do niewłaściwego parsera; dlatego sprawdzeniu podlega również faktycznie używany extractor path.

Sophos nie utrzymuje ani nie aktualizuje Custom Parsers. Odpowiedzialny operator musi ponownie sprawdzić mapowanie pól, znaczniki czasu i wyniki wyszukiwania lub wykrywania po zmianie formatu źródła albo parsera. Na potrzeby pilotażu pobieranie danych, normalizację i zamierzoną analizę dokumentuje się jako trzy odrębne wyniki; zielony stan transportu nie wystarcza.

Praktyczną konfigurację opisują Custom HTTP Ingest, warianty S3, Azure Event Hubs i Storage oraz runbook Custom Parser. W każdym wariancie transport, schemat i oczekiwana analiza są osobnymi wynikami odbioru.

Otwieranie dashboardu NG-SIEM do sprawdzania dowodów

Po włączeniu dodatku dostarczony widok można dodać do osobistej listy dashboardów w następujący sposób:

Otworzyć Dashboards > Manage dashboards.
Wybrać Find dashboards i dodać NG-SIEM do listy.
Otworzyć dashboard z listy i porównać wyświetlane dane z inwentaryzacją źródeł, okresem i oczekiwanymi zdarzeniami.

Dashboard NG-SIEM zawiera widżety dotyczące kontroli dostępu, bezpieczeństwa sieci i zdarzeń audytowych. Sophos opisuje też przykład dashboardu ISO 27001 łączącego uwierzytelnianie, zmiany, zdarzenia sieciowe i zapory, aktywność poczty e-mail i plików oraz procesy wykrywania i obsługi Cases. To, jakie informacje są rzeczywiście dostępne na potrzeby własnych dowodów, zależy od podłączonych źródeł i jakości ich danych; widok nie stanowi certyfikacji ISO ani automatycznego potwierdzenia zgodności.

Ogólna instrukcja dotycząca dashboardów wyjaśnia listy osobiste, dostępne widoki i eksport PDF. Jeśli brakuje NG-SIEM, najpierw sprawdza się dzierżawę, dodatek i uprawnienia; pusty widok bada się w odniesieniu do źródła danych i okresu. Ani brakujące, ani zielone widżety nie zastępują sprawdzenia zdarzeń źródłowych.

Aktualna pomoc NG-SIEM właściwa dla produktu z 1 października 2026 r. opisuje ten dostęp. Starsza wspólna pomoc dashboardów z 17 września wymienia jeszcze tylko dashboard TAC. To różnica dokumentacyjna, a nie gwarancja widoku w niesprawdzonym tenancie. Jeśli wpisu brakuje mimo zgodnej oferty, należy wyjaśnić faktyczne udostępnienie; nie tworzyć drugiej integracji na próbę.

Oddzielić retencję, okna wyszukiwania i dane surowe

13 miesięcy w pomocy administracyjnej, rok na stronie produktu

Techniczne omówienie z 1 października 2026 r. podaje 13 miesięcy standardowego przechowywania. Publiczna strona produktu, według weryfikacji z 28 października, podaje natomiast jeden rok. Oba źródła wymieniają rozszerzenia do trzech, pięciu, siedmiu lub dziesięciu lat. Różnicy nie interpretuje się jako potwierdzonej zmiany produktu ani jedynie innego zaokrąglenia; brakuje jednoznacznego wyjaśnienia Sophos.

Dla technicznego omówienia w tym artykule punktem odniesienia jest 13 miesięcy z pomocy administracyjnej tego produktu. Przed zamówieniem lub wiążącym zobowiązaniem dotyczącym przechowywania trzeba jednak potwierdzić okres obowiązujący dla konkretnego tenanta, typów danych i oferty. Potwierdzenie powinno znaleźć się w inwentaryzacji źródeł. Jeśli firma potrzebuje na przykład ponad dwunastu miesięcy historii, nie można zakładać dodatkowego czasu wyłącznie na podstawie ogólnej reklamy produktu. Poniższa inwentaryzacja retencji i odbiór weryfikują uzgodniony zakres; nie rozstrzygają konfliktu źródeł przez przyjęcie domniemanego okresu.

Okres wyszukiwania i dostęp do danych surowych

Długa retencja nie pozwala na dowolnie duże pojedyncze zapytanie. Aktualna pomoc schematów dopuszcza dla znormalizowanych Events maksymalnie 31 dni na zapytanie, z dowolną datą początkową w faktycznie zachowanych danych. Dłuższe dochodzenia dzieli się na odpowiednie okna. Wyszukiwanie detections jest odrębne.

Dla @raw i original_data nowszy przewodnik migracji SQL do QL z 15 września 2026 r. wskazuje osobny limit dostępu 20 dni. Żądanie poza tym zakresem jest odrzucane, nie skracane po cichu do dozwolonego okresu. Starsza pomoc Query Language wspomina też kroki 20-dniowe; nie gwarantuje to starszych danych surowych. Podział żądań nie udostępnia ich automatycznie. Ten limit wyszukiwania nie dowodzi fizycznego usuwania po 20 dniach ani ogólnego skrócenia retencji danych znormalizowanych.

Data Lake Search i eksport wyjaśnia wybór schematu, limity zapytań, okna historyczne i dowód kompletnego eksportu. Eksploatacja reguł oddziela udane wyszukiwanie od stale ocenianej reguły detection lub suppression.

Inwentaryzacja retencji dla każdego źródła

Inwentaryzacja należy do dokumentacji operacyjnej, nie tylko do oferty. Dla każdego źródła należy zapisać poniższe informacje; różne kategorie zdarzeń tej samej aplikacji mogą wymagać oddzielnych wpisów:

System źródłowy, dzierżawa źródłowa, kategorie zdarzeń i osoba odpowiedzialna.
Cel pobierania danych i konkretne pytanie, na które późniejsze wyszukiwanie lub dowód mają odpowiedzieć.
Wymagane pola, na przykład czas zdarzenia ze strefą czasową, działanie, wynik i tożsamość odpowiednia do dochodzenia.
Klasyfikacja danych, dozwolona zawartość i zgoda na przesyłanie oraz dostęp.
Pożądany okres przechowywania z uzasadnieniem oraz potwierdzony, rzeczywiście obowiązujący zakres.
Metoda integracji, wymagane uprawnienia i właściciel danych uwierzytelniających, bez kopiowania sekretów do inwentaryzacji.
Początek pobierania danych, oczekiwane opóźnienie przetwarzania i odtwarzalne zdarzenie testowe.
Zweryfikowana metoda wyszukiwania, najstarszy znaleziony rekord, ostatnia udana kontrola i termin kolejnego przeglądu.
Postępowanie w razie awarii, zmiany źródła, zmiany okresu przechowywania i wycofania integracji.

Informacja produktowa 13 miesięcy, z możliwością wydłużenia do 10 lat nie jest automatycznie wpisywana jako rzeczywisty okres dla każdego istniejącego rekordu. Dla własnego źródła trzeba wyjaśnić zakres, początek obowiązywania i dostęp do danych historycznych. Nie można też zakładać wstecznego importu starych danych ani odzyskania danych, których okres przechowywania już upłynął.

Przykład źródła pilotażowego

Poniższy przykład to zapis planistyczny, a nie konfiguracja Sophos ani zweryfikowany konektor. Wartości są dowolnie dobranymi wymaganiami fikcyjnej organizacji:

Źródło: wewnętrzna aplikacja biznesowa, środowisko testowe
Zdarzenia: udane logowanie i administracyjna zmiana roli
Cel: ustalić, kto zmienił uprawnienie
Wymagane pola: czas zdarzenia ze strefą czasową, konto testowe, działanie, wynik
Pożądany okres przechowywania: 24 miesiące
Uzasadnienie: okres dochodzenia zatwierdzony wewnętrznie
Potwierdzony zakres: do wyjaśnienia przed zamówieniem i pilotażem
Połączenie i metoda wyszukiwania: do potwierdzenia dla tego źródła niestandardowego
Test: zatwierdzona zmiana roli na dedykowanym koncie testowym
Wycofanie zmiany: przywrócić początkową rolę i sprawdzić zmianę
Zespoły odpowiedzialne: zespół aplikacji wspólnie z zespołem operacji bezpieczeństwa

24 miesiące to tutaj wymaganie wewnętrzne, a nie ogólny termin ustawowy ani standard produktu. Jest to okres dłuższy niż opisana standardowa retencja, dlatego przed zatwierdzeniem trzeba potwierdzić odpowiednie rozszerzenie. Konta i zdarzenia należy zastąpić własnymi zatwierdzonymi danymi testowymi. Na potrzeby tego testu nie zmienia się uprawnień produkcyjnych.

Oddzielny odbiór pobierania i przechowywania danych

Na potrzeby pilotażu zapisuje się stan początkowy i początek pobierania danych. Dotychczasowe ścieżki przesyłania logów pozostają zachowane do czasu odbioru nowego źródła. Następnie generuje się nieszkodliwe, zatwierdzone zdarzenie należące do planowanej kategorii. W przykładzie rola konta testowego zostaje zmieniona, a później przywrócona do udokumentowanej wartości początkowej.

Po oczekiwanym czasie przetwarzania, korzystając z potwierdzonej dla tego źródła metody wyszukiwania lub analizy, sprawdza się:

Czy dokładnie to zdarzenie testowe znajduje się we właściwej dzierżawie?
Czy system źródłowy, czas zdarzenia, działanie i wynik zgadzają się z dowodem ze źródła?
Czy wymagane pola są zmapowane w zrozumiały sposób, zamiast występować wyłącznie jako nieużyteczny surowy tekst?
Czy można prześledzić kolejne oczekiwane zdarzenia z okresu pilotażu?

Nowo znaleziony rekord dowodzi pobrania danych w tym teście, a nie wieloletniego przechowywania. Przy odbiorze retencji porównuje się dodatkowo potwierdzony zakres z rzeczywistym ustawieniem lub potwierdzeniem dotyczącym konkretnej dzierżawy. Istniejące dane historyczne sprawdza się w wybranym oknie czasowym, zapisując najstarszy znaleziony rekord i znane luki. Dla nowego źródła bez historii dokumentuje się, że długoterminowe przechowywanie nie zostało jeszcze wykazane upływem czasu, i planuje późniejsze kontrole.

Kontrola pobierania danych nie wymaga alertu bezpieczeństwa. Zwykłe zdarzenie audytowe może być potrzebne jako rekord, mimo że nie powstaje z niego incydent. Data Collection i Live Discover wyjaśnia istniejące zapytania XDR; nie wynika z tego jednak uniwersalne zapytanie dla nowego źródła niestandardowego.

Zawężanie przyczyn błędów i bezpieczne cofanie zmian

Jeśli brakuje dodatku lub funkcji, najpierw sprawdza się dzierżawę, rzeczywisty stan aktualizacji do Fusion i potwierdzony zakres dodatku. Nie tworzy się drugiej integracji na próbę ani nie zmienia polityki ochrony endpointów, aby usunąć domniemany brak licencji.

Jeśli brakuje bieżących zdarzeń, najpierw porównuje się dowód ze źródła z początkiem pobierania danych, kategorią zdarzeń, uwierzytelnianiem, formatem i uzgodnionym opóźnieniem przetwarzania. Jeśli rekordy istnieją, ale są nieużyteczne, sprawdza się mapowanie pól i odniesienia czasowe. Jeśli brakuje tylko starszych zdarzeń, oddzielnie analizuje się początek pobierania danych, luki, rzeczywistą retencję i okno wyszukiwania. Późniejsze wydłużenie retencji nie jest gwarantowanym sposobem naprawy brakujących już danych.

Przed skróceniem okresu przechowywania lub wycofaniem integracji ustala się z odpowiedzialnymi osobami, jakie dane nadal są potrzebne i jak można je zabezpieczyć, o ile jest to obsługiwane i konieczne. Nie wolno zakładać, że późniejszy powrót do starej wartości odtworzy utraconą historię. Usunięcie integracji również nie dowodzi usunięcia danych już pobranych.

W razie nieudanego pilotażu cofa się wyłącznie udokumentowaną zmianę w źródle pilotażowym, zgodnie z potwierdzoną dla niego procedurą powrotu. Współdzielone dane uwierzytelniające, kolektory i inne źródła pozostają nietknięte. Następnie sprawdza się przywrócony stan źródła oraz nadal potrzebną starą ścieżkę przesyłania logów. Usuwanie danych i rezygnację z dodatku ustala się osobno z partnerem lub właściwymi osobami; ten artykuł nie obiecuje uniwersalnego przełącznika do tych działań.

Do przekazania do eksploatacji potrzebne są inwentaryzacja źródeł, potwierdzony zakres, dowody pilotażu, otwarte luki historyczne, odpowiedzialność w razie awarii i termin przeglądu. Jeśli format danych, metoda wyszukiwania lub retencja wymaganego źródła pozostają nieustalone, to źródło nie jest jeszcze odebrane. Do eskalacji wystarczą początkowo przypisanie do dzierżawy, okno czasowe, kategoria zdarzeń i oczyszczone dowody błędów; zgłoszenie nie powinno zawierać sekretów ani zbędnych surowych danych osobowych.