Nie wszystko da się załatać od razu. Jak podjąć decyzję, którą obronisz

Przedsiębiorstwo wodociągowe w średnim mieście. Na serwerze Linux działa system rozliczeń z odbiorcami, dostarczony przez zewnętrzną firmę. Skan pokazuje podatność o wysokiej wadze w bibliotece, z której ten system korzysta. Poprawka jest dostępna od tygodnia. Dostawca systemu odpisuje, że nowej wersji biblioteki jeszcze nie przetestował i nie gwarantuje, że rozliczenia po aktualizacji będą działać. Certyfikację obiecuje za sześć tygodni.

Administrator dzwoni do kierownika działu obsługi klienta. Ustalają, że poczekają. Rozmowa trwa trzy minuty, nikt jej nie zapisuje. Po sześciu tygodniach dostawca prosi o kolejne cztery, a za rok audytor pyta, dlaczego podatność z dostępną poprawką była otwarta przez dziesięć miesięcy.

Decyzja o czekaniu mogła być rozsądna. Problem w tym, że nie da się już tego wykazać.

Co mówi przepis

Ustawa o krajowym systemie cyberbezpieczeństwa w brzmieniu po nowelizacji z 2026 roku wymaga od podmiotów kluczowych i ważnych systemu zarządzania bezpieczeństwem informacji. Trzy jego elementy dotyczą tej sytuacji wprost.

Art. 8 ust. 1 pkt 1 mówi o systematycznym szacowaniu ryzyka i zarządzaniu nim. Art. 8 ust. 1 pkt 5 lit. b wymaga regularnych aktualizacji oprogramowania stosownie do zaleceń producenta, ale z uwzględnieniem analizy wpływu aktualizacji na bezpieczeństwo świadczonej usługi i poziomu krytyczności poszczególnych aktualizacji. Art. 8 ust. 1 pkt 5 lit. d wymaga niezwłocznego działania po dostrzeżeniu podatności, w tym, jeśli trzeba, czasowego ograniczenia ruchu przychodzącego.

Czytam to tak: przepis nie każe instalować każdej poprawki w chwili, gdy się ukaże. Przewiduje, że czasem trzeba ocenić, czy aktualizacja nie zaszkodzi usłudze. Nie pozwala jednak na to, żeby po dostrzeżeniu podatności nic się nie działo. Jeśli aktualizacja musi poczekać, w tym czasie powinno zadziałać coś innego, a ktoś powinien za to odpowiadać. Dyrektywa NIS2 dodaje w art. 20, że organy zarządzające zatwierdzają środki zarządzania ryzykiem i nadzorują ich wdrażanie. Nie znaczy to, że zarząd podpisuje każdą decyzję operacyjną, ale powinien wiedzieć, kto w firmie jest do takich decyzji upoważniony. (Dla części podmiotów publicznych i sektora finansowego ustawa przewiduje odrębne zasady; opisuję ogólny reżim art. 8 ust. 1.)

Gdzie jest luka

W większości firm decyzja o odroczeniu aktualizacji zapada tak jak w wodociągach: telefon, wiadomość na komunikatorze, "dobra, czekamy". Brakuje jej czterech rzeczy, bez których za kilka miesięcy przestaje być decyzją.

Nie ma powodu na piśmie. Za pół roku nikt nie pamięta, czy chodziło o certyfikację dostawcy, brak okna serwisowego, czy po prostu o to, że był piątek.

Nie ma nikogo, kto bierze ryzyko na siebie. Administrator nie powinien sam decydować, że system rozliczeń przez dwa miesiące działa z podatnością. To ryzyko dla działania firmy, więc powinna je przyjąć osoba, która za ten obszar odpowiada.

Nie ma daty powrotu. "Poczekamy, aż dostawca da znać" zamienia się w "czekamy od dziesięciu miesięcy", bo nikt nie ma w kalendarzu dnia, w którym trzeba zapytać ponownie.

Nie ma zabezpieczenia na czas oczekiwania. Skoro aktualizację odroczono, co ogranicza szansę wykorzystania podatności? Jeśli odpowiedź brzmi "nic", to też jest odpowiedź, ale wtedy ktoś powinien ją świadomie zaakceptować.

Jak to zamknąć

Poniższe działa w arkuszu, w systemie zgłoszeń albo na papierze. Ważne, żeby każda decyzja miała te same pola i żeby trafiała w jedno miejsce.

1. Zapisz, czego dotyczy decyzja. Która podatność, w którym pakiecie, na którym serwerze. Nie "biblioteka od rozliczeń", tylko konkretna pozycja, którą da się później porównać ze skanem.

2. Zapisz powód, dla którego aktualizacja musi poczekać. Jednym, konkretnym zdaniem: "dostawca systemu rozliczeń nie certyfikował wersji X, termin certyfikacji podany na piśmie: 14 grudnia". Powód "brak czasu" też jest powodem, ale wtedy problem leży gdzie indziej i pisałem o nim w poprzednim odcinku.

