CVE, NVD i KEV: jak powstał język podatności

CVE nie jest bazą poprawek, skanerem ani oceną ryzyka. To wspólny identyfikator konkretnej, publicznie opisanej podatności. Powstał, ponieważ pod koniec lat 90. różne bazy, dostawcy i narzędzia nadawały tym samym problemom inne nazwy. Zespół nie mógł łatwo ustalić, czy alert skanera, advisory producenta i sygnatura IDS opisują tę samą lukę.

Dzisiejszy ekosystem składa się z kilku warstw: CVE identyfikuje, CNA publikuje rekord, NVD wzbogaca go o dane, CVSS opisuje techniczną dotkliwość, EPSS szacuje prawdopodobieństwo wykorzystania, a katalog CISA KEV wskazuje potwierdzone aktywne wykorzystanie. Pomylenie tych ról prowadzi do złych priorytetów.

Przed CVE: disclosure bez wspólnego języka

W latach 90. informacje o lukach krążyły przez listy mailingowe, archiwa producentów, CERT i niezależne bazy. Bugtraq, utworzony w 1993 roku, stał się jednym z najważniejszych publicznych forów technicznego ujawniania podatności. Publikacje mogły zawierać opis, wersje, obejście i kod demonstracyjny. Otwarta dyskusja przyspieszała poprawki, ale wywoływała spór o moment i szczegółowość publikacji.

Pełne ujawnienie zakładało, że publiczna presja zmusza dostawcę do reakcji i daje użytkownikom wiedzę. Koordynowane ujawnienie dawało producentowi czas na przygotowanie poprawki. Oba modele próbowały rozwiązać asymetrię: odkrywca, dostawca, użytkownik i atakujący mają inne cele oraz terminy.

Największym problemem operacyjnym pozostawało nazewnictwo. „Błąd przepełnienia w usłudze X” mógł występować pod kilkoma nazwami. Automatyczna korelacja była zawodna, a liczby z różnych baz nie porównywały się.

1999: narodziny CVE

David E. Mann i Steven M. Christey z MITRE przedstawili koncepcję wspólnej enumeracji podczas warsztatów w Purdue w styczniu 1999 roku. Powstała grupa robocza i początkowy zbiór 321 rekordów. Lista CVE została publicznie uruchomiona we wrześniu 1999 roku.

Projekt celowo był słownikiem, nie uniwersalną bazą wiedzy. Identyfikator CVE-rok-numer umożliwia różnym stronom wskazanie tej samej podatności. Opis, referencje i produkty mogą się zmieniać, lecz identyfikator pozostaje punktem korelacji.

Wczesny proces był bardziej scentralizowany. Wraz ze wzrostem liczby produktów program rozbudował model CNA—CVE Numbering Authorities. Dostawcy, koordynatorzy i inne uprawnione organizacje rezerwują identyfikatory oraz publikują rekordy w swoim zakresie. Federacja skaluje proces, ale powoduje różnice w jakości i szybkości opisów.

Cykl życia rekordu CVE

Odkrywca zgłasza problem dostawcy, koordynatorowi lub CNA.
CNA sprawdza, czy problem mieści się w zakresie i nie jest duplikatem.
Identyfikator otrzymuje stan RESERVED—numer istnieje, ale szczegóły nie są publiczne.
Po ujawnieniu CNA publikuje opis, wersje i referencje; stan przechodzi na PUBLISHED.
Rekord może być aktualizowany, uzupełniany przez Authorized Data Publishers albo oznaczony REJECTED, na przykład jako duplikat.

RESERVED nie dowodzi ukrywanego zero-day. Numer można zarezerwować z wyprzedzeniem, a publikacja zależy od poprawki i koordynacji. REJECTED nie usuwa numeru; pozostaje informacja, by narzędzia nie przypisały go ponownie.

NVD: wzbogacenie, nie źródło identyfikatora

National Vulnerability Database NIST pobiera rekordy z CVE List i je wzbogaca. Dodaje między innymi mapowania CPE produktów, klasy CWE i oceny CVSS. NVD może mieć rekord „awaiting analysis” lub „not scheduled”, mimo że CVE jest już opublikowane. Brak oceny NVD nie oznacza braku podatności.

