Usługi / Security i hardening
Detekcja, krawędź, odzyskanieSecurity, które da się utrzymać i rozliczyć
Wazuh zbiera sygnał z hostów i aplikacji. OpenVAS zamyka podatności w backlogu. Cloudflare trzyma krawędź. Własny system analizy ruchu pilnuje sieci. Backup dwutorowy daje odzyskanie, gdy reszta zawiedzie. Dyżur, playbook i ślad zmian.
Jak to składa się w całość
Pięć warstw, jeden obraz incydentu
Narzędzia bez korelacji to pięć konsol i zero decyzji. Cloudflare i analiza ruchu widzą krawędź i sieć. Wazuh widzi host. OpenVAS mówi, co da się wykorzystać. Backup dwutorowy jest ostatnią linią, niezależną od tej samej tożsamości i sieci.
- OpenVAS zasila backlog napraw i reguły detekcji prób eksploitu.
- Nieudany backup, utrata immutability albo zmiana retencji idzie do tego samego dyżuru.
SIEM, który ma właściciela na dyżurze
Wazuh zbiera logi z systemów, kontenerów, chmury i urządzeń sieciowych. Pilnuje integralności plików, baseline konfiguracji i reguł MITRE. Alert ma priorytet, kontekst i playbook, nie sam zrzut z sysloga.
Źródła
Agenci na Linux i Windows, logi z Kubernetes, cloud trail, syslog z firewalla, VPN i z Cloudflare.
Detekcja
FIM, SCA, rootkit, brute force, zmiana uprawnień, wykonanie poza znaną ścieżką, próba eksploitu po skanie OpenVAS.
Odpowiedź
Active response tam, gdzie jest bezpieczny. Izolacja, blokada, zbieranie artefaktów. Eskalacja według SLA.
Rozliczenie
Retencja, kto widział alert, co zrobiono, kiedy zamknięto. Materiał pod ISO 27001, DORA i audyt wewnętrzny.
Podatności w backlogu, nie w PDF na półce
Greenbone OpenVAS skanuje sieć i hosty w cyklu, także ze skanem uwierzytelnionym. Wynik to kolejka napraw z właścicielem, oknem serwisowym i weryfikacją po patchu. Krytyczne luki nie czekają na kwartalny przegląd.
Zakres
Systemy, usługi sieciowe, panele, bazy, środowiska staging i produkcja. Osobne polityki dla DMZ i LAN.
Rytm
Skan stały plus skan po zmianie i przed oknem patchy. Ponowny skan po zamknięciu zgłoszenia.
Priorytet
CVSS razem z ekspozycją. Publiczny origin i dane kartowe idą przed hostem bez ruchu z internetu.
Sprzęg z detekcją
Otwarta luka dostaje regułę w Wazuh. Próba wykorzystania nie ginie w ogólnym szumie IDS.
Krawędź, której origin nie wystawia się sam
DNS, proxy, TLS, WAF, ograniczenie botów i DDoS. Adres origin zostaje prywatny. Panele administracyjne wchodzą przez Access, nie przez otwarty port. Logi z krawędzi idą do Wazuh, żeby atak na WAF i atak na host były jednym wątkiem.
Ekspozycja
Tylko to, co ma być publiczne. Reszta za tożsamością, mTLS albo VPN. Żadnego RDP i SSH na 0.0.0.0/0.
WAF i limity
Reguły pod aplikację, nie sam managed ruleset. Rate limit na logowanie, API i kosztowne endpointy.
DDoS
Warstwa 3 i 7 na krawędzi. Origin nie trzyma ataku. Playbook na status, komunikację i failover DNS.
Zero Trust
Cloudflare Access do Grafana, paneli cloud i staging. Jedna tożsamość, krótka sesja, log każdego wejścia.
Sieć ma profil. Odchylenie ma alert.
Cloudflare widzi ruch z internetu na krawędzi. Wazuh widzi proces na hoście. Pomiędzy zostaje ruch w LAN, między VPC, do object storage i do ASN, których aplikacja nigdy nie woła. Nasz system buduje baseline per usługa, port, peer i pora dnia.
Telemetria
NetFlow, sFlow, mirroring, eBPF tam, gdzie host na to pozwala. Bez pełnego pcap na stałe, z zapisem okna przy alercie.
Co łapiemy
Skanowanie, cykliczne wywołania C2, nietypowy DNS, eksfiltracja objętością, ruch między hostami po kompromitacji, połączenia poza znanym kontraktem.
Kontekst
Alert mówi kto, dokąd, ile i czy to znany serwis. Nie sam numer portu. Korelacja z loginem, podem i regułą Wazuh.
Granica
To nie jest kolejny SIEM. To warstwa sieci, która karmi SIEM. Tuning baseline jest częścią dyżuru, nie projektem raz na rok.
Dwa tory, które da się spalić osobno
Jeden backup na tym samym koncie co produkcja nie przeżyje ransomware ani błędu IAM. Prowadzimy dwa tory: kopia blisko, pod krótki RTO, i kopia poza lokalizacją, na osobnych kontach i kluczach, z immutability. Restore jest w kalendarzu, nie w założeniu.
Tor A
Blisko, szybko
Snapshoty i kopia w tej samej lokalizacji albo regionie. Krótki RTO, test odtworzenia pojedynczego systemu i całej aplikacji. Osobna polityka retencji od toru B.
Tor B
Daleko, osobno
Drugi dostawca albo drugi tenant. Inny klucz, inna sieć, object lock albo air-gap. Ten tor nie używa tych samych kont serwisowych co produkcja i tor A.
Zakres danych
Bazy, wolumeny, konfiguracja IaC, sekrety w vault poza backupem aplikacji, poczta i pliki tam, gdzie to część usługi.
RPO i RTO
Spisane per system. Backup bez udanego restore nie liczy się jako kopia. Raport z testu idzie do Was i do audytu.
Sygnał
Nieudane zadanie, skrócona retencja, wyłączony lock, zmiana bucket policy. To alert w Wazuh, nie cichy mail z crona.
Ludzie
Kto odtwarza, w jakiej kolejności, z jakim DNS i sekretem. Playbook offline, bo katalog w tej samej sieci może nie wstać.
Operacja
Od mapy do dyżuru
Najpierw inwentaryzacja ekspozycji, tożsamości i kopii. Potem baseline i wdrożenie warstw. Na końcu rytm: przegląd alertów, skanów, restore i zmian. Jeden kanał eskalacji.
- Mapa Systemy, origin, panele, konta backup, przepływy sieci, kto ma klucz.
- Baseline Hardening, WAF, agenci Wazuh, pierwsza pełna kopia na obu torach.
- Detekcja Reguły, szum, priorytety, powiązanie OpenVAS z Wazuh i analizą ruchu.
- Dyżur SLA, playbooki, raport tygodniowy i materiał pod audyt.
Rozmowa
Omówimy ekspozycję, detekcję i restore
Na tej podstawie przygotujemy zakres: warstwy, rytm skanów, dyżur i test odtworzenia.
Skontaktuj się