Düzeltme İçin Ortalama Süre (MTTR)

Kısaca

MTTR, bir güvenlik açığının tespit edildikten sonra çözülmesi için gereken ortalama süreyi temsil eder ve operasyonel verimliliğin doğrudan bir ölçüsünü sağlar.
MTTR’yi hesaplamak için, sorunları düzeltmek için harcanan toplam süreyi olay sayısına bölün.
Amaç, maruz kalma süresini en aza indirmektir, böylece saldırganlar bilinen boşluklardan yararlanma olasılığı daha düşük olur.
Çözüm, süreci hızlandırmaktır, bu da güvenlik açığı tespitinden kod düzeltme üretimine kadar her şeyi otomatikleştirerek manuel bilet kuyruklarındaki gecikmeleri ortadan kaldırır ve daha hızlı düzeltme sağlar.

MTTR Nedir?

Düzeltme İçin Ortalama Süre (MTTR), bilinen bir tehdide ne kadar hızlı yanıt verdiğinizi gösteren önemli bir siber güvenlik metriğidir. Bir güvenlik açığının bulunmasından düzeltmenin uygulanmasına kadar geçen süreyi ölçer.

MTTD gibi metrikler tespit hızını yansıtırken, MTTR organizasyonunuzun gerçek düzeltme verimliliğini ortaya koyar. Hızlı tespit, risk maruziyetini sınırlamak ve iş sürekliliğini desteklemek için hızlı çözümle eşleştirilmelidir.

MTTR Neden Önemlidir

Siber suçlular, geleneksel geliştirme zaman çizelgelerinden daha hızlı hareket eder ve bu da duyarlı güvenlik operasyonları talebini artırır. Endüstri trendleri, savunma pencerelerinin daraldığını göstermektedir.

5 günlük istismar penceresi: 2025 yılında, bir güvenlik açığının kamuya açıklanması ile aktif olarak istismar edilmesi arasındaki boşluk olan İstismar Süresi (TTE), 32 günden sadece 5 güne düştü (CyberMindr, 2025).
İstismar artışı: Güvenlik açıklarını bir giriş yolu olarak kullanma oranı bu yıl %34 arttı ve artık tüm doğrulanmış ihlallerin %20’sine neden oluyor.
Düzeltme gecikmesi: Saldırganlar günler içinde harekete geçerken, organizasyonlar genellikle haftalar alır. Kenar ve VPN cihazlarındaki kritik güvenlik açıklarını düzeltme medyan süresi 32 gün olarak kalıyor ve bu da önemli bir risk penceresi bırakıyor. Kusurların sadece %54’ü tamamen yamalanıyor (Verizon DBIR, 2025). Gün Hızlanması: İstismar edilen sıfır gün güvenlik açıklarının keşfi geçen yıla göre %46 arttı. Saldırganlar artık bu kusurları tespit edildikten saatler sonra silah haline getiriyor (WithSecure Labs, 2025).
Yüksek MTTR iş maliyetlerini teknik borcun çok ötesine taşıyor. 2025 yılında, ABD’deki bir veri ihlalinin ortalama maliyeti, gecikmiş yanıt ve düzenleyici cezalar nedeniyle 4,4 milyon dolar (IBM, 2025).
Uyum cezaları: DORA gibi kurallar altında, uzun maruz kalma süreleri operasyonel dayanıklılık altında başarısızlık olarak sayılır. Yüksek MTTR’ye sahip organizasyonlar artık zorunlu raporlama ve büyük uyumsuzluk cezalarıyla karşı karşıya. İstismar scriptlerinden daha hızlı hareket edemezsiniz; savunmanız tamamen teoriktir.

MTTR Nasıl Hesaplanır

MTTR, belirli bir dönem boyunca gerçekleştirilen onarımların sayısına bölünerek sistemin onarımı için harcanan toplam süre ile hesaplanır.

Formül

MTTR-formülü

Hesaplama Örneği

Mühendislik ekibinizin geçen ay 4 olay ile ilgilendiğini hayal edin:

Olay A: Veritabanı kesintisi (30 dakikada düzeltildi)
Olay B: API arızası (2 saatte / 120 dakikada düzeltildi)
Olay C: Önbellek hatası (15 dakikada düzeltildi)
Olay D: Güvenlik yaması (45 dakikada düzeltildi)

Toplam Onarım Süresi: 30 + 120 + 15 + 45 = 210 dakika
Onarım Sayısı: 4

MTTR-formül-hesaplama

Bu, ekibinizin bir sorunu çözmeye başladığında ortalama olarak 52 dakika sürdüğünü gösterir.

Uygulamada Örnek

Log4Shell gibi kritik bir güvenlik açığı ile karşılaşan iki şirketi düşünün.

Şirket A (Yüksek MTTR):

Süreç: Manuel. Uyarılar e-posta ile gönderilir. Bir mühendis, sunuculara manuel olarak SSH yaparak savunmasız jar dosyalarını bulmalı ve tek tek yamalamalıdır.
MTTR: 48 Saat.
Sonuç: Saldırganların güvenlik açığını istismar etmek için iki tam günü vardır. Veriler muhtemelen tehlikeye girmiştir.

