Sygnał, gdy w Waszym środowisku dzieje się coś nietypowego — zamiast dowiadywania się o tym od klienta.
Mniej alertów, ale każdy ma właściciela i instrukcję.
Tak wygląda punkt wyjścia w wielu firmach, które dowożą szybko i podlegają regulacjom.
Logi są zbierane, bo ktoś kiedyś tak ustawił. Nikt ich nie ogląda, dopóki nie ma incydentu — a wtedy okazuje się, że akurat tego jednego zdarzenia nie zapisano albo retencja skończyła się dwa tygodnie temu.
Zakres ustalamy po diagnozie — zaczynamy od elementu, który najszybciej obniży Wasze ryzyko.
Sygnał wtedy, gdy naprawdę coś się dzieje.
Zaczynamy od ustalenia, co ma być widoczne — nie wszystko naraz, tylko zdarzenia, które faktycznie coś znaczą, bo zalew alertów kończy się ich wyłączeniem. Budujemy jeden widok pokazujący, czy proces i środowisko są w porządku, żeby zarząd nie musiał pytać zespołu o stan bezpieczeństwa. Alerty kierujemy do osoby, która może zareagować, razem z opisem, co z tym zrobić. Na koniec symulujemy zdarzenie i sprawdzamy, czy powiadomienie rzeczywiście dotarło — bo monitoring niesprawdzony w praktyce jest założeniem, nie zabezpieczeniem.
Po każdym etapie zostaje u Was konkretny rezultat, a nie notatka ze spotkania.
Nie wszystko naraz — te zdarzenia, które faktycznie coś znaczą.
RezultatLista zdarzeń, które mają być widoczne, i okres przechowywania logów
Jeden ekran pokazujący, czy proces i środowisko są w porządku.
RezultatJeden widok stanu procesu i środowiska
Powiadomienie idzie do człowieka, który może zareagować, z opisem co robić.
RezultatAlerty z właścicielem i instrukcją reakcji
Symulujemy zdarzenie i patrzymy, czy alert faktycznie dotarł.
RezultatWynik testu: które alerty dotarły, a które trzeba poprawić
Wdrożenie kończy się działającą konfiguracją i dowodami, a nie raportem z listą zaleceń. Tak to wygląda na przykładzie.
title: Logowanie do konsoli bez MFA
logsource:
product: aws
service: cloudtrail
detection:
selection:
eventName: ConsoleLogin
additionalEventData.MFAUsed: 'No'
condition: selection
level: highReguła opisana kodem — przegląda się ją i zmienia jak każdą inną zmianę.
| Zdarzenie | Do kogo | Reakcja |
|---|---|---|
| logowanie bez MFA | dyżur platformy | w ciągu godziny |
| wdrożenie poza pipeline’em | lider zespołu | tego samego dnia |
| nietypowy eksport danych | bezpieczeństwo | natychmiast |
Alert nie ląduje w skrzynce, której nikt nie czyta.
Monitoring sprawdzony w praktyce, a nie tylko na papierze.
Ilustracja. Zakres i narzędzia dobieramy po diagnozie.
Zakres ustalamy po rozmowie i diagnozie. Mniejsze wdrożenia zamykają się w kilku tygodniach, większe dzielimy na etapy, żeby efekt był widoczny po pierwszym.
Zwykle nie do całego. W większości przypadków wystarczy dostęp do konfiguracji procesu budowania i ustawień organizacji. Zakres ustalamy pisemnie przed startem.
Tak, ale nie na pełen etat. Potrzebujemy kontaktu z osobą, która zna system, i przeglądu naszych zmian. Reszta jest po naszej stronie.
Wpinamy się w to, co u Was działa. Wymiana narzędzia to najdroższy i najrzadziej potrzebny sposób poprawy bezpieczeństwa.
Nie. Pracujemy na standardach i narzędziach, które Wasz zespół zna albo szybko pozna — nie na autorskiej metodyce, którą rozumiemy wyłącznie my. Wszystko jest udokumentowane i przekazane.
Tak wpinamy kontrole, żeby działały w tle. Jeśli któraś zaczyna blokować pracę, dostrajamy ją albo zmieniamy jej miejsce w procesie.