Amerykańskiemu kasiarzowi Willie Suttonowi, działającemu w połowie XX w., przypisuje się powiedzenie, iż obrabia on banki, ponieważ "jest to miejsce, gdzie znajdują się pieniądze". W erze cyfrowej ta sama motywacja kieruje podobnymi działaniami w stosunku do szeroko pojętego handlu elektronicznego.

Bezpośrednim obiektem ataku tradycyjnych kryminalistów był kasjer w okienku, dzisiejsi na cel biorą aplikacje bankowe oraz systemy e-commerce. Jednak choć zmieniły się infrastruktura i narzędzia, to cel pozostał ten sam: miejsce, gdzie można ukraść pieniądze, a dzisiaj są to kiepsko zaprojektowane i słabo chronione aplikacje bankowe i e-commerce. Niedbałe zabezpieczenia tych aplikacji ułatwiają kradzież i następnie wykorzystywanie informacji osobowych i finansowych z transakcji kart płatniczych oraz systemów ich przetwarzania.

Zobacz również:

• Firmy IT nasilają walkę z treściami deepfake
• Klucze passkey zapewniają bezpieczeństwo ponad połowie kont Google

Lista zagrożeń dotyczących banków i aplikacji płatności jest bardzo długa: kradzież tożsamości, wycieki danych, phishing, ataki SQL Injection, robaki, ataki DoS (Denial of Service), a także botnety - to tylko niektóre z nich. Największym problemem jest to, że zarówno liczba zagrożeń, jak i aplikacji, które wymagają zabezpieczeń - wciąż rośnie.

Nadużycia w sieciach płatności

Podstawowym celem ataków cyberprzestępców są zazwyczaj sieci płatności. Napastnik poszukuje podatnych systemów i podejmuje próby włamania do nich, aby wykraść informacje finansowe i osobowe, które można łatwo sprzedać online lub wykorzystać do oszustw finansowych.

Czego poszukuje napastnik i gdzie? W praktyce funkcjonują dwa typy płatności elektronicznych: online i fizyczny z wykorzystaniem terminali POS (Point of Sale), akceptujących karty płatnicze. W obu przypadkach klienci pozostawiają część swoich danych. Cyberprzestępcy poszukują danych posiadacza karty, najlepiej połączonych z danymi personalnymi. Kradzież samej karty nie jest już wystarczająca.

Dokonywana przez internet kradzież w sklepie online jest zwykle związana z lukami bezpieczeństwa w komponentach systemu komputerowego, takich jak zapory ogniowe, serwery czy aplikacje.

W sklepie fizycznym istnieje kilka sposobów kradzieży danych. Jednym z nich może być zhakowanie podatnej na ataki sieci bezprzewodowej, za pośrednictwem której transmitowane są dane właściciela karty.

W różnych rejonach świata dominują różne rodzaje przestępstw. W Europie więcej nadużyć związanych z kartami płatniczymi odnotowuje się w handlu online, natomiast w Stanach Zjednoczonych - w sklepach fizycznych.

Wyróżnia się dwa zasadnicze rodzaje danych związanych z kartami płatniczymi i każdy z nich wymaga innego typu ochrony. Pierwszy, to dane posiadacza karty (Cardholder Data), obejmujące: numer konta podstawowego, nazwę/nazwisko posiadacza, kod serwisowy i datę ważności. Drugi - to wrażliwe dane uwierzytelniania SAD (Sensitive Authentication Data), znajdujące się na pasku magnetycznym: 3- lub 4-cyfrowe kody (CAV2, CID, CVC2, CVV2) oraz PIN.

Przy realizacji transakcji kartą płatniczą, sprzedający nie powinien przechowywać danych uwierzytelniania (SAD) po wykonaniu autoryzacji, aczkolwiek może zachować dane posiadacza karty, jeżeli są odpowiednio zaszyfrowane.

PCI Data Security Standard (DSS) - dotyczy jednostek przechowujących i/lub transmitujących dane posiadacza karty. Obejmuje techniczne i operacyjne komponenty związane z danymi posiadacza karty. Wymagania PCI DSS powinien spełniać np. sklep akceptujący karty płatnicze.

Wymagania bezpieczeństwa dla PIN Entry Device (PED) - odnoszą się do charakterystyki i zarządzania urządzeniami wprowadzania PIN, używanymi w transakcjach kartami płatniczymi.

Payment Application Data Security Standard (PA-DSS) - wymagania dla projektantów oprogramowania komercyjnego (i integratorów aplikacji płatności) przechowującego, przetwarzającego i transmitującego dane posiadacza karty w ramach procesów autoryzacji i sprawdzania pokrycia finansowego.

Niezabezpieczone aplikacje bankowe

