İstisna Yönetimi ve Geçici Risk Kabulü

Kısaca

• İstisna, riski kalıcılaştırmak değildir; süreli ve koşullu bir karardır.
• Kompansatuar kontroller ile risk etkisi düşürülmelidir.

Özet Anlatım

İstisna yönetimi, gerçek hayatta bazen yamaların veya mimari değişikliklerin hemen yapılamadığı durumlarda riski geçici olarak kabul edip kontrol altında tutma yöntemidir. Başarılı bir süreç; net bitiş tarihleri, sorumlular ve tamamlayıcı kontrollerle ölçülür.

Politika ve Onay Akışı

• İş gerekçesi, kapsam, süre ve sonlandırma planı zorunlu alanlar
• Rol bazlı onay ve bilgilendirme

İzleme ve Denetim

• Yaklaşan bitişler için hatırlatmalar ve otomatik kapama
• Denetim için tam değişiklik/karar izi

Pratik Rehber

Kullanım senaryoları:

• Eski sistemlerde geçici risk kabulü ile planlı iyileştirme
• Ürün çıkış tarihine yetişmeyen yamalar için istisna
• Üçüncü taraf bağımlılıklarında tedarikçi bekleme süreci

Sık yapılan hatalar:

• Belirsiz bitiş tarihi ve sorumlu tayin etmemek
• Kompansatuar kontrolleri dokümante etmemek
• İstisnaları düzenli gözden geçirmemek

Adım adım (onay akışı):

1. İş gerekçesi ve kapsamı kaydet
2. Risk analizi ve kompansatuar kontrolleri belirle
3. Rol bazlı onay → bildirim → gözden geçirme döngüsü

İstisna Türleri ve Kategorileri

Zafiyet yönetimi sürecinde her istisna aynı değildir. Farklı türler farklı iş akışları, onay seviyeleri ve takip mekanizmaları gerektirir. İstisnaları doğru kategorize etmek, siber güvenlik ekiplerinin riskleri doğru yönetmesini sağlar.

• Yanlış Pozitif (False Positive): Tarayıcının hatalı olarak raporladığı bulgular. Doğrulama sonrası kalıcı olarak bastırılır. Gerekçe ve doğrulama kanıtı belgelenmeli, tarayıcı kuralına geri bildirim yapılmalıdır.
• Kabul Edilen Risk (Accepted Risk): Gerçek bir güvenlik açığı mevcut ancak iş, teknik veya maliyet sebepleriyle düzeltme yapılamıyor. En ciddi istisna türüdür; resmi onay, kompansatuar kontrol ve süre sınırı gerektirir.
• Kompansatuar Kontrol: Asıl zafiyet giderilemese de ek güvenlik önlemleri ile riskin etkisi kabul edilebilir seviyeye indirilir. WAF kuralı, ağ segmentasyonu, ek izleme gibi önlemler bunu sağlar.
• Ertelenmiş Düzeltme (Deferred Fix): Düzeltme planlanmıştır ancak belirli bir bütçe, pencereye veya değişiklik döngüsüne bağlıdır. SLA uzatımı olarak işlenir, net bir hedef tarih zorunludur.
• Operasyonel Kısıt: Varlığın doğası gereği (OT/SCADA, legacy ERP) yama uygulanamaz. Uzun vadeli decommissioning veya modernizasyon planı gerektirir.

Her istisna türü için ayrı onay şablonu, süre politikası ve gözden geçirme sıklığı tanımlayın. Kategorizasyonu standartlaştırmak, raporlama ve denetim süreçlerini önemli ölçüde kolaylaştırır.

Risk Kabul Süreci

Risk kabulü, zafiyet yönetimi programının en hassas karar mekanizmasıdır. Yapılandırılmış bir süreç olmadan risk kabulleri kontrol dışına çıkar.

Resmi onay iş akışı:

1. Talep açma: Talep eden kişi iş gerekçesini, etkilenen varlıkları, güvenlik açığı detayını ve önerilen kompansatuar kontrolleri standart bir formda doldurur.
2. Güvenlik değerlendirmesi: Siber güvenlik ekibi riskin gerçek etkisini analiz eder, exploit olasılığını ve olası hasar senaryolarını değerlendirir.
3. Kademeli onay: Risk seviyesine göre onay yetkisi yükselir. Düşük risk: Takım lideri. Orta risk: Güvenlik müdürü. Yüksek/Kritik risk: CISO veya Risk Komitesi.
4. Dokümantasyon: Onaylanan risk kabullerinin tüm detayları (gerekçe, onaylayan, tarih, süre, koşullar) değiştirilemez formatta arşivlenir.
5. Bilgilendirme: İlgili paydaşlar (varlık sahibi, operasyon ekibi, denetçiler) karardan haberdar edilir.

