2026-07-15 · PRAKTIJK · Het Offensive Technology-team

Waarom elke opdracht begint met een handtekening

Er is precies één ding dat een penetratietest onderscheidt van computercriminaliteit, en dat is geen vaardigheid, tooling of intentie. Het is autorisatie. Hetzelfde commando uitgevoerd tegen dezelfde server is een professionele dienst op dinsdag en een misdrijf op woensdag, en het enige verschil is een papiertje.

Dus voordat we ook maar iets aanraken, regelen we dat papierwerk goed. Dit is wat dat in de praktijk echt betekent, en waarom we dit niet overslaan, zelfs niet als een klant haast heeft.

Eigenaarschap voor toegang

De eerste vraag is niet "wat wilt u laten testen", het is "kunt u bewijzen dat u er de controle over heeft". Iedereen kan een domein invoeren in een formulier. Dat betekent niet dat ze het bezitten, en als dat niet zo is, brengt het testen ervan ons beiden aan de verkeerde kant van de wet.

Dus verifiëren we. Meestal houdt dat in dat u een token plaatst in een DNS-record dat wij kunnen lezen, of bevestigt vanaf een e-mailadres op het domein zelf. Het duurt een paar minuten en er valt niet over te onderhandelen. Als u de controle over het doelwit niet kunt bewijzen, is er geen opdracht.

We vertrouwen ook niet alleen op een handtekening. We vragen schriftelijke autorisatie van een met naam genoemde persoon en willen alsnog het technische bewijs erachter zien, want een handtekening op het verkeerde briefpapier is precies hoe een tester bij het verkeerde doelwit belandt.

Scope is een hekwerk, geen suggestie

Zodra het eigenaarschap is vastgesteld, leggen we precies vast wat binnen de scope valt en wat niet: welke hosts, welke applicaties, welke technieken, en welke expliciet niet zijn toegestaan. Dat document is het hekwerk. We blijven erbinnen, zelfs als iets interessants net daarbuiten duidelijk bereikbaar is.

• De assets die we mogen aanraken, met naam genoemd.
• De technieken die u heeft goedgekeurd, en technieken die u heeft uitgesloten.
• Tijdsvensters, zodat het testen uw team of uw klanten nooit verrast.
• Een met naam genoemde contactpersoon die het hele traject met één bericht kan stopzetten.

Ditzelfde document regelt twee dingen die men vergeet totdat ze er echt toe doen. Ten eerste de omgeving: testen we productie, waar een zwaar verzoek echte klanten kan beïnvloeden, of een staging-kopie die deze spiegelt? Beide zijn valide keuzes, maar de keuze moet bewust worden gemaakt en niet halverwege de test worden ontdekt. Ten tweede de stopconditie: wie kan het testen stilleggen, hoe bereiken ze ons, en wat gebeurt er met eventueel reeds verkregen toegang als ze dat doen? Dit is een ondertekende overeenkomst voorafgaand aan de opdracht, geen vrijblijvende afspraak. Wanneer dit goed is geregeld, hoeft niemand onder druk te improviseren.

Wanneer het doelwit niet volledig van u is

Het bezitten van een domeinnaam is niet hetzelfde als het bezitten van alles waarnaar deze verwijst, en dit is waar goedbedoelde scopes misgaan. Een veelvoorkomend voorbeeld: een klant geeft aan dat app.clientco.com binnen de scope valt. We zoeken het op en het blijkt een CNAME te zijn naar een SaaS-platform van een derde partij waar de klant een abonnement op heeft, maar dat de klant niet zelf beheert. Ze beheren de DNS-naam; ze beheren niet de servers erachter. Het testen van die host betekent het testen van de leverancier, die nergens mee in heeft gestemd. Dus valt het buiten de scope, of de klant vraagt eerst schriftelijke toestemming aan de leverancier.

