Beveiligingsteams hebben nog nooit zo goed zicht gehad op hun omgevingen en zijn nog nooit zo slecht geweest in het bevestigen dat wat ze repareren ook blijft.
Het M-Trends 2026-rapport van Mandiant schat de gemiddelde tijd voor exploitatie op een geschatte negatieve zeven dagen. De Verizon 2025 DBIR schat de gemiddelde tijd voor het herstellen van kwetsbaarheden in edge-apparaten op 32 dagen. Deze cijfers hebben de sector begrijpelijkerwijs in de richting van een duidelijk antwoord gedreven: stel beter prioriteiten, patch sneller. Dat advies is nodig. Het is ook onvolledig. Want de vraag die nog steeds niet genoeg aandacht krijgt, is deze: als je een patch maakt, hoe weet je dan dat het werkt?
Mythos heeft het probleem niet veranderd. Het veranderde de snelheid en het gemak van exploitatie.
De discussies over de impact van AI concentreerden zich op snelheid: de ontwikkeling van exploits wordt goedkoper, sneller en minder afhankelijk van menselijke vaardigheden van de elite.
Voor sanering verandert dit de inzet. Veel oplossingen worden gemarkeerd als ‘hersteld’, terwijl wat er in werkelijkheid gebeurde een patch van een leverancier was die omzeilbaar bleek te zijn, of een oplossing die ervan afhing of aanvallers zich op een bepaalde manier gedroegen. Vroeger waren dat veilige weddenschappen. Dat zijn ze niet meer. De vraag is niet langer de snelheid van de sanering. De vraag is of uw herstel de blootstelling daadwerkelijk heeft geëlimineerd of eenvoudigweg het ticket naar ‘klaar’ heeft verplaatst.
Patch-perfect, maar nog steeds kwetsbaar
Niet elke blootstelling is patchbaar. Een zwakke firewallregel laat bijvoorbeeld de deur openstaan. Gebleken is dat de beleidsregel is herschreven en naar verluidt is toegepast. Maar was dat zo? Wanneer een patch wordt toegepast, krijgt u een bevestiging. Wanneer een privilege is ingesteld of een EDR-beleid of SIEM-instelling is geconfigureerd, moet een test verifiëren of dit effect heeft gehad.
De organisatorische naad waar weken verdwijnen
Zelfs met gevalideerde bevindingen met een hoog signaal is de vertraging tussen identificatie en herstel in de eerste plaats organisatorisch van aard. Jij vindt het risico. Jij bent niet de eigenaar van de oplossing. De teams die er wel eigenaar van zijn, opereren op verschillende tijdlijnen met verschillende prioriteiten. De bevindingen worden niet geconsolideerd in acties waartegen ingenieurs kunnen optreden, waardoor het signaal opnieuw verloren gaat.
In cloud-native en hybride omgevingen wordt het eigendom onduidelijker: een kwetsbaarheid kan zich bevinden op de applicatielaag, de infrastructuurlaag of in een afhankelijkheid van derden. En zodra het ergens terechtkomt, loopt het herstel via het proces dat het team al gebruikt, het wijzigen van vensters voor IT en DevOps en het sprinten van verplichtingen voor engineering. Beveiligingsbevindingen concurreren uiteindelijk met wat al op de planning stond, en verliezen meestal. AI-versnelde aanvallers wachten niet op het volgende veranderingsvenster of de volgende sprint.
Consolidatie en automatisering zijn noodzakelijk. Ze zijn niet voldoende.
De operationele belemmering heeft echte oplossingen. Consolideer gerelateerde bevindingen, zodat verschillende gevalideerde problemen die teruggaan naar dezelfde verkeerd geconfigureerde load balancer één ticket met één eigenaar worden. Automatiseer routering, toewijzing, SLA-handhaving en escalatiepaden. Haal de workflow uit spreadsheets en Slack-berichten.
Maar doorvoer en snelheid vertellen je hoe snel het systeem beweegt, niet of het werkt. U kunt een geconsolideerd ticket binnen enkele minuten naar een bevestigde eigenaar sturen, de SLA afdwingen, volgens schema escaleren en toch een ticket sluiten dat de blootstelling niet heeft geëlimineerd. Misschien overleeft de oplossing een configuratiewijziging niet, is de oplossing uitgegaan naar drie van de vier betrokken systemen, of is de patch met succes toegepast, maar is een omringende verkeerde configuratie intact gebleven.
Op het ticket staat ‘opgelost’. Het aanvalspad is nog steeds open. Wanneer AI exploitketens autonoom kan afleiden en opnieuw kan herleiden, zoals Mythos heeft aangetoond, is vals vertrouwen het duurste in uw beveiligingsprogramma.
Revalidatie is de ontbrekende discipline
Revalidatie zou moeten betekenen dat het risico niet langer bestaat. Een hertest bevestigt alleen dat de oorspronkelijke aanval niet bestaat. U moet valideren dat het risico zelf niet bestaat.
Wanneer elke oplossing opnieuw wordt getest en de resultaten zichtbaar zijn voor zowel de beveiligings- als de technische leiding, worden gedeeltelijke oplossingen en tijdelijke oplossingen onmiddellijk gemarkeerd in plaats van dat ze in een dashboard blijven hangen. Het creëert een feedbacklus waardoor het hele systeem zichzelf corrigeert.
De herstelworkflow die onder de huidige omstandigheden standhoudt: gevalideerde bevindingen geconsolideerd in herstelacties, doorgestuurd naar bevestigde eigenaren, gevolgd tot afsluiting en vervolgens opnieuw gevalideerd om te bevestigen dat het onderliggende risico verdwenen is, en niet alleen het oorspronkelijke aanvalspad. Het platform van Pentera is ontworpen voor dat bedrijfsmodel en verbindt de herstelworkflow met validatie na de reparatie, zodat teams kunnen meten of het risico daadwerkelijk is geëlimineerd.
Drie vragen die een systeem scheiden van hoop
- Wat is uw gemiddelde tijd om een gevalideerde, exploiteerbare bevinding te herstellen? Als u dit niet kunt beantwoorden, meet u de activiteit en niet de resultaten.
- Wanneer een oplossing wordt toegepast, hoe kunt u dan bevestigen dat deze heeft gewerkt? Als het antwoord luidt: ‘De ingenieur heeft het ticket gesloten’, vraag uzelf dan af hoeveel van die herstelde bevindingen een hertest zouden overleven.
- Meet u tickets gesloten of risico gesloten? De ticketdoorvoer geeft aan dat het team bezig is. Het zegt niet dat de blootstelling verdwenen is. Programma’s verbeteren wanneer ze bevindingen consolideren met betrekking tot het onderliggende risico en nagaan of dat risico daadwerkelijk verdwijnt.
De organisaties die dit goed aanpakken, zullen degenen zijn die herstel niet langer beschouwen als iets dat gebeurt nadat de taak van de beveiliging is gedaan, maar het gaan behandelen als de plaats waar de taak van beveiliging daadwerkelijk wordt gemeten.
Opmerking: Dit artikel is vakkundig geschreven en bijgedragen door Nimrod Zantkern Lavi, Productdirecteur bij Pentera.