NVD istnieje w pewnej formie od 1999 roku, a jakość starszych rekordów jest nierówna. NIST wprost ostrzega, że wpisy sprzed 2015 roku mogą mieć mniej szczegółów. Narzędzia nie powinny bezrefleksyjnie traktować CPE jako doskonałego inwentarza: nazwy produktów i zakresy wersji bywają niekompletne.

Praktyczny przepływ powinien łączyć rekord CNA i advisory producenta z lokalnym dowodem wersji oraz konfiguracji. NVD pomaga korelować, ale nie zastępuje weryfikacji ekspozycji.

CVSS: severity to nie risk

Common Vulnerability Scoring System powstał, ponieważ dostawcy używali nieporównywalnych skal. FIRST został opiekunem CVSS w 2005 roku. Base score opisuje techniczne cechy podatności: wektor ataku, złożoność, wymagane uprawnienia, interakcję użytkownika i wpływ. Kolejne wersje rozwijały sposób opisu zakresu i skutków.

CVSS nie zna Twojej organizacji. Nie wie, czy produkt stoi w Internecie, czy system przetwarza krytyczne dane, czy exploit jest aktywnie używany ani czy kontrola kompensacyjna blokuje drogę. 9.8 oznacza poważne właściwości techniczne w założonym scenariuszu, nie automatycznie najwyższy priorytet w każdym środowisku.

Do lokalnej decyzji potrzebne są co najmniej:

obecność podatnego produktu i wersji;
osiągalność z perspektywy napastnika;
znaczenie zasobu i możliwy wpływ biznesowy;
potwierdzone wykorzystanie lub wiarygodna dostępność exploita;
istniejące kontrole oraz koszt bezpiecznej poprawki.

2021: CISA KEV zmienia rozmowę o priorytecie

3 listopada 2021 roku CISA opublikowała Binding Operational Directive 22-01 i żywy katalog Known Exploited Vulnerabilities. Do KEV trafiają CVE, dla których istnieją wiarygodne dowody aktywnego wykorzystania oraz działanie naprawcze. Dyrektywa zobowiązuje amerykańskie cywilne agencje federalne do naprawy w terminie; CISA zaleca katalog również innym organizacjom.

KEV odpowiada na problem skali. Tysiące wysokich ocen CVSS konkurują o zasoby, lecz napastnicy wykorzystują podzbiór. Obecność w KEV jest silnym sygnałem operacyjnym. Nadal trzeba potwierdzić, czy produkt istnieje w środowisku, ale nie należy czekać na idealną analizę ryzyka.

Katalog nie jest pełną listą wszystkich exploitowanych luk na świecie. Wpis wymaga spełnienia kryteriów i procesu potwierdzenia. Brak w KEV nie oznacza bezpieczeństwa; obecność oznacza natomiast, że argument „brak dowodu wykorzystania” przestał obowiązywać.

EPSS, SSVC i dojrzalsze priorytety

Exploit Prediction Scoring System FIRST wykorzystuje model statystyczny do oszacowania prawdopodobieństwa wykorzystania CVE w najbliższym okresie. EPSS jest probabilistyczny i zmienny. Nie mierzy wpływu, więc wysoki EPSS przy niskim wpływie i niski EPSS przy krytycznym aktywie wymagają różnych decyzji.

Stakeholder-Specific Vulnerability Categorization CISA i SEI prowadzi przez drzewo decyzji uwzględniające status wykorzystania, wpływ techniczny, znaczenie misji i możliwość działania. To alternatywa dla sortowania jedną liczbą. NVD zaczęło udostępniać dodatkowe dane wspierające takie decyzje.

Najlepsza praktyka łączy sygnały: KEV dla potwierdzonego wykorzystania, EPSS dla prawdopodobieństwa, CVSS dla technicznych właściwości i lokalny kontekst dla wpływu.

Kod PoC: dowód, narzędzie czy ryzyko

Proof of concept może potwierdzić przyczynę i pomóc w bezpiecznym retestowaniu. Publiczny kod obniża jednak koszt wejścia dla napastników. Link oznaczony „PoC” nie jest automatycznie bezpieczny: repozytoria podszywające się pod exploity rozprowadzały malware.

W środowisku obronnym kod należy przeglądać, uruchamiać w izolacji, przypinać do konkretnego commita i nigdy nie testować bez zgody na produkcji. Tam, gdzie wystarczy kontrola wersji, baner lub nieinwazyjna sonda, pełny exploit jest niepotrzebnym ryzykiem. Takie podejście stosujemy w zarządzaniu podatnościami.

