Het recent ontdekte lek in kindersmartwatches toont eens te meer aan welke impact een veiligheidslek kan hebben. Het is dan ook zaak je applicatie, systeem of netwerk te controleren op de aanwezigheid van zwakke plekken. Een penetratietest, ofwel pentest is daarvoor uiterst geschikt, maar de bruikbaarheid van de resultaten valt of staat met een goede voorbereiding, juiste uitvoering en uiteindelijk omzetten van de gerapporteerde bevindingen.
In deze bijdrage geef ik zes tips waarmee men het onderste uit de kan haalt. Natuurlijk zijn er wel meer tips, maar hier kunt u al vast een begin maken. Ik sta open voor suggesties en tips van derden.
Inventariseer bedrijfsrisico’s
Een goede voorbereiding vergroot de effectiviteit van een pentest. Dit vereist een scherpe blik op de risico’s die voor uw organisatie van belang zijn. Is bijvoorbeeld uw imago cruciaal, beschikt u over zeer gevoelige data, of leunt u enorm op een goede uptime? Wie zijn achilleshiel kent, weet ook waar hij zijn aandacht op moet vestigen tijdens een pentest.
Het is altijd een goed idee vooraf een rondgang te maken langs alle stakeholders binnen een organisatie. De financial controller en de hr-directeur benoemen wellicht andere risico’s dan de systeembeheerder en de ciso. De combinatie van al die inzichten zorgt voor een zo volledig mogelijk risicobeeld.
Bepaal de juiste scope
Een belangrijke keuze vooraf is de scope van de test. Wat wilt u precies toetsen? De scope kan variëren van de weerbaarheid van een enkele website of applicatie tot aan die van de volledige it-infrastructuur. Bij het kiezen van een scope is het essentieel alle betrokken systeemonderdelen te selecteren. Een kwetsbaar component dat tijdens de test gemist wordt, kan impact hebben op de volledige functionaliteit.
Kies passende testmethode
De gebruikte testmethode bepaalt voor een groot deel de betekenis en bruikbaarheid van de uitkomsten. Er zijn grofweg drie testmethoden te onderscheiden. Iedere variant heeft zijn eigen specifieke kenmerken en use cases:
Blackbox: De ethical hacker krijgt vooraf, naast de scope, geen informatie over de it-infrastructuur. Wel wordt in veel gevallen een scope afgesproken om verwachting over en weer goed af te stemmen. Merendeel van onze klanten ervaren deze aanpak als meest realistische simulatie van een opportunistische hacker. Deze testmethode is doorgaans de minst grondige vanwege beperkingen in aangeleverde informatie. Immers: hoe meer informatie de ethical hacker tot zijn beschikking heeft, hoe grondiger de test uitgevoerd kan worden. Blackbox pentesting is geschikt voor het bepalen van een realistisch startpunt voor verdere verbetering vanuit beveiligingsperspectief om naar een hoger maturiteitsniveau te komen.
Greybox: Deze variant houdt het midden tussen een blackbox- en een whiteboxtest. De pentesters krijgen van tevoren beperkte informatie over de it-infrastructuur of toegang tot een klant- of medewerkersaccount. Greyboxtesten zijn doorgaans minder grondig dan whiteboxtesten, maar hebben wel een realistisch uitgangspunt. De pentesters beschikken hiermee over ongeveer evenveel voorkennis als bijvoorbeeld een rancuneuze klant/medewerker of een goed geïnformeerde hacker. Onderzoekers verkrijgen tijdens een greyboxonderzoek bijvoorbeeld geldige logingegevens om zo de autorisatie te onderzoeken. Tijdens een blackboxonderzoek zou dit alleen getest kunnen worden wanneer de pentester de authenticatie kan omzeilen of op geldige logingegevens stuit.
White box: Pentesters krijgen met een whiteboxpentest vooraf volledige openheid van zaken. Dat maakt een grondige test mogelijk. Dit biedt de mogelijkheid op de scope in de breedste zin te onderzoeken. Denk aan elementen als de broncode, documentatie, configuratie en bijvoorbeeld servers. Het nadeel: deze methode kost veel tijd, omdat de te onderzoeken infrastructuur of functionaliteit tot in detail onderzocht dient te worden. Deze methode wordt veelal toegepast met een gerichte focus, bijvoorbeeld een applicatie die zeer belangrijk (bedrijfskritisch) is voor de klant.
Houd rekening met downtime
Een pentest grijpt vaak diep in op de it van de organisatie. Hoewel een pentester over het algemeen alles aan doet om het te voorkomen, kunnen systemen verstoord raken. Daarom is het belangrijk om een acceptatieomgeving te faciliteren die de productieomgeving zo goed mogelijk simuleert. Dat beperkt de impact van eventuele downtime en ontziet bestaande klanten van het systeem zoveel mogelijk.
Soms is dit geen optie en vindt de test op de productieomgeving plaats. Dan is het belangrijk rekening te houden met mogelijke downtime. Als onderdeel van de vrijwaringsverklaring zal daarom ook de aansprakelijkheid benoemd worden. Het is hoe dan ook verstandig de nodige voorzorgsmaatregelen te nemen. Zorg dat je downtime van bedrijfskritische systemen en applicaties snel kunt opvangen. Vergeet ook niet dat de applicatie in specifieke situaties e-mails of api-calls maakt. Dit kan voor onverwachte situaties zorgen waarbij partners of gebruikers onverwachte e-mails of api-calls ontvangen.
Vergeet de public cloud niet
Steeds vaker komt een deel van de it-omgeving uit de public cloud. Denk aan platforms als Amazon Web Services (AWS), Azure en Google Cloud, maar ook kant-en-klare SaaS-toepassingen vinden gretig aftrek. Partijen als Google, Microsoft en Amazon beschikken over grote budgetten voor de beveiliging van hun fysieke en digitale infrastructuur. Maar de grote hoeveelheden data die ze verwerken, maakt hen ook tot een aantrekkelijk doelwit.
Bovendien ontslaat het u niet van de zorgplicht: uw organisatie is verantwoordelijk voor de data die u bij cloudproviders stalt. Het is dan ook absoluut zinvol om de public cloud mee te nemen in de scope van een pentest, mits van toepassing uiteraard. Zorg wel voor een vrijwaringsovereenkomst: deze partijen moeten wel op de hoogte zijn van de pentest en bovendien zullen ze hun eigen spelregels hierin hanteren. De meeste cloudproviders beschikken over een standaard beschrijving welke tests wel en niet mogen: een rules of engagement. Hierin staat beschreven welke tests wel mogen, en welke handelingen absoluut verboden zijn.
Zet verbeterpunten om in acties
Weinig is zo zonde als een grondig uitgevoerde pentest waarvan de resultaten uiteindelijk in een la belanden. De werkelijke waarde van een pentest zit juist in de stap daarna: het omzetten van opgedane inzichten naar daadwerkelijke veranderingen in de dagelijkse praktijk. Dit is het moment om vragen te stellen, bijvoorbeeld aanvullende duiding omtrent een kwetsbaarheid. Of een voorgestelde oplossing past niet binnen de architectuur of infrastructuur is dit het moment om samen een veilige passende oplossing te bedenken.
Het is verstandig de conclusies en aanbevelingen uit een rapportage direct te vertalen naar concrete acties. Een ticketing- of projectmanagementsysteem is hiervoor geschikt. Daarmee kunt u direct de juiste acties koppelen aan verantwoordelijken.
Kies voor kwaliteit
Een pentest is zo goed als de uitvoering ervan. Het kiezen voor een partij met meer dan genoeg kennis, vaardigheden en ervaring is dan ook belangrijk. Een van de indicatoren is de mate waarin een pentest geautomatiseerd plaatsvindt. Het is geen goed teken wanneer het merendeel bestaat uit automatische testen. Een computer kan maar een beperkte set aan kwetsbaarheden in kaart brengen.
Certificaten kunnen ook een indicatie van kwaliteit zijn. Certificaten als OSCP/OSCE tonen aan dat een pentester beschikt over aantoonbare vakkennis, praktische vaardigheden, doorzettingsvermogen en creativiteit. Een VOG (Verklaring Omtrent het Gedrag) mag vanuit vertrouwensperspectief ook niet ontbreken. Ten slotte zal een goede pentester vanaf het begin van het traject meedenken over de scope, aanpak en de betekenis van de testresultaten voor de organisatie.
