ZY SLA ve Politika Oluşturma Rehberi

Zafiyet Yönetiminde SLA Nedir ve Neden Gereklidir?

SLA (Service Level Agreement - Hizmet Seviyesi Anlaşması), zafiyet yönetiminde keşfedilen bir zafiyetin ne kadar sürede ele alınması gerektiğini tanımlayan taahhüt çerçevesidir. SLA'sız bir zafiyet yönetimi programı, pusolasız bir gemiye benzer; ilerleme ölçülemez ve güvenlik açıkları kabul edilemez sürelerde açık kalır.

SLA tanımlamak birçok kritik faydayı beraberinde getirir: İyileştirme süreçlerine disiplin katar, ekipler arası beklentileri netleştirir, yönetim raporlaması için standart metrikler üretir ve düzenleyici denetimlerde uyumu kanıtlar. Sektör araştırmalarına göre, net SLA'lar tanımlamış organizasyonlarda MTTR %45 daha kısadır.

Etkili bir SLA çerçevesi, yalnızca zaman sınırları koymaz; aynı zamanda istisna süreçlerini, eskalasyon tetikleyicilerini ve performans ölçüm yöntemlerini de kapsar. Bu bütünsel yaklaşım, SLA'ları biçimsel bir belge olmaktan çıkarıp yaşayan bir yönetim aracına dönüştürür.

Seviye Bazlı SLA Süreleri: Pratik Öneriler

Zafiyet kritiklik seviyesine göre SLA süreleri, organizasyonun risk iştahı ve operasyonel kapasitesiyle uyumlu olmalıdır. Aşağıda sektör standartlarına dayalı önerilen süreler yer almaktadır:

• Kritik (CVSS 9.0-10.0): İyileştirme başlatma: 4 saat, tamamlama: 72 saat (3 gün). İnternetten erişilebilir, aktif istismar edilen zafiyetler için sıfıra yakın tolerans.
• Yüksek (CVSS 7.0-8.9): İyileştirme başlatma: 24 saat, tamamlama: 7 iş günü. Potansiyel etki büyük ancak istismar koşulları bir miktar karmaşık.
• Orta (CVSS 4.0-6.9): İyileştirme başlatma: 72 saat, tamamlama: 30 iş günü. Kontrollü risk; planlı yama döngüsüne dahil.
• Düşük (CVSS 0.1-3.9): İyileştirme başlatma: 1 hafta, tamamlama: 90 iş günü. Bilgilendirme amaçlı, sonraki büyük güncelleme döngüsüne dahil.

"SLA süreleri gerçekçi olmalıdır; ulaşılamaz hedefler ekipte motivasyon kaybına yol açar. Başlangıçta daha rahat süreler belirleyip, olgunluk arttıkça sıkılaştırın."

Varlık kritikliği de SLA hesaplamasında faktör olarak dahil edilmelidir. Bir kritik zafiyet DMZ'deki sunucuda bulunuyorsa standart SLA'nın yarısı uygulanabilirken, izole test ortamında daha esnek süreler tanınabilir.

Zafiyet Yönetimi Politikası Yazım Süreci

Bir zafiyet yönetimi politikası, programın kurallarını, beklentilerini ve prosedürlerini tanımlayan resmi belgedir. Politika yazım süreci sistematik bir yaklaşım gerektirir:

