Przejdz do tresci
Avanet
Zaloguj sie

Tworzenie, testowanie i obsługa Custom Parsers w Sophos SIEM

Sophos Fusion Admin Sophos SIEM

Custom Parser przypisuje pola komunikatu logu do standardowych schematów zdarzeń Sophos XDR. Pomaga, gdy dane z podłączonego źródła nie są prawidłowo normalizowane. Praca odbywa się w Security Operations > Integrations > Custom Parsers: utworzenie parsera, testy z różnymi pojedynczymi komunikatami, sprawdzenie faktycznego mapowania i dopiero potem włączenie. Wymagana jest subskrypcja Next-Gen SIEM oraz rola Admin lub Super Admin; pozostałe role mogą tylko przeglądać listę skonfigurowanych parserów.

Parser nie konfiguruje transportu logów. Najpierw źródło musi dostarczać dane; omówienie SIEM rozdziela ingestowanie, normalizację i detekcję. W przypadku obsługiwanej integracji należy najpierw zapewnić oczekiwany format źródła, zamiast przedwcześnie zastępować globalną logikę parsera.

Przygotowanie źródła, schematu i wycofania

Przed rozpoczęciem zapisać produkt źródłowy, format, typy zdarzeń, odniesienie czasowe i wymaganą analizę. Sophos obsługuje CEF, LEEF, JSON, XML oraz komunikaty niestrukturalne. Każdy istotny wariant wymaga oczyszczonego przykładu: udanego i nieudanego logowania, brakujących pól opcjonalnych oraz różnych użytkowników czy adresów. Usunąć sekrety, zachowując strukturę potrzebną do parsowania.

Schemat docelowy opisuje rodzaj zdarzenia. Przykładowo logowanie pasuje do Auth, połączenie sieciowe do Netflow, a zapytanie DNS do DNS. Custom Parsers obsługują tylko część wszystkich schematów XDR. W Data Lake Search > Schema Library sprawdzić schematy i pola dostępne do wyszukiwania; dokumentacja normalizacji wskazuje też odpowiednie pola parsera i typy danych. Sama nazwa pola nie dowodzi, że źródło dostarcza jego wartość.

W dokumentacji zmiany zapisać nazwę parsera, właściciela, format źródła, wymagane pola docelowe, komunikaty testowe i wcześniejsze przetwarzanie. Dla istniejącego parsera zabezpieczyć poprzedni skrypt w miejscu z ograniczonym dostępem. Wycofanie powinno obywać się bez usuwania: nowe parsery początkowo pozostają wyłączone, a w razie problemów należy je ponownie wyłączyć lub kontrolowanie przywrócić zapisany skrypt. Sophos nie utrzymuje ani nie aktualizuje Custom Parsers; odpowiada za nie operator.

Wybór Standalone, Parent lub Child

  • Standalone odpowiada źródłu z dokładnie jednym typem komunikatu i jednym schematem docelowym.
  • Parent rozpoznaje źródło i przygotowuje wspólne wartości. Sophos zaleca scwx.generic jako schemat docelowy. Powiązane Child Parsers normalizują poszczególne typy zdarzeń.
  • Child wymaga Parent i odpowiedniego końcowego schematu. Zmienne i pola Parent są dostępne dla Child.

Firewall może dostarczać logowania, połączenia sieciowe i zdarzenia HTTP. Parent rozpoznaje wspólny format, a trzy Children obsługują różne treści. Własny Child Parser nie może mieć kolejnych Child Parsers. Jedno proste źródło nie wymaga automatycznie takiego podziału.

Utworzenie parsera i jednoznaczne rozpoznawanie źródła

  1. Otworzyć Security Operations > Integrations > Custom Parsers i wybrać Add Custom Parser.
  2. Nadać zrozumiałą nazwę, np. EXAMPLE_APP_JSON_AUTH. To dowolny przykład; nazwa powinna wskazywać produkt, format i zadanie.
  3. Wybrać Parent, Child lub Standalone. Dla Child wskazać właściwy Parent, a następnie format źródła i schemat docelowy.
  4. Otworzyć edytor przyciskiem Create. Wygenerowany szkielet zawiera funkcję podziału właściwą dla wybranego formatu.

Confirm String określa, czy komunikat należy do parsera. !CONFIRMWITH=PATTERN wybiera wyrażenie regularne zgodne z Go; !CONFIRMWITH=EXPRESSION warunek zwracający prawdę lub fałsz. Właściwe wyrażenie znajduje się w obu przypadkach w !CONFIRMSTRING w bloku deklaracji skryptu. Musi wystarczająco dokładnie identyfikować źródło i ewentualny typ zdarzenia. Ogólne słowo, takie jak „network”, jest zwykle zbyt szerokie. Pełny szablon w podlinkowanym poniżej praktycznym przykładzie HTTP/parsera pokazuje razem tryb i matcher; jego wąski format laboratoryjny nie jest zamienny z poniższym fragmentem example-auth.

