#zostanwdomuzGBS: "Regulacje prawne dotyczące cyberbezpieczeństwa bankowego"

Kliknij, aby powiększyć

Regulacje prawne dotyczące cyberbezpieczeństwa bankowego

Członkowie zarządów banków powinni przyzwyczajać się do myśli, że cyberbezpieczeństwo dawno już przestało być wyłącznie domeną sektora IT. Konieczność transformacji cyfrowej, w połączeniu z rosnącą skalą cyberprzestępczości sprawia, że ryzyka operacyjne związane z tym obszarem urastają do głównych wyzwań nadchodzących lat.

W świecie cyberregulacji

W połowie lat dziewięćdziesiątych XX w. Bill Gates stwierdził, że usługi bankowe przetrwają, bo są niezbędne, ale ta sama zasada nie musi dotyczyć banków. Po upływie ponad dwudziestu lat banki nadal mają się nieźle i w dalszym ciągu tworzą fundament nowoczesnej gospodarki, jednakże rysy na ich pancerzu są coraz bardziej widoczne. Spośród ponad 3,5 mld użytkowników internetu coraz większa ich liczba dochodzi do wniosku, że tradycyjne usługi bankowe można w coraz łatwiejszy sposób zastąpić poprzez powstające jak grzyby po deszczu instytucje finansowe, realizujące wybrane funkcje bankowe za pomocą najnowszej technologii, ale bez zbędnych formalności, biurokracji i wizyt w oddziale. Mimo to wydaje się, że Bill Gates nie miał do końca racji, a w krajach takich jak Polska banki w dalszym ciągu cieszą się sporym zaufaniem. Jednakże warunkiem utrzymania tego zaufania jest konieczność prawidłowego zaadresowania jednego z podstawowych ryzyk operacyjnych XXI  w. – ryzyka cyberprzestępczości. Co ciekawe, wedle wielu zestawień, póki co to nie banki (czy też szerzej: instytucje finansowe) padają najczęściej ofiarą hackerów. Raport ERPScan obejmujący rok 2017 sytuuje sektor finansowy dopiero na trzeciej pozycji za branżą mediów i rozrywki, branżą informatyczną oraz administracją publiczną. Dziewięć procent wszystkich incydentów obejmuje banki (prawie połowa z tych incydentów), projekty związane z kryptowalutą (ok. 20%), firmy pożyczkowe (11%) oraz wiele innych podmiotów prowadzących działalność w innych obszarach tego sektora. Według innych źródeł to właśnie jednak banki są atakowane kilkaset razy bardziej intensywnie niż inne podmioty. Oczywiście nikt nie jest zainteresowany upowszechnianiem tych danych (w Wielkiej Brytanii spekuluje się, że nie więcej niż 15% incydentów jest ujawnianych publicznie), albowiem straty wizerunkowe mogą niejednokrotnie być równie bolesne jak straty finansowe.

O tym, że cyberzagrożenia są niezwykle realne, świadczyć może przypadek Centralnego Banku Bangladeszu. W lutym 2016 r. Amerykański Bank Rezerw Federalnych otrzymał od tegoż banku polecenie dokonania przelewów na łączną kwotę 1 mld dolarów. Pięć z łącznej liczby 55 poleceń, zostało zrealizowanych na łączną kwotę 101 mln dolarów. Pozostałe przelewy zostały zablokowane z uwagi na… błędy w poleceniach dokonania przelewów. Atak, dokonany przy wykorzystaniu programu Dridex, obnażył nie tylko braki w systemach informatycznych Banku Bangladeszu, ale także brak w owym czasie systemu antyfraudowego w Banku Rezerw Federalnych, który działałby w czasie rzeczywistym (transakcje sprawdzane były losowo już po dokonaniu przelewów). Pikanterii całej sytuacji dodaje fakt, że na rok przed całym wydarzeniem gubernator banku z  Bangladeszu, zdając sobie sprawę ze słabości posiadanej infrastruktury, zatrudnił jedną z  firm amerykańskich w celu zwiększenia odporności tych systemów na ataki cybernetyczne. Z uwagi na biurokrację i przewlekłe procesy wewnętrzne, firma ta mogła przystąpić do prac… dopiero po całym zdarzeniu.

