Testy penetracyjne wymuszone zgodnością
Większość testów penetracyjnych kupuje się dlatego, że wymaga ich regulacja. To norma wyznacza zakres, częstotliwość oraz — część najczęściej niedoceniana — dowody, które trzeba będzie potem przedstawić. Ta strona porównuje reżimy, pod które testuję, abyście rozpoznali ten, który naprawdę Was dotyczy.
Porównanie norm
Każdy z tych reżimów nakazuje niezależne testy bezpieczeństwa albo faktycznie ich wymaga. Różnice, które mają znaczenie: kogo wiąże, jak często i co trzeba potem wykazać.
Arabia Saudyjska
- NCA Essential Cybersecurity Controls (po angielsku) — krajowa podstawa dla podmiotów publicznych, ich wykonawców i infrastruktury krytycznej. Kontrola 2-11 obejmuje testy penetracyjne: zdefiniowane, udokumentowane, zatwierdzone i wdrożone, z zakresem obejmującym co najmniej usługi wystawione do internetu i infrastrukturę techniczną za nimi. Okresowo.
- NCA Critical Systems Cybersecurity Controls — gdy systemy zaklasyfikowano jako krytyczne, częstotliwość rośnie do co najmniej raz na sześć miesięcy. To właśnie ta zmiana rytmu zwykle wywraca założenie budżetowe.
- SAMA Cyber Security Framework (po angielsku) — banki, ubezpieczyciele, firmy finansowe i dostawcy usług płatniczych nadzorowani przez saudyjski bank centralny. Niezależne testy zewnętrzne co najmniej raz w roku, obejmujące systemy wystawione do internetu, aplikacje webowe i infrastrukturę sieciową.
Zjednoczone Emiraty Arabskie
- NESA / UAE Information Assurance Standards (po angielsku) — podmioty federalne i infrastruktura informacyjna uznana za krytyczną. Oceny podatności i testy penetracyjne są przeprowadzane i monitorowane, w praktyce corocznie, z udokumentowaną naprawą i dowodem ponownego testu dla ustaleń krytycznych i wysokich w wyznaczonym terminie. Audytorzy sprawdzają kwalifikacje wykonawcy.
- Dubai ISR (DESC) — podmioty publiczne Dubaju i ich dostawcy. Działa równolegle z NESA; jedno zlecenie może udokumentować oba.
- CBUAE, DFSA i ADGM (po angielsku) — banki i firmy finansowe onshore, spółki DIFC, spółki ADGM. We wszystkich trzech przypadkach oczekiwane są regularne testy niezależne.
- VARA — dostawcy usług w zakresie aktywów wirtualnych w Dubaju. Niezależny test penetracyjny co najmniej raz w roku na mocy Technology and Information Rulebook, a także testy oparte na wywiadzie, gdy VARA uzna to za proporcjonalne.
- ADHICS (po angielsku) — podmioty ochrony zdrowia w Abu Zabi i ich dostawcy technologii.
Międzynarodowe
- PCI DSS — dla każdego, kto przechowuje, przetwarza lub przesyła dane posiadaczy kart. Wymóg 11.4 nakazuje wewnętrzne i zewnętrzne testy penetracyjne co najmniej raz w roku oraz po istotnych zmianach, a także testy segmentacji tam, gdzie służy ona zawężeniu zakresu.
- SOC 2 — nie jest to nakaz wprost, ale test penetracyjny to dowód, którego większość audytorów oczekuje przy CC4.1 i CC7.1, a klienci korporacyjni coraz częściej wymagają go w raporcie.
- ISO 27001 — zarządzanie podatnościami technicznymi z Załącznika A, gdzie test jest praktycznym sposobem wykazania, że kontrola działa.
Czego audytorzy naprawdę żądają
Raport jest konieczny, lecz niewystarczający. Pełny komplet dowodów tworzą cztery dokumenty, a większość organizacji przychodzi tylko z drugim:
- Dokument zakresu — co testowano, czego nie i dlaczego ten zakres odpowiadał kontroli. Test, który pominął właśnie te systemy, o które kontroli chodzi, nie przechodzi, choćby był znakomity.
- Raport — ustalenia, istotność, szczegóły odtworzenia i mapowanie na właściwe kontrole.
- Udokumentowana naprawa — co naprawiliście, kiedy i co zaakceptowaliście jako ryzyko wraz z uzasadnieniem. Akceptacja ryzyka jest dozwolona; brak zapisu decyzji — nie.
- Dowód ponownego testu — potwierdzenie, że ustalenia krytyczne i wysokie są faktycznie zamknięte, w terminie Waszej normy. Oczekiwanie 90 dni w NESA potyka najczęściej: test w jedenastym miesiącu nie zostawia miejsca na ponowny przed zamknięciem cyklu.
List atestacyjny — kto, jaki zakres, jakie daty — spina komplet i zwykle to on trafia do akt albo do klienta. Każde zlecenie tutaj zawiera taki list.
Niezależność to wymóg czytany opacznie
Kilka z tych norm używa słowa niezależny i ma ono konkretne znaczenie: testu nie może wykonać ten, kto zbudował lub eksploatuje badany system. Wewnętrzny zespół bezpieczeństwa testujący infrastrukturę własnej organizacji spełnia niektóre normy, a innych nie; zespół, który napisał aplikację i następnie ją testuje, nie spełnia żadnej.
To w dużej mierze wyjaśnia istnienie zewnętrznych konsultantów na tym rynku i warto zestawić to z Waszym konkretnym obowiązkiem, zanim uznacie, że wewnętrzne możliwości wystarczą. Pomyłka tutaj jest kosztowna, bo wychodzi na audycie, a nie przy ustalaniu zakresu.
Jak planuję zlecenie zgodnościowe
Pierwsza rozmowa dotyczy obowiązku, nie technologii: która norma, która kontrola, jaki termin i czy od ostatniego testu zmieniło się coś istotnego. Na tej podstawie zwykle jestem w stanie w jednej rozmowie powiedzieć, czy jedno zlecenie pokrywa wszystko, czemu podlegacie, i co musi zawierać zakres, by dowody przetrwały audyt.
Co otrzymujecie: stałą cenę przed rozpoczęciem, testy wykonane przez osobę, z którą rozmawialiście, natychmiastowe zgłoszenie wszystkiego, co krytyczne, zamiast niespodzianki w dokumencie końcowym, raport napisany jednocześnie dla zarządu i dla inżynierów, wsparcie w trakcie naprawy, ponowny test i list atestacyjny. Jest przykładowy raport, jeśli chcecie najpierw zobaczyć format (po angielsku), oraz strona z cenami dla rzędu wielkości.
Według regionu
Jeśli działacie w Zatoce, strony regionalne wchodzą głębiej w to, które reżimy obowiązują i jak się przenikają: testy penetracyjne w Arabii Saudyjskiej i testy penetracyjne w ZEA. Poza tym strony usług opisują samo testowanie, a kontakt to najszybsza droga do jasnej odpowiedzi.
Pytania o testy zgodnościowe
Zwykle tak i jest to znacznie tańsze niż alternatywa. Zakres techniczny w dużej mierze się pokrywa — powierzchnia zewnętrzna, aplikacje webowe i API, sieć wewnętrzna, Active Directory, chmura — więc różni się mapowanie na kontrole i forma raportu, a nie samo testowanie. Warunek jest jeden: trzeba tak zaplanować od początku. Test zakresowany wyłącznie pod PCI nie wytworzy dowodów, których oczekuje NESA, choć praca pod spodem jest niemal identyczna. Przy ustalaniu zakresu wymieńcie wszystkie reżimy, którym podlegacie, a raport powiąże ustalenia z każdym z nich.
Nie i to najczęstszy powód odrzucenia dowodów. Skaner porównuje znane sygnatury ze znanymi wersjami i zwraca listę; test penetracyjny łączy ustalenia w łańcuch i pokazuje, co ktoś mógłby z nimi naprawdę zrobić. Normy mówią to coraz wyraźniej, a audytorzy dobrze już rozpoznają raport ze skanera z okładką testu penetracyjnego — sygnałem jest to, że każde ustalenie to CVE i żadne nie łączy się z innym. Różnica szczegółowo (po angielsku).
Czterech rzeczy, a większość organizacji ma tylko drugą. Dokumentu zakresu pokazującego, co testowano i dlaczego ten zakres był właściwy. Samego raportu z ustaleniami, poziomami istotności i szczegółami odtworzenia. Udokumentowanej naprawy ustaleń krytycznych i wysokich. Oraz dowodu ponownego testu potwierdzającego, że poprawki zadziałały, w terminie wskazanym przez Waszą normę — zwykle 90 dni. List atestacyjny wskazujący, kto testował, w jakim zakresie i w jakich datach, spina całość i zwykle to właśnie ta kartka trafia do akt.
Corocznie to zwyczajowa podstawa: SAMA, NESA, VARA i PCI DSS schodzą się w tym miejscu. Dwie rzeczy skracają ten okres: klasyfikacja jako system krytyczny w ramach saudyjskich CSCC, która wymaga testów co najmniej raz na sześć miesięcy, oraz istotne zmiany. Niemal każda norma wymaga ponownego testu po materialnych zmianach w środowisku, niezależnie od tego, kiedy odbył się ostatni test roczny — duża migracja albo nowa aplikacja wystawiona do internetu faktycznie zeruje licznik.
Zwykle tak, a przyczyny są przewidywalne: zakres był zbyt wąski wobec tego, czego wymaga kontrola; test wykonał zespół, który zbudował system, więc nie był niezależny; nie powstał dowód ponownego testu; albo skan przedstawiono jako test penetracyjny. Wszystkie cztery da się naprawić, a rozwiązaniem jest zwykle jedno poprawnie zakresowane zlecenie, a nie program. Prześlijcie mi uwagę audytora i poprzedni raport, a powiem, który z czterech przypadków to był, zanim wydacie cokolwiek.
Nie wiecie, która norma Was dotyczy?
Krótka rozmowa zwykle wystarczy — i pokaże, czy jeden test może pokryć je wszystkie.