SOC i SIEM, które wykrywają realne ataki — nie tylko gromadzą logi.

SIEM to technologia gromadzenia, wyszukiwania i korelacji danych bezpieczeństwa. SOC to ludzie, procesy i narzędzia odpowiedzialne za wykrywanie, analizę, eskalację i reakcję. Sam SIEM bez źródeł danych, reguł, właścicieli i procedur nie tworzy działającego SOC.

Obsługa SOC/SIEM BSTA zaczyna się od 2 000 PLN netto miesięcznie. Cena zależy od liczby i rodzaju źródeł danych, wolumenu logów, zakresu godzinowego, wymaganych czasów reakcji, retencji, integracji, licencji oraz odpowiedzialności za działania reakcyjne.

Możemy zaprojektować różne modele pokrycia, ale tryb 24/7 nie jest automatycznie zawarty w cenie startowej. Godziny obsługi, dyżury, kanał krytyczny, czasy reakcji i zasady eskalacji muszą być jednoznacznie zapisane w ofercie i umowie.

Tak. Zaczynamy od przeglądu architektury, źródeł, jakości danych, kosztów, reguł, ról, retencji i zaległych alertów. Następnie proponujemy plan stabilizacji, strojenia oraz rozwoju bez niepotrzebnej wymiany działających komponentów.

Tak. Projektujemy i wdrażamy Wazuh, jego agenty, manager, indexer i dashboard, integrujemy źródła agentowe i bezagentowe oraz stroimy reguły. Zakres może obejmować analizę logów, FIM, ocenę konfiguracji, wykrywanie podatności i kontrolowaną aktywną odpowiedź.

Tak. Projektujemy ingest, Elasticsearch, Kibana, Elastic Agent i integracje bezpieczeństwa, a następnie budujemy reguły, dashboardy i proces analityczny. Uwzględniamy wydajność, retencję, kontrolę dostępu, jakość mapowania pól i koszty przechowywania danych.

Tak. Możemy integrować sygnały Microsoft 365, Entra ID, Defender for Endpoint, Defender for Identity, pocztę, chmurę i inne źródła. Dokładny zakres zależy od posiadanych licencji i konfiguracji klienta.

Nie. Najpierw oceniamy istniejące inwestycje i luki. Często większą wartość daje poprawa telemetrii, konfiguracji, reguł, procesów i odpowiedzialności niż migracja do kolejnego produktu.

Priorytet zwykle otrzymują tożsamość i uwierzytelnianie, endpointy, Active Directory, urządzenia brzegowe, VPN, poczta, kluczowe systemy biznesowe, chmura oraz narzędzia EDR/XDR. Kolejność wynika jednak z krytyczności zasobów i scenariuszy ryzyka.

Tak. Możemy zbierać zdarzenia systemowe, logowania, procesy, PowerShell, usługi, zadania, zmiany plików, zdarzenia domenowe, Kerberos, NTLM i inne dane potrzebne do uzgodnionych detekcji. Zakres telemetryczny zależy od narzędzi i polityk klienta.

Tak. Integrujemy logi control plane, tożsamości, sieci, storage, workloadów, audytu Kubernetes, kontenerów i narzędzi cloud security. Najpierw wskazujemy minimalny zestaw źródeł potrzebny do wykrywania ryzyk właściwych dla danego środowiska.

Tak, ale architektura musi respektować bezpieczeństwo procesu technologicznego, segmentację i ograniczenia dostawców. Preferujemy bezpieczny odbiór zdarzeń z istniejących komponentów i uzgodnione źródła pasywne; działania aktywne wymagają odrębnej oceny ryzyka i zgody.

DLP obejmuje rozpoznanie danych wrażliwych, ich klasyfikację, kanały przepływu, polityki wykrywania i zapobiegania oraz proces obsługi alertów. Zaczynamy od trybu obserwacyjnego i strojenia, aby ograniczyć blokowanie prawidłowych procesów biznesowych.

EDR koncentruje się na telemetrii, detekcji i reakcji na urządzeniach końcowych. XDR koreluje sygnały z szerszego środowiska, na przykład endpointów, tożsamości, poczty, aplikacji, sieci i chmury. Zakres zależy od konkretnego produktu i jego integracji.

Nie. SIEM agreguje i analizuje dane, ale potrzebuje wiarygodnych źródeł i narzędzi wykonawczych. EDR, XDR, firewall, IAM, DLP i bezpieczeństwo chmury dostarczają sygnały lub egzekwują działania; SOC łączy je w jeden proces operacyjny.

Budujemy reguły na konkretnych scenariuszach, wzbogacamy alerty kontekstem zasobu i tożsamości, analizujemy przyczyny szumu, stosujemy wyjątki o ograniczonym zakresie i mierzymy efekt strojenia. Nie wyciszamy reguły bez zrozumienia, co przestanie być widoczne.

Tak. Mapowanie pomaga opisać zachowania atakującego, mierzyć pokrycie, wskazywać brakujące dane i planować walidację. Nie traktujemy liczby technik jako samodzielnego miernika skuteczności, ponieważ jakość telemetrii i logiki detekcji ma równie duże znaczenie.

Tak. Sigma pomaga opisywać przenośną logikę detekcji, ale każdą regułę trzeba dopasować do schematu danych i składni docelowej platformy. Reguły wersjonujemy, testujemy i dokumentujemy wraz z założeniami oraz źródłami danych.

