“Wij laten jaarlijks een test doen.” Die zin hoor ik vaak, en meestal blijkt bij doorvragen dat er een vulnerability scan draait terwijl de organisatie denkt dat ze een pentest heeft. Dat is geen woordenspel. Het verschil bepaalt of je weet welke kwetsbaarheden er zijn, of dat je weet of iemand er daadwerkelijk mee binnenkomt.
Drie vormen van testen worden door elkaar gebruikt: de vulnerability scan, de pentest en de red teaming oefening. Ze beantwoorden verschillende vragen, kosten sterk uiteenlopende bedragen en passen bij verschillende volwassenheidsniveaus. Dit artikel zet ze naast elkaar.
Kort samengevat
- Een vulnerability scan is geautomatiseerd en beantwoordt de vraag: welke bekende kwetsbaarheden zie ik?
- Een pentest is mensenwerk en beantwoordt de vraag: kan iemand hier daadwerkelijk binnenkomen, en hoe ver komt hij?
- Red teaming test niet je systemen maar je organisatie: merkt iemand het, en wat doen we dan?
- De volgorde is belangrijk. Red teaming op een omgeving die nooit is gescand, levert een dure bevestiging van iets wat je al had kunnen weten.
- De waarde zit niet in het rapport maar in de opvolging, en juist daar loopt het bij de meeste organisaties vast.
Wat is een vulnerability scan?
Een vulnerability scan is een geautomatiseerde controle van je systemen tegen een database met bekende kwetsbaarheden. De scanner kijkt welke software en versies draaien en meldt waar bekende problemen zitten of waar configuraties afwijken van wat gebruikelijk is.
De sterke kant: breed, snel, herhaalbaar en relatief goedkoop. Je kunt maandelijks of zelfs continu scannen, en zo zien of je achterstand in updates groter of kleiner wordt.
De beperking: een scanner combineert niet. Hij ziet drie los van elkaar onschuldige instellingen, maar niet dat die drie samen een aanvalspad vormen. En hij levert vals alarm op. Een lijst met tweehonderd meldingen zonder duiding is een lijst waar niemand iets mee doet.
Wat is een pentest en waarin verschilt die?
Bij een penetratietest probeert een ethisch hacker daadwerkelijk binnen te komen. Hij gebruikt scans als vertrekpunt, maar de waarde zit in wat daarna gebeurt: het combineren van kleine zwakheden tot een werkend aanvalspad, het misbruiken van bedrijfslogica en het uitbuiten van fouten die geen enkele scanner herkent omdat ze uniek zijn voor jouw applicatie.
Het verschil in uitkomst is groot. Een scan zegt: deze component is verouderd. Een pentest zegt: via deze verouderde component kwam ik binnen, kon ik doorstappen naar de beheeromgeving en had ik toegang tot de klantgegevens. Dat tweede is een verhaal dat een directie begrijpt en waar een budget op volgt.
Er zijn verschillende soorten pentesten, van webapplicatie tot interne infrastructuur. We hebben eerder de verschillende soorten pentesten uitgelegd en beschreven wat een pentest is en wat die kost.
Wat is red teaming?
Red teaming gaat een stap verder en verlegt het doel. Bij een pentest is de vraag of een systeem te kraken is. Bij red teaming is de vraag of jouw organisatie een echte aanval opmerkt en afslaat.
Een red team werkt daarom scenariogedreven en zonder aankondiging aan de operationele kant. Er wordt gewerkt vanuit een realistisch dreigingsbeeld: hoe zou een aanvaller die het op jouw sector gemunt heeft te werk gaan? Alle wegen zijn toegestaan, inclusief phishing en soms fysieke toegang.
Wat je eruit haalt, gaat over detectie en reactie. Hoe lang duurde het voor iemand iets doorhad? Werd de juiste persoon gebeld? Klopte het draaiboek? Dat zijn andere vragen dan een technische kwetsbaarhedenlijst, en ze zijn alleen zinvol als je detectie en incidentrespons al hebt ingericht. Anders is de uitkomst voorspelbaar: niemand merkte iets.
Welke test past bij welke volwassenheid?
De volgorde die in de praktijk het meeste oplevert:
- Nog geen structureel zicht? Begin met periodieke vulnerability scans en een proces om de bevindingen weg te werken. Dit is de goedkoopste manier om de grootste stapel weg te nemen.
- Scans onder controle, patchproces draait? Nu is een pentest zinvol. Je betaalt dan voor het vinden van wat een scanner niet ziet, in plaats van voor het bevestigen van achterstallig onderhoud.
- Pentesten leveren weinig nieuws meer op en je hebt detectie ingericht? Dan is red teaming de logische volgende stap.
De fout die geld kost, is stap twee of drie doen zonder stap één. Een pentester die zijn eerste dag besteedt aan het documenteren van ontbrekende updates, doet werk dat een scanner voor een fractie van het bedrag had gedaan.
Wat kost het en hoe vaak doe je het?
Grofweg: een vulnerability scan is een abonnementsvorm en kan continu draaien. Een pentest is een project van enkele dagen tot enkele weken, afhankelijk van de scope. Red teaming duurt weken en vraagt voorbereiding aan beide kanten.
Over frequentie krijg ik vaak de vraag of één keer per jaar genoeg is. Mijn antwoord: de kalender is de verkeerde aanleiding. Test wanneer er iets verandert dat ertoe doet. Een nieuwe applicatie live, een grote migratie, een koppeling met een nieuwe partner, een overname. Een jaarlijkse test op een omgeving die halverwege het jaar ingrijpend is verbouwd, dekt de laatste zes maanden niet.
Voor omgevingen die continu doorontwikkelen is een combinatie het beste: continu scannen, jaarlijks of per grote release een pentest, en red teaming zodra detectie serieus is ingericht. Hoe zo’n traject bij ons verloopt, staat op de pagina over een pentest laten uitvoeren.
Hoe voorkom je dat een rapport in de la belandt?
Dit is waar het bij de meeste organisaties misgaat, en het is zonde van het geld. Een paar dingen die helpen:
- Spreek de hertest vooraf af. Neem hem op in dezelfde opdracht, met een datum. Anders verdwijnt hij in de begroting van volgend jaar.
- Zet bevindingen in je bestaande werkvoorraad. Niet in een los actieplan dat niemand bijhoudt, maar in de backlog of het ticketsysteem waar het team elke dag in werkt.
- Beleg eigenaarschap per bevinding. Een bevinding zonder naam is een bevinding zonder opvolging.
- Vraag om duiding, niet alleen om classificatie. Welke drie bevindingen zou de tester zelf als eerste oplossen? Dat is een andere lijst dan alles wat op hoog staat.
- Laat de bevindingen terugkomen in je risicoanalyse. Zo landen ze in de cyclus die je toch al draait.
We hebben apart beschreven hoe je van bevindingen naar echte verbetering komt, in het artikel over pentestresultaten implementeren.
Veelgestelde vragen
Is een vulnerability scan genoeg om aan de norm te voldoen?
Meestal niet. Zowel ISO 27001 als de zorgplicht uit de Cyberbeveiligingswet vraagt om het testen en beoordelen van de effectiviteit van maatregelen. Een geautomatiseerde scan dekt een deel daarvan, maar zegt weinig over de werkelijke weerbaarheid van je omgeving.
Wat is het verschil tussen een pentest en red teaming in één zin?
Een pentest test of je systemen te kraken zijn; red teaming test of je organisatie het merkt en er goed op reageert.
Moet ik een pentest aankondigen binnen mijn organisatie?
Bij een pentest is dat gebruikelijk, omdat je de techniek test en niet de alertheid. Bij red teaming juist niet: daar is de onwetendheid van de operationele teams onderdeel van de test. Wel weet altijd een kleine groep binnen de organisatie ervan.
Hoe vaak moet ik laten testen?
Laat de aanleiding leidend zijn in plaats van de kalender: bij nieuwe applicaties, grote wijzigingen, migraties of nieuwe koppelingen. Voor stabiele omgevingen is jaarlijks een gangbaar minimum, met tussentijds continu scannen.
Wat is een hertest en heb ik die nodig?
Een hertest controleert of de gevonden kwetsbaarheden daadwerkelijk zijn verholpen. Zonder hertest weet je alleen dat er iets is opgepakt, niet dat het probleem weg is. Spreek hem meteen bij de opdracht af.