Celem dawnych włamywaczy były sejfy bankowe, w których przechowywano złoto. Poza solidnym zabezpieczeniem wokół i wewnątrz takiego skarbca, głównym problemem dla włamywaczy był ciężar łupu i jego wyniesienie. Nawet, jeżeli napastnik dostał się do skarbca, to trudno mu było wynieść stamtąd znaczącą ilość kruszcu.

Takich kłopotów nie sprawiają dane: są niezwykle "lekkie" i bardzo łatwe do przenoszenia - transfer gigabajtów danych to zadanie niemal trywialne w sensie fizycznym. Dane znajdujące się w dzisiejszych aplikacjach bankowych mają wartość złota, a mimo to dostęp do nich nie jest zbyt skomplikowany.

Z aplikacjami tymi mogą być powiązane dziesiątki lub setki milionów rekordów. Aplikacja łączy się z bazą danych, służącą za repozytorium wrażliwych danych osobowych. Łup napastnika znajduje się wewnątrz takich aplikacji i może przybierać różnorodne formy - zazwyczaj są to informacje o koncie klienta i personalnych identyfikatorach, które można potem użyć do uzyskiwania nielegalnych korzyści. Wyprowadzenie takich danych polega jedynie na transmisji ciągów zer i jedynek z jednego komputera do drugiego, w niczym nie przypominając trudu i ryzyka związanego z przewozem ciężkich sztab złota.

Jak pokazują wyniki audytów systemu Visa, niewłaściwe przechowywanie danych to podstawowa przyczyna naruszenia danych posiadacza karty. Często znajdują się one w bazach danych, w których nigdy nie powinny być przechowywane po tym, gdy żądana transakcja karty kredytowej została autoryzowana.

Z kolei, z badań przeprowadzonych na zlecenie RSA/EMC przez Forrester Consulting wśród organizacji obsługujących karty płatnicze, a dotyczących działań narażających na ryzyko dane posiadaczy kart - wynika, że 81% badanych przechowywało w swoich bazach danych numery kart płatniczych, 73% - daty ich ważności, a 57% - dane z pasków magnetycznych kart.

Wciąż funkcjonują aplikacje własne i komercyjne, które narażają dane, ponieważ nie były zaprojektowane zgodnie z wymaganiami bezpieczeństwa i zaleceniami bezpiecznego kodowania. W niektórych przypadkach raportowane usterki kodu naruszają właśnie proste standardy projektowania aplikacji, takie jak OWASP (Open Web Application Security Project).

W 2008 r. nadal można było znaleźć aplikacje bankowe, które są wdrażane bez uwzględniania wymogów formalnych wywodzących się z SDLC (Software Development Life Cycle) i przeglądania kodu pod kątem luk bezpieczeństwa. W wielu przypadkach okazuje się, że projektanci aplikacji przetwarzania płatności nawet nie znają wymagań w zakresie właściwego przetwarzania i przechowywania informacji wrażliwej.

Dodatkowy poziom ochrony winien być zapewniony przez odpowiednie testowanie aplikacji płatniczych. Powinno się je przeprowadzać z uwzględnieniem wszystkich aspektów tego, jak informacja wrażliwa jest obsługiwana w całym jej cyklu życia, oraz historycznych zapisów transakcji wynikowych. Zbyt wiele zespołów testowania aplikacji skupia się jednak wyłącznie na testowaniu funkcjonalności, skalowalności i obciążeń.

Podejmuje się próby skanowania różnych komponentów aplikacji z pomocą ogólnych skanerów podatności, ale przy braku doświadczenia niezbędnego do właściwej interpretacji wyników takiego skanowania, okazują się one nieadekwatne dla aplikacji pracujących w otwartej, publicznie dostępnej sieci.

Payment Card Industry i bezpieczeństwo aplikacji

Do niedawna nie przejmowano się zbytnio wymogami bezpieczeństwa aplikacji i płacimy teraz za to wysoką cenę - częstymi przypadkami naruszania danych. Microsoft na przykład zaczął poważnie traktować bezpieczeństwo aplikacji dopiero w 2002 r., ogłaszając inicjatywę Trustworthy Computing (TWC). TWC jest reakcją na dewastujące ataki na system operacyjny Microsoftu z użyciem takich robaków, jak Code Red czy Nimda.

Bezpieczeństwo aplikacji stanowi podstawę standardów i wymogów bezpieczeństwa w zakresie Payment Card Industry (PCI). W ciągu ostatnich kilku lat naruszenia danych są liczone w setkach milionów rekordów - w większości przypadków przy pracujących zaporach ogniowych, stosowaniu szyfrowania i uwierzytelniania. Dzieje się tak dlatego, że aplikacje mają luki bezpieczeństwa, które niwelują działanie większości zastosowanych środków ochrony. To zupełnie jakby wstawić opancerzone drzwi wejściowe do banku, ale pozostawić otwarte okno na zapleczu.