John Chambers, twórca przedsiębiorstwa informatycznego Cisco Systems, Inc., zwykł mawiać, że istnieją jedynie dwa rodzaje przedsiębiorstw. Te, które już odkryły, że stały się przedmiotem ataku ze strony cyberprzestępców oraz takie, które co prawda zostały zaatakowane, ale jeszcze o tym nie wiedzą. Banki nie stanowią tu wyjątku, choć regulatorzy tego sektora od dawna przykładali ogromną wagę do zarządzania ryzykiem operacyjnym, którego częścią składową stał się obecnie narastający problem cyberprzestępczości.

Trójpak regulacyjny

Kwestia cyberbezpieczeństwa i wymogów z nim związanych coraz częściej jest przedmiotem regulacji prawnych. Dynamiczny rozwój technologii, a co za tym idzie – wzrost cyberzagrożeń dla obywateli, organizacji czy nawet całego państwa, stanowi nie lada wyzwanie dla ustawodawcy. Kwestia cyberbezpieczeństwa jest kwestią złożoną, dlatego uregulowania prawne tego obszaru to szereg tematycznie powiązanych ze sobą aktów prawnych, zarówno na poziomie unijnym, jak i krajowym.

Pierwsza rekomendacja dotycząca zarządzania obszarami technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego w bankach została wydana w  formie uchwały Komisji Nadzoru Bankowego już w grudniu 2002  r. Zastąpiona została obecnie obowiązującą Rekomendacją D, przyjętą uchwałą w  styczniu 2013 r. (tzw. Rekomendacja D). Rekomendacja ta, zeszłoroczna ustawa o Krajowym Systemie Cyberbezpieczeństwa (wraz z aktami wykonawczymi) oraz wprowadzona do polskiego porządku prawnego Dyrektywa PSD2 tworzą swoisty trójpak regulacyjny, wyznaczający ramy postępowania banków w obszarze cyberbezpieczeństwa.

Kwestia bezpieczeństwa teleinformatycznego nie może pozostawać w oderwaniu od bezpieczeństwa przetwarzania danych osobowych, w szczególności w sektorze bankowym, gdzie dane osobowe klientów banku stanowią jeden z kluczowym komponentów działalności banku. Przy zapewnieniu odpowiedniego poziomu cyberbezpieczeństwa w bankach należy zatem wziąć pod uwagę nie tylko regulacje wynikające z wyżej wskazanego trójpaku regulacyjnego, ale również przepisy Ogólnego Rozporządzenia o Ochronie Danych Osobowych (RODO) oraz Ustawy o ochronie danych osobowych z 10 maja 2018 r. 

Rekomendacja D – informacje ogólne

Rekomendacja D dotycząca zarządzania obszarami technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego w bankach została wydana w styczniu 2013 r. przez Komisję Nadzoru Bankowego w związku z koniecznością znowelizowania regulacji z 2002 r. Znowelizowany dokument przedstawia podejście komisji do technologii
informatycznych, które angażuje w spełnienie wymogów związanych z bezpieczeństwem teleinformatycznym nie tylko działy IT, ale również biznes, audyt wewnętrzny oraz departamenty prawne.

Rekomendacja D zawiera 22 rekomendacje i wskazuje bankom oczekiwania nadzorcze w następujących obszarach: (1) strategia i organizacja obszarów technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego, (2) rozwój środowiska IT, (3) utrzymanie i eksploatacja środowiska IT oraz (4) zarządzanie bezpieczeństwem środowiska IT. 

Rekomendacja D a banki spółdzielcze. Rekomendacja D powinna być stosowana przez wszystkie banki, w tym banki spółdzielcze. Jednak, jak KNF wyraźnie zaznacza, ogólną zasadą jest, że wdrożenie rekomendacji powinno uwzględnić skalę działalności oraz profil ryzyka banku. Inny będzie więc oczekiwany stopień zgodności z rekomendacjami w niewielkim banku spółdzielczym, a inny w dużym banku komercyjnym.

Rekomendacja D powyższą zasadę precyzuje w odniesieniu do banków spółdzielczych. Podkreśla się rolę banku zrzeszającego, który powinien wspierać proces wdrażania Rekomendacji D w danym banku spółdzielczym przy zastosowaniu zasady proporcjonalności. Co to oznacza? Zakres i  stopień przyjmowanych rozwiązań, które wynikają z Rekomendacji D, powinien wynikać ze skali działalności banku i dotychczas wykorzystywanych technologii informatycznych. Mniejsze banki, mniej zaawansowane technologicznie, nie muszą więc dostosowywać swojego środowiska IT do wymagań komisji na takim poziomie, jak w przypadku banków o szerszej skali działalności, w których technologie bankowe są dość zaawansowane.

