ZBP (PolishAPI) publikuje rekomendacje ws. bezpieczeństwa dla banków oraz TPP. Jakie wymagania stawia sektorowi?

Grupa robocza ds. PolishAPI przy Związku Banków Polskich opracowała i opublikowała niedawno bardzo wartościowy dokument „PolishAPI. Rekomendacje dotyczące obszaru bezpieczeństwa dla podmiotów korzystających ze standardu”. Choć odnosi się on zasadniczo do standardu stosowanego przez większość banków w Polsce, to wiele z zasad jest na tyle uniwersalnych, że spokojnie można je zastosować w działalności na innych standardach. Co istotne, rekomendacje mogą być stosowane zarówno przez banki, jak i Third Party Providers (TPP – do których zaliczamy także działające w tej „formule” banki) co jeszcze bardziej zwiększa jego użyteczność. Kwestia bezpieczeństwa to także istotny element oceny przy ubieganiu się o stosowne zezwolenie KNF, a zaproponowane przez ZBP rekomendacje śmiało można zastosować również na te potrzeby (dostrzegając oczywiście pewne różnice w stosunku do Rekomendacji D KNF). W kolejnych artykułach przybliżę wszystkie elementy dokument, dzisiaj zaczynając od wymagań organizacyjnych i procesowych, które jednak również wymagają podzielenia na przynajmniej dwa artykuły. Zaczynamy! Na marginesie chciałbym tylko zaznaczyć, że moja analiza wykracza poza dość ogólne ramy rekomendacji.

Dla przypomnienia – standard Polish API został opracowany jako standard dla specjalnych interfejsów dostępowych, do których wdrożenia zobowiązane są banki na 14 września (oczywiście dopuszczalne jest „otworzenie” interfejsu dostępnego dla klientów – więcej w serii artykułów pod tym adresem). Rozwiązanie zaproponowane przez Związek Banków Polskich bazuje na wytycznych stosowanych przez standardy międzynarodowe, co ułatwia ewentualną integrację podmiotom spoza Polski.

Polityka bezpieczeństwa jako punkt wyjścia

Podstawowym dokumentem, na którym de facto zasadzają się wszystkie szczegółowe procedury i procesy bezpieczeństwa jest polityka. Jest to zwykle dość ogólny „zestaw” zadań i zasad odpowiedzialności za poszczególne obszary bezpieczeństwa (pokrywa się to z rekomendacją 18 KNF). Taka polityka powinna być przyjmowana i aktualizowana przez zarząd (oraz radę nadzorczą), a także podlegać musi regularnemu przeglądowi, w którym uczestniczyć powinny nie tylko komórki stricte operacyjne, ale również funkcje kontroli wewnętrznej (compliance, ryzyko, audyt).

Taka polityka powinna wskazywać na wszystkie obszary, które są istotne chociażby z punktu widzenia wytycznych Europejskiego Urzędu Nadzoru Bankowego EBA w sprawie ryzyk operacyjnych i bezpieczeństwa. Powinna ona również określać „podstawowe” jednostki odpowiedzialne za jej wdrażanie na różnych poziomach organizacji (oraz monitorowanie tej implementacji). Istotnym elementem jest określenie zasad bezpieczeństwa informacji (w tym zapewnienie integralności), określenie (nie)dostępności określonych danych i ich rodzajów czy też odpowiedzialność osób zatrudnionych za bezpieczeństwo informacji. Polityka powinna również określać zasady jej rozpowszechniania i szkolenia pracowników.

W aspekcie świadczenia usług inicjowania płatności (Payment Initation Service – PIS) oraz dostępu do informacji o rachunku (Account Information Service) ma to szczególne znaczenie, ponieważ zarówno Rozporządzenie 2018/389 (art. 35 oraz 36), jak i ustawa o usługach płatniczych (art. 59r oraz 59s) nakładają szczególne obowiązki w tym zakresie na banki, jak i TPP. O zabezpieczeniu indywidualnych danych uwierzytelniających chyba nie ma co wspominać (art. 22-27 Rozporządzenia 2018/389).

Na marginesie warto zwrócić uwagę, że projekt rozporządzenia w sprawie warunków organizacyjnych i technicznych dla podmiotów świadczących usługi z zakresu cyberbezpieczeństwa oraz wewnętrznych struktur organizacyjnych operatorów usług kluczowych odpowiedzialnych za cyberbezpieczeństwo również stawia w tym zakresie pewne wymagania.

Organizacja bezpieczeństwa informacji

