Pentest scope bepalen: wat laat je testen en wat juist niet?

De pentest scope is de belangrijkste beslissing van het hele traject, en tegelijk de beslissing die het minste aandacht krijgt. Meestal wordt hij bepaald door het budget: hier is een bedrag, wat kunnen we daarvoor testen? Dat is de verkeerde volgorde, en het levert rapporten op waar je niets aan hebt.

De betere vraag is: welke vraag wil ik beantwoord hebben? Daaruit volgt de scope, en daaruit volgt de prijs. In dit artikel zet ik uiteen hoe je die afbakening maakt.

Kort samengevat

• Begin bij de vraag die je beantwoord wilt hebben, niet bij het budget of bij een lijst systemen.
• Een te brede scope levert oppervlakkig werk op; een te smalle scope mist juist het aanvalspad dat ertoe doet.
• Sluit productie niet standaard uit, want dat is doorgaans de omgeving waar het risico zit.
• Bepaal vooraf hoeveel voorkennis de tester krijgt; dat is een keuze over efficiëntie, niet over realisme.
• Neem de hertest meteen in de scope op, anders verdwijnt hij in de begroting van volgend jaar.

Wat valt er precies onder de pentest scope?

De scope legt vast wat er getest wordt en onder welke voorwaarden. Concreet gaat het om vier dingen: welke systemen, applicaties en netwerken meedoen, welke technieken zijn toegestaan, wanneer er getest wordt, en wat er expliciet buiten valt.

Dat laatste is geen bijzaak. Een scope zonder duidelijke uitsluitingen leidt tot discussie tijdens de test, precies op het moment dat je die niet kunt gebruiken.

Hoe bepaal je wat er getest moet worden?

Draai de gebruikelijke volgorde om en werk vanuit de schade.

1. Benoem het scenario dat je vreest. Klantgegevens op straat? Productie stil? Fraude in het betaalproces? Kies er één of twee.
2. Zoek de systemen die daarbij horen. Welke applicaties en koppelingen zijn nodig om dat scenario werkelijkheid te laten worden?
3. Neem de weg ernaartoe mee. Een aanvaller begint zelden bij het doelsysteem. Neem de route erbij: de externe toegang, de werkplek, de beheeromgeving.
4. Bepaal wat er echt buiten kan. Alles wat het scenario niet raakt.

Deze aanpak levert bijna altijd een andere scope op dan een lijst van systemen. En hij levert een rapport op dat je aan je directie kunt uitleggen, omdat het over een risico gaat en niet over een technische bevinding.

Welke keuzes maken je resultaat waardeloos?

• Alles tegelijk willen testen met een klein budget. Twintig applicaties in vijf dagen betekent een half uur per applicatie. Dat is een scan met een mens ernaast, geen pentest.
• Alleen de losse applicatie testen. Zonder de koppelingen en de onderliggende infrastructuur mis je precies het pad dat een aanvaller neemt.
• Productie categorisch uitsluiten. Begrijpelijk, maar een acceptatieomgeving met andere data, andere configuratie en andere rechten geeft een vertekend beeld. Maak in plaats daarvan afspraken over tijdstippen en over wat er niet mag.
• De beheeromgeving vergeten. Daar zit de hoogste privilege, en daarmee de grootste schade.
• Geen tijd inruimen voor uitwerking. Een tester die alleen mag zoeken en niet mag uitwerken, levert bevindingen zonder bewijs.

Voor het verschil tussen de testvormen zelf hebben we eerder beschreven wat een pentest is, welke types er zijn en wat het kost, en welke soorten pentesten er bestaan.

Hoeveel voorkennis geef je de tester?

Er zijn drie varianten, en de keuze is praktischer dan hij klinkt.

• Zonder voorkennis. De tester begint van buitenaf, zonder informatie. Realistisch, maar je betaalt voor de dagen die hij besteedt aan het in kaart brengen van wat jij al weet.
• Met gedeeltelijke kennis. Documentatie en gebruikersaccounts. In de meeste gevallen de beste verhouding tussen kosten en opbrengst.
• Met volledige kennis. Inclusief broncode, architectuur en beheertoegang. Levert de meeste bevindingen per dag op.

Mijn advies aan organisaties die niet jaarlijks al testen: geef informatie mee. Je koopt geen realistische aanval, je koopt bevindingen. Wil je weten of een echte aanval wordt opgemerkt, dan is dat een andere oefening met een andere opzet.

Wat leg je verder vast voordat de test begint?

Vier afspraken die achteraf gedoe voorkomen:

• Een contactpersoon aan beide kanten, bereikbaar tijdens de test.
• Een stopregel. Wat gebeurt er als de tester iets kritieks vindt, of als er onbedoeld iets uitvalt? Spreek af dat een kritieke bevinding direct wordt gemeld en niet tot het rapport wacht.
• Wie is op de hoogte. Bij een reguliere pentest normaal gesproken de beheerorganisatie, zodat niemand een echte aanval vermoedt.
• De hertest. Zet hem in dezelfde opdracht, met een datum. Zonder hertest weet je alleen dat er iets is opgepakt, niet dat het weg is.

Twijfel je of een pentest wel het juiste instrument is voor je vraag, dan is een security assessment soms passender. En wil je gewoon weten hoe zo’n traject bij ons loopt, kijk dan bij een pentest laten uitvoeren.

Veelgestelde vragen over de pentest scope

Hoe groot moet mijn scope zijn?

Klein genoeg om diepgang mogelijk te maken. Liever één applicatie inclusief koppelingen en onderliggende infrastructuur goed getest, dan tien applicaties oppervlakkig.

Mag er op productie getest worden?

Ja, mits je afspraken maakt over tijdstippen en over technieken die uitval kunnen veroorzaken. Productie uitsluiten geeft een vertekend beeld, omdat data, configuratie en rechten daar anders zijn.

Moet ik broncode meegeven?

Voor maatwerkapplicaties levert dat vrijwel altijd meer op. De tester vindt fouten in bedrijfslogica die van buitenaf onzichtbaar zijn.

Hoe lang duurt een pentest?

Dat volgt uit de scope, niet andersom. Een enkele webapplicatie is meestal een kwestie van dagen; een omgeving met meerdere applicaties, koppelingen en een interne component loopt op tot enkele weken.

Wat als de tester buiten de scope iets ernstigs ziet?

Spreek vooraf af dat hij dat meldt zonder het uit te diepen. Je wilt weten dat het er is, en je wilt niet dat er ongepland getest wordt op systemen die er niet in stonden.