Wdrożenie SIEM — jakie logi zbierać i w jakiej kolejności

SIEM, czyli platforma zbierania i korelacji zdarzeń bezpieczeństwa, pełni w organizacji rolę wspólnego miejsca, w którym spotykają się zapisy z wielu niezależnych systemów. Jego wartość nie polega na samym gromadzeniu danych, lecz na możliwości zestawienia zdarzeń, które osobno nic nie znaczą, a razem układają się w rozpoznawalny wzorzec.

Z tego wynika ograniczenie, o którym warto powiedzieć wprost. Platforma nie wykrywa niczego sama z siebie — wykrywa to, co ktoś wcześniej opisał regułą. Wdrożenie polegające na podłączeniu źródeł i pozostawieniu reszty domyślnej konfiguracji kończy się archiwum, do którego nikt nie zagląda.

Warto też oddzielić dwie funkcje, które w rozmowach bywają mylone. Pierwszą jest wykrywanie, czyli sygnalizowanie zdarzeń wymagających uwagi. Drugą jest dowodzenie, czyli zdolność odtworzenia przebiegu zdarzenia po fakcie. Obie wymagają innych danych i innego okresu przechowywania, a projekt, który tego nie rozstrzyga, zwykle realizuje pierwszą kosztem drugiej.

Rozstrzygnięcie tej kwestii na początku ma skutek finansowy. Dane potrzebne do wykrywania muszą być dostępne natychmiast i przeszukiwane na bieżąco, co jest kosztowne. Dane potrzebne do odtworzenia przebiegu zdarzenia mogą leżeć w tańszym archiwum, z którego pobiera się je rzadko. Projekt traktujący oba zbiory jednakowo płaci najwyższą stawkę za całość.

Typowy plan wdrożenia zakłada podłączenie wszystkich dostępnych źródeł w jednym etapie, ponieważ wydaje się to najszybsze. W praktyce prowadzi to do sytuacji, w której zespół otrzymuje jednocześnie ogromny wolumen danych i żadnej reguły pozwalającej odróżnić w nich zdarzenie istotne od tła.

Podłączanie falami odwraca tę zależność. Każda fala kończy się nie w chwili, gdy dane zaczynają napływać, lecz w chwili, gdy dla tych danych działają reguły, a zespół rozumie, co oznacza wygenerowany przez nie sygnał. Dopiero wtedy rusza kolejna fala.

Podejście to bywa odbierane jako wolniejsze, choć zwykle jest szybsze w rozliczeniu całościowym. Skraca czas od uruchomienia platformy do pierwszego realnie użytecznego sygnału i zapobiega sytuacji, w której trzeba wracać do źródeł podłączonych wcześniej, bo nikt nie zdążył ich opisać.

Widać to szczególnie przy projektach prowadzonych równolegle z innymi zmianami w infrastrukturze. Fala zamknięta i opisana zachowuje wartość niezależnie od tego, co dzieje się dalej, natomiast wdrożenie zatrzymane w połowie jednego wielkiego etapu zostawia po sobie wyłącznie koszt.

Ma też skutek budżetowy. Wolumen danych rośnie stopniowo, więc organizacja poznaje realny koszt utrzymania platformy, zanim zwiąże się z nim na całą skalę środowiska.

Wreszcie fale porządkują rozmowę z właścicielami systemów. Każda z nich wymaga ich udziału przy ustalaniu, co w danym środowisku jest zachowaniem normalnym. Rozłożenie tych rozmów w czasie jest jedynym sposobem, aby faktycznie się odbyły — przy podejściu jednoetapowym są one pierwszą rzeczą, którą się pomija.

Pierwszym krokiem nie jest konfiguracja, lecz odpowiedź na pytanie, co organizacja właściwie posiada. Bez listy systemów, ich właścicieli i wzajemnych zależności nie sposób rozstrzygnąć, które źródła są istotne, a które jedynie dostępne.

Inwentaryzacja porządkuje również rozmowę o priorytetach. Systemy wspierające procesy, których zatrzymanie zatrzymuje działalność, trafiają do pierwszych fal niezależnie od tego, jak wygodnie się z nich pobiera dane. Systemy poboczne czekają, choćby ich integracja była trywialna.

