Playbook D · Podatności / CVE / misconfig

Procedura reagowania na podatności oprogramowania, aktywnie eksploatowane CVE oraz błędy konfiguracji (misconfiguration). Podatność niezałatana na systemie brzegowym jest jednym z głównych wektorów uzyskania pierwszego dostępu (initial access) — playbook przekłada wiedzę o podatności na czas i dowód usunięcia ryzyka.

Problem — podatności jako wektor pierwszego dostępu

Raporty branżowe (Verizon DBIR, ENISA Threat Landscape) od lat wskazują eksploatację podatności jako jeden z trzech dominujących wektorów uzyskania pierwszego dostępu — obok phishingu i wykradzionych poświadczeń. PUBLIC CLAIM Kluczowe okno ryzyka to czas między publikacją poprawki (i towarzyszącego jej opisu podatności) a jej wdrożeniem u odbiorcy — w tym oknie atakujący ma gotową mapę słabości.

• Systemy brzegowe — VPN, firewalle, serwery pocztowe, bramy aplikacyjne, urządzenia dostępowe. Najwyższe ryzyko: bezpośrednia ekspozycja + wysoka wartość dostępu.
• Zero-day i n-day — n-day (znana, załatana, ale niewdrożona) jest w praktyce częstszym źródłem incydentów niż zero-day, bo eksploit jest publiczny.
• Misconfiguration — otwarte panele administracyjne, domyślne poświadczenia, publiczne buckety/storage, brak nagłówków bezpieczeństwa, nadmiarowe uprawnienia. Podatność bez CVE, równie groźna.
• Dług podatnościowy — narastająca kolejka niezałatanych systemów bez SLA to systemowe ryzyko, nie pojedynczy incydent.

Rozwiązanie 1 — Vulnerability Management (zarządzanie podatnościami)

Ciągły proces, nie jednorazowy skan. Cel: żadna podatność nie „ginie" bez decyzji (łatam / mityguję / akceptuję ryzyko z uzasadnieniem).

• Skan cykliczny — cotygodniowy skan całego środowiska (authenticated scan tam, gdzie to możliwe — daje pełniejszy obraz niż skan sieciowy).
• Skan po deployu — każde wdrożenie na produkcję uruchamia skan różnicowy: czy nowa wersja / obraz nie wprowadził znanej podatności.
• Lista krytycznych CVE — utrzymywany rejestr podatności dotyczących stacku odbiorcy (technologie, biblioteki, urządzenia), z mapowaniem na konkretne aktywa.
• CISA KEV — codzienna synchronizacja z katalogiem Known Exploited Vulnerabilities. Każda pozycja z KEV obecna w środowisku = automatyczne podbicie do P0.
• Enrichment — łączenie CVSS z kontekstem: ekspozycja aktywa, krytyczność biznesowa, dostępność eksploita (EPSS jako sygnał prawdopodobieństwa eksploatacji).
• Właściciel aktywa — każda podatność ma przypisanego właściciela systemu odpowiedzialnego za łatę; brak właściciela = eskalacja do Admina.

Rozwiązanie 2 — SLA patchowania (zegar, nie intencja)

SLA nadaje podatności wymiar czasowy i rozliczalny. Zegar startuje w momencie wykrycia/publikacji, nie w momencie „gdy będzie okno serwisowe".

Rozwiązanie 3 — DevSecOps (shift-left, podatność wychwycona przed produkcją)

Najtańsza podatność to ta, która nigdy nie dotarła na produkcję. Kontrole wpięte w pipeline CI/CD:

Rozwiązanie 4 — Hardening (redukcja powierzchni ataku)

Utwardzenie konfiguracji domyka drogę, którą podatność mogłaby zostać wykorzystana. Lista kontrolna misconfiguration:

• Brak publicznych paneli administracyjnych — panele admin dostępne wyłącznie przez VPN / listę dozwolonych adresów, nigdy z otwartego Internetu.
• MFA — wieloskładnikowe uwierzytelnianie na wszystkich kontach uprzywilejowanych i dostępach zdalnych; MFA odporne na phishing dla admina.
• Least privilege — konta i usługi z minimalnym niezbędnym zakresem uprawnień; brak współdzielonych kont admin.
• Security headers — Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Referrer-Policy na wszystkich odpowiedziach.
• CSP — Content-Security-Policy (nonce + strict-dynamic) domykająca wektory XSS i wstrzyknięcia zasobów zewnętrznych.
• NOINDEX paneli — panele wewnętrzne i środowiska testowe oznaczone noindex + wyłączone z wyszukiwarek, by nie stały się celem rekonesansu.
• Logi admin — pełne, niemodyfikowalne logowanie działań uprzywilejowanych (kto, kiedy, co), z retencją i alertowaniem na anomalie.
• Zamknięte porty i usługi — wyłączenie nieużywanych usług, zamknięcie zbędnych portów, domyślne poświadczenia zmienione i zweryfikowane.

Playbook operacyjny — 8 kroków

Powiązania systemowe