Jak przygotować się do pierwszego testu penetracyjnego
Większość wartości testu penetracyjnego zyskuje się lub traci zanim cokolwiek zostanie wpisane na klawiaturze. Zespół, który zaczyna pracę przy nieokreślonym zakresie, braku kont testowych i zdenerwowanym szefie zespołu inżynieryjnego, spędzi pierwsze dwa dni na logistyce zamiast na szukaniu tego, za co mu zapłacono. Jeśli to Twój pierwszy test, kilka godzin przygotowań zapewni Ci odczuwalnie lepszy rezultat. Oto lista kontrolna, którą chcielibyśmy widzieć w rękach każdego nowego klienta.
Wiedz, dlaczego wykonujesz testy
Wszystko inne wynika z tej decyzji. Czy testujesz, ponieważ wymaga tego umowa z klientem lub audytor, czy pytał o to ubezpieczyciel, czy naprawdę chcesz wiedzieć, na ile jesteś narażony? Test nastawiony na zgodność może mieć zakres podyktowany przez normę. Test nastawiony na ryzyko powinien być skierowany na to, co zabolałoby najbardziej w przypadku awarii lub przejęcia. Zapisz swój powód w jednym zdaniu. Rozstrzygnie to dziesiątki późniejszych sporów o to, co znajduje się w zakresie.
Zdefiniuj zakres na piśmie
Zakres to najważniejszy element wejściowy. Jest to dokładna lista tego, co testerzy mogą badać: które domeny, które aplikacje, które zakresy IP, które API oraz które techniki są wykluczone. Otwarty standard Penetration Testing Execution Standard (PTES) nie bez powodu traktuje ten krok przedwdrożeniowy jako osobną fazę, ponieważ nieprecyzyjny zakres prowadzi do nieprecyzyjnego testu.
Bądź precyzyjny i szczery w kwestii granic. Jeśli system jest zarządzany przez dostawcę zewnętrznego, zazwyczaj nie możesz autoryzować testów bez jego zgody, a żaden ceniony tester nie zaatakuje go tylko na Twoje słowo. Zdecyduj, co wchodzi w zakres, a co z niego wyleci, a następnie utrwal to na piśmie i podpisz. Ten dokument, często nazywany rules of engagement, chroni Ciebie w takim samym stopniu, jak testerów.
Wybierz środowisko: produkcyjne czy stagingowe
Otrzymasz pytanie, czy testować środowisko produkcyjne, czy kopię stagingową. Oba rozwiązania mają swoje wady i zalety.
- Produkcja to prawdziwy system, więc podatności są rzeczywiste, ale istnieje niewielkie ryzyko, że testy spowodują spowolnienia lub skutki uboczne. Dobre zespoły testujące pracują ostrożnie, ale i tak należy to uwzględnić w planach.
- Staging jest bezpieczniejszy do intensywnych testów, ale przydatny tylko wtedy, gdy wiernie odzwierciedla produkcję. Środowisko stagingowe spóźnione o trzy wersje, z fikcyjnymi danymi i inną konfiguracją, generuje wyniki, które mogą nie mieć zastosowania do systemu używanego przez klientów.
Jeśli wybierzesz staging, upewnij się, że jest to wierna kopia. Wprowadzające w błąd środowisko jest gorsze niż nieznacznie ryzykowne środowisko produkcyjne.
Przygotuj dostęp i konta testowe
Jeśli chcesz, aby test objął działania zalogowanego użytkownika lub klienta (a prawie zawsze warto), testerzy potrzebują działających poświadczeń. Testy bez uwierzytelnienia sięgają tylko do drzwi wejściowych. Większość prawdziwych szkód powstaje po zalogowaniu.
Przed rozpoczęciem testu przygotuj:
- Konta użytkowników dla każdej istotnej roli: zwykłego użytkownika, administratora oraz wszelkich ról pośrednich.
- Więcej niż jedno konto na rolę, aby testerzy mogli sprawdzić, czy jeden użytkownik może uzyskać dostęp do danych innego użytkownika.
- Wszelkie klucze API, tokeny lub dokumentację niezbędne do korzystania z aplikacji tak, jak robi to rzeczywisty klient.
- Informację o wszystkim, co może wywołać blokady konta, naliczanie opłat lub wysyłkę wiadomości e-mail, aby uniknąć niespodzianek.
Ustal harmonogram i komunikację
Uzgodnij okno testowe oraz listę powiadomionych osób. Wskaż jednego kontaktowego inżyniera, który szybko odpowie na pytania i ma uprawnienia do przerwania testu jedną wiadomością, jeśli coś pójdzie nie tak.
Zdecyduj z wyprzedzeniem, co zrobić z własnymi mechanizmami obronnymi. Jeśli WAF lub system monitorowania będzie blokować ruch testowy lub zgłaszać alerty, należy ustalić z testerami, czy dodać ich adresy na listę dozwolonych. Zapora, która po prostu zablokuje test, może ukryć podatności znajdujące się za nią. Uprzedź zespoły utrzymania i wsparcia, aby gwałtowny wzrost nietypowego ruchu nie wywołał alarmu bojowego o 3 rano.
Przygotuj dokumentację
Testerzy szybciej wchodzą w temat, gdy dostarczysz im kontekst. OWASP Web Security Testing Guide, powszechnie stosowana otwarta metodologia, traktuje zbieranie informacji jako fundament dobrego testu. Możesz skrócić tę fazę, udostępniając przegląd architektury, dokumentację API, listę ról użytkowników oraz uwagi o czymś nietypowym lub podatnym na awarie. Nie wykonujesz pracy za nich, upewniasz się jedynie, że ich czas zostanie przeznaczony na szukanie problemów, a nie na ponowne odkrywanie architektury aplikacji.
Oprzyj się pokusie porządkowania
Częstą pokusą przed pierwszym testem jest szybkie załatanie i posprzątanie wszystkiego, aby raport wyglądał dobrze. Nie rób tego. Celem jest poznanie rzeczywistego stanu, a nie przygotowanie reżyserowanego pokazu. Usuwanie znanych problemów jest ogólnie wskazane, ale nie ukrywaj ani nie wyłączaj elementów wyłącznie po to, by uniknąć ich przetestowania. Płaciłbyś wtedy tylko za okłamywanie samego siebie.
Wiedz, co otrzymasz na koniec
Ustal zakres produktów końcowych przed pierwszym dniem: pisemny raport z kategoryzacją podatności i jasnymi krokami do odtworzenia, a najlepiej także spotkanie omówieniowe. Zapytaj, czy retest poprawek jest w cenie, czy wymaga dopłaty, ponieważ podatność nie jest zamknięta, dopóki ktoś nie potwierdzi, że poprawka naprawdę działa.
Tańszy pierwszy krok, jeśli nie jesteś jeszcze gotowy
Jeśli pełny test penetracyjny wydaje się zbyt dużym pierwszym zobowiązaniem, uzasadnione jest rozpoczęcie od mniejszego kroku i poznanie ekspozycji zewnętrznej. Temu właśnie służy nasza weryfikacja za $100: ukierunkowane spojrzenie na zewnętrzną powierzchnię ataku, w zakresie potwierdzonym jako Twoja własność i autoryzowanym na piśmie, przeanalizowane przez doświadczonego specjalistę i podsumowane podczas 30-minutowej rozmowy.
Miej jasność co do tego, czym to jest, a czym nie jest. Ta weryfikacja to wstępny wgląd, a nie pełna usługa i nie zadowoli audytora, który wymagał testu penetracyjnego. Pokaże Ci jednak, co widzi napastnik z zewnątrz i pomoże właściwie określić zakres właściwego testu, dzięki czemu przystąpisz do niego w pełni przygotowany.
Powiązane artykuły
Zacznij od wstępnego wglądu.
Przed pełnym audytem nasza weryfikacja za $100 pokazuje, co widzi napastnik z zewnątrz, dzięki czemu przystępujesz do testów przygotowany. Nie zastąpi ona pełnego pentestu i otwarcie o tym informujemy.
Zamów weryfikację za $100