Sızma Testi için Kapsam Belirleme

Kısaca

• Hedefi, kapsam dışını ve kısıtları açık yazın.
• İzin/onay akışını netleştirin; iletişim/escalation planını ekleyin.
• Başarı kriterlerini ölçülebilir tanımlayın; rapor formatı ve teslim tarihini belirleyin.

Neden Kapsam Kritik?

Doğru kapsam, güvenlik testinin iş hedefleriyle hizalı ve ölçülebilir olmasını sağlar. Yanlış tanımlar, boşa efor ve eksik tespit doğurur.

Checklist

• Varlık listesi (domain, IP, uygulama, API)
• Zaman penceresi ve test türü (black/grey/white-box)
• Başarı kriterleri (ör. kritik X açığın kapatılması)
• Onay/iletişim akışı ve acil durum prosedürleri

Kapsam Şablonu (Örnek)

• Hedefler: app.acme.com (web), api.acme.com (REST), 10.10.0.0/24 (iç ağ)
• Kapsam dışı: prod veritabanı, DDoS, sosyal mühendislik
• Kısıtlar: İş saatleri dışında test, 02:00–06:00 bakım penceresi
• Başarı: Kritik ve yükseklerin %100 kapatılması + doğrulanmış retest

Hukuki ve Onay Akışı

• Yetkilendirme mektubu (LoA) ve sorumluluk sınırları
• Gizlilik ve veri işleme protokolü
• Acil durdurma ve incident bildirim planı

Ürünle Entegrasyon

SİTEY, test bulgularını standart veri modeline çevirir; tekilleştirme, önceliklendirme ve yeniden test akışları ile kapanış hızını artırır.

Kullanım Senaryoları

• Kurumsal kırmızı ekip: Birden fazla sistem ve ekiple paralel yürüyen testlerde tek kapsam belgesi ve değişiklik günlüğü.
• Tedarikçi testi: Tedarikçilere özel yetkilendirme mektubu, kapsam dışı kurallar ve iletişim/escalation şablonları.
• Regülasyon uyumu: ISO 27001/PCI-DSS gereksinimlerine uygun test kapsamı ve kanıt saklama.

Sık Yapılan Hatalar

• Belirsiz hedefler: Domain ve IP aralığı net değil; API uçları atlanıyor.
• İzin/veri koruma eksikliği: Üretim verisi üzerinde agresif test; veri gizliliği ihlali riski.
• Başarı kriteri yok: “En iyi çabayı” hedefleyen, ölçülemeyen tanımlar.
• İletişim planı eksik: Incident anında kime haber verileceği ve durdurma prosedürü tanımsız.

Adım Adım Uygulama

1. Hedefleri yazın: Uygulama, API, IP aralığı; kapsam dışı açıkça belirtin.
2. Test türünü seçin: Black/grey/white-box; zaman penceresini yazın.
3. Onay ve iletişim: Yetkilendirme mektubu, escalation ve durdurma prosedürü.
4. Başarı kriterleri: Kapanması beklenen açık türleri, yanlış pozitif yönetimi, retest.
5. Rapor ve teslim: Format, teslim tarihi ve saklama kuralları.

Metodoloji Seçimi

Doğru sızma testi metodolojisi seçimi, testin derinliğini, tekrarlanabilirliğini ve raporlama kalitesini doğrudan etkiler. Farklı metodolojiler farklı test senaryolarına uygundur; birini diğerine tercih etmek yerine test amacına en uygun olanı seçmek gerekir.

OWASP Testing Guide (OTG), web uygulaması güvenlik testleri için en kapsamlı referanstır. 11 kategoride 90'dan fazla test senaryosu sunar; kimlik doğrulama, oturum yönetimi, girdi doğrulama, iş mantığı ve yapılandırma kontrolleri dahil. Özellikle web ve API odaklı sızma testi projelerinde birincil rehber olarak kullanılır.

