Gemiddelde Tijd tot Herstel (MTTR)

TL;DR

• MTTR vertegenwoordigt de gemiddelde tijd die nodig is om een beveiligingskwetsbaarheid op te lossen na identificatie, en biedt een directe maatstaf voor operationele efficiëntie.
• Om MTTR te berekenen, deel de totale tijd besteed aan het oplossen van problemen door het aantal incidenten.
• Het doel is om de blootstellingstijd te minimaliseren zodat aanvallers minder snel bekende gaten kunnen exploiteren.
• De oplossing is om het proces te versnellen door alles te automatiseren van kwetsbaarheidsdetectie tot het genereren van codefixes, waardoor vertragingen in handmatige ticketwachtrijen worden geëlimineerd en snellere herstelacties worden gegarandeerd.

Wat is MTTR?

Gemiddelde Tijd tot Herstel (MTTR) is een belangrijke cyberbeveiligingsmaatstaf die laat zien hoe snel u reageert op een bekende bedreiging. Het meet de tijd vanaf het moment dat een kwetsbaarheid wordt gevonden tot het moment dat een oplossing wordt geïmplementeerd.

Hoewel maatstaven zoals MTTD de detectiesnelheid weerspiegelen, onthult MTTR de werkelijke herstel efficiëntie van uw organisatie. Snelle detectie moet worden gevolgd door snelle oplossing om risico blootstelling te beperken en bedrijfscontinuïteit te ondersteunen.

Waarom MTTR Belangrijk Is

Cybercriminelen opereren sneller dan traditionele ontwikkelingslijnen, waardoor de vraag naar responsieve beveiligingsoperaties toeneemt. Industrietrends geven aan dat verdedigingsvensters kleiner worden.

• Het 5-daagse exploitvenster: In 2025 daalde de gemiddelde Time to Exploit (TTE), de kloof tussen wanneer een kwetsbaarheid openbaar wordt gemaakt en wanneer deze actief wordt uitgebuit, van 32 dagen naar slechts 5 dagen (CyberMindr, 2025).
• Toename van exploitatie: Het gebruik van kwetsbaarheden als toegangsmiddel is dit jaar met 34% gestegen en veroorzaakt nu 20% van alle bevestigde inbreuken.
• De remediatieachterstand: Aanvallers handelen binnen dagen, maar organisaties doen er vaak weken over. De mediane tijd om kritieke kwetsbaarheden in rand- en VPN-apparaten te verhelpen blijft 32 dagen, waardoor er een aanzienlijk risicovenster ontstaat. Slechts 54% van de gebreken wordt ooit volledig gepatcht (Verizon DBIR, 2025). Dagversnelling: De ontdekking van uitgebuite zero-day kwetsbaarheden is met 46% gestegen ten opzichte van vorig jaar. Aanvallers maken nu binnen enkele uren na identificatie gebruik van deze gebreken (WithSecure Labs, 2025).
• Hoge MTTR drijft de bedrijfskosten op ver boven de technische schuld. In 2025 bedragen de gemiddelde kosten van een datalek in de VS $4,4 miljoen, voornamelijk door vertraagde reacties en regelgevende boetes (IBM, 2025).
• Complianceboetes: Onder regels zoals DORA tellen lange blootstellingstijden als mislukkingen onder operationele veerkracht. Organisaties met een hoge MTTR worden nu geconfronteerd met verplichte rapportage en grote boetes voor niet-naleving. Je kunt niet sneller bewegen dan de exploit scripts; je verdediging is puur theoretisch.

Hoe MTTR te berekenen

MTTR wordt berekend door de totale tijd die besteed is aan het repareren van een systeem te delen door het aantal reparaties dat gedurende een specifieke periode is uitgevoerd.

De Formule

MTTR-formule

Voorbeeldberekening

Stel je voor dat je engineeringteam afgelopen maand 4 incidenten heeft afgehandeld:

1. Incident A: Database-uitval (Opgelost in 30 minuten)
2. Incident B: API-fout (Opgelost in 2 uur / 120 minuten)
3. Incident C: Cachefout (Opgelost in 15 minuten)
4. Incident D: Beveiligingspatch (Opgelost in 45 minuten)

• Totale Reparatietijd: 30 + 120 + 15 + 45 = 210 minuten
• Aantal Reparaties: 4

MTTR-formule-berekening

Dit betekent dat het je team gemiddeld ongeveer 52 minuten kost om een probleem op te lossen zodra ze eraan beginnen.

Voorbeeld in de Praktijk

Overweeg twee bedrijven die te maken hebben met een kritieke beveiligingskwetsbaarheid (bijv. Log4Shell).

Bedrijf A (Hoge MTTR):