Performans kriteri: Risk kabul sürecinin ortalama tamamlanma süresi 5 iş gününü aşmamalıdır. Uzayan süreçler, riskin kontrol dışı kaldığı anlık maruziyeti artırır.

Kompansatuar Kontroller

Kök neden düzeltmesi yapılamadığında, kompansatuar kontroller riski kabul edilebilir seviyeye indirmek için uygulanan alternatif önlemlerdir. PCI DSS, ISO 27001 ve NIST gibi çerçeveler, kompansatuar kontrolleri resmi olarak tanır.

• Ağ segmentasyonu: Zafiyetli varlığı daha kısıtlı bir ağ segmentine taşıyarak saldırı yüzeyini daraltın. Mikro-segmentasyon ile yanal hareket riskini minimize edin.
• WAF / IPS kuralları: Bilinen exploit vektörlerini engelleyen özel kurallar yazın. Virtual patching olarak da bilinir; özellikle web uygulamalarındaki güvenlik açığı için etkilidir.
• Geliştirilmiş izleme: Zafiyetli varlık üzerindeki aktiviteyi artmış log seviyesiyle izleyin. SIEM korelasyon kuralları ile şüpheli erişim paternlerini gerçek zamanlı uyarıya dönüştürün.
• Erişim kısıtlaması: Zafiyetli servise erişimi minimum gerekli kişi/sistem ile sınırlayın. IP whitelist, MFA zorunluluğu veya VPN gerekliliği gibi ek katmanlar ekleyin.
• Geçici workaround'lar: Zafiyetli özelliği devre dışı bırakma, port kapatma veya servis kısıtlama gibi hızlı önlemler. İş etkisi analiz edilmeli ve dokümante edilmelidir.

Her kompansatuar kontrolün etkinliği düzenli test edilmelidir. Kontrolün kaçırılabilirliğini doğrulamak için hedefli sızma testi planlayın.

İstisna Süre ve Koşul Yönetimi

Açık uçlu istisnalar, zafiyet yönetimi programının en büyük düşmanıdır. Her istisnanın net bir bitiş tarihi ve devam koşulları olmalıdır.

• Süre politikaları: Risk seviyesine göre maksimum istisna süresi belirleyin. Örneğin: kritik - 30 gün, yüksek - 60 gün, orta - 90 gün, düşük - 180 gün. Uzatma için yeniden onay gerekmelidir.
• Otomatik hatırlatma: Bitiş tarihinden 30, 14 ve 7 gün önce ilgili paydaşlara otomatik bildirim gönderin. Bitiş gününde eğer uzatma onayı yoksa istisna otomatik sonlandırılsın ve bulgu yeniden aktif duruma geçsin.
• Yeniden değerlendirme döngüsü: Her yenileme talebinde güncel risk analizi yapılmalıdır. Tehdit ortamı değişmişse (yeni exploit yayınlanmışsa, saldırı yüzeyi genişlemişse) istisna koşulları güncellenmelidir.
• Koşullu devam: Bazı istisnalar süreye değil koşula bağlıdır: "Üretici yaması çıkınca", "yeni sistem devreye alınınca", "bütçe onaylandığında". Bu koşulların gerçekleşip gerçekleşmediği otomatik izlenmelidir.

SİTEY platformu, istisna süre ve koşul takibini otomatikleştirerek "unutulan istisna" riskini ortadan kaldırır.

Denetim ve Uyumluluk

İstisna yönetimi, siber güvenlik denetimlerinin en yakından incelediği alanlardan biridir. Denetçiler, organizasyonun riskleri bilinçli ve kontrollü bir şekilde yönetip yönetmediğini istisnalar üzerinden değerlendirir.

• Denetçi beklentileri: Resmi politika, tanımlı onay mekanizması, karar geçmişi, kompansatuar kontrol kanıtları ve düzenli gözden geçirme kayıtları. Bunlardan herhangi birinin eksikliği denetim bulgusu olarak raporlanır.
• Kanıt saklama: Tüm istisna kararları, onay e-postaları/imzaları, risk analiz dokümanları ve kompansatuar kontrol test sonuçları en az 3 yıl (sektöre göre 5-7 yıl) saklanmalıdır. Değiştirilemez (immutable) arşiv kullanın.
• Uyumluluk çerçeveleri: ISO 27001 (A.12.6 Teknik Zafiyet Yönetimi), PCI DSS (Req 6.1 ve 11.2), NIST CSF (ID.RA, RS.MI) ve KVKK gereksinimleri istisna sürecinin yapılandırılmasını zorunlu kılar.
• Sürekli denetim hazırlığı: Yıllık denetime hazırlık yerine, sürekli uyumluluk yaklaşımı benimseyin. Dashboard'lardan anlık olarak açık istisna sayısı, süresi dolmuş istisnalar ve risk maruziyeti görüntülenebilmelidir.

