Sızma Testi Öncesi Hazırlık Süreci

Risk Yönetimi,Siber Güvenlik,Siber Savunma,Sızma Testi,Uncategorized

Kapsam belirleme, testin sınırlarını çizen ve operasyonel riskleri yöneten en kritik aşamadır. Kapsam; hedef IP aralıkları, domain isimleri, web uygulamaları, mobil API uç noktaları ve fiziksel lokasyonlar gibi test edilecek varlıkların net listesini içermelidir. Bu süreçte, iş sürekliliği için hayati önem taşıyan sistemler (örneğin canlı üretim veritabanları, acil durum kurtarma merkezleri veya hassas hasta verisi barındıran sunucular) kesinlikle “kapsam dışı” bırakılmalıdır. Kapsam dışı bırakma, yalnızca sistemi korumak için değil, aynı zamanda yasal sorumlulukları sınırlamak ve test ekibinin enerjisini en kritik hedeflere odaklamak için gereklidir. Kapsamın netleşmesi, “nerede duracağımızı” bilmek anlamına gelir ve yetkisiz erişim iddialarına karşı hukuki bir kalkan oluşturur.

Bilgi Toplama ve Keşif (Reconnaissance) Stratejileri

 Keşif aşaması, saldırganın hedefi tanıma sürecini simüle eder ve iki ana kategoriye ayrılır. Pasif keşif, hedef sistemle doğrudan etkileşime girilmeden, üçüncü taraf kaynaklardan (WHOIS kayıtları, DNS verileri, arama motorları, sosyal medya, sızdırılmış veritabanları) bilgi toplama sürecidir; bu yöntem tespit edilme riski taşımaz ve RoE kapsamında genellikle serbesttir. Aktif keşif ise, hedefe port tarama, servis tanımlama veya ağ keşif paketleri gönderme gibi doğrudan temas gerektiren teknikleri içerir; bu yöntem güvenlik duvarları ve IDS/IPS sistemleri tarafından tespit edilebilir. Hazırlık aşamasında, öncelikle pasif keşif ile hedefin dijital ayak izi (attack surface) haritalanır; aktif keşif ise RoE’de belirlenen zaman dilimlerinde ve uyarılmış (grey/white box) senaryolarda kontrollü şekilde uygulanır.

Teknik Altyapı Hazırlığı ve Erişim Yönetimi

 Testlerin canlı sistemi (production) etkilememesi adına, mümkün olduğunca izole bir ortam tercih edilmelidir. Eğer test canlı ortamda yapılacaksa, test trafiğinin izlenebilmesi için ağ üzerinde “port mirroring” (SPAN port) yapılandırılmalı ve test ekibinin IP adresleri güvenlik loglarında işaretlenmelidir. Test araçlarının çalışacağı istasyonlar (attacker machine), güvenli bir ağ segmentinde konumlandırılmalı ve test sırasında oluşacak verilerin (ekran kayıtları, loglar, kanıtlar) şifreli ve güvenli şekilde saklanması sağlanmalıdır. Sanal laboratuvar ortamlarında ise, test ağının kurumsal ağdan fiziksel veya mantıksal (VLAN/Firewall) olarak ayrıldığından emin olunmalı; yanlışlıkla dışarıya sızabilecek zararlı trafiğin engellendiği doğrulanmalıdır. Bu izolasyon, testin güvenli bir şekilde icra edilmesinin teknik temelidir.

 Erişim sağlanan testlerde (Grey/White Box), güvenlik ilkeleri gereği “en az ayrıcalık” (least privilege) prensibi uygulanmalıdır. Test ekibine verilecek hesaplar, doğrudan “admin” yetkisine sahip olmamalı; bunun yerine test senaryolarını yürütmek için gerekli minimum yetkilerle (örneğin standart kullanıcı, içerik yöneticisi) tanımlanmalıdır. Kimlik bilgilerinin paylaşımı, güvenli kanallar (şifreli e-posta, kurumsal parola yöneticisi) üzerinden yapılmalı ve test bitiminde bu hesaplar derhal pasife çekilmeli veya silinmelidir. Ayrıca, çok faktörlü kimlik doğrulama (MFA) gerektiren sistemlerde, test ekibi için geçici bypass mekanizmaları veya test amaçlı MFA cihazları hazırlanmalıdır. Bu disiplinli erişim yönetimi, test sırasında oluşabilecek yetki suiistimallerini ve veri sızıntılarını önler.