3. Zapisz, co robicie w zamian. Ograniczenie dostępu do serwera tylko z sieci wewnętrznej, wyłączenie podatnej funkcji, dodatkowe monitorowanie, przeniesienie usługi za dodatkową warstwę ochrony. Jeśli nic się nie da zrobić, zapisz to jawnie: "brak zabezpieczeń zastępczych, ryzyko przyjęte jak jest". To uczciwsze niż puste pole, ale taki wpis nie zamyka sprawy: ktoś musi ocenić, czy dalsza praca systemu bez zabezpieczeń jest w ogóle dopuszczalna, a data przeglądu powinna być wtedy możliwie krótka.

4. Wskaż właściciela ryzyka. Osobę, która rozumie, co się stanie, jeśli podatność zostanie wykorzystana, i ma prawo zdecydować, że firma to ryzyko przyjmuje. W wodociągach to kierownik obszaru rozliczeń albo członek zarządu, nie administrator.

5. Ustal datę przeglądu. Krótką. Termin podany przez dostawcę plus kilka dni, a nie "koniec roku". Dla podatności, o których wiadomo, że są wykorzystywane w atakach, krócej. W dniu przeglądu ktoś sprawdza, czy powód nadal istnieje, i decyduje od nowa.

6. Rozdziel wniosek od zatwierdzenia. Administrator najlepiej zna technikę, więc niech przygotuje wniosek. Zatwierdzić powinien ktoś inny, z odpowiednimi uprawnieniami. Dwie osoby to nie biurokracja, tylko pewność, że decyzja nie jest wygodnym skrótem jednej z nich.

7. Po terminie podatność wraca do normalnego trybu. Jeśli nikt nie przedłużył decyzji, pozycja znów jest zwykłą zaległością, liczoną od dnia wykrycia, a nie od dnia wygaśnięcia decyzji. Inaczej każda decyzja staje się sposobem na wyzerowanie licznika.

Taka decyzja to nie to samo co stwierdzenie, że podatność firmy nie dotyczy, bo podatny element nie jest używany. To osobny przypadek i osobny odcinek.

Gdzie pomaga Secvalis, a gdzie nie

Akceptacja ryzyka w Secvalis wymaga uzasadnienia, właściciela ryzyka, daty przeglądu i informacji o kontrolach kompensacyjnych. Rola techniczna może złożyć wniosek, który zatwierdza właściciel lub administrator konta; oni mogą też zaakceptować ryzyko bezpośrednio.

Ważna akceptacja wyłącza otwartą pozycję z bieżącego pomiaru terminowości, ale w raporcie za okres nie usuwa przekroczenia terminu, które nastąpiło przed decyzją. Po dacie przeglądu traci ważność, a pozycja wraca do pomiaru z terminem liczonym od wykrycia. Datę przeglądu ogranicza limit konta, domyślnie 365 dni od decyzji. Jeśli codzienne podsumowanie jest włączone, wskazuje akceptacje wygasłe i te, które wkrótce wygasną, a raport ISO osobno oznacza zaakceptowane podatności z katalogu KEV albo krytyczne. Taka akceptacja ustawia werdykt raportu zarządczego na "Stan krytyczny": odroczenie aktualizacji może być uzasadnione, ale przy podatności wykorzystywanej w atakach albo krytycznej zarząd powinien je widzieć, a nie dowiadywać się o nim przy audycie. Dziennik audytowy zapisuje decyzje, w tym akceptacje ryzyka, i można go wyeksportować do CSV. Rejestr akceptacji ryzyka jest też częścią Evidence Packa.

Secvalis nie oceni za Ciebie, czy ryzyko jest dopuszczalne. Nie sprawdzi, czy zabezpieczenie opisane w polu "kontrole kompensacyjne" naprawdę działa, i nie wdroży go. Nie negocjuje z dostawcą terminu certyfikacji. Narzędzie pilnuje, żeby decyzja miała wszystkie pola, żeby była zatwierdzona przez właściwą osobę i żeby po dacie przeglądu przestała obowiązywać, zamiast trwać bez końca. Treść decyzji i odpowiedzialność za nią zostają u ludzi, a uprawnienia w narzędziu nie zastępują ustalenia w firmie, kto może takie decyzje podejmować.

Jak wygląda rejestr akceptacji ryzyka w paczce dowodów, zobaczysz w przykładowym Evidence Packu, a okno decyzji przy podatności w publicznym demo, bez rejestracji.

W następnym odcinku: audytor przyjdzie. Co mu położysz na stole z obszaru podatności i dlaczego plan to jeszcze nie dowód.

Źródła

• ELI: ustawa o zmianie ustawy o krajowym systemie cyberbezpieczeństwa, Dz.U. 2026 poz. 252, art. 8 ust. 1
• EUR-Lex: dyrektywa NIS2 (UE) 2022/2555, art. 20 i art. 21
• KSC wymaga aktualizacji oprogramowania, ale nie ślepego patchowania
• System po EOL to nie dług techniczny. To wpis w rejestrze ryzyka