Jak daleko mógłby dotrzeć atakujący?

Test prowadzony z internetu odpowiada na inne pytania niż sprawdzenie ze zwykłego konta wewnętrznego. Wspólnie ustalamy, jaki scenariusz ma być rozpatrywany i jakie uprawnienia są dostępne na początku. Z tej sytuacji wyjściowej wynika dozwolony zakres. Systemy, adresy i tożsamości są dokumentowane; wspólnie użytkowane usługi i systemy podmiotów trzecich wymagają szczególnej uwagi. Takie planowanie zapobiega sytuacji, w której z powodu niejasnego podziału odpowiedzialności badanie niezamierzenie wykroczyłoby poza udzielone zatwierdzenie.

Do przygotowania należą również warunki eksploatacyjne. Ustalane są osoby kontaktowe, okna czasowe i kryteria przerwania. Zmiany w systemach, testy obciążeniowe lub dalej idące działania nie są domyślnie częścią każdego pentestu. Muszą być wyraźnie objęte uzgodnioną procedurą. Wyniki wskazują następnie rzeczywistą pozycję wyjściową i sprawdzoną wersję. To ułatwia interpretację: podatność zaobserwowana przy posiadanych już uprawnieniach administracyjnych ma inną wymowę niż dowód uzyskany z nieuprzywilejowanego punktu wyjściowego.

Sama segmentacja sieci nie opisuje jeszcze wszystkich możliwości dostępu. Konta użytkowników, konta usług i ścieżki administracyjne mogą tworzyć inne połączenia między systemami. Sprawdzenie analizuje więc w zatwierdzonych ramach, czy granice techniczne i role faktycznie wymuszają zamierzony model. Poszczególne błędy konfiguracji są oceniane w powiązaniu z ich skutkiem. Ustalenie ma pokazać, dlaczego jest istotne dla Państwa środowiska i jakie warunki muszą być spełnione dla wykazanego dostępu.

W środowiskach IaaS dochodzi jeszcze kwestia rozgraniczenia odpowiedzialności względem dostawcy. Przedmiotem badania mogą być zasoby i konfiguracja, za które odpowiada klient; nie oznacza to automatycznego zatwierdzenia wspólnie użytkowanych usług platformy. Przed sprawdzeniem wyjaśniane są niezbędne prawa i wymagania. Może to dotyczyć również podłączonych lokalizacji i aplikacji. Dlatego planowanie łączy osoby odpowiedzialne za chmurę i infrastrukturę, aby test pozostał przejrzysty, a jego skutki można było kontrolować w uzgodnionych ramach.

Wynik oddziela potwierdzone ustalenia, wskazówki i obszary niesprawdzone. Dowody opisują niezbędne warunki i zaobserwowany skutek. Mają one umożliwić ocenę bez niepotrzebnego gromadzenia wrażliwych danych. Kierownictwo i zespoły techniczne otrzymują odpowiednio przygotowane opracowanie; szczególnie istotne obserwacje są przekazywane uzgodnionymi ścieżkami zgłaszania. W ten sposób pentest staje się czymś więcej niż eksportem zgłoszeń technicznych: osoby odpowiedzialne mogą zdecydować, które działania należy wdrożyć w pierwszej kolejności.

W naprawę może być zaangażowanych kilka zespołów, na przykład zarządzanie tożsamością, eksploatacja sieci i opieka nad aplikacjami. Dlatego rekomendacje są omawiane wraz z ich zależnościami. Retest koncentruje się na uzgodnionej, zmienionej wersji i dokumentuje, czy konkretne ustalenie nadal daje się wykazać. Wynagrodzenie uzależnione od sukcesu można dla odpowiedniego, jasno zdefiniowanego celu uregulować w modelu Result as a Service. Dozwolony zakres testów pozostaje przy tym wiążący i nie jest rozszerzany ze względu na zachętę ekonomiczną.