Sızma Testi Alırken Yapılan 7 Kritik Hata
(ve Şirketinize Maliyeti)

2024 yılı, Türkiye'de siber güvenlik tarihi açısından bir dönüm noktası oldu. WatchGuard verilerine göre, sadece bir yılda 1,5 milyona yakın siber saldırı gerçekleşti - bu her gün 4.000'den fazla saldırı demek. Global çapta ise siber saldırıların maliyeti 9,5 trilyon dolara ulaştı ve bu rakamın 2025'te 10,5 trilyonu aşması bekleniyor.

Mart 2025'te yürürlüğe giren Siber Güvenlik Kanunu ile birlikte, artık düzenli güvenlik testleri yapmak birçok sektör için yasal zorunluluk haline geldi. KVKK denetimleri sıklaştı, ISO 27001 sertifikasyonu için sızma testi raporu şart, bankacılık ve finans sektöründe BDDK düzenlemeleri var.

Sonuç? Her geçen gün daha fazla şirket "sızma testi" satın alıyor.

Ama işin gerçeği şu: Çoğu firma yanlış satın alıyor ve bunun farkında bile değil.

Bu yazıda, 7 kritik hatayı gerçek hikayelerle anlatacağım. Bu hatalardan herhangi biri, sizin paranızı çarçur edebilir, şirketinizi riske atabilir ve en kötüsü - gerçek bir siber saldırıya karşı savunmasız bırakabilir.

HATA #1: "En Ucuzu Alalım, Nasılsa Aynı İş"

Ankara'da faaliyet gösteren 120 kişilik bir yazılım şirketi. Müşterileri için CRM sistemi geliştiriyorlar, içinde yüzlerce kurumun hassas verileri var. ISO 27001 denetimi yaklaşıyor, denetçi sızma testi raporu istiyor.

Satın alma müdürü görevlendiriliyor. 5 firmadan teklif alıyor:

CFO bakıyor, "Hepsi sızma testi yazıyor, fark ne ki?" diyor. En ucuzu seçiyorlar.

İki gün sonra ekip geliyor. Bir laptop'la ofise geliyorlar, köşeye oturuyorlar. Akşam gidiyorlar. Ertesi gün tekrar geliyorlar, öğlene kadar kalıyorlar, gidiyorlar. Üçüncü gün rapor mailde: "Kapsamlı Sızma Testi Raporu - 500 Zafiyet Tespit Edildi"

IT müdürü rapora bakıyor ve donup kalıyor. 500 açık! Panik başlıyor. Yönetimi çağırıyor, "Acil toplanın, sistem batmış!" diyor. Sistemleri kapatmayı bile konuşuyorlar.

Bir arkadaş öneriyor: "Ben tanıdık bir siber güvenlik uzmanı çağırayım, bir baksın." Uzman geliyor, rapora göz atıyor ve gülüyor: "480 tanesi false positive. Nessus taraması yapmışlar, hiç doğrulamamışlar. Gerçek sorun 5 tane var, onlar da 'Low Risk' seviyesinde."

Daha da kötüsü, CRM sistemindeki kritik bir authorization açığı - ki bir kullanıcı başka kurumun verilerine erişebilirdi - hiç bulunamamış. Çünkü bu tür mantık hataları ancak manuel testle, business logic'i anlayarak bulunabilir.

İlk başta 75.000 TL'lik kaliteli hizmeti alsalardı, hem daha ucuza gelecekti hem de gerçekten güvende olacaklardı.

Peki Doğru Fiyat Nedir?

Piyasa gerçekleri şöyle (2024-2025 Türkiye):

HATA #2: "Manuel mi Otomatik mi? Fark Eder mi?"

İstanbul'da bir finans teknolojisi şirketi. Ödeme altyapısı sağlıyorlar, günde 50.000 işlem yapılıyor. BDDK denetimi için sızma testi zorunlu.

