Zespół spędza sprint na łataniu CVSS 9.8, odnajdując ukryte w bibliotece błędy, których w środowisku produkcyjnym nigdy nie wywołano. Tymczasem CVSS 6.5, znajdujący się w dostępnym, internetowym punkcie końcowym, pozostaje otwarty przez kolejny miesiąc, ponieważ nigdy nie znalazł się na szczycie listy. To nie jest hipotetyczne, lecz domyślny wynik priorytetyzacji luk w zabezpieczeniach opartej wyłącznie na ocenie ważności, i jest to częstsza awaria, niż większość programów bezpieczeństwa jest skłonna przyznać.
Co właściwie ma zrobić priorytetyzacja luk w zabezpieczeniach
Priorytetyzacja luk w zabezpieczeniach to proces decydowania, które znaleziska zostaną naprawione w pierwszej kolejności, z listy, która prawie zawsze jest zbyt długa, aby ją w całości usunąć. Dobrze przeprowadzona, odpowiada na węższe i trudniejsze pytanie niż „jak poważna jest ta luka w zabezpieczeniach w teorii”: odpowiada na pytanie „w jakim stopniu naprawienie jej, już teraz, faktycznie zmniejsza ryzyko dla tego konkretnego systemu”. To nie są te same pytania, a ich mieszanie to błąd w większości działań priorytetyzacyjnych.
Dlaczego sam wskaźnik ważności zawodzi
CVSS nigdy nie został zaprojektowany jako kompletny system priorytetyzacji, jest to ocena ważności, opis tego, jak poważna mogłaby być teoretycznie luka w ogólnym kontekście. Nie mówi nic o:
- Dostępność. Niezależnie od tego, czy podatna ścieżka kodu jest faktycznie wywoływana gdziekolwiek w aplikacji, czy też tkwi w zależności, nic jej nie wywołuje.
- Możliwość wykorzystania. Nie wiadomo, czy luka w zabezpieczeniach istnieje już w praktyce, czy też jest to kwestia teoretyczna, istniejąca poza laboratorium.
- Ekspozycja. Niezależnie od tego, czy dany komponent ma dostęp do Internetu, czy też znajduje się trzy warstwy za wewnętrzną usługą i nie ma dostępu z zewnątrz.
- Kontekst biznesowy. Czy problem dotyczy danych klientów lub przepływów płatności, czy też jest wewnętrznym narzędziem o niskiej wartości, z którego nikt nie korzysta.
Podejście do priorytetyzacji luk w zabezpieczeniach, które opiera się wyłącznie na klasyfikacji CVSS, traktuje niedostępne podatności o wartości 9.8 jako bardziej pilne niż podatności o wartości 6.5 znajdujące się na dostępnej ścieżce internetowej ze znanym exploitem. Ta kolejność jest odwrotna i wynika bezpośrednio z oceny ważności, przy jednoczesnym ignorowaniu wszystkich innych czynników determinujących rzeczywiste ryzyko.
Ukryty koszt błędnej priorytetyzacji luk w zabezpieczeniach
Koszt to nie tylko stracone godziny pracy inżynierów, choć to realne: zespoły rutynowo poświęcają cykle na rozwiązywanie poważnych problemów, które nie stanowią praktycznego ryzyka, podczas gdy problemy, które rzeczywiście można wykorzystać, pozostają nierozwiązane. Subtelniejszym kosztem jest zaufanie. Kiedy programiści są wielokrotnie odrywani od prawdziwej pracy, aby naprawić luki w zabezpieczeniach, które okazują się niedostępne lub zostały już załatane gdzie indziej, zaczynają również ignorować kolejny alert, a cała idea priorytetyzacji luk w zabezpieczeniach, czyli naprawiania najpierw właściwych rzeczy, po cichu przestaje działać, mimo że lista jest technicznie i po kolei sprawdzana.
Czego tak naprawdę wymaga dobra priorytetyzacja luk w zabezpieczeniach
Skuteczna priorytetyzacja luk w zabezpieczeniach polega na nakładaniu na nie kilku sygnałów zamiast całkowitego zastąpienia ich:
- Analiza osiągalności. Sprawdź, czy podatna na ataki funkcja jest rzeczywiście wywoływana z kodu aplikacji, a nie tylko znajduje się w drzewie zależności.
- Wykorzystaj dostępność. Sprawdź, czy publiczna akcja lub aktywna kampania nie jest ukierunkowana na konkretną lukę, a nie tylko na rodzinę luk CVE.
- Deduplikacja pomiędzy skanerami. Ten sam podstawowy problem zgłaszany przez trzy różne narzędzia nie powinien być traktowany jako trzy oddzielne kwestie konkurujące o uwagę.
- Kontekst biznesowy i ekspozycji. Wyniki należy oceniać na podstawie tego, czego faktycznie dotyczy dany zasób, a nie tylko na podstawie ogólnego wyniku CVE.
- Widoczny lejek, a nie płaska lista. Możliwość sprawdzenia, ile ustaleń przetrwa każdy filtr, od każdego problemu do elementów rzeczywiście nadających się do wykorzystania, sprawia, że priorytetyzacja jest łatwa do obrony, a nie czarna skrzynka.
Ten ostatni punkt ma większe znaczenie, niż się wydaje. Płaska lista posortowana według ważności nie daje zespołowi poczucia skali: czy 40% zaległości to realne, czy 2%? Widok lejka, wszystkie ustalenia, następnie te, które można naprawić, następnie te, które można osiągnąć, następnie te ze znanym exploitem, a na końcu te, które rzeczywiście można wykorzystać w tym środowisku, zamienia przytłaczającą listę w krótką, możliwą do obrony.
Na co zwracać uwagę przy wyborze narzędzi do priorytetyzacji luk w zabezpieczeniach
Nie każda platforma reklamowana w kontekście priorytetyzacji luk w zabezpieczeniach faktycznie spełnia opisane powyżej funkcje. Podczas oceny narzędzi do priorytetyzacji luk w zabezpieczeniach, kilka pytań szybko przewija się przez marketing:
- Czy wskazuje dostępność, czy też tylko informuje o obecności podatnego pakietu?
- Czy usuwa duplikaty wyników z różnych skanerów, w tym z już używanych narzędzi innych firm, czy też każde źródło dodaje osobną, nieskorelowaną listę?
- Czy osoba odpowiedzialna za bezpieczeństwo widzi lejek, ile ustaleń zostało odfiltrowanych i dlaczego, czy tylko ostateczną „priorytetową” listę, nie mając wglądu w logikę stojącą za nią?
- Czy bierze pod uwagę dostępność exploitów na podstawie rzeczywistych informacji o zagrożeniach, czy tylko statyczny wynik CVSS publikowany w momencie ujawnienia?
- Czy priorytetyzacja dotyczy w równym stopniu wyników uzyskanych za pomocą natywnych skanerów i narzędzi innych firm, czy tylko wyników uzyskanych od dostawcy?
To ostatnie pytanie ma większe znaczenie, niż się wydaje. Wiele narzędzi do priorytetyzacji luk w zabezpieczeniach nadaje priorytet tylko temu, co same wykryły, pozostawiając wszystko, co zostało pobrane z… SAST, SCAlub skanery innych firm umieszczone w oddzielnym, nieuporządkowanym stosie.
Jak Xygeni podchodzi do priorytetyzacji luk w zabezpieczeniach
Xygeni'ego ASPM Stosuje czteroetapowy lejek: pobieranie ustaleń z natywnych skanerów i narzędzi innych firm, budowanie ujednoliconej widoczności w całym powstałym inwentarzu, a następnie korelowanie i priorytetyzacja z wykorzystaniem deduplikacji, dostępności i kontekstu opartego na sztucznej inteligencji, zanim ustalenia dotrą do kolejki programisty. W praktyce lejek zawęża pełną listę ustaleń, określając, co można naprawić, co jest dostępne w kodzie aplikacji, co ma znany exploit, a na końcu, co jest rzeczywiście podatne na exploit w danym środowisku. Dzięki temu lista, z którą faktycznie pracuje zespół, jest na tyle krótka, że można ją w pełni wykorzystać, a nie tylko segregować w nieskończoność.
Ponieważ ta warstwa priorytetyzacji luk w zabezpieczeniach dotyczy ustaleń pozyskanych ze skanerów innych firm, a także Własne natywne skanery Xygeni, drużyna nie musi wyrywać istniejące narzędzie aby uzyskać ujednolicony, skorelowany widok. Logika priorytetyzacji działa na podstawie tego, co już istnieje, wypełniając lukę, którą większość narzędzi do priorytetyzacji luk pozostawia otwartą, gdy klasyfikują tylko własne ustalenia.
FAQ
Dlaczego sam system CVSS nie wystarcza do priorytetyzacji luk w zabezpieczeniach?
CVSS mierzy teoretyczną wagę, a nie rzeczywiste ryzyko w konkretnym środowisku. Nie uwzględnia on tego, czy podatny kod jest osiągalny, czy exploit istnieje w sieci, ani jak bardzo narażony jest system, który go atakuje – wszystkie te czynniki istotnie wpływają na decyzję o tym, czy dany błąd wymaga naprawy w pierwszej kolejności.
Jaka jest różnica między powagą a podatnością na wykorzystanie w priorytetyzacji luk w zabezpieczeniach?
Poważność opisuje, jak szkodliwa może być teoretycznie luka w zabezpieczeniach. Podatność na wykorzystanie opisuje, czy szkoda jest rzeczywiście możliwa do osiągnięcia w danej chwili, biorąc pod uwagę działający exploit i dostępną ścieżkę kodu. Odkrycie o wysokiej powadze i niskiej podatności na wykorzystanie jest często mniej pilne niż odkrycie o umiarkowanej powadze i wysokiej podatności na wykorzystanie.
Czy narzędzia do priorytetyzacji luk w zabezpieczeniach muszą uwzględniać również wyniki skanowania przeprowadzanego przez inne firmy?
Tak, w przeciwnym razie zespół będzie miał kilka oddzielnych, nieskorelowanych list priorytetów, po jednej dla każdego narzędzia, zamiast jednego, ujednoliconego widoku tego, co jest naprawdę najważniejsze w całym stosie.
W jakim stopniu analiza dostępności może realistycznie skrócić listę ustaleń?
Różni się to w zależności od bazy kodu, ale często większość oznaczonych luk znajduje się w ścieżkach kodu, które nigdy nie są faktycznie wywoływane. Oznacza to, że sama dostępność często eliminuje znaczną część ustaleń z poważnego rozważenia jeszcze przed oceną możliwości wykorzystania luk.
Czy krótsza, priorytetowa lista jest oznaką ignorowania ryzyka?
Nie, wręcz przeciwnie. Krótsza lista wygenerowana w wyniku rzeczywistej priorytetyzacji luk w zabezpieczeniach oznacza, że odfiltrowano szum, a nie ryzyko. Alternatywa, długa, niefiltrowana lista, której nikt nie jest w stanie w pełni przeanalizować, przynosi gorsze rezultaty, ponieważ rzeczywiste ryzyko gubi się w objętości.
