Zafiyet Yönetimi (Vulnerability Management) Süreci Nasıl Kurulur?

Modern bir teknoloji şirketinde asıl güvenlik sorunu zafiyetlerin bulunamaması değil, aksine tarama araçlarının (Scanner) on binlerce zafiyet (CVE) bulup BT ekiplerini alarm yorgunluğuna (Alert Fatigue) sokmasıdır.

Etkili bir Zafiyet Yönetimi (Vulnerability Management) süreci; "Her bulduğunu yamala" gibi çalışmayan bir felsefeden ziyade, "Önce gerçekten yanmakta olan yangınları söndür" mantığıyla risk bazlı hareket eder. CRA, NIS2 ve Türkiye'deki 7545 sayılı Siber Güvenlik Kanunu gibi regülasyonlar da şirketlerden kaotik bir çaba değil, izlenebilir ve sistematik bir zafiyet yönetim döngüsü bekler.

Zafiyet Yönetimi Yaşam Döngüsü (Lifecycle)

Başarılı bir süreç 5 ana adımdan oluşan ve hiç bitmeyen bir döngüdür:

#

1. Keşif ve Envanter (Discovery)

Koruyacağınız sistemin sınırlarını bilmeden zafiyet bulamazsınız. İlk adım, şirketin dijital ayak izini haritalandırmaktır. Sunucular, bulut (AWS/Azure) varlıkları, geliştirici bilgisayarları, dışa açık (Public) API'ler ve SBOM ile elde edilen yazılım bağımlılıkları eksiksiz listelenmelidir.
> *Kural:* Varlık envanterinizde olmayan bir cihazdaki kritik zafiyeti asla göremezsiniz.

#

2. Tarama (Scanning)

Zafiyet tarama araçları (Örn. Nessus, Qualys, OpenVAS) ve kod içi analiz araçları (SCA/SAST) kullanılarak envanterdeki sistemler belirli periyotlarla (Örn. dışa açık sistemler için her gün, iç ağlar için haftada bir) taranır. Sonuç, potansiyel güvenlik açıklarının yer aldığı devasa bir listedir.

#

3. Önceliklendirme (Prioritization / Triage)

Burasi sürecin kalbidir. Binlerce zafiyeti aynı anda kapatmaya çalışmak BT operasyonlarını durdurur. Yeni nesil yaklaşımlar zafiyetleri aşağıdaki faktörlere göre filtreler:
- **CISA KEV (Known Exploited Vulnerabilities):** Açık sadece teorik mi yoksa an itibariyle internette Rus veya Çinli hacker grupları tarafından aktif olarak kullanılıyor mu? (Kullanılıyorsa 1 numaralı önceliktir).
- **EPSS (Exploit Prediction Scoring System):** Bu zafiyetin önümüzdeki 30 gün içinde istismar edilme ihtimali istatistiksel olarak yüzde kaçtır?
- **Varlık Kritiği:** Zafiyet, müşteri veritabanı sunucusunda mı yoksa stajyerlerin kullandığı boş bir test sunucusunda mı?
- **Erişilebilirlik:** Zafiyetli sistem internete doğrudan açık mı, yoksa VPN arkasında derin bir katmanda mı?

CVSS v4.0 skoru 9.8 (Kritik) olan ama internetten erişilemeyen bir zafiyettendense, CVSS skoru 7.5 olan ama aktif olarak istismar edilen dışa açık bir zafiyet önce kapatılmalıdır.

#

4. Giderme ve Yama (Remediation / Patching)

Açığın kapatılması için ilgili sistemlere üreticinin (Örn. Microsoft, Linux) çıkardığı yama (patch) yüklenir. Eğer bir yama henüz yoksa (Zero-Day) veya yama yüklemek sistemi bozacaksa "Telafi Edici Kontroller" (Mitigation) devreye alınır. (Örneğin, WAF üzerinden o zafiyete gelen trafiği bloklayan geçici bir kural yazmak).

#

5. Doğrulama (Verification)

Yama uygulandıktan sonra BT ekibinin işi bitmez. Güvenlik ekibi veya sistem, ilgili cihazı tekrar tarayarak (Rescan) zafiyetin gerçekten kapandığını raporlar ve döngü baştan başlar.

Hizmet Seviyesi Taahhütleri (SLA) Belirlemek

Zafiyet yönetimi sürecinin işlemesi için BT (IT) ve Bilgi Güvenliği ekipleri arasında süreye dayalı mutabakatlar (SLA) olmalıdır. Örnek bir endüstri standardı SLA matrisi:

- **Kritik (Kırmızı):** CVSS 9.0+ veya CISA KEV listesinde. -> **48 Saat ile 7 Gün içinde** yamalanmalı.
- **Yüksek (Turuncu):** CVSS 7.0 - 8.9. -> **14 ile 30 Gün içinde** yamalanmalı.
- **Orta (Sarı):** CVSS 4.0 - 6.9. -> **30 ile 90 Gün içinde** yamalanmalı.
- **Düşük (Yeşil):** CVSS 0.1 - 3.9. -> **90+ Gün** (Genellikle Risk Kabulü yapılarak izlenir).

Zafiyet Yönetimi Neden Başarısız Olur?

- **BT ve Güvenlik Çatışması:** Güvenlik ekibi sadece tarama yapıp yüzlerce sayfa PDF'i BT'ye "Hepsini düzeltin" diye atarsa, BT ekibi (sistemi ayakta tutma telaşıyla) bu raporları görmezden gelir. (Silo problemi).
- **Düzensiz Yama Yönetimi:** Şirketlerin bir patch (yama) test ortamı yoksa, yüklenen güvenlik yamaları mevcut iş yazılımlarını bozabilir. Bu korku, sistemlerin bilerek yamasız bırakılmasına yol açar.
- **Tedarikçi Ağını Unutmak:** Kendi sunucularınız kusursuz taranırken, web sitenizdeki bir reklam scriptinin veya e-ticaret sitenizdeki ödeme eklentisinin zafiyet taşıması.

Regülasyonların Bakış Açısı

CRA (Cyber Resilience Act) veya Türkiye 7545 sayılı Kanun denetçileri; "Hiç zafiyetiniz yok mu?" diye sormaz, çünkü bunun imkansız olduğunu bilirler. Denetçinin sorduğu şudur: "Yeni çıkan kritik bir zafiyeti (Örn. Log4j) kendi sistemlerinizde bulup yamalamanız ortalama kaç gün sürüyor? Bu süreci kanıtlayan log kayıtlarınız (Technical Evidence) nerede?"

TEVSİK'in Varlık ve Kanıt Yönetimi Yaklaşımı

Zafiyet yönetimi sadece bir güvenlik aracı satın almak değil, bir operasyon ve kültür inşasıdır. TEVSİK, Güven Masası hizmetleri ve Teknik Kanıt Yönetimi (TEM) altyapısı ile, siber güvenlik politikalarınızı, yama SLA'lerinizi ve SBOM bazlı varlık tespit süreçlerinizi bir araya getirir. Amacımız, olası bir resmi denetimde zafiyet yönetim döngünüzün işletildiğini saniye saniye doğrulayabilecek yapılandırılmış kanıt havuzunu kurmaktır.

Hizmet Sınırı

Bu içerik genel teknik bilgilendirme amacı taşır; hukuk görüşü, resmî uygunluk değerlendirmesi veya doğrudan uygulamalı sızma testi (pentest) hizmeti değildir. TEVSİK; teknik envanter, süreç, veri, kanıt ve hazırlık yapılanması sunar.