Sophos SIEM: wybór transportu i konfiguracja HTTP Ingest

HTTP Ingest odbiera logi przez endpoint HTTPS udostępniony przez Sophos. Źródło musi obsługiwać HTTP POST do webhooka lub endpointu HTTP z uwierzytelnianiem tokenem Bearer. Wymagana jest subskrypcja Sophos Next-Gen SIEM; sama istniejąca licencja XDR nie wystarcza.

To trzy oddzielne zadania: wybór transportu, podłączenie źródła i sprawdzenie rzeczywistych zdarzeń. Utworzenie konektora nie dowodzi poprawnej normalizacji ani detekcji. Przed pilotażem należy sprawdzić podstawy SIEM i licencje.

Jaki transport pasuje do źródła?

Custom służy źródłom bez odpowiedniej zoptymalizowanej integracji Sophos. Najpierw należy sprawdzić w Marketplace integrację produktu i faktyczne kategorie zdarzeń. Znana nazwa dostawcy nie oznacza obsługi każdego typu jego logów.

Dostępnych jest sześć metod:

• HTTP Ingest: bezpośrednie HTTPS POST z Bearer, bez własnej infrastruktury chmurowej do utrzymania.
• Customer-Managed S3: logi we własnym buckecie AWS, przekazywane przez dostarczoną konfigurację Lambda/CloudFormation.
• S3 Ingest – Sophos-Managed (with token): cel zarządzany przez Sophos z potwierdzeniem własności wymaganym przez dostawcę.
• S3 Ingest – Sophos-Managed (without token): ten sam model bez takiego sprawdzania.
• Azure Event Hubs: strumień zdarzeń w dostępnym hubie.
• Azure Storage Account: pliki w Blob Storage przekazywane przez Azure Function.

Instrukcja S3 rozróżnia trzy warianty bucketów. Instrukcja Azure oddziela Event Hubs od Storage/Function. Urządzenie syslog może wymagać XDR Data Collector; jego IP nie zastępuje endpointu HTTP Ingest.

Przygotowanie pilotażu i danych dostępowych

Należy zapisać tenant, uprawnienie SIEM, źródło, kategorię i właściciela. Ogólna konfiguracja integracji wymaga odpowiedniej roli Admin lub Super Admin i dostępu do eksportu źródła. Dokumentacja źródła musi wyjaśniać URL, Bearer, format i zachowanie transmisji; nie zakłada się tutaj uniwersalnego JSON.

Wybrać zatwierdzone źródło testowe i nieszkodliwe, rozpoznawalne zdarzenie. Zapisać czas ze strefą, identyfikator i oczekiwane pola. Dotychczasowe ścieżki pozostają do odbioru; dodatkowe przekazywanie nie może tworzyć przypadkowych duplikatów ani przesyłać niezatwierdzonych danych osobowych.

Integration Key i URL są wyświetlane tylko raz. Wcześniej przygotować zatwierdzony magazyn sekretów. Klucze nie mogą trafić do zrzutów, zgłoszeń, publicznych repozytoriów ani poleceń zachowanych w historii powłoki. Udokumentować właściciela i kontrolowaną rotację. Integration Credential Manager obsługuje wybrane typy, a nie dowolny klucz ingestii.

Utworzenie HTTP Ingest w Sophos Fusion

1. Otworzyć Security Operations > Integrations > Marketplace > Custom.
2. Przy HTTP Ingest wybrać Set Up.
3. Podać unikalną nazwę, np. Aplikacja-Test-HTTP, i Done. To dowolna etykieta pozwalająca rozpoznać źródło i środowisko.
4. Natychmiast zapisać Integration Key i URL w bezpiecznym magazynie. Nie będą ponownie pokazane. Bez bezpiecznej kopii wstrzymać podłączenie i ustalić obsługiwaną wymianę; nie obiecuje się późniejszego odczytu.
5. Skonfigurować udokumentowany eksport HTTPS źródła dokładnie tymi wartościami. Sprawdzić Bearer, format i ewentualne ponawianie/buforowanie według instrukcji źródła. Nie używać wymyślonego payloadu ani szablonu innego API.
6. Znaleźć połączenie w Configured integrations na stronie Custom, wysłać zaplanowane zdarzenie i osobno potwierdzić pobranie.

Własne źródło syntetyczne wraz z pełnym szablonem parsera i zapytaniami opisuje przykład HTTP i parsera. Oczekiwane wyniki są tam wyraźnie oddzielone od praktycznego testu w tenancie, który nadal czeka na wykonanie.

Odbiór transportu, normalizacji i analizy

Custom Integration zapewnia najpierw transport do XDR. Wspierane typy korzystają z istniejącej normalizacji; własne lub niewspierane formaty mogą trafić do generic. Model parserów w artykule SIEM wyjaśnia potrzebę dodatkowego parsera i wymaganych pól.

Na potrzeby odbioru otworzyć Security Operations > Integrations > Configured Data Sources i wybrać własne źródło. W szczegółach źródła Advanced Search pokazuje przygotowane wyszukiwanie dla jego identyfikatora sensora z ostatnich 24 godzin. Zawęzić czas do momentu testu i porównać tenant, identyfikator źródła, czas zdarzenia, akcję i wymagane pola z wysłanym zdarzeniem. Odbiór integracji opisuje punkt wejścia, a Data Lake Search dalsze zawężanie wyszukiwania.

Zielony status wskazuje połączenie, nie kompletność ani poprawny schemat. Wynik jako surowy tekst generic nie dowodzi przydatności dla wybranego detektora. Brak wyników prostego wyszukiwania nie wyklucza danych generic.

Zaakceptować pilotaż dopiero po oddzielnym potwierdzeniu transportu, użytecznego mapowania i wyszukiwania. Testować detekcję tylko przy przewidzianej odpowiedniej wspieranej logice. Zwykły audyt lub logowanie nie musi wywoływać alarmu.

Błędy i kontrolowane wycofanie

Gdy brak danych, najpierw sprawdzić rzeczywistą wysyłkę, endpoint i użycie klucza jako Bearer. Następnie błędy źródła, sieć, przedział czasu i status. Sukces HTTP nie zastępuje potwierdzenia zdarzenia. Przy złym mapowaniu sprawdzać format/parser, zamiast profilaktycznie tworzyć drugi konektor.

Przerwę realizować udokumentowanym zatrzymaniem eksportu źródła. Przed wycofaniem ustalić zależności, dowody historyczne i retencję. Zatrzymać tylko tę ścieżkę i sprawdzić poprzednią nadal potrzebną. Usunięcie integracji, unieważnienie klucza i skasowanie historii są różnymi operacjami bez uniwersalnego przełącznika. Przy utracie lub kompromitacji klucza ustalić z Sophos wspieraną wymianę/unieważnienie, nie improwizować nieprzetestowanej rotacji.