PTES (Penetration Testing Execution Standard), testin tüm yaşam döngüsünü kapsar: ön etkileşim, istihbarat toplama, tehdit modelleme, güvenlik açığı analizi, sömürü, post-exploitation ve raporlama. Kapsamlı yapısıyla siber güvenlik danışmanlık firmalarının standart çerçevesidir. OSSTMM (Open Source Security Testing Methodology Manual) ise ölçülebilir güvenlik odaklıdır; RAV (Risk Assessment Values) ile test sonuçlarını sayısal ifade eder.

NIST SP 800-115, ABD hükümet kurumları için hazırlanmış olsa da genel güvenlik değerlendirme rehberi olarak dünya genelinde kullanılır. Teknik test, inceleme ve analiz yöntemlerini kapsar. Kurumsal zafiyet yönetimi programlarının sızma testi bileşeninde referans alınır.

• OWASP OTG: Web/API testleri - en detaylı kontrol listesi
• PTES: Uçtan uca sızma testi - ön etkileşimden raporlamaya
• OSSTMM: Ölçülebilir güvenlik - sayısal risk değerlendirmesi
• NIST SP 800-115: Kurumsal/kamu - teknik değerlendirme rehberi
• CREST / CHECK: Akreditasyonlu testler - düzenleyici gereksinimler için

Test Ortamı Hazırlığı

Sızma testi ortamının doğru hazırlanması, hem testin güvenilirliğini hem de üretim sistemlerinin korunmasını sağlar. Ortam kararları kapsam tanımı kadar dikkatle verilmelidir.

Staging vs. Production kararı projenin en kritik ayrım noktasıdır. Staging ortamında test yapmak üretim verilerini korur ancak bulguların gerçek ortamdaki geçerliliği sorgulanabilir. Production testi gerçekçi sonuçlar verir ama iş kesintisi riski taşır. Optimum yaklaşım; geniş kapsamlı testleri staging'de, son doğrulama ve güvenlik açığı teyidini üretimde (kontrollü şekilde) yapmaktır.

Veri maskeleme, üretim benzeri test verileri oluştururken kişisel ve hassas bilgilerin korunmasını sağlar. KVKK ve GDPR kapsamında gerçek müşteri verileriyle test yapmak hukuki risk taşır. Maskeleme araçları, veri yapısını koruyarak gizli alanları rastgele değerlerle değiştirir.

Rollback planları, olası aksaklıklar için önceden hazırlanmalıdır. Veritabanı snapshot'ı, yapılandırma yedekleri ve hızlı geri dönüş prosedürleri test başlamadan önce doğrulanmalıdır. SİTEY'in zafiyet yönetimi platformu test bulgularını anlık kaydederek, olası geri alma senaryolarında bile kanıt bütünlüğünü korur.

• Staging testi: Güvenli ortam, üretim benzeri yapılandırma, sınırsız test kapsamı
• Production testi: Bakım penceresi, hız limitleri, anlık izleme, acil durdurma
• Veri maskeleme: KVKK/GDPR uyumu, yapısal tutarlılık, maskeleme doğrulaması
• Rollback: DB snapshot, config yedekleri, DNS/load balancer geri dönüş planı
• Ortam izolasyonu: Test trafiği etiketleme, SIEM filtresi, false alarm engelleme

İletişim ve Koordinasyon

Başarılı bir sızma testi projesi, teknik yetkinlik kadar etkili iletişimle şekillenir. Test ekibi ile kurum arasındaki iletişim kopuklukları yanlış beklentiler, gereksiz paniğe yol açan bulgu bildirimleri ve süre kayıpları yaratır.

İletişim protokolleri test başlamadan önce mutabık kalınmalıdır: Kim, kime, hangi kanalda, hangi sıklıkla bilgi verir? Kritik bir güvenlik açığı bulunduğunda anlık bildirim mi yoksa günlük özet mi yapılır? RCE veya aktif veri sızıntısı gibi acil durumlarda war room prosedürü nasıl çalışır?

