Zafiyet Yönetimi Programı: Tarama, Önceliklendirme ve SLA

Ayda bir çalışan tarayıcı, yüzlerce sayfalık bir rapor, her ay aynı kalan kritik bulgu sayısı. Pek çok kurumda zafiyet yönetimi bundan ibarettir ve denetimde “zafiyetleri nasıl yönetiyorsunuz?” sorusuna bir tarama ekran görüntüsüyle cevap verilir. Rapor üretmek program değildir. Aşağıda kapsam, kimlik bilgili tarama, sömürü sinyalleriyle önceliklendirme, kapatma süreleri, istisna süreci ve ölçülebilir metriklerle işleyen bir zafiyet yönetimi programını adım adım kuruyoruz.

Zafiyet taraması ile zafiyet yönetimi farkı

Tarama veri toplar; yönetim bu veriyi karara ve kapanışa dönüştürür. Kurumsal siber güvenlik açısından bir programın bileşenleri şunlardır:

1. Kapsam: Hangi varlıkların hangi yöntemle ve hangi sıklıkta değerlendirildiği.
2. Tespit: Ağ tabanlı tarama, ajan tabanlı tarama, bulut yapılandırma değerlendirmesi, uygulama taraması.
3. Önceliklendirme: Ciddiyet, sömürülebilirlik ve varlık kritikliğinin birleşimi.
4. Düzeltme: Yama, yapılandırma değişikliği, sürüm yükseltme veya telafi edici kontrol.
5. Doğrulama: Düzeltmenin yeniden taramayla teyidi.
6. İstisna ve risk kabulü: Kapatılamayan bulguların süreli ve onaylı yönetimi.
7. Ölçüm: Programın işlediğini gösteren metrikler.

ISO/IEC 27001:2022 Ek A 8.8 (Teknik zafiyetlerin yönetimi) ve NIS2’nin zafiyet yönetimi başlığı, taramanın yapıldığını değil bu döngünün döndüğünü görmek ister. Yama dağıtımının teknik tarafı (WSUS, Azure Update Manager) için sunucu yama yönetimi rehberine bakın; burada programın karar ve ölçüm katmanına odaklanıyoruz.

Kapsam ve kimlik bilgili tarama

Kapsamı varlık envanteri belirler; tarayıcının “bulduğu” cihazlar değil. İki listeyi ayrı ayrı raporlayın: envanterde olup son 30 günde taranmamış varlıklar ve taramada görünüp envanterde olmayan varlıklar. Programın kör noktaları bu iki listededir.

Kimlik bilgisi olmadan yapılan ağ taraması yalnızca dışarıdan görünen servisleri ve banner bilgisini değerlendirir. Yüklü yazılım sürümleri, eksik işletim sistemi yamaları ve yerel yapılandırma hataları ancak kimlik bilgili taramada veya ajanla görünür.

Yöntem	Güçlü yanı	Sınırlaması
Kimlik bilgisiz ağ taraması	Saldırgan bakışını gösterir	Yerel yazılım zafiyetlerini kaçırır
Kimlik bilgili ağ taraması	Yama ve yazılım sürümlerini görür	Ayrıcalıklı hesap yönetimi gerektirir
Ajan tabanlı tarama	Ağ dışındaki dizüstüleri de kapsar	Ağ cihazı ve gömülü sistemlere kurulamaz
Dış yüzey taraması	İnternete açık varlığı doğrular	İç ağdaki riski göstermez

Kimlik bilgili tarama hesabı saldırgan için değerli bir hedeftir. Windows’ta bu hesap yalnızca tarama hedeflerinde yerel yönetici olmalı, etkileşimli oturum açamamalı ve domain admin olmamalı. Linux’ta SSH anahtarıyla ve sınırlı sudo yetkisiyle çalışmalı. Her taramada kimlik doğrulamanın başarılı olduğu hedeflerin oranını izleyin. Sahada en sık gördüğümüz tablo şudur: parolası değişmiş tarama hesabı, kimlik doğrulaması başarısız olan yüzlerce hedef ve “temiz” görünen bir rapor. Temiz rapor yanıltır. İnternete açık varlıkların keşfi için dış saldırı yüzeyi yönetimi rehberi tamamlayıcıdır.

CVSS’in sınırları: EPSS ve KEV ile önceliklendirme

