Zafiyet yönetimi nedir?

Bir güvenlik tarayıcısının ekranında yüzlerce satır görebilirsin. Her satırda bir önem seviyesi, ürün adı ve bazen bir CVE numarası bulunur. Bu görüntü, işin bittiğini değil, incelenmesi gereken iddiaların başladığını gösterir. Zafiyet yönetimi; bu iddiaları doğru varlıklarla eşleştiren, kanıtlayan, önceliklendiren, sorumlu kişiye taşıyan ve düzeltmenin gerçekten işe yarayıp yaramadığını yeniden ölçen sürekli bir disiplindir.

Önce kavramları ayıralım

Günlük konuşmada birçok farklı durum için “açık” denir. Profesyonel bir kayıtta daha kesin bir dil gerekir:

• Weakness (zayıflık): Tasarımda, kodda, donanımda veya yapılandırmada zafiyet oluşmasına katkı sağlayabilecek genel koşuldur. Örneğin kullanıcı girdisinin komut içinde güvenli biçimde ayrılmaması bir weakness sınıfıdır.
• Vulnerability (zafiyet): Belirli bir ürün veya sistemde, belirli koşullarda güvenlik etkisi oluşturabilen somut örnektir. Etkilenen sürüm ve yapılandırma önemlidir.
• Exposure (maruziyet): Bir servis veya bilginin gereğinden geniş biçimde erişilebilir olmasıdır. Her maruziyet kendi başına yazılım zafiyeti değildir; yine de saldırı yüzeyini büyütebilir.
• Finding (bulgu): Bir değerlendirme sırasında kayda alınan ve kanıtla desteklenmesi gereken gözlemdir. Bulgu doğrulanmış, yanlış pozitif veya henüz belirsiz olabilir.
• Risk: Zafiyetin belirli bir varlıkta, belirli tehdit koşulları altında doğurabileceği zararın kurum açısından değerlendirilmesidir.

Bu ayrım yalnız terminoloji değildir. Yanlış pozitif bir alarmı gerçek zafiyet gibi işleme almak ekip zamanını tüketir. Gerçek bir zafiyeti “yalnızca düşük skorlu” diyerek görmezden gelmek ise önemli bir iş sürecini tehlikeye atabilir.

Ana ilke

Tarayıcı karar vermez; karar için kanıt üretir

Bir scanner sonucu “bu varlıkta şu sorun bulunabilir” iddiasıdır. Profesyonel analist, doğru varlığı ve ürünü doğrular, detection yöntemini inceler, mümkünse üretici kaynağıyla karşılaştırır ve ancak bundan sonra bulgunun durumuna karar verir.

Neden tek bir skor yetmez?

Bir internet sunucusu ile internete çıkışı olmayan eğitim makinesi aynı CVE'den etkilenebilir. Teknik zafiyet aynı olsa bile erişilebilirlik, taşınan veri, iş kritikliği ve telafi edici kontroller farklıdır. Bu nedenle teknik severity, kurumun risk kararına önemli bir girdi sağlar; onun yerine geçmez.

Örneğin bir scanner, sürüm bilgisinden hareketle kritik bir zafiyet bildirir. İlk soru “skor kaç?” değil, “bu ürün ve sürüm gerçekten burada mı?” olmalıdır. Ardından zafiyetli özelliğin etkin olup olmadığı, servise kimlerin ulaşabildiği, saldırının hangi yetkileri gerektirdiği ve varlık üzerindeki muhtemel etki incelenir. Sonuçta aynı teknik zafiyet iki varlık için farklı aksiyon zamanlarına sahip olabilir.

Yaşam döngüsü nasıl ilerler?

Olgun bir zafiyet yönetimi çalışması sekiz bağlı adımdan oluşur:

1. Yetki ve kapsam: Hangi varlıkların, hangi kaynak IP'den, hangi zaman aralığında ve hangi tekniklerle değerlendirileceği yazılı olarak belirlenir.
2. Varlık bilgisi: Sistem sahibi, işlev, kritik hizmetler, beklenen servisler ve bakım penceresi kayda alınır.
3. Güvenli tespit: Araca uygun, kontrollü ve izlenebilir tarama yürütülür; ham çıktı korunur.
4. Doğrulama: Asset kimliği, ürün, sürüm, yapılandırma, scanner kanıtı ve birincil advisory bilgisi karşılaştırılır.
5. Bağlamsal öncelik: Teknik severity; erişilebilirlik, aktif istismar bilgisi, iş etkisi ve mevcut kontrollerle birlikte değerlendirilir.
6. Aksiyon: Patch, upgrade, yapılandırma değişikliği, özelliği kapatma veya geçici erişim sınırlaması için sahip ve hedef tarih atanır.
7. Tekrar test: Aynı bulgu, karşılaştırılabilir kapsam ve koşullarda yeniden ölçülür. Sistem işlevinin bozulmadığı da kontrol edilir.
8. Öğrenme ve izleme: Kapanan kayıt, tekrar eden kök nedenleri ve gecikme örüntülerini görünür kılacak şekilde ölçülür.

Bu döngüde “risk kabul edildi” ile “false positive” aynı durum değildir. False positive, iddianın gerçekte bulunmadığına dair teknik bir doğrulama kararıdır. Risk kabulü ise zafiyet gerçek olduğu hâlde, belirli süre ve koşullarla riski taşımaya ilişkin yönetim kararıdır. Risk kabulünün sahibi ve sona erme tarihi olmalıdır.

Kayıtların bir sahibi ve zamanı olmalı

Sahipsiz bulgu, teknik olarak doğru olsa bile çoğu zaman ilerlemez. Her kayıtta düzeltmeyi koordine edecek bir owner, kararı verecek sistem sahibi, hedef tarih ve bir sonraki kontrol zamanı bulunmalıdır. Bu alanlar yalnız iş takibi için değil, sorumluluk sınırını korumak için de gereklidir. Güvenlik ekibi problemi açıklayabilir ve çözümü doğrulayabilir; fakat hizmetin ne zaman değiştirileceği çoğunlukla operasyon ve iş sahibiyle birlikte kararlaştırılır.

Durum adları da ölçülü olmalıdır. Open, In progress, Mitigated, Risk accepted, False positive ve Remediated — retest passed gibi ifadeler birbirinden farklı gerçekleri anlatır. “Tamamlandı” gibi belirsiz bir durum, patch'in yalnız planlandığını mı, kurulduğunu mu, yoksa tekrar testten geçtiğini mi göstermez. Açık durum dili, aynı kaydın aylar sonra da doğru yorumlanmasını sağlar.

Kanıt odaklı çalışma nasıl görünür?

İyi bir bulgu kaydı başka bir analistin aynı sonuca nasıl ulaşıldığını anlayabilmesini sağlar. En azından hedef kimliği, gözlem zamanı, scanner ve policy bilgisi, port veya bileşen, ham teknik çıktı, doğrulama yöntemi, güven düzeyi ve kullanılan birincil referans bulunur. Parola, token, kişisel veri veya gereksiz hassas içerik ise kanıta eklenmez; maskelenir.

Son aşamada kayıt “patch uygulandı” diye kapanmaz. Patch'in doğru hedefe ulaştığı, zafiyetli sürüm veya davranışın değiştiği ve tekrar testte bulgunun artık üretilemediği gösterilir. Eğer yalnız güvenlik duvarı kuralı gibi telafi edici kontrol uygulanmışsa zafiyetin kendisi duruyor olabilir; durum mitigated olarak açıkça yazılmalıdır.

Zafiyet yönetiminin amacı mümkün olan en çok alarmı üretmek değildir. Amaç, doğru varlıklardaki gerçek zayıflıkları güvenli biçimde bulmak, karar verilebilir kanıta dönüştürmek ve ölçülebilir biçimde azaltmaktır.