Jak przygotować firmę do testu penetracyjnego - checklista od zgody do retestu

Wykonawca wybrany, termin uzgodniony. Od tej chwili wynik testu penetracyjnego zależy także od Ciebie: od tego, czy tester dostanie działające konta, czy zapora aplikacyjna (WAF) nie zablokuje go po kilku minutach, czy zespół monitorujący wie, że atak jest kontrolowany, i czy ktoś odbierze telefon, gdy tester znajdzie coś krytycznego.

Jeśli dopiero porównujesz oferty, zacznij od artykułu jak porównać oferty na testy penetracyjne, a przebieg samego testu opisujemy w artykule testy penetracyjne krok po kroku.

Przygotowanie do testu penetracyjnego w skrócie

1. 01

   Dwa tygodnie przed

   Zgoda i zasady testu, umowa i NDA, decyzje o środowisku, WAF i danych osobowych.

2. 02

   Tydzień przed

   Konta, dostępy, dokumentacja, kopia zapasowa, powiadomienia i kontakty awaryjne.

3. 03

   Start i przebieg testu

   Sprawdzenie dostępów, odpowiedzi na pytania testera, decyzje o pilnych poprawkach.

4. 04

   Po teście

   Porządki, plan poprawek, retest i dokumentacja.

Najwięcej czasu zajmują formalności oraz wyjątki w zabezpieczeniach, które w wielu firmach wymagają akceptacji w procesie zarządzania zmianą - dlatego zalecamy zacząć co najmniej dwa tygodnie przed testem. Pełna lista zadań z terminami i rolami jest w checkliście niżej.

Kto po Twojej stronie bierze udział w teście

Każdą rolę przypisz konkretnej osobie - w małej firmie jedna osoba może łączyć kilka ról:

• osoba upoważniona do wyrażenia zgody - zwykle członek zarządu albo właściciel biznesowy systemu; podpisuje zgodę i akceptuje ryzyko testu,
• koordynator testu i zastępca - punkt kontaktowy dla testera; koordynuje przekazanie dostępów i odpowiada na pytania,
• administrator lub zespół DevOps - konta, środowisko, kopie zapasowe, wyjątki w zabezpieczeniach,
• zespół monitorowania bezpieczeństwa (SOC) albo zewnętrzny dostawca usług bezpieczeństwa (MSSP) - obsługa alertów w czasie testu,
• inspektor ochrony danych (IOD) albo osoba odpowiedzialna za RODO - decyzje o danych osobowych w teście,
• dział prawny - umowa, NDA i zgody dostawców,
• właściciel produktu i programiści - dokumentacja, odpowiedzi na pytania testera, a po teście poprawki.

Zgoda na test penetracyjny i zasady testu na piśmie

Zgoda Twojej firmy nie obejmuje infrastruktury dostawców hostingu i chmury, platform SaaS ani API partnerów - tam decydują zasady dostawcy, a czasem potrzebna jest także jego zgoda. Sprawdź też, czy każdy adres IP i każda domena z listy celów naprawdę należą do Twojej firmy. Typowe pułapki to stare rekordy DNS wskazujące na serwery, z których już nie korzystasz, oraz hosting współdzielony i sieci CDN, w których adres IP należy do dostawcy.

Zasady testu (rules of engagement) - co w nich zapisać

Zasady testu opisują, jak ma on przebiegać, a umowa - co jest jego przedmiotem i na jakich warunkach. Oba dokumenty podpisuje się przed startem. Wzór zasad testu można znaleźć m.in. w dodatku B do NIST SP 800-115, a ustalenia przed testem porządkuje PTES. Zasady testu powinny obejmować:

Systemy wrażliwe - urządzenia przemysłowe i medyczne, starsze serwery, procesy obsługujące prawdziwe płatności, masowe wysyłki do klientów - wyłącz z testu albo dopuść wobec nich tylko działania pasywne, tak jak w naszych zasadach bezpieczeństwa testów infrastruktury. Każde wyłączenie zapisz wprost, z adresem lub nazwą funkcji, zamiast ogólnika „systemy krytyczne”. Stałe zasady, które stosujemy w każdym teście, opisujemy w części o gwarancji nieinwazyjności testów.

Testy penetracyjne a RODO: umowa, NDA i dane osobowe

RODO dotyczy testów penetracyjnych na dwa sposoby. Po pierwsze, test pomaga wykazać zgodność: wśród środków bezpieczeństwa rozporządzenie wymienia regularne testowanie, mierzenie i ocenianie skuteczności środków technicznych i organizacyjnych (art. 32 ust. 1 lit. d RODO). Po drugie, sam test może oznaczać przetwarzanie danych osobowych, jeśli tester zobaczy prawdziwe dane: na produkcji, w kopii danych produkcyjnych na środowisku testowym, w logach albo w repozytorium.

