Cyberincydent i ransomware w firmie – prawny plan działania na pierwsze 72 godziny

Pierwsza godzina: bezpieczeństwo i zachowanie dowodów

Priorytetem jest zatrzymanie rozprzestrzeniania incydentu bez niszczenia materiału potrzebnego do ustalenia przyczyny. Zespół techniczny powinien pracować według procedury, a osoba koordynująca sprawę musi rejestrować czas, decyzje, systemy i osoby uczestniczące w reakcji.

Nie należy automatycznie wyłączać wszystkich urządzeń, kasować logów ani przywracać systemów bez oceny wpływu na dowody. W zależności od sytuacji potrzebna może być analiza forensic, zabezpieczenie kopii pamięci, logów, wiadomości i danych z urządzeń brzegowych.

Kwalifikacja prawna: jedno zdarzenie może uruchomić kilka reżimów

Ransomware może być jednocześnie incydentem cyberbezpieczeństwa, naruszeniem ochrony danych osobowych, zdarzeniem objętym DORA, naruszeniem umowy z klientem oraz zdarzeniem ubezpieczeniowym. Te kwalifikacje trzeba prowadzić równolegle.

W pierwszych godzinach nie zawsze znamy pełny zakres ataku. Dlatego decyzje powinny być aktualizowane wraz z nowymi ustaleniami. Ważne jest odróżnienie faktów potwierdzonych od hipotez i zachowanie wersji raportów, na których oparto poszczególne zgłoszenia.

KSC/NIS2: szybkie ostrzeżenie i współpraca z CSIRT

Nowy system KSC przewiduje szybkie raportowanie istotnych incydentów. Materiały dla przedsiębiorców wskazują wczesne ostrzeżenie do właściwego CSIRT do 24 godzin. Organizacja nie może zaczynać w tym momencie poszukiwania osoby odpowiedzialnej za zgłoszenie.

Procedura powinna wskazywać właściwy CSIRT, dane kontaktowe, sposób autoryzacji zgłoszenia oraz minimalny zestaw informacji. Zespół techniczny musi wiedzieć, jakie wskaźniki kompromitacji i dane o wpływie należy przekazać prawnikowi lub osobie odpowiedzialnej za compliance.

RODO: czy doszło do naruszenia ochrony danych?

Naruszenie ochrony danych osobowych obejmuje nie tylko wyciek, lecz także utratę dostępności lub integralności danych, jeżeli zdarzenie spełnia definicję z RODO. Administrator ocenia ryzyko dla praw i wolności osób, a w odpowiednich przypadkach zgłasza naruszenie organowi nadzorczemu bez zbędnej zwłoki, w miarę możliwości nie później niż 72 godziny od stwierdzenia.

Nie każde ransomware wymaga identycznego komunikatu do osób. Trzeba ustalić rodzaj danych, skutki, możliwość odtworzenia, prawdopodobieństwo wykorzystania informacji i zastosowane zabezpieczenia. Decyzję o zgłoszeniu albo jej braku należy udokumentować.

DORA i incydent ICT w podmiocie finansowym

Podmiot finansowy objęty DORA ma własny reżim klasyfikacji i raportowania poważnych incydentów ICT. Wymaga to powiązania danych technicznych z wpływem na funkcje biznesowe i kryteriami regulacyjnymi.

Jeżeli firma podlega równolegle RODO lub KSC, zespoły nie powinny tworzyć odrębnych, sprzecznych osi czasu. Wspólna dokumentacja bazowa pozwala przygotować raporty właściwe dla każdego reżimu bez utraty spójności faktów.

Żądanie okupu – decyzja prawna, biznesowa i bezpieczeństwa

Decyzja o zapłacie okupu nie może opierać się wyłącznie na presji czasu. Trzeba ocenić legalność transakcji, ryzyko sankcyjne, stanowisko ubezpieczyciela, realność odzyskania danych oraz wpływ na dalsze bezpieczeństwo. Zapłata nie daje gwarancji usunięcia kopii danych ani otrzymania sprawnego klucza.

Kontakt z atakującym również powinien być kontrolowany. Należy ustalić, kto prowadzi komunikację, jak zachować dowody i czy angażowane są służby, zewnętrzny zespół IR lub negocjator wskazany przez ubezpieczyciela.

Polisa cyber, klienci i obowiązki kontraktowe