Cyberbezpieczeństwo a Rekomendacja D

Wśród 22 rekomendacji znajdziemy takie, które wprost mówią o bezpośrednim zaangażowaniu rady nadzorczej oraz zarządu w obszar bezpieczeństwa teleinformatycznego. Rekomendacja D kładzie nacisk na sformalizowanie zasad w obszarze zarządzania obszarami IT i bezpieczeństwa systemów IT w bankach. Rekomendacje przewidują m.in., że banki powinny posiadać sformalizowane zasady prowadzenia projektów, zasady zarządzania danymi wykorzystywanymi w ramach prowadzonej działalności, zarządzania infrastrukturą teleinformatyczną czy współpracy z  zewnętrznymi dostawcami. Wyzwaniem dla banków mogą być wymagane przez komisję: zarządzanie jakością danych wykorzystywanych w ramach prowadzonej przez bank działalności (Rekomendacja 8), zarządzanie uprawnieniami do systemów IT (Rekomendacja 5 i 11) czy konieczność przeprowadzania regularnych, niezależnych audytów bezpieczeństwa (Rekomendacja 22).

Zarządzanie ryzykiem. Zarządzanie ryzykiem, podejście oparte na ryzyku, analiza ryzyka – to pojęcia i hasła, które w ostatnich latach nabrały ogromnego znaczenia, jeżeli mowa o bezpieczeństwie informatycznym. Rekomendacja D w obszarze oznaczonym jako zarządzanie bezpieczeństwem środowiska teleinformatycznego wskazuje, że w banku powinien funkcjonować sformalizowany, skuteczny system zarządzania bezpieczeństwem środowiska IT, który ma obejmować kontrolę, przeciwdziałanie, monitorowanie oraz raportowanie ryzyka w zakresie bezpieczeństwa IT. Co więcej, system dotyczący analizy ryzyka bezpieczeństwa IT powinien być zintegrowany z całościowym systemem zarządzania ryzykiem i bezpieczeństwem informacji w banku. Dobrą praktyką w tym zakresie jest oparcie systemu zarządzania bezpieczeństwem IT w  każdym banku na wewnętrznych procedurach, które będą zgodne z ogólną strategią bezpieczeństwa. Banki spółdzielcze powinny zatem posiadać przede wszystkim wdrożoną politykę bezpieczeństwa informacji. Rozważyć też można stosowanie międzynarodowych standardów w zakresie bezpieczeństwa informacji, takich jak normy ISO (z serii ISO/IEC 2700).

Incydenty na gruncie Rekomendacji D. Rekomendacja D w obszarze dotyczącym zarządzania bezpieczeństwem wskazuje również na kwestię zarządzania incydentami bezpieczeństwa, czyli m.in. w przypadku awarii, przeciążeń systemów, utraty danych, błędów ludzkich itd. Wewnętrzne regulacje banku w tym zakresie powinny określać w szczególności: metody i zakres zbierania informacji o incydentach (system zgłaszania, identyfikacja), zakres
odpowiedzialności personelu, rejestrowanie incydentów, analizę wpływu incydentów na środowisko IT, zasady kategoryzacji i priorytetyzacji incydentów, wyszukiwanie powiązań i zależności między incydentami oraz działania naprawcze i usuwanie przyczyn.

Rekomendacja D jest regulacją dość ogólną, niemniej jednak stanowi pewnego rodzaju „checklistę” ogólnych wytycznych w zakresie bezpieczeństwa IT w banku. Ogólność wytycznych Rekomendacji D powoduje również, że mimo iż rekomendacje uchwalone zostały ponad 6 lat temu, nadal pozostają aktualne oraz zgodne z wydawanymi w późniejszym czasie regulacjami, które również dotyczą kwestii cyberbezpieczeństwa, takimi jak Dyrektywa PSD2 czy ustawa o Krajowym Systemie Cyberbezpieczeństwa.

Ustawa o KSC

