Ład decyzyjny dotyczący płatności okupu w ataku ransomware w kontekście NIS2 i DORA

Jest 3:17 nad ranem w dzień roboczy w 2026 roku. Maria, CISO w szybko rosnącej platformie fintech, zostaje włączona do telekonferencji kryzysowej po wiadomości od głównego analityka SOC: potwierdzono szyfrowanie na szeroką skalę, kluczowe usługi są niedostępne, a grupa ransomware twierdzi, że wykradła 2 TB danych klientów.

Jako pierwszy dołącza CEO. Następnie dział prawny, zespół ochrony prywatności, finanse, komunikacja, ubezpieczyciel cybernetyczny, dostawca usług informatyki śledczej oraz zespół operacji chmurowych. Portal w dark webie pokazuje 48-godzinne odliczanie i siedmiocyfrowe żądanie w kryptowalucie.

CEO zadaje pytanie, którego obawia się każdy CISO.

„Czy możemy zapłacić i kto może o tym zdecydować?”

Błędną odpowiedzią jest potraktowanie tego jako problemu negocjacyjnego. Właściwą odpowiedzią jest potraktowanie tego jako problemu ładu zarządczego.

W 2026 roku ład decyzyjny dotyczący płatności okupu w ataku ransomware nie jest już prywatną, techniczną decyzją kryzysową. Może zostać poddany kontroli przez organy regulacyjne, audytorów, ubezpieczycieli, klientów, organy ścigania, akcjonariuszy i zarząd. Decyzja o płatności przecina się z ekspozycją sankcyjną, oceną naruszenia ochrony danych osobowych, warunkami ubezpieczenia cybernetycznego, obowiązkami umownymi, komunikacją kryzysową, zabezpieczaniem materiału dowodowego, etapowym raportowaniem NIS2, klasyfikacją incydentów DORA, zgłoszeniem GDPR oraz doskonaleniem po incydencie.

Dlatego Clarysec rekomenduje klientom zbudowanie ładu decyzyjnego dotyczącego płatności okupu w ataku ransomware w ramach SZBI jeszcze przed incydentem. ISO/IEC 27001:2022 zapewnia strukturę systemu zarządzania. Kontrole ISO/IEC 27002:2022 dostarczają model operacyjny. Zenith Blueprint: 30-stopniowa mapa drogowa audytora oraz Zenith Controls: przewodnik po zgodności krzyżowej pomagają przełożyć tę strukturę na praktyczne dowody możliwe do prześledzenia w audycie.

Playbook ransomware, który mówi „powiadom dział prawny”, nie wystarcza. Organizacja musi wiedzieć, kto może autoryzować negocjacje, jak wykonywana jest weryfikacja sankcyjna, kiedy ubezpieczyciel musi wyrazić zgodę, jak dokumentowana jest klasyfikacja GDPR, NIS2 i DORA oraz jak chroniony jest materiał dowodowy, gdy zespoły odzyskiwania działają pod presją.

Dlaczego doraźne decyzje o płatności okupu w ataku ransomware zawodzą

Decyzję o płatności okupu w ataku ransomware często opisuje się jako binarną: zapłacić albo nie zapłacić. W rzeczywistości decyzja ma co najmniej sześć warstw:

1. Czy zdarzenie zostało potwierdzone, opanowane i prawidłowo sklasyfikowane?
2. Czy dotknięte są dane osobowe, dane regulowane albo świadczenie usług krytycznych?
3. Czy organizacja może zgodnie z prawem komunikować się lub zawierać transakcje ze sprawcą zagrożenia?
4. Czy ubezpieczenie cybernetyczne wymaga wcześniejszego powiadomienia, zatwierdzonych dostawców, zgody lub określonych dowodów?
5. Czy płatność ograniczyłaby wpływ na biznes, czy zwiększyłaby ryzyko prawne, finansowe i reputacyjne?
6. Kto ma uprawnienia decyzyjne i jak decyzja jest rejestrowana?

Podczas trwającego incydentu nieskoordynowane zespoły często działają w różnych kierunkach. CFO może postrzegać okup jako koszt biznesowy w porównaniu z narastającym przestojem. Dział prawny widzi sankcje, przestępczość finansową i ekspozycję regulacyjną. DPO ocenia, czy zaszyfrowane lub wyeksfiltrowane dane powodują naruszenie ochrony danych osobowych podlegające zgłoszeniu. Funkcja zgodności monitoruje terminy raportowania NIS2 i DORA. CISO próbuje zabezpieczać materiał dowodowy, równolegle przywracając usługi. CEO oczekuje rekomendacji przed upływem licznika atakującego.

