Bezpieczeństwo systemów bankowych: kompletny przewodnik

Artykuł zaktualizowano 24.11.2020

Z bankowych aplikacji mobilnych korzysta już 9 milionów Polaków. To nowoczesne rozwiązanie cenimy za dostępność, możliwość wykonywania przelewów w każdej chwili czy ułatwione planowanie budżetu tu i teraz. Jednak aplikacje bankowe, tak jak bankowe systemy, nie zawsze zapewniają klientom 100% bezpieczeństwa. Z jakimi lukami w cyberzabezpieczeniach borykają się banki i jakie działania powinny podjąć, by jeszcze lepiej zadbać o dane i pieniądze konsumentów?

Chociaż banki starają się zawsze być kilka kroków przed potencjalnymi oszustami, możliwości na wykradzenie danych osobowych lub zasobów finansowych jest dużo, a zabezpieczenia niestety nie zawsze okazują się wystarczające. Różne kanały dystrybucji, przez które świadczone są usługi bankowe, stwarzają inne możliwości dla hakerów. Próżno szukać statystyk dotyczących najczęstszych powodów włamań do systemów i aplikacji bankowych, jednak do najpopularniejszych z nich należą włamania na internetowy rachunek bankowy, niekontrolowane udostępnianie danych osobowych z zasobów banku, kradzież tożsamości i oszustwa podczas płatności elektronicznych.

Same banki czują się dobrze zabezpieczone przed zagrożeniami. Najlepiej oceniają zapobieganie włamaniom na internetowe konta bankowe (94%). Ich zdaniem pracy wymagają jeszcze zabezpieczenia związane z czasowymi awariami systemów i kradzieżami danych z kart płatniczych.

Z kolei badanie 14 aplikacji bankowych przeprowadzone przez Positive Technologies wykazało, że aż 13 z nich posiadało luki, które mogłyby dać dostęp do danych klientów niepożądanym osobom. 76% luk można było wykorzystać bez fizycznego dostępu do urządzenia właściciela konta. Serwery zawierały natomiast 54% wszystkich luk wykrytych w badaniu – każdy z banków miał ich średnio 23.

Jedną z aktualnych podstaw prawnych, regulujących bezpieczeństwo systemów i aplikacji bankowych, jest Unijna Dyrektywa PSD2. Nakłada ona na dostawców usług płatniczych obowiązek silnego uwierzytelniania klientów. Zgodnie z założeniem dyrektywy, tożsamość użytkownika musi być zweryfikowana na podstawie dwóch z trzech składników:

Podwójna weryfikacja musi być przeprowadzana zawsze, gdy klient chce uzyskać dostęp do swojego rachunku online, przeprowadzić elektroniczną transakcję lub przeprowadzać inną czynność, która może wiązać się z ryzykiem oszustwa płatniczego lub innych nadużyć.

Dyrektywa PSD2 wprowadziła też nowe wymogi dla interfejsów komunikacji z osobami trzecimi (TPP). Zgodnie z nią dostawcy usług płatniczych (ASPSP) muszą zapewnić otwarte interfejsy programistyczne (API), na bazie których TPP będą mieć możliwość oferowania innowacyjnych usług i produktów. Każdy ASPSP powinien udostępnić co najmniej jeden interfejs komunikacji z TPP. Istotne jest tu rozpoczęcie uwierzytelniania na podstawie zgody wyrażonej przez użytkownika oraz zapewnienie integralności i poufności danych uwierzytelniających. Ważnym nakazem nałożonym przez PSD2 jest też konieczność stosowania przez banki bezpiecznego szyfrowania danych przez cały czas trwania sesji komunikacyjnej.

Sektor bankowy powinien też działać zgodnie z rekomendacjami Komisji Nadzoru Finansowego. Ta dotycząca bezpieczeństwa płatności elektronicznych rekomendacja mówi o wytycznych w zakresie oceny ryzyka i polityki bezpieczeństwa płatności. Rekomendacja przypomina ogólne zasady analizy ryzyka, dobre praktyki i standardy, którymi powinny kierować się banki, ustanawiając standardy w zakresie audytowania procesów. Istotna jest również konieczność współpracy banków z właściwymi organami ścigania w przypadku incydentów bezpieczeństwa.

Standardem narzucającym reguły dbania o bezpieczeństwo aplikacji i systemów bankowych na terenie Stanów Zjednoczonych jest tzw. PCI Standard. Norma musi być stosowana w przypadku, gdy umowa jest zawierana pomiędzy przedsiębiorcą a centrem autoryzacyjnym, lub centrem a organizacją płatniczą.

