Kurumsal Sızma Testinde Kapsam Belirlemenin Önemi
Sızma testi kapsamı yalnızca teknik bir karar değil, aynı zamanda risk yönetimi ve iş önceliklendirme kararıdır. Hatalı belirlenmiş bir kapsam ya kritik sistemleri test dışında bırakır ya da kaynakları düşük öncelikli alanlara yönlendirir. Her iki durumda da yatırım iadesi düşer.
Kapsam belirlemede dikkate alınması gereken temel unsurlar şunlardır:
- Hangi sistemler kurum için iş kritik kabul edilmektedir
- Hangi varlıklar kişisel veri içermektedir ve KVKK çerçevesine girmektedir
- Hangi sistemler sektörel regülasyon kapsamındadır (BDDK, SPK, TCMB)
- Son sızma testinden bu yana hangi mimari değişiklikler yapılmıştır
- Önceki testlerde tespit edilip yeniden test edilmesi gereken bulgular bulunmaktadır
Web Uygulama Sızma Testi Neyi İçerir?
Web uygulamaları kurumsal saldırı yüzeyinin en geniş ve en görünür katmanını oluşturur. Bu nedenle web uygulama sızma testi her kapsamlı sızma testinin merkezinde yer alır. Test, OWASP Top 10 ve OWASP ASVS standartlarına göre yapılandırılır.
Web uygulama sızma testinde tipik olarak değerlendirilen başlıklar:
- Kimlik doğrulama ve oturum yönetimi açıkları (broken authentication, session fixation)
- Erişim kontrolü zafiyetleri (IDOR, dikey ve yatay ayrıcalık yükseltme)
- Enjeksiyon türleri (SQL, NoSQL, OS Command, LDAP, template injection)
- Cross-Site Scripting (Reflected, Stored, DOM-based) ve CSRF saldırıları
- Sunucu tarafı istek sahteciliği (SSRF) ve dosya yükleme açıkları
- Yapılandırma hataları, varsayılan kimlik bilgileri ve eksik yamalar
Bulgular CVSS 3.1 metodolojisiyle skorlanır ve her bulguya iş etkisi açıklaması eklenir.
API Güvenliği Sızma Testinde Nasıl Değerlendirilir?
REST ve GraphQL API servisleri kurumsal entegrasyonların belkemiğidir, ancak güvenlik perspektifinden klasik web uygulamalarından farklı bir saldırı yüzeyi sunar. API'ler doğrudan iş mantığını ve veri katmanını dışa açtığı için ayrı bir test metodolojisi gerektirir.
Kurumsal API sızma testi süreçleri OWASP API Security Top 10 kapsamında yürütülür:
- Bozuk nesne seviyesi yetkilendirmesi (BOLA)
- Bozuk kullanıcı kimlik doğrulaması ve token yönetimi açıkları
- Aşırı veri ifşası (excessive data exposure)
- Kaynak ve hız kısıtlaması eksikliği (lack of rate limiting)
- Toplu atama (mass assignment) zafiyetleri
- Güvenlik yapılandırma hataları ve güncel olmayan bileşenler
Profesyonel bir sızma testi çalışmasında API endpoint'leri otomatik tarayıcılarla yetinmeden manuel test edilir; iş mantığı zafiyetleri ve özelleştirilmiş senaryolar ancak bu yolla tespit edilebilir.
Mobil Uygulama Sızma Testi Süreç ve Bulguları
Mobil uygulamalar iOS ve Android platformlarda kullanıcı tarafında çalışan bağımsız yazılımlardır ve yapısal olarak farklı zafiyetler içerir. Sızma testi hem istemci tarafı (uygulama ikilisi) hem de sunucu tarafı (mobil API) açılarından yürütülür.
Mobil sızma testinde değerlendirilen kritik alanlar:
- Uygulama ikili dosyalarının statik analizi ve obfuscation kontrolü
- Yerel veri depolama (Keychain, SharedPreferences) güvenliği
- Sertifika sabitleme (certificate pinning) ve TLS yapılandırması
- Root ve jailbreak tespiti ile uygulama bütünlük kontrolleri
- Mobil API trafiğinin proxy ile dinamik analizi
- Ters mühendislik denemeleri ve kritik mantığın korunması
Ağ ve Altyapı Sızma Testi Bileşenleri
Ağ sızma testi kurumun internet üzerinden erişilebilen sınır sistemlerini ve iç ağdaki yatay hareket olanaklarını değerlendirir. Test, dış (eksternal) ve iç (internal) olmak üzere iki ayrı senaryoda yürütülebilir.
Standart bir ağ sızma testi kapsamı:
- Açık port ve servis tespiti, banner enumeration, OS fingerprinting
- Güvenlik duvarı, IDS/IPS ve WAF kurallarının baypas denemeleri
- VPN, RDP, SSH gibi uzak erişim hizmetlerinin test edilmesi
- Active Directory yapılandırması, Kerberoasting ve AS-REP Roasting denemeleri
- Yerel ağda lateral movement ve domain admin yolu çıkarımı
Bulut Sızma Testi Diğer Testlerden Nasıl Ayrılır?
Bulut ortamları (AWS, Azure, GCP) klasik altyapıdan farklı olarak paylaşılan sorumluluk modeliyle işler. Bulut sağlayıcısı altyapı katmanını korur; yapılandırma katmanı ise tamamen kurumun sorumluluğundadır. Yanlış yapılandırma bulut ortamlarındaki açıkların büyük çoğunluğunun kaynağıdır.
Bulut sızma testi diğer testlerden şu unsurlarla ayrılır:
- Test öncesi bulut sağlayıcısının test izin politikalarına uyum sağlanması
- IAM rolleri, politikaları ve servis hesaplarının ayrıcalık yükseltme açısından denetlenmesi
- S3 bucket, Azure Blob ve GCS gibi nesne depolama servislerinin yetkilendirme kontrolü
- KMS, Secrets Manager ve Key Vault gibi anahtar yönetim servislerinin yapılandırması
- VPC, Network ACL ve security group yapılandırmasının segmentasyon analizi
OT ve Endüstriyel Kontrol Sistemlerinde Sızma Testi
Endüstri 4.0 dönüşümüyle birlikte üretim ağları kurumsal BT altyapısına bağlandı ve OT/ICS sistemleri saldırı yüzeyine girdi. Bu sistemler üzerinde yürütülecek sızma testi standart BT testlerinden farklı yaklaşım gerektirir; çünkü üretim hattındaki bir kesinti gerçek finansal hasar yaratır.
OT sızma testinde uygulanan özel yaklaşımlar:
- Üretim ağında pasif izleme ve trafik analizi tekniklerinin kullanılması
- Aktif testlerin üretim dışı izole ikiz (digital twin) ortamlarda simüle edilmesi
- Modbus, DNP3, OPC UA, EtherNet/IP endüstriyel protokollerinin zafiyet analizi
- SCADA, DCS ve PLC bileşenlerinin segmentasyon ve sertleştirme denetimi
- IT/OT sınırının ve veri akış noktalarının (data diode, jump server) test edilmesi
OT sızma testi NIST SP 800-82 ve IEC 62443 standartlarına referansla yürütülür.
Aşağıdaki tablo farklı sızma testi türlerinin metodolojik referansını ve tipik süresini özetlemektedir:
Test Türü | Standart / Metodoloji | Tipik Süre |
Web Uygulama | OWASP Top 10, OWASP ASVS | 2-5 gün (uygulama büyüklüğüne göre) |
API | OWASP API Security Top 10 | 3-7 gün (endpoint sayısına göre) |
Mobil Uygulama | OWASP MASVS, MSTG | 3-6 gün (platform başına) |
Ağ ve Altyapı | PTES, OSSTMM | 5-10 gün (host sayısına göre) |
Bulut | CIS Benchmark, sağlayıcı rehberi | 4-8 gün (servis çeşitliliğine göre) |
OT/ICS | NIST SP 800-82, IEC 62443 | 7-14 gün (saha ziyareti dahil) |
Sıkça Sorulan Sorular
Bir kurumsal sızma testi tipik olarak ne kadar sürer?
Süre testin kapsamına ve sistem büyüklüğüne göre değişir. Tek bir web uygulaması için iki ile beş gün, kapsamlı bir kurumsal kampanya için iki ile dört hafta arası planlama yapılır. Pre-engagement evresinde sistem envanterine bakılarak gerçekçi bir takvim çıkarılır.
Test sonunda hangi çıktılar teslim edilir?
Standart bir sızma testi en az dört dosya teslim eder. Yönetici özetli teknik rapor, bulguların CVSS skor matrisi ve kanıt ekran görüntüleri, kapatma önerilerini içeren remediation planı ve PoC kayıtları. Tüm dosyalar şifreli kanaldan paylaşılır.
Test kapsamına dahil edilmeyecek sistemler nasıl belirlenir?
Pre-engagement aşamasında kapsam dışı (out-of-scope) sistemler yazılı olarak listelenir. Üçüncü taraf SaaS sistemleri, müşteri ortamları, üretim hattını anlık etkileyebilecek kritik PLC'ler ve yasal kısıtlama altındaki bileşenler genellikle kapsam dışında tutulur. Bu liste sözleşmeye eklenir ve test ekibinin bu sistemlere yönelik herhangi bir aksiyonu sözleşmeyle sınırlandırılır.
Bulunan açıklar test sırasında istismar edilir mi?
Hayır. Profesyonel bir sızma testinde açıklar yalnızca tespit ve kanıt amacıyla doğrulanır. Veri kopyalama, kalıcı backdoor yerleştirme veya hizmet kesintisi yaratacak istismar denemeleri sözleşmeyle açıkça yasaklanır. PoC'ler ekran görüntüsü, log kaydı ve kontrollü komut çıktıları ile sınırlı tutulur.