Testy penetracyjne w Zjednoczonych Emiratach Arabskich
ZEA nakładają na siebie więcej reżimów cyberbezpieczeństwa niż niemal jakikolwiek inny kraj — federalne, na poziomie emiratu, sektorowe i strefowe — i niemal wszystkie sprowadzają się do tego samego wymogu: niezależnego testu penetracyjnego, co najmniej raz w roku, z dowodami. Oto który Was dotyczy i co obejmuje test.
Mapa regulacyjna ZEA, krótko
ZEA nakładają na siebie przepisy federalne, emiratu i sektorowe. Większość organizacji objęta jest więcej niż jednym reżimem, a użyteczny wniosek brzmi: jeden dobrze zakresowany test może spełnić kilka naraz — jeśli zaplanowano go tak celowo, a nie przypadkiem.
NESA / UAE Information Assurance Standards
Podstawa federalna, mająca zastosowanie do podmiotów publicznych i do organizacji uznanych za krytyczną infrastrukturę informacyjną w energetyce, wodociągach, transporcie, telekomunikacji, usługach finansowych i ochronie zdrowia. Zarządzanie podatnościami technicznymi wymaga, by oceny i testy penetracyjne były przeprowadzane i monitorowane — w praktyce corocznie. Dwa wymogi zaskakują najczęściej: ustalenia krytyczne i wysokie wymagają udokumentowanej naprawy z dowodem ponownego testu w wyznaczonym terminie, zwykle 90 dni; oraz audytorzy sprawdzają kwalifikacje wykonawcy, przy czym deklarowanym oczekiwaniem jest OSCP lub równoważny. Strona NESA wchodzi w szczegóły (po angielsku).
Dubai ISR (DESC)
Information Security Regulation od Dubai Electronic Security Centre wiąże podmioty publiczne Dubaju oraz dostawców, którzy je obsługują. Biegnie równolegle do NESA, zamiast ją zastępować, a organizacje pracujące z rządem Dubaju muszą często wykazać oba reżimy. Wymóg testowy jest w istocie podobny, więc jedno zlecenie zakresowane pod oba daje jeden komplet dowodów.
Usługi finansowe: CBUAE, DFSA, ADGM
Bank centralny ZEA ustala oczekiwania dla banków i firm finansowych onshore; DFSA reguluje spółki w DIFC, a FSRA te w ADGM. Wszystkie trzy oczekują regularnych niezależnych testów bezpieczeństwa i wszystkie trzy niechętnie patrzą na skan podatności przedstawiony jako test penetracyjny. Szczegółowo tutaj (po angielsku).
VARA: aktywa wirtualne
Dubajski regulator aktywów wirtualnych wymaga od każdego licencjonowanego dostawcy niezależnego testu penetracyjnego co najmniej raz w roku na mocy swojego Technology and Information Rulebook, a także testów opartych na wywiadzie tam, gdzie uzna to za konieczne i proporcjonalne. Regulamin sąsiaduje z wymaganiami dotyczącymi zarządzania kluczami opartego na HSM, minimalnych poziomów przechowywania offline i zgłaszania incydentów w 24–72 godziny według wagi.
Ochrona zdrowia: ADHICS
Standard Abu Zabi dla bezpieczeństwa informacji w ochronie zdrowia dotyczy podmiotów leczniczych i ich dostawców technologii w emiracie, z wymaganiami co do testów i dowodów obok kontroli nad danymi klinicznymi. Więcej tutaj (po angielsku).
Ochrona danych
Federalna PDPL oraz odrębne ustawy DIFC i ADGM przynoszą obowiązki bezpieczeństwa wszędzie tam, gdzie przetwarzane są dane osobowe. Nie wymieniają testu penetracyjnego wprost, ale miarą są „odpowiednie środki techniczne”, a wykazanie ich po incydencie jest znacznie łatwiejsze, gdy w aktach leży świeży niezależny test.
Jeden test, wiele obowiązków
Kosztownym błędem w ZEA jest kupowanie osobnej oceny pod każdego regulatora. W większości przypadków zakres techniczny pokrywa się niemal całkowicie — powierzchnia zewnętrzna, aplikacje webowe i API, sieć wewnętrzna i Active Directory, dzierżawa chmurowa — a różni się mapowanie i forma raportu, nie testowanie.
Dlatego zlecenie zakresuje się raz wobec wszystkiego, czemu podlegacie, a raport wiąże każde ustalenie z każdą właściwą kontrolą. Zakres praktyczny:
- Sieć zewnętrzna — wszystko osiągalne z internetu, łącznie z hostami, których publikacji nikt nie pamięta.
- Aplikacje webowe i API — uwierzytelnianie, autoryzacja, logika biznesowa, wstrzyknięcia. Warstwa kliencka, o którą pyta każdy regulator.
- Sieć wewnętrzna — dokąd sięga przyczółek i czy segmentacja rzeczywiście trzyma.
- Active Directory — nadużycia ADCS, Kerberoasting, delegacja i ścieżki ACL do Domain Admin.
- Chmura — eskalacja w Entra ID i Azure RBAC, odsłonięte magazyny, błędy konfiguracji tożsamości.
Dla dostawców aktywów wirtualnych pod VARA dochodzi granica powiernictwa: infrastruktura portfeli, procesy podpisywania i kontrole operacyjne wokół materiału kluczowego — to tam dochodzi do straty, a nie w interfejsie webowym.
Wymóg kwalifikacji, konkretnie
Większość stron o zgodności przechodzi nad tym do porządku, ale w ZEA jest to niezwykle konkretne: audytorzy NESA sprawdzają, kto wykonał test, a oczekiwany jest OSCP lub równoważny. Testy wykonane przez osobę bez uznanej certyfikacji ofensywnej bywają kwestionowane, a czasem odrzucane na audycie.
Mam OSCP+ — aktualną, odnowioną formę certyfikacji — wraz z eCPPT, eWPT i eCIR po stronie ofensywnej oraz AZ-500, SC-200 i SC-300 po stronie bezpieczeństwa Microsoft, co czyni część dotyczącą Entra ID i Azure wiarygodną, a nie ogólnikową. Wszystkie są niezależnie weryfikowalne w portfelu certyfikatów OffSec, a ten odnośnik powinien znaleźć się w Waszym komplecie dowodów obok raportu.
Jak przebiega zlecenie
Najpierw zakres i wycena: podajecie obowiązek, środowisko i termin; dostajecie stałą cenę i datę startu, zwykle w ciągu jednego do dwóch tygodni. Zasady prowadzenia prac uzgadniane są na piśmie, w tym okna testowe, kontakty eskalacyjne i wszystko, co Wasz regulator narzuca co do przetwarzania lub przechowywania dowodów.
Testy trwają zwykle jeden do dwóch tygodni zależnie od zakresu, a wszystko, co krytyczne, zgłaszane jest natychmiast, zamiast czekać na dokument końcowy. Raport przychodzi w ciągu kilku dni: streszczenie, ustalenia techniczne z krokami odtworzenia i ocenami CVSS, mapowanie kontroli i priorytetyzowana naprawa. Potem ponowny test tego, co naprawiliście, i list atestacyjny — w ZEA ważniejszy, niż się sądzi, bo dowód ponownego testu w 90 dni sam w sobie jest wymogiem, a nie dodatkiem.
Pracuję zdalnie z Ammanu, godzinę za Dubajem, w tym samym rytmie tygodnia co region, po arabsku lub angielsku. Bez lokalnego biura i bez twierdzenia, że je mam — w zamian dostajecie osobę, która wykonuje pracę, bezpośrednio i z weryfikowalnymi kwalifikacjami.
Zacznijcie tutaj
Powiedzcie, przed którym regulatorem odpowiadacie i co wchodzi w zakres. Jeśli nie macie pewności — przy tylu nakładających się reżimach to zupełnie normalne — krótka rozmowa to rozstrzyga. Przegląd zgodności porównuje normy obok siebie, bezpłatny skan perymetru pokazuje bieżące odsłonięcie zewnętrzne w kilka minut, a przykładowy raport pokazuje dokładnie, co otrzymacie.
Napiszcie — zapytania po arabsku są mile widziane, a jeśli harmonogram wyznacza termin złożenia dokumentów, napiszcie o tym w pierwszym zdaniu.
ZEA: częste pytania
Z grubsza: podmioty federalne i infrastruktura informacyjna uznana za krytyczną — energetyka, woda, transport, telekomunikacja, usługi finansowe, ochrona zdrowia — podlegają Information Assurance Standards od NESA. Podmioty publiczne Dubaju i ich dostawcy podlegają ISR od DESC. Banki i firmy finansowe odpowiadają przed bankiem centralnym; spółki DIFC przed DFSA, a spółki ADGM przed FSRA; dubajscy dostawcy usług w zakresie aktywów wirtualnych przed VARA. Ochrona zdrowia w Abu Zabi podlega ADHICS. Wiele organizacji objętych jest dwoma lub trzema naraz, co zwykle nie stanowi problemu — jeden dobrze zakresowany test może dostarczyć dowodów dla wszystkich, jeśli tak go zaplanowano od początku.
Tak. Zarządzanie podatnościami technicznymi w ramach Information Assurance Standards wymaga, by oceny podatności i testy penetracyjne były przeprowadzane i monitorowane, co w praktyce oznacza co najmniej raz w roku dla objętych podmiotów. Poza samym testem liczą się dwa szczegóły: ustalenia krytyczne i wysokie wymagają udokumentowanej naprawy z dowodem ponownego testu w wyznaczonym terminie, zwykle 90 dni — test bez ponownego testu to niepełna odpowiedź. Oraz audytorzy NESA sprawdzają kwalifikacje wykonawcy, przy czym oczekiwany jest OSCP lub równoważny.
Tak. Na mocy Technology and Information Rulebook od VARA każdy licencjonowany w Dubaju dostawca usług w zakresie aktywów wirtualnych potrzebuje niezależnego testu penetracyjnego co najmniej raz w roku, a VARA może dodatkowo zażądać testów opartych na wywiadzie, gdy uzna to za konieczne i proporcjonalne. Regulamin obejmuje też zarządzanie kluczami z użyciem HSM, minimalne poziomy przechowywania offline oraz zgłaszanie incydentów w ciągu 24–72 godzin zależnie od wagi. Dla takich dostawców zakres zwykle musi sięgać dalej niż standardowy test aplikacji — infrastruktura portfeli, procesy podpisywania i granica powiernictwa skupiają rzeczywiste ryzyko.
Nie. Testy zewnętrzne, aplikacji webowych, chmury i większość testów wewnętrznych realizowane są zdalnie, co jest standardem w regionie. Sieć wewnętrzna i Active Directory obsługiwane są przez VPN albo host przesiadkowy wewnątrz Waszego środowiska. Gdy regulator albo Wasza własna polityka ogranicza miejsce przetwarzania danych lub przechowywania dowodów, trafia to na piśmie do zasad prowadzenia prac przed rozpoczęciem.
Zwykle w ciągu jednego do dwóch tygodni od uzgodnienia zakresu, szybciej gdy naciska termin złożenia dokumentów. Ponieważ angażujecie testera bezpośrednio, między podpisem a startem nie ma wewnętrznej kolejki po zasoby. Typowe zlecenie „zewnętrzne plus aplikacje webowe” to jeden do dwóch tygodni testów, a raport powstaje w ciągu kilku dni od zakończenia — harmonogram szczegółowo (po angielsku).
Macie termin wobec NESA, ISR lub VARA?
Podajcie obowiązek i zakres, a dostaniecie stałą cenę i datę startu.