Je kan verschillende redenen hebben om een pentest af te nemen. In deze blog bespreken we vier vaak voorkomende redenen om een pentest te laten doen van (web) applicaties of hardware. Bij deze scenario’s geven we handige tips.
De belangrijkste is alvast: Begrijp je eigen reden waarom je een pentest wilt en communiceer dat met de leverancier. Het zal je pentest ervaring flink verbeteren, beloofd!
De vier meest voorkomende redenen zijn:
- Verkoop: Je verkoopt een product of dienst en jouw klanten of externe wetgeving vragen om een test.
- Uitrollen: Je ontwikkelt een product en het interne beleid van de organisatie vraagt om een pentest.
- Aanschaf: je wilt een product aanschaffen en de bijkomende risico’s begrijpen.
- Verbeteren: Je ontwikkelt een product en wilt de risico’s minimaliseren.
Verkoop
Je benadert een pentestleverancier om je (web)applicatie te testen. Wellicht vragen je klanten of deze is getest, of bestaat er externe wetgeving die dicteert dat je de test moet doen. In dit geval wil je niet zelf een pentest doen, maar wordt de vraag gecreëerd door externe factoren.
Onder deze voorwaarden:
- Wil je dat de pentest leverancier niet te veel tijd spendeert aan het testen.
- Je wilt de kosten zo laag mogelijk houden.
- Je wilt dat de uitkomst van de pentest zegt: prima!
- Je wilt de code niet delen met je tester.
In dit geval is een black box test binnen een nauw tijdskader het meest geschikt.
Wees ervan bewust dat er wat spanning kan ontstaan tussen jij als opdrachtgever en pentester, want:
Een goede pentest kan iets anders betekenen voor jou dan voor de pentester. Dit komt omdat het uitgangspunt van de pentester altijd een grondige kwalitatieve test is.
Een pentester zal niet snel een opdracht aannemen wanneer de scope te krap is. Wat is te krap? Dat is onderdeel van het gesprek wat je voert met je leverancier. Met goede communicatie vergemakkelijk je het proces.
Als opdrachtgevers dit duidelijk communiceren zal de pentester goed begrijpen dat de test een ‘moetje’ is. Echter, een pentester zal niet snel een opdracht aannemen wanneer de scope te krap is.
Er kleven reputatierisico’s aan voor de pentester als de resultaten worden gebruikt om te laten zien dat de applicatie veilig is.
Denk daarnaast al na over het moment wanneer je het pentest rapport ontvangt. In het rapport komen wellicht issues naar voren die je eerst moet oplossen voordat jouw klant tevreden is of voordat je voldoet aan de regelgeving. Het oplossen kost tijd en dat kan vertraging opleveren in het proces.
Uitrollen
In dit scenario wil je een pentest omdat de nieuwe versie van je product klaar is om uit te rollen. Jouw organisatie heeft als beleid dat je in dat geval een pentest moet afnemen voor de livegang.
Onder deze voorwaarden:
- Wil je niet dat de pentester veel tijd kwijt is aan testen.
- Je wilt waarschijnlijk hetzelfde betalen als de pentest die je hiervoor hebt laten doen.
- Je wilt dat het resultaat van de pentest positief is, maar wel de kennis wilt hebben van issues.
- Het delen van de code is optioneel.
In dit geval is een test binnen een vast tijdskader geschikt. De voorkeur gaat uit naar White Box.
Je ligt redelijk op één lijn met je leverancier, maar voor jou is de test simpelweg een kwestie van een taak die afgevinkt moet worden. Hoeveel tijd moet worden besteed aan het testen hangt af van de veranderingen sinds de laatste release van de applicatie. Dit overleg je met je leverancier. Hou er rekening mee dat het rapport bepaalde issues van de applicatie kan beschrijven die je eerst moet oplossen voordat je de nieuwe versie kan uitrollen.
Aanschaf
In dit scenario vraag je om een pentest omdat je software of hardware wilt gebruiken dat nieuw voor de organisatie is. Enkele voorbeelden zijn:
Software die je on-Prem gaat draaien en daar wil je de risico’s van kennen.
Hardware of IoT apparaten, of andere “smart devices”. Vaak zijn er vragen rondom de privacy (welke informatie wordt opgeslagen, en wordt deze informatie gedeeld met onbekende servers op het internet?)
Onder deze omstandigheden:
- Wil je een redelijke prijs betalen.
- Wil je diepgaande inzichten hebben in security en risico’s.
- Kan je de code met de pentest waarschijnlijk niet delen.
In dit geval licht een Black Box test het meeste voor de hand.
Afhankelijk van het object dat getest moet worden, is het in onze ervaring altijd aan te raden om contact op te nemen met de vendor. Niet elke vendor zal staan te springen om hun product te laten testen, maar het is het waard om het proces en eventuele resultaten te delen. We kennen gevallen waarbij de kosten voor een pentest werden gedeeld of zelf helemaal vergoed!
Verbeteren
In dit scenario wil je een pentest afnemen voor het product dat je zelf ontwikkeld. Je wilt de risico’s door en door kennen zodat je deze kan verlagen.
Onder deze omstandigheden wil je:
- Een redelijke prijs betalen.
- Lever je de code aan (tenzij dit echt niet anders kan).
- Wil je een realistische kijk op de risico’s.
In dit scenario werkt een White Box het beste.
Als het verbeteren van je product een hoge prioriteit heeft, is het waard om al te kijken naar je security eerder in de lifecyle. Door een secure development lifecycle te implementeren verbeter je de kwaliteit van je product en verminder je het aantal gevonden issues tijdens een pentest achteraf. Het gebruik van code analyse tools en code review hebben een directe impact op de kwaliteit van de code.
Samenvattend
Het helpt door jezelf de vraag te stellen wat je motivaties zijn om een pentest te laten doen. Door je overwegingen te delen met je pentestleverancier verbeter je het proces en het eindresultaat van de test, of je nu wilt verkopen, uitrollen, aanschaffen of verbeteren!