In de beoordeling van de veiligheid van software speelt voor veel mensen de penetratietests of pentests een belangrijke rol. Ze worden in veel verschillende smaken geleverd, wat de beoordeling lastig maakt. Hoe onderscheid je een lijstje van een onderzoeker met gevonden lekken van een gestructureerd onderzoek waar je een auditwaarde aan kunt ontlenen? Na het bekijken van tientallen pentesten is het duidelijk dat er grote verschillen bestaan. Anders gezegd: de ene pentest is de andere niet.
De pentest is een onderzoek naar kwetsbaarheden in voornamelijk software. Wanneer wordt getest op een object zonder logingegevens of gedetailleerde schema’s spreken we van een blackbox test. Zodra er verdere informatie beschikbaar is over het object en er ook logingegevens worden verstrekt, heet het een greybox test. Is vervolgens ook de broncode van de programmatuur beschikbaar dan is het een crystalbox test of whitebox test. Een securityreview van de broncode noemen we doorgaans een pentest. Naarmate er dieper naar het product wordt gekeken, nemen zowel de waarde van het onderzoek als de kostprijs toe. Daarbij is er nog een groot verschil of het onderzoek geautomatiseerd of handmatig plaatsvindt en of bevindingen geautomatiseerd of handmatig worden gecontroleerd.
Helderheid
Tijdens het offertetraject zijn er per dienstverlening grote verschillen in kosten en beschrijving. Voor de rapportage is het belangrijk dat duidelijk is wat er nu precies aan onderzoek is gedaan. Wie bijvoorbeeld wil voldoen aan basale beveiligingsstandaarden kan niet volstaan met een geautomatiseerde scan of een blackbox pentest. Verder moet duidelijk zijn welke tests er gedaan worden en hoe dat tot een helder verslag gaat leiden. Er is een CCV-keurmerk voor pentests, waarin een aantal procesmatige zaken is geborgd. Zo geeft dit keurmerk bijvoorbeeld meer zekerheid over de scope van een onderzoek en het handmatig controleren van bevindingen. Het zegt alleen niets over wat er precies onderzocht dient te worden, de bewijsbaarheid van het onderzoek of de reproduceerbaarheid van alle stappen, toch belangrijke zaken voor de auditwaarde van een onderzoek.
De scope
Bij ieder onderzoek is een nauwkeurige beschrijving van de scope belangrijk. Neem bijvoorbeeld een onderzoek naar een domein. Wanneer daar sprake is van twee IP-versies, 4 en 6, wordt iedere test dan daadwerkelijk dubbel uitgevoerd? Het is namelijk niet 100 procent zeker dat software op dezelfde manier reageert in verschillende configuraties. Als er binnen dat domein bijvoorbeeld mail draait bij Google, Microsoft of een andere speler, wordt dit dan in het onderzoek meegenomen of juist niet? Vaak is het ingewikkeld om enerzijds de vrijwaring te krijgen voor het aanvallen van de systemen en anderzijds de hand te leggen op gedetailleerde systeeminformatie. Dit kan problematisch zijn, omdat bedrijfsprocessen soms zijn vervlochten met het gebruik van mail en de totale oplossing ook kwetsbaarheden kan bevatten. Overigens bieden grotere dienstverleners vaak wel de mogelijkheid om veel instellingen te regelen. Alleen wordt niet altijd begrepen dat de organisatie zelf verantwoordelijkheid draagt voor de beveiliging. Een goede onderzoeker vraagt die informatie uit. Soms blijkt tijdens het onderzoek dat de gekozen scope niet alle systemen dekt die een organisatie kwetsbaar kunnen maken. Beding tot slot een hertest. Anders zijn wel de problemen gedocumenteerd, maar ontbreekt het bewijs dat de zwakheden zijn opgelost.
Het onderzoek en de rapportage
Voor de onderzoeken die minimaal deel moeten uitmaken van een nuttige pentest zijn er standaarden ontwikkeld. Naast de checks op kwetsbaarheden uit de OWASP top-10 is dat het doorlopen van de WSTG (Web Application Security Testing Guide) voor webapplicaties en voor mobiele applicaties de MSTG. Daarnaast geeft de Pentest Execution Standard een aantal nuttige checks voor organisaties en infrastructuur. Ook biedt het een helder kader van wat er in de rapportage moet worden opgeschreven.
Belangrijk is om in ieder geval helder te krijgen wat er is getest (welke systemen en welke software), welke tests er zijn uitgevoerd en wat de resultaten zijn. Dat behelst natuurlijk niet alleen de tests met bevindingen, maar ook de tests zonder bevindingen. Anders is het ingewikkeld om een auditwaarde aan het rapport toe te kennen. Hiervoor is een uniforme standaard beschikbaar: de Common Vulnerability Scoring System (CVSS). Die zorgt ervoor dat er fors minder subjectiviteit in de weging zit.
OWASP TOP-10
Voor webapplicaties wordt de OWASP top-10 breed gezien als een absolute ondergrens voor beveiliging. De lijst wordt door de OWASP-organisatie samengesteld op basis van de tien meest voorkomende problemen die in de praktijk leiden tot incidenten. Het zijn de basispunten die een algemene indicatie over betrouwbaarheid geven en de belangrijkste oorzaken van incidenten kunnen wegnemen. Net als bij een APK-keuring biedt dat geen absolute zekerheid, maar het is wel basaal. Als het op één of meerdere van die punten mis is dan heeft verder kijken eigenlijk weinig zin, omdat het in de basis al verkeerd zit. Uit deze lijst vloeit voort dat er voor een pentest meer kennis vereist is van de applicatie en de omgeving. Zo gaat nummer 4 van de lijst over een onveilig ontwerp van de applicatie, waarbij naar documentatie moet worden gekeken en gesprekken moeten worden gevoerd. Dit is nodig omdat insecure design veronderstelt dat je naar ontwerpen kijkt. Ook de logging en monitoring maakt het noodzakelijk te kijken naar de ontwerpen of liever nog naar de software en de processen rond detectie. Een blackbox test is voor het toetsen van de OWASP top-10 niet voldoende.
Lees ook:
- Executives Guide: Penetration Testing and Ethical Hacking
- Waarom pentesten alleen niet genoeg is