Nawet parser poprawny składniowo może przechwytywać komunikaty innych źródeł. Sophos nie gwarantuje stałej kolejności dla wszystkich możliwych kolizji parserów. Przetestować również co najmniej jeden podobny komunikat, który nie powinien pasować. Później w extractor path sprawdzić, jaki Parent i Child faktycznie zostały użyte.

Mapowanie pól i kontrola znaczników czasu

Skrypt rozróżnia zmienne lokalne i pola parsera zakończone $. Normalizowane są tylko pola zgodne ze schematem docelowym; dowolna własna nazwa z $ nie tworzy nowego pola schematu. Pola schematu często używają snake_case, a parsera camelCase. Dokładną pisownię sprawdzić w wybranym schemacie.

Ten fikcyjny JSON stanowi niewielki punkt wyjścia do mapowania Auth:

{"product":"example-auth","user":"pilot-user","src_ip":"192.0.2.25","time":"2026-10-27T10:15:00Z","result":"success"}

192.0.2.25 jest adresem dokumentacyjnym, nie celem produkcyjnym. Fragment skryptu JSON może odczytać użytkownika i adres źródłowy następująco:

json = JSON(originalData$)
sourceUserName$ = json["$.user"]
sourceAddress$ = json["$.src_ip"]

Pełny szablon dla ściśle określonego formatu syntetycznego, obejmujący czas, mapowanie enum i odbiór wyszukiwania, znajduje się w przykładzie HTTP i parsera.

Ten fragment nie jest kompletną definicją parsera. Celowo brakuje Confirm String, schematu, czasu, akcji uwierzytelniania i wyniku; trzeba je dopasować do rzeczywistego formatu. W szczególności nie kopiować tekstu success bez kontroli do numerycznego pola enum. Schemat Auth definiuje np. SUCCESS i FAILED dla action_result; ich mapowanie w parserze wymaga osobnej weryfikacji.

Dla czasu porównać wartość surową, strefę czasową i znormalizowane event_time_usec. Funkcja DATETIME() używa wzorców czasu Go. Błędna strefa może dać technicznie udaną, ale czasowo niepoprawną analizę. Sprawdzić również wspólne wartości pobrane przez Root Parser względem źródła.

Pola powtarzane, takie jak wiele załączników, wskaźników lub rekordów metadanych, wymagają list obiektów zgodnych ze schematem. Tekst rozdzielony przecinkami nie zastępuje tej struktury. ADDFIELD() może łączyć tablice w powtarzane obiekty; w tablicach JSON należy zachować powiązane pozycje. Brakujące wartości nie mogą np. przypisać skrótu do niewłaściwego typu pliku.

Testowanie pojedynczych komunikatów i odczyt wyników

Jeżeli źródło już wysyła dane, odpowiednich surowych komunikatów można szukać w Data Lake Search za pomocą FROM generic WHERE sensor_id='[my data source]'. Zastąpić symbol identyfikatorem źródła zweryfikowanym w rzeczywistych zdarzeniach. W szczegółach zdarzenia wybrać Original Data > Copy Original Data i wkleić do Sample Message w edytorze. Można też użyć jednej oczyszczonej linii logu, a nie całego pliku.

  1. Najpierw sprawdzić podział przez Parse Message. Parsed Source Message pokazuje pary klucz/wartość dla formatów strukturalnych lub indeksowane części komunikatów niestrukturalnych.
  2. W Source Destination Mapping sprawdzić przypisanie wartości źródłowych do pól. Osobno porównać użytkownika, adresy źródła/celu, czas, akcję i wynik z surowym komunikatem.
  3. Sprawdzić extractor path. Musi wskazywać zamierzoną ścieżkę. Ostrzeżenie o innym parserze nie jest kosmetycznym komunikatem.
  4. Dodać dalsze reprezentatywne oraz celowo niepasujące komunikaty. Przy Parent/Child sprawdzić zarówno wspólne rozpoznawanie, jak i wybór Child.
  5. Uruchomić Run Test dla wszystkich zapisanych próbek i porównać schemat, wartości oraz ścieżkę. Sophos zaleca powtarzane testy, około 12–15 uruchomień, aby wykryć zmienne błędne dopasowania. Konkretna liczba nie gwarantuje poprawnego przetwarzania wszystkich przyszłych komunikatów.