Ustawa o Krajowym Systemie Cybeberzpieczeństwa z 5 lipca 2018 r. („Ustawa o KSC”) jest odpowiedzią polskiego ustawodawcy na unijne regulacje w zakresie cyberbezpieczeństwa, czyli Dyrektywę NIS [1]. Ustawa o KSC wraz z towarzyszącymi aktami rangi rozporządzeń tworzy tzw.krajowy system bezpieczeństwa, czyli system, który ma na celu zagwarantowanie odporności systemów IT na działania naruszające poufność, integralność i autentyczność przetwarzanych danych lub związanych z nimi usług oferowanych przez systemy na poziomie krajowym („KSC”).

Mimo iż intuicyjnie wydawać się może, że krajowy system cyberbezpieczeństwa to domena podmiotów publicznych, Ustawie o KSC podlega cały szereg podmiotów, które ze względu na specyfikę swojej działalności, sektor czy rodzaj świadczonych usług zostały zakwalifikowane przez ustawodawcę do kategorii podmiotów tworzących KSC. Do wdrożenia wymogów związanych z cyberbezpieczeństwem zobowiązani są m.in. tzw. (1) operatorzy usług kluczowych (czyli usług kluczowych dla utrzymania krytycznej działalności społecznej lub gospodarczej, zgodnie z wykazem) oraz (2) dostawcy usług cyfrowych (dostawcy usług świadczonych drogą elektroniczną). W praktyce cały szereg przedsiębiorców jest obowiązany do wdrożenia wymogów przewidzianych przez Ustawę o KSC.

O tym, które podmioty będą uznawane za operatorów usług kluczowych, co ma znaczenie z punktu widzenia banków, decyduje wiele czynników. Zgodnie z Ustawą o KSC operatorem usług kluczowych będzie podmiot, który łącznie:

a) został wskazany (jako rodzaj podmiotu) w załączniku do Ustawy o KSC;
b) świadczy usługę kluczową określoną w rozporządzeniu do Ustawy o KSC [2];
c) świadczenie tej usługi zależy od systemów informacyjnych;
d) usługa jest świadczona powyżej określonego progu istotności – najczęściej jest to wielkość produkcji, zasięg geograficzny świadczenia usługi albo liczba odbiorców.

O uznaniu danego podmiotu za operatora usługi kluczowej zdecydują, kompetentne dla danego sektora, organy właściwe (w drodze decyzji administracyjnej). Banki krajowe znalazły się w wykazie podmiotów znajdującym się w załączniku nr 1 do ustawy jako podmioty działające w sektorze „bankowość i infrastruktura rynków finansowych”. Również w rozporządzeniu do Ustawy o KSC określono zarówno banki jako operatorów kluczowych oraz wskazano, które usługi świadczone przez banki są kluczowe. O finalnym zakwalifikowaniu do tej kategorii podmiotów KSC przesądza jednak decyzja administracyjna.

Usługi banku a KSC. Rozporządzenie do Ustawy o KSC wskazuje szereg usług świadczonych przez banki, które uznawane są za usługi kluczowe. W wykazie znalazło się wykonywanie przez bank takich czynności, jak np.:

1) przyjmowanie wkładów pieniężnych;
2) prowadzenie rachunków bankowych;
3) udzielanie kredytów i pożyczek pieniężnych;
4) dokonywanie obrotu papierami wartościowymi czy świadczenie usługi inicjowania transakcji płatniczej.

Z wykazu wskazanego w rozporządzeniu wynika, że działalność bankowa w bardzo szerokim zakresie traktowana jest jako kluczowa z punktu widzenia działalności społecznej lub gospodarczej.

Obowiązki w świetle KSC. Ustawa o KSC nakłada na banki będące operatorami usług kluczowych obowiązki dotyczące m.in.: szacowania ryzyka wystąpienia incydentu, stosowania właściwych środków bezpieczeństwa oraz obsługi i zarządzania incydentami.

Generalnym i podstawowym obowiązkiem w zakresie krajowego systemu cyberbezpieczeństwa jest wdrożenie systemu zarządzania bezpieczeństwem w systemie informatycznym wykorzystywanym do świadczenia usługi kluczowej. System zarządzania bezpieczeństwem IT w banku musi zapewniać:

• szacowanie ryzyka – prowadzenie systematycznego szacowania ryzyka wystąpienia incydentu, tj. zdarzenia, które ma lub może mieć niekorzystny wpływ na cyberbezpieczeństwo;
• zarządzanie ryzykiem;
• wdrożenie odpowiednich i proporcjonalnych do oszacowanego ryzyka środków organizacyjnych i technicznych (co ważne – z uwzględnieniem najnowszego stanu wiedzy);
• informacje o cyberzagrożeniach – system musi zbierać
  informacje o cyberzagrożeniach i podatnościach na incydenty;
