Terug naar Pentesten

Retest na Pentest: schriftelijke bevestiging dat je fix werkt

Een retest is een gerichte herhaling door dezelfde ethische hacker, die precies daar opnieuw probeert binnen te komen waar het lek zat.

Bij elke Sectricity-pentest is één retest per bevinding inbegrepen, met schriftelijke bevestiging, als die binnen 90 dagen na het rapport gebeurt. Later, of een rapport van een andere leverancier? Ook dat kunnen we hertesten, op basis van het oorspronkelijke rapport en de resultaten.

Zo verloopt een retest4 stappen

Van bevinding tot bevestigde fix

  1. 1We vinden een lekIn het rapport staat hoe het misbruikt wordt en wat je eerst doet
  2. 2Je team voert de fix doorJe laat ons weten wanneer die klaar is
  3. 3Dezelfde ethische hacker test opnieuwPrecies waar het lek zat, ook via omwegen en varianten
  4. 4Bevestigd: het lek is dichtSchriftelijk en per bevinding, bruikbaar voor je auditor
Inbegrepen binnen 90 dagen na elke Sectricity-pentest

Wanneer vraag je een retest aan?

Je team heeft bevindingen uit een pentest aangepakt en wil bevestiging dat de fixes werken
Een auditor (NIS2, ISO 27001, SOC 2) vraagt schriftelijk bewijs van remediatie
Je hebt een patch uitgerold en wil weten of de kwetsbaarheid effectief gesloten is
Je interne scan of tooling rapporteert geen issues meer, maar je wil menselijke validatie
Je staat voor een nieuwe release en wil bevestigen dat kwetsbare componenten niet meer exploiteerbaar zijn
Je hebt een pentestrapport van een andere leverancier en wil weten welke bevindingen nog openstaan

Waarom is menselijke validatie bij een retest onmisbaar?

Scanners bevestigen het signaal, niet de fix

Een scanner detecteert of een bekende kwetsbaarheidssignatuur aanwezig is. Als de signature verdwijnt na een patch, rapporteert de scanner geen probleem. Maar een menselijke tester probeert de aanval opnieuw uit, inclusief varianten en omwegen. Die diepgang is het verschil tussen een melding die zegt 'niet gedetecteerd' en een mens die zegt 'niet exploiteerbaar'.

Tooling mist context en aanvalsketens

Geautomatiseerde testtools, inclusief AI-gestuurde oplossingen, verbeteren snel in het vinden van bekende patronen. Ze begrijpen niet hoe de oorspronkelijke kwetsbaarheid in je specifieke applicatie werkte, welke omwegen de aanvaller kon nemen, of de fix een nieuw zwak punt introduceert. Een hacker die het originele exploitpad kent, test alle varianten.

Business logic-fixes zijn niet scanbaar

Fouten in bedrijfslogica, toegangscontrole en autorisatie worden door scanners gemist bij ontdekking, en bij validatie evenzeer. Als je fix een autorisatieregel aanpast of een flow herschrijft, is een handmatige hertester de enige betrouwbare manier om te bevestigen dat het misbruikpad gesloten is.

Auditklaar bewijs vereist een menselijke handtekening

Een NIS2-auditor of ISO 27001-reviewer accepteert geen scanoutput als bewijs van remediatie. Een schriftelijk hertestrapport van een ervaren ethische hacker, met per bevinding een bevestiging open of gesloten, is het document dat je complianceteam kan overhandigen.

Hoe verloopt een retest bij Sectricity?

Scope bepalen

We nemen het oorspronkelijke pentestrapport als uitgangspunt. Samen bepaal je welke bevindingen geretest worden: alle kritieke en hoge risico's, een selectie, of een uitgebreide delta inclusief nieuwe componenten.

Gericht hertesten

Dezelfde technieken als de originele test, gefocust op de specifieke kwetsbaarheden. De hacker probeert actief de fix te omzeilen, inclusief aanverwante aanvalsvectoren die bij de eerste test zijn genoteerd.

Validatierapport

Per bevinding een duidelijke status: gesloten, gedeeltelijk gesloten, of nog open. Met technische onderbouwing, reproductiebewijs en een bijgewerkte CVSS-score waar relevant.

Auditpakket

Executive summary voor management. Technische bevestiging voor je ontwikkelteam. Compliance-documentatie voor je auditor. Alles in één rapport, klaar om te gebruiken.

Retest vs. intern valideren: wat is het verschil?

Intern valideren

Bevestigt een fix op signaalniveau. Test geen actieve exploiteerbaarheid. Valideert geen business logic-fixes. Geen auditklaar rapport. Menselijke verificatie afhankelijk van interne expertise.

Scanner of tooling

Bevestigt afwezigheid van signatuur. Test geen exploiteerbaarheid. Kan logica- of autorisatiefixes niet valideren. Output wordt niet geaccepteerd als auditbewijs. Geen menselijke verificatie.

Sectricity Retest

Bevestigt fix op signaalniveau. Test actieve exploiteerbaarheid. Valideert business logic- en autorisatiefixes. Levert auditklaar rapport. Altijd menselijk geverifieerd door een ervaren ethische hacker.

Veelgestelde vragen

Een retest is een gerichte herhaling van een pentest, uitgevoerd nadat je team de bevindingen heeft aangepakt. Een ervaren ethische hacker probeert opnieuw in te breken op de specifieke kwetsbaarheden uit het originele rapport. Het doel is niet het ontdekken van nieuwe kwetsbaarheden, maar het bevestigen dat de fixes effectief zijn en niet meer exploiteerbaar.

Na ontvangst van de bevestiging dat de fixes zijn doorgevoerd, plannen we de retest doorgaans binnen vijf tot tien werkdagen in. Voor urgente situaties, zoals een nakende audit of een geplande release, stemmen we de timing af op je deadline.

Dat is een zinvolle eerste stap, zeker voor bekende kwetsbaarheden met een duidelijke signatuur. Maar scanners valideren het signaal, niet de exploiteerbaarheid. Business logic-fouten, IDOR en autorisatiefouten worden door geautomatiseerde tools niet betrouwbaar gevalideerd. Een menselijke retest bevestigt dat de aanval zelf niet meer slaagt.

NIS2 vereist aantoonbare technische beheersmaatregelen en bewijs dat risico's worden beheerst en opgevolgd. Een schriftelijk hertestrapport van een ervaren pentester is het sterkste bewijs dat een gevonden kwetsbaarheid effectief is verholpen. ISO 27001 Annex A vereist vergelijkbare validatie van corrigerende maatregelen.

Dan documenteren we dat in het rapport met de technische details waarom de fix niet volstaat en een bijgewerkte remediatie-aanbeveling. Een bijkomende hertest van diezelfde bevinding stemmen we samen af.

Ja. We hebben dan het oorspronkelijke rapport en de resultaten van die test nodig. We moeten eerst uitzoeken waar en hoe elk lek gevonden werd, dus dit vraagt meer werk dan de retest die bij onze eigen pentests inbegrepen is. Op basis van het rapport spreken we samen scope en aanpak af.

Zeker weten dat je fix werkt?

Vraag een retest aan en ontvang schriftelijke bevestiging per bevinding.