Zafiyet Yönetimine Başlangıç

Kısaca

• Veriyi tekilleştir, gerçeği tek kaynağa indir (single source of truth).
• Risk tabanlı önceliklendir, SLA tanımla ve net sorumluluk ata.
• Otomatik retest ile kapanışı doğrula; denetime hazır kanıt üret.

Neden Zafiyet Yönetimi?

Dağınık araçlar ve tekrar eden kayıtlar, ekiplerin gerçek riske odaklanmasını zorlaştırır. SİTEY, 17 aracı tek panelde birleştirir; yapay zeka destekli veri standardizasyonu ile gürültüyü azaltır, SLA takibi ve yeniden test ile kapanış hızını artırır.

Adım 1 - Keşif

• ASM ile dışa açık varlık haritalama
• Nessus, OpenVAS, Nuclei, ZAP ve benzeri tarama sonuçlarının konsolidasyonu
• Otomatik envanter eşleşmesi ve kapsam yönetimi

Adım 2 - Doğrulama

Tekrarlayan ve yanlış pozitif kayıtlar tekilleştirilir; PoC ve kanıtlar ilişkilendirilir. Böylece analist zamanı verimli kullanılır.

• Aynı kök sebebe ait bulguları parmak izi (fingerprint) ile birleştirme
• Varlık kritiklik seviyesi ile bağlamlandırma (internet-facing, crown-jewel)
• İş birimleriyle yorum akışı: yanlış pozitif reddi, açıklama ve kanıt

Adım 3 - Önceliklendirme

CVSS + varlık önemi + sömürülebilirlik bileşenleri ile risk tabanlı puanlama. Kritikler için hedef < 72 saat.

• Exploit mevcudiyeti ve internet maruziyeti ile artan risk
• Otomatik etiket kümeleri: RCE, Auth Bypass, Data Exposure vb.
• Çakışan işler için planlama: bakım pencereleri, versiyon yükseltme

Adım 4 - Atama ve Düzeltme

RBAC ile doğru kişiye net sorumluluk. Otomasyon ve hazır şablonlarla düzeltme süreci hızlanır.

• Otomatik ticket entegrasyonları (Jira, GitLab, ServiceNow)
• Kapatma kanıtı zorunluluğu ve değişiklik günlüğü
• SLA ihlalinde otomatik eskalasyon

Adım 5 - Yeniden Test

Planlı/otomatik retest ile kapanış doğrulaması ve doğrulama mektubu üretimi.

• Değişiklikten sonra otomatik tetikleme
• Başarısız retest’te yeniden açma ve sorumluya atama
• Uyum denetimleri için kanıt arşivi

Otomasyon Örnekleri

• Nuclei haftalık tarama → bulguların SİTEY’de otomatik açılması
• Yeni internet-facing varlık bulunduğunda ASM → ZY pipeline tetikleme
• CVSS 9+ ve exploit bulunan kayıtlar için anında uyarı

İzlenecek KPI’lar

• MTTR (kritik/yüksek) ve SLA uyum oranı
• Yanlış pozitif oranı ve tekilleştirme başarısı
• Retest başarı oranı ve kapanış doğruluğu

Zafiyet Yönetimi Araçları ve Teknolojileri

Etkili bir zafiyet yönetimi programı, birden fazla tarama aracının çıktısını birleştirerek kapsamlı bir görünürlük sağlar. Tek araçla yetinmek kör noktalar bırakırken, çok fazla aracı koordinesiz kullanmak da gürültü üretir. Doğru strateji; farklı araç türlerini tamamlayıcı bir mimari içinde konumlandırmaktır.

Nessus, kurumsal ortamlarda en yaygın kullanılan ticari güvenlik açığı tarayıcılarından biridir. Geniş eklenti kütüphanesi sayesinde işletim sistemi, ağ cihazı ve uygulama katmanında binlerce güvenlik açığı tespit eder. Kimlik tabanlı (credentialed) taramalarla yama eksiklerini, yapılandırma hatalarını ve politika ihlallerini ortaya çıkarır. OpenVAS ise açık kaynak alternatif olarak benzer yetkinliği sunar; topluluk destekli imza tabanı sürekli güncellenir ve maliyet hassasiyeti olan ekipler için güçlü bir seçenektir.

