Elementrica
03Realizacje04Referencje05Firma06Aktualności07Kontakt
PLENDE

Dlaczego wyniki CVSS często nie odzwierciedlają rzeczywistych zagrożeń

ElementricaElementrica4 min
Dlaczego wyniki CVSS często nie odzwierciedlają rzeczywistych zagrożeń

Wysoki wynik CVSS nie znaczy, że luka realnie Ci zagraża. Niski nie znaczy, że możesz ją zignorować. CVSS to użyteczny standard oceny podatności, ale traktowany jako jedyne kryterium potrafi skierować budżet i uwagę zespołu w złe miejsce. Poniżej pokazujemy, gdzie CVSS zawodzi, co ujawniła analiza JFrog i jak priorytetyzować podatności bliżej rzeczywistego ryzyka.

Czym jest CVSS i po co powstał

Common Vulnerability Scoring System (CVSS) to otwarty standard oceny wagi podatności, utrzymywany przez organizację FIRST. Nadaje luce wynik liczbowy, który ma pomóc ustalić kolejność łatania.

Wyniki CVSS przypisuje między innymi baza NVD prowadzona przez NIST i publikuje je. Zespoły bezpieczeństwa używają ich na co dzień do oceny pilności. Problem zaczyna się, gdy liczba staje się jedynym kryterium decyzji.

Co ujawniła analiza JFrog

W 2022 roku firma JFrog przeanalizowała 50 najczęstszych podatności (CVE) w oprogramowaniu open source i porównała publiczne wyniki CVSS z własną oceną realnego wpływu. Rozbieżności były duże.

  • Zawyżona waga. W 64% przypadków realny wpływ był niższy, niż sugerował wynik NVD. Firmy angażują więc zasoby w usuwanie luk, które w ich środowisku niewiele znaczą.
  • Przykład CVE-2022-3602. Podatność w weryfikacji certyfikatów X.509 początkowo uznano za krytyczną. Bliższa analiza pokazała marginalny wpływ, bo realne wykorzystanie było bardzo trudne.
  • Niedoceniane luki. Część powszechnych, groźnych w praktyce podatności miała niskie wyniki CVSS. Takie luki są odkładane i z czasem stają się realnym wektorem ataku.

Dlaczego sam wynik nie wystarcza

Ograniczenia CVSS wynikają z trzech rzeczy.

  • Brak kontekstu. Ten sam błąd jest czym innym w odizolowanym systemie wewnętrznym, a czym innym w usłudze wystawionej do internetu. Podstawowy wynik CVSS tego nie widzi.
  • Uproszczona złożoność ataku. Luka wymagająca zaawansowanej wiedzy albo połączenia z innym błędem może dostać wysoki wynik, mimo że w pojedynkę jest trudna do wykorzystania.
  • Statyczny model. Wynik nie zmienia się w czasie. Nowa technika ataku podnosi realne ryzyko, a dostępna łatka je obniża, ale liczba zostaje ta sama, dopóki ktoś jej manualnie nie zaktualizuje.

Co to znaczy dla Twojej firmy

Trzymanie się wyłącznie wyników CVSS ma wymierny koszt:

  • łatasz mniej ważne luki, a groźniejsze czekają w kolejce,
  • budżet bezpieczeństwa idzie tam, gdzie nie zmniejsza realnego ryzyka,
  • podatności z niskim wynikiem, ale wysokim realnym wpływem, zostają w systemie miesiącami.

CVSS 4.0 i kierunek zmian

Nowsza wersja standardu, CVSS 4.0, ma częściowo odpowiadać na te problemy. Dodaje między innymi oceny pilności od twórców produktu oraz wskaźniki uwzględniające warunki środowiskowe i dojrzałość exploita.

Sami autorzy standardu przyznają, że CVSS nie jest kompletnym rozwiązaniem. To jedno z narzędzi, które trzeba łączyć z analizą zagrożeń i znajomością własnego środowiska.

Jak priorytetyzować podatności rozsądnie

  • Oceniaj w kontekście. Bierz pod uwagę, gdzie działa system, jak jest wystawiony i jak krytyczne dane obsługuje.
  • Aktualizuj ocenę. Śledź, czy pojawił się działający exploit albo łatka, i zmieniaj priorytety na bieżąco.
  • Łącz źródła. Traktuj CVSS jako jeden element szerszego zarządzania ryzykiem, obok analizy zagrożeń i krytyczności zasobów.

Najpewniejszy sposób, żeby dowiedzieć się, które luki naprawdę da się u Ciebie wykorzystać, to test penetracyjny. Pokazuje realne ścieżki ataku, a nie samą listę wyników. Umów bezpłatną konsultację i sprawdźmy, gdzie w Twoim środowisku ryzyko jest naprawdę wysokie.

Chcesz wiedzieć, które luki realnie Ci zagrażają?

Umów bezpłatną konsultację, a w teście penetracyjnym pokażemy, które podatności da się u Ciebie faktycznie wykorzystać.

Poprzedni
Wzmocnienie cyberbezpieczeństwa w sektorze finansowym: kompletny przewodnik po ustawie o cyfrowej odporności operacyjnej (DORA)
Następny
Wprowadzenie do NIST Cybersecurity Framework