Günlük durum toplantıları (daily standup), özellikle uzun süreli testlerde ilerlemenin takibi için kritiktir. 15 dakikalık kısa toplantılarda önceki günün bulguları, bugünün odak alanları ve engeller paylaşılır. Bu yaklaşım, siber güvenlik ekipleriyle iş birimlerinin senkronize kalmasını sağlar.

İlerleme raporlaması, testin her aşamasında paydaşlara görünürlük verir. Testin yüzde kaçının tamamlandığı, bulunan kritik/yüksek bulgu sayısı ve kalan süre gibi bilgiler düzenli paylaşılmalıdır. SİTEY platformu üzerinden paylaşılan canlı dashboard, koordinasyonu kolaylaştırır ve tüm tarafları güncel tutar.

• Kickoff toplantısı: Kapsam doğrulama, iletişim kanalları, acil durum prosedürü
• Daily standup: 15 dk - dünün bulguları, bugünün planı, engeller
• Anlık bildirim: Kritik/RCE bulgu → acil kanal (telefon/Slack/Teams)
• Haftalık özet: İlerleme raporu, bulgu dağılımı, kalan kapsam
• Kapanış brifingi: Sonuçlar, öneriler, retest planı, bilgi aktarımı

Üçüncü Taraf ve Tedarikçi Testleri

Kurumların dijital tedarik zinciri genişledikçe, sızma testi kapsamına üçüncü taraf hizmet ve yazılım sağlayıcılar da dahil edilmelidir. Tedarikçi kaynaklı güvenlik açığı ihlalleri, doğrudan kurumun verilerini ve itibarını etkiler.

Uyum gereksinimleri tedarikçi testlerinin birincil itici gücüdür. PCI-DSS (Requirement 11.3), ISO 27001 (A.14.2.8) ve BDDK düzenlemeleri, dışarıdan hizmet alan kuruluşların tedarikçilerinin güvenlik seviyesini periyodik olarak doğrulamasını zorunlu kılar.

NDA ve yasal altyapı tedarikçi testlerinde kritiktir. Test kapsamı, veri erişim sınırları, bulgu paylaşım kuralları ve gizlilik yükümlülükleri yazılı anlaşmalarla tanımlanmalıdır. Tedarikçinin testi kendi ortamında kabul edip etmediği veya rapor paylaşımının yeterli görülüp görülmediği - bu kararlar önceden netleştirilmelidir.

Erişim yönetimi, tedarikçi testlerinin en hassas noktasıdır. Test için sağlanan hesaplar minimum yetki prensibine uygun olmalı, test bitiminde devre dışı bırakılmalı ve tüm erişim logları saklanmalıdır. SİTEY'in zafiyet yönetimi platformunda tedarikçi bazlı ayrı projeler oluşturularak bulgu izolasyonu ve gizlilik kontrolleri sağlanır.

• Hukuki hazırlık: NDA, test yetkilendirme mektubu, veri işleme sözleşmesi
• Kapsam tanımı: Tedarikçinin hangi sistemleri/API'leri test kapsamında
• Erişim kontrolü: Minimum yetki, zaman sınırlı hesaplar, çok faktörlü doğrulama
• Bulgu yönetimi: Paylaşılacak/paylaşılmayacak bilgi sınırları, remediation takibi
• Periyodik tekrar: Yıllık veya değişiklik bazlı yeniden test zorunluluğu

Kapsam Değişiklik Yönetimi

Sızma testi projelerinde kapsam kayması (scope creep) en sık karşılaşılan sorunlardan biridir. Test sırasında keşfedilen yeni sistemler, değişen iş gereksinimleri veya acil güvenlik ihtiyaçları kapsamın genişlemesine neden olabilir. Bu değişikliklerin kontrollü yönetilmemesi bütçe aşımı, süre uzaması ve test kalitesinde düşüşe yol açar.

