W 2004r. branża kart płatniczych wprowadziła standard ochrony informacji PCI DSS (Payment Card Industry Data Security Standard). Sprzedawcy akceptujący karty płatnicze i wszystkie inne organizacje uczestniczące w autoryzacji lub rozliczaniu płatności kartowych są zobowiązane do wdrożenia PCI DSS. Nadzór nad procesem wdrożenia musi być sprawowany przez organizacje kart płatniczych tj. Visa, Mastercard, Amex, etc. ponieważ PCI DSS jest standardem pozarządowym.
Przed wprowadzeniem PCI DSS mieliśmy do dyspozycji wiele dojrzałych standardów dla systemów zarządzania bezpieczeństwem informacji: BS-7799, ISO-27001, ISO-13335 i AS/NZS 4360. Dlatego warto zastanowić się co zmusiło branżę kart płatniczych do wprowadzenia swojego standardu.
Wdrożenie PCI DSS ma zapewnić poufność danych kartowych (numer karty, imię i nazwisko, data ważności i kod serwisów). Jeśli firma obsługuje płatności kartowe i uzyskała certyfikat zgodności z ISO-27001, to co stoi na przeszkodzie aby danym kartowym nadać dostatecznie wysoką klauzulę poufności i chronić je w ramach istniejącego systemu bezpieczeństwa IT? Dlaczego organizacje kart płatniczych nie akceptują takiego rozwiązania?
Analiza odmienności PCI DSS i metod weryfikacji zgodności ze PCI DSS ułatwia dostrzeżenie słabości dotychczasowych standardów. Moim zdaniem są to:
- ignorowanie faktu, że idea klasyfikacji poufności informacji nie pasuje do współczesnych systemów informatycznych
- nadmierna swoboda w interpretacji wymogów standardów
- audyt certyfikacyjny systemu zarządzania bezpieczeństwem informacji jest bardzo słabą gwarancją jego jakości i skuteczności
Klasyfikacja informacji poufnych
Elementarnym wymogiem dominujących standardów jest nadawanie informacjom elektronicznym różnych klauzul poufności. Im wyższa klauzula poufności tym silniejsze zabezpieczenia. Jednak bez przekroczenia granic zdrowego rozsądku nie da się skutecznie różnicować siły zabezpieczeń poufności w ramach środowiska teleinformatycznego zbudowanego na bazie Windows lub unix.
Autorzy PCI DSS to rozumieją i zamiast postulować nadanie danym kartowym wysokiej klauzuli poufności każą oddzielić środowisko teleinformatyczne, w którym dane kartowe występują od reszty infrastruktury IT. Separacja może być fizyczna lub logiczna. Ważne żeby była skuteczna. Wymogi PCI DSS dotyczą tylko środowiska IT z danymi kartowymi.
Wymóg klasyfikowania poufności informacji ma ograniczony sens nawet w przypadku silnie zhierarchizowanych organizacji jakich nie spotykamy w świecie biznesu. O absurdach klasyfikacji informacji wynikających z ustawy o ochronie informacji niejawnych pisałem w: Czy tajemnice państwowe służą Polsce?
Interpretacja wymogów standardów
Wymogi istniejących standardów są na tyle ogólne, że bez uwzględnienia specyfiki danego środowiska nie można ani ocenić ich przydatność ani określić sposobu implementacji. W dominujących standardach podstawą interpretacji wymogów są wyniki analizy ryzyka. Jednak istniejące metody analizy ryzyka nie sprawdzają się w świecie IT. Jeśli różne osoby użyją tej samej metody to jest bardzo prawdopodobne, że uzyskane zbiory zagrożeń i ryzyk będą rozbieżne w stopniu trudnym do zaakceptowania.
Specjaliści od bezpieczeństwa IT niechętnie akceptują pogląd, że analiza ryzyka w świecie cyfrowym jest raczej sztuką niż metodą a w konsekwencji jakość rezultatu zależy bardziej od osoby niż od metody. Proces wdrożenia PCI DSS nie obejmuje analizy ryzyka.
W PCI DSS wymogi są precyzyjne a większość z nich dotyczy konkretnych mechanizmów bezpieczeństwa. Ma być np. IDS/IPS, dwuczynnikowe uwierzytelnienie dla zdalnych użytkowników, konkretny sposób zbierania logów, konkretny sposób synchronizowania zegarów, maksymalny czas opóźnienia dla instalacji łat, etc. Całość tworzy spójny system mechanizmów bezpieczeństwa o dość uniwersalnym charakterze.
Audytor rzecznikiem interesów klienta
Aby uzyskać certyfikat zgodności z ISO-27001 trzeba zakupić audyt u odpowiedniego specjalisty. Zwykle jest to ten sam specjalista, który pomagał wdrożyć wymogi standardu i przygotować odpowiednią dokumentację. Gdyby w trakcie prac przygotowawczych nie był wystarczająco elastyczny i nie okazywał zrozumienia dla różnych uwarunkowań i humorów, to szybko zrezygnowanoby z jego usług. Jeśli zaakceptował wiele kompromisów, to klient ma gwarancję, że w trakcie audytu certyfikującego niedociągnięcia będą interpretowane na jego korzyść a audytor ma gwarancję, że bez problemu otrzyma zapłatę.
Z mojego doświadczenia wynika, że w ponad 90% przypadków głównym powodem starania się o certyfikację ISO-27001 nie jest chęć niezależnego sprawdzenia adekwatności i jakości wdrożenia standardu tylko potrzeby marketingowo-wizerunkowe. Faktycznym celem projektu jest uzyskanie certyfikacji a nie zbudowanie skutecznego systemu bezpieczeństwa.
Większość osób odpowiedzialnych za bezpieczeństwo IT popiera „marketingowy” projekt certyfikacyjny mimo niedostatecznego budżetu na właściwe wdrożenie standardu. Jest to zrozumiałe. Jak wystąpi incydent z poważnymi konsekwencjami, to można będzie się tłumaczyć, że system bezpieczeństwa był dobry bo uzyskał certyfikat. Zatem przyczyną incydentu musiał być niemożliwy do przewidzenia i wyjątkowo pechowy zbieg okoliczności.
W PCI DSS zrezygnowano z idei samodzielnego audytora. Audytor musi być zatrudniony w firmie, która uzyskała akceptację PCI Council. Zatem odpowiedzialność za jego pracę w większym stopniu ponosi firma niż on sam. Rzetelny ale niekorzystny dla klienta wynik audytu certyfikującego nie ma dużego wpływu na zarobki audytora.
Z drugiej strony organizacje kart płatniczych ustanowiły kary pieniężne dla agentów autoryzacyjno-rozliczeniowych (acquirer) za wyciek danych kartowych z systemów sprzedawców, których obsługują. Agenci także bezpośrednio kontrolują wdrożenie PCI DSS u sprzedawców. W takich okolicznościach audytor tylko w niewielkim stopniu może sprzyjać klientowi.
