Sızma Testi Kapsamı ve Bulgu Doğrulama: Teknik Kanıt Rehberi

Sızma testi raporu uyum dosyasında en çok “var” işareti alan, en az sorgulanan belgedir. Kapsamı yanlış çizilmiş, kuralları yazılmamış ya da bulguları yeniden test edilmemiş bir test denetçinin önünde zayıf bir kanıttır ve gerçek riski de ölçmez. Rapor rafta durur. Aşağıda test türü seçimini, kapsam ve kurallar belgesini, test sırasındaki operasyonel güvenliği, rapor kalitesinin nasıl okunacağını ve düzeltme sonrası doğrulamayı teknik ekip gözüyle ele alıyoruz.

Zafiyet taraması ve sızma testi farkı

Zafiyet taraması bilinen zafiyet imzalarını otomatik araçlarla geniş bir varlık kümesinde arar ve sürekli tekrarlanır. Sızma testi ise belirli bir kapsamda, sınırlı sürede, bir uzmanın bulguları birbirine bağlayarak gerçek etkiyi göstermeye çalıştığı manuel bir çalışmadır. Tarama “bu sunucuda eksik yama var” der. Sızma testi “bu eksik yama, zayıf bir servis hesabı parolasıyla birleşince domain yöneticisi yetkisine ulaşılabiliyor” sonucunu masaya koyar.

Biri diğerinin yerine geçmez. Sızma testi raporunda taramayla bulunabilecek bulgular çoğunluktaysa ya tarama düzenli yapılmıyordur ya da test derinleşmemiştir. Sürekli tarama ve önceliklendirme döngüsü için zafiyet yönetimi programı rehberine bakın; sızma testinin asıl değeri otomatik araçların göremediği yerlerde çıkar: yetki yükseltme, iş mantığı ve zincirleme saldırı yolları.

Test türleri: dış, iç, web, sosyal mühendislik

Uyum gereklilikleri çoğunlukla “düzenli güvenlik testi” der, türünü söylemez. Doğru türü korumak istediğiniz varlık ve tehdit senaryosu belirler:

Test türü	Yanıtladığı soru	Tipik kapsam
Dış ağ testi	İnternetten içeri girilebilir mi?	Açık IP’ler, VPN, e-posta, yayındaki servisler
İç ağ testi	İçerideki bir saldırgan ne kadar ilerler?	Kullanıcı VLAN’ından AD, sunucular, segmentler
Web uygulaması testi	Uygulama mantığı ve yetkilendirme sağlam mı?	Kimlik doğrulama, oturum, yetki, girdi işleme, API
Sosyal mühendislik	İnsan katmanı kontrolleri işliyor mu?	Phishing, telefon, fiziksel giriş denemesi
Kablosuz ve bulut yapılandırma	Kablosuz ağ ve bulut ayarları sızıntı yaratıyor mu?	SSID’ler, misafir ağ ayrımı, bulut kimlik ve depolama ayarları

Bilgi düzeyi ayrı bir karardır. Kara kutu (black box) testte test ekibine yalnızca hedef adresler verilir; gerçekçidir ama sınırlı sürede yüzeyde kalabilir. Gri kutu testte standart kullanıcı hesabı ve temel mimari bilgisi verilir; uyum amaçlı testlerde süre ve derinlik dengesi açısından çoğu zaman en verimli seçenektir. Beyaz kutu test kaynak kod veya yapılandırma erişimi içerir. İç ağ testinde “ele geçirilmiş kullanıcı” senaryosuyla, yani standart bir domain hesabı ve kurumsal bir dizüstüyle başlamak, sahada en sık yaşanan saldırı başlangıcını taklit eder. Test ekibinin ilk saatini sizin zaten bildiğiniz açıklara harcamaması için AD tarafındaki bilinen zayıflıkları önceden kapatın; Active Directory güvenlik kontrolleri rehberi bu iş için hazırlandı.

Kapsam ve kurallar belgesinin hazırlanması

Kurallar belgesi (rules of engagement), test başlamadan iki tarafın imzaladığı ve testin yasal ve teknik sınırlarını çizen belgedir. Eksik bir belge testin yarıda kesilmesine ya da üretimde kesintiye yol açar. En az şunları içermeli:

• Kapsam: IP aralıkları, alan adları, uygulama URL’leri, API uç noktaları ve test edilecek kullanıcı rolleri. Kapsamdaki varlıkların gerçekten kuruma ait olduğunu doğrulayın; yıllar önce bırakılmış bir IP bloğu artık başkasına ait olabilir.
• Kapsam dışı: Hariç tutulan sistemler ve gerekçesi. Kritik bir sistemi kapsam dışı bırakmak bir risk kararıdır ve raporda görünmelidir.
• Üçüncü taraf izinleri: Bulutta veya barındırma firmasında çalışan sistemler için sağlayıcının test politikasını kontrol edin; paylaşımlı altyapıda izin gerekebilir.
• İzinli ve yasak teknikler: Hizmet engelleme, veri silme, kalıcılık mekanizması bırakma, fiziksel giriş ve sosyal mühendislik açıkça yazılır.
• Zaman pencereleri ve test kaynak IP’leri: Hangi saatlerde ve hangi kaynak adreslerden test yapılacağı; SOC test trafiğini gerçek saldırıdan ancak böyle ayırır.
• İletişim ve acil durdurma: İki tarafta 7/24 ulaşılabilir kişiler, kritik bulgu anında bildirim yöntemi ve testi durdurma prosedürü.
• Veri işleme: Test sırasında erişilen kişisel veya gizli verinin kopyalanmaması, ele geçirilen parola hash’lerinin nasıl saklanıp imha edileceği.

Türkiye’de bazı sektör düzenlemeleri testin belirli yetkinlik belgelerine sahip firma veya personel tarafından yapılmasını şart koşabilir. Bağlı olduğunuz düzenleyicinin güncel şartını sözleşmeden önce doğrulayın.

Test sırasında operasyonel güvenlik

Test kurumun kendi güvenlik kontrollerini de sınar. Hazırlık bu yüzden iki yönlüdür:

• Kapsamdaki kritik sistemlerin güncel ve geri yüklemesi denenmiş yedeği olmalı.
• Hesap kilitleme politikası bilinmeli; parola denemeleri kilitleme eşiğinin altında tutulmalı. Aksi halde sabah yardım masası kilitli hesap çağrılarıyla dolar.
• SOC’ye test bildirilecek mi, yoksa tespit kabiliyeti de mi ölçülecek? İkinci durumda yalnızca sınırlı sayıda yönetici bilgilendirilir ve “test mi, gerçek mi?” doğrulaması için bir kod kelime belirlenir.
• Test ekibinin kullandığı hesaplar ve oluşturduğu nesneler (dosyalar, kullanıcılar, zamanlanmış görevler) kayıt altına alınır; test sonunda temizlendikleri doğrulanır.
• Test trafiği merkezi loglarda iz bırakmalı. Test sırasında hangi alarmların üretildiğine bakmak, tespit kapsamınızı ek maliyet olmadan ölçmenin yoludur.

Rapor kalitesini değerlendirme

Rapor testin tek kalıcı çıktısıdır; uyum kanıtının değeri doğrudan raporun kalitesine bağlıdır. Teslim aldığınız raporu şu sorularla okuyun:

• Yönetici özeti, teknik ayrıntıya boğmadan en önemli risk zincirlerini ve iş etkisini anlatıyor mu?
• Kapsam, test tarihleri, kaynak IP’ler, test türü ve bilgi düzeyi raporda yazılı mı?
• Metodoloji belirtilmiş mi? Örneğin web uygulamaları için OWASP Web Security Testing Guide, genel test süreci için NIST SP 800-115 veya PTES gibi bir çerçeveye atıf.
• Her bulgu için etkilenen varlık, yeniden üretme adımları, istek/yanıt veya ekran kanıtı, ciddiyet derecesi ve derecelendirme gerekçesi (örneğin CVSS vektörü) var mı?
• Bulgular manuel olarak doğrulanmış mı, yoksa tarayıcı çıktısı mı kopyalanmış? Ayıklanmamış yanlış pozitifler ve ham tarayıcı çıktısı düşük kalitenin işaretidir.
• Saldırı zincirleri tek tek bulgulardan ayrı olarak anlatılmış mı?
• Düzeltme önerileri uygulanabilir ve ortama özgü mü? “Yamaları uygulayın” düzeyindeki öneriler işe yaramaz.
• Test edilemeyen alanlar ve nedeni (zaman, erişim, kapsam) belirtilmiş mi?

Pratik bir test: rapordan rastgele bir bulgu seçin ve yeniden üretme adımlarını kendi ekibinize uygulatın. Adımlar tutmuyorsa rapor da tutmaz.

Düzeltme takibi ve yeniden test