Polisa może wymagać zgłoszenia zdarzenia w określonym terminie oraz uzgodnienia wyboru ekspertów. Pochopne zlecenie kosztownych prac bez sprawdzenia warunków ubezpieczenia może utrudnić refundację.

Równolegle trzeba przejrzeć umowy z klientami i dostawcami. Niektóre kontrakty wymagają powiadomienia szybciej niż przepisy powszechne. Komunikat powinien być zgodny z faktami i nie tworzyć niepotrzebnych przyznań odpowiedzialności przed zakończeniem analizy.

Komunikacja z pracownikami, klientami i mediami

Brak komunikacji przez wiele godzin sprzyja plotkom, ale zbyt wczesne deklaracje mogą okazać się fałszywe. Organizacja powinna mieć jedno źródło zatwierdzonych informacji i rozdzielać komunikat operacyjny od informacji prawnej o zakresie zdarzenia.

Warto z góry przygotować szablony, które nie zawierają niepotwierdzonych stwierdzeń. Przy naruszeniu danych komunikacja do osób musi spełniać wymagania RODO, jeżeli zachodzą przesłanki poinformowania.

Po opanowaniu zdarzenia: analiza przyczyny i dowody naprawy

Zamknięcie techniczne incydentu nie kończy pracy. Trzeba ustalić przyczynę, zakres, skuteczność reakcji, błędy w procedurze i działania naprawcze. Następnie należy sprawdzić, czy podobny scenariusz może wystąpić w innych systemach.

W przygotowaniu procedury i prowadzeniu incydentu prawnego pomaga połączenie pracy prawnej z techniczną. Więcej: Prawo nowych technologii i cyberbezpieczeństwo. Największą wartość ma plan przećwiczony przed atakiem.

Łańcuch dowodowy i dokumentowanie czynności

Jeżeli sprawa może trafić do organu, ubezpieczyciela lub sądu, warto zachować informację, kto pozyskał dowód, kiedy i z jakiego systemu. Kopie logów i obrazów powinny być odpowiednio zabezpieczone, a ich integralność możliwa do potwierdzenia.

Nie każdy incydent wymaga pełnej informatyki śledczej, ale brak podstawowej dokumentacji może uniemożliwić późniejsze ustalenie przyczyny lub zakresu szkody. Procedura powinna wskazywać, kiedy angażuje się zewnętrzny zespół forensic.

Policja, prokuratura i inne organy – kiedy rozważyć zgłoszenie?

Ransomware, oszustwo, włamanie do systemu lub kradzież danych mogą wypełniać znamiona czynów zabronionych. Decyzja o zawiadomieniu powinna uwzględniać charakter zdarzenia, materiał dowodowy, ryzyko dla organizacji i potrzebę współpracy ze służbami.

Zawiadomienie karne nie zastępuje zgłoszeń regulacyjnych. Są to odrębne ścieżki z innym celem i zakresem informacji. Warto koordynować komunikację, aby nie przekazywać niespójnych opisów tego samego zdarzenia.

Odtwarzanie usług: kiedy można bezpiecznie wrócić do produkcji?

Przywrócenie systemu z kopii nie powinno nastąpić bez oceny, czy usunięto wektor ataku. W przeciwnym razie organizacja może odtworzyć środowisko tylko po to, aby zostało ponownie zaszyfrowane lub przejęte.

Decyzję o powrocie do produkcji warto oprzeć na kryteriach technicznych i biznesowych: usunięcie podatności, reset poświadczeń, weryfikacja kopii, monitoring zwiększonego ryzyka i akceptacja właściciela usługi. Każdy wyjątek należy zapisać.

Tabletop exercise – najtańszy sposób sprawdzenia planu przed atakiem

Ćwiczenie stolikowe pozwala przejść przez scenariusz ransomware bez wyłączania produkcji. Uczestnicy otrzymują kolejne informacje i podejmują decyzje: izolacja systemów, kontakt z CSIRT, RODO, ubezpieczyciel, klient i komunikat publiczny.

Największą wartość dają pytania, na które organizacja nie potrafi odpowiedzieć: kto ma numer do dostawcy, gdzie jest polisa, kto może zatwierdzić komunikat, jak pobrać logi. Wnioski z ćwiczenia powinny zostać zamknięte przed kolejnym testem.

Najczęstsze pytania