Nuclei, YAML tabanlı şablon yapısıyla hızla özelleştirilip CI/CD pipeline'larına entegre edilebilir. Özellikle web uygulama ve API taramalarında sızma testi ekiplerinin favori aracıdır. Qualys ise bulut tabanlı mimarisiyle agent'lı ve agent'sız tarama seçenekleri sunar; büyük ölçekli varlık envanterleri için idealdir.

SİTEY platformu bu araçların çıktılarını tek veri modeline dönüştürür. Alan eşleme sihirbazı sayesinde farklı formatları standartlaştırır, tekilleştirme motoru ile mükerrer bulguları birleştirir ve risk puanını iş bağlamı ile zenginleştirir. Böylece siber güvenlik ekipleri araçlar arasında kaybolmak yerine doğrudan aksiyona odaklanır.

• Ağ katmanı: Nessus, OpenVAS, Qualys - işletim sistemi ve ağ cihazı zafiyetleri
• Web & API: Nuclei, ZAP, Burp Suite - uygulama seviyesi güvenlik açığı taraması
• Konteyner & IaC: Trivy, Checkov - imaj ve altyapı kodu taraması
• Bulut: AWS Inspector, Azure Defender, GCP SCC - bulut yapılandırma kontrolleri
• Konsolidasyon: SİTEY - tüm çıktıları standartlaştırma, tekilleştirme ve önceliklendirme

Zafiyet Veri Modeli ve Standardizasyon

Farklı tarama araçları farklı formatlarda çıktı üretir: JSON, XML, CSV, PDF. Bu çeşitlilik ortak bir dilde konuşmayı zorlaştırır. Zafiyet yönetimi sürecinin temel taşı, tüm verilerin tek bir veri modeline standartlaştırılmasıdır.

CVE (Common Vulnerabilities and Exposures), her güvenlik açığına benzersiz bir kimlik numarası atar. CWE (Common Weakness Enumeration) ise açığın kök sebebini sınıflandırır; örneğin CWE-89 SQL Injection'ı, CWE-79 XSS'i temsil eder. CPE (Common Platform Enumeration), etkilenen ürün ve sürümü standart isimlendirir. Bu üçlü birlikte kullanıldığında "hangi ürünün hangi zayıflığı, hangi açık kimliğiyle biliniyor?" sorusu netleşir.

NVD (National Vulnerability Database), NIST tarafından yönetilen ve CVE kayıtlarını CVSS puanlarıyla zenginleştiren resmi veri tabanıdır. Siber güvenlik ekipleri NVD verisini günlük olarak çekerek yeni yayınlanan güvenlik açıklarını varlık envanterleriyle otomatik eşleştirebilir.

SİTEY'in veri standardizasyon motoru; CVE, CWE ve CPE ilişkilerini otomatik olarak kurar, farklı kaynaklardan gelen aynı bulguyu parmak izi (fingerprint) algoritmasıyla eşleştirir ve tek bir kayıt altında birleştirir. Bu sayede analistler aynı güvenlik açığı için birden fazla ticket açmak yerine bağlamı zengin tek bir kayıt üzerinden çalışır.

• CVE: Açığın dünya genelinde kabul görmüş benzersiz kimliği
• CWE: Yazılım zayıflığının kategorisi ve kök sebep sınıflandırması
• CPE: Etkilenen ürün, sürüm ve platform bilgisi
• NVD: CVSS puanları, etki analizi ve referans bağlantıları
• EPSS: Sömürü olasılığı tahmini - gerçek dünyada exploit edilme ihtimali

Risk Tabanlı Önceliklendirme Detayları

Binlerce güvenlik açığı arasından hangisine önce müdahale edileceğini belirlemek, zafiyet yönetimi programının en kritik noktasıdır. Salt CVSS puanına güvenmek yanıltıcı olabilir; bağlamdan yoksun bir 9.8 puanlı açık, izole bir test sunucusundaysa gerçek riski düşüktür.

