Dlaczego CVSS zapewnia fałszywe poczucie bezpieczeństwa?

CZY SAM CVSS DZISIAJ WYSTARCZY?

CVSS (Common Vulnerability Scoring System) to techniczny standard opracowany po to, by w ujednolicony sposób oceniać powagę podatności. W teorii wystarczy wprowadzić kilka parametrów i otrzymać wynik w skali od 0 do 10. Brzmi prosto — ale właśnie w tej prostocie kryje się największy problem.

System CVSS opiera się na trzech grupach metryk – bazowych, czasowych i środowiskowych – które razem mają opisać ogólne ryzyko związane z podatnością. System ten zakłada, że oceniający zna dokładnie sposób wykorzystania oprogramowania, środowisko jego pracy oraz potencjalny wpływ błędu na bezpieczeństwo.

Ostateczny poziom ryzyka zależy od kontekstu – zastosowanych zabezpieczeń, znaczenia systemu w środowisku czy jego ekspozycji na atak. Dlatego CVSS warto traktować jako punkt wyjścia do analizy, a nie ostateczny wyznacznik priorytetu działań naprawczych.

DLACZEGO CVSS ZAWODZI W PRAKTYCE?

1. Kontekst, kontekst i jeszcze raz kontekst
   CVSS opiera się na ograniczonej liczbie parametrów i nie bierze pod uwagę tego, gdzie i jak oprogramowanie jest wykorzystywane. Luka w narzędziu używanym w miliardach środowisk i systemów — może być teoretycznie poważna, ale w praktyce dotyczyć tylko specyficznej, rzadko spotykanej konfiguracji. CVSS nie rozróżnia takich przypadków.
2. Automatyczne i powierzchowne ocenianie.
   Każda nowa podatność (CVE) powinna mieć przypisany wynik CVSS. Gdy autorzy go nie podadzą, urzędowe instytucje „uzupełniają” brakujące dane. Problem polega na tym, że robią to często bez głębszej znajomości technologii. Efekt? Setki tysięcy luk ocenianych przez osoby, które nie mają rzeczywistego kontekstu produktu ani jego architektury.

W rezultacie trafność wielu takich ocen jest czysto przypadkowa. Część podatności zostaje niesłusznie oznaczona jako krytyczne, co prowadzi do niepotrzebnej paniki i błędnych decyzji w organizacjach.

• Konsekwencje błędnych ocen.
  Wystarczy jedna niepoprawnie wysoka ocena, by setki skanerów bezpieczeństwa zaczęły zgłaszać krytyczny problem. W praktyce administratorzy zaczynają usuwać lub aktualizować komponenty systemu tylko po to, by pozbyć się alertu — nawet jeśli rzeczywiste ryzyko jest minimalne.

DLACZEGO ORGANIZACJE NADAL UFJĄ CVSS?

Pomimo wszystkich ograniczeń CVSS stał się podstawą dla całego ekosystemu narzędzi skanujących i raportujących. Automatyczne skanery, raporty zgodności i systemy SIEM polegają na tej punktacji jako łatwym wskaźniku ryzyka.

W efekcie powstał błędny obieg informacji:

• Skany opierają się na CVSS,
• Firmy reagują na alerty,
• Audytorzy weryfikują zgodność z CVSS,
• A faktyczne ryzyko często pozostaje bez zmian.

W ten sposób CVSS przestał być narzędziem analitycznym, a stał się systemem używanym, bo „tak trzeba”.

JAK SECUREVISIO POMAGA W OCENIE RZECZYWISTEGO POZIOMU RYZYKA PODATNOŚCI?

SecureVisio rozszerza klasyczne podejście bazujące na CVSS o elementy kontekstowe. Tradycyjny wynik CVSS (tzw. base score) stanowi jedynie punkt wyjścia. System oblicza następnie indywidualny wskaźnik ryzyka na podstawie danych z infrastruktury i procesów organizacji. Pod uwagę brane są m.in.:

• znaczenie danego zasobu w środowisku (np. czy to maszyna testowa, czy kluczowy serwer produkcyjny),
• powiązania z procesami biznesowymi (np. obsługa płatności lub przetwarzanie danych osobowych),
• zastosowane mechanizmy ochronne (firewall, WAF, systemy klasy EDR),
• a także inne czynniki wpływające na prawdopodobieństwo i skutki potencjalnego incydentu.

W efekcie organizacja otrzymuje priorytety, które rzeczywiście odzwierciedlają kontekst ryzyka, a nie tylko liczbową ocenę. Przykładowo, w panelu SecureVisio może się okazać, że podatność z bazowym CVSS 7.2 ma wyższy priorytet naprawy niż inna z wynikiem 9.8 – ponieważ dotyczy zasobu o krytycznym znaczeniu lub eksponowanego w strefie zdemilitaryzowanej (DMZ).

Po wejściu w szczegóły podatności administrator może sprawdzić m.in.:

• lokalizację aktywa (np. DMZ),
• przypisany poziom krytyczności,
• powiązania z procesami biznesowymi,
• oraz listę innych zależnych podatności.

Zintegrowana baza CMDB ułatwia z kolei analizę środowiskową – można w niej szybko sprawdzić, jakie inne systemy lub aplikacje znajdują się w tej samej strefie sieciowej, np. serwery aplikacji wewnętrznych czy stanowiska testowe.

Dalszą częścią analizy jest mapowanie zagrożeń dla konkretnego aktywa. Dla przykładu, w przypadku serwera WordPress system może wskazać potencjalne wektory ataku typu server-side attack oraz pokazać możliwe ścieżki przełamania zabezpieczeń – od warstwy zewnętrznej po komponenty w DMZ. Równocześnie widać, jakie środki ochrony są już aktywne, np. firewall aplikacyjny lub kontrola dostępu do usług.

Całość daje dużo pełniejszy obraz sytuacji niż sam wynik CVSS – pozwala zobaczyć, które zagrożenia są faktycznie istotne, jak rozkładają się zależności między zasobami i jakie działania przyniosą największy efekt w ograniczeniu ryzyka.