BACKUP MÓWI „SUCCESS”. RANSOMWARE MÓWI „SPRAWDZAM”

Raport jest zielony.

SUCCESS.

Backup w banku wykonuje się codziennie, administrator nie widzi błędów, a Zarząd otrzymuje informację:

„Kopie zapasowe działają.”

A potem pojawia się ransomware.

I nagle pytanie nie brzmi już:

„Czy backup się wykonał?”

ale:

„Czy bank naprawdę potrafi odtworzyć krytyczne usługi i wrócić do działania?”

Bo wykonanie kopii zapasowej i rzeczywista zdolność odtworzenia to dwie zupełnie różne rzeczy.

Czy zielony status backupu naprawdę coś gwarantuje?

Nie.

Status „SUCCESS” potwierdza przede wszystkim wykonanie zadania backupowego.

Nie potwierdza natomiast:

• kompletności kopii,
• spójności danych,
• możliwości uruchomienia aplikacji,
• dostępności repozytorium,
• bezpieczeństwa kont administracyjnych,
• odporności kopii na ransomware,
• rzeczywistego czasu odtworzenia.

Dlatego znacznie ważniejsze pytanie brzmi:

Kiedy ostatnio bank rzeczywiście odtworzył krytyczną usługę z backupu?

Czy bank naprawdę osiąga RTO i RPO?

BIA może określać:

RTO = 4 godziny

i

RPO = 1 godzina

Ale są to wymagania.

Nie dowód.

Jeżeli pełne odtworzenie usługi podczas testu trwa 7 godzin, a BIA zakłada 4 godziny, bank posiada realną lukę odpornościową.

Warto więc porównywać:

RTO/RPO z BIA → rzeczywisty wynik testu → wykrytą różnicę → działanie naprawcze.

Czy ransomware może zniszczyć również backup?

Takie ryzyko istnieje.

Atakujący może próbować przejąć:

• konta administratorów,
• system zarządzający backupem,
• repozytoria kopii,
• mechanizmy replikacji,
• poświadczenia dostępowe.

Dlatego szczególne znaczenie mają kopie:

offline, odseparowane lub immutable.

Jeżeli atakujący może usunąć albo zaszyfrować wszystkie dostępne kopie, sam fakt wykonywania backupu nie zapewnia odporności.

Prawdziwy test zaczyna się od „RESTORE”

Najważniejszym dowodem nie jest raport z wykonania kopii.

Jest nim udane odtworzenie.

Warto testować różne poziomy:

• pojedynczy plik,
• bazę danych,
• system operacyjny,
• aplikację,
• pełną usługę biznesową.

To ostatnie daje bankowi najwięcej informacji.

Bo klient nie potrzebuje odzyskanego pliku backupowego.

Potrzebuje działającej usługi bankowej.

Czy bank zna właściwą kolejność odtwarzania?

Odtworzenie krytycznej usługi rzadko oznacza uruchomienie jednego serwera.

Może wymagać wcześniejszego przywrócenia:

• sieci,
• usług katalogowych,
• DNS,
• baz danych,
• uwierzytelniania,
• integracji,
• systemów wspierających,
• usług ZDU.

Dlatego BIA i mapa zależności ICT powinny odpowiadać nie tylko na pytanie:

„co odtwarzamy?”

ale również:

„w jakiej kolejności?”

Źle zaplanowana kolejność może całkowicie zniweczyć zakładane RTO.

Jaką informację powinien otrzymywać Zarząd?

Mało przydatna informacja:

„99,8% backupów zakończyło się sukcesem.”

Znacznie lepsza:

Ostatni test pełnego odtworzenia krytycznej usługi wykonano 12 sierpnia. Rzeczywisty czas odtworzenia wyniósł 3 godziny 42 minuty przy wymaganym RTO 4 godziny. Wykryto jedną lukę dotyczącą systemu uwierzytelniania. Działanie naprawcze jest w realizacji.

To jest informacja zarządcza.

Pokazuje:

wymaganie → test → wynik → luka → działanie.

5 pytań, które warto zadać IT już dziś

1. Kiedy ostatnio odtworzyliśmy pełną krytyczną usługę?
2. Czy osiągnęliśmy RTO i RPO wynikające z BIA?
3. Czy ransomware może uzyskać dostęp do naszych kopii?
4. Czy mamy kopię offline lub immutable?
5. Czy znamy dokładną kolejność odtwarzania systemów?

Jeżeli na któreś z nich odpowiedź brzmi:

„musimy sprawdzić”

– właśnie znaleziono temat do przetestowania przed prawdziwym incydentem.

Najdroższy test to ten wykonywany podczas ataku

Kontrolowany test może ujawnić:

• uszkodzoną kopię,
• brak hasła,
• brak dostępu administracyjnego,
• błędną instrukcję,
• zależność od innego systemu,
• zbyt długi restore,
• niespójność z BIA.

To cenna informacja.

Bo problem wykryty podczas ćwiczenia można poprawić.

Problem wykryty podczas ransomware staje się już problemem biznesowym banku.

Podsumowanie

Backup w banku nie powinien kończyć się na komunikacie:

SUCCESS.

Powinien kończyć się dowodem:

ODTWORZYLIŚMY → ZMIERZYLIŚMY → SPRAWDZILIŚMY → WYKRYLIŚMY LUKI → POPRAWILIŚMY → PRZETESTOWALIŚMY PONOWNIE

Dopiero wtedy można mówić o rzeczywistej zdolności odtworzeniowej.

Bo ransomware nie zapyta:

„Czy kopia została wykonana?”

Zapyta:

„Czy potraficie z niej wrócić do działania?”

Pytania i odpowiedzi