Standard podzielono na 12 wymagań zgrupowanych w 6 grup, z których każda odpowiada na osiągnięcie konkretnego celu:

Ataki hakerskie na systemy i aplikacje bankowe przybierają różne formy. Przed dużą częścią z nich banki mogą uchronić swoich klientów, zabezpieczając kod systemu i aplikacji oraz podejmując inne działania przez dział IT. Nad niektórymi atakami sam bank nie ma tak dużej kontroli – są one skierowane bezpośrednio do nieświadomych konsumentów, żerując na ich niewiedzy. Przed takimi sytuacjami instytucja może uchronić klientów tylko poprzez ich skuteczne informowanie, edukację o bezpiecznej bankowości oraz samodzielne śledzenie potencjalnych oszustw.

Przed czym banki i podobne instytucje powinny szczególnie się przygotować?

Posiadającym wiele odmian socjotechnicznym oszustwem bankowym (ale nie tylko), jest phishing, nazywany też password harvesting fishing. Phishing polega na podszywaniu się pod daną instytucję w celu “złowienia” danych osobistych, takich jak hasła do logowania, numery kont bankowych lub kart kredytowych czy innych istotnych informacji. Stąd już krótka droga do przejęcia konta użytkownika.

Phishing przyjmuje wiele form, dlatego bywa trudny do szybkiego zidentyfikowania. Osoba atakująca może przykładowo:

Atak skierowany bezpośrednio na urządzenie użytkownika może być przeprowadzony z użyciem kodu QR. Fałszywy kod QR może być wysłany e-mailem lub sms-em bądź umieszczony na podszywających się pod bankowe materiałach. Zeskanowanie kodu ma rzekomo zapewnić klientowi jakieś korzyści, na przykład umożliwić pobranie aplikacji mobilnej banku. W rzeczywistości zainstalowane na urządzeniu konsumenta oprogramowanie przekazuje kontrolę nad nim hakerowi. Ten może już swobodnie podsłuchiwać lub przekierowywać rozmowy bądź wiadomości (np. zawierające dane do logowania).

W przypadku systemu Android jedną z wykorzystywanych luk jest Stagefright, czyli bug w bibliotece odpowiedzialnej za obsługę multimediów. Smartfon można zaatakować, wysyłając na niego wiadomość, najczęściej MMS. W przeciwieństwie do typowego phishingu, użytkownik, aby zostać zaatakowany, nie musi pobierać żadnego pliku rekomendowanego w wiadomości czy nawet otwierać MMS-a. Samo pojawienie się go w telefonie może posłużyć hakerowi do eksplorowania zawartości urządzenia. Po zgłoszeniu problemu Google opracowało łatki likwidujące tę lukę, jednak, jak zbadało Zimperium, na podobne ataki mogło być podatnych nawet prawie 1,5 miliarda użytkowników urządzeń z Androidem.

Stosunkowo łatwym do wykrycia, a jednocześnie dość często pojawiającym się, atakiem jest Denial of Service. Atak polega na zablokowaniu dostępu do systemu lub aplikacji, a w efekcie – do usług. W tym przypadku oszustwo wymierzone jest bezpośrednio w banki, ingerując w ich wizerunek i skutki biznesowe. Do przeprowadzenia ataku DoS hakerzy mogą celowo przeciążać serwis, tak, by nie mógł on realizować swoich funkcji. Odmianą ataku DoS jest DDoS, gdzie atakujący infekuje sprzęt “zwykłych” użytkowników, przejmując je i wykorzystując do zdalnego uruchomienia ataku na wskazany serwis.

Rosnącą częstotliwość można zauważyć wśród ataków typu APT. Ich duże niebezpieczeństwo polega na tym, iż mogą pozostać one niewykryte miesiącami, w tym czasie przynosząc straty finansowe i wizerunkowe dla banku. Są to ataki dedykowane, uwzględniające specyfikę danej organizacji, wykorzystujące wiele metod, w tym phishing, malware czy spearphishing. Instytucje finansowe mogą zabezpieczyć się przed APT, skupiając uwagę swoich działów IT na tzw. Security Incident Response Workflow, czyli połączeniu szybkości, trafności i powtarzalności procesów odpowiedzi.

