Skan to zdjęcie. Administrator potrzebuje historii podatności
Ostatni skan odpowiada na proste pytanie: co skaner widzi teraz. To ważna informacja, ale dla administratora często niewystarczająca.
Wyobraź sobie, że po aktualizacji podatność znika z raportu. Tydzień później wraca. Czy poprawka została cofnięta? Czy na serwer trafiła starsza wersja pakietu? Czy pojawił się nowy kontener? A może wcześniejszy skan nie obejmował tego źródła? Sam bieżący raport nie odpowie. Pokazuje stan, ale usuwa drogę, która do niego doprowadziła.
Dlatego skan traktuję jak zdjęcie. W utrzymaniu potrzebny jest film.
Co ginie, gdy zachowujesz tylko ostatni wynik
Najprostszy proces nadpisuje poprzedni plik JSON albo trzyma wyłącznie aktualną tabelę. Lista jest świeża i pozornie uporządkowana, ale znika kilka ważnych informacji:
- kiedy podatność pojawiła się po raz pierwszy,
- w których kolejnych skanach nadal występowała,
- kiedy przestała być wykrywana,
- czy po naprawie pojawiła się ponownie,
- jaki status i decyzję nadał jej zespół,
- czy termin naprawy został dotrzymany.
Bez historii nie odróżnisz świeżego problemu od podatności wiszącej od trzech miesięcy. Nie zobaczysz też regresji, czyli sytuacji, w której wcześniej naprawiony problem wraca.
Historia zmienia sposób ustalania priorytetów
Dwie podatności mogą mieć ten sam CVSS i dotyczyć równie ważnych maszyn. Jedna pojawiła się dziś, druga jest otwarta od sześćdziesięciu dni i przekroczyła wewnętrzny termin. Bieżący skan pokazuje dwa podobne wiersze. Historia pokazuje dwa różne problemy operacyjne.
W Secvalis cykl znaleziska ma datę pierwszego i ostatniego wykrycia oraz datę rozwiązania. Jeżeli to samo CVE dla tego samego pakietu wróci po zamknięciu, zaczyna nowy cykl. Dzięki temu stara akceptacja ryzyka nie przechodzi automatycznie na nową sytuację, a ponowne pojawienie się podatności nie udaje ciągłości poprzedniego wpisu.
To drobny szczegół modelu danych, ale duża różnica dla administratora. Sytuacja "naprawione w maju, ponownie wykryte w lipcu" wymaga innej reakcji niż "otwarte nieprzerwanie od maja".
Status bez historii jest tylko etykietą
NEW, IN_PROGRESS, ACCEPTED_RISK i FIXED są przydatne dopiero wtedy, gdy wiadomo, kto i kiedy podjął decyzję. W przeciwnym razie status FIXED może oznaczać zarówno zweryfikowaną aktualizację, jak i kliknięcie wykonane pół roku temu przez osobę, której nie ma już w zespole.
Dobra historia powinna łączyć wynik techniczny z decyzją:
- kto rozpoczął obsługę,
- jaki był komentarz lub odnośnik do zmiany,
- kto zaakceptował ryzyko,
- kiedy akceptacja wygasa i wymaga ponownego przeglądu,
- czy późniejszy skan potwierdził zniknięcie znaleziska.
Secvalis nie wdraża poprawki. Zachowuje natomiast kontekst, w którym administrator zdecydował, co zrobić, i pozwala sprawdzić tę decyzję przy kolejnych skanach.
Trend jest ważniejszy niż pojedyncza liczba
"Mamy 312 podatności" niewiele mówi bez punktu odniesienia. Czy miesiąc temu było ich 500? Czy 120? Czy liczba critical spada, ale rośnie liczba hostów, które dawno nie wysłały skanu?
Historia skanów pozwala zobaczyć zmianę liczby CVE między kolejnymi punktami w czasie. Nadal trzeba uważać na interpretację. Spadek nie zawsze oznacza naprawę: maszyna mogła przestać raportować, zmienił się zakres skanu albo usunięto ją z projektu. Dlatego trend trzeba czytać razem ze świeżością skanów i stanem floty.
To również powód, dla którego sam dashboard nie powinien zastępować pracy administratora. Wykres pomaga zadać właściwe pytanie. Nie odpowiada automatycznie, dlaczego liczba się zmieniła.
To nie jest funkcja wyłącznie dla audytora
Historia jest często sprzedawana jako "dowód zgodności". Faktycznie pomaga wykazać, co znaleziono, kiedy podjęto działanie i czy termin został dotrzymany. Ale jej pierwszym użytkownikiem powinien być zespół utrzymaniowy.
Administrator korzysta z niej, gdy:
- podatność wraca po aktualizacji,
- trzeba sprawdzić, od kiedy problem istnieje,
- zmiana przeszła między zespołami lub dyżurami,
- właściciel systemu pyta, dlaczego zadanie jest pilne,
- trzeba odróżnić brak podatności od braku świeżego skanu,
- ktoś wraca do decyzji sprzed kilku miesięcy.
Audyt wykorzystuje ślad pozostawiony przez normalną pracę. Nie powinien wymuszać rekonstrukcji tej pracy tydzień przed spotkaniem.
Kiedy wystarczy prostsze rozwiązanie
Jeśli utrzymujesz dwie maszyny, regularnie przeglądasz wyniki i jesteś jedyną osobą podejmującą decyzje, katalog plików z datami albo mały skrypt porównujący skany może być wystarczający. Nie ma sensu wdrażać platformy tylko po to, żeby narysować wykres.
Centralna historia zaczyna realnie zarabiać na siebie, gdy rośnie liczba maszyn, wyniki przegląda kilka osób, obowiązują terminy albo decyzje muszą przetrwać zmianę administratora. Granicą nie jest ustawa. Granicą jest moment, w którym pamięć jednej osoby przestaje być wiarygodnym systemem ewidencji.
Jeśli chcesz zobaczyć historię skanów i statusy na fikcyjnych danych, otwórz publiczne demo Secvalis.
To jest część 3 serii o CVE w codziennej pracy administratora. Część 1 pokazuje, jak czytać kartę CVE, a część 2 opisuje sprawdzanie wpływu na flotę.