1. Kapsam belirleme: Politikanın hangi varlıkları, ağları ve iş süreçlerini kapsadığını netleştirin.
2. Paydaş analizi: BT, güvenlik, geliştirme, uyum ve yasal ekiplerden temsilcileri belirleyin.
3. Mevcut durum değerlendirmesi: Halihazırda uygulanan süreçleri, araçları ve standartları belirleyin.
4. Taslak oluşturma: Politika bölümlerini (amaç, kapsam, tanımlar, roller, süreçler, SLA'lar, istisnalar) yazın.
5. Gözden geçirme döngüsü: Teknik doğruluk, yasal uyumluluk ve operasyonel uygulanabilirlik açısından inceleyin.
6. Yönetim onayı: CISO ve üst yönetimden resmi onay alın; politikayı kurumsal belge yönetim sistemine kaydedin.
7. Dağıtım ve eğitim: Tüm ilgili personele politikayı duyurun ve farkındalık eğitimleri düzenleyin.

Politika belgesinde kullanılan dil net, anlaşılır ve yoruma açık olmayan ifadelerden oluşmalıdır. "Mümkün olan en kısa sürede" yerine "72 saat içinde" gibi ölçülebilir hedefler tercih edilmelidir.

Yönetim Onayı ve Paydaş Yönetimi

Zafiyet yönetimi politikası, yalnızca güvenlik ekibinin iç dokümanı değildir; üst yönetimin onayladığı ve tüm organizasyonu bağlayan bir kurumsal belge olmalıdır. Yönetim onayı, politikaya otorite kazandırır.

Yönetim onayı sürecinde dikkat edilecek noktalar:

• Politikanın iş etkisini somut örneklerle (güvenlik ihlali maliyeti, uyumsuzluk cezaları) sunun.
• Kaynak gereksinimlerini net biçimde belirtin; bütçe ve insan kaynağı taahhüdü alın.
• Politikayı destekleyen metrik ve KPI hedeflerini tanımlayın.
• Yıllık gözden geçirme takvimini belirleyin ve otomatik hatırlatma mekanizması kurun.

Özellikle BT operasyon ve yazılım geliştirme ekipleri, SLA sürelerinin iş yüklerini artıracağından endişe duyabilir. Bu ekiplerle erken aşamada iletişim kurmak ve otomatize iş akışlarıyla yük azaltma stratejileri sunmak, benimsemeyi kolaylaştırır.

İstisna Süreçleri: SLA Esnekliği

Her zafiyet, standart SLA süreleri içinde kapatılamayabilir. Teknik nedenler (yama mevcut değil, uyumsuzluk riski), iş gereksinimleri (donma dönemleri, kritik proje takvimleri) veya kompenzasyon kontrolleri gibi durumlar istisna sürecini gerektirir.

"İstisna süreci, SLA'nın göz ardı edilmesi değil; riskin kabul edilerek yönetilmesidir. Her istisna belgelenmeli, onaylanmalı ve düzenli olarak gözden geçirilmelidir."

Etkili bir istisna süreci şu bileşenlerden oluşur:

1. İstisna talebi: Gerekçe, etkilenen varlıklar, önerilen kompenzasyon kontrolleri ve talep edilen ek süre belirtilir.
2. Risk değerlendirmesi: Güvenlik ekibi, istisnanın yarattığı ek riski değerlendirir ve risk skorunu günceller.
3. Onay yetkisi: Orta seviye istisnalar güvenlik yöneticisi, yüksek/kritik seviye istisnalar CISO onaylar.
4. Geçerlilik süresi: Her istisna en fazla 90 gün geçerlidir; süre sonunda yeniden değerlendirilir.
5. İzleme: İstisna süresince kompenzasyon kontrollerinin etkinliği izlenir ve kayıt altında tutulur.

SİTEY platformu üzerinde istisna talepleri dijital iş akışıyla yönetilir, onay geçmişi otomatik loglanır ve geçerlilik süresi dolduğunda ilgili kişilere hatırlatma gönderilir.

SLA İhlal Eskalasyonu ve Uyarı Mekanizmaları

SLA ihlali gerçekleştiğinde hızlı ve yapılandırılmış bir eskalasyon süreci devreye girmelidir. Eskalasyon, yalnızca suçlama mekanizması değil; engellerin kaldırılması ve kaynakların yönlendirilmesi aracıdır.

Önerilen eskalasyon kademeleri:

• 1. Kademe - Uyarı (%75 SLA süresinde): Otomatik e-posta ve dashboard uyarısı, atanmış mühendise bildirim.
• 2. Kademe - İhlal (SLA süresinde): Güvenlik yöneticisine eskalasyon, zorunlu durum toplantısı planlanır.
• 3. Kademe - Kritik ihlal (SLA + %50): CISO'ya eskalasyon, BT yönetimi dahil edilir, kök neden analizi başlatılır.
• 4. Kademe - Yönetim müdahalesi (SLA + %100): CTO/CIO'ya eskalasyon, bütçe/kaynak tahsisi kararları alınır.

Her eskalasyon kademesinde alınan aksiyonlar ve sonuçlar belgelenir. Bu veriler, SLA sürelerinin gerçekçiliğini ölçmek ve süreçleri iyileştirmek için değerli girdi sağlar.

SLA Performans Metrikleri ve Sürekli İyileştirme

SLA'ları tanımlamak yeterli değildir; performansın düzenli olarak ölçülmesi ve iyileştirme fırsatlarının belirlenmesi gerekir. Metrik takibi olmayan SLA'lar zamanla etkisini yitirir.

• SLA uyum oranı: Süresinde kapatılan zafiyetlerin toplam zafiyetlere oranı; hedef %90 üzeridir.
• Ortalama SLA aşım süresi: SLA'yı aşan zafiyetlerin ortalama gecikme süresi; süreç darboğazlarını işaret eder.
• İstisna oranı: Toplam zafiyetler içinde istisna tanınan oran; %10 üzerindeyse SLA süreleri gözden geçirilmelidir.
• Eskalasyon frekansı: Eskalasyon tetiklenen zafiyet yüzdesi; yüksekse kaynak veya süreç sorunu vardır.

Bu metrikleri aylık trend grafikleriyle izlemek, iyileşme veya kötüleşme eğilimlerini erken tespit etmenizi sağlar. Çeyreklik retrospektif toplantılarda metrik verileri incelenerek politika güncellemeleri yapılmalıdır.

SİTEY SLA Dashboard ile Gerçek Zamanlı Takip

SİTEY'in SLA Dashboard modülü, tüm zafiyet yönetimi SLA metriklerini tek bir ekrandan izlemenize olanak tanır. Gerçek zamanlı veriler, eyleme dönüştürülebilir içgörüler sunar.

• SLA uyum oranı göstergesi: Anlık ve trend bazlı uyum yüzdelerini seviye bazında görüntüler.
• Yaklaşan SLA ihlalleri paneli: İhlale yaklaşan zafiyetleri otomatik önceliklendirerek proaktif müdahale sağlar.
• Ekip performans kartı: Her ekip üyesinin SLA uyum oranını ve iş yükünü gösterir.
• Otomatik rapor zamanlayıcı: Haftalık ve aylık SLA raporlarını belirlenen alıcılara otomatik gönderir.

Dashboard'un sunduğu şeffaflık, güvenlik ekibinden üst yönetime kadar herkesin aynı verilere bakmasını sağlar. SİTEY, SLA süreçlerinizi politikadan pratiğe dönüştüren entegre bir platform olarak her ölçekte organizasyona değer sunar.