Incydent w piątek o godzinie dwudziestej. Czy twoja firma wie, co robić? [WYWIAD]

• Wpis do wykazu nie oznacza jeszcze, że firma jest przygotowana na incydent
• Ćwiczenia symulacyjne sprawdzianem gotowości
• Współdzielona odpowiedzialność

Wpis do wykazu nie oznacza jeszcze, że firma jest przygotowana na incydent

Infor.pl: Mija pierwszy etap wdrożenia nowelizacji ustawy o KSC. Jak ocenia Pani dotychczasowy przebieg tego procesu?

Marta Dąbrowska: Pierwszy etap miał przede wszystkim charakter identyfikacyjny i formalny. Podmioty objęte przepisami musiały ustalić, czy podlegają nowym regulacjom, określić swój status i, jeżeli nie były wpisywane z urzędu, zarejestrować się w Wykazie KSC. Już samo to, że wiele organizacji musiało przeanalizować swoją działalność pod kątem cyberbezpieczeństwa i zaangażować się w ten proces, jest istotną wartością pierwszego etapu. Regulacja przeniosła ten temat z poziomu działu IT na poziom zarządu i całej organizacji.

Jednocześnie wpis do wykazu nie oznacza jeszcze, że firma jest przygotowana na incydent ani że wdrożyła wymagane środki bezpieczeństwa. To dopiero początek. Najtrudniejszy etap zaczyna się teraz, ponieważ do 3 kwietnia 2027 r. trzeba przełożyć wymagania ustawy na działające procedury, odpowiedzialności, zabezpieczenia techniczne oraz współpracę z dostawcami. O powodzeniu wdrożenia nie zdecyduje liczba przygotowanych dokumentów, ale to, czy organizacja potrafi wykryć incydent, właściwie na niego zareagować i odtworzyć działanie swoich kluczowych systemów.

Firmy mają teraz niecałe pół roku na wdrożenie wymaganych środków bezpieczeństwa. Dlaczego, mimo dostępnych narzędzi zabezpieczających, to właśnie „podstawy” stanowią największy problem?

M.D.: Ponieważ narzędzia działają tylko w ramach zasad, które organizacja wcześniej ustali. System monitorowania może wykryć nietypowe logowanie, ale nie rozstrzygnie, czy dana osoba nadal powinna mieć dostęp. Mechanizm tworzenia kopii wykona zadanie zgodnie z harmonogramem, ale sam nie potwierdzi, że kopia jest kompletna i pozwoli odtworzyć cały proces biznesowy. Do tego potrzebne są aktualna inwentaryzacja, właściciele systemów i określone wymagania bezpieczeństwa.

Najwięcej luk powstaje w codziennych procesach na styku IT, biznesu, kadr i dostawców. Informacja o odejściu pracownika musi skutkować odebraniem wszystkich dostępów. Poprawka bezpieczeństwa w systemie dostosowanym do firmy wymaga analizy wpływu, testów i zaplanowanego okna serwisowego. Z kolei kopię zapasową warto okresowo odtworzyć w warunkach zbliżonych do awarii. Każdy taki proces powinien mieć przypisaną osobę odpowiedzialną, ustalony termin i sposób potwierdzenia wykonania.

Jakie są główne obszary zaniedbań? Który z nich w praktyce najtrudniej uporządkować organizacjom i dlaczego?

M.D.: Pierwszym obszarem są konta i uprawnienia: konta współdzielone, zbyt szerokie uprawnienia administratorów, aktywne konta byłych pracowników oraz brak okresowych przeglądów dostępu. Drugą kategorią są aktualizacje i zarządzanie podatnościami, zwłaszcza gdy organizacja korzysta ze starszych wersji systemów albo odkłada instalowanie poprawek z obawy przed przerwą w pracy.