Praktyczną korzyścią jest też ujawnienie zasobów, o których nikt nie pamiętał. Wdrożenia platform zbierania zdarzeń regularnie kończą się odkryciem usług wystawionych na zewnątrz bez wiedzy właściciela procesu — i to odkrycie bywa cenniejsze niż pierwsze uruchomione reguły.

Inwentaryzacja nie musi być kompletna, żeby była użyteczna. Wystarczy, że obejmuje procesy krytyczne wraz z systemami, od których zależą, oraz wskazuje właściciela każdej pozycji. Dążenie do pełnej listy wszystkich zasobów bywa pułapką, w której projekt zatrzymuje się na etapie porządkowania i nie dociera do pierwszej reguły.

Zdarzenia związane z uwierzytelnianiem i zarządzaniem kontami dają najlepszy stosunek wartości do wolumenu danych. Większość scenariuszy, które organizacja chce wykryć, zaczyna się od nieuprawnionego dostępu albo od nadużycia dostępu uprawnionego, a jedno i drugie zostawia ślad właśnie tutaj.

Do tej fali należą logi katalogu użytkowników, systemu uwierzytelniania wieloskładnikowego, mechanizmów podnoszenia uprawnień oraz operacji na kontach uprzywilejowanych. Wartościowe są nie tylko nieudane próby logowania, lecz przede wszystkim zmiany w uprawnieniach i tworzenie nowych kont.

Fala ta ma dodatkową zaletę organizacyjną. Wnioski z niej płynące trafiają wprost do właścicieli procesów, a nie tylko do zespołu technicznego — konta bez właściciela i uprawnienia nadane bez terminu ważności są problemem zarządczym, który dopiero wtórnie staje się problemem bezpieczeństwa.

Praktyczną wskazówką jest rozpoczęcie od zdarzeń dotyczących kont uprzywilejowanych, a nie od całego katalogu użytkowników. Kont takich jest zwykle kilkadziesiąt, ich aktywność jest przewidywalna, a każde odstępstwo ma wysoką wartość informacyjną. Reguła zbudowana na tym zbiorze daje użyteczny sygnał już w pierwszym tygodniu.

Warto przy tej okazji zweryfikować samą listę kont uprzywilejowanych. W większości organizacji okazuje się ona dłuższa, niż zakładano, i zawiera pozycje po osobach, które dawno zmieniły stanowisko. Uporządkowanie tej listy bywa najtańszym pojedynczym działaniem podnoszącym poziom bezpieczeństwa w całym projekcie.

Druga wskazówka dotyczy kont technicznych, wykorzystywanych przez systemy do wzajemnej komunikacji. Bywają one wyłączane z monitorowania, ponieważ generują dużo zdarzeń rutynowych — i z tego samego powodu bywają wykorzystywane, gdy ktoś chce działać niezauważenie.

Druga fala obejmuje systemy operacyjne stacji roboczych i serwerów wraz z warstwą ochrony punktów końcowych. To tutaj widać uruchamianie procesów, zmiany konfiguracji, instalacje oprogramowania i operacje na plikach — czyli materiał pozwalający odtworzyć, co faktycznie wydarzyło się na urządzeniu.

Wolumen jest w tej fali istotnie wyższy niż w pierwszej, dlatego dobór zdarzeń wymaga selekcji. Zbieranie wszystkiego, co system potrafi zapisać, jest technicznie możliwe i ekonomicznie nieuzasadnione. Punktem wyjścia bywają rekomendacje bezpiecznej konfiguracji, takie jak CIS Benchmarks, które wskazują zdarzenia o realnej wartości dowodowej.

Warto z góry ustalić, co dzieje się z urządzeniami spoza sieci firmowej. Praca zdalna sprawia, że część stacji roboczych przez większość czasu nie ma kontaktu z infrastrukturą wewnętrzną, a luka w zbieraniu danych z tych urządzeń bywa odkrywana dopiero podczas analizy zdarzenia.