CVSS temel puanı bir zafiyetin teknik ciddiyetini ölçer; sizin ortamınızdaki riski de, sömürülme olasılığını da ölçmez. Yalnızca CVSS 7.0 ve üzerini “acil” sayan programlar binlerce bulguyu aynı önceliğe koyar ve gerçekten sömürülenleri ayırt edemez. Ekip her şeyi acil görünce hiçbir şeyi acil yapamaz. CVSS v4.0 da bu yüzden temel puanın tehdit ve ortam ölçütleriyle zenginleştirilmesini açıkça öne çıkarır.

Önceliklendirmede iki dış sinyal pratikte işe yarar:

• CISA KEV kataloğu: ABD CISA’nın, sahada aktif olarak sömürüldüğüne dair güvenilir kanıt bulunan zafiyetleri listelediği katalog. Listede olmak “teorik değil, gerçek” demektir.
• EPSS: FIRST tarafından yayımlanan, bir CVE’nin önümüzdeki 30 gün içinde sömürü faaliyetinde görülme olasılığını 0–1 arasında tahmin eden model. Her gün güncellenir.

Her iki kaynak da makinece okunabilir biçimde sunulur ve tarama sonuçlarına otomatik eklenebilir:

# CISA KEV kataloğunu indir ve CVE listesini çıkar
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq -r '.vulnerabilities[].cveID' > kev-cve.txt

# Tek bir CVE için EPSS olasılığı ve yüzdelik değeri
curl -s "https://api.first.org/data/v1/epss?cve=CVE-2021-44228" \
  | jq '.data[] | {cve, epss, percentile}'

Karar mantığı bu sinyalleri varlık kritikliğiyle birleştirir. Aşağıdaki sıralama örnek bir şablondur; eşikleri kendi risk iştahınıza göre ayarlayın:

1. KEV’de olan ve internete açık veya kritik varlıktaki bulgular: en yüksek öncelik.
2. KEV’de olan iç ağ bulguları ve EPSS değeri yüksek (örnek eşik: 0,1 üzeri) olan internete açık bulgular.
3. CVSS yüksek/kritik, sömürü sinyali olmayan, kritik varlıktaki bulgular.
4. Diğer bulgular: standart bakım döngüsünde kapatılır.

Daha yapılandırılmış bir karar ağacı istiyorsanız CISA’nın SSVC (Stakeholder-Specific Vulnerability Categorization) yaklaşımına bakın. SSVC; sömürü durumunu, saldırının otomatikleştirilebilirliğini, teknik etkiyi ve görev/kamu etkisini karar noktası olarak kullanır ve sonucu sayısal puan yerine “izle”, “takip et”, “müdahale et” gibi eylem kategorileriyle verir.

Kapatma süreleri (SLA) tasarımı

SLA, bulgunun tespit tarihinden doğrulanmış kapanışına kadar izin verilen azami süredir. Tasarlarken şu üç noktaya dikkat edin:

• Süreyi CVSS sınıfına değil, yukarıdaki öncelik sınıfına bağlayın.
• Sayaç bulgunun ilk tespitinde başlar, yeniden tarama tarihinde durur. Bilet kapanışı tek başına kanıt değildir.
• Bakım penceresi gerçeğini hesaba katın. Uygulanamayan bir SLA istisna yığınına dönüşür.

Öncelik sınıfı	Örnek SLA	Notlar
P1: KEV + açık/kritik varlık	7 gün veya daha kısa	Acil değişiklik süreci kullanılır
P2: Sömürü sinyali yüksek	15 gün	Bir sonraki bakım penceresi
P3: Yüksek ciddiyet, sinyal yok	30 gün	Aylık yama döngüsü
P4: Diğer	90 gün	Sürüm yükseltme planıyla

Tablodaki süreler örnektir; hiçbir standarttan alınmamıştır. Müşteri sözleşmeniz veya sektör düzenlemeniz daha kısa süre öngörüyorsa o süre esas alınır.

İstisna ve risk kabul süreci

Bazı bulgular SLA içinde kapanmaz: üreticinin desteğini bitirdiği bir uygulama, sertifikalı bir medikal cihaz, yeniden başlatılmasına izin verilmeyen bir üretim sunucusu. Yama yapılamayan OT sistemleri için karar yöntemi OT zafiyet yönetimi ve yama kararı rehberinde ayrıca anlatılıyor. IT ortamında istisna kaydı en az şunları içermeli:

• Bulgu, etkilenen varlıklar ve öncelik sınıfı
• Kapatılamama gerekçesi (teknik engel, üretici bağımlılığı)
• Telafi edici kontroller: ağ izolasyonu, servis kapatma, erişim kısıtı, ek izleme
• Risk sahibi olarak iş biriminin yöneticisinin onayı
• Bitiş tarihi; süresiz istisna kabul edilmez