Narzędzia testowe sprawdzają aktualną zawartość edytora, lecz jej nie zapisują. Wyłączony niepoprawny parser może zostać zapisany; sam zapis nie stanowi więc odbioru funkcjonalnego. Gdy brakuje pól, najpierw sprawdzić treść źródła, typ danych, dokładne nazwy pól i ewentualny podział komunikatu.

Zapis i kontrolowane włączenie

Dla nowego parsera Save and Continue zapisuje projekt. Nowe parsery są domyślnie wyłączone. Po testach opuścić edytor przez Exit, wybrać ikonę Play w Actions na liście i potwierdzić Enable. W strukturze Parent/Child najpierw włączyć Parent, potem Children.

Po włączeniu wygenerować zatwierdzone nieszkodliwe zdarzenie źródłowe lub jednoznacznie skorelować już oczekiwane zdarzenie. Szukać znormalizowanych wyników według źródła, czasu, schematu i wymaganych pól. Sophos podaje np. WHERE sensor_type=[your_sensor_type]; symbol oznacza faktycznie istniejący typ sensora, nie gotowe zapytanie do skopiowania.

Przetwarzanie do dodatkowych schematów odbywa się obok zdarzeń generycznych. Wynik wyszukiwania dowodzi początkowo tylko sprawdzonej normalizacji. Automatyczne detektory nie są gwarantowane dla każdego własnego źródła. Udokumentowane ścieżki obejmują DGA i Domain Watchlist przez DNS query_name oraz IP Watchlist przez adresy źródłowe/docelowe w NIDS lub Netflow. Wymaganą detekcję odebrać osobno; zwykłe zdarzenie testowe nie musi generować alarmu.

Reguły klienta i odpowiedzialność MDR

is_custom_alert, a w Email vendor_alert_details.is_custom_alert, oznacza pochodzenie reguły alarmowej. Według dokumentacji schematów detekcje tak oznaczone jako Custom Alert z true trafiają bezpośrednio do tenanta do samodzielnej obsługi i nie wchodzą do kolejki usługi MDR; ich ważność się nie zmienia. Nie ustawiać flagi tak, aby alarm klienta wyglądał jak niezmodyfikowana detekcja dostawcy.

Nie znaczy to, że każdy komunikat znormalizowany przez Custom Parser automatycznie podlega temu wyłączeniu. Zdarzenie źródłowe, wynikowa detekcja i właściciel sprawy to osobne zagadnienia. Artykuł o Cases i Rules wyjaśnia istniejącą granicę dla Self-managed Cases z reguł klienta.

Diagnostyka i bezpieczne wycofanie

Niewłaściwy parser w extractor path: Porównać Confirm Strings odpowiednich parserów. Przy kolizji z globalnym parserem poprosić Sophos Support o sprawdzenie precyzji dopasowania, zamiast dokładać kolejne szerokie overrides.

Komunikat tylko w generic: Sprawdzić transport i surowy komunikat, następnie Confirm String, aktywny parser i schemat. Sam brak znormalizowanego wyniku nie dowodzi awarii transportu.

Skrypt poprawny, wartości błędne: Porównać komunikat i mapowanie pole po polu, szczególnie czas i enumy. W aktywnym parserze kontrolowanie przywrócić zapisaną wersję po błędnej zmianie i sprawdzić ponownie.

Nowy błędny parser wyłączyć przez ikonę Pause i Disable. W hierarchii wszystkie Children muszą być wyłączone lub usunięte przed wyłączeniem Parent. Dodatkowa normalizacja zatrzymuje się natychmiast, lecz zdarzenia generyczne nadal powstają. Wycofanie nie poprawia automatycznie wcześniej błędnie znormalizowanych danych historycznych ani wynikłych detekcji.

Usunięcia przez ikonę kosza i Delete nie można cofnąć. Przy pierwszym wycofaniu zwykle wystarczy wyłączenie. Trwałe usunięcie rozważyć dopiero po zabezpieczeniu konfiguracji, wyjaśnieniu zależności i zakończeniu odbioru.

Globalnych parserów nie można edytować bezpośrednio. Override zastępuje ich przetwarzanie dla danego przypadku, a Extension dodaje dotąd nienormalizowane typy zdarzeń. Oba wymagają prawidłowego powiązania z globalnym Parent i własnego utrzymania. Bez jednoznacznej nazwy i zweryfikowanego mapowania pozostawić istniejącą ścieżkę globalną; nie naprawiać na produkcji strefy czasowej lub nowego formatu niesprawdzonym Override.