Osobnego rozstrzygnięcia wymagają serwery obsługujące procesy krytyczne. Zakres zbieranych z nich zdarzeń powinien być szerszy niż na pozostałych systemach, a decyzja o tym rozszerzeniu należy do właściciela procesu, nie do zespołu utrzymaniowego. To on ponosi skutki niemożności odtworzenia przebiegu zdarzenia.

Trzecia fala dotyczy granicy między siecią organizacji a światem zewnętrznym: urządzeń filtrujących ruch, kanałów dostępu zdalnego, systemów pocztowych i usług publikowanych w internecie. Zdarzenia z tej warstwy opisują próby dostania się do środowiska, zanim jeszcze dojdzie do interakcji z systemem docelowym.

Charakterystyczną cechą tej fali jest bardzo wysoki udział zdarzeń nieistotnych. Ruch skanujący z sieci publicznej jest stanem stałym, a nie sygnałem, więc reguły muszą od początku odróżniać tło od zdarzenia wymagającego uwagi. Bez tego rozróżnienia fala trzecia potrafi samodzielnie zniechęcić zespół do korzystania z platformy.

Osobno warto potraktować kanały dostępu zdalnego. Ich logi łączą warstwę sieciową z warstwą tożsamości, przez co pozwalają wykryć scenariusze niewidoczne w żadnej z nich osobno — na przykład poprawne uwierzytelnienie z lokalizacji, z której dany pracownik nigdy nie pracował.

Przy tej fali warto również ustalić, jak długo przechowywane są surowe zapisy ruchu. Ich wolumen jest największy w całym projekcie, a wartość dowodowa spada szybciej niż w przypadku zdarzeń dotyczących tożsamości. Jednolity okres przechowywania dla obu kategorii jest wygodny administracyjnie i kosztowny bez potrzeby.

Ostatnia fala obejmuje logi aplikacji wspierających procesy krytyczne oraz środowisk chmurowych. Jest najtrudniejsza, ponieważ dane z aplikacji rzadko mają ustandaryzowaną postać, a ich interpretacja wymaga wiedzy o samym procesie biznesowym, nie tylko o technologii.

W środowiskach chmurowych szczególne znaczenie mają zapisy dotyczące zmian konfiguracji i uprawnień. Większość poważnych zdarzeń w tej warstwie nie polega na włamaniu w klasycznym rozumieniu, lecz na zmianie ustawienia, która udostępnia zasób szerzej, niż zakładał właściciel.

Z tego powodu w tej fali warto od początku objąć monitorowaniem konsolę zarządzania środowiskiem, a nie wyłącznie uruchomione w nim usługi. Zapisy z warstwy zarządzania są zwykle niewielkie objętościowo i mają najwyższą wartość informacyjną w całym środowisku chmurowym.

Fala ta bywa odkładana i jest to decyzja uzasadniona, pod warunkiem że zapada świadomie. Odłożenie jej bez zapisania w planie kończy się tym, że najbardziej wartościowe procesy organizacji pozostają poza obrazem, podczas gdy infrastruktura pomocnicza jest opisana szczegółowo.

Trudność techniczna nie jest tu jedyną przeszkodą. Logi aplikacji dziedzinowych bywają w gestii dostawcy oprogramowania, a ich udostępnienie wymaga zapisu umownego albo dodatkowej licencji. Pytanie o to warto zadać przy zawieraniu umowy na system, a nie kilka lat później, gdy pozycja negocjacyjna jest już inna.

Decyzja o odrzuceniu źródła jest równie ważna jak decyzja o jego włączeniu, a znacznie rzadziej podejmowana świadomie. Domyślnym odruchem jest zbieranie wszystkiego, co da się zebrać, ponieważ nadmiar wydaje się bezpieczniejszy od braku.

Nadmiar ma jednak dwa koszty. Pierwszy jest finansowy i wynika z modeli licencjonowania rozliczanych wolumenem danych — każdy zbędny strumień podnosi rachunek co miesiąc, niezależnie od tego, czy ktokolwiek do niego zajrzał. Drugi jest poznawczy: im więcej danych bez przypisanej reguły, tym trudniej odnaleźć w nich zdarzenie istotne.