Banki muszą zmagać się z bezpieczeństwem operacyjnym własnych rozwiązań wewnętrznych. Proces zabezpieczania przed atakami powinien obejmować zarówno opracowanie polityki bezpieczeństwa na poziomie technicznym (infrastruktury i aplikacji), jak i zadbanie o poziom operacyjny – związany z procesami i zasobami ludzkimi. Co oczywiste, zabezpieczenia systemów i aplikacji bankowych muszą zawierać mechanizmy prewencyjne oraz przeznaczone do zarządzania incydentami.

Odpowiedzią na stosunkowo nowe regulacje unijne, które weszły w życie jesienią 2019 roku, może być cloud computing. Rozwiązania pozwalające na szybkie dostosowanie technologii do wymagań biznesowych czy zmieniających się regulacji prawnych są teraz rozsądnym wyborem. Chmura, którą cechują szybkość, otwartość na innowacje i wysoki stopień zabezpieczeń, idealnie wpisuje się w aktualne potrzeby instytucji finansowych. Jak wynika z badania Accenture, już 20% światowych banków przeznacza środki inwestycyjne na rozwój otwartej bankowości.

O bezpieczeństwie rozwiązań chmurowych mogą świadczyć chociażby instytucje, które zdecydowały się umieścić swoją infrastrukturę w cloudzie. Znajdziemy wśród nich Departament Obrony Stanów Zjednoczonych, który planuje przenieść całą infrastrukturę do chmury w ciągu najbliższych 10 lat czy Pentagon, który na ten cel ma przeznaczyć 10 mld USD.

Oczywiście, nad działalnością hostingodawcy kontrolę musi sprawować sam bank. Ustawa o ochronie danych osobowych nakazuje, by instytucja finansowa:

Raport Związku Banków Polskich i Accenture wskazuje 5 kluczowych zaleceń dotyczących migracji i utrzymania infrastruktury banku w chmurze:

Więcej o wadach i zaletach hostingu w chmurze dowiesz się z tego artykułu.

Po wdrożeniu Ogólnego Rozporządzenia o Ochronie Danych Osobowych (RODO) oraz Dyrektywy PSD2 twórcy aplikacji nie mają innej możliwości niż wdrożenie lepszych praktyk bezpieczeństwa w swoim procesie wytwarzania oprogramowania. Nawet po odłożeniu na bok wszystkich innych aspektów, zaprojektowanie bezpiecznej aplikacji wymaga użycia szyfrowania, a złota zasada kryptografii mówi o tym, że nigdy nie należy tworzyć własnego szyfru.

Szyfrowanie stanowi podstawę nowoczesnego bezpieczeństwa oprogramowania. Szyfrowanie TLC służy do zabezpieczenia komunikacji między aplikacjami (lub przeglądarkami internetowymi) i serwerami. Sieci VPN zapewniają bardziej kompletne, bezpieczne tunele, które umożliwiają aplikacjom lub urządzeniom bezpieczne łączenie się z siecią. W wielu jurysdykcjach szyfrowanie danych wrażliwych jest regulowane nakazem prawnym. To sprawia, że twórcy aplikacji nie mogą uniknąć szyfrowania w swoich aplikacjach. Pole szyfrowania jest podzielone na dwie rozległe grupy: tworzące nowe szyfry i implementujące szyfry już istniejące. Wielu deweloperów wdraża szyfrowanie w takiej czy innej formie. Włączają je do aplikacji (lub komponentu aplikacji) bądź używają gotowych rozwiązań z punktu widzenia operacji IT.

Oczywiście, nad tworzeniem odpowiednio zabezpieczonych aplikacji nie pracują wyłącznie programiści. Wysoko cenionymi specjalistami w dziedzinie szyfrowania są kryptografowie posiadający wystarczające umiejętności i odpowiednie doświadczenie, które pozwalają im tworzyć nowe, realne i skuteczne algorytmy kryptograficzne. W wyniku niedoboru profesjonalnych kryptografów banki nie zawsze mają dostęp do odpowiednich osób, dzięki którym są w stanie wdrożyć legalne i zgodne z wymogami szyfrowanie w swoich aplikacjach bez udziału komponentów aplikacji innych firm. Kryptografowie z całego świata współpracują ze sobą, aby projektować nie tylko algorytmy, z których wszyscy korzystamy, ale także komponenty aplikacji powszechnie służące do udostępniania funkcji szyfrowania.

Regulacja prawna zasady „bezpieczeństwa poprzez projektowanie” jest zatem – przynajmniej w praktyce – zagwarantowaniem prawa do korzystania z komponentów aplikacji podmiotów trzecich.