Bez formalnego procesu decyzyjnego najgłośniejszy głos w pomieszczeniu może stać się modelem ładu zarządczego. To dokładnie sytuacja, której współczesne regulacje cyberbezpieczeństwa mają zapobiegać.

NIS2 czyni cyberbezpieczeństwo odpowiedzialnością zarządczą. Article 20 dotyczy ładu zarządczego i rozliczalności organów zarządzających, natomiast Article 21 wymaga środków zarządzania ryzykiem obejmujących obsługę incydentów, ciągłość działania, zarządzanie kopiami zapasowymi, zarządzanie kryzysowe, bezpieczeństwo łańcucha dostaw, kontrolę dostępu, zarządzanie aktywami, MFA oraz ocenę skuteczności. Article 23 ustanawia etapowe raportowanie znaczących incydentów, w tym wczesne ostrzeżenie w ciągu 24 godzin, zgłoszenie w ciągu 72 godzin oraz raport końcowy w ciągu jednego miesiąca, jeżeli ma to zastosowanie.

Dla podmiotów finansowych DORA jest sektorowym zbiorem zasad odporności operacyjnej. Article 5 nakłada odpowiedzialność za zarządzanie ryzykiem ICT na organ zarządzający. Articles 17, 18 i 19 dotyczą zarządzania incydentami związanymi z ICT, klasyfikacji oraz raportowania poważnych incydentów związanych z ICT. DORA wymaga również zdolności reagowania i odzyskiwania, tworzenia kopii zapasowych i odtwarzania, uczenia się po incydentach, testowania oraz zarządzania ryzykiem ICT stron trzecich.

GDPR dodaje osobną, ale nakładającą się ocenę. Jeżeli ransomware powoduje przypadkowe lub niezgodne z prawem zniszczenie, utratę, zmianę, nieuprawnione ujawnienie danych osobowych albo nieuprawniony dostęp do nich, administrator musi ocenić, czy doszło do naruszenia ochrony danych osobowych. Jeżeli wymagane jest zgłoszenie, termin dla organu nadzorczego wynosi zasadniczo 72 godziny od momentu stwierdzenia naruszenia. Jeżeli istnieje wysokie ryzyko dla osób fizycznych, może być również wymagana komunikacja do osób, których dane dotyczą.

Wniosek jest prosty: pytanie o okup nie może paść po raz pierwszy dopiero w sztabie kryzysowym.

Kontrole ISO 27001:2022 stanowiące podstawę ładu decyzyjnego dotyczącego płatności

SZBI zgodny z ISO/IEC 27001:2022 nie jest listą kontrolną dla audytorów. Jest systemem zarządzania służącym do podejmowania decyzji opartych na ryzyku. Ład decyzyjny dotyczący płatności okupu w ataku ransomware należy do tego systemu, ponieważ łączy ocenę ryzyka, postępowanie z ryzykiem, role, obowiązki prawne, reagowanie na incydenty, ciągłość działania, zarządzanie dostawcami oraz ciągłe doskonalenie.

Najistotniejsze kontrole z Annex A ISO 27001:2022 tworzą powiązany łańcuch kontroli.

W Zenith Controls sekcja dotycząca A.5.24, planowania i przygotowania zarządzania incydentami bezpieczeństwa informacji, klasyfikuje kontrolę jako korygującą, powiązaną z poufnością, integralnością i dostępnością oraz dostosowaną do koncepcji reagowania i odzyskiwania. Łączy także A.5.24 z oceną zdarzeń A.5.25, uczeniem się z incydentów A.5.27, rejestrowaniem A.8.15, monitorowaniem A.8.16, bezpieczeństwem podczas zakłócenia A.5.29, ciągłością działania oraz kontaktem z organami.

Ma to znaczenie, ponieważ ład decyzyjny dotyczący płatności okupu w ataku ransomware jest łańcuchem. Jeśli nie można wykryć i sklasyfikować zdarzenia, nie można podjąć decyzji. Jeśli nie można zabezpieczyć materiału dowodowego, nie można obronić decyzji. Jeśli obowiązki prawne nie są zmapowane, negocjacje lub płatność mogą być niezgodne z prawem. Jeśli opcje odzyskiwania nie zostały przetestowane, najwyższe kierownictwo może zostać popchnięte w stronę decyzji opartej na strachu, a nie na faktach.

Zenith Controls jasno opisuje relację między przygotowaniem a podejmowaniem decyzji:

„5.25 jest punktem decyzyjnym, który określa, kiedy zdarzenie przekracza próg incydentu bezpieczeństwa, uruchamiając działania opisane w 5.26. Terminowa i dokładna ocena zdarzenia zapewnia, że reagowanie na incydenty nie jest ani opóźnione, ani skierowane w niewłaściwą stronę.”