Użytecznym kryterium jest pytanie o przeznaczenie. Jeżeli dla danego źródła nie potrafimy wskazać ani reguły detekcji, ani scenariusza dowodowego, ani wymogu regulacyjnego, źródło nie powinno trafić do platformy w tym etapie. Nie znaczy to, że nie trafi tam nigdy — znaczy, że nie ma powodu, dla którego miałoby trafić teraz.

Odrębną kategorią są dane, których zbieranie rodzi ryzyko prawne. Szczegółowe zapisy aktywności pracowników, treść komunikacji czy dane szczególnych kategorii wymagają uzasadnienia celu i mogą podlegać ograniczeniom wynikającym z prawa pracy. Decyzja o ich zbieraniu nie należy do zespołu technicznego.

Korelacja zdarzeń między systemami wymaga dwóch rzeczy, o które projekty potykają się najczęściej. Pierwszą jest normalizacja, czyli sprowadzenie zapisów o różnej strukturze do wspólnego modelu, w którym nazwa użytkownika, adres i identyfikator zasobu znaczą to samo niezależnie od źródła.

Drugą jest wspólny czas. Systemy zapisujące zdarzenia w różnych strefach czasowych lub z rozjeżdżonym zegarem uniemożliwiają ustalenie kolejności zdarzeń, a bez kolejności nie ma rekonstrukcji przebiegu. Synchronizacja czasu jest czynnością prostą i regularnie pomijaną, ponieważ nie należy do zakresu żadnego z zespołów.

Skutki braku obu warunków ujawniają się dopiero podczas analizy realnego zdarzenia, czyli w najgorszym możliwym momencie. Do tego czasu platforma sprawia wrażenie działającej, bo dane napływają, a pulpity się wypełniają.

Trzecim, mniej oczywistym warunkiem jest spójna identyfikacja zasobów. Ten sam serwer bywa opisany w trzech systemach trzema różnymi nazwami, a użytkownik występuje raz jako login, raz jako adres pocztowy, raz jako identyfikator kadrowy. Bez uzgodnienia tych identyfikatorów korelacja formalnie działa, lecz nie łączy zdarzeń, które powinna połączyć.

Reguły warto budować wokół scenariuszy, a nie wokół pojedynczych zdarzeń. Scenariusz opisuje sekwencję: uzyskanie dostępu, utrwalenie się w środowisku, rozszerzenie uprawnień, sięgnięcie po dane. Reguła zbudowana wokół jednego zdarzenia bez kontekstu daje sygnał, którego nie da się ocenić.

Do porządkowania scenariuszy służy publiczna baza wiedzy MITRE ATT&CK, opisująca taktyki i techniki stosowane przez atakujących. Jej wartość dla organizacji jest przede wszystkim porządkująca: pozwala zobaczyć, które obszary są opisane regułami, a które nie, i prowadzić o tym rozmowę w kategoriach zrozumiałych także poza zespołem technicznym.

Rozsądnym początkiem jest niewielki zestaw reguł o wysokiej wiarygodności, obejmujący scenariusze najbardziej prawdopodobne w danym środowisku. Zestaw ten rozszerza się wraz z kolejnymi falami źródeł, a nie z góry.

Każda reguła powinna mieć opisane przeznaczenie i sposób postępowania z wygenerowanym sygnałem. Reguła bez takiego opisu po kilku miesiącach staje się kłopotem: nikt nie pamięta, po co ją utworzono, a nikt nie ma odwagi jej wyłączyć. Katalog reguł prowadzony bez tej dyscypliny rośnie w sposób nieodwracalny.

Warto również zaplanować przegląd reguł w stałym rytmie. Środowisko zmienia się szybciej niż dokumentacja, a reguła oparta na nieaktualnym założeniu daje sygnał gorszy niż jego brak, bo buduje fałszywe poczucie pokrycia.

Pierwszy tydzień działania nowych reguł zawsze produkuje więcej sygnałów, niż wynosi realna liczba zdarzeń wymagających uwagi. Jest to stan oczekiwany, a nie usterka. Problemem staje się dopiero wtedy, gdy nikt nie zaplanował okresu strojenia i zespół przyzwyczaja się do ignorowania sygnałów.