Słabe punkty mogą pojawiać się w całym systemie przetwarzania informacji kart płatniczych: w punktach kasowych (POS), komputerach osobistych i serwerach, bezprzewodowych punktach dostępowych lub aplikacjach e-commerce. Mogą też dotyczyć systemów usługodawców i instytucji finansowych, powiązanych z placówkami handlowymi akceptującymi karty płatnicze.

Rosnąca liczba przypadków kradzieży danych z kart płatniczych skłoniła operatorów tych systemów do działań na rzecz zwiększenia bezpieczeństwa. Powstał standard PCI DSS (Payment Card Industry Data Security Standard), który nakłada na każdego sprzedawcę przetwarzającego, przesyłającego lub przechowującego informacje o kartach - wymóg spełnienia określonych kryteriów.

Standardy bezpieczeństwa PCI są wymaganiami technicznymi i operacyjnymi ustanowionymi przez radę PCI Security Standards Council (PCI SSC), w celu ochrony danych posiadacza karty. Dotyczą wszystkich organizacji, które przechowują, przetwarzają lub transmitują takie dane, oraz zawierają zalecenia dla projektantów oprogramowania i dostawców aplikacji oraz urządzeń używanych w takich transakcjach. Rada PCI SSC jest odpowiedzialna za zarządzanie tymi standardami, a zgodność z nimi jest wymuszana przez jej członków-założycieli: American Express, Discover Financial Services, JCB, MasterCard i Visa.

W przypadku PCI DSS, "waluta" to wrażliwe informacje, które najbardziej potrzebują ochrony, takie jak: numery kont, nazwisko właściciela karty, różne kody serwisowe, data ważności i inne pozycje, które mogą być przechowywane cyfrowo, a także dane z pasków magnetycznych, w tym kody zabezpieczeń i PIN-y.

Wymagania dla bezpieczeństwa aplikacji PCI

Obecnie zaleca się, aby aplikacje tworzone we własnym zakresie lub zlecane na zewnątrz, oraz oprogramowanie, które nie jest komercyjnie odsprzedawane, spełniały wymagania standardu PCI DSS. Wszystkie tworzone aplikacje powinny być projektowane, wdrażane, obsługiwane i "odświeżane" zgodnie z tymi wymaganiami.

Bezpieczeństwo aplikacji płatniczych w epoce internetu

Wraz z rozwojem internetu, rada PCI SSC zaczęła skupiać się na Webie i aplikacjach płatności korzystających z tej techniki. Takie aplikacje są traktowane przez atakującego jako najbardziej oczywisty punkt wejścia, w celu uzyskania dostępu do baz danych zaplecza, zawierających dane o kartach płatniczych.

W ramach PCI DSS w wersji 1.2, wymagania 6.6 (obowiązujące od czerwca 2008 r.) stawiają wymóg sprawdzania bezpieczeństwa aplikacji opartych na Webie. PCI DSS requirement 6.6 nakładają na organizacje przetwarzające transakcje dokonywane za pomocą kart płatniczych - obowiązek uwzględnienia bezpieczeństwa aplikacji webowych (poprzez zagwarantowanie aplikacjom stykającym się z publiczną siecią WWW co najmniej corocznej weryfikacji kodu pod kątem luk bezpieczeństwa) oraz instalowania aplikacyjnych zapór ogniowych na styku takich aplikacji z publicznym Webem.

Aplikacyjna zapora ogniowa jest urządzeniem sieciowym umieszczanym na froncie aplikacji webowej, w celu ochrony jej przed atakami aplikacyjnymi. Zapora taka może przeglądać cały ruch aplikacyjny, ma też szersze możliwości specyficznego filtrowania warstwy sesji, prezentacji i aplikacyjnego ruchu sieciowego w czasie rzeczywistym. To pozwala wykorzystywać ją do ochrony aplikacji, i wszystkich związanych z nią danych wrażliwych, przed nielegalnym dostępem lub nieupoważnionym użyciem.

Zagrożenia bezpieczeństwa, choć są łagodzone przez zaporę ogniową poziomu aplikacyjnego, pozostają bardzo realne. Zakres ryzyka związanego z bezpieczeństwem oprogramowania można podzielić na dwa rodzaje: słabości kodu programu i słabe strony projektów. Pierwsza grupa obejmuje m.in. brak kontroli przepełnienia bufora, luki w łańcuchach formatów, błędy kontroli we/wy i błędy prowadzące do możliwości wykonania ataków typu SQL Injection czy Cross-site scripting. Natomiast słabe strony projektu i naruszenia zasad polityki projektowej dotyczą: kryptografii, luk w komunikacji sieciowej i w konfiguracji aplikacji, kontroli dostępu, sposobu korzystania z bazy danych i systemu plików, błędów w kontroli dostępu i uwierzytelnianiu, luk w obsłudze błędów i rejestrowaniu (niezabezpieczona obsługa błędów, nieadekwatne rejestrowanie błędów) oraz niebezpiecznych komponentów (cookies, ukryte pola).