Değişiklik talep süreci (change request process), resmi bir formla yapılandırılmalıdır. Talep sahibi, değişikliğin gerekçesi, etkilenen kapsam alanları, ek süre/bütçe gereksinimleri ve onay akışı açıkça belgelenmelidir. Onaysız kapsam genişletmeleri kesinlikle yapılmamalıdır.

Re-scoping ihtiyacı doğduğunda mevcut durum değerlendirmesi yapılmalıdır: Testin yüzde kaçı tamamlandı, mevcut bulgular neler, eklenen kapsam mevcut kritik bulgulardan daha mı öncelikli? Bu sorular risk tabanlı bir yaklaşımla yanıtlanmalı ve kaynak tahsisi buna göre yeniden planlanmalıdır.

SİTEY platformu, kapsam değişikliklerini versiyon geçmişi ile kayıt altına alır. Her değişiklik; kim talep etti, kim onayladı, hangi tarihte uygulandı bilgisiyle saklanır. Bu denetim izi, hem zafiyet yönetimi sürecinin şeffaflığını artırır hem de uyum denetimleri için kanıt sağlar.

• Değişiklik formu: Gerekçe, etki analizi, ek kaynak gereksinimi, onay akışı
• Etki değerlendirmesi: Mevcut ilerlemeye etkisi, bütçe ve zaman revizyonu
• Onay mekanizması: Proje sponsoru ve teknik lider çift onayı
• Versiyon kontrolü: Kapsam dokümanının tüm sürümlerinin saklanması
• İletişim: Tüm paydaşlara değişiklik bildirimi ve güncellenen takvim

Test Sonrası Süreç

Sızma testi tamamlandığında asıl iş yeni başlamaktadır. Bulguların düzeltilmesi, doğrulanması ve kurumsal öğrenmenin paylaşılması testin gerçek değerini ortaya çıkarır. Test sonrası süreç ihmal edildiğinde, tespit edilen güvenlik açıkları açık kalır ve bir sonraki testte aynı bulgular tekrarlanır.

Kapanış brifingi (debrief), test sonuçlarının tüm paydaşlarla paylaşıldığı toplantıdır. Kritik bulgular, saldırı zincirleri, iş etkisi ve önerilen düzeltme adımları sunulur. Teknik detayların yanı sıra yönetim için risk özeti ve önceliklendirme matrisi de paylaşılmalıdır.

Bilgi aktarımı (knowledge transfer), test ekibinin kurumsal siber güvenlik ekibine bulguları, kullanılan teknikleri ve test sürecinde edinilen öğrenmeleri aktarmasıdır. Bu adım, iç ekibin yetkinliğini artırır ve gelecek testlerde daha derin kapsam sağlanmasına yardımcı olur.

Retest planlaması ve remediation takibi, düzeltmelerin doğrulanması için kritiktir. Her bulgu için düzeltme sorumlusu, hedef tarih ve doğrulama yöntemi belirlenmelidir. SİTEY'in zafiyet yönetimi platformu, sızma testi bulgularını otomatik olarak düzeltme iş akışına aktarır; SLA takibi, otomatik retest tetikleme ve kapanış kanıtı toplama ile sürecin uçtan uca yönetilmesini sağlar.

• Debrief: Bulgular, saldırı zincirleri, iş etkisi ve öneriler
• Knowledge transfer: Teknik detaylar, kullanılan araçlar, öğrenilen dersler
• Remediation planı: Bulgu bazında sorumlu, süre, öncelik ve düzeltme yöntemi
• Retest: Düzeltme sonrası doğrulama testi, SİTEY üzerinden otomatik tetikleme
• Kapanış raporu: Nihai durum, kapatılan/açık bulgular, gelecek test önerileri

Sektörel Kapsam Örnekleri

Her sektörün kendine özgü düzenleyici gereksinimleri, varlık profili ve tehdit modeli vardır. Sızma testi kapsamı bu farklılıklara göre özelleştirilmelidir; tek beden herkese uymaz.