Na dużym poziomie ogólności ta rekomendacja wskazuje, że podmiot powinien wdrożyć odpowiednie polityki dotyczące zarządzania bezpieczeństwem informacji oraz wymianą informacji z podmiotami zewnętrznymi (zarówno TPP versus bank, jak i dostawcy funkcji krytycznych w ramach outsourcingu – więcej w tym artykule). Co to oznacza w praktyce? Wdrożenie odpowiednich procedur i regulaminów wewnętrznych, które definiować będą podstawowe zasady w zakresie:

  1. Zarządzania dostępem do informacji (w tym w szczególności wrażliwymi, tj. objętymi tajemnicą bankową lub zawodową) – tutaj istotne będzie wyraźne określenie zasad przyznawania dostępów na różnych poziomach „poufności” a także ograniczanie tego dostępu do minimum;
  2. Monitorowania i zarządzania incydentami operacyjnymi (tutaj znaczenie mają wytyczne EBA w sprawie incydentów oraz komunikat KNF w tej sprawie, który opisałem tutaj) – ważny jest tutaj przepływ (flow) informacji, tak aby zarządzić incydentem operacyjnym bez szkody dla użytkowników oraz TPP (warto tutaj zwrócić uwagę na art. 33 ust. 2 Rozporządzenia 2018/389 w kontekście środków awaryjnych i zasad komunikacji);
  3. Współpracy i komunikacji z nadzorcą – jest to zasadniczo pokryte w punkcie drugim, który odnosi się również do zgłaszania incydentów i informowania KNF o postępach w ich usuwaniu;
  4. Zarządzania umowami o zachowaniu poufności (tutaj niezwykle istotna będzie rola komórek compliance, co będzie zgodne zarazem z rekomendacją H KNF). Dostawca powinien prowadzić stosowny rejestr takich umów i przeprowadzać ich regularny przegląd;
  5. Regularnych audytów, w tym audytów zewnętrznych, o których mowa w art. 3 Rozporządzenia 2018/389 (w kontekście stosowania wyłączenia z art. 18 tego rozporządzenia).

Rekomendacja grupy ds. PolishAPI wskazuje również na konieczność wdrożenia odpowiednich rozwiązań w zakresie autoryzacji „nowych środków przetwarzania informacji wprowadzanych do użycia”, co rozumiem jako określenie zasad certyfikacji infrastruktury technicznej, w tym sieci (zamkniętej lub otwartej), która może być wykorzystywana do przetwarzania danych. Rozciąga się to również na wymogi w zakresie outsourcingu (w tym cloud computing – więcej o chmurze w bankowości w tym artykule).

Zresztą w zakresie zarządzania relacjami z zewnętrznymi dostawcami mamy rekomendację nr 3, która zobowiązuje do wdrożenia polityki (i odpowiednich procedur) outsourcingu. Nie będę tutaj się rozwodził nad zakresem takiej polityki, bo to zupełnie odrębny temat (m.in. o polityce outsourcingu w kontekście najnowszych wytycznych EBA będzie można niedługo przeczytać w Lex Banki). Ważne z punktu widzenia PolishAPI jest jednak to, aby polityka „zachęcała” do nawiązywania relacji z takimi podmiotami, które stosują się do standardu.

Zarządzanie aktywami (technologicznymi)

To bardzo ważny element (który jest poruszany również w kontekście obecnego i projektowanego rozporządzenia w sprawie sposobu tworzenia, utrwalania, przekazywania, przechowywania i zabezpieczania dokumentów związanych z czynnościami bankowymi, sporządzanych na elektronicznych nośnikach informacji (czyli „popularnego” art. 7 – tutaj warto zwrócić uwagę, że projekt dopuszcza stosowanie technologii blockchain). Warto już teraz przeprowadzić audyt procedur i procesów w tym zakresie. Generalnie chodzi o stworzenie odpowiednich zasad (procesów) pozwalających na prawidłowe inwentaryzowanie posiadanych zasobów teleinformatycznych, w tym nośników danych (czyli znowu ww. rozporządzenie). Oznacza to, że podmiot powinien:

  1. Określić własność poszczególnych aktywów oraz dopuszczalny czas eksploatacji;
  2. Wskazać jakie dane powinny być przechowywane na konkretnych nośnikach danych;
  3. Zdefiniować zasady i okresy regularnych przeglądów;
  4. Wprowadzić zasady fizycznego zabezpieczenia nośników danych oraz całej infrastruktury (np. wydzielone pomieszczenia, ograniczenia dostępu);
  5. Tworzyć kopie bezpieczeństwa;
  6. Określić zasady kontroli i monitorowania dostępu, a także bezpiecznego niszczenia danych;
  7. Wskazać zasady dokumentowania wszystkich zdarzeń dotyczących punktów 1-6.

To oczywiście w dużym skrócie, bo te zasady – wykraczające już poza dość ogólną politykę – powinny zostać dokładnie opisane w stosownych procedurach oraz regulaminach (tutaj niezwykle istotne będzie przypisanie odpowiedzialności oraz eskalacji.

Na dziś to tyle

W kolejnym artykule przejdziemy przez kolejne rekomendacje w zakresie organizacji wewnętrznej i być może zahaczymy już o wymogi dla samej infrastruktury.

 

 

 

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *