Co powinieneś wiedzieć o testach penetracyjnych PCI DSS

Jeśli Twoja firma akceptuje płatności kartą kredytową, należy zapewnić zgodność ze standardem bezpieczeństwa danych branży kart płatniczych (PCI DSS), aby chronić dane posiadacza karty. PCI DSS ma wiele aspektów, a testy penetracyjne stanowią największe wyzwanie dla firm.

Aby upewnić się, że Twoja firma jest zgodna z PCI DSS, należy od czasu do czasu przeprowadzać testy penetracyjne, aby upewnić się, czy Twoje systemy i procesy są odpowiednio skonfigurowane, aby zapewnić bezpieczeństwo danych posiadaczy kart.

Testy penetracyjne PCI DSS

Istnieją trzy główne typy testów penetracyjnych: czarna skrzynka, biała skrzynka i szara skrzynka.

• Ocena penetracji czarnej skrzynki nie dostarcza żadnych informacji przed rozpoczęciem testów
• Ocena białej skrzynki zapewnia szczegółowe informacje o aplikacji i sieci podczas testu
• Ocena szarej skrzynki dostarcza częściowych informacji o systemach docelowych

Oceny w białej i szarej skrzynce zapewniają najlepszy wgląd w stan bezpieczeństwa środowiska danych posiadacza karty (CDE). Testy są tańsze, wymagają mniej zasobów i są bardziej usprawnione.

Różnica między testami penetracyjnymi a skanowaniem podatności

Testy penetracyjne to nie to samo, co skanowanie podatności.

Celem skanowania podatności jest zidentyfikowanie, ocena i zgłoszenie słabych punktów, które mogą zagrozić Twoim systemom. Ogólnie rzecz biorąc, firmy powinny przeprowadzać oceny podatności na zagrożenia co kwartał lub po wprowadzeniu istotnych zmian w środowisku danych posiadaczy kart. Skany podatności są często przeprowadzane przy użyciu zautomatyzowanych narzędzi, a następnie są uzupełniane ręcznymi procesami weryfikacji.

Z drugiej strony celem testu penetracyjnego jest wykorzystanie systemu w poszukiwaniu luk w zabezpieczeniach. Testy penetracyjne to celowy proces próby złamania bezpieczeństwa CDE lub systemu sieciowego. Proces trwa dłużej, jest bardziej ręczny i zapewnia kompleksowy przegląd stanu bezpieczeństwa systemu sieciowego. Testy penetracyjne należy przeprowadzać co roku, a nie co kwartał.

Zakres środowiska danych posiadacza karty (CDE)

PCI DSS definiuje środowisko danych posiadacza karty jako technologię, ludzi i procesy zaangażowane w przesyłanie, przetwarzanie i przechowywanie poufnych informacji o kartach kredytowych. Testy penetracyjne powinny obejmować wszystkie systemy i procesy, które obsługują dane posiadaczy kart.

Pierwszy test penetracyjny ocenia dostępność sieci publicznych Twojej organizacji. Oceny należy dokonać we wszystkich systemach i procesach, które mają dostęp do zastrzeżonych danych posiadaczy kart. Następnie należy ocenić wewnętrzne systemy organizacyjne, które mają dostęp do poufnych informacji o kartach kredytowych.

Testy penetracyjne powinny obejmować nie tylko systemy, ale także procesy, które uzyskują dostęp do sieci firmy. Jeśli część danych posiadacza karty jest przechowywana poza środowiskiem CDE, systemy należy przetestować, aby upewnić się, że nie mają żadnych luk, które mogłyby narazić systemy wewnętrzne na infiltrację przez nieautoryzowanych użytkowników.

Wreszcie, wszelkie systemy „poza zakresem”, które są używane do przechowywania, przesyłania lub przetwarzania danych posiadaczy kart, również powinny zostać przetestowane, aby upewnić się, że są bezpieczne.

Ocena systemów krytycznych

Według PCI DSS, krytyczne systemy odnoszą się do infrastruktury, sprzętu i procesów, które obsługują dane posiadaczy kart. Systemy mogą być urządzeniami dostępnymi publicznie, konfiguracjami zabezpieczeń i ogólnym sprzętem, który może przechowywać, przesyłać i przetwarzać informacje o kartach kredytowych.

Testy penetracyjne mogą być przeprowadzane na różnych elementach systemu obsługi kart kredytowych, w tym między innymi na firewallach, serwerach przekierowań e-commerce, usługach uwierzytelniania, systemach wykrywania/zapobiegania włamaniom. Wszystkie te zasoby technologiczne, wraz z tymi, do których uzyskują dostęp uprzywilejowani użytkownicy i którymi nimi zarządzają, należą do systemów o znaczeniu krytycznym.

Różnica między testowaniem w warstwie aplikacji a testowaniem w warstwie sieci

Ostatnie ataki na infrastrukturę kart kredytowych koncentrowały się na wykorzystaniu luk w warstwach aplikacji.

Wiele firm korzysta ze starszych aplikacji, aplikacji internetowych, aplikacji mobilnych, komponentów typu open source oraz oprogramowania opracowanego we własnym zakresie w ramach infrastruktury przetwarzania płatności. Testowanie w warstwie aplikacji polega na próbie penetracji aplikacji używanych przez organizację poprzez wykorzystanie ich luk w zabezpieczeniach.

Z drugiej strony, testowanie w warstwie sieciowej obejmuje pomiar integralności urządzeń, które są częścią sieci organizacji. Na przykład testowanie może polegać na próbie włamania się do przełączników, routerów, zapór ogniowych i serwerów, wykorzystując ich słabości. Typowe luki, które mogą znajdować się w warstwie sieci, obejmują źle skonfigurowane urządzenia, domyślne hasła i niezałatane systemy.

Testy warstwy aplikacji i sieci wymagane przez PCI DSS

Aby zachować zgodność z PCI DDS, organizacje muszą testować uwierzytelnianie, aplikacje zgodne z PA-DSS, aplikacje internetowe i oddzielne środowisko testowe.

1. i) Uwierzytelnianie. Tutaj firmy muszą dokonać przeglądu ról i dostępu do środowiska swoich pracowników. Ponadto powinni zapewnić klientom dostęp tylko do ich danych. Podczas przeprowadzania testów penetracyjnych należy ocenić zarówno kontrole klientów posiadacza karty, jak i kontrole użytkownika pracodawcy.
2. ii) Aplikacje zgodne z PA-DDS. Te aplikacje nie muszą być testowane, ale ich implementacja powinna. Testy powinny koncentrować się na odsłoniętych usługach i systemach operacyjnych, a nie na funkcjonalności systemu płatniczego.

iii) Aplikacje internetowe. W przypadku firm, które korzystają z aplikacji innych firm lub aplikacji komercyjnych, bardzo ważne jest, aby programy zostały prawidłowo zaimplementowane, zabezpieczone i skonfigurowane.

Powyższe stanowi przegląd testów penetracyjnych PCI DSS.

Ken Lynch to weteran tworzenia oprogramowania dla przedsiębiorstw, który zawsze był zafascynowany tym, co motywuje pracowników do pracy i jak sprawić, by praca była bardziej angażująca. Ken założył Reciprocity, aby to osiągnąć. Napędzał sukces Reciprocity dzięki temu celowi opartemu na misji, jakim jest zaangażowanie pracowników w cele związane z zarządzaniem, ryzykiem i zgodnością ich firmy, aby stworzyć bardziej społecznie nastawionych obywateli korporacyjnych. Ken uzyskał tytuł licencjata w dziedzinie informatyki i elektrotechniki na MIT.