Zarządzanie podatnościami: jak zbudować proces
Skaner to najłatwiejsza część. Jak zbudować proces zarządzania podatnościami: inwentaryzacja, priorytety po ryzyku, SLA naprawy i sensowne metryki.
Wiele firm „ma zarządzanie podatnościami”, które w praktyce wygląda tak: raz na kwartał ktoś uruchamia skaner, PDF z 4000 znalezisk trafia mailem do administratorów i… tyle. Po roku ta sama lista jest dłuższa, a najstarsze pozycje pamiętają poprzedniego prezesa. Tymczasem statystyki są brutalne: znaczna część udanych włamań wykorzystuje podatności, na które łatka istniała od miesięcy. Różnicę robi nie skaner, lecz proces — od inwentaryzacji, przez priorytety, po egzekwowalne terminy naprawy. Oto jak go zbudować.
Zasada zero: nie naprawisz tego, czego nie widzisz
Fundamentem jest inwentaryzacja zasobów: serwery, stacje, urządzenia sieciowe, chmura, kontenery, aplikacje — wraz z właścicielami i wagą biznesową. Bez niej skaner bada tylko to, co zna, a atakujący wejdzie przez to, czego nie zna nikt: zapomnianą subdomenę, testowy serwer, urządzenie „tymczasowe”. Dobre praktyki:
- inwentarz odświeżany automatycznie (skan sieci, API chmury, agent na stacjach), nie ręczny arkusz,
- zewnętrzna powierzchnia ataku mapowana regularnie także „od internetu” — to, co widzi atakujący, bywa różne od tego, co widzi CMDB,
- każdy zasób ma właściciela; podatność bez właściciela nie zostanie naprawiona nigdy.
Skanowanie: częstotliwość i pokrycie
Rytm, który działa w praktyce: zasoby wystawione do internetu — skan co najmniej co tydzień (a najlepiej ciągle), sieć wewnętrzna i stacje — co 2–4 tygodnie, plus skan po każdej istotnej zmianie. Skanuj z uwierzytelnieniem (credentialed scan) — bez tego widzisz może jedną trzecią prawdy. Pamiętaj też o warstwach, które klasyczne skanery pomijają: zależności aplikacji (łańcuch dostaw), obrazy kontenerów, konfiguracje chmury i tenanta M365.
Priorytetyzacja: CVSS to za mało
Największa pułapka: sortowanie po samym CVSS. Wynik 9.8 na odizolowanym serwerze testowym bywa mniej pilny niż 6.5 na systemie płatności wystawionym do internetu — pisaliśmy o tym szerzej w tekście o priorytetyzacji CVE. Skuteczna formuła łączy trzy pytania:
- Czy podatność jest wykorzystywana? Źródła: katalog CISA KEV (potwierdzone aktywne wykorzystanie), wskaźnik EPSS (prawdopodobieństwo eksploatacji), doniesienia o exploitach publicznych.
- Czy jest u nas osiągalna? Ekspozycja do internetu, segmentacja, wymagane uwierzytelnienie.
- Co chroni ten zasób? Krytyczność biznesowa, dane, powiązania z innymi systemami.
Praktyczny model: priorytet = wykorzystywanie (KEV/EPSS) × ekspozycja × krytyczność zasobu. Prosta macierz z tymi trzema osiami bije po efektach każdy „czerwony raport” z tysiącem pozycji.
SLA naprawy i ścieżka wyjątków
Proces staje się realny, gdy ma terminy uzgodnione z właścicielami systemów zanim pojawi się pierwsza podatność:
| Klasa | Przykład | Termin naprawy |
|---|---|---|
| Krytyczna wykorzystywana (KEV) na zasobie z internetu | RCE na VPN | 24–72 h |
| Krytyczna/wysoka na zasobie z internetu | Panel admina ze znaną luką | 7 dni |
| Wysoka wewnętrznie / średnia z internetu | Eskalacja uprawnień na serwerze | 30 dni |
| Pozostałe | Niska, defence-in-depth | 90 dni / świadoma akceptacja |
Równie ważna jest ścieżka wyjątków: gdy łatka niemożliwa (system legacy, okno serwisowe za miesiąc), decyzja o ryzyku zapada świadomie — z mitygacją (odcięcie od sieci, WAF, wzmocniony monitoring), właścicielem ryzyka i datą ponownego przeglądu. Wyjątek bez daty wygaśnięcia to nie wyjątek, tylko kapitulacja.
Naprawa: wąskie gardło jest organizacyjne
Skanowanie jest tanie — naprawa kosztuje. Trzy rzeczy, które odblokowują przepływ:
- Automatyzacja łatania tam, gdzie ryzyko zmiany jest niskie (stacje robocze, przeglądarki, oprogramowanie standardowe): pierścienie wdrożeń (pilot → reszta) zamiast ręcznego zatwierdzania każdej łatki.
- Integracja z pracą zespołów: podatności trafiają jako zadania do systemu ticketowego właściciela (Jira/DevOps), nie jako PDF do skrzynki. Co nie jest w backlogu, nie istnieje.
- Naprawa przyczyn, nie objawów: jeśli co skan wraca to samo (stare biblioteki w obrazach, brak procesu aktualizacji u dostawcy aplikacji), problemem jest proces — i to jego naprawa powinna być ticketem.
Metryki, które coś znaczą
Zarząd nie potrzebuje liczby podatności (zawsze będzie duża). Raportuj to, co opisuje ryzyko i sprawność:
- Czas naprawy (MTTR) per klasa — szczególnie dla krytycznych wykorzystywanych,
- Odsetek zasobów w SLA — ile % podatności krytycznych/wysokich naprawiono w terminie,
- Ekspozycja: liczba podatności KEV otwartych na zasobach internetowych (cel: zero, mierzony w godzinach),
- Pokrycie skanowania: % zasobów z inwentarza realnie skanowanych z uwierzytelnieniem,
- Dług: trend liczby przeterminowanych względem SLA (kierunek ważniejszy niż wartość).
Pięć liczb na jednym slajdzie co miesiąc — to wystarczy, żeby program był rozliczalny.
Gdzie wpasować testy penetracyjne
Skaner znajduje znane podatności; nie znajdzie błędów logiki, złych uprawnień ani łańcuchów ataku łączących drobne słabości. Dlatego dojrzały program łączy: ciągłe skanowanie (szerokość) z okresowymi testami penetracyjnymi (głębokość) — tak przygotujesz się do testu. Wyniki pentestu zasilają ten sam proces: te same SLA, ta sama ścieżka wyjątków, ten sam backlog. U klientów w stałej opiece spinamy obie pętle w jeden rytm: skan → priorytety → naprawa → retest.
Najczęstsze pytania (FAQ)
Jaki skaner wybrać? Mniej ważne, niż się wydaje. Każdy uznany skaner (komercyjny czy open source jak OpenVAS) znajdzie 90% tego samego. Wybieraj pod: pokrycie Twojego środowiska (chmura? kontenery?), skan z uwierzytelnieniem, integracje z ticketami i jakość deduplikacji. Reszta to proces.
Mamy 4000 otwartych podatności. Od czego zacząć? Od filtra trzech pytań: (1) co jest w CISA KEV i wystawione do internetu — napraw w tym tygodniu; (2) co krytyczne na systemach o znaczeniu biznesowym — w tym miesiącu; (3) resztę potnij po przyczynach (np. „stary OpenSSL wszędzie” to jeden projekt, nie 800 ticketów). Po dwóch takich cyklach lista zrobi się zarządzalna.
Jak często raportować i komu? Operacyjnie: tygodniowy przegląd nowych krytycznych z właścicielami systemów. Zarządczo: miesięczny dashboard z metrykami wyżej. Po każdym incydencie branżowym typu „głośne CVE”: jednorazowy raport „czy nas dotyczy, co zrobiliśmy” — to buduje zaufanie zarządu lepiej niż sto slajdów.
Czy chmura zmienia ten proces? Zmienia narzędzia, nie zasady. Dochodzą: skan konfiguracji (CSPM), obrazy kontenerów w rejestrze, IaC przed wdrożeniem. Zaleta: w chmurze naprawa bywa szybsza (nowy obraz zamiast łatania serwera). Wada: inwentarz zmienia się z godziny na godzinę — automatyzacja inwentaryzacji przestaje być opcją.
Nie mamy ludzi do prowadzenia tego procesu. Co realnie zrobić? Minimalny wariant do wdrożenia od zaraz: automatyczne aktualizacje wszędzie, gdzie się da; cotygodniowy skan zewnętrznej powierzchni; abonament na czyjś nadzór nad resztą. Ten model oferujemy w pakietach wsparcia — comiesięczny skan z priorytetyzacją i konkretną listą „napraw te 12 rzeczy”. Porozmawiajmy.
Podsumowanie
Zarządzanie podatnościami to pętla: widzisz wszystko → skanujesz regularnie → priorytetyzujesz po ryzyku (KEV/EPSS × ekspozycja × krytyczność) → naprawiasz w terminach → mierzysz i wracasz. Skaner jest w tej pętli najmniejszym problemem. Jeśli chcesz zderzyć swój proces z rzeczywistością — test penetracyjny pokaże, które z „niskich” podatności układają się w ścieżkę do Twoich danych.
