Follow Środowisko przedsiębiorstwa emituje miliony zdarzeń co godzinę. Podczas incydentu osoba reagująca rzadko potrzebuje ich wszystkich. Potrzebuje tych kilku setek, które opowiadają historię: wybuch porażek 4625, po których następuje jedno udane 4624, zaszyfrowany PowerShell uruchomiony przez winword.exe, nowa usługa zainstalowana o 03:12 na kontrolerze domeny. Analiza logów jest dyscypliną polegająca na przejściu od pierwszej liczby do drugiej na tyle szybko, aby miało to znaczenie.
To zadanie stało się trudniejsze w dwóch kierunkach jednocześnie. Atakujący korzystający z narzędzi AI generują dowody z prędkością maszyny i wypełniają rzeczywiste działania aktywnością wyglądającą na nieszkodliwą. Tymczasem oczywista droga na skróty, polegająca na zaciąganiu logów do dużych modeli językowych (LLM), napotyka ograniczenia związane z szynami bezpieczeństwa, oknami kontekstu i obowiązkami dotyczącymi ochrony danych. Zespół reagujący Hugging Face napotkał dokładnie tę przeszkodę w lipcu 2026 roku, kiedy mniej więcej 17 000 zdarzeń zostało odrzuconych przez modele bazowe i musiało zostać przetworzonych na lokalnym modelu zamiast tego.
Poniżej omówimy analizę logów od początku do końca, a następnie przyjrzymy się LogTotal, bezpłatnemu rozwiązaniu SOC Prime odpowiadającemu na problem w czasie incydentu.
Jakie są podstawy analizy logów?
Każdy przepływ pracy analizy logów, nieważne czy działa w SIEM, jeziorze danych czy na laptopie osoby reagującej, opiera się na tych samych pięciu etapach. Pominięcie jednego z nich zwykle skutkuje później jako przeoczona detekcja lub fałszywy alarm, którego nikt nie potrafi wyjaśnić.
- Zbieranie. Agenci, przekazujący Syslog, sondy API i eksporty cloud-native przenoszą zdarzenia z źródła. Luki tutaj są ciche: konfiguracja Sysmon, która pomija identyfikator zdarzenia 10 (dostęp do procesu), oznacza, że wyciek danych przez LSASS nigdy się nie pojawia w dalszym ciągu.
- Parsowanie i normalizacja. Surowe linie stają się polami. Źródłowy adres IP powinien być tym samym polem, niezależnie od tego, czy pochodzi z zapory, IdP czy EDR, dlatego istnieją schematy takie jak ECS i OCSF.
- Wzbogacanie. Krytyczność zasobu, rola użytkownika, GeoIP i inteligencja o zagrożeniach zmieniają adres IP w kontekst, na którym analityk może działać.
- Korelacja. Pojedyncze zdarzenia rzadko dowodzą czegokolwiek. Łączenie ich przez hosta, użytkownika, GUID procesu lub identyfikator sesji to sposób tworzenia narracji o ataku.
- Przechowywanie i integralność. Gorące magazynowanie do wyszukiwania, zimne magazynowanie do badań kryminalistycznych oraz dowody manipulacyjne, by zapis był trwały.
Co to jest analiza logów?
Analiza logów to proces badania rekordów generowanych przez maszyny w celu odtworzenia tego, co się wydarzyło w systemie, zdecydowania, czy ma to znaczenie oraz ustalenia, co należy zrobić dalej. W operacjach bezpieczeństwa odpowiada na pięć pytań dotyczących każdej podejrzanej aktywności: kto działał, na jakim zasobie, kiedy, skąd i za pomocą jakiego mechanizmu.
Jest to inne niż zarządzanie logami. Zarządzanie to hydraulika: wciąganie, przechowywanie, przechowywanie danych, kontrola dostępu. Analiza to interpretacja. Zespół może mieć dobrze funkcjonującą linię przetwarzania logów i nadal przegapić włamanie, ponieważ nikt, ani człowiek, ani maszyna, nie zadaje właściwych pytań dotyczących danych.
W praktyce analiza logów działa w trzech trybach:
- Detekcja. Zasady i modele oceniają zdarzenia w sposób ciągły i podnoszą alerty, gdy pojawia się znane złośliwe zachowanie.
- Badanie. Po wystąpieniu alertu lub wskazówki, analitycy przechodzą przez powiązane zdarzenia, aby określić zakładkę incydentu i znaleźć przyczynę podstawową.
- Polowanie na zagrożenia. Analitycy zaczynają od hipotezy, takiej jak nadużycie konkretnego LOLBin, i szukają proaktywnie dowodów, które przegapiła warstwa wykrywania.
Z wszystkich zespołów korzystających z logów, bezpieczeństwo ma najmniej miejsca na luki.
Dlaczego analiza logów jest tak ważna?
Ponieważ czas wpływa na koszt naruszenia, a logi to miejsce, gdzie czas jest wygrany lub stracony. Raport IBM z 2026 roku o kosztach naruszenia danych ustala średni czas zidentyfikowania i zapanowania nad naruszeniem na 247 dni, co jest pierwszym wzrostem od pięciu lat. Naruszenia życia powyżej 200 dni średnio kosztowały 5,65 miliona dolarów w porównaniu do 4,32 miliona dolarów dla tych opanowanych szybciej.
Poza kosztami, analiza logów wspiera cztery obowiązki, jakie niesie każdy program bezpieczeństwa:
- Detekcja. EDR i NDR widzą skrawki aktywności. Logi z dostawców tożsamości, ślady audytowe SaaS i płaszczyzny sterujące chmurą wypełniają luki między nimi.
- Zakres i przyczyna podstawowa. Bez dowodów na poziomie zdarzeń, osoby reagujące nie mogą powiedzieć, które konta zostały dotknięte lub jak atakujący dostał się, więc działanie naprawcze staje się zgadywaniem.
- Raportowanie regulacyjne. Wymóg PCI DSS 4.0 10 nakłada obowiązek przeglądu logów audytowych i 12 miesięcy przechowywania. Formularz SEC 8-K Punkt 1.05 daje notowanym firmom cztery dni robocze od ustalenia materialności, co jest niemożliwe bez szybkiego określenia zakresu.
- Inżynieria detekcji. Rzeczywista telemetria to sposób, w jaki zasady są testowane i dostrajane.
Jest jednak haczyk. Te same logi, które to wszystko umożliwiają, zawierają nazwy użytkowników, adresy IP, pliki cookies sesji i tokeny nosicieli. Dobra analiza coraz częściej oznacza analizowanie ich w sposób bezpieczny.
Jakie są rodzaje danych logów?
Logi związane z bezpieczeństwem dzielą się na sześć rodzin. Każda odpowiada na inne pytanie, a badanie opierające się na tylko jednej lub dwóch z nich będzie miało ślepe punkty, w których atakujący może działać.
| Rodzina logów | Typowe źródła | Co mówi analitykowi |
| Punkty końcowe i system operacyjny | Zabezpieczenia Windows (4624, 4688, 7045), Sysmon, Linux auditd, journald | Który proces został uruchomiony, pod jakim kontem, z jakim rodzicem i wierszem poleceń |
| Tożsamość | Active Directory (4768, 4769), logowania Entra ID, System Log Okta | Kto się uwierzytelnił, skąd, z jakim protokołem i wynikiem MFA |
| Sieć | Zapora, DNS, serwer proxy, Zeek, NetFlow | Kto do kogo mówił, ile danych przesunięto, które domeny zostały rozwiązane |
| Płaszczyzna sterowania chmurą | AWS CloudTrail, Dziennik aktywności Azure, dzienniki audytu GCP, audyt Kubernetes | Które wywołania API zmieniły infrastrukturę, role lub polityki |
| Aplikacje i SaaS | Dzienniki dostępu serwera WWW, zintegrowany dziennik Microsoft 365, Google Workspace | Co użytkownicy zrobili w aplikacjach biznesowych i składowiskach danych |
| Kontrolki bezpieczeństwa | EDR, IDS/IPS (Suricata), WAF, bramka pocztowa | Co inne narzędzia już oznaczyły, i dlaczego |
Najbardziej wartościowe odkrycia z reguły pojawiają się na szwach. Próba Kerberoastingu pojawia się jako klaster żądań 4769 z szyfrowaniem RC4 w dziennikach tożsamości. Udowodnienie, co atakujący zrobił z przełamanym kontem usługi, wymaga danych punktu końcowego i chmury.
Jakie są popularne formaty i struktury plików logów?
Logi obejmują od w pełni ustrukturyzowanych do wolnego tekstu, a obciążenie związane z parsowaniem rośnie odpowiednio. Cztery formaty obejmują większość tego, co SOC obsługuje na co dzień.
Syslog. Wciąż język uniwersalny dla urządzeń sieciowych i hostów Unix. RFC 3164 (BSD syslog) jest luźno zdefiniowany i ubogi w stemple czasowe. RFC 5424 dodaje pole wersji, stemple czasowe ISO 8601, MSGID i blok STRUCTURED-DATA, ale treść wiadomości często jest specyficzna dla dostawcy.
CEF. Format wspólnego zdarzenia ArcSight umieszcza zdarzenia w nagłówku oddzielanym pionową kreską, a następnie rozszerzenia z klucz=wartość:
CEF:0|Acme|FW|7.2|4625|Logon failure|5|src=10.1.4.22 suser=jdoe dst=10.1.0.5
Jest łatwy do parsowania, ale płytki, a sprzedawcy różnie mapują pola. LEEF, wykorzystywany przez QRadar, opiera się na tym samym pomyśle.
JSON i NDJSON. Domyślny dla dzienników audytowych chmury i SaaS. Jeden obiekt na wiersz sprawia, że NDJSON to format, który można strumieniować, podczas gdy głębokie zagnieżdżanie i tablice komplikują spłaszczanie do ustalonego schematu.
Windows EVTX. Format binarny z rekordami podzielonymi na fragmenty zawierającymi dane zdarzeń XML. Nie można go przeszukiwać; wymaga dedykowanego parsera, a przydatne pola żyją w EventData.
Praktyczny test dla każdego narzędzia analitycznego polega na tym, czy przyjmuje wszystkie cztery formy natywnie, bez konieczności konwersji skryptów przez analizanta podczas incydentu.
Monitorowanie logów w czasie rzeczywistym
Monitorowanie w czasie rzeczywistym polega na ocenie zdarzeń w miarę ich przybycia, a nie w harmonogramie wyszukiwania. Zaplanowane zapytanie SIEM działające co 15 minut w oknie widoku wstecz 20 minut, za kilkoma minutami opóźnienia przetwarzania i indeksowania, może łatwo wprowadzić pół godziny między akcją atakującego a pierwszym alertem.
Architektury strumieniowe zamykają tę lukę, przesuwając logikę wykrywania na wcześniejszy etap. Zdarzenia przepływają przez magistralę taką jak Kafka lub kanał taki jak Cribl Stream, a zasady są oceniane w locie z użyciem okien stanowych dla liczników i sekwencji. Tylko wzbogacone, oznaczone zdarzenia i alerty trafiają do SIEM, co również zmniejsza koszty przyjęcia.
Przychodzą z tym trzy problemy inżynieryjne:
- Opóźnione i nieuporządkowane zdarzenia. Okna potrzebują tzw. znaczników wodnych lub okresów łaski, inaczej sekwencja rozdzielona na opóźnioną paczkę nigdy się nie zakończy.
- Zarządzanie stanem. Śledzenie 10 000 hostów w 30-minutowym oknie to problem związany z pamięcią, nie zapytaniem.
- Wolumen alertów. Szybsze wykrycie głośnych zasad tylko szybciej produkuje hałas.
Strumieniowe potoki mają również ślepy punkt w swoim zamyśle. Widzą tylko to, co do nich podłączono. Logi pobrane z odizolowanego serwera, laptopa kontrahenta lub nowo nabytej spółki zależnej wciąż potrzebują szybkiej, samodzielnej analizy.
Jakie są główne techniki rozpoznawania wzorców w logach?
Rozpoznawanie wzorców w logach działa w warstwach, od pojedynczych zdarzeń po całe łańcuchy ataków.
- Dopasowanie atomowe. Jedno zdarzenie, jeden warunek: znany zły skrót, rundll32.exe ładowany z zapisywalnej przez użytkownika ścieżki, reguła Sigma na podejrzanym wierszu poleceń. Szybkie i precyzyjne, ale ślepe na wszystko, co jest szkodliwe tylko w kontekście.
- Agregacja i progi. Liczenie w oknie czasowym. Dwadzieścia nieudanych logowań do jednego konta sugeruje brute force; jeden błąd w odniesieniu do dwudziestu kont z tego samego źródła wskazuje na rozpraszanie haseł. Ten sam identyfikator zdarzenia, inny wzorzec.
- Korelacja sekwencji. Zdarzenia uporządkowane w oknie czasowym, takie jak nowy lokalny administrator utworzony, a następnie użyty do logowania RDP w ciągu dziesięciu minut.
- Bazowanie i wykrywanie anomalii. Pary procesów rodzice-dzieci, które pojawiły się po raz pierwszy, rzadkie łańcuchy uruchomieniowe agenta użytkowników, logowania poza normalnymi godzinami użytkownika.
- Korelacja wyższego rzędu. Zasady uruchamiane na wykryciach, a nie na surowych zdarzeniach, łącząc pojedyncze trafienia w łańcuch odwzorowany do taktyk MITRE ATT&CK. To jest warstwa, która zamienia 400 alertów w jeden incydent.
Jakie są niezbędne narzędzia analizy logów?
Żaden pojedynczy produkt nie obejmuje całej pracy. Dojrzałe zespoły łączą narzędzia analizy logów z czterech kategorii.
| Kategoria | Przykłady | Najlepsze w |
| SIEM | Splunk, Microsoft Sentinel, Google SecOps, Elastic Security | Centralizowane wykrywanie, tryb alertów, zarządzanie przypadkami |
| Potoki danych bezpieczeństwa | Cribl Stream, Vector, Fluent Bit | Przekierowywanie, filtrowanie, normalizacja i kontrola kosztów przed przechowywaniem |
| Jeziorka danych | Amazon Security Lake (OCSF), Snowflake, ClickHouse | Tanie długoterminowe przechowywanie i polowanie na dużą skalę |
| Narzędzia DFIR | Hayabusa, Chainsaw, EvtxECmd, Velociraptor | Szybka triage zebranych artefaktów, zwłaszcza EVTX |
Luka ujawnia się podczas reakcji na incydenty. SIEM zakłada, że dane są już wprowadzone. Narzędzia DFIR są szybkie, ale działają na ograniczonym zespole zasad i zostawiają korelację analitykowi. Ogólnoświatowe systemy LLM napotykają limity kontekstu i odmawiają treści bezpieczeństwa. Narzędzie stworzone na pierwszą godzinę incydentu potrzebuje krótkiej listy właściwości:
- natywne wczytywanie EVTX, syslog, CEF i JSON
- duża, utrzymywana biblioteka wykryć, nie kilka setek zasad
- korelacja do łańcuchów ataków, nie płaska lista trafień
- wyniki w minutach na klasycznej infrastrukturze
- model prywatności, który przetrwa przegląd DPO
Dlaczego LogTotal jest jednym z najlepszych?
LogTotal spełnia każdy z wymienionych elementów, a robi to za darmo. SOC Prime udostępniło go jako publiczny podgląd 26 sierpnia 2026 i ogłosiło ogólną wersję 15 października. Przepływ pracy jest prosty: załaduj, odśwież, otrzymaj badanie z powrotem.
| Wymóg | Jak LogTotal spełnia ten wymóg |
| Natywne formaty | Automatycznie wykrywa EVTX, JSON/NDJSON i syslog, bez etapu konwersji |
| Głębokość detekcji | Dopasowuje zdarzenia do około 1 000 000 zasad wykrywania i 13 000 etykiet zagrożeń |
| Korelacja | Wyższe zasady Sigma oraz agentowa korelacja AI łączą łańcuchy ataków odwzorowane do MITRE ATT&CK |
| Szybkość | Do 1,7 miliona zdarzeń w mniej niż minutę, około 100 razy zestawu logów Hugging Face |
| Prywatność | Odświeżenie odbywa się w przeglądarce, nic nie jest przechowywane, a dane klienta nie są wykorzystywane do szkolenia |
Szybkość nie jest sztuczką GPU. Rozumowanie na temat tego, jak wygląda każdy atak, zostało wykonane z wyprzedzeniem i skompilowane do zawartości detekcji, więc silnik dopasowuje i koreluje zamiast generować tokeny.
Model prywatności to, co pozwala LogTotal przejść przez przegląd prawny. Open-source @socprime/logtotal-sanitizer (Apache-2.0) wymienia poświadczenia, adresy IP, nazwy hostów i nazwy użytkowników na stabilne tokeny HMAC, więc jeden użytkownik na trzech hostach zostaje jedną jednostką po zaciemnieniu. Klucz zostaje z tobą. Każda analiza odbywa się na jednorazowej, niezmiennej instancji, która jest usuwana po jej zakończeniu.
Wyniki pojawiają się jako uszeregowane łańcuchy ataków, z flagami dla technik ukrywania i szczytów benign-activity, typowych dla włamań wykorzystywanych przez AI.
Główne trendy w analizie logów w 2026 roku
Pięć zmian przekształca sposób, w jaki zespoły analizują logi w tym roku.
- Ataki w tempie AI zmieniają, jak wygląda „podejrzane”. IBM raportuje, że ponad jedna na cztery organizacje spotkała się z atakiem prowadzonym przez AI, co stanowi 56% wzrost rok do roku. Anomalie objętościowe w klasach zdarzeń wyglądających na nieszkodliwe stają się same w sobie sygnałem wykrywania.
- SIEM się dzieli. Raport Gartnera na temat Hype Cycle for Security Operations z 2026 roku pokazuje, że rynek dzieli się na zintegrowane platformy SOC i jeziorka danych bezpieczeństwa, z agentami AI SOC na szczycie przeszacowanych oczekiwań. Analiza coraz częściej odbywa się tam, gdzie żyją dane.
- Wykrywanie przenosi się do strumieni. Uruchamianie reguł na strumieniu, przed indeksowaniem, zmniejsza średni czas wykrycia oraz koszty zaciągu.
- OCSF staje się wspólnym schematem. Ujednolicone dane to to, co pozwala, by te same wykrycia, lub ten sam agent AI, działały w różnych dostawcach.
- Analiza chroniąca prywatność staje się standardową praktyką. IBM zanotowało udział shadow-AI w 43% incydentów, w porównaniu do 20% wcześniej. Wklejanie surowych logów do chatbota to właśnie to. Pseudonimizacja z kluczem przed tym, jak logi opuszczą organizację, zmienia się z dobrej praktyki na oczekiwanie.
Wspólnym wątkiem jest szybkość bez narażenia. To problem, który LogTotal został stworzony, aby rozwiązać, i nic nie kosztuje przetestowanie go na własnych logach.