Ten sam przewodnik łączy A.5.31, wymagania prawne, ustawowe, regulacyjne i umowne, z prywatnością, retencją zapisów, niezależnym przeglądem oraz zgodnością z politykami wewnętrznymi. Dla ransomware A.5.31 jest miejscem, w którym weryfikacja sankcyjna, obowiązki ubezpieczeniowe, współpraca z organami ścigania, umowy z klientami, obowiązki ochrony danych oraz sektorowe raportowanie regulacyjne są ujęte w jednym rejestrze zgodności.

Pięciobramkowy model Clarysec dla ładu decyzyjnego dotyczącego płatności okupu w ataku ransomware

Model Clarysec dzieli ład decyzyjny dotyczący płatności okupu w ataku ransomware na pięć bramek. Celem nie jest ułatwienie płacenia. Celem jest zapewnienie, że każda decyzja, w tym odmowa płatności, jest oparta na dowodach, poddana przeglądowi prawnemu, autoryzowana i możliwa do prześledzenia w audycie.

Model ten wykorzystuje logikę postępowania z ryzykiem ISO 27001. Płatność okupu w ataku ransomware nie jest kontrolą bezpieczeństwa. Jest co najwyżej opcją kryzysową rozważaną w kontekście postępowania z ryzykiem i odzyskiwania. Przed incydentem organizacja powinna już zdecydować, jak traktowane są ryzyka ransomware: ograniczane przez kontrole, częściowo transferowane przez ubezpieczenie w zakresie ekspozycji finansowej, unikane poprzez eliminację nieakceptowalnych zależności od systemów legacy albo jawnie akceptowane jako ryzyko szczątkowe, jeżeli istnieje uzasadnienie.

W fazie zarządzania ryzykiem, krok 13, planowanie postępowania z ryzykiem i Deklaracja stosowania, Zenith Blueprint instruuje organizacje, aby określiły opcje postępowania dla każdego ryzyka i udokumentowały je w rejestrze ryzyk. Ostrzega, że transfer, taki jak ubezpieczenie cybernetyczne, nie usuwa potrzeby stosowania kontroli, ponieważ transfer często dotyczy wpływu finansowego, a nie prawdopodobieństwa. Stwierdza również:

„Akceptacja musi być jawna i zatwierdzona przez kierownictwo, szczególnie dla wszelkich ryzyk średnich. Ryzyka wysokie są rzadko akceptowane, chyba że są rzeczywiście nieuniknione i uzgodnione na najwyższym poziomie.”

To zdanie jest bezpośrednio istotne dla ładu decyzyjnego dotyczącego płatności okupu w ataku ransomware. Jeśli zarząd jest proszony o zaakceptowanie ryzyka szczątkowego odmowy płatności albo ryzyka prawnego i reputacyjnego wynikającego z zatwierdzenia negocjacji, akceptacja musi być jawna, zarejestrowana i zatwierdzona przez właściwy organ.

Polityka zarządzania ryzykiem Clarysec wzmacnia tę samą zasadę:

„Decyzje dotyczące postępowania z ryzykiem muszą być zgodne z uprzednio zdefiniowanymi opcjami”
Z klauzuli 5.5.

Decyzja dotycząca okupu nie jest więc skrótem omijającym zarządzanie ryzykiem. Musi być obsługiwana jako formalna, udokumentowana decyzja o postępowaniu z ryzykiem, podejmowana w ramach zdefiniowanych uprawnień.

Uprawnienia wynikające z polityk: kto może decydować pod presją?

Wiele niepowodzeń ransomware to niepowodzenia ładu zarządczego przebrane za awarie techniczne. Ktoś kontaktuje się z atakującym poza zatwierdzonym kanałem. Ktoś obiecuje płatność przed zgodą ubezpieczyciela. Ktoś odtwarza systemy i nadpisuje materiał dowodowy do informatyki śledczej. Ktoś informuje klientów zbyt wcześnie, zbyt późno albo na podstawie niedokładnych faktów.

Polityki Clarysec mają usunąć tę niejednoznaczność.

Dla MŚP Polityka ról i odpowiedzialności w ramach ładu zarządczego - MŚP wprowadza prostą zasadę:

„Wszystkie istotne decyzje dotyczące bezpieczeństwa, wyjątki i eskalacje muszą być rejestrowane i identyfikowalne.”
Z sekcji „Wymagania ładu zarządczego”, klauzula polityki 5.5.

Polityka reagowania na incydenty - MŚP przypisuje uprawnienia eskalacyjne:

„Dyrektor Generalny (GM) odpowiada za autoryzację wszystkich decyzji o eskalacji incydentów, zgłoszeń regulacyjnych i komunikacji zewnętrznej.”
Z sekcji „Wymagania ładu zarządczego”, klauzula polityki 5.1.1.

