Scoring podatności vs. rzeczywistość – Dlaczego CVSS nie wystarczy
Spis treści
Dlaczego sam CVSS nie wystarczy?
Współczesne zarządzanie podatnościami zwykle opiera się na skanowaniu systemów i reagowaniu na wykryte luki. Najczęściej używanym standardem ich oceny jest CVSS – system, który przypisuje podatności ocenę od 0 do 10.
Problem w tym, że CVSS ocenia lukę technicznie, a nie kontekstowo. Dwie podatności o identycznym wyniku mogą stanowić zupełnie inne ryzyko, w zależności od tego, gdzie występują i jakie zabezpieczenia chronią system.
Przykład:
Podatność o CVSS 9.8 na serwerze przetwarzającym kluczowe dane, znajdującym się poza zabezpieczoną strefą, będzie miałaznacznie większe znaczenie biznesowe niż ta sama luka na systemie umieszczonym w odizolowanej sieci DMZ, chronionej przez WAF i firewalle.
Niestety metryki CVSS nie uwzględniają takiego kontekstu – mogą nadać wysoki wynik nawet w sytuacjach, gdy realne ryzyko jest niskie.
Dlatego organizacje, które chcą skutecznie priorytetyzować podatności i podejmować świadome decyzje naprawcze, powinnyłączyć scoring techniczny CVSS z analizą kontekstu biznesowego i środowiskowego.
Jest to szczególnie ważne z perspektywy liczby podatności – liczba nowych podatności odkrytych w 2024 roku wzrosła o 38% w porównaniu z rokiem poprzednim, osiągając poziom ponad 40 000 nowych CVE (Common Vulnerabilities and Exposures – luki i podatności). Statystyki z 2024 roku pokazują średnio 108 CVE publikowanych codziennie.
W tym artykule pokażemy, dlaczego sam wynik CVSS nie wystarczy, jakie są jego ograniczenia oraz jak podejść do zarządzania podatnościami w oparciu o realne ryzyko.
Jak system CVSS ocenia podatności?
CVSS (Common Vulnerability Scoring System) to standardowa metoda nadawania liczbowej oceny podatności komputerowych systemów i aplikacji. Skala ocen wynosi od 0 do 10, gdzie 0 oznacza brak zagrożenia, a 10 – krytyczną podatność.
System CVSS składa się z trzech głównych grup metryk:
- Podstawowe (Base) – definiują fundamentalne cechy podatności, niezależnie od środowiska organizacji. Obejmują obszary jak:
- Konsekwencje ataku dla poufności, integralności i dostępności danych
- Łatwość wykorzystania podatności
- Czasowe (Temporal) – uwzględniają czynniki zmienne w czasie, np.:
- Dostępność poprawek
- Tempo możliwego wykorzystania podatności przez cyberprzestępców
- Środowiskowe (Environmental) – pozwalają dopasować wynik CVSS do konkretnego środowiska organizacji, uwzględniając specyficzne konfiguracje systemów, ich znaczenie biznesowe czy istniejące zabezpieczenia.
Dlaczego wysoki wynik CVSS może wprowadzać w błąd?
Początkowa ocena ryzyka danej podatności może wynosić 9, ale w rzeczywistości jej zagrożenie często da się znacznie ograniczyć dzięki zaaplikowanym zabezpieczeniom czy ochronie perymetru czyli przez rozwiązania takie jak firewall czy segmentację sieci.
CVSS może wydawać się niezwykle wartościowym rozwiązaniem do oceny podatności z perspektywy ogólnej dostępności scoringu CVSS czy systemowemu podejściu autorów CVSS jednak wysoki wynik nie zawsze oznacza rzeczywiste zagrożenie dla Twojej organizacji. Wynika to głównie z:
- Braku pełnej znajomości środowiska organizacji – CVSS nie zna w pełni Twojej infrastruktury. Podatność z wysokim wynikiem (np. 9/10) może być bardzo trudna do wykorzystania w odizolowanym systemie.
- Brak priorytetu biznesowego – podatność może dotyczyć aktywa, które nie jest kluczowe z perspektywy podstawowej działalności biznesowej, a mimo to uzyskać wysoki wynik CVSS.
- Nie uwzględnia istniejących kontrolek bezpieczeństwa – wdrożone polityki, narzędzia jak firewall czy IDS/IPS mogą znacząco zmniejszać ryzyko, czego CVSS nie mierzy. CVSS może pokazać wynik 8/10, a w praktyce zaaplikowane kontrolki na hoście mogą znacząco ograniczyć ryzyko.
Praktyczny przykład
Scoring podatność na podstawie CVSS: 9.8, czyli absolutnie krytyczny poziom
- Na jakich informacjach bazuje CVSS:
- Brak wymagań uwierzytelnienia czy wysoki wpływ na integralność i poufność danych.
- Czego CVSS nie uwzględni:
- Publiczny exploit nie działa w tej konfiguracji.
- Fakt, że nasz system IT znajduje się w odizolowanej sieci zabezpieczonej firewallami czy systemem IDS.
Jakie podejście rekomendują organizacje jak Gartner?
Według Gartnera organizacje powinny odchodzić od klasycznego podejścia opartego wyłącznie na CVSS i stosować RBVM – podejście, w którym ryzyko jest oceniane całościowo, biorąc pod uwagę:
- ważność zasobu – czy dotyczy systemu produkcyjnego czy testowego,
- ekspozycję – czy podatność jest dostępna z internetu,
- zastosowane zabezpieczenia – np. WAF, IDS/IPS, firewall, segmentacja sieci,
- powiązania biznesowe – np. obsługa danych klientów czy transakcji finansowych.
Takie podejście pozwala skoncentrować się na podatnościach realnie groźnych, zamiast gasić wszystkie „pożary” po kolei.
Jakie narzędzia mogą się okazać pomocne w ocenie prawdziwego ryzyka podatności?
Poniżej przedstawiamy przykład uzupełnienia base score CVSS przez SecureVisio w konsoli do zarządzania podatnościami. W platformie Priority kółko obok podatności wskazuje jej priorytet, który jest ustalany na podstawie indywidualnego scoringu ryzyka wyliczanego przez SecureVisio.
System bierze pod uwagę m.in.:
- rolę aktywa w organizacji (np. czy jest to serwer testowy, czy produkcyjny),
- powiązane procesy biznesowe (np. przetwarzanie danych pacjentów szpitala),
- zastosowane mechanizmy zabezpieczające (np. WAF),
- oraz wiele innych czynników wpływających na realne ryzyko.
Dzięki temu wiemy, które podatności są dla naszej organizacji kluczowe i od których warto rozpocząć analizę. Jak widać na poniższym screenie, podatność nr 0009 ma najwyższy priorytet, mimo że jej base score (7.2) jest niższy niż w przypadku podatności nr 0008, której base score wynosi 9.8.
Po kliknięciu w podatność nr 0009 możemy uzyskać szczegółowy wgląd w profil aktywa oraz powiązane z nim ryzyka. Widzimy m.in., że:
- aktywo znajduje się w strefie DMZ (strefa zdemilitaryzowana),
- zostało oznaczone jako krytyczne,
- jest powiązane z procesem biznesowym hosting,
- oraz posiada 6 innych powiązanych podatności.
SecureVisio udostępnia również bazę CMDB, która pomaga lepiej zrozumieć umiejscowienie danego aktywa w środowisku. Z jej poziomu możemy łatwo sprawdzić, jakie inne zasoby znajdują się w tej samej strefie DMZ — np. serwery wewnętrznie rozwijanych aplikacji czy stacje testowe Windows.
Na koniec przechodzimy do modułu analizy ryzyka. W naszym przypadku podatność jest związana z serwerem WordPress. Platforma prezentuje listę potencjalnych zagrożeń, które mogą dotyczyć tego konkretnego aktywa.
Po kliknięciu w zagrożenie server-side attack możemy zobaczyć, jak atakujący mogliby przedostać się z internetu do poszczególnych elementów infrastruktury, w tym do strefy DMZ, gdzie znajduje się nasz serwer WordPress. Widzimy również, jakie środki ochrony zostały wdrożone — np. Cerber (firewall, kontrola aplikacji).
Jest to tylko zestaw wbudowanych zagrożeń, który można dowolnie modyfikować. Dzięki temu analiza ryzyka pozwala uzupełnić kluczowe informacje dostępne w konsoli zarządzania podatnościami. Otrzymujemy pełniejszy obraz realnego obszaru zagrożeń dla konkretnego aktywa — uwzględniając zastosowane zabezpieczenia, powiązania środowiskowe oraz krytyczność zasobów.
Najnowsze publikacje
Ukryte wyzwania SIEM: Dlaczego problemy z logami podważają skuteczność działania SOC

Trecom SOC
04.09.2025
Największe wyzwania budowy i zarządzania SOC w środowiskach multicloud

Trecom SOC
04.09.2025