Sızma Testi Aşamaları: Projede Aslında Ne Oluyor?

Sızma testi teklifi alan çoğu kurum, sürecin içeride nasıl işlediğini bilmeden imza atar. Test başlar, birkaç hafta sessizlik olur, sonra bir rapor gelir. Bu yazıda o birkaç haftada ne olduğunu aşama aşama anlatıyoruz, hem beklentiyi netleştirmek hem de teklif karşılaştırırken neye bakacağınızı göstermek için.

1. Kapsam belirleme

Test, teknik bir çalışma olarak değil, bir kapsam tartışması olarak başlar. Bu aşamada üç soruya cevap aranır: hangi sistemler test edilecek, hangi yöntemler serbest, hangi saatlerde çalışılacak.

Kapsam çıkarırken en sık gözden kaçan varlıklar şunlardır:

Bayi, tedarikçi veya iş ortağı portalları
Test ve staging ortamlarının internete açık kalmış kopyaları
Eski bir kampanya için açılmış, unutulmuş alt alan adları
Mobil uygulamanın konuştuğu, web arayüzü olmayan API’ler

Bu aşamanın çıktısı çalışma kuralları (Rules of Engagement) dokümanıdır. Hangi testin yapılmayacağı, dokümanda hangi testin yapılacağı kadar önemlidir. Servis kesintisine yol açabilecek denemeler burada yazılı onaya bağlanır.

Kapsam formunda net olmayan tek bir kalem bile, sonradan “bu dahil değildi” tartışmasına dönüşür. Sabit fiyatlı teklif verebilmenin ön koşulu da budur.

2. Keşif (Reconnaissance)

Saldırganın ilk yaptığı şey saldırmak değildir; haritalamaktır. Bu aşamada hedef hakkında dışarıdan toplanabilecek her şey toplanır.

Pasif keşif hedefe hiç dokunmadan yapılır: alan adı kayıtları, sertifika şeffaflık logları, arama motoru indeksleri, kod paylaşım platformlarında sızmış anahtarlar, çalışanların açık profilleri. Sertifika logları özellikle verimlidir: şirketlerin unuttuğu alt alan adları çoğu zaman buradan çıkar.

Aktif keşif ise hedefle doğrudan iletişim kurar: port taraması, servis sürümlerinin tespiti, dizin keşfi, teknoloji parmak izi çıkarma.

Bu aşama, testin geri kalanının kalitesini belirler. Kaçırılan bir varlık, test edilmemiş bir varlıktır.

3. Zafiyet analizi

Toplanan bilgi ışığında potansiyel zayıf noktalar çıkarılır. Otomatik tarayıcılar burada devreye girer ve bilinen zafiyetleri listeler.

Ancak tarayıcı çıktısı bir sonuç değil, bir başlangıçtır. Tarayıcılar iki yönde de yanılır: olmayan zafiyeti raporlar (false positive) ve olan zafiyeti kaçırır (false negative). İş mantığı hataları, yetki aşımı senaryoları ve zincirlenebilir küçük açıklar hiçbir tarayıcının göremeyeceği kategorilerdir.

Bu aşamada uzmanın işi, listeyi elemek ve hangi bulguların gerçekten sömürülebilir olduğunu belirlemektir.

4. Sömürü (Exploitation)

Test ile taramayı ayıran aşama budur. Tespit edilen zafiyet kontrollü biçimde sömürülür ve gerçekten işe yarayıp yaramadığı kanıtlanır.

Bir tarayıcı “SQL injection olabilir” der. Sızma testi uzmanı o açığı kullanarak veritabanına erişir ve hangi tabloya ulaşılabildiğini gösterir. Aradaki fark, bir olasılık ile kanıtlanmış bir risk arasındaki farktır.

Sömürü her zaman kontrollüdür: veri silinmez, sistem çökertilmez, üretim akışı durdurulmaz. Amaç zarar vermek değil, zararın mümkün olduğunu belgelemektir.

5. İlerleme (Post-Exploitation)

Bir sisteme girilebildiği kanıtlandıktan sonra asıl soru başlar: buradan nereye kadar gidilebilir?

Bu aşamada yetki yükseltme, ağ içinde yatay hareket (lateral movement) ve kalıcılık senaryoları denenir. Ofis ağındaki bir kullanıcı bilgisayarından üretim veritabanına ulaşılabiliyorsa, asıl bulgu ilk açık değil, aradaki segmentasyon eksikliğidir.

Kurumların en çok şaşırdığı bulgular genellikle bu aşamadan çıkar. Tek başına düşük riskli görünen üç zafiyet, zincirlendiğinde kritik bir senaryo oluşturabilir.

6. Raporlama

Rapor, testin ürünüdür. İyi bir raporda her bulgu için şunlar bulunur:

Kavram kanıtı (PoC): bulgunun nasıl doğrulanacağı, adım adım
CVSS v4.0 skoru: riskin standart bir ölçekte ifadesi
CWE sınıflandırması: zafiyetin türü
İş etkisi: teknik olmayan paydaşın anlayacağı dilde sonuç
Çözüm önerisi: genel tavsiye değil, o sisteme özel adım

Rapor ayrıca yönetici özeti içermelidir. Bulguları düzeltecek olan ekip ile bütçeyi onaylayacak olan kişi aynı kişi değildir; rapor ikisine birden hitap etmek zorundadır.

7. Doğrulama testi (Re-test)

Bulgular kapatıldıktan sonra yapılan doğrulama testi, sürecin en çok atlanan aşamasıdır. Atlanırsa geriye bir iddia kalır: “düzelttik”. Doğrulama testi bunu kanıta çevirir.

Bir denetimde sorulan soru “hangi açıklar bulundu” değil, “bulunan açıklar kapatıldı mı”dır. Cevabı ancak yeniden test ederek verebilirsiniz.

Süreç ne kadar sürer?

Tek bir web uygulaması için aktif test genellikle bir ile iki hafta, raporlama üç ile beş iş günü sürer. Birden fazla uygulama, API ve ağ altyapısını kapsayan kurumsal projeler dört haftaya kadar uzayabilir.

Süreyi belirleyen sistem sayısından çok, sistemlerin karmaşıklığıdır. Yüz sayfalık bir tanıtım sitesi ile otuz ekranlık bir bayi portalı aynı işi gerektirmez.

Sızma testinin ne olduğunu ve türlerini Sızma Testi Nedir, Neden Kritik? yazısında anlattık. Raporun denetimde nasıl kanıt olarak kullanıldığını ise KVKK sızma testi sayfamızda bulabilirsiniz.