Test penetracyjny rozlicza się za każdy dzień pracy. Każdy dzień, w którym testerzy czekają na konto, zgadują, jak ma działać jakaś funkcja, albo blokuje ich Twoja własna zapora sieciowa, to dzień, który nie idzie na szukanie podatności. Większość tego czekania można usunąć przed startem.
Zdecyduj
Jakie jest pytanie? „Czy nowy proces płatności można bezpiecznie udostępnić” i „co może nam zrobić ktoś z internetu” prowadzą do różnych testów. Zapisz pytanie w jednym zdaniu; zakres wynika z niego.
Co jest objęte zakresem, a co nie? Wypisz aplikacje, adresy, środowiska. Wypisz też wyłączenia: dostawcę płatności, systemy spółki matki, stary system, który pada, gdy tylko ktoś na niego spojrzy.
Które środowisko? Najlepszym wyborem jest środowisko przedprodukcyjne, które odpowiada produkcyjnemu: testerzy mogą działać dokładnie, a nic prawdziwego nie jest zagrożone. Jeśli istnieje tylko środowisko produkcyjne, uzgodnij godziny testów i techniki, które są wykluczone.
Ile wiedzą testerzy? Testy z kontami i dokumentacją znajdują w ciągu dnia więcej niż testy na ślepo. Testy na ślepo odpowiadają na jedno wąskie pytanie: co osiągnie ktoś z zewnątrz bez żadnych informacji. Zdecyduj, za co płacisz.
Przygotuj
Konta. Po jednym dla każdej roli, a jeśli produkt dzieli klientów na tenanty, to w dwóch oddzielnych tenantach: kontroli dostępu między klientami nie da się przetestować na jednym kliencie. Utwórz konta przed startem, zaloguj się raz na każde z nich i sprawdź, czy zawierają realistyczne dane.
Dokumentacja. Specyfikacje API, schemat architektury, opis ról i głównych procesów. Niedoskonałe dokumenty są lepsze niż żadne.
Dostęp. Jeśli środowisko testowe jest dostępne tylko przez VPN albo z adresów z listy dozwolonych, zorganizuj dostęp z wyprzedzeniem i go przetestuj. Zdecyduj, czy zapora aplikacji webowych pozostaje włączona. Jeśli przedmiotem testu jest aplikacja, przepuść przez zaporę ruch testerów; jeśli przedmiotem testu jest zapora, zostaw ją włączoną i powiedz o tym.
Dane. Wypełnij środowisko testowe danymi, które przypominają prawdziwe strukturą, ale nie treścią. Prawdziwe dane osobowe w środowisku testowym to znalezisko, zanim test w ogóle się zaczął.
Kopie zapasowe. Upewnij się, że testowane środowisko da się przywrócić. Testerzy są ostrożni; kopie zapasowe są na wypadek, w którym ostrożność nie wystarczyła.
Powiadom
Zespół utrzymania i zespół monitoringu, chyba że test ma sprawdzić właśnie ich. Przekaż im adresy, z których pracują testerzy, i daty testów. Inaczej pierwszy dzień skończy się zablokowaniem testerów i otwarciem incydentu.
Dostawcę hostingu lub chmury, jeśli wymagają tego jego zasady. Duzi dostawcy chmury nie wymagają powiadomienia o testach Twoich własnych zasobów, prowadzonych w granicach opublikowanych przez nich zasad; mniejsze firmy hostingowe często go wymagają.
Dostawców zewnętrznych, których systemów dotyczą testy. Ich zgoda musi mieć formę pisemną.
Jedną osobę kontaktową, dostępną w godzinach testów i uprawnioną do podejmowania decyzji: przedłużyć ważność konta, ponownie uruchomić serwis, przerwać test.
Podpisz
- umowę o zachowaniu poufności (NDA), zanim przekażesz cokolwiek z powyższych;
- umowę;
- pisemne upoważnienie i zasady prowadzenia testów.
Do czego służy każdy z tych dokumentów, wyjaśnia artykuł „Co sprawia, że test penetracyjny jest legalny”.
W trakcie testu
- Nie wdrażaj zmian w testowanym środowisku bez uprzedzenia testerów. Znalezisko, które zniknęło w nocy, kosztuje dzień zamieszania.
- Nie naprawiaj znalezisk w trakcie testu, z wyjątkiem krytycznych. Jeśli jakieś naprawisz, powiedz o tym.
- Odpowiadaj szybko na pytania. Tester, który pyta, jak ma działać funkcja, zwykle coś znalazł.
- Pilnych znalezisk spodziewaj się od razu. O krytycznej podatności informuje się, gdy tylko zostanie potwierdzona, a nie w raporcie końcowym.
Po teście
- Podsumowanie czytaj z kierownictwem, znaleziska z zespołem technicznym. Są pisane dla różnych odbiorców.
- Weź udział w omówieniu wyników. To najtańsza godzina całego projektu.
- Zaplanuj poprawki według priorytetów i daj testerom znać, gdy zostaną wdrożone.
- Skorzystaj z retestu. Poprawka, której nikt nie zweryfikował, to założenie.
- Zachowaj poufność raportu. Dopóki poprawki nie są wdrożone, raport jest instrukcją, jak Cię zaatakować. Dla klientów i audytorów jest poświadczenie wykonania testów.
Lista kontrolna
| Przed startem | Zrobione |
|---|---|
| Pytanie i zakres zapisane, łącznie z wyłączeniami | |
| Środowisko wybrane, okna testowe uzgodnione | |
| Konta utworzone dla każdej roli, w dwóch tenantach, jeśli produkt je ma | |
| Dokumentacja przekazana | |
| Dostęp sieciowy zorganizowany i sprawdzony | |
| Dane testowe przygotowane, bez prawdziwych danych osobowych | |
| Kopie zapasowe zweryfikowane | |
| Zespół utrzymania, monitoring i dostawcy powiadomieni | |
| Osoba kontaktowa wskazana | |
| NDA, umowa, pisemne upoważnienie, zasady prowadzenia testów podpisane |
Na stronie każdej usługi znajdziesz listę tego, czego właśnie ten test potrzebuje od Ciebie.