Korjausajan keskiarvo (MTTR)

TL;DR

• MTTR edustaa keskimääräistä aikaa, joka tarvitaan tietoturva-aukon korjaamiseen tunnistamisen jälkeen, tarjoten suoran mittarin operatiivisesta tehokkuudesta.
• MTTR
  laskemiseksi jaa ongelmien korjaamiseen käytetty kokonaisaika tapausten määrällä.
• Tavoitteena on minimoida altistumisaika, jotta hyökkääjät eivät todennäköisesti hyödynnä tunnettuja aukkoja.
• Ratkaisu on nopeuttaa prosessia automatisoimalla kaikki haavoittuvuuksien havaitsemisesta koodin korjausten luomiseen, poistamalla viiveet manuaalisissa tikettijonoissa ja varmistamalla nopeampi korjaus.

Mikä on MTTR?

Korjausajan keskiarvo (MTTR) on keskeinen kyberturvallisuuden mittari, joka osoittaa, kuinka nopeasti reagoit tunnettuun uhkaan. Se mittaa ajan haavoittuvuuden löytämisestä korjauksen toteuttamiseen.

Vaikka mittarit kuten MTTD heijastavat havaitsemisnopeutta, MTTR paljastaa organisaatiosi todellisen korjaustehokkuuden. Nopea havaitseminen on yhdistettävä nopeaan ratkaisuun riskialtistuksen rajoittamiseksi ja liiketoiminnan jatkuvuuden tukemiseksi.

Miksi MTTR on tärkeä

Kyberrikolliset toimivat nopeammin kuin perinteiset kehitysaikataulut, mikä lisää tarvetta reagoiville tietoturvaoperaatioille. Alan trendit osoittavat, että puolustusikkunat ovat kutistumassa.

• 5 päivän hyväksikäyttöikkuna: Vuonna 2025 keskimääräinen hyväksikäyttöaika (TTE), eli aika, joka kuluu haavoittuvuuden julkistamisesta sen aktiiviseen hyväksikäyttöön, laski 32 päivästä vain 5 päivään (CyberMindr, 2025).
• Hyväksikäytön kasvu: Haavoittuvuuksien käyttö sisäänpääsynä on lisääntynyt 34 % tänä vuonna ja aiheuttaa nyt 20 % kaikista vahvistetuista tietomurroista.
• Korjausviive: Hyökkääjät toimivat päivissä, mutta organisaatiot vievät usein viikkoja. Kriittisten haavoittuvuuksien korjaamiseen reuna- ja VPN-laitteissa kuluu keskimäärin 32 päivää, mikä jättää merkittävän riskiajan. Vain 54 % puutteista korjataan koskaan täysin (Verizon DBIR, 2025). Päivän kiihdytys: Hyväksikäytettyjen nollapäivähaavoittuvuuksien löytyminen kasvoi 46 % verrattuna viime vuoteen. Hyökkääjät aseistavat nämä puutteet nyt tunnistamisen jälkeen tunneissa (WithSecure Labs, 2025).
• Korkea MTTR nostaa liiketoimintakustannuksia huomattavasti teknistä velkaa enemmän. Vuonna 2025 Yhdysvaltojen tietomurron keskimääräiset kustannukset ovat 4,4 miljoonaa dollaria, pääasiassa viivästyneen reagoinnin ja sääntelysakkojen vuoksi (IBM, 2025).
• Sääntelysakot: Sääntöjen, kuten DORA
  , mukaan pitkät altistusajat lasketaan operatiivisen resilienssin epäonnistumisiksi. Organisaatiot, joilla on korkea MTTR, kohtaavat nyt pakollisen raportoinnin ja suuret sääntöjenvastaisuussakot. Et voi liikkua nopeammin kuin hyväksikäyttöskriptit; puolustuksesi on puhtaasti teoreettinen.

Kuinka laskea MTTR

MTTR lasketaan jakamalla järjestelmän korjaamiseen käytetty kokonaisaika korjausten lukumäärällä tietyn ajanjakson aikana.

Kaava

MTTR-kaava

Laskentaesimerkki

Kuvittele, että insinööriryhmäsi käsitteli 4 tapausta viime kuussa:

1. Tapaus A: Tietokantakatkos (Korjattu 30 minuutissa)
2. Tapaus B: API-virhe (Korjattu 2 tunnissa / 120 minuutissa)
3. Tapaus C: Välimuistivirhe (Korjattu 15 minuutissa)
4. Tapaus D: Tietoturvapäivitys (Korjattu 45 minuutissa)

• Kokonaiskorjausaika: 30 + 120 + 15 + 45 = 210 minuuttia
• Korjausten lukumäärä: 4

MTTR-kaavan-laskenta

Tämä tarkoittaa, että keskimäärin tiimiltäsi kestää noin 52 minuuttia korjata ongelma, kun he aloittavat sen korjaamisen.

Esimerkki käytännössä

Kuvittele kaksi yritystä, jotka kohtaavat kriittisen tietoturva-aukon (esim. Log4Shell).

Yritys A (Korkea MTTR):

• Prosessi: Manuaalinen. Hälytykset menevät sähköpostiin. Insinöörin on manuaalisesti kirjauduttava SSH
  palvelimille löytääkseen haavoittuvat jar-tiedostot ja korjattava ne yksi kerrallaan.