Finans sektörü, en sıkı düzenlemelere tabi sektörlerden biridir. BDDK, PCI-DSS ve SWIFT CSP gereksinimleri, internet bankacılığı, mobil uygulama, ATM ağı ve SWIFT altyapısının periyodik sızma testi kapsamına alınmasını zorunlu kılar. Çekirdek bankacılık sistemlerinin test edilmesi özel dikkat gerektirir; iş saatleri dışında, izole ortamda ve anlık izleme altında gerçekleştirilmelidir.

Sağlık sektörü, hasta verilerinin hassasiyeti nedeniyle öne çıkar. HIS (Hastane Bilgi Sistemi), PACS (görüntüleme), tıbbi cihaz ağları ve hasta portalı kapsama dahil edilmelidir. KVKK ve sağlık verileri yönetmeliği kapsamında, güvenlik açığı tespiti sırasında gerçek hasta verilerine erişilmemesi için maskeleme zorunludur.

E-ticaret platformlarında ödeme akışı, kullanıcı hesap yönetimi, stok ve fiyat manipülasyonu ile API güvenliği kapsam önceliklidir. PCI-DSS uyumu ve 3D Secure akışlarının doğrulanması kritiktir. Kritik altyapı (enerji, su, ulaşım) sektörlerinde ise SCADA/OT sistemleri, DCS kontrolörleri ve HMI arayüzlerinin zafiyet yönetimi kapsamına alınması, IEC 62443 ve NERC CIP standartlarına uyum gerektirir.

• Finans: İnternet bankacılığı, ATM ağı, SWIFT, mobil app - BDDK/PCI-DSS
• Sağlık: HIS, PACS, tıbbi cihazlar, hasta portalı - KVKK/Sağlık Yönetmeliği
• E-ticaret: Ödeme akışı, API, hesap yönetimi - PCI-DSS/3D Secure
• Kritik altyapı: SCADA/OT, DCS, HMI - IEC 62443/NERC CIP
• Telekomünikasyon: SS7, VoIP, core network, müşteri portalı - ETSI/BTK

SSS

Sızma Testi Araç Ekosistemi

Kapsam belirlenirken kullanılacak sızma testi araçlarının da planlanması gerekir. Araç seçimi, test derinliğini ve kapsam genişliğini doğrudan etkiler. Doğru araç kombinasyonu hem otomatik keşfi hem de manuel derinleştirmeyi desteklemelidir.

Keşif ve haritalama aşamasında Nmap (port/servis keşfi), Amass/Subfinder (subdomain keşfi), Shodan/Censys (internet-facing varlık tespiti) ve Burp Suite/ZAP (web uygulama haritalama) kullanılır. SİTEY'in ASM modülü bu araçların çıktılarını otomatik konsolide eder.

Güvenlik açığı tespiti aşamasında Nessus/OpenVAS (ağ zafiyetleri), Nuclei (web/API zafiyetleri), SQLMap (SQL Injection), ffuf/Gobuster (dizin/dosya keşfi) ve Metasploit (exploit doğrulama) kullanılır. Araç çıktıları SİTEY üzerinden zafiyet yönetimi sürecine aktarılır.

Post-exploitation aşamasında BloodHound (Active Directory yol analizi), Mimikatz (kimlik bilgisi toplama), CrackMapExec (lateral movement) ve Cobalt Strike/Sliver (C2 simülasyonu) gibi araçlar kullanılır. Bu araçların kullanımı kapsam dokümanında açıkça onaylanmalı ve sınırları belirtilmelidir.

• Keşif: Nmap, Amass, Shodan, Burp Suite - varlık haritalama ve servis tespiti
• Web/API: Nuclei, ZAP, ffuf, SQLMap - uygulama seviyesi güvenlik açığı
• Ağ: Nessus, OpenVAS, Metasploit - ağ ve sistem zafiyetleri
• AD/Kimlik: BloodHound, Mimikatz, CrackMapExec - yetki yükseltme
• Raporlama: SİTEY - tüm bulguların konsolidasyonu ve remediation takibi