• zarządzanie incydentami;
• zapobieganie i ograniczanie wpływu incydentów na bezpieczeństwo systemu;
• bezpieczną komunikację w ramach krajowego systemu cyberbezpieczeństwa.

Terminy. Obowiązki wynikające z Ustawy o KSC powinny być spełnione w określonych terminach. Biegną one od momentu otrzymania przez podmiot decyzji administracyjnej uznającej podmiot za operatora usługi kluczowej. Organizacja ma 3 miesiące na oszacowanie ryzyka dla swoich usług kluczowych, wdrożenie zarządzania incydentami, wyznaczenie osoby kontaktowej z właściwymi organami, przeszkolenie użytkowników, zgłoszenie incydentów poważnych oraz usuwanie wskazywanych podatności. Po 6 miesiącach organizacja musi wdrożyć odpowiednie środki bezpieczeństwa, aktywnie zbierać informacje o zagrożeniach i podatnościach, stosować środki zapobiegające i ograniczające wpływ incydentów na bezpieczeństwo systemu oraz stosować w pełnym zakresie wymaganą dokumentację.

Po roku od otrzymania decyzji podmiot ma obowiązek przeprowadzenia audytu oraz przekazania sprawozdania z tego audytu. Bank, wobec którego może zostać wydana decyzja
o  uznaniu go za operatora usług kluczowych, powinien zatem już teraz odpowiednio przygotować się do przyjęcia wymogów Ustawy o KSC – określając harmonogram i plan wdrożenia systemu cyberbezpieczeństwa banku, zgodnie z ustawowym zakresem i wymaganymi terminami.

Incydenty. Incydenty w świetle Ustawy o KSC dzielą się na incydenty poważne, krytyczne, istotne i zwykłe. Bank ma obowiązek klasyfikowania incydentów na podstawie progów wskazanych w rozporządzeniu do Ustawy o KSC. Zgłoszeniu do tzw. CSIRT (CSIRT MON, CSIRT GOV i CSIRT NASK to zespoły reagowania na incydenty na poziomie krajowym), i to w czasie 24 godzin od zaistnienia sytuacji, podlegają incydenty poważne.

Nakładanie się reżimów prawnych. Ustawa o KSC reguluje dość szczegółowo zakres i tryb zgłaszania incydentów, jak również szereg pozostałych obowiązków nałożonych na operatorów usług kluczowych (oraz dostawców usług cyfrowych). Co więcej – obowiązki, które na banki nakłada Ustawa o KSC, są nie lada wyzwaniem, w szczególności w świetle „nakładania się” na siebie różnych reżimów prawnych. Konieczność przeprowadzenia analizy ryzyka, stosowania adekwatnych środków bezpieczeństwa, obsługi i zgłaszania incydentów jest obowiązkiem zarówno na gruncie Ustawy o KSC, PSD2 i ustawy o usługach płatniczych, jak i RODO. Rekomendacja D również wskazuje na konieczność zarządzania incydentami bezpieczeństwa i  konieczność przeprowadzania analizy ryzyka. Sprostanie temu wyzwaniu i zapewnienie cyberbezpieczeństwa w banku na wszystkich frontach wymaga kompleksowego i przemyślanego działania. Wdrożenie systemu do zarządzania cyberbezpieczeństwem nie jest zadaniem jedynie technologicznym. Wymaga zaangażowania członków za rządu, osób odpowiedzialnych za kwestie bezpieczeństwa,
kwestie operacyjne, jak również wsparcia prawników.

PSD2

Celem pierwszej dyrektywy w sprawie usług płatniczych (PSD1), przyjętej w 2007 r. i wprowadzonej w życie w roku 2009, było utworzenie jednolitego rynku płatności w Unii Europejskiej, a także stworzenie podwalin dla jednolitego obszaru płatności w euro (SEPA). Dyrektywa ta miała sprawić, aby płatności transgraniczne stały się równie proste, tanie i bezpieczne tak, jak płatności krajowe. Warto zauważyć, że została ona uchwalona w roku, w którym na rynku pojawił się pierwszy iPhone. Rozwój technik telekomunikacyjnych, rozwój mobilności, powstawanie FinTechów, które w zakresie liczby przeprowadzanych transakcji oraz liczby klientów wyrastały ponad największe grupy bankowe, to wszystko doprowadziło do uchwalenia w listopadzie 2015 r. drugiej dyrektywy w sprawie usług płatniczych (PSD2).

