Bulgu doğrulama ve false-positive ayrımı

Bir zafiyet tarayıcısının ekranda kırmızı bir kayıt göstermesi, sistemde mutlaka sömürülebilir bir zafiyet bulunduğu anlamına gelmez. Araç; gördüğü sürüm dizesi, yanıt başlığı, açık port veya belirli bir davranış üzerinden bir sinyal üretir. Analistin görevi bu sinyali küçümsemek ya da büyütmek değil, sınanabilir bir iddiaya dönüştürmektir.

Bu dersin temel ayrımı şudur: scanner sonucu araç tarafından üretilir; finding ise evidence ile desteklenen profesyonel karardır. Karar yalnızca yazılım sürümüne değil, ilgili bileşenin gerçekten çalışıp çalışmadığına, erişim yoluna, yapılandırmaya ve mevcut kontrollere dayanır.

Sinyalden test edilebilir hipoteze

Doğrulamaya başlamadan önce scanner metnini sadeleştir. “Kritik zafiyet bulundu” gibi geniş bir ifade yerine şu dört parçayı yaz:

1. Hangi yetkili varlık inceleniyor?
2. Araç hangi koşulun var olduğunu iddia ediyor?
3. Bu koşul doğruysa hangi güvenlik hedefi etkilenebilir?
4. İddiayı en az etkileşimle hangi gözlem doğrulayabilir veya çürütebilir?

Örneğin bir araç, yönetim panelinde X-Frame-Options başlığının bulunmadığını söyleyebilir. Hipotez “başlık yok” değildir; “sayfa, çerçeve içine alınmayı engelleyen etkili bir kontrole sahip değil” şeklinde kurulmalıdır. Çünkü aynı koruma uygun bir Content Security Policy içindeki frame-ancestors direktifiyle sağlanabilir. Bir alanı görmemek, etkili kontrolün hiç olmadığı sonucunu tek başına kanıtlamaz.

Karar ilkesi

Önce iddiayı, sonra evidence'ı sınırla

Doğrulama, mümkün olan en güçlü etkiyi üretme yarışı değildir. Yetkili kapsam içinde, iddiayı ayırmaya yetecek en küçük ve en güvenli gözlem dizisidir.

Doğrulama planının güvenlik sınırı

Her doğrulama kaydı kapsam referansıyla başlamalıdır. Varlığın adı veya laboratuvar kimliği, izin verilen zaman aralığı, onaylanan yöntem ve durdurma koşulu açık değilse test başlamaz. Özellikle üretim benzeri ortamlarda veri değiştiren, hesap kilitleyen, yüksek trafik oluşturan veya hizmet durumunu etkileyen adımlar yerine pasif inceleme ve düşük etkili istekler seçilir.

Planın içinde bir stop condition bulunur. Beklenmeyen veri, farklı bir müşteriye ait kayıt, kararsız hizmet davranışı veya kapsam dışı bir yönlendirme görülürse işlem durdurulur. Bu yaklaşım doğrulamayı zayıflatmaz; aksine evidence zincirinin yetkili ve denetlenebilir kalmasını sağlar.

Hassas değerleri toplamak da amaç değildir. Oturum belirteçleri, kullanıcı adları, iç IP adresleri ve kişisel veriler ekran görüntüsüne ya da metin kaydına girmeden önce maskelenir. Gerekli olduğunda değerin tamamı yerine türü, uzunluğu ve son birkaç karakteri kaydedilir. Orijinal hassas veri ayrı ve onaylı bir kasada tutulmuyorsa rapora kopyalanmaz.

Evidence zinciri nasıl kurulur?

İyi evidence, “bende çalıştı” cümlesinden daha fazlasıdır. Bir başka uzman kaydı okuyarak neyin, ne zaman ve hangi koşulda gözlendiğini anlayabilmelidir. Asgari kayıt şu alanları içerir:

• Finding veya scanner kayıt kimliği.
• Yetkili varlık ve kapsam referansı.
• UTC zaman damgası ve kullanılan aracın sürümü.
• Test öncesi varsayım ile beklenen güvenli davranış.
• Maskelenmiş istek, yanıt, yapılandırma veya günlük kesiti.
• Gözlenen davranış ve kararın gerekçesi.
• Evidence dosyasının adı ve bütünlük özeti gibi zincir bilgisi.

Evidence bir ekran görüntüsünden ibaret olmak zorunda değildir. Yapılandırma çıktısı, paket yöneticisindeki doğrulanmış sürüm, ters vekil başlığı veya uygulama günlüğü daha güçlü olabilir. Önemli olan kaynağın belirtilmesi ve verinin finding ile açık bağ kurmasıdır.

Doğrulama oturumunu yönetmek

Doğrulama sırasında notları test bittikten sonra hafızadan tamamlamak yerine adımla birlikte tut. Her adım için amaç, kullanılan güvenli yöntem, gözlem ve sonraki karar ayrı yazılır. Beklenmedik bir sonuç görüldüğünde aynı isteği daha yüksek etkiyle tekrarlamak yerine önce kapsamı, hedefi ve aracın yapılandırmasını yeniden kontrol et. Böylece yanlış varlıktan alınmış bir çıktının finding evidence'ı sanılması engellenir.

İkinci bir uzman inceleme yapacaksa ona yalnız sonuç etiketini verme. Maskelenmiş evidence'ı, varsayımı ve stop condition bilgisini de sun. İnceleyen kişi aynı veriden aynı karara ulaşamıyorsa kayıt henüz yeterince açık değildir. Özellikle false-positive kararında bağımsız göz önemlidir; yanlış bir kapatma, gerçek riski görünmez kılabilir. İnceleme zamanı, rolü ve varsa itiraz notu zincire eklenir. Bu küçük disiplin, scanner tekrar çalıştığında eski kararın koşullarının değişip değişmediğini de karşılaştırılabilir hâle getirir.

Üç farklı karar

Verified finding, iddia edilen koşulun yetkili varlıkta bulunduğu ve güvenlik etkisinin evidence ile desteklendiği durumdur. Burada yalnızca “sürüm eşleşti” değil, koşulun o dağıtım için uygulanabilir olduğu gösterilir.

False-positive, aracın sinyal üretmesine rağmen iddianın yanlış olduğunun yeterli evidence ile gösterilmesidir. Örneğin araç yalnızca bir başlığı kontrol etmiş, fakat eşdeğer ve doğru yapılandırılmış başka bir kontrolün aynı riski engellediği doğrulanmış olabilir.

Inconclusive, karar vermek için evidence'ın yetersiz kaldığı durumdur. Ağ yolu geçici olarak kapalı olabilir, doğrulama yetkisi gereken adımı kapsamıyor olabilir veya sistem davranışı tutarsız olabilir. “Yeniden üretemedim” ifadesi tek başına false-positive değildir.

Telafi edici kontrol de false-positive anlamına gelmez. Zafiyet mevcut olabilir, ancak ağ segmentasyonu veya erişim kontrolü ihtimali düşürüyor olabilir. Bu bilgi finding'i silmez; sonraki önceliklendirme kararına bağlam sağlar.

İnceleme kaydını kapatmak

Kararın sonunda güven düzeyini ve kalan belirsizliği yaz. Verified bir finding için etkilenen varlık ve koşul; false-positive için iddiayı çürüten evidence; inconclusive için eksik bilgi ve önerilen sonraki güvenli adım görünür olmalıdır. Böylece aynı scanner kaydı tekrar geldiğinde ekip sıfırdan tartışmak yerine önceki kararın dayanağını denetler.

Profesyonel doğrulamanın değeri daha fazla kırmızı kayıt üretmek değildir. Değeri; gerçek finding'leri korumak, yanlış sinyalleri gerekçeyle ayırmak ve bilinmeyeni dürüstçe bilinmeyen olarak bırakmaktır.