Czy status „backup success” oznacza, że bank jest bezpieczny?

Nie. Potwierdza wykonanie zadania backupowego, ale nie potwierdza skutecznego odtworzenia pełnej usługi.

Jak często bank powinien testować odtworzenie?

Częstotliwość powinna wynikać z krytyczności procesów, BIA, analizy ryzyka i programu testów banku.

Czy backup immutable chroni przed ransomware?

Znacząco ogranicza ryzyko modyfikacji lub usunięcia kopii, ale powinien być jednym z elementów szerszej strategii ochrony backupu.

Czy wystarczy odtworzyć pojedynczy plik?

Nie dla procesów krytycznych. Bank powinien potwierdzić możliwość przywrócenia całej usługi biznesowej.

Co zrobić, jeśli test nie osiąga RTO?

Ustalić przyczynę, przygotować działanie naprawcze, wyznaczyć właściciela i wykonać retest.

Co powinien otrzymywać Zarząd?

Nie tylko procent poprawnych backupów, ale przede wszystkim wynik ostatnich testów, osiągnięte RTO/RPO, wykryte luki i status działań naprawczych.

Czy Twój bank naprawdę potrafi się odtworzyć?

To warto sprawdzić zanim zrobi to ransomware.

Jeżeli chcesz zweryfikować, czy backup, BIA, RTO/RPO, repozytoria oraz procedury odtworzeniowe rzeczywiście pozwalają bankowi wrócić do działania, skontaktuj się bezpośrednio ze specjalistami Servus Comp Kraków.

Pomagamy bankom spółdzielczym w:

• ocenie środowiska backupowego,
• analizie zgodności RTO/RPO z BIA,
• projektowaniu testów odtworzeniowych,
• testach pełnych usług biznesowych,
• ocenie odporności backupu na ransomware,
• analizie kopii offline i immutable,
• weryfikacji kolejności odtwarzania,
• dokumentowaniu wyników testów,
• przygotowaniu raportowania dla Zarządu.

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

Backup mówi „SUCCESS”. Prawdziwy test zaczyna się dopiero przy „RESTORE”.

 

Polecane wpisy dla banków spółdzielczych

Zapraszamy również do zapoznania się z innymi materiałami przygotowanymi z myślą o Zarządach i pracownikach banków spółdzielczych, osobach odpowiedzialnych za bezpieczeństwo informacji, ICT, DORA, zgodność i zarządzanie ryzykiem.

1. 1. AUDYT ZA PARĘ SREBRNIKÓW CZY AUDYT, KTÓRY WYTRZYMA PYTANIA SOZ, KNF I BIEGŁEGO REWIDENTA?
   2. SOC nie widzi wszystkiego. Czy bank zna swoje ślepe punkty?
   3. Awaria już trwa – co bank odtwarza jako pierwsze i kto o tym decyduje?
   4. Zostałeś ABI. I co teraz?
   5. „ATAKUJĄ BANKI”. THREAT INTELLIGENCE OSTRZEGA – CO ROBI BANK?
   6. DORA, RTS, EBA, KNF – Jak nie pogubić się w wytycznych i wiedzieć, co naprawdę wdrożyć?
   7. Bank ma procedury. Audytor pyta: „proszę pokazać, że one działają”.
   8. Dostawca nie działa. Bank też. Czy tak miało być?
   9. Exit plan dostawcy a exit plan banku – czy strategia wyjścia naprawdę chroni interes banku?
   10. Umowa chroni dostawcę. A kto chroni bank?
   11. Backup mówi „SUCCESS”. Ransomware mówi „SPRAWDZAM”
   12. Podatność jest critical. Ale czy naprawdę jest najważniejsza?
   13. SOC widzi alert. Ale czy wie, co jest ważne dla banku?
   14. Prezesie, proszę pilnie zatwierdzić przelew. Głos brzmi dokładnie jak głos członka zarządu. To deepfake.
   15. Ocena ryzyka ICT przez KNF wypadła słabo. Co teraz?
   16. Ransomware w banku i inne kryzysy – testy stolikowe i scenariuszowe: czy bank naprawdę potrafi działać?
   17. INCYDENT O 15:47. PREZES PYTA: „CO ROBIMY?” – KTO W BANKU ZNA ODPOWIEDŹ?
   18. DORA I RTS bez BIA to nie wdrożenie. To chaos bez priorytetów.
   19. BIA w banku spółdzielczym – jak przygotować analizę krok po kroku?
   20. Zarząd pyta IT: „Czy jesteśmy bezpieczni?” – czy odpowiedź „tak” cokolwiek znaczy?
   21. PAM w banku spółdzielczym – JumpServer, DORA i kontrola dostępu uprzywilejowanego
   22. Bank bez systemu PAM? JumpServer – bezpłatna ochrona dostępu uprzywilejowanego dla banków spółdzielczych
   23. Skan to za mało. Jakie testy penetracyjne powinien zlecić bank spółdzielczy, żeby nie usłyszeć tego na audycie?
   24. Wysadzenie bankomatu to nie tylko szkoda. To test procedur Banku
   25. 10 wybranych najważniejszych zaleceń KNF po ocenie ryzyka ICT 2025 — praktyczne podsumowanie dla banków spółdzielczych
   26. Dokument jest? KNF zapyta o dowód, że działa
   27. Znalazłeś podatność? KNF zapyta, kiedy ją usunąłeś
   28. Raport ICT do Zarządu — KNF pyta, kto nadzoruje ryzyko ICT w Banku
   29. Jeden dostawca, wiele systemów, jedno duże ryzyko. KNF pyta o koncentrację ICT
   30. Skan podatności to nie test odporności. KNF zapyta, czy Bank naprawdę testuje ICT

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