Większość MŚP odkrywa, że nie ma logów, dopiero po incydencie. Wtedy pytania „kto się zalogował o 3 w nocy" i „jak się dostał do środka" pozostają bez odpowiedzi. A to oznacza, że nie wiesz też, czy dziura została załatana.
„Zbieranie logów" brzmi jak temat na duże korporacje z zespołem bezpieczeństwa. To pułapka. SIEM za 200 tysięcy rocznie faktycznie nie jest dla firmy na 30 osób, ale to nie znaczy, że logi nie są. Między „nic nie zapisujemy" a „mamy SOC 24/7" jest ogromna szara strefa, którą większość MŚP ignoruje, i to jest błąd, który zawsze wychodzi w najgorszym momencie.
Po co w ogóle logi
Trzy realne scenariusze, które widzimy regularnie.
Pierwszy: atak ransomware. Płacisz albo odbudowujesz z backupu, ale nie wiesz, kędy weszli. Wracasz do produkcji z tą samą dziurą, tylko teraz atakujący ma już mapę Twojej sieci. U jednego z naszych klientów — 22-osobowa drukarnia — po ataku okazało się, że zapisów Windowsa starczyło tylko na 48 godzin wstecz, a incydent zaczął się 11 dni wcześniej. Nie dowiedzieliśmy się, jak weszli. Zmieniliśmy wszystko, co się dało, i modliliśmy się.
Drugi: były pracownik. Zwalniasz kogoś, kto miał dostęp do folderu z klientami. Trzy miesiące później klient dzwoni, że dostał ofertę od konkurencji, która zna ceny do grosza. Bez logów dostępu do plików — nic nie udowodnisz. W jednej firmie księgowej (12 osób) uruchomiliśmy elementarne logowanie dostępu do folderów sieciowych i po miesiącu okazało się, że były zewnętrzny księgowy dalej ma aktywny login i regularnie pobiera dane trzech klientów.
Trzeci: reklamacja klienta, która trafia do sądu. Klient twierdzi, że nigdy nie akceptował zamówienia. Bez logów ERP i systemu ofertowania nie masz jak pokazać, kiedy i z jakiego IP potwierdzono zamówienie.
Logi to nie „paranoja bezpieczeństwa". To Twoja pamięć, kiedy nikt nie pamięta.
Minimum, które warto zbierać
Nie wszystko. Zbieranie „wszystkiego" kończy się tym, że nikt nigdy niczego nie znajdzie. Ustal minimum, dopilnuj że działa, później rozszerzaj.
- Logowania do systemów — kto się logował, kiedy, skąd (IP), sukces czy porażka. Windows, ERP, poczta, VPN, panel administracyjny hostingu. Nieudane próby logowania to Twój wczesny sygnał — brute force wygląda tak samo od dziesięciu lat.
- Zmiany uprawnień i kont — kto nadał komu dostęp, kto zmienił rolę w ERP, kiedy powstało nowe konto administracyjne. Nowe konto admin, którego nikt nie zna, to jeden z pierwszych ruchów po włamaniu.
- Dostęp do wrażliwych zasobów — folder z umowami, katalog klientów w ERP, eksporty z bazy. Nie musisz wiedzieć, kto otworzył każdy plik, ale masowe pobieranie (500 plików w 3 minuty) powinno zostawić ślad.
- Zdarzenia z endpointów — antywirus/EDR, zablokowane exe, wyłączenie ochrony, podłączenie pendrive'a. Windows Defender to loguje domyślnie, tylko nikt tego nie zbiera.
- Wyniki backupów — co się udało, co się nie udało, kiedy ostatnio testowano odtwarzanie. To zwykle najprostszy do dodania log i najczęściej ignorowany.
- Zmiany w krytycznych aplikacjach — kto zmienił cennik, kto anulował fakturę, kto ustawił nowego kontrahenta w białej liście VAT.
Poczty i logów przeglądarki na razie nie ruszamy. Za dużo szumu, za mało wartości.
Gdzie to trzymać
Zasada numer jeden: nie na tej samej maszynie, którą monitorujesz. Jeżeli atakujący dostanie się do serwera, pierwsze co zrobi, to skasuje logi. Trzymanie logów wyłącznie lokalnie na serwerze plików to jak nagrywanie kamerki włamaniowej na dysk stojący na biurku włamywacza.
W praktyce dla MŚP wystarcza kombinacja trzech rzeczy. Prosty kolektor logów w firmie (Wazuh, Graylog Open, albo nawet Windows Event Forwarding na dedykowany serwer) zbiera zdarzenia z endpointów i serwerów w jedno miejsce. Krytyczne logi (kontroler domeny, ERP, VPN) idą dodatkowo do zewnętrznej lokalizacji — może to być prosta usługa cloud logowania albo nawet szyfrowany dziennik na zewnętrznym S3. Kopia zapasowa logów jest tak samo ważna jak kopia zapasowa danych.
Retencja: 30 dni „gorących" (szybko przeszukiwalnych), 90 dni „ciepłych" (dostępnych w kilka minut), 365 dni „zimnych" (kompresja, może w chmurze, do wyciągnięcia w godzinę). Dla większości MŚP 30/90/365 jest wystarczające i tanie. Jeżeli branża wymaga więcej (medycyna, finanse, przetwarzanie danych osobowych powyżej pewnej skali), zweryfikuj z prawnikiem.
Czego pilnować na bieżąco
Zbieranie bez patrzenia to atrapa. Ale też nikt w firmie na 30 osób nie będzie 24/7 patrzył w konsole. Ustaw więc kilka konkretnych, głośnych alertów — takich, których nie wolno zignorować, i których nie ma dużo.
- Nieudane logowania administracyjne > 10 na godzinę na jedno konto.
- Nowe konto z uprawnieniami admina — natychmiast.
- Wyłączenie antywirusa/EDR na endpoincie.
- Nieudany backup dwa dni z rzędu.
- Logowanie do VPN z kraju, w którym nie prowadzisz działalności.
- Masowe pobieranie plików z folderu z umowami/klientami.
Wszystko inne trafia do dziennika i czeka na moment, w którym będzie potrzebne. Nie próbuj alertować o wszystkim — skończysz z 200 mailami dziennie, których nikt nie czyta.
Ścieżka wdrożenia dla MŚP
Nie kupuj SIEM-a. Nie zatrudniaj analityka SOC. Zacznij od trzech kroków, które można zrobić w miesiąc.
Tydzień pierwszy: włącz szczegółowe logowanie na kontrolerze domeny i serwerze plików. Windows domyślnie loguje mniej niż potrzebujesz — trzeba to podkręcić w politykach audytu. Drugi tydzień: postaw prosty kolektor (Wazuh w kontenerze na jednym serwerze jest wystarczający na start) i zwal do niego logi z 3-5 najbardziej krytycznych źródeł. Trzeci tydzień: ustaw sześć alertów z listy powyżej. Czwarty tydzień: przeprowadź próbny test — zasymuluj nieudane logowanie admina, sprawdź, czy alert dotarł, czy log jest w kolektorze, czy da się go znaleźć w 2 minuty. Jeśli tak — działa. Jeśli nie — napraw teraz, nie po incydencie.
To nie jest SOC. Ale to jest różnica między „nie mamy pojęcia, co się stało" a „widzimy, kto wszedł, kiedy i którym kontem". W większości przypadków to wystarcza, żeby zamknąć dziurę i spać spokojnie.
Jeśli nie wiesz, od którego z sześciu alertów zacząć w Twojej infrastrukturze, umów się na godzinną rozmowę. Zwykle po niej mamy już listę trzech rzeczy, które można zrobić w tydzień, i nazwisko osoby, która to poprowadzi.
Logi zbiera się przed incydentem. Po incydencie zbiera się już tylko wnioski.