Excel jako rejestr podatności: dlaczego to działa, dopóki nie przestanie

Prawie każda firma, która zaczyna świadomie zarządzać podatnościami, zaczyna od arkusza. To nie jest błąd. To naturalny pierwszy krok i przez jakiś czas naprawdę działa. Kolumny na CVE, serwer, wagę, status i termin, kilka wierszy, jeden admin, który wie, co gdzie stoi. Nie potrzeba do tego żadnego narzędzia i namawianie kogoś takiego na platformę byłoby sprzedażą rozwiązania do nieistniejącego problemu.

Sam prowadziłem podatności w arkuszu i nie mam z tym nic wspólnego wstydliwego. Warto tylko wiedzieć, gdzie ten model pęka, bo pęka cicho, bez komunikatu o błędzie, i najczęściej odkrywa się to w najgorszym możliwym momencie: na audycie.

Gdzie arkusz działa dobrze

Bądźmy uczciwi, bo bez tego reszta brzmi jak reklama. Arkusz jest wystarczający, gdy:

• masz kilka maszyn i jedną osobę, która faktycznie czyta wyniki skanów,
• nikt Cię nie audytuje i nie musisz nikomu raportować za okres wstecz,
• historia napraw nie interesuje nikogo poza Tobą,
• liczba otwartych podatności jest na tyle mała, że mieści się w głowie.

W takim układzie arkusz wygrywa z każdą platformą, bo ma zerowy koszt wdrożenia i zerową krzywą uczenia. Jeśli to Twój przypadek, przestań czytać i wróć do pracy, niczego Ci nie brakuje.

Pierwsze pęknięcie: aktualność zależy od zasilania

Skan podatności to obraz z konkretnej chwili. Bazy CVE aktualizują się codziennie, pakiety dostają poprawki, pojawiają się nowe podatności w rzeczach, które wczoraj były czyste. Arkusz nie wie o niczym z tego. Jest tak aktualny, jak ostatni raz, gdy ktoś ręcznie przepisał do niego wyniki.

W praktyce arkusz zaczyna się dezaktualizować po kolejnej zmianie w środowisku albo publikacji nowych danych o podatnościach, jeśli nie ma automatycznego zasilania. Sam plik nie sygnalizuje, czy dane są sprzed godziny, czy sprzed miesiąca. Warto przy tym zaznaczyć, że Microsoft 365 zapewnia współtworzenie, historię wersji i śledzenie zmian. Problemem nie jest więc format arkusza sam w sobie, tylko ręczny proces bez jednego źródła prawdy i automatycznego importu.

Drugie pęknięcie: brak historii

Typowy ręczny rejestr pokazuje stan, ale nie ma strukturalnego dziennika przebiegu każdej podatności. Historia wersji pliku może pomóc odtworzyć zmianę, lecz nie zastępuje łatwego zapytania: kto, kiedy i dlaczego zamknął konkretną pozycję. Bez osobnej ewidencji odpowiedź wymaga ręcznego porównywania wersji.

A to jest dokładnie pytanie, które może paść na audycie. Audytor może chcieć zobaczyć, że podatność wykryta trzy miesiące temu została obsłużona w terminie, wraz z datowanym dowodem. Arkusz prowadzony wyłącznie jako stan bieżący nie daje tej odpowiedzi bez dodatkowej ewidencji.

Trzecie pęknięcie: rozjazd wersji

Arkusz kopiuje się sam. Jedna wersja na dysku sieciowym, druga w mailu do szefa, trzecia lokalnie u kogoś, kto "chciał tylko sprawdzić". Po miesiącu nikt nie wie, która jest prawdziwa. Ktoś nanosi zmianę na kopię, która nigdy nie wróci do głównego pliku, i wpis o naprawie ginie.

To nie jest nieunikniona wada Excela: współtworzenie w Microsoft 365 ogranicza ten problem. Rozjazd pojawia się wtedy, gdy organizacja nadal wysyła kopie pliku i nie ustali jednego źródła prawdy.

Czwarte pęknięcie: nic nie jest wymuszone

W arkuszu wszystko jest opcjonalne. Kolumna "właściciel" bywa pusta, bo nikt nie musiał jej wypełnić. Kolumna "termin" istnieje, ale nic nie pilnuje, żeby minięty termin rzucał się w oczy. Wpis o akceptacji ryzyka to komórka z tekstem, bez podpisu, bez daty wygaśnięcia, bez informacji, kto miał prawo taką decyzję podjąć.

Rejestr, w którym pola kluczowe dla procesu są opcjonalne, w praktyce staje się listą życzeń. Wygląda jak proces, ale niczego nie egzekwuje.

Piąte pęknięcie: ręczne przepisywanie

Wyniki skanera są w JSON. Rejestr jest w arkuszu. Między nimi siedzi człowiek, który przepisuje. Przy dwudziestu maszynach i kilkuset znaleziskach dziennie to godziny pracy, w których wkradają się błędy: literówka w numerze CVE, pominięty wiersz, zła wersja pakietu. Im nudniejsza czynność, tym więcej pomyłek, a trudno o coś nudniejszego niż ręczne przepisywanie skanów.

Jak wygląda przygotowanie dowodów na audyt

Wszystkie powyższe pęknięcia zbierają się w jednym momencie: gdy trzeba przygotować dowody za okres. W modelu arkuszowym oznacza to tygodnie zbierania screenshotów, wyciągania starych kopii z maili, rekonstruowania z pamięci, kiedy co zostało naprawione. Efekt jest tak wiarygodny, jak wiarygodne były źródła, czyli umiarkowanie.

Czego wymaga minimalny prawdziwy rejestr

Nie chodzi o to, żeby arkusz zastąpić czymś skomplikowanym. Chodzi o pięć rzeczy, których arkusz z natury nie daje:

• automatyczne zasilanie prosto ze skanera, bez ręcznego przepisywania,
• historię zmian, w której nic nie znika, tylko dopisuje się kolejne stany,
• wymuszonych właścicieli i terminy, gdzie minięty termin sam się zgłasza,
• ścieżkę akceptacji ryzyka z podpisem i datą wygaśnięcia,
• eksport dowodów za dowolny okres jednym ruchem, a nie tygodniem zbierania.

Zbudowałem Secvalis wokół tych pięciu rzeczy, bo to one odróżniają rejestr, który przejdzie audyt, od arkusza, który tylko wygląda jak rejestr. Jeśli chcesz zobaczyć, jak wygląda rejestr zasilany automatycznie ze skanera, z historią i terminami, wejdź do demo. Bez rejestracji, na fikcyjnych danych.

Arkusz nie jest zły. Jest dobrym początkiem, który przestaje wystarczać dokładnie w chwili, gdy ktoś z zewnątrz zaczyna pytać o przeszłość. Warto wiedzieć wcześniej, że ten moment nadejdzie, niż odkryć to na tydzień przed audytem.

Źródła

• Microsoft: współtworzenie skoroszytów programu Excel
• Oficjalne FAQ do ustawy o KSC