CVSS v3.1, üç metrik grubundan oluşur: Base (değişmez teknik özellikler), Temporal (exploit olgunluğu, yama durumu) ve Environmental (kurumunuza özgü etki). CVSS v4.0 ise Supplemental metrikleri ekleyerek otomasyona uygunluk, kurtarılabilirlik ve saldırı karmaşıklığına daha ince ayrıntılar katar. Her iki sürüm de tek başına yeterli olmayıp iş bağlamıyla zenginleştirilmelidir.

EPSS (Exploit Prediction Scoring System), makine öğrenmesi ile bir güvenlik açığının 30 gün içinde gerçek dünyada sömürülme olasılığını tahmin eder. CVSS 7.0 olan ama EPSS %85 olan bir bulgu, CVSS 9.8 ama EPSS %2 olan bir bulgudan çok daha acildir. SSVC (Stakeholder-Specific Vulnerability Categorization) ise karar ağacı yaklaşımıyla "hemen düzelt / planla / izle / kabul et" aksiyonlarından birini önerir.

Exploit maturity bilgisi de kritik bir girdidir: Kavram kanıtı (PoC) mevcut mu, aktif olarak kullanılıyor mu, yoksa yalnızca teorik mi? Bu bilgi Exploit-DB, GitHub PoC veritabanları ve tehdit istihbarat beslemeleri ile güncellenir. SİTEY, CVSS + EPSS + varlık kritikliği + exploit maturity bileşenlerini entegre ederek risk tabanlı bir nihai skor üretir ve sızma testi bulgularını da aynı çerçeveye oturtur.

• CVSS Base: Saldırı vektörü, karmaşıklık, ayrıcalık gereksinimi, etki
• CVSS Temporal: Exploit kodu olgunluğu, resmi yama durumu, raporun güvenilirliği
• EPSS: 30 günlük sömürü olasılığı tahmini (0–1 arası)
• SSVC: Paydaşa özgü karar ağacı - aksiyon odaklı kategorilendirme
• Asset Context: Varlık internet'e açık mı, crown-jewel mı, PII barındırıyor mu

SLA Tanımlama ve Takibi

SLA (Hizmet Düzeyi Anlaşması), güvenlik açıklarının ne kadar süre içinde kapatılması gerektiğini ölçülebilir biçimde tanımlar. Net SLA'lar olmadan düzeltme süreleri uzar, sorumluluklar belirsizleşir ve denetim hazırlığı zorlaşır.

Tipik bir zafiyet yönetimi SLA matrisi aşağıdaki gibi yapılandırılabilir: Kritik bulgular için 72 saat, Yüksek için 7 gün, Orta için 30 gün, Düşük için 90 gün. Bu süreler kurumun risk iştahına, ekip kapasitesine ve düzenleyici gereksinimlere göre özelleştirilmelidir.

Eskalasyon kuralları SLA'ların bel kemiğidir. SLA süresinin %75'ine ulaşıldığında otomatik uyarı gönderilmeli, %100'e ulaşıldığında yöneticiye eskalasyon yapılmalı ve aşımda kök sebep analizi zorunlu olmalıdır. SİTEY'in otomasyon motoru bu kuralları webhook ve e-posta ile tetikler.

Siber güvenlik ekiplerinin en sık karşılaştığı sorun, SLA ihlallerine rağmen aksiyon alınmamasıdır. Bu nedenle SLA breach dashboard'u ayrı bir görünüm olarak yapılandırılmalı, ihlal eden bulguların sahibi, yaşı ve ihlal süresi açıkça görünmelidir. Periyodik SLA uyum toplantıları da süreci canlı tutar.

• Kritik: Maks. 72 saat - internet-facing RCE, aktif exploit
• Yüksek: Maks. 7 gün - kimlik doğrulama bypass, veri sızıntısı
• Orta: Maks. 30 gün - bilgi ifşası, yapılandırma hataları
• Düşük: Maks. 90 gün - teorik risk, düşük etkili bilgi toplama
• Eskalasyon: %75 otomatik uyarı → %100 yönetici bildirimi → aşımda kök sebep zorunluluğu

Entegrasyon ve Otomasyon

Modern zafiyet yönetimi, izole çalışan araçlarla değil entegre bir ekosistemle başarılı olur. Tarama sonuçlarının otomatik olarak iş takip sistemine aktarılması, düzeltme sonrası otomatik retest tetiklenmesi ve CI/CD pipeline'larına güvenlik kapılarının eklenmesi, sürecin hızını ve güvenilirliğini katlayarak artırır.