Najprościej testować na danych syntetycznych lub zanonimizowanych - NIST SP 800-115 zaleca rozważenie takiego wariantu, gdy test mógłby ujawnić dane osobowe. Jeśli prawdziwych danych nie da się uniknąć, z inspektorem ochrony danych ustal, czy wykonawca będzie przetwarzał je w Twoim imieniu i czy potrzebna jest umowa powierzenia.

Umowy, które podpisujemy, w tym umowę powierzenia, opisujemy na stronie modeli współpracy. Niezależnie od danych osobowych raport i dowody z testu pokazują, jak zaatakować Twój system. Dlatego przed przekazaniem dokumentacji podpisz NDA i ustal bezpieczny kanał przekazywania haseł i raportu, krąg odbiorców raportu oraz termin usunięcia danych z testu u wykonawcy.

Konta testowe, dane i dostępy

Przy teście grey box tester pracuje na kontach, które przygotujesz - od nich zależy, ile funkcji zdąży sprawdzić. Przygotuj:

• po dwa konta w każdej roli, z przypisanymi danymi (np. fakturami, zamówieniami) - dwa konta w jednej roli pozwalają sprawdzić dostęp do cudzych obiektów (IDOR), a konta w różnych rolach - eskalację uprawnień,
• uwierzytelnianie wieloskładnikowe na kontach testowych - jeśli system wymaga MFA, ustal, jak tester dostanie drugi składnik, zamiast wyłączać MFA na czas testu,
• konta, które nie wygasną w trakcie testu - sprawdź politykę haseł i blokadę konta po nieudanych próbach logowania,
• integracje w trybie testowym (sandbox) - płatności oraz wysyłkę SMS-ów i e-maili, żeby test nie obciążył prawdziwej karty ani nie wysłał wiadomości do klientów,
• dostępy z datą wygaśnięcia - ułatwią porządki po teście.

Pozostałe dostępy i dokumenty zależą od rodzaju testu: do testu API - specyfikacja i przykładowe żądania (czego potrzebujemy do testu API), do testu sieci wewnętrznej - VPN albo komputer w Twojej sieci i konto zwykłego użytkownika domeny (przygotowanie testu infrastruktury), a do testu white box - dostęp do repozytorium w trybie tylko do odczytu (jak przygotować kod do audytu).

Środowisko testowe czy produkcja

Test z zewnątrz, bez kont, zwykle ma sens na produkcji, bo liczy się to, co widzi atakujący. Funkcje, które zmieniają dane - zamówienia, płatności, wysyłki do klientów - bezpieczniej testować na środowisku testowym. NIST SP 800-115 wskazuje trzy kryteria wyboru: ryzyko dla działania produkcji, obecność danych osobowych i to, jak bardzo środowisko testowe przypomina produkcję. Oba warianty porównujemy w części o środowisku testów aplikacji webowych.

Środowisko testowe nadaje się do testu, gdy ma tę samą wersję aplikacji i konfigurację (serwer, WAF, uwierzytelnianie) co produkcja, integracje działają w trybie testowym, a nikt nie wdraża na nie zmian w trakcie testu. Wstrzymaj też wdrożenia w testowanym zakresie na produkcji, a jeśli któreś jest konieczne - uprzedź testera. Inaczej część ustaleń będzie opisywać system, którego już nie ma.

Nawet test w trybie nieinwazyjnym nie eliminuje ryzyka całkowicie, dlatego przed startem zrób kopię zapasową testowanego środowiska, sprawdź, czy da się ją odtworzyć, i ustal, kto przywraca system.

Kogo powiadomić: SOC, MSSP, hosting i chmura

W teście zapowiedzianym zespół monitorujący zna terminy i adresy IP testera. Alerty zostają włączone, ale analitycy nie blokują tych adresów ani nie eskalują alarmów wywołanych testem.

Test niezapowiedziany sprawdza wykrywanie i reakcję, więc bliżej mu do ćwiczeń typu red team. Nawet wtedy ktoś w ścieżce eskalacji musi wiedzieć o teście i móc go potwierdzić, żeby wykryta aktywność testera nie została zgłoszona na zewnątrz jako prawdziwe naruszenie. NIST SP 800-115 zaleca, by zasady testu określały, jak taką aktywność obsłużyć. Jeśli monitoring prowadzi zewnętrzny dostawca, sprawdź umowę z nim: jedni wymagają zgłoszenia testu z wyprzedzeniem, inni - szybkiego potwierdzenia, że wykryta aktywność to autoryzowany test.

Osobno sprawdź systemy u dostawców:

• hosting i centrum danych - zasady testów znajdziesz zwykle w umowie lub regulaminie; test bez zgłoszenia może skończyć się blokadą adresów testera,
• chmura publiczna - dostawcy określają, które usługi i działania wolno testować, a niektóre rodzaje testów trzeba zgłosić; zasady AWS, Azure i Google Cloud zebraliśmy w części o zasadach testów u dostawców chmury,
• platformy SaaS i API partnerów, np. bramka płatności - tylko w trybie testowym albo za zgodą dostawcy.

