Ransomware w banku i inne kryzysy – testy stolikowe i scenariuszowe: czy bank naprawdę potrafi działać?

 

Procedura jest przygotowana. Backup działa. SOC monitoruje. Zespół zna swoje obowiązki.

Ale co wydarzy się, gdy pewnego dnia na ekranach pracowników pojawi się informacja o zaszyfrowaniu danych?

Czy bank naprawdę wie, co wtedy zrobić?

Tego nie da się wiarygodnie ocenić wyłącznie na podstawie dokumentacji.

Trzeba to przetestować.

Test stolikowy to nie czytanie procedury

Dobry test stolikowy powinien postawić uczestników przed konkretną sytuacją i wymusić decyzje.

Nie pytamy:

„Czy bank posiada procedurę ransomware?”

Pytamy:

„SOC wykrył szyfrowanie plików na kilku urządzeniach. Co robimy w ciągu najbliższych 10 minut?”

Wtedy szybko okazuje się:

• kto podejmuje decyzję,
• kto koordynuje działania,
• kiedy informowany jest Zarząd,
• kto kontaktuje ZDU,
• jak uruchamiany jest BCP/DR,
• czy wiadomo, które procesy są zagrożone,
• czy możliwe jest odtworzenie usług.

Scenariusz 1 – ransomware w banku

SOC wykrywa nietypową aktywność.

Po kilku minutach kolejne urządzenia tracą dostęp do danych.

Pierwsze pytania powinny dotyczyć:

• skali zdarzenia,
• możliwości izolacji,
• zagrożonych systemów,
• procesów krytycznych,
• bezpieczeństwa backupu,
• sposobu eskalacji,
• komunikacji.

Najważniejsze jest sprawdzenie, czy bank potrafi przejść od:

alertu → decyzji → izolacji → oceny wpływu → odtworzenia → komunikacji.

Scenariusz 2 – awaria krytycznego systemu ICT

System wspierający proces krytyczny przestaje działać.

Nie wiadomo, kiedy zostanie przywrócony.

W takim teście należy sprawdzić:

• jaki proces został dotknięty,
• jakie RTO wynika z BIA,
• czy istnieje tryb alternatywny,
• które systemy zależne również zostaną zatrzymane,
• kto podejmuje decyzję o uruchomieniu procedury awaryjnej.

Test bardzo szybko pokazuje, czy wartości zapisane w BIA odpowiadają rzeczywistym możliwościom banku.

Scenariusz 3 – krytyczny ZDU nie działa

Dostawca informuje o poważnej awarii.

Nie podaje wiarygodnego czasu przywrócenia usługi.

Bank powinien wtedy wiedzieć:

• jak eskalować problem,
• kto kontaktuje dostawcę,
• jakie informacje musi uzyskać,
• jaki proces banku jest zagrożony,
• jak długo bank może czekać,
• czy istnieje rozwiązanie alternatywne,
• kiedy uruchomić działania wynikające z Exit Planu.

To jeden z najlepszych sposobów sprawdzenia, czy zależność od ZDU jest naprawdę kontrolowana.

Scenariusz 4 – backup istnieje, ale odtworzenie trwa za długo

Raport pokazuje:

BACKUP SUCCESS.

Podczas testu pojawia się jednak problem.

BIA wymaga odtworzenia usługi w ciągu 4 godzin, a rzeczywisty proces trwa 8 godzin.

Wtedy bank otrzymuje bardzo konkretną informację:

backup działa, ale zdolność odtworzeniowa nie spełnia wymagań procesu.

Test powinien więc sprawdzać nie tylko wykonanie kopii, ale również:

• integralność danych,
• dostępność repozytorium,
• kolejność odtwarzania,
• zależności między systemami,
• rzeczywisty czas uruchomienia usługi.

Scenariusz 5 – jednocześnie pojawia się kilka problemów

Najtrudniejsze kryzysy rzadko przebiegają według jednego prostego scenariusza.

Wyobraźmy sobie sytuację:

• system jest niedostępny,
• klienci zaczynają zgłaszać problemy,
• dostawca nie podaje czasu naprawy,
• Zarząd oczekuje informacji,
• pojawiają się pytania o bezpieczeństwo danych,
• pracownicy potrzebują instrukcji dalszego działania.

Taki scenariusz sprawdza nie tylko technologię.

Sprawdza przede wszystkim zdolność organizacji do podejmowania decyzji pod presją czasu.

Co powinien wykazać dobry test odporności?

Po zakończeniu testu nie wystarczy stwierdzić:

