Dostałeś KSC na biurko. 10 pytań, które zadasz działowi IT
Scena, którą łatwo sobie wyobrazić w niejednej firmie. Zarząd ustalił, że firma podlega pod ustawę o krajowym systemie cyberbezpieczeństwa, a temat trafił do osoby, która ma go "poukładać". Często jest to kierownik jakości, ktoś od compliance albo kierownik biura. Rzadko informatyk, bo informatyk ma swoją robotę.
Jeśli to Ty, ten tekst jest dla Ciebie. Nie musisz znać się na serwerach, żeby sprawdzić, czy jeden z ważniejszych obszarów, zarządzanie podatnościami, naprawdę działa. Wystarczy zadać dziesięć pytań i posłuchać odpowiedzi.
To pierwszy odcinek cyklu, w którym biorę jeden obowiązek z ustawy, pokazuję, gdzie w praktyce jest luka i jak ją zamknąć. Kolejne odcinki rozwijają pytania z tej listy.
Uwaga porządkowa: nie jestem prawnikiem i to nie jest porada prawna. Status Twojej firmy i zakres obowiązków potwierdź w tekście ustawy albo z prawnikiem.
Dlaczego to w ogóle Twoja sprawa
Dyrektywa NIS2, którą wdraża znowelizowana ustawa o KSC, w art. 20 mówi wprost, że organy zarządzające zatwierdzają środki zarządzania ryzykiem, nadzorują ich wdrażanie i mogą za to odpowiadać. Art. 21 wymienia te środki. Jednym z nich jest bezpieczeństwo przy nabywaniu, rozwoju i utrzymaniu systemów, w tym obsługa i ujawnianie podatności. Innym jest ocena, czy wdrożone środki są skuteczne.
Dla podmiotów, które spełniały kryteria w dniu wejścia nowelizacji w życie, czyli 3 kwietnia 2026, okres dostosowawczy kończy się 3 kwietnia 2027. Do tego dnia proces ma działać, a nie tylko istnieć w dokumentach. Okres dostosowawczy nie odracza obowiązków, które firma miała już wcześniej. Terminy dla podmiotów, które spełniły kryteria później, trzeba ustalić osobno.
Ustawa nie mówi, jakim narzędziem skanować ani jak często. Organizacja dobiera środki do ryzyka i musi umieć tę decyzję obronić. Dlatego pytania poniżej nie dotyczą narzędzia, tylko tego, czy proces zostawia ślad.
Zasada: nie pytaj "czy jest dobrze". Poproś, żeby pokazali
Na pytanie "czy mamy to ogarnięte" prawie każdy odpowie "tak". Na prośbę "pokaż mi" odpowiedź jest albo konkretna, albo jej nie ma. Każde z dziesięciu pytań poniżej kończy się czymś, co da się zobaczyć: listą, datą, nazwiskiem, plikiem.
1. Których serwerów dotyczy nasz raport o podatnościach, a których w nim nie ma?
Dobra odpowiedź to lista systemów i jasna informacja, czego raport nie obejmuje, na przykład stacji roboczych, urządzeń sieciowych albo systemów sterowania. Wymijająca to "wszystkiego". Żaden pojedynczy skaner nie widzi wszystkiego, a raport, który nie mówi, czego nie obejmuje, daje fałszywe poczucie bezpieczeństwa.
2. Kiedy był ostatni skan i jak często skanujemy?
Skan to automatyczne sprawdzenie, czy na serwerze jest oprogramowanie ze znanymi lukami. Poproś o trzy rzeczy: datę ostatniego skanu, zapisany harmonogram i nazwisko osoby, która go zatwierdziła. Wymijająca odpowiedź to "jak jest potrzeba". Częstotliwość może być różna dla różnych systemów, ale powinna wynikać z decyzji, a nie z tego, kiedy ktoś miał wolną chwilę.
3. Ile mamy podatności po terminie usunięcia i czy ta liczba rośnie, czy spada?
Ta odpowiedź mówi więcej niż sama liczba podatności. Firma może mieć setki otwartych pozycji i dobrze działający proces, jeśli mieści się w terminach. Może też mieć kilka pozycji i proces, który stoi. Poproś o liczbę pozycji po terminie na koniec każdego z ostatnich trzech miesięcy. Wymijająca odpowiedź to jedna liczba bez punktu odniesienia.
4. Jakie terminy usunięcia obowiązują i gdzie są zapisane?
Dobra odpowiedź wskazuje dokument i konkretne liczby, na przykład: krytyczne w 14 dni, wysokie w 30, pozostałe w 90, zapisane w polityce zatwierdzonej przez zarząd. To tylko przykład, liczby dobiera się do ryzyka. Wymijająca to "jak najszybciej". Jeśli terminy istnieją tylko w głowie administratora, nie da się sprawdzić, czy są dotrzymywane.
5. Od czego zaczynacie w tym tygodniu i kto to robi?
Raport ze skanera potrafi mieć kilkaset albo kilka tysięcy pozycji. Poproś o trzy pierwsze zadania na ten tydzień, z osobą odpowiedzialną i terminem przy każdym. Wymijająca odpowiedź to "pracujemy nad tym".
6. Czego świadomie nie naprawiamy, kto to zatwierdził i kiedy wrócimy do tematu?
Nie każdą lukę da się usunąć od razu. Czasem aktualizacja wymaga zatrzymania usługi, czasem dostawca aplikacji nie wspiera nowszej wersji. Odroczenie naprawy wymaga jednak oceny ryzyka i działań, które je ograniczają do czasu aktualizacji. Sam zapis decyzji nie wystarcza, ale bez niego nie da się pokazać, że ocena w ogóle była. Dobra odpowiedź wskazuje uzasadnienie, właściciela ryzyka, zastosowane zabezpieczenia i datę przeglądu. Podejrzana jest odpowiedź "naprawiamy wszystko", bo w realnej firmie prawie nigdy nie jest prawdziwa.
7. Które systemy działają bez wsparcia producenta i jaki jest plan?
Serwer, który działa, ale nie dostaje już poprawek bezpieczeństwa, to typowa luka, o której wszyscy wiedzą i nikt nie decyduje. Dobra odpowiedź wskazuje, kto prowadzi migrację, na kiedy i co robimy do tego czasu. Wymijająca to "kiedyś to przeniesiemy".
8. Jeśli serwery utrzymuje firma zewnętrzna: co od niej dostajemy i jak często?
Zadania można zlecić, odpowiedzialności nie. Poproś o ostatni raport od tej firmy, termin następnego i nazwisko osoby po Waszej stronie, która go czyta. Dobrze, jeśli umowa mówi, co ma się w takim raporcie znaleźć. Wymijająca to "mamy firmę, która się tym zajmuje".
9. Pokaż mi jedną decyzję o podatności z poprzedniego kwartału i wszystko, co z niej zostało.
Na przykład jedną poważną lukę: kiedy ją wykryto, kto się nią zajął, kiedy zniknęła. Zmierz, ile czasu zajmie znalezienie tych informacji. Jeśli kilka minut, ślad powstaje przy pracy. Jeśli trzeba go składać z maili, arkuszy i pamięci ludzi, to sygnał, że przed audytem czeka Was ręczne odtwarzanie, a ono rzadko wychodzi kompletne.
10. Gdyby dziś doszło do poważnego incydentu, kto decyduje o zgłoszeniu i gdzie zapisujemy fakty?
Dyrektywa wymaga, żeby poważne incydenty zgłaszać bez zbędnej zwłoki: wczesne ostrzeżenie najpóźniej w 24 godziny, a zgłoszenie incydentu zasadniczo w 72 godziny od powzięcia o nim wiedzy. Dla dostawców usług zaufania termin zgłoszenia jest krótszy. W takim czasie nie ma miejsca na ustalanie, kto ma podjąć decyzję. Dobra odpowiedź to nazwisko i jedno miejsce, w którym zbierane są fakty. Wymijająca to "zadzwonimy do informatyka".
Jak czytać odpowiedzi
Nie oceniaj technicznej treści, oceniaj konkret. Dobra odpowiedź ma datę, liczbę, nazwisko albo plik. Zła ma "na bieżąco", "w zasadzie", "jak będzie trzeba".
Jeśli większość odpowiedzi jest wymijająca, to nie jest powód do paniki ani do szukania winnych. Zwykle znaczy to, że administrator robi swoją pracę, ale nikt nie dał mu czasu ani narzędzi, żeby ta praca zostawiała ślad. To da się naprawić, a do kwietnia 2027 jest na to czas, choć mniej, niż się wydaje. Historia działań potrzebuje miesięcy, żeby powstać, nie da się jej dopisać tydzień przed audytem.
Gdzie pomaga Secvalis, a gdzie nie
Secvalis zbiera wyniki skanów podatności z serwerów Linux i obrazów uruchomionych na nich kontenerów, pilnuje terminów usunięcia luk i zapisuje decyzje. Z dziesięciu pytań powyżej wprost odpowiada na kilka: raport zarządczy pokazuje terminowość napraw, lista zadań grupuje podatności według pakietu, czyli składnika oprogramowania, który trzeba zaktualizować, akceptacja ryzyka wymaga uzasadnienia, właściciela, opisu zabezpieczeń i daty przeglądu, dla systemów po końcu wsparcia sprawdza właściciela migracji i datę docelową, a Evidence Pack składa raporty, rejestr decyzji o ryzyku i dziennik audytowy z tego obszaru w jedno archiwum.
Nie skanuje stacji roboczych z Windows, urządzeń sieciowych ani systemów sterowania przemysłowego. Nie zastępuje polityki bezpieczeństwa, analizy ryzyka całej organizacji, kopii zapasowych ani szkoleń. Nie zgłasza incydentów za Ciebie. Odpowiedzi na pytania 1, 8 i 10 w dużej części leżą poza każdym narzędziem do podatności.
W kolejnych odcinkach biorę te pytania po kolei: od tego, jak zarząd ma ocenić, czy IT nadąża, przez pracę z zewnętrznym informatykiem i planowanie napraw, po decyzje o ryzyku i dowody dla audytora.
Jeśli chcesz zobaczyć, jak wyglądają odpowiedzi na te pytania w działającym systemie, zajrzyj do publicznego demo. To dane fikcyjnej firmy, bez rejestracji.
Źródła
Cotygodniowy digest CVE
Jeden mail w tygodniu z nowo opublikowanymi podatnościami, o których warto wiedzieć. Bez zakładania konta.
Digest dotyczy ogólnie nowych podatności, nie Twoich serwerów. Jeśli chcesz wiedzieć, które z nich faktycznie działają w Twojej infrastrukturze, tym zajmuje się Secvalis : skanuje Twoje maszyny i zgłasza wyłącznie to, co ich dotyczy.