Een beveiligingstest die iets oplevert

Een beveiligingstest die iets oplevert is een test die vaststelt wat er moet gebeuren, en die het mogelijk maakt dat opvolging wordt belegd, uitgevoerd en aantoonbaar gemaakt. Het is een diagnose-instrument, geen doel op zich. Een test die alleen een lijst bevindingen achterlaat heeft niets opgeleverd, hoe grondig hij ook was. De waarde zit niet in het vinden, maar in wat erna in beweging komt. Dat is het verschil tussen een test als afvinkmoment en een test als startpunt van werk.

Dit stuk gaat over een woord dat in de praktijk twee dingen tegelijk betekent en daardoor verwarring veroorzaakt. "Beveiligingstest" is voor de een een jaarlijkse pentest met een vast bereik, en voor de ander de doorlopende vraag of de beveiliging echt doet wat ze moet doen. Die twee zijn niet hetzelfde, en het verschil bepaalt of er na de test iets verandert of niet.

Wat lost een pentest eigenlijk op?

Een pentest is een test waarbij specialisten een aanval simuleren, kwetsbaarheden vinden en die rapporteren. De klassieke vorm is een geplande test, vaak jaarlijks, met een afgebakend bereik. Dat is nuttig werk. Maar het is goed om scherp te benoemen wat het wel en niet oplost.

Een pentest doet vooral één ding: hij maakt zichtbaar wat er op de geteste dagen, binnen het geteste bereik, fout zat. Dat is een diagnose. Een waardevolle, mits ze klopt en mits het bereik de juiste dingen raakte. Maar een diagnose is geen behandeling. De pentest verandert niets aan de omgeving. Hij beschrijft haar.

Wat een pentest niet oplost, is alles wat erna komt. Hij dicht geen gat. Hij belegt geen eigenaarschap. Hij zorgt er niet voor dat de bevinding van vorig jaar dit jaar niet opnieuw op de lijst staat. En hij dekt de tijd tussen twee tests niet af. Een jaarlijkse test vertelt je de beveiligingsstand op de dagen dat er getest werd. De elf maanden ertussen zijn geen bewezen veilige periode. Het zijn maanden die door die pentest niet zijn bekeken. In een omgeving die continu verandert, met nieuwe systemen, nieuwe koppelingen en nieuwe configuratiefouten, is dat onbekeken venster precies waar het mis kan gaan.

Het beeld dat hierbij hoort is bekend voor wie op de werkvloer staat: de pentest-PDF die in een la verdwijnt. Niet omdat niemand hem serieus nam, maar omdat het rapport het eindpunt was in plaats van het beginpunt. De test werd gezien als de prestatie. De prestatie is wat erna gebeurt.

Waarom is een jaarlijkse pentest niet wat je denkt dat het is?

Als je jaarlijks een pentest inkoopt, is dit de vraag die je vooraf moet stellen. De aanname onder een jaarlijkse test is dat een momentopname representatief is voor het hele jaar. Dat klopt zelden. Tussen twee tests in verandert de omgeving voortdurend. Code gaat live, een leverancier wijzigt een koppeling, iemand opent tijdelijk een poort en vergeet hem te sluiten. De test van januari ziet de configuratiefout die in juni ontstond niet.

Dat is geen pleidooi om elke maand een volledige pentest te doen. Het is een pleidooi om scherp te zijn over wat een test je geeft. Drie dingen bepalen of een beveiligingstest iets oplevert:

Dekking over tijd. Niet alleen "is er getest", maar "hoeveel van het jaar is er feitelijk in beeld geweest". Een momentopname per jaar laat het grootste deel van de tijd onbekeken. Wie het risico van dat venster niet benoemt, verkoopt een gedeeltelijk antwoord als een volledig antwoord.

Handelbaarheid van de uitkomst. Een rapport met vijftig bevindingen zonder prioritering, zonder eigenaar en zonder relatie tot wat de organisatie aankan, is geen diagnose maar een nieuwe stapel werk. Een uitkomst die je niet kunt verwerken, heeft je niets opgeleverd.

Aantoonbaarheid. Kun je na de test laten zien wat er gevalideerd is, welk gat dicht is, en wat er nog open staat met een reden waarom? Aantoonbaarheid is wat een test om laat zetten in een argument naar boven, naar een CISO of een budgethouder. Zonder dat blijft het bij een gevoel.

Deze drie zijn de echte toets. Niet "hebben we onze jaarlijkse pentest gehad", maar "wat is er aantoonbaar veranderd en wat dekt het niet af". Het Nationaal Cyber Security Centrum beschrijft security testing als onderdeel van risicogestuurd beveiligingsbeheer, niet als losse jaarlijkse gebeurtenis. ENISA wijst er in zijn werk over het dreigingsbeeld op dat het aanvalsoppervlak meebeweegt met de organisatie. Een testritme dat niet meebeweegt, raakt achterop zodra de inkt droog is.