• Proces: Handmatig. Waarschuwingen gaan naar e-mail. Een ingenieur moet handmatig SSH naar servers om de kwetsbare jar-bestanden te vinden en ze één voor één te patchen.
• MTTR: 48 Uur.
• Resultaat: Aanvallers hebben twee volle dagen om de kwetsbaarheid uit te buiten. Gegevens zijn waarschijnlijk gecompromitteerd.

Bedrijf B (Lage MTTR - gebruikmakend van Plexicus om herstel te automatiseren):

• Proces: Geautomatiseerd. De kwetsbaarheid wordt onmiddellijk gedetecteerd. Een geautomatiseerd draaiboek wordt geactiveerd om getroffen containers te isoleren en een patch of virtuele firewallregel toe te passen.
• MTTR: 15 Minuten.
• Resultaat: De kwetsbaarheid wordt gesloten voordat aanvallers een succesvolle exploit kunnen lanceren.

Wie Gebruikt MTTR

• DevOps Engineers - Om de efficiëntie van hun implementatie- en rollback-pijplijnen bij te houden.
• SREs (Site Reliability Engineers) - Zorgen ervoor dat ze voldoen aan SLA’s (Service Level Agreements) voor uptime.
• SOC Analisten - Om te meten hoe snel ze actieve beveiligingsdreigingen kunnen neutraliseren.
• CTO’s & CISO’s - Om investeringen in automatiseringstools te rechtvaardigen door een vermindering van de hersteltijd aan te tonen.

Wanneer MTTR Toepassen

MTTR moet continu worden bewaakt, maar is het meest kritisch tijdens de Incident Response fase van de SDLC (Software Development Life Cycle)

• Tijdens Incidenten: Het fungeert als een live polscontrole. “Repareren we dit snel genoeg?”
• Post-Mortem: Na een incident helpt het beoordelen van MTTR bij het identificeren of de vertraging werd veroorzaakt door het detecteren van het probleem (MTTD) of het oplossen ervan (MTTR).
• SLA Onderhandeling: Je kunt een klant geen “99,99% uptime” beloven als je gemiddelde MTTR 4 uur is.

Beste Praktijken om MTTR te Verminderen

• Automatiseer Alles: Handmatige oplossingen zijn traag en foutgevoelig. Gebruik Infrastructure as Code (IaC) om kapotte infrastructuur opnieuw uit te rollen in plaats van deze handmatig te repareren.
• Betere Monitoring: Je kunt niet repareren wat je niet kunt zien. Granulaire observatietools helpen de oorzaak sneller te achterhalen, waardoor de “diagnose”-tijd van reparatie wordt verkort.
• Runbooks & Playbooks: Heb vooraf geschreven gidsen voor veelvoorkomende storingen. Als een database vastloopt, zou de ingenieur niet hoeven Googlen “hoe een database te ontgrendelen.”
• Blameless Post-Mortems: Focus op proces verbetering, niet op mensen. Als ingenieurs bang zijn voor straf, kunnen ze storingen verbergen, waardoor MTTR-metrics onnauwkeurig worden.

Gerelateerde Termen

• MTTD (Mean Time To Detect)
• MTBF (Mean Time Between Failures)
• SLA (Service Level Agreement)
• Incident Management

Veelvoorkomende Mythen

• Mythe: Je kunt “nul kwetsbaarheden” bereiken.

  Realiteit: Het doel is om kritieke problemen snel genoeg op te lossen om uitbuiting te voorkomen.

• Mythe: Meer scanners betekenen betere beveiliging.

  In werkelijkheid creëert het toevoegen van tools alleen maar meer ruis en handmatig werk als ze niet geïntegreerd zijn.

• Mythe: Beveiligingstools vertragen ontwikkelaars.

  Realiteit: Beveiliging vertraagt ontwikkelaars alleen wanneer het “kapotte” waarschuwingen genereert. Wanneer je een vooraf geschreven pull request biedt, bespaar je hen uren aan onderzoek.

FAQ

Wat is een “goede” MTTR?

Top DevOps-teams streven naar een MTTR van minder dan 24 uur voor kritieke kwetsbaarheden.

Hoe verschilt MTTR van MTTD?

MTTD (Mean Time to Detect) toont hoe lang een bedreiging aanwezig is voordat je het opmerkt. MTTR toont hoe lang het blijft nadat je het hebt gevonden.

Kan AI daadwerkelijk helpen met MTTR?

Ja. AI-tools zoals Plexicus behandelen triage en stellen oplossingen voor, wat doorgaans 80% van het herstelproces uitmaakt.

Laatste Gedachte

MTTR is de hartslag van je beveiligingsprogramma. Als het hoog is, is je risico hoog. Door de overgang van het vinden van problemen naar het maken van pull-verzoeken te automatiseren, stop je met het behandelen van beveiliging als een knelpunt en begin je het te behandelen als een normaal onderdeel van je CI/CD-pijplijn.