Zmiany wynikające z PSD2 zostały wprowadzone do ustawodawstwa polskiego i weszły w życie w czerwcu 2018  r. (Ustawa z 10 maja 2018 r. zmieniająca Ustawę z 19 sierpnia 2011 r. o usługach płatniczych – „Ustawa”), za wyjątkiem niektórych obowiązków, których wprowadzenie zostało odsunięte w czasie. Z punktu widzenia zagadnień cyberbezpieczeństwa najciekawsze są zmiany wprowadzone w nowo dodanym dziale IIa Ustawy, który został poświęcony zapewnieniu bezpieczeństwa usług płatniczych.

Bezpieczeństwo świadczenia usług płatniczych

Zgodnie z zasadami zawartymi w wyżej wspomnianym dziale Ustawy, dostawca usług płatniczych („Dostawca”) zobowiązany jest podjąć środki ograniczające ryzyko oraz wprowadzić mechanizmy kontroli służące zarządzaniu ryzykiem operacyjnym oraz ryzykiem naruszenia zasad bezpieczeństwa. W Ustawie wskazuje się wprost (wyliczenie nie jest wyczerpujące) dwa elementy takiej kontroli. Pierwszym jest utrzymywanie skutecznej procedury zarządzania incydentami, czyli zdarzeniami niespodziewanymi (lub serią takich zdarzeń), mającymi niekorzystny wpływ na integralność, dostępność, poufność, autentyczność lub ciągłość świadczenia usług płatniczych albo stwarzającymi znaczne prawdopodobieństwo, że taki wpływ będzie mieć. Drugim elementem jest prowadzenie bieżącej oceny i aktualizacji procedur w zakresie zarządzania ryzykiem, bieżącej oceny środków ograniczających ryzyko, a także bieżącej oceny mechanizmów kontroli.

Podkreślenie obowiązku prowadzenia tych działań na bieżąco wskazuje na konieczność niezwłocznego reagowania w tym zakresie, np. w przypadku otrzymania informacji wskazującej na nieadekwatność rozwiązań zastosowanych w przyjętym systemie zarządzania ryzykiem.

Z kolei obowiązek raportowania oceny i aktualizacji procedur w zakresie zarządzania ryzykiem operacyjnym i ryzykiem naruszenia bezpieczeństwa, środków ograniczających ryzyko oraz mechanizmów kontroli do KNF, realizowany jest tylko raz w roku – do 31 stycznia roku następującego po roku, którego dotyczy raport. Do tej samej daty, dostawcy przekazują do KNF (lub do innego właściwego organu nadzoru) dane dotyczące oszustw związanych z wykonywanymi usługami płatniczymi, uwzględniając różne sposoby ich świadczenia.

Incydent czy incydent poważny

Jeżeli chodzi o raportowanie incydentów, to zgodnie z Ustawą dostawcy mają obowiązek niezwłocznego zawiadamiania KNF o każdym przypadku wystąpienia poważnego incydentu operacyjnego lub incydentu związanego z bezpieczeństwem, w tym incydentu o charakterze teleinformatycznym (KNF przekazuje takie informacje dalej do EUNB i EBC, a czasami do organów nadzoru w innych krajach). Zgodnie z literalną treścią art. 32g ustawy należałoby
przyjąć, iż zgłoszeniu podlega każdy (a nie tylko poważny) incydent o charakterze teleinformatycznym, co odbiegałoby jednak od treści dyrektywy PSD2 w tej mierze.

Europejski Urząd Nadzoru Bankowego (EBA) we współpracy z Europejskim Bankiem Centralnym (ECB) wydał w  roku 2017 wytyczne dotyczące raportowania incydentów poważnych (Wytyczne). Wytyczne wydane na podstawie delegacji zawartej w dyrektywie PSD2 określają sposób klasyfikacji oraz notyfikacji incydentów, wskazując szczegółowe kryteria oraz metodologię postępowania. Zgodnie z tym dokumentem zgłoszeniu podlega każde zdarzenie, które spełnia przynajmniej jedno kryterium o wysokim stopniu oddziaływania (High Level Impact – przykładowo zdarzenia dotykające co najmniej 50 000 użytkowników) albo zdarzenia spełniające trzy lub więcej kryteriów, których poziom oddziaływania jest niski (Low Level Impact).