Bezpieczeństwo komercyjnych aplikacji przetwarzania płatności

Komercyjne aplikacje przetwarzania płatności, które są sprzedawane lub dzierżawione publicznie, muszą spełniać bardziej surowe wymagania bezpieczeństwa. Pierwotnie zaprojektowano je, zaimplementowano i wdrożono w systemie kart Visa i były znane jako standard PABP (Payment Application Best Practices).

Przez lata wymagania te pomagały chronić handel z wykorzystaniem kart kredytowych Visa wszędzie tam, gdzie zostały wdrożone zgodne z nimi aplikacje. Jednak PABP skupiały się przede wszystkim na aplikacjach przetwarzających płatności Visa i korzyści z poprawionego bezpieczeństwa nie mogły być wykorzystane we wszystkich markach kart płatniczych. Stało się więc oczywiste, że są potrzebne standardy bezpieczeństwa aplikacji obejmujące szerszy zakres, i to był powód opracowania PCI Payment Application Data Security Standard (PA-DSS).

W listopadzie 2007 r. PCI Security Standards Council ogłosiła, że PABC będzie zastąpiony przez PCI Payment Application Digital Security Standard (PA-DSS). W ten sposób PCI SSC stała się wyłączną jednostką utrzymania nowych, niezależnych od marki wymagań i podmiotem odpowiedzialnym za nadzór zgodności z nowym standardem bezpieczeństwa. Aplikacje płatności, wcześniej certyfikowane na zgodność z najbardziej aktualną wersją specyfikacji PABP, będą mogły zachować swoje certyfikaty przez ograniczony czas i po tym okresie muszą być odnawiane w ramach nowego PA-DSS.

Nowo projektowane komercyjne aplikacje handlowe, które są oferowane publicznie, muszą być testowane na zgodność z PA-DSS, począwszy od października 2008 r. Te dwa standardy są podobne i w rzeczywistości większość treści PA-DSS opiera się na wcześniej zdefiniowanych wymaganiach PABP. Jednak istnieją pewne wyraźne różnice pomiędzy nimi, w tym bardzo surowe wymagania w PA-DSS QSA w zakresie oceny środowiska, które jest używane dla wszystkich testów bezpieczeństwa aplikacji.

Ponadto, PA-DSS Implementation Guide (podobny do PABP Best Practices Implementation Guide) zawiera szczegółowe zalecenia dotyczące tego, jak implementować aplikacje płatności i związane z nimi systemy, w utrzymywanych w określony sposób, zgodnych konfiguracjach. Stanowi on także wyraźnie, że jakiekolwiek odchylenie od określonej konfiguracji, może w praktyce zagrażać zgodności PCI DSS.

Bezpieczeństwo kosztowne, ale niezbędne

Aplikacje webowe stają się podstawą bankowości i handlu elektronicznego. POS i aplikacje przetwarzania płatności, wykorzystujące technologie webowe i im podobne, będą wdrażane jako alternatywa podobnych klasycznych systemów. Łączą one użytkowników końcowych, klientów, sprzedawców, agentów i partnerów oraz przetwarzają wrażliwe dane, obejmujące informacje osobowe i finansowe o największej wartości. Realizują to wszystko w czasie rzeczywistym - w dowolnym miejscu i o dowolnej porze. Potrzeba istotnego wzmocnienia bezpieczeństwa aplikacji staje się najważniejsza i dlatego rośnie znaczenie wymagań bezpieczeństwa PCI DSS i PA-DSS.

Choć bezpieczeństwo aplikacji pozostaje jednym z większych wyzwań i jest kosztowne, przeszkody na drodze do uzyskania zgodności z wymaganiami 6.6 PCI DSS nie mogą zakłócać dążenia do pełnej ochrony płatniczych systemów transakcyjnych. Przyszłość organizacji zależy od bezpieczeństwa aplikacji webowych, a koszty nieupoważnionego naruszenia danych mogą znacznie przekraczać koszty wdrożenia ochrony aplikacji i wrażliwych danych. Ponadto, zgodnie z przepisami dotyczącymi pobierania, wykorzystywania i przechowywania danych kart płatniczych, w najbliższych latach przeprowadzenie udanej operacji obciążenia karty bez spełnienia rygorystycznych standardów bezpieczeństwa PCI DSS będzie niemożliwe.