Het verschil tussen een test als momentopname en een test als diagnose

Hier ligt het oorspronkelijke punt van dit stuk. Er bestaat een denkbeeld dat een beveiligingstest een prestatie is: een examen dat je haalt of niet haalt. Dat denkbeeld is de kern van waarom zoveel testen niets opleveren. Een test is geen examen. Een test is een diagnose, en een diagnose heeft pas waarde als er een behandeling op volgt die past bij wat de organisatie aankan.

Dat verandert wat je van een test mag verwachten en hoe je hem inkoopt. Een test die als diagnose is opgezet, vraagt niet "welke vinkjes ontbreken nog", maar "wat raakt deze specifieke omgeving in haar eigen werkproces feitelijk". Dat is een andere vraag, en hij levert een ander soort uitkomst op: minder bevindingen, scherper geprioriteerd, gekoppeld aan wat er daarna moet gebeuren. Een lijst van vijftig kwetsbaarheden is makkelijker te produceren dan een diagnose die zegt: dit zijn de drie dingen die er voor jou toe doen, in deze volgorde, om deze reden.

Aan dit onderscheid hangt nog een vraag, en die wordt zelden hardop gesteld: van wie blijft de uitkomst? Een test die de regie en de toolkeuze impliciet bij de testende partij legt, levert minder op dan een test waarvan de conclusie en het vervolg van jou blijven. De toets die je daarbij kunt aanleggen is gedragsmatig en eenvoudig: zoekt de partij die test het probleem niet toevallig bij de oplossing die ze zelf verkoopt? Een test waarvan de aanbeveling toevallig altijd uitkomt bij wat de tester levert, is geen onafhankelijke diagnose. Hij is een offerte met een rapport eromheen. Een beveiligingstest die iets oplevert houdt de uitkomst, de prioritering en de vervolgkeuze bij jou, en maakt expliciet welk belang de testende partij wel of niet bij een bepaalde uitkomst heeft.

Dit is ook waar de scheiding zit tussen dit verhaal en de praktische vraag "ik wil nu een pentest laten uitvoeren". Die vraag is legitiem en heeft een eigen plek: een concrete opdracht met een datum, een bereik en een prijs. Maar het is een andere vraag dan de vraag die dit stuk behandelt. Wie alleen een pentest inkoopt, koopt een momentopname. Wie een beveiligingstest wil die iets oplevert, koopt een diagnose plus het werk en de aantoonbaarheid die erop volgen. Het is verstandig om te weten welke van de twee je nodig hebt voordat je tekent, want het verkeerde antwoord op die vraag is een jaar lang een vals gevoel van zekerheid.

Hoe ziet een test eruit die wel iets oplevert?

Concreet, en zonder dat hier een dienst wordt gepitcht: een beveiligingstest die iets oplevert heeft vier eigenschappen die je vooraf kunt afdwingen.

De eerste is dat het bereik is afgeleid van wat de organisatie feitelijk raakt, niet van wat makkelijk te testen is. De tweede is dat de uitkomst geprioriteerd is naar wat het werkproces aankan, niet naar het aantal bevindingen. De derde is dat er een eigenaar en een vervolg aan elke bevinding hangt voordat het rapport wordt opgeleverd, zodat niets standaard in de la belandt. De vierde is dat het resultaat aantoonbaar is: niet alleen "we hebben getest", maar "dit is gevalideerd, dit is dicht, dit staat nog open en daarom".

Een norm als ISO/IEC 27001 helpt hier, mits je hem leest zoals hij bedoeld is. ISO/IEC 27001 schrijft geen jaarlijkse pentest als los afvinkpunt voor. De norm vraagt om risicobeoordeling, risicobehandeling en aantoonbaar beheer binnen een ISMS. Een test is daar een instrument in, geen doel. Wie de norm gebruikt als argument voor een test per jaar, gebruikt hem als checklist en mist precies het punt. Wie hem gebruikt als argument voor een doorlopend, aantoonbaar testproces dat meebeweegt met de omgeving, gebruikt hem zoals hij is bedoeld.

Voor wie dit naar boven moet brengen, naar een CISO of een budgethouder, is dit het bruikbare frame. Het gesprek gaat niet over "meer testen is beter". Het gaat over dekking over tijd, over de handelbaarheid van de uitkomst, en over het onbekeken risico van de maanden tussen tests. Dat zijn argumenten die standhouden als er wordt doorgevraagd. "We doen toch al jaarlijks een pentest" is geen argument dat standhoudt, want het beantwoordt geen van de drie vragen.

De volgende stap is dan ook geen aanvraag voor een test, maar een eerlijk gesprek over welke van de twee je nodig hebt: een momentopname met een datum, of een diagnose met een vervolg. Pas als die vraag beantwoord is, heeft het zin om over bereik, ritme en prijs te praten. Wie die volgorde omdraait, koopt opnieuw een rapport voor in de la.