Łączy również incydenty dotyczące danych klientów z obowiązkami regulacyjnymi:

„Jeżeli zaangażowane są dane klientów, Dyrektor Generalny musi ocenić prawne obowiązki powiadomienia na podstawie zastosowania GDPR, NIS2 lub DORA.”
Z sekcji „Postępowanie z ryzykiem i wyjątki”, klauzula polityki 7.4.1.

W przypadku większych organizacji korporacyjna Polityka ról i odpowiedzialności w ramach ładu zarządczego wymaga natychmiastowej eskalacji tam, gdzie może występować ekspozycja prawna lub naruszenia ochrony danych podlegające zgłoszeniu:

„Eskalacja prawna/regulacyjna: Incydenty obejmujące potencjalną ekspozycję prawną lub naruszenia ochrony danych podlegające zgłoszeniu muszą być natychmiast eskalowane do Oficera ds. prawnych i zgodności oraz Kierownictwa wykonawczego.”
Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.4.3.

Korporacyjna Polityka reagowania na incydenty definiuje uprawnienia kierownictwa wykonawczego podczas poważnych incydentów. Klauzula 4.6.1 stwierdza, że rolą zespołu kierownictwa wykonawczego jest:

„Podejmowanie strategicznych decyzji podczas incydentów o wysokiej wadze, w tym zatwierdzanie zgłoszeń i komunikacji publicznej.”

W kontekście ransomware Clarysec traktuje dyskusję o płatności, autoryzację negocjacji, powiadomienie klientów, oświadczenie regulacyjne i komunikację publiczną jako decyzje strategiczne, a nie działania techniczne.

Z tego wynika praktyczna zasada ładu zarządczego: CISO może rekomendować, zespół incydentowy może oceniać, dział prawny może doradzać, finanse mogą potwierdzać mechanikę płatności, ubezpieczyciel może wyrazić zgodę lub odmówić pokrycia, ale decyzja musi należeć do kierownictwa wykonawczego albo zarządu zgodnie z wcześniej zdefiniowanymi uprawnieniami.

Eskalacja zgodna z wymogami sankcyjnymi przed jakimikolwiek negocjacjami

Proces ransomware zgodny z wymogami sankcyjnymi zaczyna się od zakazu: żaden pracownik, wykonawca, dostawca, broker, negocjator ani członek zespołu reagowania na incydenty nie może negocjować, obiecywać, ułatwiać ani przekazywać wartości sprawcy zagrożenia bez zatwierdzonego przeglądu prawnego.

Punkt kontrolny działu prawnego musi nastąpić przed jakimkolwiek aktywnym kontaktem z atakującym, a nie dopiero po pojawieniu się adresu portfela. Proces powinien obejmować:

• Zaangażowanie doradcy prawnego przed jakąkolwiek komunikacją wykraczającą poza pasywne zabezpieczenie dowodów.
• Identyfikację sprawcy zagrożenia z wykorzystaniem dostępnych danych z informatyki śledczej, informacji wywiadowczych o zagrożeniach i organów ścigania.
• Weryfikację sankcyjną i weryfikację stron objętych ograniczeniami dla nazw grup, aliasów, adresów portfeli, infrastruktury, pośredników i kanałów płatności.
• Rozważenie i zarejestrowanie konsultacji z organami ścigania.
• Powiadomienie ubezpieczyciela cybernetycznego zgodnie z warunkami polisy przed powołaniem dostawców lub rozpoczęciem negocjacji.
• Zaangażowanie DPO lub osoby odpowiedzialnej za ochronę prywatności, jeżeli mogą być zaangażowane dane osobowe.
• Potwierdzenie przez CFO lub osobę odpowiedzialną za finanse kontroli płatności, rozdzielenia obowiązków, kontroli antyfraudowych oraz wymagań dotyczących zatwierdzenia przez zarząd.
• Zarejestrowanie decyzji kierownictwa wykonawczego z uwzględnieniem rozważonych alternatyw, w tym odtworzenia, powstrzymania, zawieszenia usługi, komunikacji z klientami oraz odmowy płatności.
• Zabezpieczenie dowodów dotyczących komunikacji z atakującym, wskaźników, danych portfela, spotkań decyzyjnych, akceptacji i porad zewnętrznych.

Dla ransomware rejestr prawny powinien obejmować co najmniej następujące źródła obowiązków.

Organizacje powinny również zdefiniować, kto może wstrzymać decyzję o płatności. Dział prawny, funkcja zgodności, DPO, doradca ds. sankcji lub zarząd powinni mieć wyraźne uprawnienie do wstrzymania negocjacji lub płatności, jeżeli weryfikacja jest niekompletna, dowody są niewiarygodne, warunki ubezpieczyciela nie są spełnione albo działanie może naruszać prawo lub umowę.