„Test zakończono pozytywnie.”

Powinno być wiadomo:

• co zadziałało,
• co nie zadziałało,
• jakie założenie było błędne,
• jaka luka została wykryta,
• jaki jest jej wpływ,
• kto odpowiada za poprawę,
• jaki jest termin działania,
• kiedy wykonany zostanie retest.

Najbardziej wartościowy test to często taki, który wykrył problem zanim zrobił to prawdziwy incydent.

Jak zamienić wynik testu w realną poprawę?

Dobry model jest prosty:

SCENARIUSZ → DECYZJA → WYNIK → LUKA → DZIAŁANIE → WŁAŚCICIEL → TERMIN → RETEST → DOWÓD

Jeżeli test wykazał, że odtworzenie trwa za długo – należy usunąć przyczynę.

Jeżeli nie było wiadomo, kto informuje Zarząd – należy poprawić ścieżkę eskalacji.

Jeżeli dostawca nie odpowiadał – należy zweryfikować umowę, SLA i procedurę kontaktu.

Jeżeli SOC nie widział zdarzenia – należy sprawdzić monitoring i telemetrię.

Test bez działania naprawczego nie zwiększa odporności banku.

Jak często bank powinien przeprowadzać testy?

Nie warto ograniczać się do jednego scenariusza wykonywanego każdego roku.

Roczny program testów powinien obejmować różne obszary, np.:

• ransomware,
• awarię ICT,
• odtworzenie z backupu,
• niedostępność ZDU,
• ciągłość procesów krytycznych,
• reakcję SOC,
• komunikację kryzysową.

Kolejne testy powinny wynikać z BIA, analizy ryzyka, incydentów, zmian technologicznych oraz wyników wcześniejszych ćwiczeń.

Podsumowanie

Bank może posiadać:

BCP, DRP, SOC, backup, procedurę incydentową i umowę z ZDU.

Ale dopiero test odpowiada na pytanie:

czy to wszystko naprawdę zadziała podczas kryzysu?

Dlatego warto przejść od pytania:

„Czy mamy procedurę?”

do pytania:

„Kiedy ostatnio ją sprawdziliśmy i co wtedy nie zadziałało?”

Bo odporność banku buduje się nie przez samo posiadanie dokumentów.

Buduje się ją przez:

test → wykrytą lukę → poprawę → ponowną weryfikację.

Pytania i odpowiedzi

Czym jest test stolikowy w banku?

To praktyczne ćwiczenie, podczas którego uczestnicy otrzymują scenariusz incydentu lub awarii i muszą podejmować decyzje zgodnie z rzeczywistymi rolami oraz procedurami.

Czy test stolikowy wymaga wyłączania systemów?

Nie. Test może być przeprowadzony bez ingerencji w środowisko produkcyjne. Jego celem jest przede wszystkim sprawdzenie decyzji, odpowiedzialności, komunikacji i procedur.

Czy bank powinien testować scenariusz ransomware?

Tak. Ransomware pozwala jednocześnie zweryfikować SOC, reakcję IT, eskalację, ochronę backupu, BCP/DR, komunikację oraz decyzje Zarządu.

Czy poprawny backup oznacza, że test odtworzenia nie jest potrzebny?

Nie. Wykonanie kopii nie potwierdza, że bank potrafi odtworzyć pełną usługę w czasie wymaganym przez BIA.

Czy podczas testów należy uwzględniać ZDU?

Tak. Jeżeli dostawca wspiera proces krytyczny, jego awaria lub brak reakcji powinny być uwzględnione w scenariuszach testowych.

Co zrobić, jeżeli test wykryje poważną lukę?

Należy określić wpływ, przyczynę, właściciela działania naprawczego i termin, a następnie przeprowadzić retest potwierdzający skuteczność poprawy.

Co jest najważniejszym efektem testu odporności?

Nie „zaliczenie” testu, ale wiedza, co należy poprawić zanim pojawi się prawdziwy kryzys.

Czy Twój bank naprawdę potrafi działać podczas ransomware lub poważnej awarii?

Jeżeli chcesz sprawdzić, czy BCP, DRP, SOC, backup, ZDU oraz procedury reagowania rzeczywiście zadziałają podczas kryzysu, skontaktuj się bezpośrednio ze specjalistami Servus Comp Kraków.

Pomagamy bankom spółdzielczym w:

• przygotowaniu testów stolikowych,
• projektowaniu scenariuszy ransomware,
• testowaniu BCP i DRP,
• testowaniu backupu i odtworzenia,
• symulacji awarii ZDU,
• sprawdzaniu ścieżek eskalacji,
• ocenie reakcji SOC i IT,
• dokumentowaniu wyników testów,
• budowie planów działań naprawczych,
• przygotowaniu dowodów dla Zarządu i audytora.

Servus Comp Kraków
Bezpieczeństwo • Odporność • Ryzyko ICT • Zgodność

Zapraszamy Państwa do zapoznania się z innymi wpisami na naszm blogu:

1. Strategia ICT to za mało. KNF pyta o operacyjną odporność cyfrową Banku:

   https://premiumbank.zadbajobezpieczenstwo.pl/strategia-ict-to-za-malo-knf-pyta-o-operacyjna-odpornosc-cyfrowa-banku/

2. Backup jest? To za mało. KNF zapyta, czy Bank potrafi się odtworzyć:
   https://premiumbank.zadbajobezpieczenstwo.pl/backup-jest-to-za-malo-knf-zapyta-czy-bank-potrafi-sie-odtworzyc-strategia-ciaglosci-dzialania-ict-po-ocenie-knf-ryzyka-ict-za-2025-r/

3. Skan to za mało. KNF zapyta, czy Bank naprawdę testuje odporność ICT:
   https://premiumbank.zadbajobezpieczenstwo.pl/skan-podatnosci-to-nie-test-odpornosci-knf-zapyta-czy-bank-naprawde-testuje-ict/

4. Jeden dostawca, wiele systemów, jedno duże ryzyko. KNF pyta o koncentrację ICT:
   https://premiumbank.zadbajobezpieczenstwo.pl/jeden-dostawca-wiele-systemow-jedno-duze-ryzyko-knf-pyta-o-koncentracje-ict/

5. Audyt ZDU — czy wiesz, kogo naprawdę powinien kontrolować Bank?:
   https://premiumbank.zadbajobezpieczenstwo.pl/audyt-zdu-w-banku-spoldzielczym-jak-kontrolowac-dostawcow-zewnetrznych-zgodnie-z-dora/

6. Zarząd musi wiedzieć. KNF zapyta, kto naprawdę nadzoruje ryzyko ICT w Banku:
   https://premiumbank.zadbajobezpieczenstwo.pl/raport-ict-do-zarzadu-knf-pyta-kto-nadzoruje-ryzyko-ict-w-banku/

7. Znalazłeś podatność? KNF zapyta, kiedy ją usunąłeś:
   https://premiumbank.zadbajobezpieczenstwo.pl/znalazles-podatnosc-knf-zapyta-kiedy-ja-usunales-zarzadzanie-podatnosciami-ict-po-ocenie-knf-ryzyka-ict-za-2025-r/

8. Masz procedury DORA? KNF zapyta: kiedy ostatnio naprawdę je przeczytałeś?:
   https://premiumbank.zadbajobezpieczenstwo.pl/coroczny-przeglad-dokumentacji-ict-dora-w-banku-spoldzielczym-po-ocenie-nadzorczej-knf-ryzyka-ict-za-2025-r/

9. DORA nie zna wymówki: pracownik nie miał czasu na szkolenie:
   https://premiumbank.zadbajobezpieczenstwo.pl/szkolenia-ict-dora-po-ocenie-knf-ryzyka-ict-za-2025-r-czy-bank-przeszkolil-wszystkich-czy-tylko-ma-plan-szkolenia/

10. Dokument jest? KNF zapyta o dowód, że działa:
    https://premiumbank.zadbajobezpieczenstwo.pl/dokument-jest-knf-zapyta-o-dowod-ze-dziala/

Zadzwoń lub napisz do Servus Comp, aby omówić temat.

• Strona główna: https://premiumbank.zadbajobezpieczenstwo.pl

Servus Comp Data Security, Świętokrzyska 12/403, 30-015 Kraków

tel. +48 608 407 668, +48 12 631 91 22 • biuro@servus-comp.pl

PODEJMIEMY DLA PAŃSTWA KAŻDE WYZWANIE!

JESTEŚ ZAINTERESOWANY? ZADZWOŃ, NAPISZ DO NAS

#Ransomware #RansomwareWBanku #BankSpółdzielczy #TestyStolikowe #TestyScenariuszowe #TestyOdporności #Cyberbezpieczeństwo #DORA #BIA #BCP #DRP #SOC #Backup #Odtwarzanie #RTO #RPO #ZDU #IncydentICT #CiągłośćDziałania #OdpornośćCyfrowa #ServusCompKraków