Webhook entegrasyonları, olay odaklı bir mimari kurmanın en hızlı yoludur. Yeni bir kritik bulgu tespit edildiğinde SİTEY webhook ile Slack/Teams kanalına anlık bildirim gönderir, Jira'da otomatik ticket açar ve OpsGenie/PagerDuty üzerinden nöbetçiyi uyarır. Bu sayede güvenlik açığı tespit ile müdahale arasındaki gecikme dakikalara iner.

API tabanlı entegrasyon daha derin kontrol sağlar. SİTEY REST API'si ile bulgu oluşturma, güncelleme, durum değiştirme ve toplu raporlama işlemleri programatik olarak yapılabilir. Jira ve ServiceNow çift yönlü senkronizasyonu sayesinde ticket durumu değiştiğinde bulgu durumu da otomatik güncellenir. GitLab ve GitHub entegrasyonlarıyla güvenlik bulgularını doğrudan geliştirici iş akışına taşımak mümkündür.

CI/CD pipeline hooks, DevSecOps yaklaşımının temel bileşenidir. Build aşamasında SAST/SCA taraması, deploy öncesi DAST kontrolü ve release kapısında sızma testi bulgularının durumu kontrol edilerek güvenli olmayan kodun üretime çıkması engellenir. SİTEY CLI aracı, Jenkins/GitLab CI/GitHub Actions pipeline'larına kolayca eklenir.

• Jira/ServiceNow: Çift yönlü ticket senkronizasyonu ve SLA takibi
• Slack/Teams: Anlık bildirimler, özet raporlar ve komut tabanlı sorgulama
• GitLab/GitHub: Issue açma, PR güvenlik kontrolü ve merge gate
• CI/CD: Build/deploy kapısı, güvenlik eşik kontrolü ve otomatik retest
• SIEM/SOAR: Korelasyon verisi gönderme ve otomatik müdahale tetikleme

Raporlama ve Yönetici Görünürlüğü

Etkili zafiyet yönetimi raporlaması, teknik detayı karar vericiler için anlamlı bilgiye dönüştürür. Yöneticiler CVE numaralarını değil, iş etkisini ve risk trendini görmek ister. Bu nedenle raporlama iki katmanlı kurgulanmalıdır.

Yönetici dashboard'u (executive view), üst düzey metrikleri özetler: toplam açık bulgu sayısı ve trendi, SLA uyum oranı, ortalama kapanış süresi (MTTR), risk skoru dağılımı ve en riskli 5 varlık. Tüm bu veriler tek bakışta anlaşılabilecek grafiklerle sunulmalıdır. Aylık veya haftalık siber güvenlik brifingleri için otomatik PDF/PPT raporu üretimi de zaman kazandırır.

Trend analizi, programın olgunluğunu ölçmenin en güçlü aracıdır. Çeyreklik MTTR değişimi, açık bulgu yaş dağılımı, yeni/kapatılan bulgu oranı ve tekrar açılan bulgu trendi izlenmelidir. Düşen MTTR ve yükselen SLA uyum oranı, programın sağlıklı ilerlediğini gösterir.

Uyum raporlaması ise düzenleyici gereksinimler için kritiktir. ISO 27001, PCI-DSS, KVKK ve BDDK gibi standartların gerektirdiği kanıtlar - tarama tarihleri, düzeltme süreleri, retest sonuçları - SİTEY üzerinden denetime hazır formatlarda dışa aktarılabilir. Sızma testi raporlarının bulgu durumlarıyla eşleştirilmesi de denetim hazırlığını güçlendirir.

• Executive Dashboard: Risk trendi, SLA uyumu, MTTR, en riskli varlıklar
• Operasyonel Panel: Açık bulgu yaşı, atanmamış bulgular, darboğaz analizi
• Uyum Raporları: ISO 27001, PCI-DSS, KVKK kanıt paketleri
• Trend Analizi: Çeyreklik karşılaştırma, improvement velocity, regresyon oranı
• Otomatik Dağıtım: Haftalık/aylık PDF, Slack/e-posta ile zamanlı gönderim