İletişim Protokolleri ve Paydaş Yönetimi

 Sızma testi sırasında hassas veriler ve kritik bulgular paylaşılacağından, iletişim kanallarının güvenliği standart e-posta veya mesajlaşma uygulamalarından daha üst düzeyde olmalıdır. Hazırlık aşamasında, test ekibi ve kurum yetkilileri arasında Signal, Wire veya kurumsal şifreli chat platformları gibi uçtan uca şifreli kanallar tanımlanmalıdır. Ayrıca, bir kriz anında (sistem çökmesi, veri kaybı şüphesi) kimin kime haber vereceğini belirten bir “Eskalasyon Matrisi” hazırlanmalıdır. Bu matris; teknik iletişim (Test Lideri – BT Müdürü), operasyonel iletişim (Proje Yöneticisi – CISO) ve kriz iletişimi (Kurul Üyeleri) seviyelerini içermeli ve 7/24 ulaşılabilir kişiler listelenmelidir. Net iletişim protokolleri, kriz anında paniği önler ve koordinasyonu hızlandırır.

Testin türüne göre (Blind vs. Informed), SOC ve IT ekiplerinin bilgilendirilmesi stratejik bir karardır. “Informed” testlerde, SOC ekiplerine testin yapılacağı tarih ve saat aralığı bildirilir; ancak testin detayları (hangi IP’den, hangi tekniklerle) gizli tutularak gerçek bir saldırıymış gibi tepki vermeleri beklenir. “Blind” testlerde ise SOC ekibi tamamen habersiz tutulur; bu senaryo, ekibin gerçek bir kriz anındaki performansını ölçmek için kullanılır ancak yüksek risk taşır ve üst yönetimin onayını gerektirir. Hangi senaryo seçilirse seçilsin, SOC ekibine “test trafiği mi gerçek saldırı mı?” ayrımını yapabilmeleri için gerekli log ipuçları veya “test başlangıç/bitiş” bildirimleri operasyonel prosedürlerde tanımlanmalıdır.

Raporlama formatı ve beklentileri test öncesinde neden netleştirilmelidir?

 Müşterinin beklentisi ile test ekibinin çıktısı arasındaki uyumsuzluk, en sık yaşanan sorunlardan biridir. Hazırlık aşamasında, raporun formatı (PDF, interaktif portal), dili (Türkçe/İngilizce) ve içeriği (Yönetici Özeti, Teknik Detaylar, CVSS Skorları, Remediation Önerileri) karara bağlanmalıdır. Özellikle, raporun hangi standartlara (OWASP, PTES, NIST) uygun olacağı ve bulguların nasıl sınıflandırılacağı (Kritik, Yüksek, Orta, Düşük, Bilgilendirme) önceden belirlenmelidir. Ayrıca, müşterinin rapor dışında talep edebileceği ek çıktılar (kayıt defteri, video kanıtları, executive sunum) ve teslim süreleri sözleşmeye işlenmelidir. Bu netlik, test bittiğinde “beklediğimiz rapor bu değil” tartışmalarını önler ve sürecin profesyonelce tamamlanmasını sağlar.

Tags :
#SızmaTestiHazırlık #PentestPlanning #RoE #OSINT #SiberSavunma #CyberResilience #RiskYönetimi #NDA #ShadowIT #SiberGüvenlik2026 #KapsamBelirleme
Share This :

Bize Soru Sorun

Soru ve görüşleriniz için bizimle iletişime geçebilirsiniz.