Zabezpieczanie dowodów: nie niszcz materiału dowodowego podczas przywracania usługi

Zespoły reagujące na ransomware naturalnie spieszą się, aby przywrócić operacje. Jeśli jednak odtwarzanie niszczy logi, migawki, żądania okupu, próbki złośliwego oprogramowania, obrazy pamięci lub wiadomości od atakującego, organizacja może utracić możliwość wykazania, co się wydarzyło.

W fazie Controls in Action, krok 23, zabezpieczenia organizacyjne, Zenith Blueprint instruuje organizacje, aby walidowały i testowały zdolności zarządzania incydentami poprzez definiowanie podlegających zgłoszeniu zdarzeń bezpieczeństwa, dokumentowanie procesu decyzyjnego oraz zabezpieczanie dowodów kryminalistycznych. Instruuje zespoły, aby:

„Rejestrowały i zapisywały wszystkie decyzje, role i komunikację (5.26) oraz aktualizowały plan o wnioski (5.27). Potwierdzały, że istnieją procedury zabezpieczania dowodów kryminalistycznych (5.28), w tym migawek logów, kopii zapasowych i bezpiecznej izolacji dotkniętych systemów.”

Ten sam krok wyjaśnia A.5.28 językiem zrozumiałym dla każdego zarządu:

„to, co można udowodnić, ma takie samo znaczenie jak to, co faktycznie się wydarzyło”

Korporacyjna Polityka zabezpieczania materiału dowodowego i informatyki śledczej Clarysec wzmacnia zasadę, że dowody muszą pozostać identyfikowalne:

„Rejestr łańcucha nadzoru musi towarzyszyć wszystkim dowodom fizycznym lub cyfrowym od momentu pozyskania, przez archiwizację lub przekazanie, i musi dokumentować:”
Z sekcji „Wymagania ładu zarządczego”, klauzula polityki 5.6.

Dla MŚP Polityka zabezpieczania materiału dowodowego i informatyki śledczej - MŚP jest celowo praktyczna:

„Zawsze należy utworzyć kopię kryminalistyczną lub eksport; oryginalnego dowodu nigdy nie wolno edytować bezpośrednio.”
Z sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula polityki 6.1.1.

Wymaga również konsultacji prawnej tam, gdzie może występować wpływ na HR, kwestie prawne lub klientów:

„Jeżeli incydent obejmuje potencjalny wpływ na zasoby ludzkie (HR), kwestie prawne lub klientów, GM musi skonsultować się z doradcą prawnym przed podjęciem działań egzekwujących lub eskalacji.”
Z sekcji „Wymagania ładu zarządczego”, klauzula polityki 5.4.2.

Praktyczny pakiet dowodowy powinien zostać otwarty podczas bramki 2. Utwórz ograniczony folder dowodów incydentu. Wyeksportuj osie czasu SIEM, detekcje EDR, logi audytowe chmury, logi logowań dostawcy tożsamości, status zadań kopii zapasowych, żądania okupu, zrzuty ekranu, wiadomości atakującego, adresy portfeli, próbki plików, odniesienia do porad prawnych, korespondencję z ubezpieczycielem i decyzje ze spotkań. Wyznacz depozytariusza danych. Zapisuj wartości skrótów tam, gdzie jest to właściwe. Nie pozwól administratorom czyścić dotkniętych systemów przed pozyskaniem materiału kryminalistycznego, chyba że wymaga tego bezpieczeństwo życia, ochrona usługi krytycznej lub zatwierdzone przez kierownictwo wykonawcze powstrzymanie.

Jeden arkusz klasyfikacji dla NIS2, DORA i GDPR

Incydent ransomware może uruchomić wiele terminów raportowych. Wyzwanie polega nie tylko na znajomości terminów. Polega na tym, aby wiedzieć, kiedy organizacja stwierdziła naruszenie, co wiedziała w tym momencie i jak podjęto decyzje klasyfikacyjne.

NIS2 Article 23 wymaga, aby podmioty kluczowe i ważne bez zbędnej zwłoki powiadamiały CSIRT lub właściwy organ o znaczących incydentach. Znaczenie jest powiązane z poważnym zakłóceniem operacyjnym, stratą finansową albo istotną szkodą materialną lub niematerialną wyrządzoną innym. Model etapowy obejmuje wczesne ostrzeżenie w ciągu 24 godzin, zgłoszenie w ciągu 72 godzin, aktualizacje pośrednie, jeżeli zostaną zażądane, oraz raport końcowy w ciągu jednego miesiąca od zgłoszenia incydentu, jeżeli ma to zastosowanie.

