[PORADNIK] Jak instytucja płatnicza powinna dbać o bezpieczeństwo? 12 procedur, które pozwalają spać spokojnie

Kilka dni temu popełniliśmy ogólną publikację Fala wycieków danych. Jak fintechy powinny się zabezpieczać? Dziś przedstawiamy bardziej profesjonalne opracowanie, które każda Krajowa Instytucja Płatnicza powinna mieć w małym palcu. Ale… czy w rutynie dnia codziennego ma na pewno?

Prowadzenie krajowej instytucji płatniczej oznacza dziś znacznie więcej niż zabezpieczenie serwerów, włączenie dwuskładnikowego uwierzytelniania i wykonanie raz w roku testu penetracyjnego. Bezpieczeństwo KIP jest całym systemem organizacyjnym, który musi obejmować technologię, ludzi, dostawców zewnętrznych, środki klientów, sposób reagowania na incydenty, ciągłość działania oraz kontrolę tego, czy przyjęte zabezpieczenia rzeczywiście działają.

Co istotne, nie jest to wyłącznie kwestia dobrych praktyk. Ustawa o usługach płatniczych bardzo konkretnie wymaga od KIP posiadania systemu zarządzania ryzykiem i kontroli wewnętrznej, procedur identyfikowania i ograniczania ryzyka, strategii bezpieczeństwa, zasad ochrony szczególnie chronionych danych dotyczących płatności, procedur dotyczących incydentów oraz planów ciągłości działania. Od 17 stycznia 2025 roku dochodzi do tego DORA, czyli unijne rozporządzenie dotyczące operacyjnej odporności cyfrowej sektora finansowego.

W praktyce oznacza to, że krajowa instytucja płatnicza powinna być przygotowana nie tylko na pytanie „jak zabezpieczamy system?”, ale również: kto odpowiada za dane ryzyko, kto może podjąć decyzję podczas awarii, kiedy należy poinformować KNF, kiedy UODO, kto może odłączyć produkcję, jak szybko można odtworzyć system, jakie systemy są krytyczne i co stanie się w przypadku awarii dostawcy, od którego zależy połowa infrastruktury.

Dobrze poukładana KIP powinna posiadać więc nie jedną „politykę bezpieczeństwa”, ale cały zestaw powiązanych ze sobą procedur.

1. Procedura zarządzania ryzykiem ICT – dokument nadrzędny

Punktem wyjścia powinien być system zarządzania ryzykiem, a nie lista zabezpieczeń technicznych. Ustawa o usługach płatniczych wymaga procedur identyfikacji ryzyka, jego pomiaru, szacowania, monitorowania, raportowania oraz ograniczania. DORA rozszerza ten model szczególnie w zakresie ryzyka ICT.

KIP powinna więc posiadać przynajmniej:

• rejestr ryzyk, zawierający zidentyfikowane zagrożenia, ich prawdopodobieństwo, potencjalny wpływ i zastosowane zabezpieczenia,
• zasady okresowej oceny ryzyka,
• metodologię oceny prawdopodobieństwa i skutków,
• przypisanie właściciela każdego istotnego ryzyka,
• określenie poziomu akceptowalnego ryzyka,
• sposób eskalowania ryzyka do zarządu,
• procedurę ponownej oceny po istotnej zmianie systemu, wdrożeniu nowej usługi lub wystąpieniu incydentu.

Nie wystarczy więc stwierdzenie, że „ryzyko wycieku danych jest niskie”. Powinno być wiadomo dlaczego uznano je za niskie, jakie zabezpieczenia obniżają ryzyko oraz kto zaakceptował ryzyko rezydualne.

2. Zarząd musi wiedzieć, za co odpowiada

Jedną z najważniejszych zmian wynikających z DORA jest wyraźne przeniesienie odpowiedzialności za odporność cyfrową na poziom organu zarządzającego. Cyberbezpieczeństwo nie może być tematem, którym „zajmuje się informatyk”.