Kolejnym obszarem są kopie zapasowe i ciągłość działania. Kopie bywają wykonywane, ale nie zawsze są przechowywane poza środowiskiem produkcyjnym i regularnie testowane. Często brakuje również potwierdzonych i przetestowanych parametrów RTO i RPO, czyli odpowiedzi na pytania, w jakim czasie system ma zostać przywrócony oraz ile najnowszych danych organizacja może utracić.

Najtrudniejsze jest jednak zwykle nie wdrożenie pojedynczego zabezpieczenia, lecz uporządkowanie odpowiedzialności. System biznesowy zależy często jednocześnie od klienta, producenta oprogramowania, administratora infrastruktury, firmy hostingowej oraz innych dostawców. Jeżeli wcześniej nie ustalono, kto wykrywa zdarzenie, kto podejmuje decyzję, kto odtwarza system i kto zgłasza incydent, w sytuacji kryzysowej organizacja traci najcenniejszy zasób - czas.

Ćwiczenia symulacyjne sprawdzianem gotowości

Ustawa wymaga przekazania wczesnego ostrzeżenia w ciągu 24 godzin od wykrycia incydentu poważnego, a jego zgłoszenia w ciągu 72 godzin. Czy polskie firmy są organizacyjnie gotowe na dotrzymanie tych terminów?

M.D.: Poziom przygotowania jest bardzo zróżnicowany. Organizacje, które od lat działają w sektorach regulowanych, zazwyczaj mają już procedury reagowania i wyznaczone osoby odpowiedzialne. W wielu pozostałych firmach problemem nie jest jednak samo wysłanie zgłoszenia, lecz wcześniejsze zauważenie zdarzenia, ocena jego wpływu i podjęcie decyzji, czy mamy do czynienia z poważnym incydentem.

W ciągu 24 godzin firma musi być w stanie zebrać dostępne informacje, przeprowadzić wstępną ocenę zdarzenia, uruchomić właściwą ścieżkę eskalacji i przekazać wczesne ostrzeżenie. Nie oznacza to, że na tym etapie musi już znać wszystkie przyczyny i skutki incydentu. Musi jednak działać na tyle sprawnie, aby nie tracić czasu na ustalanie, kto odpowiada za analizę zdarzenia, kontakt z dostawcami i komunikację z właściwym CSIRT (zespołem reagowania na incydenty bezpieczeństwa informatycznego).

Najlepszym sprawdzianem gotowości jest ćwiczenie symulacyjne. Warto przeanalizować prosty scenariusz: incydent zostaje wykryty w piątek wieczorem. Czy informacja dotrze do właściwej osoby? Kto oceni jego wagę? Kto skontaktuje się z dostawcami i kto podejmie decyzję o zgłoszeniu? Dopiero taki test pokazuje, czy organizacja rzeczywiście jest w stanie dotrzymać ustawowych terminów.

Jaki realistyczny plan działania na najbliższe miesiące jest możliwy dla firm, które dopiero przystępują do porządkowania bezpieczeństwa?

M.D.: Na początku firma powinna ustalić, co właściwie chroni. Potrzebna jest inwentaryzacja najważniejszych systemów, danych, integracji, kont i dostawców oraz wskazanie procesów, których zatrzymanie miałoby największy wpływ na działalność. Każdy z tych obszarów powinien mieć właściciela odpowiedzialnego za decyzje i zarządzanie ryzykiem.
Następnie warto usunąć luki, które można ograniczyć stosunkowo szybko: zlikwidować konta współdzielone i nieużywane, odebrać nadmierne uprawnienia, zabezpieczyć dostęp zdalny i serwisowy oraz ustalić plan zaległych aktualizacji. Równolegle należy wykonać pełny test odtworzenia z kopii zapasowych.
Kolejnym krokiem powinno być przećwiczenie reagowania na incydent i uporządkowanie współpracy z dostawcami. Trzeba ustalić, kto klasyfikuje zdarzenie, podejmuje decyzję o zgłoszeniu, przywraca działanie systemu i przekazuje informacje o podatności lub incydencie.