DORA wymaga, aby podmioty finansowe definiowały i wdrażały zarządzanie incydentami związanymi z ICT, rejestrowały incydenty i znaczące cyberzagrożenia, klasyfikowały incydenty według kryteriów takich jak dotknięci klienci, czas trwania, zasięg geograficzny, utrata danych, krytyczność i wpływ ekonomiczny oraz zgłaszały poważne incydenty związane z ICT do właściwych organów poprzez raporty wstępne, pośrednie i końcowe.

GDPR zadaje inne, ale nakładające się pytanie: czy incydent spowodował naruszenie ochrony danych osobowych? Jeśli tak, czy prawdopodobnie skutkuje ryzykiem dla osób fizycznych? Jeżeli próg zgłoszenia został spełniony, zgłoszenie do organu nadzorczego musi zostać ocenione względem 72-godzinnego terminu. Jeżeli istnieje wysokie ryzyko, może być również konieczna komunikacja do osób fizycznych.

Clarysec rekomenduje prowadzenie jednego arkusza klasyfikacji ransomware z osobnymi sekcjami dla każdego reżimu.

Takie podejście wpisuje się w klauzule ISO 27001 dotyczące oceny ryzyka, postępowania z ryzykiem oraz udokumentowanej informacji. Jest również zgodne z NIST CSF 2.0. Funkcja GOVERN w NIST CSF 2.0 oczekuje, że organizacje rozumieją interesariuszy, obowiązki prawne i regulacyjne, apetyt na ryzyko, role, politykę, nadzór i ryzyko stron trzecich. Jej wyniki w obszarach wykrywania, reagowania i odzyskiwania wspierają deklarację incydentu, analizę, koordynację reakcji, powiadamianie interesariuszy, realizację odzyskiwania i walidację odtworzenia.

Dla podmiotów finansowych DORA może funkcjonować jako sektorowy reżim cyberbezpieczeństwa dla nakładających się obowiązków NIS2, ale nie usuwa to potrzeby rozumienia zastosowania NIS2 do podmiotów grupy, dostawców ICT, usług zarządzanych lub zależności chmurowych. Praktyczna odpowiedź nie polega na utrzymywaniu odrębnych playbooków. Polega na prowadzeniu jednego modelu dowodowego SZBI, zmapowanego na wszystkie właściwe obowiązki.

Ubezpieczenie cybernetyczne i koordynacja dostawców są kontrolami ładu zarządczego

Ubezpieczenie cybernetyczne może być wartościowe, ale nie jest strategią ransomware. Jest mechanizmem transferu ryzyka z warunkami. Podczas zdarzenia ransomware ubezpieczyciel może wymagać natychmiastowego powiadomienia, korzystania z firm panelowych, uprzedniej zgody na negocjacje, zabezpieczenia dowodów, wykazania nieskuteczności kopii zapasowych, wykazania rozsądnych kontroli oraz przeglądu prawnego przed jakimkolwiek rozważeniem płatności.

DORA czyni ryzyko ICT stron trzecich pełnoprawną domeną zgodności. NIS2 Article 21 wymaga również bezpieczeństwa łańcucha dostaw oraz uwzględnienia podatności dostawców i ich praktyk cyberbezpieczeństwa. ISO 27001 wspiera tę samą logikę poprzez kontrole dostawców i chmury, takie jak A.5.19 do A.5.23, a także kontrole incydentów, ciągłości działania i prawne.

Zenith Controls łączy przygotowanie do incydentu z partnerami zewnętrznymi, w tym firmami informatyki śledczej, działem prawnym, PR oraz kontaktem z organami. Z perspektywy audytu brak uprzednio wskazanych partnerów zewnętrznych może zostać uznany za lukę gotowości, ponieważ może opóźnić reakcję podczas rzeczywistego incydentu.

Dla ładu decyzyjnego dotyczącego płatności okupu w ataku ransomware Clarysec rekomenduje wcześniejsze uzgodnienie:

• Umowy retainerowej na informatykę śledczą lub warunków szybkiej reakcji.
• Dostępności zewnętrznego doradcy prawnego w zakresie naruszeń, sankcji i strategii ochrony tajemnicy zawodowej.
• Ścieżki powiadamiania ubezpieczyciela cybernetycznego oraz listy zatwierdzonych dostawców.
• Ścieżki eskalacji do dostawcy chmury w zakresie migawek, logów, izolacji i odzyskiwania.
• Procedur współpracy incydentowej z MSSP lub MDR.
• Procesu przeglądu PR i komunikacji kryzysowej.
• Bankowych lub finansowych kontroli zatwierdzania dla każdej nadzwyczajnej płatności.
• Protokołu kontaktu z organami ścigania.

