Ta sama podatność, ten sam numer CVE, ten sam CVSS — a trzy różne decyzje. Wszystko zależy od tego, gdzie ona występuje. Bo ryzyko nie mieszka w podatności. Mieszka w zasobie, na którym ta podatność siedzi.
Problem
Skaner ocenia podatność, nie miejsce, w którym ona żyje. Wypluwa listę, na której CVE na zapomnianej maszynie testowej wygląda identycznie jak ten sam CVE na systemie obsługującym płatności. Z perspektywy skanera to jeden wiersz. Z perspektywy ryzyka — dwa różne światy.
To naturalne ograniczenie narzędzia. Skaner zna podatność. Nie zna Twojej organizacji — tego, co jest wystawione, co jest krytyczne i czego nikt nie pilnuje.
Dlaczego to ma znaczenie
podatność w próżni → podatność w kontekście zasobu
Kontekst zasobu to kilka wymiarów, które razem decydują o priorytecie:
- Ekspozycja — czy system jest osiągalny z internetu, czy zamknięty w wewnętrznym segmencie.
- Krytyczność biznesowa — czy to serwis na ścieżce przychodowej, czy poboczne narzędzie.
- Wrażliwość danych — co ten system przetwarza i przechowuje.
- Osiągalność — czy atakujący w ogóle do niego dotrze (segmentacja, firewalle).
- Promień rażenia — czy to komponent współdzielony przez wiele aplikacji.
- Stan opieki — czy ktoś ten system w ogóle utrzymuje i monitoruje.
Ten ostatni wymiar jest najczęściej pomijany, a bywa decydujący. Zapomniana maszyna bez właściciela potrafi być groźniejsza niż znana aplikacja krytyczna — bo nikt jej nie łata, nikt nie patrzy w jej logi i nikt nie zauważy, że ktoś już na niej jest.
Przykład z organizacji
Weźmy jedną podatność, CVSS 6.5, i trzy miejsca, w których ją znajdujemy:
Ten sam numer. Trzy różne decyzje. I czwarty przypadek, który zmienia skalę: jeśli ta podatność siedzi w obrazie bazowym używanym przez 40 usług, jedna poprawka ma czterdziestokrotny zasięg. To też kontekst — tylko liczony promieniem rażenia, nie ekspozycją.
Tu wraca wątek z wcześniejszych części: żeby przypisać kontekst, najpierw musisz wiedzieć, co masz i gdzie to działa. Bez inwentaryzacji — zwłaszcza tej obejmującej zapomniane, lokalnie uruchamiane hosty — kontekst jest zgadywany, a priorytety stają się loterią.
Dobre praktyki
- Buduj i utrzymuj inwentaryzację zasobów z atrybutami, które realnie zmieniają priorytet: ekspozycja, krytyczność, właściciel, rodzaj danych.
- Traktuj „brak właściciela" jako sygnał ryzyka, nie jako puste pole do uzupełnienia kiedyś.
- Uwzględniaj promień rażenia — komponenty współdzielone priorytetyzuj wyżej.
- Nie zakładaj, że „wewnętrzne" znaczy „bezpieczne". Segmentacja bywa teoretyczna.
- Łącz kontekst zasobu z sygnałami o wykorzystaniu i ekspozycji — dopiero to razem daje priorytet.
Najczęstsze błędy
- Priorytetyzacja podatności w oderwaniu od miejsca, w którym występuje.
- Traktowanie wszystkiego „wewnętrznego" jako nieistotne z założenia.
- Ignorowanie zapomnianych, niczyich systemów — często najbardziej narażonych.
- Brak inwentaryzacji, przez co kontekst jest zgadywany z pamięci.
- Równe traktowanie środowiska testowego i produkcyjnego.
Podsumowanie
Priorytet podatności nie wynika z samej podatności. Wynika z zasobu: jak bardzo wystawiony, jak ważny, jak osiągalny, ilu rzeczy dotyczy i czy ktokolwiek go pilnuje. Dopóki nie znasz kontekstu zasobu, nie priorytetyzujesz ryzyka — sortujesz liczby.