Czy ta nowa podatność dotyczy któregoś z moich serwerów?
Kilka lat temu takie zadanie wyglądało u mnie bardzo zwyczajnie. Pojawiał się komunikat o nowej luce w OpenSSL, jądrze Linuksa albo popularnej bibliotece. Potem zaczynało się chodzenie po serwerach: gdzie ten pakiet jest zainstalowany, w jakiej wersji, czy usługa jest uruchomiona, czy host jest wystawiony do internetu i czy producent dystrybucji wydał już poprawkę.
Jedna podatność nie była problemem. Problem polegał na tym, że to zadanie wracało. Nowe CVE, kolejna lista maszyn, ponowne komendy, kolejne notatki i znowu pytanie, czy sprawdziłem wszystko. Przy kilku hostach da się to utrzymać w głowie. Przy kilkunastu lub kilkudziesięciu zaczynasz płacić czasem za brak jednego widoku.
Numer CVE nie jest jeszcze odpowiedzią
Publiczny katalog pozwala szybko ustalić, czym jest podatność, jaki ma CVSS, EPSS i status KEV. To pierwszy krok, ale administrator potrzebuje odpowiedzi osadzonej w swoim środowisku:
- na których maszynach występuje podatny pakiet,
- jaka wersja jest zainstalowana,
- czy znana jest wersja naprawiona,
- czy problem pochodzi z systemu operacyjnego czy obrazu kontenera,
- czy dany host jest krytyczny albo wystawiony publicznie,
- czy wynik jest nowy, obsługiwany, zaakceptowany czy naprawiony.
Bez tych informacji karta CVE jest wiedzą. Dopiero ich połączenie tworzy zadanie operacyjne.
Jak wygląda ręczne sprawdzanie
Rzetelna odpowiedź zwykle wymaga pięciu kroków.
1. Zrozum zakres podatności
Najpierw trzeba przeczytać opis NVD, komunikat producenta i advisory dystrybucji. Nazwa produktu z nagłówka często nie wystarcza. Luka może dotyczyć tylko konkretnego modułu, ustawienia lub sposobu użycia biblioteki.
2. Znajdź komponent we flocie
Potem trzeba sprawdzić pakiety, obrazy kontenerów i wersje na wszystkich hostach. Polecenie uruchomione na jednym serwerze odpowiada tylko za ten serwer. Skrypt uruchomiony przez SSH pomaga, ale jego wynik nadal trzeba zebrać, ujednolicić i zachować.
3. Uwzględnij poprawki dystrybucji
W ekosystemie Linuksa wersja upstream nie zawsze jest równa wersji bezpiecznej w dystrybucji. Debian, Ubuntu, Red Hat i inni dostawcy przenoszą poprawki do starszych wersji pakietów. Proste porównanie tekstowe numerów może uznać poprawiony pakiet za podatny albo odwrotnie. Dlatego wynik skanera jest punktem analizy, a nie poleceniem bezwarunkowej aktualizacji.
4. Dodaj kontekst maszyny
Ta sama luka ma inne znaczenie na publicznym reverse proxy i inne na wyłączonej maszynie laboratoryjnej. Ekspozycja, krytyczność usługi, dostęp atakującego i zabezpieczenia kompensacyjne wpływają na kolejność działania.
5. Zapisz decyzję
Jeżeli poprawka jest dostępna, zadanie powinno otrzymać właściciela i termin. Jeżeli poprawki nie ma, trzeba zapisać obejście albo świadomą akceptację ryzyka z datą ponownego przeglądu. "Sprawdzone" zapisane w prywatnej notatce administratora nie tworzy procesu dla zespołu.
Agregator nie zastępuje skanera ani administratora
Secvalis wykorzystuje wyniki Trivy i zbiera je w jednym miejscu. W widoku maszyny łączy CVE z pakietem, wersją zainstalowaną, wersją naprawioną i źródłem znaleziska. Dokłada tłumaczenie, KEV, EPSS, status, termin oraz historię decyzji. Dzięki temu można zacząć od pytania "których maszyn dotyczy ta podatność?", zamiast od logowania się kolejno na każdy host.
To nie oznacza automatycznej pewności, że luka jest możliwa do wykorzystania. Skaner dopasowuje dane o komponencie i wersji. Nie zna całego kontekstu uruchomieniowego aplikacji, wyjątków producenta ani każdego zabezpieczenia kompensacyjnego. Ostateczna ocena nadal należy do człowieka, który zna system.
Automatyzować warto zbieranie i porządkowanie danych. Decyzji technicznej nie warto udawać, że można pozbyć się jednym czerwonym badge'em.
Największy zysk to brak powtarzania tej samej pracy
Przy pojedynczym alarmie ręczne sprawdzenie może zająć kilkanaście minut. Koszt pojawia się w skali i częstotliwości: wiele CVE, wiele maszyn i ten sam proces wykonywany od początku za każdym razem.
Centralny widok nie sprawi, że podatności znikną. Sprawi natomiast, że administrator nie musi za każdym razem odtwarzać inwentaryzacji, szukać poprzedniej notatki i zastanawiać się, czy któryś host został pominięty. To korzyść niezależna od audytu. Audyt wykorzystuje tę samą historię później, ale zespół utrzymaniowy korzysta z niej codziennie.
Jeśli chcesz zobaczyć ten przepływ na przykładowej flocie bez podłączania własnych serwerów, otwórz publiczne demo Secvalis.
To jest część 2 serii o CVE w codziennej pracy administratora. Część 1 wyjaśnia, jak przeczytać kartę CVE w pięć minut, a część 3 pokazuje znaczenie historii skanów.