Dobrze mapuje się to na wyniki NIST CSF 2.0 dotyczące łańcucha dostaw, w tym role i odpowiedzialności dostawców, due diligence, umowne wymagania cyberbezpieczeństwa, koordynację incydentów z dostawcami oraz działania po zakończeniu współpracy.

Praktyczny playbook eskalacji płatności okupu w ataku ransomware

Pięć bramek można przełożyć na operacyjny playbook. Każdy krok powinien być udokumentowany, mieć właściciela i być przećwiczony.

Celem nie jest zagwarantowanie komfortowej decyzji. Komfortowej decyzji może nie być. Celem jest zapewnienie, że decyzja jest autoryzowana, oparta na dowodach, uwzględnia stanowisko prawne i jest możliwa do obrony.

90-minutowe ćwiczenie tabletop potwierdzające gotowość

Najprostszym sposobem przetestowania ładu decyzyjnego dotyczącego płatności okupu w ataku ransomware nie jest techniczny red team. Jest nim decyzyjne ćwiczenie typu tabletop.

Użyj Zenith Blueprint, faza Controls in Action, krok 23, aby zwalidować zdolność zarządzania incydentami. Wybierz scenariusz ransomware i przeprowadź ćwiczenie w określonym czasie. Celem nie jest wcześniejsze zdecydowanie, że organizacja zapłaci albo nigdy nie zapłaci. Celem jest wykazanie, że organizacja potrafi dojść do decyzji objętej ładem zarządczym.

Scenariusz: baza danych klientów hostowana w chmurze zostaje zaszyfrowana, atakujący twierdzi, że doszło do eksfiltracji, kopie zapasowe istnieją, ale ich integralność nie została jeszcze przetestowana, ubezpieczyciel nie został powiadomiony, a atakujący podaje adres portfela z 48-godzinnym terminem.

Lista kontrolna ćwiczenia:

• Zadeklaruj incydent i przypisz Dowódcę incydentu.
• Otwórz rejestr decyzji ransomware.
• Sklasyfikuj zdarzenie z wykorzystaniem kryteriów A.5.25.
• Zidentyfikuj dotknięte aktywa i usługi biznesowe.
• Ustal, czy zaangażowane są dane osobowe.
• Uruchom przepływy pracy oceny GDPR, NIS2, DORA oraz umownej.
• Powiadom dział prawny, DPO, kierownictwo wykonawcze, ubezpieczyciela i dostawcę informatyki śledczej.
• Zabezpiecz dowody przed destrukcyjnymi działaniami odzyskiwania.
• Sprawdź integralność kopii zapasowych i opcje odtworzenia.
• Przeprowadź weryfikację sankcyjną przed jakimikolwiek negocjacjami.
• Zarejestruj, czy wymagana jest konsultacja z organami ścigania.
• Przygotuj komunikaty tymczasowe dla klientów i regulatorów.
• Przedstaw opcje decyzyjne uprawnionemu organowi wykonawczemu.
• Zarejestruj decyzję, uzasadnienie, zdania odrębne, akceptacje i następne działania.
• Zaplanuj przegląd po incydencie oraz działania doskonalące kontrole.

Wynikiem powinien być kompletny pakiet dowodowy: lista obecności, oś czasu, arkusz klasyfikacji, rejestr decyzji, projekty komunikatów, zadania prawne, zadania dla ubezpieczyciela, ustalenia dotyczące kopii zapasowych oraz wnioski. Taki pakiet jest bardzo wartościowy audytowo, ponieważ pokazuje działanie ładu zarządczego przed realnym kryzysem.

Jak audytorzy i regulatorzy będą testować proces

Audytorzy z różnych środowisk będą badać ten sam proces ransomware przez różne pryzmaty.

Zenith Controls dostarcza szczegółową metodykę audytu dla A.5.24, A.5.25 i A.5.31. Dla A.5.24 audytorzy badają plan reagowania na incydenty, klasyfikacje wagi, role, listy kontaktów, instrukcje raportowania regulacyjnego, ćwiczenia i uzgodnienia z partnerami zewnętrznymi. Dla A.5.25 sprawdzają, czy istnieją kryteria klasyfikacji zdarzeń, czy zapisy obsługi alertów pokazują decyzje dotyczące dochodzenia i eskalacji, czy wykorzystywane są SIEM i informacje o zagrożeniach oraz czy zespoły DPO lub prawne są angażowane, gdy mogą być dotknięte dane osobowe. Dla A.5.31 audytorzy szukają rejestrów prawnych, mapowania zgodności, dowodów przeglądu, pokrycia audytem wewnętrznym i raportowania do kierownictwa wyższego szczebla.