Tak, w uzgodnionym modelu. Polowanie na zagrożenia opieramy na hipotezie, dostępnej telemetrii, zmianach w środowisku, informacjach o zagrożeniach, wynikach incydentów i pentestów. Wynikiem jest nie tylko lista obserwacji, lecz także nowe detekcje i rekomendacje.

Możemy zaprojektować takie działania, lecz automatyzacja wymaga jawnej autoryzacji, odpowiednich uprawnień, testów, warunków bezpieczeństwa i procedury wycofania. Dla ryzykownych akcji często stosujemy zatwierdzenie człowieka przed wykonaniem.

Budujemy wielowarstwowe scenariusze obejmujące między innymi nietypowe wykonanie procesów, zmiany uprawnień, ruch boczny, narzędzia administracyjne, szyfrowanie, wyłączenie zabezpieczeń i próby usuwania śladów. Żaden pojedynczy alert nie gwarantuje wykrycia każdego wariantu ataku.

Tak. Korelujemy zdarzenia logowania, MFA, ryzykowne sesje, zmiany uprawnień, tworzenie reguł pocztowych, nowe urządzenia, nietypowe lokalizacje i aktywność w chmurze. Dokładne detekcje zależą od dostępnych logów oraz licencji.

Może obejmować analizę, zabezpieczenie dowodów, rekomendację containmentu, koordynację działań i wsparcie techniczne. Uprawnienia do izolacji, blokowania, resetowania lub zmian produkcyjnych oraz dostępność poza ustalonymi godzinami określa umowa.

Retencję dobieramy do celu detekcyjnego, czasu potrzebnego do dochodzeń, wymagań prawnych i umownych, wolumenu danych oraz kosztu. Rozdzielamy dane gorące do szybkiej analizy od tańszego archiwum, jeżeli architektura i wymagania na to pozwalają.

Zaczynamy od kilku najważniejszych scenariuszy i źródeł: tożsamości, endpointów, urządzeń brzegowych, poczty i systemów krytycznych. Dopiero po potwierdzeniu jakości danych rozszerzamy zakres. Takie podejście ogranicza koszt, szum alertów i ryzyko zbudowania kosztownego archiwum logów bez zdolności reakcji.

Managed SOC może zapewnić platformę, proces i analityków, MDR zwykle koncentruje się na zarządzanym wykrywaniu i reakcji, a zespół wewnętrzny daje największą znajomość biznesu. Dobry model może być hybrydowy: BSTA prowadzi monitoring i inżynierię detekcji, a klient zachowuje decyzje biznesowe oraz właścicielstwo incydentu.

Warto wskazać właściciela biznesowego i technicznego, systemy krytyczne, istniejące narzędzia, wymagania retencji, kontakty awaryjne i ograniczenia sieciowe. Nie trzeba wcześniej centralizować wszystkich logów; plan źródeł i priorytetów przygotowujemy podczas onboardingu.

Monitoring, zarządzanie incydentami, logowanie, detekcja i udokumentowana eskalacja mogą wspierać techniczną gotowość organizacji. Sama usługa SOC/SIEM nie jest jednak automatycznym potwierdzeniem zgodności ani ustawowym audytem; zakres należy odnieść do obowiązków konkretnego podmiotu.

Raport zarządczy opisuje istotne incydenty, trendy, wpływ na ryzyko, stan najważniejszych źródeł, pokrycie uzgodnionych scenariuszy i priorytety. Szczegóły techniczne, dowody, reguły i backlog działań trafiają do zespołów odpowiedzialnych za wdrożenie.

Mierzymy między innymi zdrowie źródeł, jakość danych, pokrycie scenariuszy, odsetek false positive, czas wykrycia, analizy i eskalacji oraz skuteczność zamykania rekomendacji. Konkretne KPI muszą uwzględniać zakres godzinowy i odpowiedzialność opisaną w umowie.

Nie należy tego zakładać. Cena startowa dotyczy podstawowego, ograniczonego zakresu obsługi. Licencje producentów, infrastruktura, przechowywanie, transfer i duży wolumen danych mogą być rozliczane osobno; wszystkie składniki kosztu pokazujemy w ofercie.

Tak. Krótki etap oceny lub pilot pozwala sprawdzić jakość źródeł, wolumen, kilka priorytetowych detekcji, sposób eskalacji i realny nakład operacyjny. Na tej podstawie można odpowiedzialnie zaplanować pełną usługę i jej koszt.

Nie zawsze. Wazuh i Elastic mogą działać w infrastrukturze klienta lub w uzgodnionym środowisku, a inne platformy oferują modele chmurowe. Architekturę dobieramy do poufności, wymagań prawnych, kosztu, administracji i dostępności zespołu.

Tak. Możemy podpisać NDA przed przekazaniem architektury i informacji o incydentach. Obsługujemy projekty w Polsce i globalnie, a dokumentacja oraz komunikacja mogą być prowadzone po polsku albo angielsku.

Pentest pokazuje rzeczywiste ścieżki ataku, techniki i artefakty, które powinny być widoczne w telemetrii. Po teście możemy zamienić wnioski w reguły, zapytania, runbooki i ćwiczenia purple team, a następnie sprawdzić, czy organizacja wykrywa podobne zachowania.

Termin zależy od dostępu do źródeł, architektury, sieci, licencji, wolumenu i uzgodnień odpowiedzialności. Najpierw uruchamiamy źródła o najwyższym priorytecie i walidujemy pełny przepływ od zdarzenia do eskalacji; harmonogram potwierdza oferta.