Wytyczne wskazują zarówno rodzaje kryteriów (m.in. łączna wartość płatności dotkniętych incydentem, liczba płatności wyrażona jako określony procent, liczba użytkowników dotkniętych incydentem zarówno w wartościach bezwzględnych, jak też jako odsetek łącznej liczby użytkowników, czas, w którym usługi były niedostępne, skutki ekonomiczne, utrata reputacji itd.) oraz podają konkretne ich wartości (w przypadku każdego z kryteriów osobno dla HLI oraz LLI). Wytyczne zawierają także wzór zgłoszenia incydentu oraz uszczegóławiają sam proces takiego raportowania. Zgodnie z Wytycznymi, raportowanie składa się z  trzech faz – pierwszej (tzw. zgłoszenie wstępne), która powinna nastąpić co do zasady w ciągu 4 godzin od wystąpienia incydentu, drugiej (tzw. przejściowej), która może składać się z większej ilości informacji przesyłanych do regulatora za każdym razem, kiedy dostawca poweźmie dodatkowe istotne informacje uzupełniające zgłoszenie wstępne, oraz trzeciej (zgłoszenie końcowe), która następuje nie później niż 2 tygodnie od przywrócenia normalnego świadczenia usług płatniczych, a które zawiera pełną analizę przyczyn wystąpienia incydentu oraz podsumowanie skutków jego działania.

Dostawca usług płatniczych w przypadku incydentów mających lub mogących mieć wpływ na interesy finansowe użytkowników świadczonych przez siebie usług ma obowiązek zawiadomienia (bez zbędnej zwłoki) tych użytkowników o incydencie oraz poinformowania ich o dostępnych środkach, które mogą podjąć w celu ograniczenia negatywnych skutków incydentu.

Ponadto, jeśli KNF (lub inny właściwy organ nadzoru) otrzyma od EUNB lub EBC informację o incydencie, który ma znaczenie dla krajowego rynku finansowego, będzie on zobowiązany do podjęcia „niezbędnych działań w celu ochrony bezpieczeństwa systemu finansowego”. Ustawa nie definiuje, co wchodzi w skład takich działań, ale z pewnością można do nich zaliczyć co najmniej działania o charakterze informacyjnym (tak w stosunku do dostawców usług płatniczych, jak i do innych organów, zobowiązanych na mocy odrębnych przepisów do realizacji zadań odnoszą cych się do zarządzania ryzykiem naruszenia bezpieczeństwa systemów teleinformatycznych w skali kraju).

2 z 3, czyli silne uwierzytelnienie w usługach płatniczych

Oprócz obowiązków o charakterze systemowym Ustawa wprowadza także obowiązek określonego sposobu uwierzytelnienia użytkownika w przypadku, gdy ten uzyskuje dostęp
do swojego rachunku w trybie online, inicjuje elektroniczną transakcję płatniczą lub przeprowadza za pomocą kanału zdalnego czynność, która może wiązać się z ryzykiem oszustwa związanego z wykonywanymi usługami płatniczymi lub innymi nadużyciami.

W takiej sytuacji konieczne jest stosowanie silnego uwierzytelnienia, czyli takiego, które zapewnia ochronę poufności danych w oparciu o zastosowanie co najmniej dwóch elementów należących do kategorii: a) wiedzy o czymś, o czym wie wyłącznie użytkownik; b) posiadania czegoś, co posiada wyłącznie użytkownik lub c) cechy charakterystycznej użytkownika. Owe dwa elementy muszą być integralną częścią procesu uwierzytelnienia w taki sposób, że naruszenie jednego z tych elementów nie osłabia wiarygodności pozostałych.

Przy inicjowaniu elektronicznej transakcji płatniczej z wykorzystaniem internetu lub za pośrednictwem środków wykorzystywanych do porozumiewania się na odległość, dostawca ma ponadto obowiązek stosowania silnego uwierzytelnienia użytkownika obejmującego elementy łączące dynamicznie odbiorcę z transakcją płatniczą oraz określoną kwotą tej transakcji. Indywidualne dane uwierzytelniające muszą być przechowywane przez dostawcę usług płatniczych z zastosowaniem odpowiednich środków bezpieczeństwa, zapewniających ochronę poufności i integralności tych danych.