Dezelfde voorzichtigheid geldt voor assets op shared hosting of achter een gedeelde CDN, waar één enkel IP-adres duizenden ongerelateerde tenants kan bedienen, en voor een domein dat via een overname is verkregen waarvan de records nog steeds verwijzen naar de infrastructuur van de verkoper. Grote cloudproviders publiceren ook hun eigen beleid voor toegestane tests, en sommige activiteiten, in het bijzonder denial-of-service en stresstesten, vereisen nog steeds hun voorafgaande kennisgeving of goedkeuring, zelfs op resources die u bezit. Het ontrafelen van wat daadwerkelijk van u is, maakt deel uit van het in kaart brengen van het extern aanvalsoppervlak, en het gebeurt voorafgaand aan elke test, niet tijdens.

De wet achter de grens

De reden dat we hier onbuigzaam in zijn, is geen intern beleid. De meeste landen beschouwen ongeoorloofde toegang tot een computersysteem als een misdrijf op zich. In de Verenigde Staten is dat de Computer Fraud and Abuse Act; in het Verenigd Koninkrijk de Computer Misuse Act 1990; in de gehele Europese Unie stellen lidstaten illegale toegang strafbaar op grond van nationale wetgeving ter implementatie van de richtlijn van de Unie inzake aanvallen op informatiesystemen. De details verschillen per rechtsgebied, maar de rode draad is hetzelfde: toegang zonder toestemming van de eigenaar is het strafbare feit, en een hulpvaardige intentie is geen verweer. Dit is geen juridisch advies, en uw eigen jurist is de aangewezen persoon om de wetgeving te lezen die op u van toepassing is. Het is simpelweg de reden waarom er geen enkel verzoek wordt verstuurd voordat autorisatie en eigenaarschap zijn geregeld.

Waarom we streng zijn over het saaiere gedeelte

Klanten zien dit soms als bureaucratie. Het is het tegenovergestelde. Een strakke autorisatie is wat ons in staat stelt om binnen het hekwerk agressief te werk te gaan zonder dat een van ons zich zorgen hoeft te maken. Wanneer de grenzen zijn vastgelegd en ondertekend, kunnen we aanvallen stevig aan elkaar koppelen en echte impact aantonen, omdat iedereen het al eens is over waar de grenzen liggen.

De teams die in de problemen komen, zijn de teams die scope als een formaliteit behandelden. Wij behandelen het als het fundament, want dat is het.

Autorisatie eerst: snelle antwoorden

Heb ik schriftelijke autorisatie nodig om systemen te testen die ik al bezit?

In de praktijk wel. Schriftelijke autorisatie bewijst dat uw eigen team de test heeft goedgekeurd, wat u intern beschermt, en het beschermt de tester die de test uitvoert. Als een deel van de omgeving op infrastructuur staat die u niet volledig beheert, zoals een cloudplatform of een gehost SaaS-product, heeft u mogelijk ook toestemming van die provider nodig. Zorg dat u dit allemaal schriftelijk heeft geregeld voordat er iets wordt uitgevoerd.

Wat is een rules of engagement-document?

Het is de schriftelijke overeenkomst die de test definieert: de precieze doelen binnen de scope, de toegestane en verboden technieken, het testvenster, de met naam genoemde contactpersonen aan beide kanten, en de voorwaarden waaronder het testen stopt. Het verandert een vage "ga ons maar testen" in iets waaraan beide partijen kunnen worden gehouden.

Is het illegaal om een website te scannen die niet van mij is?

Dat kan het zijn. Veel rechtsgebieden stellen ongeoorloofde toegang tot computersystemen strafbaar, en de grens tussen een scan en toegang ligt niet altijd waar mensen denken. Richt zonder autorisatie en bewijs dat u de controle over het doelwit heeft niets op het doelwit. Dit is geen juridisch advies; raadpleeg een gekwalificeerde jurist voor uw rechtsgebied.

Hoe bevestigt u dat ik een doelwit bezit voordat u het test?

Meestal via een record dat we u vragen te publiceren in de DNS van het doelwit, of een antwoord vanaf een mailbox op het domein zelf. Beide bewijzen controle op een manier waarop een webformulier dat niet kan. Totdat die controle is geslaagd, is er geen opdracht.

Gerelateerde artikelen

• Check, scan of volledige pentest?
• Hoe bereidt u zich voor op uw eerste penetratietest
• Wat OSCP, OSEP en CRTO daadwerkelijk bewijzen