Penetratietesten met bevindingen die handmatig zijn gevalideerd.
Een penetratietest uitgevoerd door mensen, met handmatige exploitatie en elke bevinding gereproduceerd voordat zij het rapport haalt. Het doel is niet om op te sommen wat kwetsbaar lijkt, maar om aan te tonen wat een aanvaller werkelijk kan doen met wat u vandaag blootstelt.
Wat een pentest beantwoordt en een scanner niet
Een geautomatiseerde tool wijst aan wat kwetsbaar lijkt. Een penetratietest toont aan wat werkelijk misbruikbaar is en hoe ver de toegang reikt. Het verschil zit in het aaneenketenen: een autorisatiefout die op zichzelf als laag zou gelden, wordt kritiek zodra zij leidt tot gegevens die die gebruiker nooit had mogen aanraken. Geen enkele tool bouwt dat pad zelf — en het is het pad, niet het etiket, dat bepaalt hoe een oplossing wordt geprioriteerd.
- Elke bevinding wordt handmatig gereproduceerd voordat zij in het rapport komt: ruwe tooloutput is geen oplevering.
- Het risico wordt beschreven aan de hand van de impact op uw bedrijf, niet alleen met een algemene score uit een openbare database.
- Valse positieven bereiken u nooit — wat wij niet konden reproduceren blijft uit het document.
- Het exploitatiepad wordt stap voor stap vastgelegd, zodat uw team het kan herhalen en het herstel kan bevestigen.
Wat inbegrepen is
De scope hieronder is de standaard voor een gebruikelijke opdracht. Alles is tijdens de scoping aan te passen, kosteloos.
- Authenticatie, sessiebeheer en wachtwoordherstel
- Horizontale en verticale autorisatie per object
- Injectie in queries, commando's en templates
- Bedrijfslogica en stromen die te omzeilen zijn
- Uploaden, verwerken en uitleveren van bestanden
- Configuratie van headers, cookies en CORS
- Opsomming van resources en voorspelbare identifiers
- Toegangscontrole tussen accounts en tenants
- Schemavalidatie en omgang met onverwachte typen
- Limieten op frequentie, kosten en geautomatiseerd misbruik
- Authenticatie tussen services en rotatie van geheimen
- Te veel gegevens in de respons
- Blootgesteld randoppervlak en vergeten diensten
- Versies zonder ondersteuning en openstaande patches
- Segmentatie tussen omgevingen en netwerken
- Interne diensten bereikbaar vanaf de perimeter
- TLS-configuratie en terminatie van verkeer
- Laterale beweging vanaf een eerste toegangspunt
- Identity provider en federatiestromen
- Tweede factor: dekking, omzeiling en herstel
- Overgeërfde rechten en opgestapelde permissies
- Serviceaccounts en inloggegevens in code
- Sessies op meerdere apparaten en intrekking
- Registratie en onboarding van nieuwe gebruikers
- Android- en iOS-apps, inclusief lokale opslag
- Communicatie tussen app en API en certificate pinning
- Bescherming tegen manipulatie en gedrag op een gecompromitteerd toestel
- Bedrijfs-wifi, gastnetwerk en de scheiding daartussen
- Infrastructuur op locatie en wat die in de cloud bereikt
- Kiosken, terminals en gedeelde apparaten
- Injectie: SQL, NoSQL, LDAP, commando en template
- Authenticatie, autorisatie, IDOR en privilege-escalatie
- SSRF, XXE en onveilige deserialisatie
- Fouten in bedrijfslogica en betaalstromen
- XSS, CSRF en clickjacking met aangetoonde impact
- Zwakke cryptografie, voorspelbare tokens en broze JWT's
Varianten
aan te passen aan de scopeBlack box
Wij beginnen zonder bevoorrechte informatie, in dezelfde positie als een aanvaller van buiten. Dit meet wat uw oppervlak aan een vreemde prijsgeeft, en het brengt geregeld systemen aan het licht waarvan niemand wist dat ze blootstonden.
Grey box
Wij krijgen inloggegevens en een overzicht van de architectuur. Zo dekken wij binnen hetzelfde tijdsbestek het meeste af, omdat de inspanning naar exploitatie gaat in plaats van naar verkenning — en juist hier komen autorisatiefouten boven.
White box
Toegang tot code, configuratie en documentatie. Hiermee bereiken wij paden die van buitenaf zelden zichtbaar zijn, zoals race conditions, foutafhandeling en gevoelige logica die onder meerdere lagen ligt.
Wanneer een pentest zich doorgaans terugverdient
Dit is geen jaarlijks vinkje. Er zijn momenten waarop de test meer oplevert dan hij kost, omdat het oppervlak is veranderd of omdat iemand van buiten er binnenkort naar vraagt.
Een herbouw, een nieuwe identity provider of een migratie verschuiven aannames die niemand nog nakijkt. Testen vóór de wijziging is goedkoper dan het achteraf ontdekken met echt verkeer erbovenop.
Zakelijke contracten, securityvragenlijsten en inkooptrajecten vragen standaard om een onafhankelijke test. Het rapport beantwoordt dat objectief, zonder op zelfbeoordeling te leunen.
Nieuw team, nieuwe dienst, nieuwe koppeling. Snelle groei creëert oppervlak dat niemand volledig in kaart heeft, en rechten die als tijdelijke maatregel zijn verleend en nooit zijn teruggedraaid.
Verouderde interne systemen, beheerpanelen en oude koppelingen vallen vaak jarenlang buiten elke scope — juist omdat ze als te intern worden beschouwd om zorgen over te maken.
Hoe wij het uitvoeren
[pipeline]Scope en rules of engagement
Voordat er één pakket vertrekt, leggen wij schriftelijk vast wat binnen en buiten de scope valt, welke vensters zijn toegestaan en wie er gebeld wordt als iets van het plan afwijkt. Ook spreken wij het stopcriterium voor kritieke bevindingen af, zodat een ernstige ontdekking u dezelfde dag bereikt in plaats van op het rapport te wachten.
Verkenning en kaartwerk
Wij brengen het werkelijke oppervlak in kaart: domeinen, subdomeinen, blootgestelde diensten, technologieën, ingangen en alles wat al openbaar is over de omgeving. In deze fase komen de systemen boven die in de inventaris ontbreken — een bereikbare stagingomgeving, een vergeten paneel, een dienst die voor een test werd opgezet en bleef draaien.
Scannen en triage
Automatisering hoort hier thuis, en alleen hier: zij dekt volume af en levert kandidaten aan. Elk resultaat gaat door handmatige triage, want het meeste wat een tool aanmerkt houdt geen stand zodra iemand het probeert te reproduceren. Wat overleeft wordt een hypothese om te exploiteren.
Handmatige exploitatie
Hier onderscheidt een test zich van een scan. Wij ketenen fouten aaneen, testen de bedrijfslogica, proberen rechten te verhogen en trachten gegevens te bereiken die beschermd zouden moeten zijn — steeds binnen de afgesproken regels en zonder de beschikbaarheid van productie aan te tasten.
Post-exploitatie en reikwijdte
De deur vinden is niet het punt: het gaat om waar zij heen leidt. Wij meten hoe ver een eerste toegangspunt reikt, wat daarvandaan te lezen, te wijzigen of vast te houden is, en of daarmee een ander systeem bereikbaar wordt. Die meting maakt van een technische score een zakelijk risico.
Rapport en hertest
Het rapport bevat het reproduceerbare pad, de impact en de aanbevolen oplossing, met de bestuurlijke leeswijze gescheiden van het technische detail. Na het herstel testen wij de behandelde punten opnieuw en leggen vast wat gesloten is — want een herstelde bevinding telt pas als iemand dat bevestigt.
Openbare referenties achter het werk
Wij werken volgens open, erkende methodieken. Daardoor is de scope vergelijkbaar tussen leveranciers en kunnen uw auditors nagaan wat er is gedekt zonder ons op ons woord te geloven.
- OWASP WSTG
- De OWASP Web Security Testing Guide ordent de dekking per categorie — authenticatie, sessie, autorisatie, validatie, bedrijfslogica — en geeft een heldere basis om te tonen wat is geverifieerd.
- OWASP API Security
- De risicolijst voor API's dekt wat klassiek webtesten slecht afvangt: autorisatie op objectniveau, te veel blootgestelde gegevens en onbeperkt verbruik.
- PTES
- De Penetration Testing Execution Standard beschrijft de fasen van een test, van voorbereiding tot rapportage, en vormt de ruggengraat van de bovenstaande volgorde.
- MITRE ATT&CK
- De catalogus van tactieken en technieken van aanvallers benoemt wat er is uitgevoerd, zodat uw verdedigingsteam elke stap kan leggen naast wat de detectie zag — of miste.
- NIST SP 800-115
- De technische NIST-gids voor securitytesten beschrijft planning, uitvoering en wat er na de test gebeurt, en is de referentie die in contractuele eisen het vaakst wordt genoemd.
- CVSS
- De score standaardiseert de technische ernst, maar telt mee als invoer: de prioritering volgt de impact in uw context, die in gewone taal naast het cijfer staat.
Opleveringen
twee lagen · NDABestuurlijke samenvatting
Een korte tekst voor wie budget en prioriteit bepaalt: wat is getest, wat vormt werkelijk risico en waarover moet worden besloten. Zonder jargon geschreven, zodat zij standhoudt in een directievergadering.
Bevindingen met volledige reproductie
Elk punt bevat het pad stap voor stap, met request, response en bewijs. Een ontwikkelaar reproduceert het zonder om toelichting te vragen en zonder afhankelijk te zijn van degene die de test uitvoerde.
Beoordeling van impact en prioriteit
Technische ernst en zakelijke impact staan apart, want zij vallen niet altijd samen. De voorgestelde volgorde houdt rekening met de hersteltijd, zodat het team niet begint met het duurste en minst urgente punt.
Concrete hersteladviezen
Advies toegepast op uw code en uw architectuur, niet een algemene alinea uit de documentatie. Waar meer dan één route bestaat, beschrijft het rapport de afweging per route.
Toetsing tegen uw monitoring
Een overzicht van wat wij hebben uitgevoerd, geordend per techniek, zodat uw detectieteam het kan vergelijken met wat logs en alarmen hebben opgepikt. Dat onthult vaak evenveel als de lijst met kwetsbaarheden.
Hertest en afsluitende verklaring
Na het herstel bekijken wij de behandelde punten opnieuw en leggen de eindstand vast. De verklaring dient klanten, partners en auditors die bewijs nodig hebben dat de cyclus is gesloten.
Veelgestelde vragen
Standaard testen wij geen beschikbaarheid. Denial of service en elke handeling met hoog risico blijven buiten de scope, tenzij daar uitdrukkelijk om wordt gevraagd met een afgesproken venster. Kan een test productie raken, dan verhuist die naar een gelijkwaardige omgeving of draait in een afgesproken venster, met een open lijn van begin tot eind.
Een afgebakende scope, testaccounts voor elke gebruikersrol en een bereikbare technische contactpersoon. Kan bescherming aan de rand de test blokkeren, dan bepalen wij samen of die binnen de scope valt of een uitzondering krijgt — het blokkeermechanisme testen en de applicatie testen zijn verschillende doelen.
Een scan vergelijkt wat zij aantreft met een bekende database en levert een lijst. Een pentest probeert daadwerkelijk te exploiteren, ketent fouten aaneen en meet hoe ver de toegang reikt. Scannen is goedkoop en geschikt voor doorlopende bewaking; handmatig testen beantwoordt wat de lijst niet kan — of dat punt in uw context misbruikbaar is.
Ja. De bestuurlijke samenvatting is voor niet-technische lezers geschreven en kan met een klant, partner of auditor worden gedeeld. Het technische detail staat in een apart hoofdstuk, en de afsluitende verklaring na de hertest is het document dat in inkooptrajecten doorgaans als bewijs wordt geaccepteerd.
Dat hangt van het risico af. Een stagingomgeving die productie getrouw volgt heeft de voorkeur als die bestaat, omdat er dan agressiever getest kan worden. Bestaat alleen productie — het gebruikelijke geval — dan beperken wij destructieve handelingen, spreken een venster af en houden het hele traject een kanaal open.
Dan geldt het stopcriterium dat vooraf is afgesproken: een kritieke bevinding wordt onmiddellijk gemeld, met het minimum dat u nodig hebt om te handelen, zonder het eindrapport af te wachten. Vraagt de situatie erom, dan pauzeert de uitvoering tot de zaak is ingedamd.
Dat hangt af van hoe snel u verandert. Een applicatie die doorlopend uitrolt verandert wekelijks van oppervlak, en een jaarlijkse test kijkt naar een systeem dat niet meer bestaat. Gebruikelijk is een periodieke test van de hoofdscope, aangevuld met een gerichte test bij elke structurele wijziging — een nieuwe koppeling, een nieuwe identity provider, een nieuwe omgeving.