Zafiyet Yönetimi Ekip Yapısı

Başarılı bir zafiyet yönetimi programı, net rol tanımları ve sorumluluk matrisine dayanır. Kimin tarama yapacağı, kimin doğrulayacağı, kimin düzelteceği ve kimin kabul edeceği önceden belirlenmelidir. Aksi takdirde bulgular sahipsiz kalır ve SLA'lar ihlal edilir.

ZY Analisti, günlük tarama çıktılarını inceler, yanlış pozitif ayrımını yapar, bulguları doğrulayıp kategorize eder ve ilgili ekiplere atar. Güvenlik Mühendisi, karmaşık bulguları derinlemesine analiz eder, sızma testi sonuçlarını yorumlar, remediation önerileri üretir ve retest sürecini yönetir. CISO / Güvenlik Yöneticisi ise programın stratejik yönünü belirler, KPI'ları izler, bütçe ve kaynak tahsisi yapar.

RACI matrisi, her süreç adımında kimin Responsible (Sorumlu), Accountable (Hesap Verebilir), Consulted (Danışılan) ve Informed (Bilgilendirilen) olduğunu açıkça tanımlar. Örneğin keşif adımında ZY Analisti sorumlu, Güvenlik Mühendisi danışılandır; düzeltme adımında ise ilgili sistem yöneticisi/geliştirici sorumlu, ZY Analisti doğrulayandır.

Küçük ekiplerde roller birleşebilir ancak görevler ayrılığı (segregation of duties) ilkesi korunmalıdır: taramayı yapan kişi düzeltmeyi doğrulamamalı, düzeltmeyi yapan kişi kapanışı onaylamamalıdır. SİTEY'in RBAC (Rol Tabanlı Erişim Kontrolü) yapısı bu ayrımı platform seviyesinde zorunlu kılar.

• ZY Analisti: Tarama, tekilleştirme, doğrulama, atama, raporlama
• Güvenlik Mühendisi: Derinlemesine analiz, PoC geliştirme, remediation rehberliği
• Sistem/Uygulama Yöneticisi: Yama uygulama, yapılandırma düzeltme, değişiklik kaydı
• CISO: Strateji, KPI izleme, bütçe, yönetim kurulu raporlaması
• DevOps/Geliştirici: Kod düzeltme, güvenli kodlama, pipeline entegrasyonu

Başarılı Bir Zafiyet Yönetimi Programı İçin İpuçları

Mükemmel bir zafiyet yönetimi programı bir gecede kurulmaz. Ancak doğru adımlarla hızlı kazanımlar elde etmek ve programı iteratif olarak olgunlaştırmak mümkündür. Aşağıdaki pratik ipuçları, hem yeni başlayanlar hem de programını güçlendirmek isteyenler için rehber niteliğindedir.

Hızlı kazanımlar (quick wins) ile başlayın: İlk hafta mevcut tarama araçlarını SİTEY'e entegre edin ve tekilleştirmeyi çalıştırın - gürültünün ne kadar azaldığını görünce ekip motivasyonu artar. İkinci hafta SLA'ları tanımlayın ve ilk dashboard'u yayınlayın. Üçüncü hafta otomatik ticket entegrasyonunu açın. Bu üç adım bile siber güvenlik olgunluğunuzu önemli ölçüde artırır.

Değişiklik yönetimi (change management) göz ardı edilmemelidir. Yeni süreçler ekiplerin iş yapış biçimini değiştirir; dirençle karşılaşmak normaldir. Geliştirici ekiplerle empati kurarak güvenlik bulgularını "suçlama aracı" değil "kalite geliştirme fırsatı" olarak konumlandırın. Ortak retrospektifler ve başarı hikayelerinin paylaşımı kültürel dönüşümü hızlandırır.

Geliştirici ekiplerle iletişim, programın sürdürülebilirliğinin anahtarıdır. Bulguları geliştiricinin anlayacağı dilde yazın: CVE numarası yanında etkilenen kod satırını, reprodüksiyon adımlarını ve önerilen düzeltmeyi ekleyin. Otomatik remediation rehberleri ve güvenli kodlama örnekleri, düzeltme süresini kayda değer biçimde kısaltır.