Kapsam Belirleme Kontrol Listesi

Aşağıdaki sızma testi kapsam belirleme kontrol listesi, projenin başlangıcında tüm kritik kararların alınmasını sağlar. Her madde paydaşlarla mutabık kalınarak belgelenmeli ve onaylanmalıdır.

1. Hedef varlıkları tanımlayın: Domain listesi, IP aralıkları, uygulama URL'leri, API endpoint'leri, mobiluygulama sürümleri ve bulut kaynakları.
2. Kapsam dışını açıkça belirtin: DDoS, sosyal mühendislik, fiziksel güvenlik, üretimimcritik veritabanları gibi test edilmeyecek alanlar.
3. Test türünü belirleyin: Black-box (bilgi yok), grey-box (kısmi bilgi), white-box (tam erişim). Her tür için farklı zaman ve kaynak gereksinimi vardır.
4. Zaman penceresini tanımlayın: Başlangıç/bitiş tarihleri, test saatleri, bakım pencereleri ve yasak dönemler (ör. kampanya dönemleri).
5. Hukuki altyapıyı tamamlayın: Yetkilendirme mektubu (LoA), NDA, veri işleme sözleşmesi ve sorumluluk sınırları.
6. İletişim planını oluşturun: Kickoff, daily standup, acil durum prosedürü, iletişim kanalları ve eskalasyon matrisi.
7. Başarı kriterlerini tanımlayın: Kapatılması beklenen güvenlik açığı türleri, minimum test kapsamı ve kabul edilebilir risk eşikleri.
8. Rapor formatını belirleyin: Yönetici özeti + teknik bulgular + remediation önerileri. Teslim tarihi ve sunum planı.
9. Test sonrası süreci planlayın: Debrief, knowledge transfer, remediation takibi, retest takvimi ve SİTEY entegrasyonu.
10. Tüm paydaşlardan onay alın: Proje sponsoru, teknik lider, hukuk, BT operasyon ve siber güvenlik ekibi onayı.

Raporlama Standartları

Bir sızma testi projesinin değeri, testin kalitesiyle olduğu kadar raporun kalitesiyle de ölçülür. İyi bir rapor, teknik bulguları iş etkisine dönüştürür ve düzeltme sürecini hızlandırır.

Yönetici özeti, teknik detay içermeyen 1-2 sayfalık bir bölüm olmalıdır. Genel risk durumu, en kritik 3-5 bulgu, iş etkisi ve acil aksiyon önerileri yer alır. Yönetim kurulu üyeleri ve CISO bu bölümü okur.

Teknik bulgular bölümünde her bulgu için: başlık, CVSS skoru, OWASP/CWE kategorisi, etkilenen varlık, reprodüksiyon adımları (PoC), iş etkisi analizi, remediation önerisi ve referanslar sunulmalıdır. Ekran görüntüleri ve HTTP istek/yanıt çiftleri kanıt olarak eklenmelidir.

Remediation roadmap, tüm bulguların öncelik sırasına göre listelendiği ve düzeltme takviminin önerildiği bölümdür. SİTEY'in zafiyet yönetimi platformuna aktarıldığında her bulgu otomatik olarak ilgili ekibe atanır, SLA hesaplanır ve retest planlanır.

• Yönetici özeti: Risk durumu, kritik bulgular, iş etkisi, acil aksiyonlar
• Metodoloji: Kullanılan standart, araçlar, test kapsamı ve sınırlamalar
• Teknik bulgular: CVSS, CWE, PoC, etki, remediation - her bulgu için
• Remediation roadmap: Öncelik sırası, düzeltme takvimi, sorumlu atama
• Ekler: Ham tarama çıktıları, ek kanıtlar, ağ şemaları