Zarząd powinien zatwierdzać kluczowe elementy systemu zarządzania ryzykiem ICT, znać najważniejsze zagrożenia i otrzymywać cykliczne raporty dotyczące bezpieczeństwa. W praktyce warto stworzyć formalną matrycę odpowiedzialności, która odpowiada między innymi na pytania:

• kto odpowiada za bezpieczeństwo ICT,
• kto zarządza incydentem,
• kto klasyfikuje incydent jako poważny,
• kto zgłasza go do KNF,
• kto odpowiada za ciągłość działania,
• kto zarządza dostawcami ICT,
• kto akceptuje ryzyka,
• kto odpowiada za ochronę danych osobowych,
• kto odpowiada za fraud i bezpieczeństwo transakcji,
• kto podejmuje decyzję o odłączeniu systemu lub uruchomieniu środowiska awaryjnego.

Najgorszym momentem na ustalanie odpowiedzialności jest chwila, w której trwa już cyberatak.

3. Rejestr systemów, danych i zależności

Nie można chronić czegoś, o czym organizacja nie wie, że istnieje. KIP powinna posiadać aktualną inwentaryzację swoich zasobów ICT oraz wiedzieć, które z nich wspierają funkcje krytyczne lub istotne.

Taki rejestr powinien obejmować między innymi:

• serwery i maszyny wirtualne,
• bazy danych,
• aplikacje,
• systemy transakcyjne,
• panele administracyjne,
• repozytoria kodu,
• urządzenia pracowników,
• systemy kopii zapasowych,
• interfejsy API,
• systemy KYC i AML,
• narzędzia antyfraudowe,
• systemy księgowe i rozliczeniowe,
• systemy komunikacji,
• usługi chmurowe,
• zewnętrznych dostawców ICT.

Równolegle warto prowadzić klasyfikację danych. Dokument KYC zawierający skan dowodu osobistego nie powinien być traktowany tak samo jak publiczny materiał marketingowy. Szczególnie chronione dane dotyczące płatności powinny posiadać jasno określone zasady dostępu, przechowywania, monitorowania i śledzenia.

4. Procedura zarządzania dostępami

To jedna z najważniejszych procedur w całej organizacji. Każdy dostęp powinien mieć właściciela, uzasadnienie oraz datę nadania.

W praktyce procedura powinna regulować:

• zakładanie kont pracownikom,
• nadawanie i zmianę uprawnień,
• zasadę najmniejszych uprawnień,
• dostęp administratorów,
• dostęp do produkcyjnych baz danych,
• uwierzytelnianie wieloskładnikowe,
• wykorzystanie kont technicznych,
• zasady przechowywania sekretów i kluczy API,
• cykliczne przeglądy dostępów,
• odebranie dostępów po zmianie stanowiska lub zakończeniu współpracy,
• dostęp pracowników zewnętrznych i dostawców.

Szczególnie ważne jest rozdzielenie zwykłego konta pracownika od kont administracyjnych. Administrator nie powinien przez cały dzień pracować na koncie posiadającym możliwość wykonania najbardziej krytycznych operacji.

Dobrym standardem jest także regularna recertyfikacja uprawnień. Kierownik albo właściciel systemu powinien okresowo potwierdzać, że dana osoba nadal potrzebuje określonego dostępu.

5. Bezpieczeństwo aplikacji i zarządzanie zmianą

Fintech rozwija oprogramowanie bardzo szybko, dlatego sama bezpieczna konfiguracja istniejącego środowiska nie wystarczy. Każda kolejna aktualizacja może wprowadzić nową podatność.

Procedura zarządzania zmianą powinna określać między innymi:

• kto może zatwierdzić wdrożenie na produkcję,
• w jaki sposób testowany jest kod,
• jakie testy bezpieczeństwa wykonywane są przed wdrożeniem,
• kto dokonuje code review,
• w jaki sposób kontrolowane są wykorzystywane biblioteki,
• jak przechowywane są hasła, sekrety i klucze API,
• jak oddzielone są środowiska DEV, TEST i PROD,
• kiedy zmiana wymaga dodatkowej analizy ryzyka,
• jak wygląda procedura awaryjnego wycofania wdrożenia.

Developer nie powinien móc bez kontroli zmienić kodu, wdrożyć go na produkcję, zmodyfikować bazy danych i później samodzielnie zatwierdzić prawidłowości całej operacji.

Tam, gdzie jest to uzasadnione skalą organizacji, należy stosować rozdział obowiązków i zasadę czterech oczu.

6. Zarządzanie podatnościami i aktualizacjami

Powinna istnieć formalna procedura określająca, co dzieje się po wykryciu podatności. Samo posiadanie skanera podatności niewiele daje, jeżeli nikt nie odpowiada za wyniki skanowania.

W procedurze warto określić klasy podatności oraz maksymalne czasy reakcji, przykładowo dla podatności krytycznych, wysokich, średnich i niskich. Osobno należy uregulować postępowanie w przypadku aktywnie wykorzystywanej podatności typu zero-day, ponieważ w takim przypadku standardowy miesięczny cykl aktualizacji może być zdecydowanie zbyt wolny.

KIP powinna prowadzić również ewidencję wykrytych podatności i sposobu ich usunięcia. Podczas kontroli znacznie lepiej wygląda bowiem system, w którym można pokazać: „podatność wykryta 4 maja, zaklasyfikowana jako wysoka, poprawka 5 maja, ponowny test 6 maja”, niż zapewnienie administratora, że „aktualizujemy wszystko na bieżąco”.

7. Logowanie i monitoring

Rozporządzenie 2018/389 dotyczące między innymi silnego uwierzytelniania wymaga zapewnienia identyfikowalności transakcji i interakcji związanych z usługami płatniczymi. DORA dodatkowo wymaga mechanizmów umożliwiających wykrywanie anomalii i incydentów ICT.

Dlatego procedura logowania powinna określać:

• jakie zdarzenia są rejestrowane,
• przez jaki czas przechowywane są logi,
• kto posiada do nich dostęp,
• jak chronione są przed modyfikacją,
• jak synchronizowany jest czas pomiędzy systemami,
• jakie zdarzenia generują alarm,
• kto analizuje alerty,
• jakie działania są podejmowane po wykryciu anomalii.

Log powinien pozwolić odtworzyć przebieg zdarzenia po fakcie. Jeżeli po incydencie nie można ustalić kto, kiedy, z jakiego adresu i za pomocą jakiego konta wykonał operację, system kontroli ma istotną lukę.

8. Procedura antyfraudowa i monitorowania transakcji

W przypadku dostawców świadczących określone elektroniczne usługi płatnicze szczególne znaczenie ma rozporządzenie 2018/389. Wymaga ono stosowania mechanizmów monitorowania transakcji umożliwiających wykrywanie transakcji nieautoryzowanych lub oszukańczych.

System powinien uwzględniać między innymi:

• nietypową wartość transakcji,
• nietypowe zachowanie użytkownika,
• znane scenariusze oszustw,
• podejrzane urządzenia,
• sygnały mogące wskazywać na obecność malware,
• historię poprzednich transakcji,
• nietypowe wykorzystanie instrumentu płatniczego.

KIP powinna mieć również jasno określone zasady stosowania SCA – silnego uwierzytelniania klienta, zasad korzystania z poszczególnych wyłączeń oraz, tam gdzie ma to zastosowanie, dynamicznego powiązania autoryzacji z kwotą transakcji i jej odbiorcą.

Nie wystarczy przy tym wdrożyć odpowiedniej technologii. Firma musi potrafić wykazać, dlaczego dana transakcja została wykonana bez SCA i z jakiego konkretnego wyłączenia skorzystano.

9. Procedura reagowania na incydenty