Son olarak, sürekli iyileştirme döngüsü kurun. Her çeyrekte KPI'ları gözden geçirin, SLA'ları gerçekleşen verilere göre kalibre edin, araç entegrasyonlarını genişletin ve yeni tehdit vektörlerini kapsama ekleyin. Zafiyet yönetimi bir proje değil sürekli bir süreçtir; başarısı ölçülen ve iyileştirilen adımlarla büyür.

1. Küçük başlayın, hızlı büyütün: İlk fazda en kritik 3 aracı entegre edin
2. Veriyi standartlaştırın: Tekilleştirme ve normalizasyon ilk günden aktif olsun
3. SLA'ları tanımlayın ve uygulayın: Kağıt üstünde kalan SLA işe yaramaz
4. Otomasyon kademeli ekleyin: Ticket, bildirim, retest sırasıyla otomatikleştirin
5. İletişimi güçlendirin: Haftalık kısa güvenlik brifingi ve aylık trend raporu paylaşın
6. Olgunluğu ölçün: Her çeyrekte KPI'ları gözden geçirin ve hedefleri yükseltin

SSS

Zafiyet Yönetimi Olgunluk Seviyeleri

Bir zafiyet yönetimi programının nerede olduğunu ve nereye gittiğini anlamak için olgunluk modeli kullanmak faydalıdır. Olgunluk seviyesi arttıkça süreçler daha otomatik, tutarlı ve ölçülebilir hale gelir.

Seviye 1 - Reaktif: Taramalar düzensiz yapılır, bulgular manuel olarak takip edilir, SLA yoktur. Güvenlik açığı kapanış süreci bireylere bağımlıdır ve tekrarlanabilirlik düşüktür. Çoğu kuruluş bu seviyede başlar.

Seviye 2 - Tanımlı: Tarama takvimi belirlenmiştir, SLA'lar tanımlı ama uygulama düzensizdir. Tekilleştirme kısmi yapılır, raporlama periyodik ama manueldir. Sızma testi sonuçları ayrı dosyalarda takip edilir.

Seviye 3 - Yönetilen: SLA'lar aktif uygulanır, otomatik eskalasyon çalışır, dashboard'lar mevcuttur. Çoklu araç entegrasyonu sağlanmış, tekilleştirme ve önceliklendirme otomatikleşmiştir. SİTEY bu seviyede tam potansiyelini gösterir.

Seviye 4 - Optimize Edilen: KPI'lar düzenli kalibre edilir, trend analizi karar vermeye rehberlik eder, DevSecOps entegrasyonu tamamdır. Siber güvenlik programı sürekli iyileştirme döngüsündedir ve sektör benchmark'larının üzerinde performans gösterir.

• Seviye 1: Reaktif - düzensiz tarama, manuel takip, SLA yok
• Seviye 2: Tanımlı - takvim var, kısmi tekilleştirme, düzensiz SLA
• Seviye 3: Yönetilen - SLA aktif, otomasyon çalışıyor, dashboard mevcut
• Seviye 4: Optimize - sürekli iyileştirme, benchmark üzerinde, DevSecOps entegre

Kullanım Senaryoları

• Merkezi ZY Ofisi: Farklı kaynaklardan gelen bulguları tek panelde birleştirip ekipler arası atama.
• Ürün Güvenliği: Uygulama ekipleriyle ortak retest ve değişiklik kaydı entegrasyonu.
• Uyum ve Denetim: Kanıt saklama, kapanış doğruluğu ve denetime hazır raporlama.

Sık Yapılan Hatalar

• Tek araç bağımlılığı: Farklı kaynakları konsolide etmeden karar vermek.
• Bağlam yokluğu: Varlık kritiklik/ maruziyet bilgisini skora katmamak.
• Retest atlanması: Kapanışı doğrulamadan kapatma ve tekrar eden açıklar.

Örnek İş Akışı

1. Tarama raporları içe aktarılır ve tekilleştirilir.
2. Varlık envanteriyle eşleşir, bağlam ve kritiklik eklenir.
3. Risk skoru hesaplanır ve otomatik atama yapılır.
4. Düzeltme tamamlanınca otomatik retest tetiklenir.
5. Kapanış kanıtı saklanır; rapor ve KPI’lar güncellenir.