Uprzedź też helpdesk i osoby pełniące dyżur poza godzinami pracy.

WAF, IPS i limity: wyłączyć czy zostawić

WAF i system zapobiegania włamaniom (IPS) mogą zablokować testera po kilku minutach. Wtedy test sprawdza głównie zabezpieczenia, a nie aplikację. Masz trzy warianty:

• wyjątki dla adresów testera, logowanie i alerty włączone - test sprawdza aplikację i w tym samym czasie obejmuje najwięcej scenariuszy,
• bez wyjątków - test w dużej mierze sprawdza WAF, a część żądań testera nie dotrze do aplikacji,
• wariant mieszany - wyjątki na czas testu, a pod koniec, po ich usunięciu, powtórzenie najważniejszych ataków; pokazuje to, które ataki WAF zatrzymuje.

Wyłączanie WAF w całości zwykle nie jest potrzebne. Zdecyduj też o limitach żądań, CAPTCHA, blokadzie geograficznej i blokadzie konta po nieudanych próbach logowania. Raport powinien podawać, w jakim wariancie prowadzono test, a po teście wszystkie wyjątki trzeba usunąć.

Komunikacja w trakcie testu i krytyczne ustalenia

Ustal kanał podstawowy i awaryjny, np. telefon i szyfrowaną pocztę, oraz listę kontaktów awaryjnych po obu stronach. PTES zaleca, by - jeśli to możliwe - z każdą osobą z tej listy dało się skontaktować całodobowo na dwa sposoby.

Gdy tester znajdzie podatność krytyczną, np. dającą uprawnienia administratora w ważnym systemie, nie powinien czekać na raport - NIST SP 800-115 zaleca natychmiastowe powiadomienie osoby wskazanej w zasadach testu. Ustal z góry, kto po Twojej stronie decyduje o pilnej poprawce, i informuj testera o wdrożonych zmianach, żeby objął je retest. Zachowaj logi i dowody.

Jeśli test ujawni ślady prawdziwego ataku, uruchom procedurę obsługi incydentów - NIST SP 800-115 zaleca, by tester przerwał wtedy prace na systemach objętych incydentem. Podmiot kluczowy lub ważny ocenia też, czy to incydent poważny: wczesne ostrzeżenie przekazuje się niezwłocznie, niepóźniej niż w ciągu 24 godzin od wykrycia incydentu poważnego (art. 11 ust. 1 pkt 4 ustawy o KSC). Gdy zdarzenie dotyczy danych osobowych, sprawdź, czy to naruszenie ochrony danych osobowych, które administrator zgłasza organowi nadzorczemu (art. 33 ust. 1 RODO).

Checklista przygotowania do testu penetracyjnego

Wydrukuj tabelę albo przenieś ją do systemu zarządzania zadaniami. Terminy to nasza rekomendacja - przy dużym zakresie zacznij wcześniej.

Po teście: plan poprawek, retest i dokumentacja

Po prezentacji wyników każdemu ustaleniu przypisz właściciela i termin. Powagę podatności ocenia się zwykle w skali CVSS, a w naszych raportach zalecane terminy usunięcia zależą od poziomu ryzyka: Critical - 14 dni, High - 30 dni, Medium - 90 dni, Low - 180 dni. Ostateczne priorytety ustala Twoja firma, bo to ona akceptuje ryzyko. Po naprawach przychodzi czas na retest: tester sprawdza każdą podatność ponownie i aktualizuje raport.

Dokumentacja testu - data, zakres, metoda, wykonawca, ustalenia i podjęte działania - pozwala wykazać regularne testowanie, które RODO wymienia wśród środków bezpieczeństwa (art. 32 ust. 1 lit. d RODO). Od razu zaplanuj też kolejny test - jednorazowy albo w ramach testów cyklicznych.

Jak możemy pomóc

Testujemy aplikacje webowe i mobilne, API, infrastrukturę, chmurę i kod źródłowy - jednorazowo albo cyklicznie. Po rozmowie zakresowej (na życzenie poprzedzonej podpisaniem NDA) wspólnie ustalamy zasady testu: listę celów, konta testowe, okna czasowe i kontakty awaryjne, a test zaczynamy dopiero po pisemnej zgodzie właściciela systemu. Pracujemy w trybie nieinwazyjnym, a gdy system zachowa się niespodziewanie, natychmiast wstrzymujemy prace. Po teście dostajesz raport po polsku i angielsku, omawiamy wyniki z Twoim zespołem, a po naprawach wykonujemy retest.

Zakres i sposób pracy opisujemy na stronie o testach penetracyjnych, a od czego zależą czas i koszt testu - w cenniku testów penetracyjnych. Dobre przygotowanie skraca test, bo tester poświęca czas na szukanie podatności, a nie na czekanie na dostępy.