Hangi sorunu çözüyoruz?
Kurumsal müşteriniz, bankanız, denetçiniz veya iş ortağınız sizden güvenlik testi raporu istiyor. Ya da sisteminizin gerçekte ne kadar dayanıklı olduğunu, bir olay yaşanmadan öğrenmek istiyorsunuz.
Otomatik bir tarama aracının çıktısı bu soruya cevap vermez: yüzlerce satırlık listede gerçek riskler gürültüye karışır, iş mantığındaki açıklar ise hiç görünmez.
Sızma testi, yetkili bir uzmanın sisteminize saldırganın bakış açısıyla, ama kontrollü ve izinli biçimde bakmasıdır. Sonuç; bulguların iş etkisine göre sıralandığı, her biri için düzeltme yolunun yazıldığı bir rapordur.
Hangi testleri yapıyoruz?
- Web uygulaması sızma testi: kimlik doğrulama, oturum yönetimi, yetkilendirme, iş mantığı, girdi doğrulama ve yapılandırma.
- Mobil uygulama testi: iOS ve Android uygulaması, cihazda saklanan veri, sertifika doğrulama ve arka uçla iletişim.
- API güvenlik testi: REST ve GraphQL uç noktaları, nesne seviyesinde yetki kontrolleri, istek limitleri ve veri ifşası.
- Ağ ve altyapı testi: dış ve iç ağ, açık servisler, yapılandırma hataları ve ağ ayrımının (segmentasyon) etkinliği.
- Bulut ortamı testi: AWS, Azure ve Google Cloud kimlik ve erişim politikaları, depolama erişimi ve ağ kuralları.
- Kaynak kod güvenlik analizi: SAST ve DAST araçlarıyla desteklenen manuel kod incelemesi.
- Zafiyet taraması: periyodik otomatik tarama, değişiklik takibi ve önceliklendirme.
- Sosyal mühendislik farkındalık testi: kimlik avı (phishing) simülasyonu ve sonrasında çalışan eğitimi.
- Uyum hazırlığı: KVKK, ISO 27001 ve PCI DSS gereksinimleri için teknik kontrollerin hazırlanması.
Yetki ve kapsam
Tüm testler yalnızca müşterinin yazılı yetkisi, imzalı kapsam sözleşmesi ve gizlilik sözleşmesi (NDA) ile, belirlenen zaman aralığında yapılır. Kapsam dışındaki hiçbir sisteme test uygulanmaz.
Kapsam belgesinde test edilecek adresler ve IP aralıkları, test türü, test penceresi, iletişim kişileri, acil durdurma yöntemi ve hariç tutulan işlemler açıkça yazılır. Üçüncü taraf barındırma veya bulut sağlayıcısı kullanılıyorsa onların test politikalarına uygunluk da bu aşamada kontrol edilir.
Test türleri karşılaştırması
| Black-box | Gray-box | White-box | |
|---|---|---|---|
| Bize verilen bilgi | Yalnızca hedef adresi | Kullanıcı hesapları ve temel dokümantasyon | Kaynak kod, mimari ve yönetici erişimi |
| Simüle ettiği durum | Dışarıdan, bilgisi olmayan saldırgan | Yetkili kullanıcı veya ele geçirilmiş hesap | İçeriden kapsamlı inceleme |
| Kapsam derinliği | Dar | Orta–geniş | En geniş |
| Ne zaman tercih edilir? | Dış yüzeyin görünürlüğünü ölçmek | Çoğu web ve mobil uygulama için önerilen | Kritik sistemler ve kod incelemesi |
Kararsız kaldığınızda gray-box öneririz: aynı test süresinde, saldırganın keşif için harcayacağı zamanı gerçek açıkları aramaya ayırır.
Test sırasında sistemim etkilenir mi?
Testler, canlı sistemin çalışmasını bozmayacak şekilde planlanır. Hizmet kesintisi yaratabilecek testler (yük testi, servis dışı bırakma denemeleri) yalnızca yazılı onayınızla ve sizin belirlediğiniz zaman aralığında yapılır.
Mümkün olduğunda testi canlı ortamın kopyası olan bir test ortamında yaparız. Veri değiştiren işlemler test hesaplarıyla ve test verisiyle sınırlı tutulur.
Test boyunca sizin tarafınızda bir iletişim kişisi belirlenir. Beklenmeyen bir durumda test anında durdurulur; kritik bir açık bulunursa raporu beklemeden aynı gün bildirilir.
Test süreci adım adım
- Kapsam görüşmesi: Test edilecek sistemleri, iş açısından kritik verileri ve uyum gereksinimlerini netleştiririz.
- Yetki ve sözleşmeler: Kapsam sözleşmesi, yazılı test yetkisi ve NDA imzalanır.
- Keşif: Uygulamanın yüzeyi, rolleri, uç noktaları ve kullandığı teknolojiler haritalanır.
- Test: Otomatik araçlar yalnızca destek olarak kullanılır; asıl çalışma manuel analizdir.
- Raporlama: Bulgular CVSS 3.1 ile puanlanır, iş etkisi ve düzeltme önerisiyle yazılır.
- Sonuç toplantısı: Raporu yönetim ve teknik ekip için ayrı ayrı sunar, soruları cevaplarız.
- Düzeltme desteği: Geliştirici ekibinizle birlikte düzeltme yöntemini konuşur, gerekirse kod incelemesi yaparız.
- Doğrulama testi (retest): Düzeltilen bulgular yeniden test edilir; sonuç rapora eklenir.
Metodoloji
Çalışmalarımız OWASP (Top 10, ASVS, MASVS, API Security Top 10), PTES ve NIST SP 800-115 referanslıdır. Her bulgu CVSS 3.1 ile puanlanır; puan, iş etkisi değerlendirmesiyle birlikte önceliklendirilir.
Yalnızca "teknik olarak mümkün" olanı değil, sizin iş modeliniz için anlamlı olanı öne çıkarırız. Aynı açık, ödeme sayfasında kritik; iç ağdaki bir test sunucusunda düşük risk olabilir.
Örnek rapor yapısı
- Yönetici özeti: genel risk seviyesi, en önemli bulgular ve öncelikli üç aksiyon.
- Kapsam, yöntem, test tarihleri ve test eden ekip.
- Bulgu özeti tablosu (kritik, yüksek, orta, düşük, bilgi).
- Her bulgu için: açıklama, etkilenen varlık, CVSS puanı ve vektörü, iş etkisi, tekrar üretme adımları ve düzeltme önerisi.
- Olumlu gözlemler: doğru uygulanmış güvenlik kontrolleri.
- Doğrulama (retest) sonuçları.
- Ekler: kullanılan araçlar ve kapsam sözleşmesi referansı.
Raporda gerçek müşteri verisi yer almaz; kanıtlar maskelenerek sunulur. İsterseniz kurumsal müşterilerinizle paylaşılabilecek, teknik ayrıntısı azaltılmış bir özet rapor da hazırlarız.
Raporlarda en sık gördüğümüz bulgu türleri
Aşağıdaki tablo, testlerde sık karşılaşılan bulgu kategorilerini ve kapatma yaklaşımlarını özetler. Amaç, raporla karşılaştığınızda neyle uğraştığınızı önceden bilmenizdir.
| Bulgu türü | İşletmeye etkisi | Kapatma yaklaşımı |
|---|---|---|
| Yetki kontrolü eksikliği | Bir kullanıcının başka müşterinin kaydını görmesi veya değiştirmesi | Her istekte sunucu tarafında sahiplik ve rol kontrolü |
| Zayıf oturum yönetimi | Hesap ele geçirme | Güvenli çerez ayarları, oturum süresi, çok faktörlü doğrulama |
| Girdi doğrulama eksikliği | Veri sızıntısı veya kullanıcı tarayıcısında istenmeyen kod | Parametreli sorgular, çıktı kodlama, içerik güvenlik politikası |
| Güncel olmayan bileşenler | Bilinen açıkların kullanılması | Bağımlılık takibi ve düzenli güncelleme |
| Yanlış yapılandırma | Yönetim panelinin veya yedeklerin internete açık kalması | Sıkılaştırma kontrol listesi ve erişim kısıtlaması |
Ne sıklıkla test yaptırmalısınız?
- Yılda en az bir kez kapsamlı test; bu, PCI DSS gibi standartların da asgari beklentisidir.
- Büyük bir sürüm, yeni bir ödeme akışı veya mimari değişiklikten sonra, ilgili bölüm için ek test.
- Arada periyodik otomatik zafiyet taraması ile yeni çıkan açıkların takibi.
- Yeni bir kurumsal müşteri veya ihale için istenen tarihten önce, düzeltmelere zaman kalacak şekilde planlanmış test.
Geliştirdiğimiz yazılımlar da bu testten geçer
Teslim ettiğimiz her web uygulaması, mobil uygulama ve API yayından önce aynı metodolojiyle test edilir. Varlık Saklama gibi güvenlik gereksinimi yüksek projelerde güvenlik kontrolleri tasarımın ilk gününden itibaren planlanır.
Bağımsızlık gerektiren durumlarda, örneğin bir denetim için, kendi yazdığımız yazılımı değil yalnızca başka ekiplerin geliştirdiği sistemleri test etmeyi öneririz.
Ekip ve belgeler
Testler, sertifikalı güvenlik uzmanlarımız tarafından yapılır. [Ekip sertifikaları ve kurum belgeleri: OSCP / CEH / TSE Sızma Testi Firma Belgesi vb. — sahip olunan belgeler buraya yazılmalı.]
Fiyatı etkileyen faktörler
- Hedef sayısı (URL, uygulama, API uç noktası, IP aralığı) ve kullanıcı rolü sayısı.
- Test türü (black, gray, white-box) ve kaynak kod incelemesinin dahil olup olmadığı.
- Test ortamının hazır olup olmadığı; testin mesai dışında yapılması gerekip gerekmediği.
- Uyum çerçevesine göre özel raporlama gereksinimi.
- Doğrulama testinin kapsamı ve sayısı.
Sık sorulan sorular
Sızma testi ne kadar sürer?
Kapsama göre değişir; tek bir web uygulaması için test ve raporlama genellikle birkaç iş günü ile birkaç hafta arasındadır. Kesin süre kapsam sözleşmesinde yazar.
Bulguları düzelttikten sonra tekrar test ediyor musunuz?
Evet. Rapordaki bulgular için doğrulama testi (retest) hizmetimize dahildir ve sonuç rapora eklenir.
Test raporunu müşterimizle paylaşabilir miyiz?
Evet. Talep ederseniz kurumsal müşterilerinize sunulmak üzere teknik ayrıntısı azaltılmış bir özet rapor da hazırlarız.
Testi kim yapıyor?
Testler sertifikalı güvenlik uzmanlarımız tarafından yapılır. Testi yapacak kişilerin adı ve belgeleri teklif dosyasında ve kapsam sözleşmesinde yer alır.
Zafiyet taraması ile sızma testi aynı şey mi?
Hayır. Zafiyet taraması otomatik bir araçla bilinen açıkların aranmasıdır; sızma testi ise bir uzmanın bulguları doğrulaması, birleştirmesi ve iş mantığındaki açıkları araması demektir. Tarama sık, sızma testi daha seyrek ve derin yapılır.
Test verilerimize erişiyor musunuz?
Test sırasında erişilen veriler yalnızca bulguyu kanıtlamak için gereken en az düzeyde tutulur, raporda maskelenir ve test bitiminde güvenli biçimde silinir. Bu kurallar NDA ve kapsam sözleşmesinde yazılıdır.
Kritik bir açık bulursanız ne oluyor?
Rapor beklenmez; açık aynı gün belirlenen iletişim kişisine bildirilir ve geçici önlem önerilir. Kalıcı düzeltme sonrasında doğrulama testi yapılır.
KVKK sızma testini zorunlu tutuyor mu?
KVKK, kişisel verilerin güvenliği için uygun teknik tedbirlerin alınmasını ister; Kurul'un yayımladığı teknik tedbirler rehberinde sızma testi de önerilen tedbirler arasında yer alır. Sektörünüze özgü düzenlemeler ayrıca zorunluluk getirebilir; durumunuzu keşif görüşmesinde değerlendiririz.