Najczęstsze błędy programu podatności

Liczenie CVE zamiast mierzenia czasu redukcji ekspozycji.
Traktowanie CVSS jako ryzyka biznesowego.
Brak właściciela zasobu i terminu naprawy.
Zamknięcie zgłoszenia po instalacji poprawki bez retestu.
Ignorowanie urządzeń brzegowych i oprogramowania bez agenta.
Brak procesu wyjątków, kontroli kompensacyjnych i daty ponownej oceny.
Skanowanie bez kompletnego inwentarza.

Dobry proces kończy się dowodem: poprawioną wersją, zmianą konfiguracji, niedostępnością ścieżki ataku i zapisem retestu. Pentest aplikacji webowej uzupełnia skan, sprawdzając, czy kilka pozornie średnich słabości tworzy krytyczny łańcuch.

Log4Shell jako test całego ekosystemu

Ujawnienie CVE-2021-44228 w Apache Log4j pokazało, że identyfikator jest dopiero początkiem. Organizacje musiały ustalić, czy biblioteka znajduje się bezpośrednio w aplikacji, wewnątrz archiwum Java, w produkcie dostawcy albo obrazie kontenera. Sama lista serwerów nie wystarczała. Potrzebny był inwentarz komponentów, kontakt z dostawcami, obserwacja prób wykorzystania i wielokrotne aktualizacje, gdy zmieniał się zakres zaleceń.

Raport amerykańskiej Cyber Safety Review Board opisał Log4j jako podatność endemiczną, która będzie pozostawać w systemach przez lata. To ilustracja różnicy między publikacją CVE a redukcją ekspozycji. Program SBOM i bezpieczeństwa łańcucha dostaw pomaga znaleźć zależność, lecz SBOM musi być aktualny i powiązany z wdrożeniem.

Od alertu do zamknięcia: minimalny workflow

Po pojawieniu się ważnego CVE zespół powinien potwierdzić źródło w advisory CNA lub producenta, zmapować wersje na aktywa, określić osiągalność, sprawdzić KEV i telemetrię prób ataku, wskazać właściciela, wybrać poprawkę albo kontrolę kompensacyjną, wykonać bezpieczny retest oraz zachować dowód i termin przeglądu wyjątku.

Internetowe urządzenia brzegowe wymagają szybszej ścieżki, ponieważ nie chroni ich wewnętrzna segmentacja, a napastnicy skanują je automatycznie. Pomaga tu zarządzanie zewnętrzną powierzchnią ataku. Program ujawniania podatności daje badaczom bezpieczny kanał, zanim informacja zacznie krążyć bez koordynacji.

Metryki powinny mierzyć wynik, nie tylko liczbę rekordów: czas od publikacji do identyfikacji aktywa, czas od wpisu do KEV do mitygacji, odsetek wyjątków z ważną kontrolą kompensacyjną oraz skuteczność retestów. Surowa liczba CVE może rosnąć właśnie dlatego, że inwentarz i wykrywanie działają lepiej. Dobry dashboard pokazuje również zasoby bez właściciela, poprawki oczekujące na okno serwisowe i wyjątki, których termin już minął.

FAQ

Czy każdy CVE jest groźny?

Nie. CVE identyfikuje podatność, ale realne ryzyko zależy od obecności produktu, konfiguracji, ekspozycji, znaczenia zasobu i aktywności napastników.

Kto nadaje numery CVE?

Uprawnione CVE Numbering Authorities, w tym dostawcy i koordynatorzy, publikują rekordy w swoim zakresie. MITRE pełni kluczową rolę w programie, ale system jest federacyjny.

Czy NVD i CVE to to samo?

Nie. CVE Program tworzy identyfikatory i rekordy. NVD pobiera je i wzbogaca o dane takie jak CVSS, CWE i CPE.

Co łatać najpierw?

Najpierw potwierdzone podatne zasoby z aktywnym wykorzystaniem, szczególnie internetowe i krytyczne. Dalej uwzględniaj prawdopodobieństwo exploita, wpływ, osiągalność i kontrole. Sama kolejność CVSS jest niewystarczająca.

Źródła

Potrzebujesz ustalić, które podatności tworzą realną drogę do danych? Zamów test penetracyjny z walidacją wpływu i bezpiecznym retestem.