Aynı sistem için gelen iki sızma testi teklifini birbirinden ayıran şey adam-gün sayısı değil, arkalarındaki OWASP PTES metodolojisi bütünlüğüdür. Birinci teklif “otomatik tarama ve doğrulama” yazıyorsa alacağınız çıktı, tarayıcının ürettiği listenin elden geçirilmiş halidir. İkinci teklif keşif, tehdit modelleme, istismar ve istismar sonrası aşamalarını ayrı ayrı tanımlıyorsa, iş mantığı hatalarını ve yetkilendirme kırılmalarını da içeren bir rapor alırsınız. İki çalışmanın fiyat farkı yüzde yirmi, bulgu değeri farkı ise kat kat olabilir.
Metodoloji, testin hangi sırayla yapıldığını belirlediği için doğrudan kapsama etki eder. PTES çalışmanın iskeletini kurar; OWASP kaynakları uygulama katmanındaki derinliği tanımlar. İkisi birlikte kullanıldığında test, hem tekrarlanabilir hem de denetlenebilir hale gelir. Bu yazıda iki çerçevenin ne yaptığını, nerede kesiştiklerini ve bir teklifin gerçekten bu çerçevelere uyup uymadığını nasıl anlayacağınızı somut kanıtlarla ele alıyoruz.
PTES çalışmanın iskeletini nasıl kurar
PTES (Penetration Testing Execution Standard) bir sızma testini yedi aşamaya böler ve her aşamanın kendi çıktısı vardır:
- Ön görüşme: kapsam, yasak eylemler, test pencereleri, yetkilendirme mektubu ve acil durum iletişimi yazılı hale gelir.
- İstihbarat toplama: açık kaynak istihbaratı, alan adı ve sertifika kayıtları, çalışan e-posta kalıpları, teknoloji yığını çıkarılır.
- Tehdit modelleme: kurumun iş modeline göre en olası saldırgan profili ve en değerli varlıklar belirlenir.
- Zafiyet analizi: otomatik ve elle bulgular birleştirilir, yanlış pozitifler ayıklanır.
- İstismar: bulguların gerçekten kullanılabilir olduğu kanıtlanır.
- İstismar sonrası: erişimin ne kadar genişletilebildiği ve hangi veriye ulaşılabildiği ölçülür.
- Raporlama: yönetici özeti ve teknik detay ayrı katmanlar olarak yazılır.
Bu aşamalardan üçüncüsü, yani tehdit modelleme, teklif metinlerinde en sık atlanan bölümdür. Oysa bir e-ticaret platformunda öncelik iş mantığı ve ödeme akışıyken, bir hastane bilgi sisteminde öncelik yetkilendirme ve kayıt bütünlüğüdür. Tehdit modelleme yapılmadan seçilen test senaryoları kurumun gerçek riskiyle örtüşmez.
OWASP hangi boşluğu doldurur
PTES süreci tanımlar, ancak “bu web uygulamasında tam olarak neye bakılacak” sorusuna cevap vermez. OWASP kaynakları bu boşluğu doldurur. Web Güvenliği Test Rehberi (WSTG) kimlik doğrulamadan oturum yönetimine, giriş doğrulamadan iş mantığına kadar test edilecek kontrolleri madde madde tanımlar. Uygulama Güvenliği Doğrulama Standardı (ASVS) ise aynı kontrolleri seviyelendirir; böylece “hangi derinlikte test edildi” sorusu ölçülebilir hale gelir. Mobil tarafta MASTG, arayüz tarafında API Güvenliği listesi aynı işlevi görür.
Bu ayrımı satın alma diline çevirmek çoğu kurumun zorlandığı noktadır ve kurumsal siber güvenlik danışmanlığının teknik ekipten çok satın alma ve denetim ekiplerine değer kattığı yer tam olarak burasıdır: teklifin hangi kontrol setini, hangi doğrulama seviyesinde uygulayacağının sözleşmeye yazılması.
ASVS seviyeleri kapsamı nasıl netleştirir
ASVS, doğrulama derinliğini üç seviyeye ayırır. Birinci seviye temel kontrollerin varlığını, ikinci seviye çoğu iş uygulaması için önerilen standart derinliği, üçüncü seviye ise yüksek değerli sistemler için ayrıntılı doğrulamayı tanımlar. Kapsam yazarken “OWASP’a göre test edilecektir” ifadesi bir taahhüt değildir; “kimlik doğrulama, oturum yönetimi ve erişim denetimi başlıkları ikinci seviyeye göre doğrulanacaktır” ifadesi taahhüttür. Aradaki fark, teslim edilen raporun hangi soruları cevaplayabildiğini belirler.
İki çerçevenin aşama bazında karşılığı
| PTES aşaması | Uygulama katmanındaki OWASP karşılığı | Kurumun göreceği somut çıktı |
|---|---|---|
| İstihbarat toplama | WSTG bilgi toplama kontrolleri, teknoloji ve sürüm tespiti | Uygulamaya ait envanter ve dışa sızan yapılandırma bilgisi listesi |
| Tehdit modelleme | ASVS seviyesinin ve kritik akışların seçimi | Test edilecek iş akışlarının önceliklendirilmiş listesi |
| Zafiyet analizi | Kimlik doğrulama, oturum, erişim denetimi ve giriş doğrulama kontrolleri | Yanlış pozitifi ayıklanmış, kanıtlı bulgu seti |
| İstismar | İş mantığı ve yetkilendirme testleri | Yatay ve dikey yetki aşımının kanıt ekranlarıyla gösterimi |
| İstismar sonrası | Sunucu tarafı erişimin genişletilmesi, MITRE ATT&CK eşlemesi | Uygulamadan altyapıya geçiş zinciri |
| Raporlama | Kontrol bazlı kapsama tablosu | Hangi kontrolün test edildiği ve sonucunun ne olduğu |
Metodolojisiz testin üç belirtisi
Bir raporun metodolojiye dayanıp dayanmadığı ilk okumada anlaşılır:
- Bulguların tamamı sürüm ve başlık kaynaklıdır. Eksik güvenlik başlıkları ve eski kütüphane sürümleri listelenmiş ama tek bir yetkilendirme testi yoktur.
- Kanıt yoktur. Bulgu açıklaması genel bir metindir; istek-yanıt örneği, ekran görüntüsü veya yeniden üretim adımı bulunmaz.
- Kapsama tablosu yoktur. Hangi kontrolün test edildiği ve hangisinin kapsam dışı kaldığı yazmaz; bu durumda “temiz rapor” ile “bakılmamış alan” birbirinden ayrılamaz.
Teklif değerlendirirken adım adım kontrol listesi
- Teklifte tehdit modelleme aşamasının ayrı bir kalem olarak yer alıp almadığına bakın. Yoksa senaryoların neye göre seçileceğini sorun.
- Hangi OWASP kaynağının, hangi doğrulama seviyesinde uygulanacağını yazılı isteyin. Yanıt “OWASP Top 10” ile sınırlıysa derinlik beklemeyin; bu liste bir test rehberi değil, farkındalık listesidir.
- Elle test ile otomatik tarama arasındaki gün dağılımını sorun ve müşteri bilgisi maskelenmiş bir örnek rapor isteyin. Kanıt ekranları ile yeniden üretim adımları, elle çalışmanın gerçek payını gösterir.
- Kimlik doğrulamalı test yapılıp yapılmayacağını netleştirin. Rol bazlı erişim testi için en az iki farklı yetki seviyesinde hesap gerekir.
- Yeniden test hakkının süresini ve kapsamını sözleşmeye yazdırın. Düzeltmenin doğrulanmadığı bir bulgu, kapatılmış sayılmaz.
- İstismar sonrası aşamanın kapsamda olup olmadığını sorun; uygulamadan sunucuya geçiş kapsam dışıysa raporun etki değerlendirmesi eksik kalır.
Metodoloji uyumunu doğrulayan kanıtlar
Teklif aşamasında verilen sözlerin teslimde karşılığı olup olmadığı somut belgelerle doğrulanır:
- Hangi kontrolün test edildiğini ve sonucunu gösteren kapsama tablosu.
- Her bulgu için yeniden üretim adımları ve istek-yanıt örnekleri.
- Test edilen uç nokta, parametre ve rol listesi.
- Test pencerelerinin, kaynak adreslerin ve kullanılan hesapların kaydı.
- Bulguların MITRE ATT&CK ve OWASP kategorileriyle eşlenmiş hali.
Bu belgeler aynı zamanda ISO 27001 kapsamındaki teknik uygunluk gözden geçirme kayıtları için de kullanılabilir; denetimde “test yapıldı” demek yerine neyin test edildiğini gösterebilirsiniz.
Metodoloji tartışması yalnızca uygulama testleri için geçerli değildir. Savunma etkinliğini ölçen çalışmalarda da senaryoların MITRE ATT&CK taktiklerine göre kurgulanması gerekir; nitekim bir red team hizmeti satın alırken sorulacak ilk soru, hangi tehdit aktörünün taktik ve tekniklerinin (TTP) taklit edileceğidir.
Metodoloji uyumunun kuruma geri dönüşü
Çerçeveye bağlı çalışmanın en görünür faydası karşılaştırılabilirliktir. Aynı kontrol setiyle yapılan iki test arasında hangi başlıkta ilerleme sağlandığı ölçülebilir. İkinci fayda kapsam güvenliğidir: test edilmeyen alan raporda açıkça yazdığı için yanlış güven oluşmaz. Üçüncü fayda ise tekrarlanabilirliktir; test ekibi değişse bile çalışma aynı derinlikte üretilir.
Sık sorulan sorular
OWASP Top 10’a göre test yapıldı demek yeterli mi?
Yeterli değildir. Top 10, en yaygın risk kategorilerini tanıtan bir farkındalık listesidir; test adımlarını tanımlamaz. Test derinliği için WSTG kontrollerine ve ASVS seviyelerine atıf yapılmalıdır. Teklifte yalnızca Top 10 geçiyorsa, kapsamın nasıl belirleneceğini yazılı olarak sorun.
PTES ile OWASP arasında seçim yapmak gerekir mi?
Hayır, ikisi rakip değildir. PTES çalışmanın uçtan uca sürecini, OWASP kaynakları uygulama katmanındaki kontrol derinliğini tanımlar. Altyapı ve dizin hizmetleri tarafında PTES’in istismar sonrası aşaması MITRE ATT&CK eşlemesiyle tamamlanır.
Metodolojiye uygun test daha mı pahalıdır?
Genellikle adam-gün sayısı arttığı için ilk fatura daha yüksektir. Buna karşılık kapsam belirsizliğinden doğan tekrar testler, kapatıldığı sanılan bulguların yeniden açılması ve denetimde istenen kanıtların sonradan üretilmesi maliyeti diğer tarafta büyütür. Karar verirken toplam maliyete bakmak daha doğrudur.
Kaynak kodu vermeden yapılan test metodolojiye uygun sayılır mı?
Sayılır; kara kutu, gri kutu ve beyaz kutu yaklaşımlarının hepsi geçerli seçeneklerdir. Ancak yaklaşımın raporda açıkça belirtilmesi gerekir. Kaynak koda erişilmeden yapılan testte bazı kontroller yalnızca dışarıdan gözlemlenebildiği için doğrulama seviyesi düşer ve bu, kapsama tablosunda görünmelidir.
Test sonrası hangi belgeleri saklamalıyız?
Yetkilendirme mektubu, kapsam ve yasak eylem listesi, kontrol bazlı kapsama tablosu, bulgu raporunun her iki katmanı, düzeltme kayıtları ve yeniden test sonucu saklanmalıdır. Bu set hem iç denetim hem de bilgi güvenliği yönetim sistemi gözden geçirmeleri için yeterli izlenebilirliği sağlar.
Sonuç
Metodoloji, sızma testinin süsü değil kapsam sözleşmesidir: neyin test edileceğini, hangi derinlikte doğrulanacağını ve raporun neyi kanıtlayacağını belirler. Bir sonraki test alımında teklifleri fiyat üzerinden değil, tehdit modelleme aşamasının varlığı ve taahhüt edilen doğrulama seviyesi üzerinden karşılaştırın.
Bilgilendirme: Bu içerik genel bilgilendirme amaçlıdır; kurumunuzun risk profiline özel değerlendirme için uzman desteği alınmalıdır.
