INCYDENT O 15:47. PREZES PYTA: „CO ROBIMY?” – KTO W BANKU ZNA ODPOWIEDŹ?

 

Jest 15:47.

SOC przekazuje informację o podejrzanej aktywności. IT widzi nietypowe zachowanie systemu. Część użytkowników zgłasza problemy z dostępem.

Kilka minut później Prezes pyta:

„Co robimy?”

To nie jest moment na szukanie procedury, ustalanie numerów telefonów ani zastanawianie się, kto powinien podjąć decyzję.

W pierwszej godzinie poważnego incydentu ICT liczą się przede wszystkim:

role, decyzje, eskalacja, informacja i czas.

DORA wzmacnia znaczenie uporządkowanego zarządzania incydentami ICT, dlatego bank powinien nie tylko posiadać procedurę, ale również wiedzieć, czy potrafi zastosować ją w praktyce.

Pierwsze minuty – czy to już incydent?

Nie każde zdarzenie techniczne oznacza poważny incydent.

Pierwszym zadaniem jest szybkie ustalenie:

• co się wydarzyło,
• kiedy pojawił się pierwszy sygnał,
• które systemy są objęte zdarzeniem,
• czy problem się rozszerza,
• czy istnieje zagrożenie dla danych,
• czy zdarzenie wpływa na procesy banku.

Bank powinien mieć jasno określone kryteria, kiedy zdarzenie wymaga uruchomienia formalnej ścieżki reakcji.

Pierwsze 10 minut – kto koordynuje działania?

Jednym z największych zagrożeń podczas incydentu jest chaos organizacyjny.

SOC analizuje alert.

IT próbuje ograniczyć problem.

ABI potrzebuje informacji do oceny sytuacji.

Zarząd oczekuje odpowiedzi.

Dostawca może prowadzić własną diagnostykę.

Dlatego od początku powinno być wiadomo:

kto koordynuje działania i kto odpowiada za wspólny obraz sytuacji.

Bez tego kilka zespołów może działać jednocześnie, ale nikt nie będzie wiedział, jaki jest faktyczny status incydentu.

Rola SOC – alert to dopiero początek

SOC powinien dostarczyć bankowi konkretnych informacji:

• co zostało wykryte,
• na jakim systemie,
• jakie są wskaźniki kompromitacji,
• czy aktywność nadal trwa,
• jaka jest skala zdarzenia,
• jakie działania rekomenduje SOC.

Sam alert techniczny jednak nie wystarczy.

Bank musi ustalić także:

jaki proces biznesowy może zostać dotknięty.

Właśnie tutaj istotne znaczenie ma BIA i znajomość krytycznych systemów.

Rola IT i ASI – ograniczyć skutki, ale zachować dowody

Pierwszą reakcją techniczną może być:

• izolacja urządzenia,
• blokada konta,
• ograniczenie komunikacji,
• zatrzymanie określonej usługi,
• zmiana konfiguracji,
• zablokowanie ruchu.

Działania powinny jednak być wykonywane świadomie.

Zbyt szybkie wyłączenie systemu może utrudnić analizę zdarzenia lub ograniczyć możliwość zebrania informacji potrzebnych do jego późniejszego wyjaśnienia.

Dlatego reakcja powinna łączyć:

ograniczenie skutków + zabezpieczenie informacji o zdarzeniu.

Rola ABI – koordynacja, nadzór i eskalacja

ABI powinien możliwie szybko posiadać obraz:

• co się wydarzyło,
• jaka jest skala zdarzenia,
• jakie procesy są zagrożone,
• jakie działania wykonano,
• jakie decyzje są potrzebne,
• czy incydent wymaga eskalacji do Zarządu.

Istotnym zadaniem jest także dokumentowanie przebiegu zdarzenia.

Po zakończeniu incydentu bank powinien móc odtworzyć:

kto, kiedy i na podstawie jakiej informacji podjął konkretną decyzję.

Kiedy uruchomić ZDU?

Jeżeli incydent dotyczy systemu lub usługi dostarczanej zewnętrznie, nie należy czekać z kontaktem do momentu pełnego potwierdzenia przyczyny.

Bank powinien wiedzieć:

• kiedy uruchomić ścieżkę eskalacyjną,
• kto kontaktuje dostawcę,
• jakiego kanału użyć,
• jak szybko dostawca powinien odpowiedzieć,
• jakich informacji oczekuje bank.

Najważniejsze jest uzyskanie odpowiedzi:

czy dostawca widzi problem i jaki jest przewidywany wpływ na usługę.

BIA podczas incydentu – co jest naprawdę zagrożone?

Incydent techniczny może wyglądać poważnie, ale jego rzeczywisty wpływ zależy od procesów, których dotyczy.

BIA pomaga szybko ustalić:

• który proces jest zagrożony,
• jak długo może pozostawać niedostępny,
• jakie systemy wspierają proces,
• czy istnieje rozwiązanie alternatywne,
• kiedy należy rozpocząć działania odtworzeniowe.

Dzięki temu bank nie reaguje wyłącznie na techniczny severity zdarzenia, ale również na jego rzeczywisty wpływ biznesowy.

Jakiej informacji potrzebuje Zarząd?

Zarząd nie potrzebuje kilkunastu stron logów.

Potrzebuje krótkiego i wiarygodnego obrazu sytuacji:

Co się wydarzyło?
Co jest zagrożone?
Co już zrobiono?
Jakie decyzje są potrzebne?
Co może wydarzyć się w najbliższym czasie?

Dobry komunikat powinien być krótki i jednoznaczny.

Przykład:

Wykryto podejrzaną aktywność na systemie wspierającym proces X. System został odizolowany. SOC analizuje skalę zdarzenia. Proces działa obecnie w trybie ograniczonym. Nie potwierdzono utraty danych. Kolejna aktualizacja za 30 minut.

To jest informacja, na podstawie której Zarząd może podejmować decyzje.

Komunikacja – kto mówi, co i do kogo?

Podczas incydentu komunikacja jest równie ważna jak działania techniczne.

Należy ustalić:

• kto informuje pracowników,
• kto komunikuje się z klientami,
• kto odpowiada za kontakt z ZDU,
• kto przekazuje informacje regulatorowi,
• kto może kontaktować się z mediami.

Niekoordynowana komunikacja może pogłębić skutki incydentu.

Dlatego podstawowa zasada powinna brzmieć:

informacja musi być potwierdzona, spójna i przekazywana przez właściwą rolę.

Pierwsza godzina powinna zakończyć się konkretnym statusem

Po pierwszej godzinie bank powinien mieć jasno określone:

• aktualny status zdarzenia,
• zakres dotkniętych systemów,
• wpływ na procesy,
• wykonane działania,
• otwarte ryzyka,
• decyzje Zarządu,
• zadania i właścicieli,
• termin kolejnej aktualizacji.

Pierwsza godzina nie musi zakończyć incydentu.

Powinna jednak zakończyć chaos informacyjny i decyzyjny.

Podsumowanie

Największym zagrożeniem podczas incydentu nie zawsze jest sam atak.

Czasami jest nim brak odpowiedzi na proste pytania:

Kto decyduje?
Kto koordynuje?
Kto informuje Zarząd?
Kiedy uruchamiamy ZDU?
Kto komunikuje się na zewnątrz?

Dlatego gotowość banku do reagowania na incydent nie powinna być oceniana wyłącznie na podstawie procedury.

Najlepszym sprawdzianem jest praktyczny scenariusz:

alert → potwierdzenie → eskalacja → decyzja → działanie → komunikacja → status → dowód

Pytania i odpowiedzi

Co bank powinien zrobić w pierwszych minutach incydentu ICT?

Powinien potwierdzić zdarzenie, ustalić jego skalę, zabezpieczyć informacje, wyznaczyć koordynatora i rozpocząć działania ograniczające skutki.

Kto powinien koordynować poważny incydent?

Bank powinien wcześniej określić rolę koordynatora. Najważniejsze jest, aby jedna osoba lub funkcja posiadała wspólny obraz sytuacji i koordynowała informacje między SOC, IT, ABI, ZDU i Zarządem.

Kiedy należy poinformować Zarząd?

Gdy zdarzenie może wpływać na procesy krytyczne, klientów, dane, ciągłość działania lub wymaga decyzji wykraczających poza kompetencje operacyjne.

Jaką rolę pełni SOC podczas incydentu?

SOC identyfikuje zdarzenie, analizuje jego charakter i skalę, dostarcza dane techniczne oraz rekomenduje działania. Bank powinien jednak połączyć tę informację z wpływem biznesowym.

Kiedy należy kontaktować ZDU?

Gdy zdarzenie dotyczy usługi lub systemu pozostającego pod kontrolą dostawcy albo gdy jego wsparcie jest niezbędne do diagnostyki i przywrócenia działania.

Dlaczego BIA jest ważna podczas incydentu?

Pozwala szybko ustalić, które procesy są zagrożone, jak długo mogą pozostawać niedostępne i jakie działania powinny mieć najwyższy priorytet.

Jak sprawdzić, czy procedura incydentowa działa?

Najlepiej poprzez test stolikowy lub scenariuszowy, który wymusza rzeczywiste decyzje i sprawdza ścieżki eskalacji, komunikacji oraz współpracy między rolami.

Czy Twój bank wie, co zrobić w pierwszej godzinie poważnego incydentu?

Jeżeli chcesz zweryfikować, czy procedura reakcji na incydenty, SOC, IT, ABI, BIA, ZDU i Zarząd tworzą jeden sprawny model działania, skontaktuj się bezpośrednio ze specjalistami Servus Comp Kraków.

Pomagamy bankom spółdzielczym w:

• budowie i weryfikacji procedur incydentowych,
• przygotowaniu scenariuszy testowych,
• organizacji współpracy SOC–IT–ABI,
• definiowaniu ścieżek eskalacji,
• analizie wpływu incydentu na procesy,
• przygotowaniu komunikacji awaryjnej,
• testowaniu współpracy z ZDU,
• dokumentowaniu decyzji i dowodów,
• przygotowaniu raportów dla Zarządu.

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

Sprawdzamy nie tylko to, co bank ma. Sprawdzamy, czy to naprawdę działa.

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

#IncydentICT #BankSpółdzielczy #Cyberincydent #ReakcjaNaIncydent #SOC #ABI #ASI #IT #ZarządBanku #BIA #ZDU #Cyberbezpieczeństwo #EskalacjaIncydentu #KomunikacjaKryzysowa #OdpornośćCyfrowa #DORA #ZarządzanieIncydentami #CiągłośćDziałania #ServusCompKraków