• MTTR: 48 tuntia.
• Tulos: Hyökkääjillä on kaksi kokonaista päivää hyödyntää haavoittuvuutta. Tiedot ovat todennäköisesti vaarantuneet.

Yritys B (Matala MTTR - käyttää Plexicusta automatisoimaan korjaukset):

• Prosessi: Automaattinen. Haavoittuvuus havaitaan välittömästi. Automaattinen toimintasuunnitelma käynnistyy eristämään vaikuttavat kontit ja soveltamaan korjausta tai virtuaalista palomuurisääntöä.
• MTTR: 15 minuuttia.
• Tulos: Haavoittuvuus suljetaan ennen kuin hyökkääjät voivat käynnistää onnistuneen hyökkäyksen.

Kuka käyttää MTTR

• DevOps-insinöörit - Seuratakseen käyttöönotto- ja palautusputkiensa tehokkuutta.
• SRE
  (Site Reliability Engineers) - Varmistaakseen, että he täyttävät SLA
  (Service Level Agreements) käyttöajan osalta.
• SOC-analyytikot - Mittaavat, kuinka nopeasti he voivat neutralisoida aktiiviset tietoturvauhat.
• CTO
  ja CISO
  - Perustellakseen investointeja automaatiotyökaluihin osoittamalla palautumisajan lyhentymistä.

Milloin soveltaa MTTR

MTTR

tulisi seurata jatkuvasti, mutta se on kriittisintä Incident Response -vaiheessa SDLC

(Software Development Life Cycle)

• Tapahtumien aikana: Se toimii reaaliaikaisena tilannekatsauksena. “Korjaammeko tämän tarpeeksi nopeasti?”
• Jälkipuinti: Tapahtuman jälkeen MTTR
  tarkastelu auttaa tunnistamaan, johtuiko viive ongelman havaitsemisesta (MTTD) vai korjaamisesta (MTTR).
• SLA-neuvottelu: Et voi luvata asiakkaalle “99,99 % käyttöaikaa”, jos keskimääräinen MTTR on 4 tuntia.

Parhaat käytännöt MTTR

vähentämiseksi

• Automatisoi kaikki: Manuaaliset korjaukset ovat hitaita ja virhealttiita. Käytä Infrastructure as Code (IaC) -menetelmää rikkoutuneen infrastruktuurin uudelleen käyttöönottoon sen sijaan, että korjaisit sen manuaalisesti.
• Parempi valvonta: Et voi korjata sitä, mitä et näe. Tarkat havaintotyökalut auttavat tunnistamaan juurisyyn nopeammin, mikä vähentää korjausajan “diagnosointi”-osuutta.
• Runbookit ja Playbookit: Pidä valmiiksi kirjoitettuja oppaita yleisille virheille. Jos tietokanta lukkiutuu, insinöörin ei pitäisi joutua etsimään Googlesta “kuinka avata tietokanta”.
• Syyttömät jälkiselvitykset: Keskity prosessin parantamiseen, ei ihmisiin. Jos insinöörit pelkäävät rangaistusta, he saattavat piilottaa virheitä, mikä tekee MTTR-mittareista epätarkkoja.

Liittyvät termit

• MTTD (Mean Time To Detect)
• MTBF (Mean Time Between Failures)
• SLA (Service Level Agreement)
• Tapahtumien hallinta

Yleiset myytit

• Myytti: Voit saavuttaa “nolla haavoittuvuutta.”

  Todellisuus: Tavoitteena on korjata kriittiset ongelmat tarpeeksi nopeasti, jotta ne eivät ehdi hyödyntää.

• Myytti: Enemmän skannereita tarkoittaa parempaa turvallisuutta.

  Todellisuudessa työkalujen lisääminen vain luo enemmän melua ja manuaalista työtä, jos niitä ei integroida.

• Myytti: Turvallisuustyökalut hidastavat kehittäjiä.

  Todellisuus: Turvallisuus hidastaa kehittäjiä vain, kun se tuottaa “rikkinäisiä” hälytyksiä. Kun tarjoat valmiiksi kirjoitetun pull requestin, säästät heiltä tuntikausia tutkimustyötä.

UKK

Mikä on “hyvä” MTTR?

Huipputason DevOps-tiimit pyrkivät alle 24 tunnin MTTR

kriittisille haavoittuvuuksille.

Miten MTTR eroaa MTTD

?

MTTD (Mean Time to Detect) näyttää, kuinka kauan uhka on olemassa ennen kuin huomaat sen. MTTR näyttää, kuinka kauan se pysyy löydettyäsi sen.

Voiko tekoäly todella auttaa MTTR

?

Kyllä. Tekoälytyökalut kuten Plexicus käsittelevät triagea ja ehdottavat korjauksia, jotka tyypillisesti muodostavat 80 % korjausprosessista.

Lopullinen ajatus

MTTR on tietoturvaohjelmasi syke. Jos se on korkea, riskisi on korkea. Automatisoimalla siirtymisen ongelmien löytämisestä pull-pyyntöjen luomiseen, lopetat tietoturvan käsittelyn pullonkaulana ja alat käsitellä sitä normaalina osana CI/CD-putkeasi.