To dokument, który powinien być gotowy długo przed pierwszym poważnym atakiem. Ustawa o usługach płatniczych wymaga skutecznej procedury zarządzania incydentami, natomiast obecnie w przypadku KIP obowiązki raportowania poważnych incydentów ICT są bezpośrednio powiązane z systemem DORA.

Procedura powinna dokładnie opisywać kolejne etapy:

1. wykrycie incydentu,
2. rejestrację,
3. ocenę,
4. klasyfikację,
5. eskalację,
6. ograniczenie skutków,
7. zabezpieczenie dowodów,
8. usunięcie przyczyny,
9. przywrócenie działania,
10. komunikację,
11. raportowanie do organów,
12. analizę przyczyn źródłowych,
13. wdrożenie działań naprawczych.

Szczególnie ważna jest procedura klasyfikacji incydentu według DORA. Przy poważnym incydencie związanym z ICT pierwsze zawiadomienie powinno zostać przekazane tak szybko, jak to możliwe, ale co do zasady nie później niż w ciągu czterech godzin od sklasyfikowania incydentu jako poważny i nie później niż 24 godziny od momentu uzyskania wiedzy o incydencie. Następnie funkcjonuje raportowanie śródokresowe i końcowe.

Nie jest to dużo czasu. Dlatego formularzy, odpowiedzialności i kanału zgłoszenia nie powinno się poznawać dopiero podczas ataku ransomware.

10. Jedno zdarzenie może wymagać kilku niezależnych zgłoszeń

KIP powinna posiadać matrycę obowiązków notyfikacyjnych. Ten sam incydent może bowiem uruchomić kilka różnych reżimów prawnych.

Przykładowo włamanie do systemu zawierającego dane klientów może wymagać analizy pod kątem:

• DORA i zgłoszenia poważnego incydentu ICT,
• RODO i zawiadomienia Prezesa UODO,
• obowiązku poinformowania osób, których dane dotyczą,
• obowiązków względem klientów,
• obowiązków wobec partnerów i dostawców,
• ewentualnego zawiadomienia organów ścigania.

W przypadku RODO trzeba pamiętać o terminie do 72 godzin od stwierdzenia naruszenia, jeżeli spełnione są przesłanki wymagające zgłoszenia organowi nadzorczemu. Terminy DORA są inne. Dlatego procedura powinna działać jak checklista: zdarzenie X zostało zakwalifikowane w określony sposób – uruchamiamy ścieżki A, B i C.

11. Business Continuity i Disaster Recovery

Ustawa o usługach płatniczych wprost przewiduje konieczność posiadania rozwiązań zapewniających ciągłość działania, dokładnego określenia krytycznych operacji, planów awaryjnych oraz procedur ciągłości i przywracania sprawności ICT zgodnych z DORA.

KIP powinna więc odpowiedzieć sobie na bardzo konkretne pytania:

• które systemy są krytyczne,
• jak długo mogą być niedostępne,
• ile danych można maksymalnie utracić,
• gdzie znajdują się backupy,
• ile trwa ich odtworzenie,
• co stanie się przy utracie głównego centrum danych,
• co stanie się przy awarii operatora chmurowego,
• jak przedsiębiorstwo będzie realizować wypłaty,
• jak rozliczone zostaną transakcje rozpoczęte przed awarią,
• kto podejmuje decyzję o uruchomieniu systemu awaryjnego.

Dla poszczególnych funkcji należy ustalić RTO i RPO, czyli oczekiwany czas odtworzenia działania oraz dopuszczalny zakres utraty danych.

Same backupy nie są jeszcze procedurą ciągłości działania.

12. Backup trzeba odtwarzać, a nie tylko wykonywać

To szczególnie banalna zasada, która w praktyce nadal bywa ignorowana. DORA wymaga nie tylko posiadania systemów kopii zapasowych, ale również okresowego testowania procedur backupu, odtwarzania i odzyskiwania