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.