Każdy kod zawiera błędy. Błędy w oprogramowaniu są przyczyną występowania luk w zabezpieczeniach. Stosowanie komponentów podmiotów trzecich, które zapewniają funkcjonalność szyfrowania, nie jest wystarczającą ochroną. Powszechne komponenty szyfrujące przez lata ujawniły wiele słynnych luk w bezpieczeństwie. Przypadki takie, jak Heartbleed, Shellshock i Krack trafiły na pierwsze strony gazet na całym świecie. Niektóre z nich można łatwo patchować, inne są bardziej fundamentalne, co wymaga rezygnacji ze starszych rozwiązań kryptograficznych na rzecz wdrożenia nowocześniejszych technologii.

Obecnie działania prewencyjne często obejmują też analizę Big Data ze względu na liczbę danych zbieranych przez banki. Oprócz tego wykorzystuje się narzędzia systemowe pozwalające na wykrywanie incydentów i zagrożeń, generujące alerty w czasie rzeczywistym, okresowe raporty i analizujące dane historyczne. Do takich rozwiązań należą m.in. Splunk, IBM QRadar czy HP ArcSight. Instytucje finansowe coraz częściej sięgają też po jednostki bezpieczeństwa operacyjnego (tzw. SOC). Pozwalają one na obsługę incydentów w oparciu o zdefiniowane procedury oraz zasady przepływu informacji wewnątrz organizacji. Jednocześnie SOC mogą komunikować się z odpowiednimi organizacjami zewnętrznymi, takimi jak Policja, Prokuratura czy NASK/CERT.

Większość osób, mówiąc o łataniu luk, ma na myśli system operacyjny swojego urządzenia. Każdy użytkownik komputera spotkał się z Windows Update, aktualizacją MacOS lub mechanizmami aktualizacji na swoich smartfonach. Te wszechobecne systemy łatania są dobrze znane, ale nie są to jedyne miejsca, w których może ono nastąpić. Komponenty firm są często dołączane bezpośrednio do skompilowanych aplikacji. Oznacza to, że te komponenty muszą zostać poprawione przed rozpoczęciem procesu budowania aplikacji, aby skompilowane aplikacje zawierały ich najnowsze wersje. Niestety, nie ma łatwego sposobu na określenie, które komponenty są załatane przez system operacyjny, a więc muszą zostać poprawione podczas procesu budowania aplikacji.

Jako przykład może posłużyć tu błąd Heartbleed, czyli wada wielu wersji biblioteki kryptograficznej OpenSSL, wspólnego komponentu open source. Biblioteka OpenSSL jest często pobierana, instalowana i zarządzana pakietowo w systemach operacyjnych Linux. Wiele aplikacji Linux jest zaprojektowanych do wywoływania i używania kopii bibliotek OpenSSL zarządzanych przez managera pakietów systemu operacyjnego. W tym przypadku regularne, zautomatyzowane aktualizacje systemu operacyjnego aktualizowałyby także OpenSSL, a każda aplikacja korzystająca z niego używałaby nowej wersji podczas ponownego uruchamiania aplikacji bez konieczności ponownej kompilacji lub ponownego wdrażania aplikacji.

OpenSSL jest jednak również wbudowywana bezpośrednio w niezliczone aplikacje, zwłaszcza gdy są one przeznaczone do użytku w systemie Windows. Manager pakietów systemu Windows nie instaluje ani nie zarządza żadną wersją bibliotek OpenSSL. W takim przypadku aplikacje muszą być przekompilowane (lub przynajmniej przepakowane) za każdym razem, gdy wychodzi nowa wersja biblioteki OpenSSL.

Do jednych z najważniejszych wydatków związanych z bezpieczeństwem aplikacji bankowych należą aplikacje wykorzystujące komponenty open source o znanych lukach. Problemu nie da się rozwiązać jedynie przez ulepszenie zabezpieczeń w urządzeniach. Żadne oprogramowanie antywirusowe, narzędzie do profilowania zachowań aplikacji, pakiet zabezpieczeń punktów końcowych ani narzędzie do zarządzania urządzeniami mobilnymi nie może sprawić, że aplikacja o znanej luce w zabezpieczeniach nie będzie podatna na ataki. Budowanie własnych aplikacji w celu korzystania z zaawansowanych funkcji zabezpieczeń urządzenia również nie rozwiąże tego problemu. Biometria, NFC i uwierzytelnianie wieloskładnikowe to tylko słowa-klucze, jeśli sama aplikacja, którą mają zabezpieczyć, jest podatna na ataki. Ponadto włączenie każdej z tych funkcji bezpieczeństwa do aplikacji może wymagać wielu dodatkowych komponentów innych firm, z których każdy będzie musiał być na bieżąco aktualizowany.