Silne uwierzytelnienie będzie wymagane także w sytuacji, w której dostawca świadczący usługę dostępu do informacji o rachunku występuje do dostawcy prowadzącego rachunek o podanie informacji o tym rachunku. Dostawca prowadzący rachunek ma obowiązek umożliwienia dostawcy usług inicjowania transakcji płatniczej oraz dostawcy świadczącemu usługę dostępu do informacji o rachunku, świadczenie usług oparte na uwierzytelnieniu stosowanym w relacji dostawca prowadzący rachunek – użytkownik.

Przepisy dotyczące silnego uwierzytelniania zawarte w art. 32ni Ustawy weszły w życie 14 września 2019 r. (inną datę przewidziano dla Banku Gospodarstwa Krajowego), łącznie z przepisami rozporządzenia delegowanego Komisji z 27 listopada 2017 r. uzupełniającego dyrektywę PSD2 względem regulacyjnych standardów technicznych, dotyczących silnego uwierzytelnienia klienta i wspólnych, bezpiecznych otwartych standardów komunikacji (RTS) do silnego uwierzytelnienia. RTS-y precyzują dalsze wymagania w zakresie m.in. kodu uwierzytelniającego (np. przyjmowanie kodu wyłącznie raz, liczba nieudanych prób uwierzytelnienia, po której następuje czasowa lub stała blokada, sposób ochrony sesji komunikacyjnych), dynamicznego połączenia (m.in. wszelkie zmiany kwoty lub odbiorcy skutkują unieważnieniem wygenerowanego kodu uwierzytelniającego), wymogów odnoszących się do kategorii „wiedza”, „posiadanie” i „cechy klienta” oraz niezależności tych elementów.

Dlaczego banki? Bo tam są pieniądze

Willie Sutton, amerykański przestępca, który upodobał sobie sektor bankowy, co – z jednej strony – wzbogaciło go o 2 mln dolarów, a z drugiej kosztowało niemal połowę dorosłego życia spędzonego za kratkami, na pytanie, dlaczego napada na banki, miał ponoć odpowiedzieć, że dlatego, że to tam właśnie są pieniądze. Instytucje finansowe, w tym banki, są i będą jednym z ulubionych celów ataków nie tylko dlatego, że „tam są pieniądze”, ale także dlatego, że instytucje te dysponują walutą XXI w. – danymi klientów. Zagrożenie ze
strony cyberprzestępców jest niewątpliwie jednym z  ryzyk operacyjnych, ale stawianie go na równi z innymi ryzykami może okazać się ryzykiem samym w sobie. Przypadek Centralnego Banku Bangladeszu pokazuje, że brak odpowiednich działań oraz inwestycji prowadzonych w tym zakresie może powodować skutki trudne do odwrócenia.

Wydaje się zatem, że zarządy banków powinny przyzwyczajać się do myśli, że cyberbezpieczeństwo dawno już przestało być wyłącznie domeną IT. Rozwój nowych produktów i transformacja cyfrowa pozwalająca na konkurowanie z coraz szerszą masą pretendentów do schedy po tradycyjnym sektorze finansowym oraz inwestycje w budowanie odporności organizacji na cyberataki to dwie strony tej samej monety, której szefowie banków nie powinni wypuszczać z rąk.

Informacje zawarte w niniejszym opracowaniu mają charakter ogólny i nie stanowią wiążącej opinii prawnej.

Przypisy:

[1] Dyrektywa Parlamentu Europejskiego i Rady (UE) 2016/1148 z 6 lipca 2016 r. w sprawie środków na rzecz wysokiego poziomu bezpieczeństwa sieci i systemów informatycznych na terytorium Unii Europejskiej.
[2] Rozporządzenie Rady Ministrów z 11 września 2018 r. w sprawie wykazu usług kluczowych oraz progów istotności skutku zakłócającego incydentu dla świadczenia usług kluczowych.

AUTORZY:

Ireneusz Piecuch

Radca prawny z blisko trzydziestoletnim stażem w obszarze nowych technologii, w szczególności outsourcingu, cloud computingu, cyberbezpieczeństwa, własności intelektualnej i prawa spółek. Łączy wiedzę prawną z doświadczeniami szefa departamentu prawnego, zewnętrznego doradcy oraz członka zarządu.

Katarzyna Kloc

Adwokat specjalizująca się w prawie nowych technologii. Doradza w zakresie regulacji sektora finansowego, outsourcingu, tajemnicy bankowej, ochrony danych osobowych i bezpieczeństwa informacji, jak również prawa konsumenckiego.