Rejestr aktywów i podatności w JST powinien odpowiadać na jedno pytanie: co trzeba zabezpieczyć najpierw i kto o tym decyduje. Sama lista sprzętu nie wystarcza, jeżeli nie ma przy niej właściciela, krytyczności usługi i terminu reakcji na wykrytą podatność.
Model pracy etapami zobaczysz na stronie O systemie. Jeżeli chcesz od razu zobaczyć rozwiązania wdrożeniowe, przejdź do modułu Minimalny standard stacji i serwera oraz Podstawy KRI.
Czym jest dobry rejestr aktywów w JST
Dobry rejestr nie zaczyna się od pola „numer seryjny”. Zaczyna się od relacji między zasobem a usługą publiczną. Trzeba wiedzieć, czy dany serwer, stacja, aplikacja albo usługa chmurowa wspiera proces krytyczny, kto jest właścicielem usługi i jak długo JST może zaakceptować niedostępność.
- Nazwa systemu lub zasobu.
- Właściciel usługi i właściciel techniczny.
- Rola w usłudze publicznej.
- Krytyczność i zależności.
- Status wsparcia producenta, w tym EOL/EOS.
Jak połączyć aktywa z podatnościami
Podatność bez kontekstu usługi publicznej niczego nie porządkuje. W praktyce trzeba połączyć wynik skanu z odpowiedzią na trzy pytania: czy zasób jest krytyczny, czy jest wystawiony na zewnątrz i czy istnieje kontrola kompensacyjna. Dopiero wtedy da się uczciwie ustawić kolejność łatania.
- Najpierw luki wysokie na zasobach krytycznych lub publicznie dostępnych.
- Następnie luki średnie, ale na systemach wspierających kluczowe procesy.
- Na końcu problemy niskie i kosmetyczne, o ile nie dotykają zasobów o wysokim znaczeniu.
Jeżeli nie masz jeszcze wspólnego standardu konfiguracji, priorytetyzacja szybko zamienia się w improwizację. Dlatego ten temat naturalnie spina się z modułem Minimalny standard stacji i serwera.
Co zrobić z EOL i EOS
Największy błąd to traktowanie systemów bez wsparcia jako „tematu na później”. W rejestrze powinien pojawić się osobny status dla EOL/EOS oraz jedna z decyzji: wymiana, izolacja, akceptacja ryzyka lub kontrola kompensacyjna. Brak takiej decyzji oznacza, że ryzyko jest realnie niezarządzane.
Jeśli temat dotyczy też dostępów dostawców i odpowiedzialności za zmiany, przejdź do modułu Konta uprzywilejowane i techniczne oraz Dostawcy i łańcuch dostaw IT.
Minimalny proces podatności w JST
Proces nie musi być rozbudowany, ale musi być rozliczalny. Najprostszy działający model to: wykrycie → priorytet → decyzja → termin naprawy → potwierdzenie wykonania. Każdy krok powinien mieć właściciela i datę. Bez tego rejestr jest tylko zrzutem technicznym, a nie narzędziem zarządczym.
W praktyce dobrze jest połączyć ten proces z dowodami oczekiwanymi przy kontroli. Tu pomocny będzie artykuł Audyt KRI w JST: 5 lekcji z przeglądu technicznego.
Checklista 30 minut
- Czy każdy system krytyczny ma właściciela usługi?
- Czy wiadomo, które zasoby są EOL lub EOS?
- Czy istnieje reguła czasu reakcji dla podatności wysokich?
- Czy ktoś zatwierdza priorytety i akceptację ryzyka?
- Czy rejestr ma datę ostatniej aktualizacji?
FAQ: rejestr aktywów i podatności
Od czego zacząć, jeśli lista sprzętu jest niepełna?
Zacznij od systemów i usług krytycznych, a nie od całego inwentarza. Lepiej mieć kompletny obraz 20 najważniejszych zasobów niż pozornie pełną, ale nieużyteczną tabelę wszystkiego.
Czy warto łączyć aktywa, podatności i aktualizacje w jednym procesie?
Tak, bo tylko wtedy kierownictwo widzi zależność między stanem technicznym a ryzykiem dla usług. Rejestr aktywów bez procesu naprawy nie daje podstaw do decyzji.
Jaki artykuł przeczytać dalej?
Jeśli chcesz uporządkować nadzór na poziomie całej organizacji, przejdź do tekstu SZBI w JST bez certyfikacji. Jeśli priorytetem jest mapa działań startowych, zobacz jak ustawić priorytety cyberbezpieczeństwa w samorządzie.
Powiązane moduły
Najbardziej logiczny zestaw startowy dla tego obszaru to Minimalny standard stacji i serwera, Podstawy KRI oraz System zarządzania bezpieczeństwem informacji.