Uyum açısından en sık eksik kalan adım, düzeltmenin doğrulanmasıdır. Rapordaki her bulgu, sahibi ve hedef tarihiyle birlikte zafiyet yönetimi sistemine veya bilet sistemine aktarılmalı. Düzeltme tamamlandığında bulgu yeniden testle (retest) kapanır. Yeniden test, test firmasının yaptığı sınırlı bir doğrulama olabilir; basit bulgular için iç ekip de tekrarlayıp kayıt altına alabilir:

# Kapatıldığı belirtilen SMB ve RDP erişiminin kullanıcı VLAN'ından doğrulanması
nmap -Pn -p 445,3389 10.10.20.0/24 -oA retest-smb-rdp-2026-11

# Web bulgusu: HSTS başlığının eklendiğinin kontrolü
curl -sI https://app.ornek.com | grep -i strict-transport-security

# Raporda geçen eski TLS sürümünün kapatıldığının kontrolü
nmap -p 443 --script ssl-enum-ciphers app.ornek.com

Yeniden test, bulgunun ilk kanıtıyla aynı yöntemi kullanmalı. Farklı yöntemle alınan “temiz” sonuç bulgunun gerçekten kapandığını göstermeyebilir; örneğin sunucu tarafında kapatılan bir port, başka bir VLAN’dan hâlâ erişilebilir olabilir. İnternete açık varlıklarla ilgili bulgulardan sonra dış yüzeyi sürekli izlemek için dış saldırı yüzeyi yönetimi rehberi tamamlayıcıdır. Kapatılamayan bulgular için süreli istisna ve telafi edici kontrol kaydı açılır.

Uyum için saklanacak teknik kayıtlar

Bir sonraki denetimde sorulacak kanıtları test bitmeden toplayın. Raporu arşive koymak yetmez:

Kayıt	Neyi kanıtlar
İmzalı kapsam ve kurallar belgesi	Testin planlı ve yetkili olduğu
Nihai rapor ve sürüm bilgisi	Testin yapıldığı ve bulgular
Bulgu–bilet eşleme tablosu	Her bulgunun bir sahibi ve hedef tarihi olduğu
Yeniden test raporu veya iç doğrulama çıktıları	Düzeltmenin etkinliği
İstisna kayıtları	Kapatılamayan riskin bilinçli kabulü
Test sırasında üretilen SOC alarmları	Tespit kabiliyetinin ölçüldüğü

Bu kayıtları test raporuyla birlikte saklamak, ISO/IEC 27001:2022 Ek A 8.8 (Teknik zafiyetlerin yönetimi) ve NIS2’deki tedbirlerin etkinliğinin değerlendirilmesi başlığı için doğrudan kanıt üretir. Test sırasında oluşan logların saklama süresi de kanıt değerini etkiler; bu konu merkezi log saklama mimarisi rehberinde anlatılıyor. Kapsam belirleme, test ve yeniden testi tek bir süreç olarak planlamanız gerekiyorsa sızma testi ve güvenlik doğrulama hizmetimize göz atabilirsiniz.

Sık sorulan sorular

Sızma testi ne sıklıkla yapılmalı?

Sıklık uyum çerçevesine, sözleşmelere ve değişiklik hızına bağlıdır. Yaygın uygulama yılda en az bir kez ve önemli altyapı veya uygulama değişikliklerinden sonra test yapmaktır. Örneğin PCI DSS v4.0 iç ve dış sızma testini yılda en az bir kez ve önemli değişikliklerden sonra ister.

Kara kutu mu, gri kutu test mi seçilmeli?

Kara kutu test dış saldırganı gerçekçi biçimde taklit eder ama sınırlı sürede yüzeyde kalabilir. Gri kutu testte standart kullanıcı hesabı ve temel mimari bilgisi verilir; aynı sürede daha derin bulgu üretir ve uyum amaçlı testlerde genellikle daha verimlidir.

Sızma testi raporunun kaliteli olduğunu nasıl anlarım?

Kapsam, tarih ve metodoloji yazılıdır; her bulgu yeniden üretme adımları ve kanıtla desteklenir; bulgular manuel olarak doğrulanmıştır; saldırı zincirleri ayrıca anlatılır ve öneriler ortama özgüdür. Ham tarayıcı çıktısı ağırlıklı raporlar düşük kalitelidir.

Yeniden test zorunlu mu?

Denetimde bulguların kapandığını göstermenin en güçlü yolu yeniden testtir. Test firmasının sınırlı doğrulaması veya iç ekibin ilk kanıtla aynı yöntemi kullanarak yaptığı ve kayıt altına aldığı kontrol kabul görür; yalnızca bilet kapanışı yeterli değildir.