Şirket B (Düşük MTTR - Plexicus kullanarak otomatik iyileştirme):

Süreç: Otomatik. Güvenlik açığı hemen tespit edilir. Etkilenen konteynerleri izole etmek ve bir yamayı veya sanal güvenlik duvarı kuralını uygulamak için otomatik bir playbook tetiklenir.
MTTR: 15 Dakika.
Sonuç: Saldırganlar başarılı bir istismar başlatmadan önce güvenlik açığı kapatılır.

MTTR’yi Kimler Kullanır

DevOps Mühendisleri - Dağıtım ve geri alma hatlarının verimliliğini izlemek için.
SRE’ler (Site Güvenilirlik Mühendisleri) - Çalışma süresi için SLA’ları (Hizmet Düzeyi Anlaşmaları) karşıladıklarından emin olmak için.
SOC Analistleri - Aktif güvenlik tehditlerini ne kadar hızlı etkisiz hale getirebildiklerini ölçmek için.
CTO’lar ve CISO’lar - Kurtarma süresinde bir azalma göstererek otomasyon araçlarına yapılan yatırımları haklı çıkarmak için.

MTTR Ne Zaman Uygulanmalı

MTTR sürekli izlenmelidir, ancak Olay Müdahale aşamasında en kritik öneme sahiptir SDLC (Yazılım Geliştirme Yaşam Döngüsü)

Olaylar Sırasında: Canlı bir nabız kontrolü olarak işlev görür. “Bunu yeterince hızlı düzeltiyor muyuz?”
Post-Mortem: Bir olaydan sonra, MTTR’yi gözden geçirmek, gecikmenin sorunun tespit edilmesinden (MTTD) mi yoksa düzeltilmesinden (MTTR) mi kaynaklandığını belirlemeye yardımcı olur.
SLA Müzakeresi: Ortalama MTTR’niz 4 saat ise bir müşteriye “%99.99 çalışma süresi” vaat edemezsiniz.

MTTR’yi Azaltmak İçin En İyi Uygulamalar

Her Şeyi Otomatikleştirin: Manuel düzeltmeler yavaş ve hataya açıktır. Bozuk altyapıyı manuel olarak düzeltmek yerine Kod Olarak Altyapı (IaC) kullanarak yeniden dağıtın.
Daha İyi İzleme: Göremediğiniz şeyi düzeltemezsiniz. Ayrıntılı gözlemlenebilirlik araçları, kök nedeni daha hızlı belirlemeye yardımcı olur ve “teşhis” süresini kısaltır.
Çalışma Kitapları ve Oyun Kitapları: Yaygın hatalar için önceden yazılmış kılavuzlar bulundurun. Bir veritabanı kilitlenirse, mühendis “veritabanı nasıl açılır” diye Google’da arama yapmamalıdır.
Suçlamasız Sonrası İncelemeler: İnsanlar yerine süreç iyileştirmeye odaklanın. Mühendisler ceza korkusu yaşarsa, hataları gizleyebilirler ve bu da MTTR metriklerini yanlış hale getirir.

İlgili Terimler

MTTD (Ortalama Tespit Süresi)
MTBF (Ortalama Arıza Arası Süre)
SLA (Hizmet Düzeyi Anlaşması)
Olay Yönetimi

Yaygın Mitler

Mit: “Sıfır güvenlik açığı”na ulaşabilirsiniz.

Gerçek: Amaç, kritik sorunları sömürüden önce yeterince hızlı bir şekilde düzeltmektir.
Mit: Daha fazla tarayıcı daha iyi güvenlik sağlar.

Gerçekte, araç eklemek, entegre edilmezse sadece daha fazla gürültü ve manuel iş yaratır.
Mit: Güvenlik araçları geliştiricileri yavaşlatır.

Gerçek: Güvenlik, yalnızca “bozuk” uyarılar oluşturduğunda geliştiricileri yavaşlatır. Önceden yazılmış bir çekme isteği sağladığınızda, onlara saatlerce araştırma yapmaktan tasarruf ettiriyorsunuz.

SSS

“İyi” bir MTTR nedir?

En iyi DevOps ekipleri, kritik güvenlik açıkları için 24 saatten kısa bir MTTR hedefler.

MTTR, MTTD’den nasıl farklıdır?

MTTD (Ortalama Tespit Süresi), bir tehdidin fark edilmeden önce ne kadar süreyle mevcut olduğunu gösterir. MTTR ise bulduktan sonra ne kadar süreyle kaldığını gösterir.

Yapay Zeka gerçekten MTTR’ye yardımcı olabilir mi?

Evet. Plexicus gibi yapay zeka araçları triyajı yönetir ve düzeltmeler önerir, bu da genellikle iyileştirme sürecinin %80’ini oluşturur.

Son Düşünce

MTTR, güvenlik programınızın nabzıdır. Eğer yüksekse, riskiniz de yüksektir. Sorunları bulmaktan çekme istekleri oluşturmaya geçişi otomatikleştirerek, güvenliği bir darboğaz olarak görmekten çıkıp, CI/CD hattınızın normal bir parçası olarak görmeye başlarsınız.