Najgorszy moment na ustalanie ról to pierwsze minuty incydentu.
Wpis do Wykazu KSC i dostęp do Systemu S46 porządkują formalny kanał kontaktu z krajowym systemem cyberbezpieczeństwa. Nie porządkują jednak automatycznie tego, co dzieje się wewnątrz urzędu: kto odbiera komunikaty, kto ocenia zdarzenie, kto podejmuje decyzję, kto kontaktuje się z dostawcą i kto dokumentuje dowody działania.
Ten artykuł nie jest poradą prawną. To praktyczna mapa pytań, które warto przejść w JST, zanim pojawi się presja czasu.
Wykaz KSC i S46 nie zastępują podziału odpowiedzialności
Według informacji Ministerstwa Cyfryzacji Wykaz KSC jest aplikacją związaną z Systemem S46, a jego celem jest m.in. uporządkowanie danych potrzebnych do współpracy z CSIRT i organami właściwymi ds. cyberbezpieczeństwa. Osobno wskazano też terminy związane z Wykazem KSC i korzystaniem z S46.
Dla JST to ważny sygnał organizacyjny. Po stronie jednostki nadal trzeba odpowiedzieć na prostsze, bardziej praktyczne pytania:
kto ma dostęp do właściwego kanału komunikacji;
kto ma zastępstwo;
kto rozpoznaje, czy zdarzenie może być incydentem;
kto podejmuje decyzję organizacyjną, jeśli trzeba ograniczyć działanie usługi;
kto informuje IOD, kierownictwo, dostawcę albo jednostkę podległą;
kto zapisuje decyzje, czasy, ustalenia i dowody działania.
NIK w kontroli cyberbezpieczeństwa JST zwracała uwagę nie tylko na techniczne zabezpieczenia, ale też na braki w ciągłości działania, dokumentacji, umowach z dostawcami i egzekwowaniu przyjętych rozwiązań. To są dokładnie te obszary, w których rozmyta odpowiedzialność szybko zmienia się w improwizację.
Minimalna mapa ról w JST
Nie chodzi o tworzenie rozbudowanej struktury. Chodzi o to, żeby w podstawowych sytuacjach nie było pustego miejsca przy decyzji.
Minimalna mapa ról powinna obejmować:
Kierownika jednostki albo osobę upoważnioną - odpowiada za decyzje organizacyjne, akceptację ryzyka i uruchomienie działań, które wpływają na pracę urzędu.
Osobę kontaktową dla Wykazu KSC / S46 - pilnuje kanału formalnego, danych kontaktowych, komunikatów i właściwej eskalacji.
Administratora IT albo osobę techniczną - analizuje zdarzenie, zabezpiecza systemy, sprawdza logi, kopie zapasowe i techniczne skutki incydentu.
Osobę odpowiedzialną za rejestry i dokumentację - dba o zapis decyzji, kartę zdarzenia, rejestr incydentów, ślady komunikacji i dowody działania.
IOD - ocenia, czy zdarzenie może dotyczyć danych osobowych i czy uruchamia obowiązki związane z ochroną danych.
Właściciela usługi lub procesu - wskazuje, jakie skutki organizacyjne ma przerwa w działaniu systemu, np. dla obsługi mieszkańców, finansów, edukacji lub pomocy społecznej.
Dostawcę zewnętrznego, CUW albo obsługę informatyczną- wspiera technicznie, ale działa w uzgodnionej ścieżce eskalacji i na podstawie jasnych ustaleń z JST.
Najważniejsza zasada: dostawca może wspierać technicznie, ale nie powinien być jedynym miejscem, w którym zapadają decyzje po stronie jednostki.
Co trzeba przypisać do ról
Sama lista stanowisk nie wystarczy. Do każdej roli trzeba przypisać działania, moment eskalacji i dowód wykonania.
W praktyce warto opisać co najmniej:
odbiór komunikatów i powiadomień;
wstępną kwalifikację zdarzenia;
uruchomienie wewnętrznej eskalacji;
kontakt z CSIRT, organem właściwym albo innym kanałem wskazanym dla jednostki;
decyzję o ograniczeniu, wyłączeniu albo przywróceniu usługi;
kontakt z dostawcą zewnętrznym;
ocenę skutków dla danych osobowych;
prowadzenie rejestru i przechowywanie dowodów działania;
informowanie kierownictwa i osób odpowiedzialnych za procesy.
To nie musi być długi dokument. Wystarczy, że w pierwszej wersji JST wie, kto jest odpowiedzialny, kto wspiera i gdzie zostaje ślad działania.
Gdzie system najczęściej pęka
Najczęstsze luki nie wynikają z braku dobrej woli. Zwykle wynikają z założenia, że „jakoś wiadomo, kto się tym zajmie”.
W praktyce warto uważać na pięć miejsc:
„Informatyk się tym zajmie” - IT wykonuje działania techniczne, ale nie zawsze może samodzielnie podjąć decyzję o ograniczeniu usługi publicznej.
Brak zastępstwa - jedna osoba kontaktowa bez zastępcy tworzy ryzyko urlopu, choroby, delegacji albo zwykłej niedostępności.
IOD włączony za późno - jeżeli zdarzenie dotyczy danych osobowych, ocena skutków nie powinna zaczynać się dopiero po zakończeniu działań technicznych.
Dostawca bez ścieżki eskalacji - umowa serwisowa nie zastępuje decyzji po stronie JST, a kontakt „do firmy” nie jest jeszcze procedurą.
Rejestry bez właściciela - jeżeli nikt nie odpowiada za zapis decyzji i dowodów, po kilku dniach trudno odtworzyć, kto co zrobił i dlaczego.
To są małe rzeczy organizacyjne, ale w incydencie decydują o tempie reakcji.
Mini-checklista: sprawdź urząd w 2 minuty
Przed publikacją procedur warto przejść krótką checklistę:
[ ] Czy wiadomo, kto odbiera komunikaty związane z Wykazem KSC / S46?
[ ] Czy ta osoba ma wskazane zastępstwo?
[ ] Czy kierownik jednostki wie, w których sytuacjach musi podjąć decyzję organizacyjną?
[ ] Czy IT wie, komu i w jakim trybie zgłasza podejrzenie incydentu?
[ ] Czy IOD jest włączany wtedy, gdy zdarzenie może dotyczyć danych osobowych?
[ ] Czy dostawcy mają wskazany kanał eskalacji i osobę po stronie JST?
[ ] Czy wiadomo, gdzie zapisywać decyzje, czasy, korespondencję i dowody działania?
[ ] Czy ktoś przegląda te ustalenia po zmianie osób, dostawców albo systemów?
Jeżeli na kilka pytań odpowiedź brzmi „nie wiem”, to nie jest powód do paniki. To dobry punkt startu do uporządkowania ról.
Co zrobić jako pierwszy krok
Najprostszy pierwszy krok to nie nowe narzędzie i nie duży projekt. Wystarczy jedno krótkie spotkanie robocze i jedna tabela:
Wypisać najważniejsze role.
Dopisać zastępstwa.
Przypisać najważniejsze decyzje.
Ustalić, gdzie zostaje ślad działania.
Sprawdzić, czy dostawcy i CUW pasują do tej ścieżki.
Role i odpowiedzialności nie są biurokracją. Są sposobem na to, żeby w pierwszych minutach incydentu jednostka nie traciła czasu na pytanie, kto właściwie może podjąć decyzję.
Jeżeli chcesz zobaczyć, jak taki porządek wygląda w dokumentacji, zacznij od próbki dokumentacji M05 - Podstawy KRI. To bezpieczny punkt odniesienia przed rozmową o pełnym wdrożeniu.