Firma buluyor, sözleşme yapılıyor: "Kapsamlı penetrasyon testi, tüm sistemler dahil." Fiyat da güzel: 65.000 TL.

Test ekibi geliyor, 4 gün şirkette kalıyorlar. Laptop'lardan sürekli bir şeyler çalışıyor, ekranlar kayıyor. IT müdürü merakla soruyor: "Ne yapıyorsunuz?" Ekip lideri: "Zafiyet taraması yapıyoruz, tüm sistemleri tarıyoruz."

Rapor geliyor. 120 sayfa. Renkli grafikler, tablolar, CVE kodları, patch önerileri. Her açık için "CVSS Score" var, risk seviyeleri belirtilmiş. Görünüşte profesyonel.

Ama bir sorun var: Raporda sadece versiyon zafiyetleri, açık portlar, eski SSL sertifikaları var. Ödeme sistemindeki asıl tehlike - amount manipulation (tutar manipülasyonu) açığı - hiç bulunamamış.

Ne demek bu? Basitçe: Bir kullanıcı, sepetinde 1000 TL'lik ürün varken, ödeme sırasında POST request'i manipüle edip 1 TL ödeyebilirdi. Sisteme 1 TL kaydedilirdi ama 1000 TL'lik ürün teslim edilirdi.

Bu açığı nasıl bulursunuz? Manuel test ile. Bir uzman, ödeme akışını adım adım takip eder, her request'i yakalar, parametreleri değiştirir, sonuçları gözlemler. Ama bu ekip bunu yapmadı. Sadece Nessus/OpenVAS çalıştırdılar ve gittiler.

Manuel vs Otomatik: Farkı Anlamak

Otomatik tarama araçları (Nessus, OpenVAS, Acunetix) harikadır. Hızlıdırlar, binlerce bilinen zafiyeti tarıyorlar, hiçbirini atlamıyorlar. Ama...

Otomatik araçların bulamadığı açıklar:

• Business logic hataları (işletme mantığı)
• Authentication bypass (kimlik doğrulama atlatma)
• Authorization açıkları (yetki kontrol hataları)
• Race condition zafiyetleri
• IDOR (Insecure Direct Object Reference)
• İleri seviye SQL injection varyasyonları

Bunları ancak deneyimli bir uzman, manuel olarak test ederek bulabilir. Sistemi kullanır, akışları gözlemler, "Ya şunu böyle yaparsam?" diye düşünür ve dener.

HATA #3: "Hepsini Test Edin!" (Kapsam Belirsizliği)

200 çalışanlı bir üretim şirketi. Kendi ERP sistemleri var, 3 farklı web uygulamaları var, 120 sunucu var, VPN sistemi var, e-posta sunucuları var. Her şey dijitalleşmiş.

Yönetim kurulu karar veriyor: "Siber güvenlik şart, kapsamlı bir sızma testi yaptıralım."

Tekliflere "Tüm sistemlerimizi test edin" yazıyorlar. Firmalar geliyor, bakıyorlar, teklif veriyorlar: 180.000 TL.

Kabul ediliyor. Test ekibi geliyor, 15 gün sürecek. İlk günler toplantılar oluyor: "Nerelere bakacaksınız?" "Her yere bakacağız." "Tamam."

15 gün geçiyor. Ekip her gün geliyor, farklı sistemlere bakıyor. Bir gün VPN'e, bir gün web sitesine, bir gün iç ağa, bir gün mail sunucusuna...

Rapor geliyor. 150 sayfa. Her sistemde birkaç bulgu var. Ama hiçbir sistemde derinlemesine analiz yapılmamış. Kritik ERP sistemindeki SQL injection - ki tüm şirketin finansal verilerine, müşteri listesine, tekliflere erişim sağlardı - bulunamamış.

Neden? Çünkü kaynaklar dağılmış. 15 gün 10 farklı sisteme dağıtılınca, her birine sadece 1.5 gün düşüyor. 1.5 günde bir ERP sisteminin tüm modüllerini test edemezsiniz.