İstisna sürecinin olgunluğu, organizasyonun genel zafiyet yönetimi olgunluk seviyesinin doğrudan göstergesidir. Denetim bulgularında en sık karşılaşılan sorun: süreli olması gereken istisnanın fiilen kalıcılaşmasıdır.

İstisna Metrikleri

İstisna sürecinin sağlığını ölçmek için düzenli metrik takibi yapılmalıdır. Ölçülmeyen istisna süreci zamanla kontrol dışına çıkar.

• Toplam açık istisna sayısı: Aktif istisnaların tür, risk seviyesi ve departman bazında dağılımı. Artma trendi kontrol zayıflığına işaret eder.
• Ortalama istisna yaşı: Açık istisnaların ortalama gün sayısı. Uzayan yaş, "geçici" kabullerin kalıcılaştığını gösterir. Hedef: kritik istisnalarda 45 günün altında.
• Risk maruziyet skorları: Kabul edilen risklerin toplamının risk skoru cinsinden ifadesi. Bu puan yönetim kuruluna raporlanmalı ve zaman içindeki trendi izlenmelidir.
• Süre aşımı oranı: Bitiş tarihini geçen istisnaların oranı. %5'in üzerindeyse süreç disiplini zayıflamaya başlamış demektir. Sıfır hedeflenmelidir.
• İstisna-düzeltme dönüşüm oranı: Sonlandırılan istisnaların yüzde kaçı düzeltme ile, yüzde kaçı yenileme ile, yüzde kaçı varlık decommissioning ile kapanıyor? Sağlıklı bir süreçte düzeltme oranı yüksek olmalıdır.
• Trend analizi: Aylık/çeyreklik bazda tüm metriklerin trendi izlenmelidir. Artan risk maruziyeti veya şişen istisna sayısı, yönetim müdahalesi gerektiren erken uyarı sinyalleridir.

Bu metrikleri aylık olarak CISO'ya ve çeyreklik olarak risk komitesine raporlayın. Sızma testi sonuçlarıyla çapraz kontrol yaparak istisna kararının isabetliliğini değerlendirin.

SİTEY ile İstisna İş Akışı

SİTEY platformu, istisna yönetimini uçtan uca otomatikleştiren yapılandırılmış bir iş akışı sunar:

• Tek tıkla istisna talebi: Bulgu detay sayfasından doğrudan istisna talep formu açılır. İş gerekçesi, süre, kompansatuar kontrol ve risk seviyesi alanları zorunlu olarak doldurulur.
• Otomatik onay zinciri: Risk seviyesine göre ilgili onaycılar otomatik atanır. Onaycılar e-posta ve platform içi bildirimle uyarılır. Bekleme süresi aşılırsa otomatik eskalasyon devreye girer.
• Süre ve koşul motoru: Bitiş tarihleri ve koşullu tetikleyiciler otomatik izlenir. Yaklaşan bitişler için kademeli hatırlatma; süresi dolmuş istisnalar otomatik olarak aktif bulgu durumuna döndürülür.
• Dashboard ve raporlama: Tüm aktif, süresi dolmuş ve kapanmış istisnalar tek panelde görüntülenir. Risk maruziyet trendi, departman bazında dağılım ve SLA uyum grafikleri anlık güncellenir.
• Denetim izi: Her işlem (talep, onay, red, yenileme, kapanma) zaman damgası, kullanıcı ve gerekçe ile değiştirilemez biçimde loglanır. Denetçi erişimi için read-only export fonksiyonu mevcuttur.
• Entegrasyonlar: Jira, ServiceNow ve Azure DevOps gibi ticket sistemleriyle çift yönlü senkronizasyon. İstisna durumu değiştiğinde ilişkili ticket otomatik güncellenir.

SİTEY'in istisna modülü, zafiyet yönetimi sürecinin geri kalanıyla tam entegredir: bulgu keşfi → önceliklendirme → düzeltme veya istisna → doğrulama akışı kesintisiz işler.

SSS