Strojenie polega na stopniowym wyłączaniu wzorców uznanych za normalne dla danego środowiska i na dopisywaniu kontekstu, który pozwala odróżnić czynność rutynową od wyjątkowej. Wymaga rozmowy z właścicielami systemów, bo tylko oni wiedzą, że dana operacja wykonywana nocą jest elementem procesu, a nie anomalią.

Zaniechanie tego etapu jest najczęstszą przyczyną cichej śmierci wdrożenia. Platforma działa, reguły generują sygnały, nikt ich nie czyta — i formalnie wszystko jest w porządku aż do pierwszego zdarzenia, które przeszło niezauważone.

Użytecznym miernikiem postępu jest odsetek sygnałów zamykanych jako nieistotne. Nie chodzi o doprowadzenie go do zera, bo to oznaczałoby regułę zbyt wąską, lecz o utrzymanie liczby sygnałów na poziomie, przy którym zespół faktycznie każdy z nich ocenia. Poziom ten jest różny dla różnych organizacji i wyznacza go dostępny czas, a nie teoria.

Wdrożenie nie kończy się uruchomieniem platformy ani odbiorem dokumentacji technicznej. Kończy się w chwili, gdy zespół, który ma z niej korzystać na co dzień, potrafi samodzielnie ocenić sygnał, dopisać regułę i wyjaśnić, dlaczego dane źródło jest podłączone.

Przekazanie wymaga trzech elementów: opisu podłączonych źródeł wraz z uzasadnieniem, katalogu reguł z informacją, co każda z nich wykrywa, oraz ustalonego trybu postępowania z sygnałem. Bez trzeciego elementu dwa pierwsze pozostają dokumentacją, do której nikt nie wraca.

Warto tu powiedzieć wprost, czego przekazanie nie zastępuje. Jeżeli organizacja nie ma zasobów do bieżącej obsługi sygnałów, żadna dokumentacja tego nie nadrobi — wtedy właściwą decyzją jest powierzenie obsługi dostawcy usługi zarządzanej i zaplanowanie nadzoru nad nim.

Sprawdzianem skuteczności przekazania jest ćwiczenie przeprowadzone bez udziału wykonawcy wdrożenia. Uzgodniony scenariusz, odtworzony w kontrolowanych warunkach, pokazuje w ciągu godziny, czy zespół potrafi rozpoznać sygnał i co z nim zrobi. Odbiór oparty wyłącznie na przeglądzie dokumentacji tego nie sprawdza.

Zestaw błędów powtarza się niezależnie od wielkości organizacji i wybranej platformy. Łączy je jedna cecha: wszystkie wynikają z decyzji podjętych na początku projektu, a ujawniają się dopiero po kilku miesiącach jego działania.

Warto je przejrzeć przed startem, ponieważ koszt uniknięcia każdego z nich jest nieporównanie niższy niż koszt naprawy. Zmiana zakresu zbieranych danych po roku oznacza zwykle renegocjację licencji i ponowne strojenie całego katalogu reguł.

Prowadzimy dobór platformy, wdrożenie, strojenie reguł i przekazanie zdolności zespołowi klienta lub wskazanemu dostawcy. Doradzamy niezależnie, ponieważ nie odsprzedajemy licencji i nie mamy interesu w tym, aby wolumen zbieranych danych rósł.

Nie prowadzimy natomiast monitorowania w trybie całodobowym ani obsługi technicznej trwających incydentów. Te funkcje realizuje zespół klienta albo zewnętrzny dostawca usługi zarządzanej, którego pomagamy wybrać i nad którym pomagamy sprawować nadzór.

Rozdzielenie tych ról ma znaczenie przy planowaniu budżetu i harmonogramu. Wdrożenie jest projektem o określonym końcu, obsługa operacyjna jest kosztem stałym — i są to dwie odrębne decyzje, które warto podejmować osobno.

Kolejność tych decyzji też ma znaczenie. Organizacja, która najpierw ustali, kto będzie obsługiwał sygnały, dobierze zakres wdrożenia do realnych możliwości. Kolejność odwrotna prowadzi do platformy zaprojektowanej pod zespół, którego nigdy nie było.