Nie trzeba od razu wdrażać wszystkich możliwych zabezpieczeń. Najważniejsze jest ustalenie priorytetów na podstawie ryzyka, rozpoczęcie od systemów krytycznych i dokumentowanie wykonanych działań. Pomocną mapą może być NIST CSF 2.0, który porządkuje pracę od identyfikacji ryzyka, przez ochronę i wykrywanie zagrożeń, po reagowanie i odtwarzanie. Samo zastosowanie NIST nie oznacza jednak automatycznej zgodności z KSC.

Współdzielona odpowiedzialność

Jak w praktyce wygląda współpraca firm objętych ustawą z dostawcami oprogramowania, którzy formalnie jej nie podlegają?

M.D.: Qustomity nie podlega bezpośrednio ustawie o KSC, ale część naszych klientów jest nią objęta. Ponieważ dostarczane przez nas systemy wspierają ich istotne procesy biznesowe, stajemy się elementem ocenianego łańcucha dostaw ICT. Jest to naturalne i uzasadnione: klient musi wiedzieć, w jaki sposób system jest rozwijany, zabezpieczany i utrzymywany oraz jak dostawca reaguje na podatności i incydenty.

W praktyce oznacza to ankiety bezpieczeństwa, wymagania umowne, przeglądy procedur oraz pytania o dostęp serwisowy, aktualizacje, zarządzanie podatnościami, kopie zapasowe, ciągłość działania, RTO i RPO, podwykonawców oraz sposób informowania o incydentach. Coraz ważniejsze staje się również określenie wspieranych wersji systemu i terminu zakończenia wsparcia.

Odpowiedzialność jest współdzielona, ale nie może być niejasna. Jej zakres powinien odpowiadać temu, kto faktycznie kontroluje dany element systemu. Po stronie producenta pozostają zwykle bezpieczeństwo rozwijanego kodu, dostarczanie uzgodnionych poprawek i zabezpieczenie własnego dostępu serwisowego. Klient odpowiada za sposób wykorzystania systemu, zarządzanie użytkownikami, własną infrastrukturę i realizację obowiązków ustawowych. Szczegółowy podział odpowiedzialności za aktualizacje, monitoring, kopie zapasowe i odtwarzanie powinien wynikać z architektury rozwiązania, umowy i SLA.

Czy termin 3 kwietnia 2027 r. jest realny dla większości firm objętych ustawą?

M.D.: To zależy od stanu wyjściowego organizacji i stopnia złożoności jej środowiska informatycznego. Pół roku to czas, w którym można uporządkować podstawy i istotnie ograniczyć najważniejsze ryzyka. Nie zawsze wystarczy jednak na usunięcie wszystkich zaległości, szczególnie w przypadku rozbudowanych, dostosowanych systemów, których aktualizacje były przez dłuższy czas odkładane.

W takim systemie nie można po prostu zainstalować najnowszej wersji. Aktualizacja wymaga sprawdzenia zgodności indywidualnych modyfikacji i integracji, przygotowania środowiska, testów funkcjonalnych i bezpieczeństwa, migracji danych, weryfikacji procesów biznesowych oraz zaplanowania możliwości wycofania zmiany. W przypadku dużych zaległości cały proces może potrwać kilka miesięcy.

Organizacje powinny więc już teraz zinwentaryzować podatności, nadać priorytet systemom krytycznym i uzgodnić z dostawcami realistyczny harmonogram aktualizacji. Jeżeli określonej podatności nie można usunąć natychmiast, trzeba zastosować zabezpieczenia ograniczające ryzyko, np. dodatkową kontrolę dostępu, segmentację środowiska lub wzmożony monitoring. Harmonogram naprawczy i zabezpieczenia przejściowe nie przesuwają jednak ustawowego terminu 3 kwietnia 2027 r. i nie zwalniają organizacji z obowiązku wdrożenia wymaganych środków bezpieczeństwa.

Dziękuję za rozmowę.

Rozmawiała Kinga Olszacka

Kalendarz książkowy 2027