Süresi dolan istisna otomatik olarak açık bulguya döner ve SLA ihlali olarak raporlanır. Yenileme sırasında telafi edici kontrolün hâlâ yerinde olduğunu doğrulayın; firewall kuralı birkaç değişiklik sonra sessizce kaybolmuş olabilir. Kâğıttaki kural koruma sağlamaz.

Program metrikleri

Metrikler “kaç bulgu var?” sorusuna değil, “program işliyor mu?” sorusuna cevap vermeli:

Metrik	Neyi gösterir
Tarama kapsamı (taranan / envanterdeki varlık)	Kör nokta büyüklüğü
Kimlik doğrulama başarı oranı	Sonuçların güvenilirliği
Öncelik sınıfına göre ortalama kapatma süresi	Düzeltme hızı
SLA içinde kapatılan bulgu oranı	Taahhüde uyum
SLA’yı aşmış açık bulgu sayısı ve yaşı	Biriken risk
Yeniden açılan bulgu sayısı	Kalıcı olmayan düzeltmeler
Aktif ve süresi dolmuş istisna sayısı	Risk kabulünün disiplini

Metrikleri varlık sahibi ekip bazında raporladığınızda düzeltme sorumluluğu netleşir. Yeniden açılan bulguların çoğu yapılandırma kaynaklıysa sorun yamada değil temel çizgidedir; bu konu yapılandırma uyumu ve sapma takibi rehberinde ele alınıyor.

Denetim için kanıt seti

Denetçi programın tasarımını ve işleyişini ayrı ayrı sorgular. Aşağıdaki set çoğu ISO 27001, TISAX, müşteri ve siber güvenlik denetiminde yeterli kabul görür:

• Onaylı zafiyet yönetimi prosedürü: kapsam, sıklık, öncelik sınıfları ve SLA tablosu
• Tarama takvimi ve son dönem tarama işlerinin tarihli çıktıları
• Kapsam raporu: envanter ile taranan varlık karşılaştırması
• Örneklem: seçilen birkaç kritik bulgu için tespit tarihi, bilet, değişiklik kaydı ve yeniden taramayla kapanış kanıtı
• Güncel istisna listesi, onaylar ve bitiş tarihleri
• Son dönemin metrik raporu ve yönetime sunulduğunu gösteren kayıt

Otomatik taramanın bulamadığı zincirleme saldırı yolları ve iş mantığı hataları için manuel test gerekir; ayrımı sızma testi kapsamı ve bulgu doğrulama rehberinde anlatıyoruz. Programı sıfırdan kurmak ya da mevcut taramalarınızın kapsamını ve kalitesini ölçtürmek isterseniz zafiyet analizi ve güvenlik taramaları hizmetimize göz atabilirsiniz. Kaynaklar: CISA KEV kataloğu ve FIRST EPSS.

Sık sorulan sorular

CVSS puanı yüksek olan her zafiyet acil mi?

Hayır. CVSS temel puanı teknik ciddiyeti ölçer; sömürülme olasılığını veya ortamınızdaki etkiyi ölçmez. CISA KEV kataloğunda yer alma, EPSS olasılığı ve varlığın kritikliği birlikte değerlendirildiğinde gerçekten acil olan bulgular ayrışır.

Kimlik bilgili tarama neden gerekli?

Kimlik bilgisiz tarama yalnızca ağdan görünen servisleri değerlendirir. Eksik işletim sistemi yamaları, yüklü yazılım sürümleri ve yerel yapılandırma hataları ancak kimlik bilgili tarama veya ajanla görünür. Kimlik doğrulama başarı oranını da ayrıca izleyin.

Zafiyet kapatma süreleri için standart bir değer var mı?

Evrensel bir değer yok. Süreler kurumun risk iştahına, bakım pencerelerine ve sözleşme ya da düzenleyici gerekliliklere göre belirlenir. CVSS sınıfı yerine sömürü sinyali ve varlık kritikliğini içeren öncelik sınıflarına bağlanmaları önerilir.

Kapatılamayan bir zafiyet nasıl yönetilir?

Gerekçe, telafi edici kontroller, risk sahibinin onayı ve bitiş tarihi içeren bir istisna kaydı açılır. Süresi dolan istisna otomatik olarak açık bulguya döner; yenilemede telafi edici kontrollerin hâlâ uygulandığı doğrulanır.