Jak przygotować firmę do testu penetracyjnego?

Test penetracyjny kupuje się w dniach pracy. Każda godzina, w której tester czeka na hasło albo ustala, czy dany serwer jest w zakresie, to godzina, w której nie szuka podatności. Poniżej lista rzeczy, które warto mieć gotowe przed pierwszym dniem testów.

1. Ustal, po co to robicie

Brzmi banalnie, a rozstrzyga o kształcie całego testu. Inaczej wygląda test pod wymóg kontrahenta, inaczej przed wdrożeniem nowej aplikacji, a jeszcze inaczej po incydencie.

Jeśli powodem jest wymóg zewnętrzny, poproś o dokładne brzmienie wymagania i przekaż je firmie testującej. Zdarza się, że kontrahent oczekuje czegoś konkretnego - określonego standardu, zakresu albo formy zaświadczenia - i lepiej wiedzieć o tym przed testem niż po.

2. Zdefiniuj zakres precyzyjnie

Zakres to lista konkretów, nie ogólne hasła. Zamiast "nasza aplikacja" - adresy środowisk, domeny i subdomeny, zakresy IP, punkty końcowe API, aplikacje mobilne wraz ze sposobem ich dostarczenia testerowi.

Równie ważne jest to, co poza zakresem: systemy zewnętrznych dostawców, na które nie macie praw, środowiska produkcyjne klientów, integracje osób trzecich. Ustalcie też, czy dopuszczacie testy destrukcyjne i socjotechnikę wobec pracowników - jedno i drugie wymaga osobnej zgody.

3. Przygotuj konta testowe

Najczęstsza przyczyna opóźnień. Zasada jest prosta: po dwa konta na każdą rolę w systemie.

Dwa, bo spora część istotnych błędów to sytuacje, w których użytkownik A widzi dane użytkownika B. Bez drugiego konta w tej samej roli tego się porządnie nie sprawdzi. Jeśli macie role gość, klient, pracownik i administrator, to osiem kont gotowych na start.

Zadbaj, żeby konta były aktywne, miały ustawione hasła i nie wygasały w połowie testów. Jeśli logowanie wymaga drugiego składnika, ustal z góry, jak tester ma go obsłużyć.

4. Zamknij kwestie formalne

Bez pisemnej autoryzacji testy nie powinny się zacząć. Poza umową i NDA potrzebna jest zgoda podpisana przez osobę uprawnioną, określająca zakres i okno czasowe. To dokument, który chroni obie strony.

Sprawdź też, czy infrastruktura należy do Was. Testowanie systemów w cudzej chmurze albo u dostawcy hostingu może wymagać jego zgody albo zgłoszenia. Warunki różnią się między dostawcami i lepiej to sprawdzić wcześniej niż tłumaczyć się później.

5. Przygotuj infrastrukturę

• Wyjątki na zabezpieczeniach. WAF, filtry antybotowe i systemy blokujące adresy IP potrafią zablokować testera po kilkunastu minutach. Ustalcie, czy testujemy z wyjątkiem (sprawdzamy wtedy samą aplikację), czy bez (sprawdzamy też skuteczność ochrony). Oba warianty mają sens, ale trzeba wybrać świadomie.
• Limity zapytań. Agresywne limitowanie potrafi wydłużyć testy kilkukrotnie. Rozważcie podniesienie ich dla adresów testera.
• Kopia zapasowa. Aktualna i sprawdzona, zwłaszcza przy testach na produkcji.
• Monitoring. Uprzedźcie zespół albo dostawcę usług monitorowania, żeby nie uruchamiać procedury reagowania na incydent z powodu zaplanowanego testu.

6. Ustal komunikację

Wskaż jedną osobę kontaktową dostępną w czasie testów, z numerem telefonu. Potrzebna jest natychmiast, jeśli coś przestanie działać albo tester natrafi na coś krytycznego, czego nie można zostawić do raportu.

Ustalcie też ścieżkę awaryjną: co się dzieje, gdy test wywoła awarię, kto podejmuje decyzję o przerwaniu i jak szybko można się skontaktować poza godzinami pracy.

Osobna decyzja: czy zespół ma wiedzieć o teście. Jeśli chcecie sprawdzić przy okazji, czy Wasz monitoring w ogóle zauważy atak, poinformujcie jak najmniejszą liczbę osób. Jeśli zależy Wam wyłącznie na znalezieniu podatności, uprzedzenie zespołu oszczędza nerwów.

7. Środowisko: produkcja czy testowe

Środowisko testowe jest bezpieczniejsze, ale ma sens tylko wtedy, gdy faktycznie odpowiada produkcji - tą samą wersją kodu, konfiguracją i zestawem integracji. Test na środowisku sprzed pół roku daje wyniki, które niewiele mówią o realnym stanie.

Jeśli takiego środowiska nie ma, testy na produkcji są normalną praktyką - z zachowaniem ostrożności, w uzgodnionych godzinach i z aktualną kopią zapasową.

Czego nie robić

Nie łatajcie w trakcie testów. Kuszące, gdy przychodzi informacja o krytycznej podatności, ale zmiana systemu w czasie testu psuje wyniki: tester nie wie, czy coś przestało działać przez poprawkę, czy przez błąd. Poprawki wdraża się po teście, a potwierdza retestem.

Nie sprzątajcie na ostatnią chwilę. Wyłączanie usług i kasowanie starych kont tuż przed testem daje obraz stanu, którego nie ma na co dzień. Zapłacicie za sprawdzenie fikcji.

Nie zawężajcie zakresu do rzeczy, których jesteście pewni. Zrozumiały odruch, ale odwrotny do celu. Najciekawsze znaleziska są zwykle tam, gdzie nikt nie zaglądał od lat.

Po teście

Raport to początek, nie koniec. Zaplanujcie z góry, kto go przeczyta, kto odpowiada za poprawki i kiedy odbędzie się retest - najlepiej ustalony już na etapie umowy.

Przy priorytetyzacji nie idźcie wyłącznie za oceną krytyczności z raportu. Ta sama podatność znaczy co innego w systemie dostępnym z internetu, a co innego w narzędziu wewnętrznym dla trzech osób. Dobry raport podpowiada kolejność, ale ostateczna decyzja zależy od Waszego kontekstu.

Lista kontrolna

• Cel testu i ewentualne brzmienie wymagania zewnętrznego
• Zakres: co wchodzi, co jest wyłączone, czy dopuszczamy testy destrukcyjne i socjotechnikę
• Po dwa konta na każdą rolę, aktywne i z ustalonym drugim składnikiem
• Umowa, NDA i pisemna autoryzacja testów
• Zgoda dostawcy chmury lub hostingu, jeśli wymagana
• Decyzja o wyjątkach na WAF i limitach zapytań
• Aktualna kopia zapasowa
• Osoba kontaktowa z telefonem i ścieżka awaryjna
• Decyzja, kto w firmie wie o teście
• Ustalony termin retestu

Jeśli któryś punkt budzi wątpliwości, to dobry temat na rozmowę przed podpisaniem umowy. Zobacz też, od czego zależy cena testu i czym pentest różni się od audytu.