Ryzyko audytowe nie polega wyłącznie na tym, że organizacja zapłaciła albo odmówiła zapłaty. Ryzyko audytowe polega na tym, że nikt nie potrafi wykazać, jak podjęto decyzję.

Od wymuszenia do doskonalenia kontroli

Ład ransomware nie kończy się po przywróceniu systemów. ISO 27001 oczekuje ciągłego doskonalenia. A.5.27, uczenie się z incydentów bezpieczeństwa informacji, jest centralne dla tego oczekiwania. DORA wymaga analizy przyczyny źródłowej i dodatkowych kontroli. Raport końcowy NIS2 oczekuje środków łagodzących oraz prawdopodobnej przyczyny źródłowej, jeżeli ma to zastosowanie. Rozliczalność GDPR oczekuje dokumentowania decyzji i środków bezpieczeństwa.

Każdy przegląd po incydencie ransomware powinien odpowiedzieć na pytania:

• Czy terminy raportowe zostały prawidłowo zidentyfikowane?
• Czy uprawnienie decyzyjne zadziałało zgodnie z projektem?
• Czy przegląd prawny i sankcyjny nastąpił wystarczająco wcześnie?
• Czy koordynacja z ubezpieczycielem pomogła, czy opóźniła reakcję?
• Czy kopie zapasowe były kompletne, odseparowane, możliwe do odtworzenia i przetestowane?
• Czy logi były wystarczające do oceny dostępu i eksfiltracji?
• Czy dostawcy reagowali zgodnie z umową?
• Czy komunikacja z klientami była dokładna i terminowa?
• Czy najwyższe kierownictwo otrzymało właściwe informacje we właściwym czasie?
• Które kontrole, polityki, umowy lub szkolenia muszą się zmienić?

Odpowiedzi powinny zaktualizować rejestr ryzyk, Deklarację stosowania, plan reagowania na incydenty, strategię kopii zapasowych, umowy z dostawcami, plan komunikacji i program szkoleniowy.

W fazie ISMS Foundation and Leadership, krok 5, Zenith Blueprint podkreśla planowanie komunikacji zewnętrznej, w tym identyfikację klientów, regulatorów, partnerów i opinii publicznej, ustalenie co i kiedy komunikować oraz zdefiniowanie, kto komunikuje. Dla ransomware ten krok staje się pomostem między reakcją techniczną a zachowaniem zaufania.

Zbuduj zapis decyzyjny zanim pojawi się żądanie okupu

Najlepszy moment na objęcie decyzji o okupie ładem zarządczym jest zanim atakujący ustawi termin.

Jeżeli Twój playbook ransomware nie definiuje uprawnień decyzyjnych, przeglądu prawnego, weryfikacji sankcyjnej, akceptacji ubezpieczyciela, zabezpieczania dowodów, klasyfikacji NIS2 i DORA, oceny naruszenia GDPR oraz dokumentacji na poziomie zarządu, organizacja ma lukę ładu zarządczego oczekującą na kryzys.

Clarysec pomaga organizacjom wbudować tę zdolność w SZBI, wykorzystując:

• Zenith Blueprint: 30-stopniowa mapa drogowa audytora do etapowego wdrożenia ISO 27001, postępowania z ryzykiem, planowania komunikacji oraz walidacji zdolności incydentowych.
• Zenith Controls: przewodnik po zgodności krzyżowej do mapowania kontroli ISO 27001 na NIS2, DORA, GDPR, NIST CSF, COBIT 2019, ISO/IEC 27035, ISO/IEC 27701, ISO/IEC 27005 oraz dowody audytowe.
• Polityki korporacyjne i dla MŚP Clarysec, w tym Polityka reagowania na incydenty, Polityka reagowania na incydenty - MŚP, Polityka zabezpieczania materiału dowodowego i informatyki śledczej, Polityka zabezpieczania materiału dowodowego i informatyki śledczej - MŚP, Polityka ról i odpowiedzialności w ramach ładu zarządczego, Polityka ról i odpowiedzialności w ramach ładu zarządczego - MŚP oraz Polityka zarządzania ryzykiem.
• Praktyczne szablony ćwiczeń tabletop ransomware, rejestry decyzji, macierze eskalacji prawnej, pakiety dowodowe oraz arkusze raportowania zgodności krzyżowej.

Nie czekaj na telefon o 3 nad ranem, aby odkryć, kto może decydować. Przejrzyj swój plan reagowania na incydenty względem pięciu bramek Clarysec, przeprowadź 90-minutowe ćwiczenie tabletop dotyczące płatności okupu w ataku ransomware i zbuduj zgodny z wymogami sankcyjnymi, gotowy do audytu zapis decyzyjny, który wytrzyma kontrolę regulatorów, ubezpieczycieli i własnego zarządu.