Sahada İşe Yarayan Risk Bazlı Patch SLA Tasarımı

Severity Bazlı SLA Modelleri Neden Kırılıyor?

Çoğu patch SLA aynı temel nedenle başarısız oluyor: yazmak kolay, içinde yaşamak zor. "Critical 7 gün, high 30 gün" gibi kurallar kağıt üstünde temiz görünür ama operasyonel aciliyeti gerçekten belirleyen her faktörü görmezden gelir.

İzole bir dahili test sistemindeki, halka açık maruziyeti olmayan ve işleyen bir telafi edici kontrole sahip CVSS 9.8 zafiyet, CISA KEV kataloğunda aktif olarak yer alan internete açık bir üretim servisindeki CVSS 7.2 zafiyetle aynı remediation kuyruğuna girmemalı. Bunları özdeşmiş gibi ele almak müdahale kapasitesini israf eder ve ekibin önceliklendirme sistemine olan güvenini aşındırır.

İşe Yarayan SLA Neyi Yansıtmalı?

Savunulabilir bir patch SLA en az şu dört boyutu içermeli:

teknik severity.

exploit gerçekliği.

maruziyet durumu.

iş kritiği.

Bu katmanlar olmadan politika ya operasyonu yönetilemez bir yük altına alır ya da yüksek puanlı bulguların gerçek risk sırasına göre giderildiğine dair yanlış bir güven hissi üretir.

Pratik Bir Katmanlama Modeli

Pratik model, teorik olarak mükemmel olandan sürekli daha iyi performans gösteriyor. Aşağıdaki tablo dört boyutu — severity, exploitation sinyali, maruziyet durumu ve varlık kritiği — eyleme dönüşebilir SLA parçalarına aktarıyor:

| Koşul | Önerilen SLA | Sahip Eylemi |

| --- | --- | --- |

| KEV + internet-facing + kritik varlık | 24-48 saat | Acil değişiklik penceresi; adı belirli sahip hemen bildirilir |

| KEV + internet-facing + kritik olmayan | 3-5 gün | Standart acil parça; yama gecikirken telafi edici kontrol belgelenir |

| Yüksek EPSS (>0,7) + erişilebilir servis | 7 gün | Yüksek öncelik; telafi edici kontroller kontrol edilir |

| Kritik CVSS + dahili + yanal hareket yolu yok | 14-30 gün | Planlı yama döngüsü; acil gerek yok |

| Yüksek severity + telafi edici kontrol doğrulandı | 30 gün + gözden geçirme tarihi | Kontrol belgelenir, yeniden değerlendirme tetikleyicisi ayarlanır |

| Düşük erişilebilirlik + hafifletilmiş | İstisna değerlendirmesi | Adı belirli onaylayıcı imzalar; 90 günlük gözden geçirme tarihi belirlenir |

Amaç sonsuz nüans katmanları oluşturmak değil. Amaç, açıkça farklı koşullar taşıyan yüksek severity bulgularını hepsini özdeşmiş gibi ele almayı bırakmak. Altı kademe yönetilebilir. Altmış kademe değil.

Tasarım Kadar Uygulama da Kritik

Sahiplik, escalation yolları ve istisna yönetimi açıkça tanımlanmadan SLA'nın operasyonel anlamı yok. Bir remediation penceresi işlem yapılmadan kapandığında kimse hesap vermiyorsa, politika işlevsel bir güvenlik kontrolü olmaktan çıkıp raporlama egzersizine dönüşür. SLA tasarımının en zor kısmı katmanlama mantığı değil — onun etrafına inşa edilen hesap verebilirlik yapısı.

Bu şu anlama geliyor: SLA tarafından yönlendirilen her bulgunun adı belirli bir sahibi, pencere kayma riskinde devreye girecek tanımlı bir escalation zinciri ve planlanmış yama yapmanın gerçekten mümkün olmadığı durumlar için belgelenmiş bir istisna süreci olmalı. Bu üç unsur olmadan, en dikkatli tasarlanmış katmanlama modeli bile yetersiz kalır.

İstisna Yönetimi Nasıl Görünmeli?