Doğru Yaklaşım: Önceliklendirme

Akıllı şirketler şöyle yapıyor:

Toplamda 3 yılda 260.000-400.000 TL. Evet, tek seferde 180.000 TL'den daha pahalı gibi görünüyor. Ama gerçek güvenlik sağlıyor çünkü her sistem derinlemesine test ediliyor.

HATA #4: "CV'ye Baktık, İyi Görünüyor"

İzmir'de özel bir sağlık kurumu. 4 hastane işletiyorlar, 30.000 hasta kaydı var sistemlerinde. KVKK denetimi geliyor, sızma testi raporu isteniyor.

Teklifler alınıyor. Bir firma öne çıkıyor: Web sitesi profesyonel, "20 yıllık tecrübe", "OSCP, CEH, GPEN sertifikalı ekip", referanslarda tanıdık isimler var. Teklif: 95.000 TL. Karar: Bu firma.

Test günü geliyor. Gelen ekip: 1 proje yöneticisi (ilk gün geldi, kapsamı anlattı, gitti) + 2 genç teknisyen. Teknisyenler LinkedIn'den bakıyorlar: 1.5 yıl ve 10 ay tecrübeli. OSCP sertifikaları yok.

"Peki web sitesinde yazanlar?" Meğer şirket sahibinin kendi sertifikaları ve tecrübesi. Ama o saha işi yapmıyor, sadece işi yönetiyor.

İki genç eleman ellerinden geleni yapıyorlar. Standart testleri yapıyorlar. Ama 1.5 yıllık tecrübeyle, bir sağlık sisteminin karmaşıklığını anlayamıyorlar. Hasta kayıt sistemindeki IDOR açığını - ki bir doktor başka doktorun hastalarının kayıtlarını görebiliyor - fark edemiyorlar.

Ekip Kalitesini Nasıl Anlarısınız?

Teklif alırken şu soruları sorun:

• "Ekipte kimler olacak?" - İsim, sertifika, tecrübe yılı, LinkedIn profillerini görün
• "Ekip üyelerinin sertifikaları?" - OSCP (altın standart), CEH (giriş seviyesi), GPEN, GXPN (iyi seviye)
• "Kaç yıllık tecrübesi var?" - Minimum 3-5 yıl olmalı senior seviye için
• "Referanslarınız?" - Aynı sektörden referans isteyin, mutlaka arayın

HATA #5: "Retest? Niye Tekrar Test Edelim ki?"

Bir e-ticaret platformu. Günlük 5.000 sipariş alıyorlar. Sızma testi yaptırdılar, rapor geldi: 18 güvenlik açığı, 6'sı kritik seviye.

IT ekibi kolları sıvadı. 2 ay boyunca çalıştılar. 18 açığı teker teker kapattılar. Ya da öyle düşündüler.

Hiçbiri test edilmedi. Çünkü sözleşmede retest yoktu. "Düzelttik işte, niye tekrar test ettirecekmişiz ki? Ek para mı harcayacağız?" dediler.

3 ay sonra, sistem hack'lendi. Saldırgan yine girdi. Nasıl? 18 açıktan:

• 7'si yanlış düzeltilmişti (fix doğru değildi)
• 3'ü hiç düzeltilmemişti (unuttular)
• 8'i doğru düzeltilmişti (bravo!)

Saldırgan yanlış düzeltilmiş açıklardan birini kullandı, sisteme girdi. 120.000 müşteri kaydı çalındı. Dark web'de satışa çıktı.

Retest Neden Kritik?

Güvenlik açığı düzeltmek, düşündüğünüz kadar basit değil. Birkaç örnek:

IT ekibiniz düzeltme yaptığını düşünüyor. Ama gerçekten düzeldi mi? Bunu ancak retest ile anlarsınız.

HATA #6: "IT Ekibine Ne Anlatacağız, Biz Hallederiz"

