Je SaaS voorbereiden op de eerste pentest

De meeste SaaS-teams boeken hun eerste pentest om een van drie redenen: een enterprise-prospect vroeg om een recent rapport, ISO 27001 of een vergelijkbaar kader vereist periodiek testen, of er staat een grote release aan te komen en iemand zei eindelijk "hier moeten we naar laten kijken". Wat de aanleiding ook is, het verschil tussen een nuttige pentest en een dure PDF wordt grotendeels bepaald voordat de test begint.

Dit is wat je klaar moet hebben.

Bepaal wat er echt in scope is

"Test onze app" is geen scope. Som de zaken op die klantdata bevatten of raken: de webapplicatie, de publieke API, mobiele apps als je die hebt, de cloudaccounts waarin ze draaien, en alles wat vanaf het internet bereikbaar is en dat je vergeten was, meestal het interessantste deel voor een aanvaller. Als je een multi-tenant product draait, zeg dat dan expliciet: tenant-isolatie hoort in de scope genoemd te worden, want cross-tenant-toegang is de klasse bevindingen met de hoogste impact in SaaS.

Een kleinere, eerlijke scope is beter dan een brede, vage. Testers besteden hun uren waar jij ze op wijst.

Zet testaccounts klaar voor dag een

Goed testen doe je ingelogd. Lever minstens twee accounts per rol (twee admins, twee gewone gebruikers, twee tenants), zodat de tester zowel verticale toegang (kan een gebruiker adminacties doen?) als horizontale toegang (kan tenant A tenant B lezen?) kan controleren. Zet ze in een staging-omgeving die de productie dicht benadert. Elke dag dat een tester op inloggegevens wacht, is een dag testen waarvoor je betaalde en die je niet kreeg.

Deel hoe het systeem echt werkt

Een korte architectuurnotitie is beter dan een wiki-dump: hoe verzoeken stromen, waar authenticatie gebeurt, hoe tenants worden gescheiden, welke delen legacy zijn. Testers werken vanuit een methode, meestal de OWASP Web Security Testing Guide, een raamwerk van testscenario's dat wereldwijd door beveiligingsprofessionals wordt onderhouden. De methode dekt het terrein; jouw context vertelt de tester waar de lijken waarschijnlijk begraven liggen.

Weet hoe "goed" eruitziet in het rapport

Een bruikbaar rapport rangschikt bevindingen op echte impact op jouw product, niet op scanner-ernst, en elke bevinding komt met genoeg reproductiedetail zodat je engineers het kunnen oplossen zonder te gokken. Verwacht een gesprek over herstel, niet alleen een document. En sta op een hertest: een bevinding is gesloten wanneer iemand de fix heeft geverifieerd, niet wanneer het ticket op "klaar" is gezet.

Na de test

Twee goedkope vervolgstappen maken de volgende test beter en de huidige waardevoller:

• Publiceer een beleid voor gecoordineerde kwetsbaarheidsmelding, zodat onderzoekers die tussen tests problemen vinden een veilige manier hebben om je te bereiken.

• Houd de rapportsamenvatting bij de hand voor sales. Een recente pentest met opgeloste bevindingen is een van de sterkste antwoorden die je op een beveiligingsvragenlijst kunt geven.

Een eerste pentest vindt altijd iets. Dat is het punt. De teams die er het meest uit halen, behandelen het als het begin van een fix-en-verifieer-loop, niet als een certificaat om in te lijsten.