Begin met de vraag achter de test
Wilt u weten of een nieuwe webapplicatie veilig genoeg is voor livegang? Moet u aan een klant aantonen dat uw portaal is getest? Of wilt u weten hoe ver een aanvaller komt nadat een medewerker op een phishinglink heeft geklikt? Elke vraag leidt tot een andere scope en aanpak. Formuleer de vraag eerst en laat de pentester daarop een voorstel maken.
Kies de testvorm
De hoeveelheid informatie die de tester vooraf krijgt, bepaalt wat de test laat zien.
- Black box: de tester krijgt weinig of geen informatie en benadert de omgeving zoals een externe aanvaller.
- Grey box: de tester krijgt bijvoorbeeld testaccounts met verschillende rollen. Dit is voor webapplicaties vaak de meest efficiënte vorm.
- White box: de tester krijgt ook documentatie, configuraties of broncode. Zo worden in dezelfde tijd meer problemen gevonden.
Baken de scope precies af
Leg vast welke systemen wel en niet worden getest: domeinnamen, IP-adressen, applicaties, API’s en omgevingen. Test bij voorkeur in een acceptatieomgeving die gelijk is aan productie, maar spreek af of productie ook in scope is. Vermeld systemen van derden apart. Voor een gehoste applicatie of clouddienst hebt u soms toestemming of moet u de testregels van de leverancier volgen.
Afspraken voor tijdens de test
Leg de spelregels vast in een schriftelijke opdracht met toestemming van een bevoegde persoon. Spreek het testvenster af, de IP-adressen van waaruit wordt getest, contactpersonen aan beide kanten en een procedure om de test direct te stoppen. Bepaal ook wat er gebeurt bij een kritieke bevinding: die wilt u meestal direct horen en niet pas in het eindrapport.
Informeer de juiste mensen
Laat uw ICT-partner, hostingprovider en eventueel uw SOC weten dat er een test plaatsvindt, tenzij u juist wilt testen of een aanval wordt opgemerkt. Maak een back-up of snapshot van de testomgeving. Zorg dat testaccounts klaarstaan en na afloop worden verwijderd. Zo besteedt de pentester zijn tijd aan testen en niet aan wachten op toegang.