Z punktu widzenia banku powinno to być niepokojące. Oznacza to, że ciężar bezpieczeństwa nie może zostać z powrotem przeniesiony na klienta lub któregoś z dostawców istniejących w łańcuchu dostaw między klientem a bankiem. Jeśli bank wdroży aplikację, która zawiera komponenty open source ze znanymi lukami w zabezpieczeniach lub, jeśli nie zaktualizuje on i nie wdroży nowej wersji swoich aplikacji od razu po wykryciu luk w komponentach, których używa – bank ponosi za to odpowiedzialność. Przerzucenie odpowiedzialności za bezpieczeństwo na klienta, producenta urządzenia lub dostawcę systemu operacyjnego nie jest możliwe. Jeżeli potencjalna luka w bezpieczeństwie występuje jako część kodu umieszczonego w aplikacji, to obowiązkiem firmy jest bieżące aktualizowanie aplikacji i dodawanie do niej odpowiednich łatek i zabezpieczeń.

Wprowadzenie otwartej bankowości staje się koniecznością, ale niesie ze sobą także nowe wyzwania, jeśli chodzi o bezpieczeństwo danych osobowych użytkowników. W zależności od tego, jak analizuje się ryzyko związane z tworzeniem aplikacji, otwarta bankowość może wydawać się idealnym rozwiązaniem w kwestii zarządzania ryzykiem lub potencjalną katastrofą. Otwarta bankowość przenosi ciężar rozwoju aplikacji na zewnętrzne podmioty – aplikację tworzy podmiot komercyjny, całkowicie niepowiązany z bankiem. Otwarte aplikacje bankowe mogą zazwyczaj współpracować z wieloma bankami, umożliwiając użytkownikowi końcowemu korzystanie z aplikacji niezależnie od wybranego przez niego banku.

Ponieważ aplikacja jest projektowana, publikowana i utrzymywana przez programistów będących trzecimi podmiotami, którzy nie są powiązani kontraktem z bankiem, to odpowiedzialność za aktualizację tej aplikacji spoczywa na jej deweloperach, a nie na samej organizacji. Chociaż może to być pożądane z punktu widzenia odpowiedzialności, oznacza to również, że bank ma niewielką kontrolę nad tym, czy jego klienci korzystają z aplikacji o znanych lukach. To wymaga od banku podwojenia wysiłków w zakresie zwalczania oszustw.

Kluczem do udanej współpracy jest zaufanie między bankiem a deweloperem otwartej aplikacji. Musi ono istnieć też pomiędzy bankiem i klientem, a także między klientem a deweloperem. Zaufanie w świecie otwartej bankowości często komplikuje się przez zmiany w relacji z klientem. Banki spółdzielcze przyzwyczajone są do tego, że proces tworzenia relacji z klientami może trwać przez całe dekady. Jednak dzięki otwartej bankowości developer otwartej aplikacji bankowej posiada wiele codziennych doświadczeń bankowych klienta.

Warto wspomnieć też, że otwarta bankowość dostarcza developerowi aplikacji otwartej bankowości wgląd w wiele codziennych doświadczeń bankowych klienta. W miarę wzmożonego użytkowania aplikacji bankowych, rynek staje się coraz bardziej konkurencyjny. Wielu twórców aplikacji bankowych dokłada wszelkich starań, aby zdobyć zaufanie, pielęgnować relacje z bankami, z którymi współpracują ich aplikacje i realizować certyfikaty bezpieczeństwa oraz formalne przeglądy kodu swoich aplikacji. Banki, które wykorzystują otwartą bankowość, mogą podnieść poziom bezpieczeństwa dzięki wykorzystaniu inicjatyw bezpieczeństwa aplikacji partnerskich. Mogą również zwiększyć swoje bezpieczeństwo, wdrażając kontrole, które dowodzą, że twórcy aplikacji otwartej bankowości wykorzystują wszystkie narzędzia niezbędne do zapewnienia bezpieczeństwa wdrożonych aplikacji poprzez ich terminową i bieżącą aktualizację.

Masz pytania dotyczące bezpieczeństwa bankowości mobilnej lub chcesz porozmawiać o zabezpieczeniu Twojego projektu open source? Napisz do nas – chętnie odpowiemy na wszystkie pytania i znajdziemy rozwiązanie dedykowane dla Twojego projektu.

Czytaj więcej