Bir holding şirketi. 8 farklı şirket, 1.500 çalışan. Yönetim kurulu, siber güvenlik bütçesi ayırdı: 500.000 TL. Dışardan danışman tuttular, strateji oluşturdular, sızma testi yaptırdılar.

IT müdürü? Hiç sürece dahil edilmedi. Neden? "Yönetim kurulu kararı, IT'nin bilmesine gerek yok. Sonunda raporu gösteririz."

Test yapıldı. Kapsamlı bir rapor geldi: 220 sayfa, 47 güvenlik açığı, 12'si kritik. Raporun bir kopyası yönetim kurulunda sunuldu. Alkışlar. "Güzel çalışma."

Rapor IT müdürüne gönderildi. Mail'de. EK dosya. Konu: "Siber Güvenlik Raporu - Aksiyonlar"

IT müdürü rapora baktı ve şok oldu. Neden?

• Test edilen sistemlerin yarısından haberi yoktu
• Bazı açıklar gerçekten kritikti ama nasıl düzelteceğini bilmiyordu
• Bazı açıklar eski sistemlerdeydi, zaten kapatılması planlanıyordu
• Bazı açıklar iş süreçleri nedeniyle kapatılamıyordu (3rd party entegrasyon)

Raporu anlayamadı. Kiminle konuşacağını bilmedi. Test firması ile iletişim kuramadı (sözleşme üst yönetimle, IT'nin bilgisi yok).

Rapor çekmecede kaldı. 8 ay sonra, bir fidye yazılımı saldırısı oldu. Sistemler kilitlendi. Raporda yazıyormuş zaten o açık: "RDP portu internete açık, zayıf parola politikası."

Doğru Süreç Nasıl Olmalı?

1. Ön Toplantı (Kick-off)

• Test firması + Üst yönetim + IT Müdürü/CTO + IT ekip liderleri
• Kapsam birlikte belirlenir
• Hangi sistemler kritik? Hangileri öncelikli?
• Kesinti olacak mı? Nasıl yöneteceğiz?

2. Test Sırasında İletişim

• IT ekibi bilgili olmalı
• Acil bir durum olursa hemen müdahale edilmeli
• Günlük/haftalık kısa brifingler

3. Rapor Sunumu

• Sadece yönetime değil, IT ekibine de sunulmalı
• Her açık detaylı anlatılmalı
• "Nasıl düzeltilir?" tartışılmalı
• Öncelik sırası belirlenmeli

4. Düzeltme Süreci

• IT ekibi düzeltmeleri yapıyor
• Sorular soruyor, destek alıyor
• Retest sırasında test firması ile çalışıyor

HATA #7: "Rapor Geldi, Tamam, İş Bitti"

50 kişilik bir yazılım şirketi. MVP'lerini geliştiriyorlar, SaaS ürünleri yapıyorlar. ISO 27001 sertifikası almak istiyorlar.

Sızma testi yaptırıyorlar. Ciddi bir firma, iyi bir ekip. 12 gün test yapılıyor. Rapor geliyor: 85 sayfa, profesyonel format, renkli grafikler, teknik detaylar, CVSS skorları, CVE referansları.

Yönetim toplantısında rapor sunuluyor (PDF üzerinden). Yönetim: "Güzel rapor, tebrikler." İmzalar atılıyor, fatura ödeniyor. İş bitmiş sayılıyor.

IT ekibi rapora bakıyor. Ama anlamıyor. Teknik terimler, İngilizce açıklamalar, CVE kodları... "CVE-2021-44228 Log4Shell zafiyeti" ne demek? Nasıl düzeltilir? Hangi sistem etkileniyor?

1 ay geçiyor, rapor unutuluyor. 2 ay geçiyor, kimse bakmıyor. 3. ayda ISO denetimi geliyor, denetçi soruyor: "Raporadaki açıklar düzeltildi mi?"

IT müdürü: "Eee... şey... hangi açıklar?"

Denetçi: "Raporun 23. sayfasındaki kritik zafiyetler."

IT müdürü rapora tekrar bakıyor. Anlayamıyor. Dış destek alıyorlar: 65.000 TL danışmanlık ücreti ödeyerek, bir güvenlik firması geliyor, raporu açıklıyor, düzeltmeleri yapıyor.

Toplam maliyet: Sızma testi (95K) + Danışmanlık (65K) = 160.000 TL

Eğer başta rapor sunumu ve Q&A olsaydı, IT ekibi raporu anlayacaktı, kendileri düzeltebilecekti. Ek 65K TL harcanmayacaktı.

İyi Bir Rapor Nasıl Olmalı?

Kaliteli bir sızma testi raporu 2 bölüm içerir:

Bölüm 1: Executive Summary (Yönetim Özeti)

• Teknik olmayan dil
• İş etkisi açıklanır
• Risk seviyeleri anlaşılır
• Genel durum değerlendirmesi
• Yönetim için eylem planı

Bölüm 2: Technical Details (Teknik Detaylar)

• Her açık için detaylı açıklama
• Screenshot'lar (kanıt)
• PoC (Proof of Concept) - açığın gerçekten var olduğunun kanıtı
• Etkilenen sistemler
• Risk skoru (CVSS)
• Nasıl düzeltilir? (En önemli kısım)

Ama rapor tek başına yetmez. Mutlaka bir rapor sunumu olmalı:

• 1-2 saat
• Test ekibi + IT ekibi + Yönetim (opsiyonel)
• Her açık anlatılır
• Sorular sorulur, cevaplar verilir
• Öncelik sırası belirlenir
• Düzeltme planı yapılır

SONUÇ: Sızma Testi Bir Checklist Değil, Yatırımdır

2024 Türkiye verileri çarpıcı: Her gün 4.000'den fazla siber saldırı, toplam 1,5 milyon saldırı. Global çapta maliyet 9,5 trilyon dolar. Ve bu rakamlar artıyor.

Siber Güvenlik Kanunu ile birlikte, artık sızma testi birçok sektör için zorunluluk. Ama unutmayın: Amaç rapor almak değil, gerçekten güvenli olmaktır.

Yukarıda anlattığım 7 hata, gerçek hikayelerden derlendi. Her biri, farklı şirketlerin başına geldi. Bazıları şanslıydı, erken fark ettiler. Bazıları şanssızdı, milyonlarca lira kaybettiler.

Özetleyelim:

• En ucuzu almayın → Ortayı hedefleyin, kalite-fiyat dengesi önemli
• Manuel test oranını sorun → Minimum %60 olmalı
• Kapsamı önceliklendirin → Her şeyi yüzeysel değil, kritik olanları derinlemesine
• Ekibi kontrol edin → CV'yi görün, referans alın, LinkedIn'den araştırın
• Retest şart → Düzeltmeleriniz doğru mu? Kontrol edin
• IT'yi dahil edin → Sürecin başından sonuna, onlar uygulayacak
• Raporu anlayın → Sunum isteyin, sorular sorun, destek alın

Bunları yaparsanız, aldığınız sızma testinden gerçek değer alırsınız. Paranız boşa gitmez, sisteminiz gerçekten güvenli olur.

Sızma Testi Alacaksanız, Doğru Soruları Sorun

Teklif alırken bu soruları mutlaka sorun:

• Hangi metodoloji kullanıyorsunuz? (OWASP, PTES, TSE...)
• Manuel test oranınız nedir?
• Ekipte kimler olacak? (İsim, sertifika, tecrübe)
• Referanslarınız var mı? (Sektörümüzden)
• Retest dahil mi?
• Rapor sunumu yapacak mısınız?
• Düzeltme sonrası destek var mı?
• Süreç nasıl ilerliyor? (Kick-off, test, rapor, sunum)

Eğer bu soruların cevaplarını net alıyorsanız, doğru yoldasınız.