İstisnalar kaçınılmaz. Amaç bunları ortadan kaldırmak değil, bilinçli kılmak. İyi tasarlanmış bir istisna süreci şunları gerektiriyor:

artık riski kabul etmeye yetecek yetkiye sahip, adı belirli bir onaylayıcı.

istisna penceresi boyunca exploitability'yi anlamlı biçimde azaltan bir telafi edici kontrol.

belirsiz erteleme değil, sabit bir gözden geçirme tarihi.

Gözden geçirilmeden yığılan istisnalar gerçek backlog haline gelir. Eskime ve yeniden değerlendirme döngüleriyle birlikte açıkça izlemek, yönetilen risk ile zamanla gerçekleşen ertelenmiş risk arasındaki farktır.

MyVuln Yaklaşımı

MyVuln, KEV durumu, EPSS skoru, varlık maruziyeti ve iş kritiğinin tümü tek bir iş akışında görünür olduğunda daha güçlü SLA tasarımını destekliyor. MyVuln'un remediation önceliklendirme görünümü tam bu dört boyutu bir arada sunuyor — bir bulguyu doğru SLA kademine yönlendirmek için gereken veri, dört ayrı araçtan elle derlenmek yerine karar anında hazır ve güncel olarak önünüzde duruyor. İyi remediation politikası şık politika diline değil; o yönlendirme sinyalinin eksiksiz ve güncel olmasına bağlı.

Patch SLA'ları tüm severity sınıflandırmalarına tek tip aciliyet dayattıklarında operasyonel olarak işlevsizleşir. "Yüksek ve kritik her zafiyet 48 saat içinde kapatılır" politikası yönetim sunumunda güçlü görünür; ancak gerçek değişiklik yönetimi süreçleri, bakım penceresi kısıtları ve üretim kararlılığı gereksinimleriyle karşılaştığında hızla aşınır. Güvenlik ekibi aciliyet arar; operasyon ekibi öngörülebilirlik ister. Her ikisine de yer açmayan SLA tasarımları her iki paydaşın gözünde güvenilirliğini kaybeder. Ekipler SLA hedeflerini gerçek taahhütler olarak görmeyi bıraktığında mekanizmanın kendisi güvenilmez hale gelir.

Kurumların gerçekten sürdürebildiği farklılaştırılmış bir SLA yapısı:

| Risk kademesi | Kriter | SLA hedefi |

|---|---|---|

| Kademe 1 — Kritik | KEV'de VE internete açık | 24–48 saat |

| Kademe 2 — Yüksek | KEV'de VEYA internete açık, güçlü kompansasyon yok | 7 gün |

| Kademe 3 — Yükseltilmiş | CVSS ≥ 7.0, iş kritiği A veya B, kompansasyon yok | 30 gün |

| Kademe 4 — Standart | CVSS ≥ 4.0, internete kapalı, kompansasyon mevcut | 90 gün |

| Kademe 5 — İzleniyor | CVSS < 4.0 veya izole varlık | Bir sonraki planlı bakım döngüsü |

İşlevsel SLA tasarımı risk profili gerçekten gerektirdiğinde zorlayıcı, her yerde ise güvenilir, farklılaştırılmış şeritler oluşturur. Bu ayrım gevşeklik değil; karar kalitesidir. Hedef her şeyi aynı anda maksimum hızda kapatmak değil; en hızlı maddi zarara yol açacak güzergâhı önce daraltmaktır.

Olgun kurumlar patch SLA'yı tek taraflı güvenlik ekibi talebi olarak değil; ortak çalışma sözleşmesi olarak yapılandırır. Varlık sahipliği, bakım penceresi gerçeklikleri, acil durum istisna prosedürleri, exploitation sinyal eşikleri ve kaçırılan son tarihlere yönelik yükseltme yolları ortak olarak tanımlanır. Ekipler yönetilecekleri SLA'nın tasarımına katıldığında onu varsayılan olarak kaçıracakları dışarıdan dayatılmış bir hedef değil; zorlayıcı ama adil bir operasyonel sözleşme olarak görürler. En iyi patch SLA en agresif olan değil; kurumun gerçekten uyduğu ve yüksek riskli zafiyetleri tutarlı biçimde kuyruğun önüne taşıyan SLA'dır.