Dış Ağ ve İç Ağ Sızma Testi Arasındaki Farklar

Bir şirket dış ağ sızma testini tamamlıyor. İnternete açık sistemlerde kritik bir açık bulunmuyor. Birkaç ay sonra ele geçirilen standart bir kullanıcı hesabı üzerinden saldırgan iç ağa giriyor, kısa sürede farklı sunuculara ulaşıyor ve yedekleme altyapısını etkileyebilecek yetkiler elde ediyor.

İlk akla gelen soru şu oluyor:

Cevap, testin başarısız olması değil, farklı bir güvenlik sorusunu yanıtlamış olmasıdır.

Dış ağ sızma testi kurumun internetten erişilebilen attack surface'ini ve perimeter kontrollerini inceler. İç ağ sızma testi ise saldırganın belirli bir iç network segment'inde foothold elde ettiği varsayımıyla hareket eder. Kullanılabilir credential'ları, trust relationship'leri, lateral movement yollarını, privilege escalation olasılıklarını ve kritik varlıklara ulaşmanın mümkün olup olmadığını araştırır.

Bu iki test aynı IP adreslerini farklı yerlerden taramak değildir. Başlangıç varsayımı, görülen attack surface, kullanılabilen protokoller, identity bağlamı, exploit zinciri, hedeflenen kanıt ve riskin business impact'e çevrilme biçimi değişir.

Üstelik modern altyapılarda “dışarı” ve “içeri” artık yalnızca firewall'ın iki tarafını ifade etmez. Remote workforce, SaaS, cloud workload, VPN, Zero Trust Network Access, hybrid identity ve üçüncü taraf bağlantıları klasik sınırı bulanıklaştırır. Buna rağmen dış ve iç ağ sızma testi ayrımı hâlâ önemlidir. Çünkü ayrım fiziksel konumdan çok hangi trust boundary'nin aşıldığı ve testin hangi foothold ile başladığı üzerinden yapılır.

Bu yazıda dış ağ ve iç ağ sızma testi arasındaki farkları kapsam, yöntem, kanıt, kör noktalar ve gerçek attack path'ler üzerinden ele alacağız. Hangi testin önce yapılması gerektiğini, ikisinin nasıl birlikte planlanacağını ve teklif alırken scope'a hangi ayrıntıların yazılması gerektiğini de açıklayacağız.

Önce tanımları netleştirelim

“Network pentest yaptırıyoruz” ifadesi tek başına yeterli değildir. Testin internet dışından mı, kurum içindeki bir segment'ten mi, VPN kullanıcısı bağlamında mı, yoksa compromised endpoint varsayımıyla mı başlayacağı sonucu kökten değiştirir.

Dış ağ sızma testi nedir?

Dış ağ sızma testi veya External Penetration Test, kurumun public network infrastructure üzerinden erişilebilen varlıklarını yetkili saldırı simülasyonlarıyla değerlendirir. Tester çoğunlukla kurum ağına önceden erişimi olmayan bir internet saldırganının bakış açısıyla başlar.

İncelenebilecek başlıca varlıklar şunlardır:

• Public IP adresleri ve IP range'leri
• Internet-facing server ve network device'lar
• VPN, ZTNA ve remote access gateway'leri
• Web application ve API endpoint'leri
• DNS, mail ve file transfer service'leri
• RDP, SSH veya management interface gibi dışarı açılmış servisler
• Cloud load balancer, storage endpoint ve public management plane'ler
• CDN ve reverse proxy arkasındaki origin sistemleri
• Eski subdomain, forgotten host ve shadow IT varlıkları
• Third-party üzerinden kuruma bağlanan veya kurum adına yayın yapan servisler

Amaç yalnızca açık portları listelemek değildir. Gerçek soru, dışarıdan görünen servislerin saldırgana bir foothold, unauthorized access, sensitive data exposure veya iç sistemlere geçiş imkânı verip vermediğidir.

İç ağ sızma testi nedir?

İç ağ sızma testi veya Internal Penetration Test, tester'a kurumun tanımlı bir internal network zone'unda başlangıç erişimi verildiği ya da bu erişimin kontrollü olarak sağlandığı çalışmadır.

Başlangıç noktası farklı şekillerde kurgulanabilir:

• Kurum binasındaki kullanıcı VLAN'ına bağlı unmanaged bir cihaz
• Standard domain user hesabına sahip kurumsal workstation
• Ele geçirilmiş kabul edilen employee endpoint
• VPN üzerinden bağlanan remote user
• Guest network içinde unauthenticated cihaz
• Contractor veya third-party segment'i
• Server network içinde düşük yetkili service account
• Cloud virtual network içindeki compromised workload
• Branch office veya subsidiary bağlantısı

İç ağ testinin amacı “içeride kaç açık port var?” sorusundan daha geniştir. Tester başlangıç foothold'unu kullanarak network discovery, identity enumeration, credential exposure, privilege escalation, lateral movement, segmentation bypass ve crown jewel erişimi senaryolarını inceler.

Crown jewel bir Domain Controller, backup management server, hypervisor, payment database, source code platformu, CI/CD sistemi, ERP, customer data store veya production cloud subscription olabilir. Hedef kurumun risk profiline göre belirlenir.

Temel fark: Başlangıç noktası değil, saldırı varsayımı

Dış ağ ve iç ağ testleri çoğunlukla tester'ın fiziksel veya logical konumuyla açıklanır. Bu yaklaşım eksiktir. Asıl fark, testin kabul ettiği saldırı varsayımıdır.

Dış ağ sızma testi şu varsayımla başlar:

İç ağ sızma testi şu varsayımla başlar:

İç ağ foothold'u şu olaylardan biri sonucunda gerçekleşmiş olabilir:

• Phishing sonrası ele geçirilen kullanıcı hesabı
• Çalınmış VPN credential'ı
• Zararlı browser extension
• Compromised contractor laptop
• Public web server üzerinde Remote Code Execution
• Supply chain kaynaklı malware
• İçeride unutulmuş veya izinsiz cihaz
• Kötü niyetli çalışan
• Yanlış yapılandırılmış cloud identity
• Ele geçirilmiş branch office

İç ağ sızma testi bu initial access yöntemlerinin tamamını yeniden gerçekleştirmek zorunda değildir. Çoğu zaman foothold kontrollü olarak sağlanır ve test eforu “erişimden sonra ne oluyor?” sorusuna ayrılır.

Bu nedenle iç ağ testine baştan bir standard user account verilmesi testi kolaylaştıran yapay bir avantaj değil, tanımlı threat scenario'nun başlangıç koşuludur. Ancak rapor, hangi access'in tester'a verildiğini ve hangisinin test sırasında elde edildiğini açıkça ayırmalıdır.

Dış ağ ve iç ağ sızma testi karşılaştırması

Tablodaki en önemli fark şudur: Dış ağ testi kapının ne kadar kolay açıldığını, iç ağ testi ise kapı açıldıktan sonra binanın içindeki bölmelerin gerçekten çalışıp çalışmadığını ölçer.

Ancak bu benzetme de bir noktada yetersiz kalır. Modern yapılarda kullanıcı, cihaz ve workload her request'te yeniden doğrulanabilir. Bu nedenle “iç ağa girdi, artık güvenilir” modeli teknik olarak savunulamaz. İç ağ pentestinin değeri de tam olarak burada ortaya çıkar. Network location'ın gereğinden fazla trust sağlayıp sağlamadığını gösterir.

Dış ağ sızma testi hangi soruları yanıtlar?

Kaliteli bir dış ağ sızma testi yalnızca “hangi CVE'ler var?” sorusuna cevap vermez. Kurumun internette bıraktığı gerçek iz ile güvenlik envanteri arasındaki farkı araştırır.

Kurum internette gerçekte ne yayınlıyor?

CMDB veya asset inventory çoğu zaman gerçeğin tamamını göstermez. Satın alınan bir SaaS, geçici migration host'u, eski VPN gateway, unutulmuş development subdomain'i veya farklı cloud account'ta açılmış management interface envanter dışında kalabilir.

External reconnaissance şu kaynakları ve sinyalleri ilişkilendirebilir:

• DNS kayıtları ve historical naming pattern'leri
• Certificate Transparency kayıtları
• Public IP ownership ve ASN ilişkileri
• Web response, redirect ve TLS certificate bilgileri
• Cloud service hostname'leri
• Public repository ve documentation içinde geçen endpoint referansları
• E-mail infrastructure ve third-party gateway kayıtları
• Subdomain ve virtual host davranışları

Bulunan her varlık otomatik olarak scope'a dahil değildir. Tester, keşfedilen fakat açıkça yetkilendirilmemiş third-party veya farklı tüzel kişiye ait sistemi test etmemelidir. Bu varlıklar önce scope owner ile doğrulanır.

Perimeter hangi servisleri dışarı açıyor?

Port taraması başlangıçtır, sonuç değildir. Açık portun arkasındaki service version, authentication yöntemi, encryption ayarı, exposure amacı ve access control birlikte değerlendirilmelidir.

Örneğin internetten erişilen SSH servisi tek başına vulnerability değildir. Fakat password authentication açıksa, MFA yoksa, management interface bütün internete açıksa ve weak credential politikası bulunuyorsa risk artar. Aynı servis yalnızca bastion üzerinden, strong key ile ve source IP restriction altında çalışıyorsa attack surface önemli ölçüde farklıdır.

Dış ağ testinde şu sorular sorulur:

• Bu servisin internete açık olması business requirement mı?
• Source IP restriction veya gateway zorunluluğu var mı?
• Default veya legacy authentication yöntemi etkin mi?
• Exposed software version bilinen ve uygulanabilir bir vulnerability taşıyor mu?
• Management plane ile user-facing service ayrılmış mı?
• Reverse proxy arkasındaki origin doğrudan erişilebilir mi?
• IPv6 exposure, IPv4 policy'sinden farklı mı?
• Alternate port veya protocol aynı kontrolü atlıyor mu?

Remote access gerçekten ne kadar dirençli?

VPN ve ZTNA servisleri dış ağ testinin en kritik parçalarından biridir. Çünkü başarılı compromise, doğrudan iç ağ veya kurumsal application erişimine dönüşebilir.

Değerlendirilebilecek başlıklar şunlardır:

• MFA enforcement ve enrollment akışı
• Legacy authentication endpoint'leri
• Account enumeration
• Password spraying'e karşı rate limit ve lockout davranışı
• Device posture kontrolü
• Split tunneling ve route kapsamı
• Session lifetime ve reauthentication
• Client certificate doğrulaması
• Self-service password reset güvenliği
• VPN portal ile identity provider arasındaki trust
• Disabled account ve offboarding etkisi

Password spraying veya credential validation production account'larını kilitleyebilir. Bu testler ancak açık Rules of Engagement, düşük hız, allowlist ve acil durdurma mekanizmasıyla yapılmalıdır.

Public web application ve API ne kadar derin test edilir?

Dış ağ pentesti web application ve API'leri keşfeder, fakat her zaman tam kapsamlı bir Web Application Penetration Test değildir.

External network scope içinde tester genellikle şunlara bakar:

• Exposed administrative panel
• Default credential
• Bilinen component vulnerability'si
• Authentication bypass sinyali
• Sensitive file ve debug endpoint
• Misconfigured reverse proxy
• Public API inventory
• Server-side vulnerability için yüksek değerli giriş noktaları

Business logic, multi-role authorization, checkout manipulation, complex API workflow ve source-informed testler gerekiyorsa ayrıca web uygulaması sızma testi scope'u tanımlanmalıdır. “Public URL'ler dış ağ testine dahildir” cümlesi, bütün uygulama use case'lerinin test edileceği anlamına gelmez.

Edge kontrolü origin'i gerçekten koruyor mu?

WAF, CDN veya reverse proxy kullanılması origin sistemin gizli olduğu anlamına gelmez. Historical DNS kaydı, certificate bilgisi, response fingerprint veya farklı hostname davranışı origin'i açığa çıkarabilir.

Origin doğrudan erişilebiliyorsa saldırgan şu avantajları elde edebilir:

• WAF kontrolünü bypass etme
• Rate limit'i atlama
• CDN authentication veya bot control katmanını geçme
• Farklı TLS veya virtual host configuration'ından yararlanma
• Public olması beklenmeyen management route'a ulaşma

Dış ağ testi yalnızca görünen hostname'e değil, ona bağlı infrastructure path'e bakmalıdır.

Dış ağ sızma testi neyi güçlü biçimde gösterir?

Dış ağ testinin en değerli çıktısı, public exposure'ın saldırgan gözünden doğrulanmasıdır.

Öne çıkan kanıt türleri şunlardır:

• İnternet üzerinden erişilebilen beklenmeyen asset
• Unauthenticated veya weakly authenticated service
• Exposed management interface
• Exploitable edge device veya remote access appliance
• Dışarıdan kullanılabilen default ya da weak credential
• MFA bypass veya legacy authentication path
• Origin exposure
• Public cloud storage veya registry erişimi
• External-facing application üzerinden server compromise
• Sensitive data'nın public response veya file içinde açığa çıkması
• Third-party entegrasyonundan kuruma uzanan trust problemi

Bu bulguların business değeri açıktır. Saldırganın içeriden hiçbir avantajı olmadan ulaşabildiği entry point'i gösterir.

Dış ağ sızma testi neyi göstermez?

Temiz sonuçlanan dış ağ testi kurumun tamamının güvenli olduğunu kanıtlamaz. Çünkü tester perimeter arkasındaki trust structure'ı çoğu zaman göremez.

Şu alanlar dış ağ testinin doğal kör noktalarıdır:

• Internal network segmentation
• User VLAN'dan server VLAN'a erişim
• Active Directory privilege path'leri
• Local administrator password reuse
• Internal file share içindeki credential ve secret'lar
• LLMNR, NBT-NS ve NTLM relay koşulları
• Internal PKI ve AD CS configuration
• Unpatched internal server'lar
• Backup ve hypervisor management erişimi
• Workstation'dan production environment'a geçiş
• Internal database'lerde excessive privilege
• Branch office ve subsidiary trust'i
• Internal DNS ve name resolution davranışı
• Management network izolasyonu
• Egress kontrolü ve data exfiltration sınırı

Perimeter'ın güçlü olması değerlidir, fakat phishing, credential theft, supply chain ve insider riskini ortadan kaldırmaz. Dış ağ pentestinden “saldırgan asla içeri giremez” sonucu çıkarılamaz.

İç ağ sızma testi hangi soruları yanıtlar?

İç ağ sızma testinin merkezinde vulnerability listesi değil, attack path vardır. Tek bir düşük yetkili foothold'un hangi trust relationship'ler üzerinden büyüyebildiği incelenir.

İçeride hangi sistemler gerçekten görülebiliyor?

Network diagram ile fiili erişim aynı olmayabilir. ACL, firewall rule, route, dual-homed host, VPN policy, IPv6 ve host firewall farklılıkları beklenmeyen yollar oluşturabilir.

Tester, kendisine verilen başlangıç segment'inden şu soruların cevabını arar:

• Hangi subnet ve host'lara route var?
• Hangi TCP ve UDP servislerine erişilebiliyor?
• Kullanıcı segment'inden management port'ları görülebiliyor mu?
• Internal DNS kritik varlıkları ne ölçüde açığa çıkarıyor?
• Legacy protocol'ler hâlâ çalışıyor mu?
• Segmentation yalnızca north-south traffic'te mi uygulanıyor?
• Host firewall network firewall'daki boşluğu kapatıyor mu?
• IPv6 ve alternative protocol aynı policy'ye tabi mi?
• Cloud ile on-premise arasındaki route beklenenden geniş mi?

Internal discovery kontrollü hızda yürütülmelidir. Özellikle OT, legacy appliance, printer, medical device ve hassas middleware agresif scan nedeniyle etkilenebilir. Scope owner test öncesi fragile system listesini paylaşmalıdır.

Identity sistemi saldırgana ne kadar bilgi ve yetki veriyor?

Active Directory ortamında sıradan bir domain user belirli directory bilgilerini doğal olarak okuyabilir. Risk, bu görünürlüğün hatalı delegation, weak credential veya yanlış trust ile birleşmesidir.

İç ağ testinde şu alanlar incelenebilir:

• Domain, forest, trust ve group yapısı
• Privileged account ve nested group ilişkileri
• Service account'ların yetkileri
• Kerberos delegation configuration
• Unconstrained veya riskli constrained delegation
• SPN kullanan account'ların password dayanıklılığı
• Preauthentication kapalı account'lar
• Local administrator password tekrarları
• Shared ve dormant account'lar
• Excessive ACL ve object control hakları
• Group Policy üzerinden verilen privilege'lar
• AD CS certificate template ve enrollment permission'ları
• Hybrid identity synchronization ve cloud role geçişleri
• Tiering modelinin uygulanıp uygulanmadığı

Bu kontrollerin amacı Domain Admin olmak için gösteri yapmak değildir. Kurumun identity modelindeki en kısa ve gerçekçi privilege path'i bulmak, her adımın hangi security control eksikliğinden doğduğunu göstermektir.

Credential'lar nerede ve nasıl açığa çıkıyor?

İç ağda saldırganlar çoğu zaman yeni bir memory corruption exploit'i aramak yerine var olan credential'ları kötüye kullanır. MITRE ATT&CK içinde Valid Accounts ve Remote Services tekniklerinin birçok tactic ve lateral movement senaryosunda yer alması bu yüzden önemlidir.

Credential exposure şu kaynaklarda görülebilir:

• Readable network share içindeki configuration ve script'ler
• Deployment file ve unattended installation artifact'ları
• Source code veya backup dosyaları
• CI/CD variable ve build log'ları
• Browser, terminal veya application credential cache'leri
• Process ve service configuration
• Shared local administrator password'ları
• Service account için zayıf veya uzun süre değişmeyen password
• Legacy Group Policy Preferences artifact'ları
• User home directory ve support script'leri
• Database connection string'leri
• Private key ve certificate export'ları

Credential dumping, hash extraction veya gerçek secret kullanımı yüksek etkili işlemlerdir. Her iç ağ testinde otomatik olarak uygulanmamalıdır. Rules of Engagement hangi host'ta, hangi account için, hangi kanıt seviyesine kadar ilerlenebileceğini belirlemelidir. Bazı ortamlarda credential'ın readable olduğunun gösterilmesi yeterlidir. Bazılarında privilege path'in doğrulanması için kontrollü kullanım gerekebilir.

Lateral movement ne kadar kolay?

İlk endpoint'in ele geçirilmesi ile kritik sunucuya ulaşılması arasında güvenlik kontrolleri bulunmalıdır. Lateral movement testi bu katmanların gerçekten çalışıp çalışmadığını inceler.

Yaygın hareket yolları şunlardır:

• RDP
• SMB ve administrative share
• WinRM
• WMI ve RPC tabanlı remote management
• SSH
• VNC
• Database remote connection
• Hypervisor ve backup console
• Software deployment platformu
• Remote support tool'u
• Cloud management API
• Container orchestration control plane

Bir protokolün açık olması tek başına açık değildir. Risk şu koşulların birleşiminden doğar:

• Gereksiz network reachability
• Stolen veya reusable credential
• Account'ın remote logon yetkisi
• MFA veya device condition bulunmaması
• Excessive local ya da domain privilege
• Monitoring ve alert üretmemesi
• Hedef sistemin kritik varlıklara ek erişim sağlaması

Tester yalnızca “RDP açık” yazmamalıdır. Hangi source segment'ten, hangi account ile, hangi target'a ve hangi sonuca ulaşıldığını göstermelidir.

Network segmentation gerçekten çalışıyor mu?

Segmentation diagram üzerinde değil traffic path üzerinde doğrulanır. Firewall rule review faydalıdır, fakat uygulamadaki gerçek sonucu tek başına kanıtlamaz.

İç ağ sızma testi şu yolları araştırabilir:

• User VLAN'dan server network'e doğrudan erişim
• Guest network'ten corporate service'e geçiş
• Contractor segment'inden production'a ulaşım
• Non-CDE network'ten Cardholder Data Environment'a erişim
• Workstation'dan backup veya hypervisor management'e bağlantı
• Development'tan production database'e route
• Branch office'ten headquarters critical system'e geçiş
• On-premise network'ten cloud management plane'e erişim
• Dual-homed host üzerinden pivoting
• Firewall'ın kontrol etmediği IPv6 path
• VPN user segment'inden geniş east-west erişim

Segmentation testinin amacı yalnızca engellenen portları saymak değildir. Korunması gereken zone'a beklenmeyen bir path bulunup bulunmadığını ve bu path'in application-level erişime dönüşüp dönüşmediğini doğrulamaktır.

Crown jewel gerçekten korunuyor mu?

İç ağ pentestinin business impact ürettiği nokta budur. Domain Admin elde etmek her kurum için nihai hedef olmayabilir. Bazı ortamlarda yedekleme altyapısı, payment switch, source code repository veya production secret vault daha kritik olabilir.

Test öncesi crown jewel listesi belirlenmelidir:

• Hangi sistem iş sürekliliği için vazgeçilmez?
• Hangi data set'i sızarsa en büyük zarar doğar?
• Hangi management plane üzerinden çok sayıda sistem kontrol edilebilir?
• Hangi backup altyapısı ransomware recovery için kritiktir?
• Hangi identity role cloud ortamının tamamını etkiler?
• Hangi CI/CD sistemi production'a code deploy edebilir?

Tester'ın görevi bu sistemleri bozmak değildir. Erişim yolunu minimum etkili kanıtla göstermek ve blast radius'u ölçmektir.

İç ağ sızma testinde öne çıkan teknik riskler

İç ağ ortamları birbirinden farklıdır, ancak bazı risk pattern'leri sık görülür.

Flat network ve aşırı east-west erişim

Bir kullanıcı workstation'ı file server, database, management interface ve backup server ile doğrudan konuşabiliyorsa tek endpoint compromise'ı geniş bir saldırı alanı oluşturur.

Mikro-segmentation ürünü satın alınmış olması yeterli değildir. Policy'nin doğru asset group'larına uygulanması, deny rule'ların log üretmesi ve exception'ların zaman içinde genişlememesi gerekir.

SMB signing ve NTLM relay koşulları

NTLM authentication kullanılan ortamlarda name resolution poisoning, coerced authentication ve relay precondition'ları birlikte ciddi risk oluşturabilir. SMB signing zorunlu değilse veya LDAP tarafında ilgili korumalar eksikse saldırgan ele geçirdiği authentication attempt'ini başka servise taşıyabilir.

Burada raporun yalnızca “SMB signing disabled” demesi yeterli değildir. Hangi source'tan authentication tetiklenebildiği, hangi target'ın relay kabul ettiği ve hangi privilege'in elde edilebildiği kontrollü biçimde gösterilmelidir. Relay mümkün değilse configuration weakness ile exploitable attack path ayrı değerlendirilmelidir.

Service account ve Kerberos riskleri

Service account'lar uzun süre değişmeyen password ve geniş privilege ile çalışabilir. SPN kayıtlı account'ların offline password guessing'e karşı dayanıklılığı, preauthentication kapalı account'lar ve delegation ayarları Active Directory attack path'lerinin önemli parçalarıdır.

Güçlü, uzun ve yönetilen secret kullanan gMSA gibi mekanizmalar riski azaltabilir. Ancak yanlış delegation ve excessive privilege, password güçlü olsa bile saldırı yolunu açık bırakabilir.

Local administrator password reuse

Aynı local administrator credential'ının çok sayıda endpoint'te kullanılması, tek bir host'tan elde edilen hash veya password'un yatay yayılımını kolaylaştırır. LAPS veya eşdeğer unique secret yönetimi uygulanmadığında compromise blast radius'u büyür.

Testte bütün cihazlara bağlanmak gerekmez. Representative sample üzerinden reuse doğrulanabilir, ardından yapılandırma ve yönetim süreci incelenebilir.

AD CS misconfiguration

Active Directory Certificate Services, authentication ve certificate enrollment için güçlü bir bileşendir. Fakat template permission, subject alternative name, enrollment agent, web enrollment ve mapping ayarları yanlışsa düşük yetkili kullanıcı daha yüksek privilege taşıyan certificate elde edebilir.

İç ağ testinde yalnızca certificate template inventory çıkarılmamalıdır. Exploit path için gerekli permission, enrollment condition, issuance requirement ve hedef privilege birlikte değerlendirilmelidir.

Paylaşımlarda secret ve sensitive data

Network share'ler yıllar içinde backup, script, export, database dump ve employee document biriktirebilir. “Authenticated Users read” gibi geniş permission'lar nedeniyle standard user bu verilere erişebilir.

Raporlama sırasında bulunan personal data ve secret'lar gereksiz yere kopyalanmamalıdır. Minimum proof alınmalı, hassas değerler maskelenmeli ve raporun kendisi restricted artifact olarak yönetilmelidir.

Backup, virtualization ve management plane exposure

Ransomware etkisini büyüten en kritik yollardan biri production workload ile backup veya virtualization management'in aynı identity ve network trust içinde bulunmasıdır.

Şu sorular önemlidir:

• Workstation account'ı backup console'a erişebiliyor mu?
• Backup administrator ile domain administrator credential'ı aynı endpoint'te kullanılıyor mu?
• Hypervisor management user VLAN'dan erişilebilir mi?
• Backup repository immutable mı ve ayrı credential mı kullanıyor?
• Management plane için MFA ve jump host zorunlu mu?
• Recovery account'ları günlük kullanım ortamından ayrılmış mı?

İç ağ testi bu ilişkileri bir attack graph içinde gösterebilir.

İç ağ sızma testi neyi güçlü biçimde gösterir?

İç ağ testinin en değerli kanıtları şunlardır:

• Standard user veya unauthenticated cihazın görebildiği gerçek internal attack surface
• Beklenmeyen network ve application path'leri
• Segmentation bypass
• Credential exposure ve reuse
• Active Directory privilege escalation yolu
• Hybrid identity üzerinden cloud privilege'e geçiş
• Endpoint'ten server'a lateral movement
• User zone'dan management plane'e erişim
• Critical data store'a unauthorized read veya write olasılığı
• Backup ve recovery katmanının compromise ihtimali
• Monitoring tarafından görünmeyen veya yanlış sınıflandırılan saldırı adımları
• Tek bir foothold'un blast radius'u

Bu çıktı, “içeride 500 adet Medium vulnerability var” listesinden daha değerlidir. Çünkü hangi zayıflıkların birleşerek gerçek bir business risk oluşturduğunu gösterir.

İç ağ sızma testi neyi göstermez?

İç ağ testi de kurumun tamamı için eksiksiz kanıt sunmaz.

Doğal sınırlamaları şunlardır:

• İnternetteki unknown ve shadow asset'leri görmeyebilir
• Public edge device ve origin exposure'ı test etmeyebilir
• External reconnaissance bulgularını kapsamayabilir
• Phishing yapılmadıysa initial access olasılığını ölçmez
• Wireless ayrıca scope'a alınmadıysa Wi-Fi attack path'lerini değerlendirmez
• Web uygulamaları yalnızca network service seviyesinde kalabilir
• OT ortamı scope dışıysa IT'den OT'ye geçiş incelenmez
• Cloud tenant scope dışında bırakıldıysa hybrid privilege path yarıda kalır
• EDR veya SOC ölçümü hedeflenmediyse detection capability hakkında kesin sonuç vermez

Özellikle son madde önemlidir. Tester'ın bazı işlemleri güvenlik ekibi tarafından allowlist'e alınmışsa veya SOC testten önceden haberdarsa “hiç alarm oluşmadı” sonucu detection başarısızlığı olarak yorumlanamaz. Monitoring ölçülecekse test tasarımı buna göre yapılmalıdır.

Aynı kurumda iki test neden çok farklı bulgu üretir?

Dış ağ raporunda üç, iç ağ raporunda kırk bulgu çıkması dış ağ testinin yüzeysel olduğu anlamına gelmez. Tersi de geçerlidir. İki testin erişebildiği asset ve protocol sayısı farklıdır.

Örnek 1: İnternete kapalı database, içeride herkese açık

External test database portuna ulaşamaz. Perimeter bu açıdan doğru çalışır. Internal test ise user VLAN'dan aynı database'e erişir ve default veya reused credential ile giriş yapabilir.

Burada dış ağ testinin “bulamaması” eksiklik değildir. Sorun perimeter arkasındaki access model'dedir.

Örnek 2: VPN güçlü, VPN sonrası erişim geniş

VPN MFA ile korunur, account lockout ve device posture etkindir. External test remote access üzerinde bypass bulamaz. Internal test standard VPN user profiliyle başladığında Domain Controller, file share ve management interface'lere gereğinden geniş erişim görür.

Kontrolün ilk yarısı güçlü, ikinci yarısı zayıftır. MFA initial access riskini azaltır, fakat authenticated session'ın blast radius'unu sınırlandırmaz.

Örnek 3: Public web server compromise ve pivot

Dış ağ pentestinde internet-facing application üzerinde Remote Code Execution doğrulanır. Eğer scope entry point'te bitiyorsa bulgu critical impact ile raporlanır, fakat internal pivot denenmez.

Kurum “Bu sunucudan iç ağa geçilebilir mi?” sorusunu da yanıtlamak istiyorsa scope genişletilmelidir. Web server'ın network zone'u, service account'ı, reachable internal host'ları ve egress path'i internal veya hybrid scenario olarak test edilir.

Örnek 4: İç ağ güvenli, public forgotten host açık

Internal network iyi segment edilmiş, credential hygiene güçlü ve privilege path'ler sınırlı olabilir. Buna rağmen farklı cloud account'ta unutulmuş bir Jenkins instance internetten erişilebilir ve weak authentication kullanıyor olabilir.

İç ağ testinin temiz sonucu bu external asset'i kapsamaz.

Örnek 5: Contractor network üzerinden production erişimi

Dış ağdan production management port'ları kapalıdır. Corporate user VLAN'dan da erişim engellidir. Fakat third-party support için açılan contractor segment'inde geniş bir firewall exception bulunur.

İç ağ testi yalnızca corporate VLAN'dan yapılırsa bu path görünmeyebilir. Başlangıç profili ve segment seçimi bu yüzden kritik önemdedir.

Dış ağdan foothold elde edilirse test iç ağa dönüşür mü?

Teknik olarak dış ağ testinde bulunan bir açık internal access sağlayabilir. Ancak tester'ın bu access'i kullanarak içeride ne kadar ilerleyebileceği tamamen Rules of Engagement'e bağlıdır.

Üç yaygın model vardır:

Model 1: Entry point kanıtında durmak

Tester public sistemde code execution veya VPN access elde edildiğini minimum proof ile gösterir. Internal network'e pivot yapmaz. Bu model operational risk'i sınırlar, fakat blast radius hakkında veri üretmez.

Model 2: Sınırlı pivot doğrulaması

Belirli internal target'lara network reachability ve düşük etkili erişim kontrol edilir. Örneğin compromised web server'dan management network'e route olduğu kanıtlanır, fakat lateral exploitation yapılmaz.

Model 3: End-to-end attack path

External initial access'ten başlayarak internal discovery, privilege escalation, lateral movement ve belirlenmiş crown jewel hedefine kadar ilerlenir. Bu yaklaşım klasik dış ağ pentestinden daha geniştir. Objective ve stealth beklentisine göre chained penetration test veya Red Team engagement olarak tasarlanabilir.

“Exploit bulundu, tester zaten devam eder” varsayımı yanlıştır. Scope içinde açık yetki yoksa iç sisteme geçiş yapılmamalıdır. Public asset üzerinden elde edilen shell, kurumun başka sistemlerine yönelik sınırsız test izni anlamına gelmez.

İç ağ testi için doğru başlangıç profili nasıl seçilir?

Tek bir internal foothold bütün tehditleri temsil etmez. Testin değeri, başlangıç profilinin gerçek threat scenario ile uyumuna bağlıdır.

En kritik kurumlarda birden fazla başlangıç profili kullanılabilir. Ancak her profil ayrı efor ve test matrisi oluşturur. Tek başlangıç noktası üzerinden yapılan beş günlük testin bütün branch, cloud ve office segment'lerini temsil edeceği düşünülmemelidir.

Zero Trust dış ve iç ayrımını ortadan kaldırır mı?

Hayır. Zero Trust, network location'a dayanarak implicit trust verilmemesini savunur. NIST SP 800-207 de local network ile internet arasında yalnızca konuma dayalı güven farkı kabul edilmemesi gerektiğini, kullanıcı ve cihaz için authentication ile authorization'ın resource erişiminden önce uygulanmasını vurgular.

Bu yaklaşım “internal pentest gereksiz” sonucunu doğurmaz. Tam tersine şu soruların test edilmesini daha önemli hale getirir:

• Internal network location hâlâ bazı servislerde authentication'ı bypass ediyor mu?
• Device identity olmadan resource erişilebiliyor mu?
• User session başka device'ta reuse edilebiliyor mu?
• Policy engine bütün protocol ve legacy application'ları kapsıyor mu?
• Service account ve machine identity için aynı kontroller uygulanıyor mu?
• Break-glass ve exception path'leri aşırı erişim sağlıyor mu?
• Micro-segmentation policy'si gerçek traffic üzerinde çalışıyor mu?

Zero Trust bir ürün adı veya network diagram etiketi değildir. İç ağ sızma testi, mimarinin network location'dan bağımsız authorization iddiasını runtime'da sınayabilir.

Cloud ve hybrid yapılarda “dış” ile “iç” nasıl tanımlanır?

Cloud ortamında public IP'si olmayan bir workload, internetten doğrudan erişilemiyor olabilir. Fakat ele geçirilmiş SaaS identity veya workload token'ı management API üzerinden bu kaynağa ulaşabilir. Bu durumda klasik IP perimeter yaklaşımı yetersiz kalır.

Scope şu düzlemlerde tanımlanmalıdır:

Public data plane

Internet-facing application, API gateway, load balancer, storage endpoint ve managed service'ler dış ağ kapsamına girer.

Management plane

Cloud console, API, CI/CD integration ve privileged identity üzerinden yapılan işlemler ayrı bir attack surface'tir. Public internetten erişilse bile test, yalnızca port taramasıyla ölçülemez. IAM ve conditional access gerekir.

Private workload network

Virtual network, subnet, peering, private endpoint ve security group ilişkileri internal segmentation mantığıyla incelenir.

Hybrid identity

On-premise Active Directory ile cloud identity arasındaki synchronization, federation ve privileged role yolları internal foothold'un cloud compromise'a dönüşmesini sağlayabilir. Ters yönde cloud account compromise'ı da on-premise resource'lara erişim üretebilir.

Bu nedenle cloud scope'unda “10 public IP dış test, 10 private IP iç test” yaklaşımı yeterli değildir. Identity, control plane ve workload path ayrı ayrı tanımlanmalıdır.

Vulnerability scan ile dış veya iç ağ pentesti aynı şey mi?

Hayır. Scanner geniş bir asset setinde bilinen vulnerability ve configuration sinyallerini hızlı biçimde bulabilir. Penetration test ise bu sinyallerin exploitability'sini, kombinasyonunu ve attack path içindeki yerini değerlendirir.

Bir external scanner raporuna “dış ağ sızma testi”, credentialed internal scan raporuna da “iç ağ sızma testi” adı verilmemelidir. Teklifte manual validation, exploitation, attack path analizi ve retest açıkça yazılmalıdır.

İç ağ sızma testi ile Active Directory Security Assessment aynı mı?

Her zaman değil.

Internal pentest Active Directory'yi attack path'in önemli bir parçası olarak inceler. Ancak tam bir Active Directory Security Assessment daha geniş configuration, architecture, tiering, hardening, delegation, trust, PKI, logging ve operational process review içerebilir.

Farkı şöyle düşünebiliriz:

• Internal pentest: Düşük yetkili foothold'dan exploitable path arar ve etkisini kanıtlar.
• AD assessment: Domain configuration'ın bütünsel güvenlik seviyesini, kullanılmamış fakat riskli ayarları ve architecture gap'lerini daha sistematik inceler.

Örneğin unused ama tehlikeli bir certificate template pentest süresinde attack path'e dönüşmeyebilir. AD assessment bunu yine de configuration risk'i olarak raporlayabilir. Tersine pentest, birkaç küçük permission'ın birleşiminden gerçek bir privilege escalation yolu çıkarabilir.

Kurumun hedefi Domain compromise riskini ayrıntılı anlamaksa scope içinde her iki yaklaşım da tanımlanmalıdır.

Black box, gray box ve white box bu ayrımın neresinde?

Dış ağ ve iç ağ, testin nereden ve hangi foothold ile başladığını anlatır. Black box, gray box ve white box ise tester'a ne kadar bilgi ve erişim verildiğini anlatır. Bunlar farklı eksenlerdir.

Örnekler:

• External black box: Yalnızca kurum adı veya public domain verilir
• External gray box: Public IP listesi ve low-privilege portal account'ı verilir
• External white box: Architecture, edge configuration ve source bilgisi paylaşılır
• Internal black box: Network portu verilir, account verilmez
• Internal gray box: Standard domain user ve scope subnet'leri verilir
• Internal white box: Network diagram, AD design, firewall rule ve admin destek bilgisi verilir

Internal testin account ile başlaması onu otomatik olarak white box yapmaz. Standard user credential'ı verilmesi yalnızca başlangıç senaryosunu tanımlayabilir.

Sızma testi raporları nasıl ayrışmalı?

Dış ve iç ağ raporları aynı vulnerability template'ini kullanabilir, ancak yönetici özeti ve risk hikâyesi aynı olmamalıdır.

Dış ağ raporunda bulunması gerekenler

• Test edilen public IP, FQDN ve cloud asset listesi
• Keşfedilen fakat scope dışında kalan potential asset'ler
• Exposed port, service ve authentication surface
• External entry point'ler
• Request, response ve network evidence
• Exploit için gereken koşullar
• Initial access sonrası elde edilen privilege
• Origin, edge ve remote access ilişkisi
• Internetten doğrulanan business impact
• Third-party boundary ve test limitation'ları
• Remediation ve external retest sonucu

İç ağ raporunda bulunması gerekenler

• Başlangıç segment'i, host'u, identity'si ve verilen credential
• Scope içindeki domain, forest, subnet, cloud tenant ve zone'lar
• Network reachability ve segmentation sonucu
• Discovery'den crown jewel'e attack path
• Her adımda kullanılan permission veya weakness
• Elde edilen credential türü ve güvenli işleme yöntemi
• Privilege escalation ve lateral movement kanıtı
• Etkilenen business asset
• Blast radius
• Detection ve response gözlemleri, eğer objective içindeyse
• Credential rotation ve cleanup kaydı
• Remediation dependency'leri ve retest sonucu

Attack path raporu neden önemlidir?

İç ağda beş ayrı Medium finding, birlikte kritik bir compromise yolu oluşturabilir:

1. 1Standard user geniş bir deployment share'ini okuyabiliyor.
2. 2Share içinde service account credential'ı bulunuyor.
3. 3Service account bir management server'da local admin.
4. 4Management server production backup network'üne erişebiliyor.
5. 5Backup console MFA istemiyor ve aynı account'ı kabul ediyor.

Bu bulgular ayrı ayrı ele alındığında öncelik kaybedebilir. Attack path olarak raporlandığında tek foothold'un recovery altyapısını etkileyebildiği anlaşılır.

İyi rapor hem zinciri hem zincirin her halkasını gösterir. Böylece kurum en kısa remediation ile attack path'i nerede kırabileceğini seçebilir.

Severity iki testte neden farklı değerlendirilir?

Aynı service vulnerability'si dış ağda Critical, iç ağda High olabilir. Ya da internal finding daha yüksek risk taşıyabilir. Severity yalnızca CVE veya CVSS base score ile belirlenmemelidir.

Şu context faktörleri önemlidir:

• Vulnerability internetten unauthenticated erişilebilir mi?
• Internal foothold için phishing, VPN veya physical access gerekiyor mu?
• Hedef asset hangi data classification'a sahip?
• Account privilege'i ne?
• Segmentation attack path'i sınırlandırıyor mu?
• Exploit birden fazla host'ta tekrar edilebiliyor mu?
• Elde edilen erişim başka critical system'e geçiş sağlıyor mu?
• Monitoring ve containment imkânı var mı?
• Compensating control ne kadar güvenilir?
• Attack complexity ve required user interaction ne?

Örneğin internetten erişilen unauthenticated RCE yüksek initial access riski taşır. Aynı RCE yalnızca izole bir internal lab segment'inde standard user erişimiyle kullanılabiliyorsa exposure farklıdır. Buna karşılık internal management server'daki düşük karmaşıklıklı credential exposure bütün backup altyapısını etkiliyorsa business impact daha yüksek olabilir.

Scope nasıl yazılmalı?

Kaliteli test, net scope ile başlar. “Dış IP'ler” veya “iç ağ” gibi iki kelimelik tanımlar yeterli değildir.

Dış ağ scope checklist'i

• Public IP ve CIDR listesi
• Primary ve secondary domain'ler
• FQDN ve known subdomain listesi
• Cloud account ve region bilgisi
• CDN, WAF, DDoS protection ve reverse proxy yapısı
• Origin IP test izni
• VPN ve remote access gateway'leri
• Public web application ve API'lerin ayrı test derinliği
• Third-party hosted asset'ler
• Test edilmeyecek service ve fragile system'ler
• Source IP allowlist gereksinimi
• Rate limit ve account lockout sınırları
• DDoS, social engineering ve phishing kapsamı
• Production exploitation seviyesi
• Discovered asset authorization süreci

İç ağ scope checklist'i

• Başlangıç lokasyonu ve network segment'i
• Verilecek cihaz veya virtual machine
• Standard user ve service account profilleri
• Domain ve forest listesi
• Internal subnet, VLAN ve site listesi
• Branch office ve third-party network'leri
• Cloud tenant, virtual network ve hybrid identity kapsamı
• Active Directory ve AD CS kapsamı
• NAC, VPN ve ZTNA senaryoları
• Segmentation hedefleri
• Crown jewel listesi
• OT, medical, IoT ve fragile system exclusion'ları
• Credential access ve password cracking sınırları
• Lateral movement için izin verilen protokoller
• EDR bypass veya payload kullanım izni
• Data exfiltration simulation sınırı
• Cleanup ve credential rotation yöntemi

Scope yalnızca hedef listesini değil, başlangıç güven seviyesini de yazmalıdır. “Internal test standard domain user ile başlayacak” ifadesi olmadan rapordaki attack path doğru yorumlanamaz.

Rules of Engagement neden daha da önemlidir?

Network pentest üretim sistemlerini etkileyebilir. Port scan, authentication denemesi, exploit, service restart, account lockout ve endpoint security tepkisi operasyonel risk oluşturur.

Rules of Engagement en az şu başlıkları kapsamalıdır:

• Yetkili test tarihleri ve saatleri
• Tester source IP ve kullanılan altyapı
• 7/24 acil iletişim kişileri
• Stop condition ve kill switch
• Test dışı asset ve third-party'ler
• DoS ve resource exhaustion yasağı
• Password spraying hız sınırı
• Account lockout koordinasyonu
• Production data'ya dokunma sınırı
• Credential capture ve storage yöntemi
• Malware veya custom payload kullanımı
• EDR quarantine durumunda izlenecek yol
• Lateral movement ve persistence sınırı
• Data exfiltration için izin verilen proof boyutu
• Cloud provider acceptable use şartları
• Log ve evidence retention süresi
• Test sonunda cleanup ve access removal

Bir bulgunun teknik olarak yapılabilir olması, test sırasında güvenli olduğu anlamına gelmez. Domain Controller üzerinde exploit çalıştırmak yerine vulnerable condition ve attack path daha düşük etkili kanıtla doğrulanabilir. Production backup silme yetkisi elde edildiğinde gerçek backup silinmez. Yetkinin varlığı ve güvenli proof yeterlidir.

SOC ve EDR testin parçası mı?

Bu, objective'e bağlıdır.

Standart bir sızma testi vulnerability ve attack path bulmaya odaklanır. Tester stealth için özel efor harcamayabilir. SOC önceden bilgilendirilebilir, scanner source IP'leri allowlist'e alınabilir veya EDR'ın testi engellememesi için koordinasyon yapılabilir.

Detection ve response ölçülecekse farklı bir tasarım gerekir:

• SOC testten ne ölçüde haberdar olacak?
• White cell kim olacak?
• Hangi activity alarm üretmesi bekleniyor?
• Alert, triage ve escalation süreleri nasıl ölçülecek?
• Tester engellendiğinde test devam edecek mi?
• EDR bypass açık bir objective mi?
• Incident response ekibi gerçek containment uygulayacak mı?

Bu çalışma pentest, Purple Team veya Red Team formatında tasarlanabilir. “İç ağ testi sırasında SOC bizi yakaladı” tek başına testin başarısız olduğu anlamına gelmez. Aksine kontrol çalışmış olabilir. Ancak tester engellendikten sonra kalan teknik coverage için yeniden koordinasyon gerekebilir.

Dış ve iç ağ testi ne zaman yapılmalı?

Tek bir yıllık takvim bütün kurumlar için yeterli değildir. Test sıklığı risk, değişiklik ve exposure'a göre belirlenmelidir.

Dış ağ testini tetikleyen değişiklikler

• Yeni public IP veya internet-facing service
• Yeni VPN, ZTNA veya SSO entegrasyonu
• Data center veya cloud migration
• WAF, CDN veya reverse proxy değişikliği
• Acquisition sonrası domain ve asset birleşimi
• Major application release
• Public management plane açılması
• Edge device veya firmware değişimi
• Third-party remote access eklenmesi
• Önceki external breach veya credential exposure

İç ağ testini tetikleyen değişiklikler

• Active Directory forest veya domain değişikliği
• Network segmentation projesi
• Yeni branch veya subsidiary bağlantısı
• Cloud ve on-premise peering
• Backup veya virtualization platformu değişimi
• Büyük endpoint migration'ı
• EDR veya NAC deployment'ı
• Privileged Access Management projesi
• Yeni contractor veya vendor network erişimi
• Ransomware olayı veya internal compromise
• Identity synchronization ve federation değişikliği

PCI DSS v4.0.1 gibi bazı standartlar belirli kapsamlar için internal ve external penetration testlerin periyodik ve önemli değişikliklerden sonra yapılmasını ister. Compliance takvimi minimum gereksinim olabilir. Gerçek test programı yalnızca audit tarihine değil, attack surface değişimine bağlanmalıdır.

Hangisi önce yapılmalı?

Çoğu kurum için cevap “ikisi de” olsa da sıra risk profiline göre değişebilir.

İnternette hızla büyüyen attack surface varsa dış ağ önce

Yeni cloud workload'lar, çok sayıda public service, acquisition domain'leri veya remote access altyapısı bulunan kurum önce external exposure'ı doğrulamalıdır. Çünkü initial access doğrudan internetten gelebilir.

Phishing ve credential compromise ana tehditse iç ağ önce

Perimeter güçlü olsa bile employee account compromise'ı makul bir senaryoysa blast radius ölçülmelidir. Özellikle Active Directory, flat network ve legacy protocol içeren yapılarda internal pentest öncelikli olabilir.

Ransomware dayanıklılığı hedefleniyorsa iç ağ ağırlıklı

Ransomware riskinde yalnızca public entry point'e bakmak yeterli değildir. Backup, hypervisor, management plane, privilege tier ve lateral movement yolları incelenmelidir. Initial access için ayrıca external, phishing veya assumed breach scenario eklenebilir.

Yeni bir kurum ilk kez test yaptırıyorsa

Önce attack surface inventory çıkarılır. Ardından external ve internal scope ayrı workstream olarak planlanır. Birini diğerinin yerine seçmek yerine, en kritik varlığa göre efor dağıtılır.

İki test birlikte nasıl planlanmalı?

En güçlü model dış ve iç ağ raporlarını iki bağımsız PDF olarak bırakmaz. Bulguları end-to-end risk hikâyesinde birleştirir.

1. Threat scenario'ları belirleyin

Örneğin:

• İnternet saldırganı VPN üzerinden initial access arıyor
• Phishing ile standard user credential'ı ele geçiriliyor
• Public web server compromise ediliyor
• Contractor laptop internal network'e bağlanıyor
• Cloud workload token'ı sızıyor

Her senaryo için başlangıç noktası ve başarı kriteri tanımlanır.

2. Attack surface ve crown jewel eşlemesi yapın

Public entry point'ler ile korunacak internal asset'ler arasındaki olası path'ler belirlenir. VPN yalnızca dış asset değildir. Başarılı session'ın iç network reachability'si de test modeline dahil edilir.

3. External testi initial access gözüyle yürütün

Public exposure, remote access ve internet-facing application'lar değerlendirilir. Bulunan entry point'lerin hangi network zone ve identity ile çalıştığı kaydedilir.

4. Internal testi birden fazla foothold ile yürütün

Standard user, compromised server veya contractor segment'i gibi en gerçekçi profiller seçilir. Her profile ait attack path ayrı raporlanır.

5. Bulguları zincirleyin

External bulgu internal path ile bağlanabiliyorsa ortak risk kaydı oluşturulur.

Örnek:

Bu zincirin risk değeri, parçaların ayrı ayrı severity'sinden daha yüksektir.

6. Attack path'i en verimli noktadan kırın

Her bulguyu aynı anda kapatmak mümkün olmayabilir. Path üzerinde birden fazla control point bulunur:

• Legacy authentication'ı kapatmak
• VPN MFA enforcement uygulamak
• VPN route kapsamını daraltmak
• Management subnet'e segmentation eklemek
• Share permission'ı düzeltmek
• Service account secret'ını rotate etmek
• Backup console için ayrı identity ve MFA kullanmak
• SOC alert'i eklemek

Kısa vadede path'i kesen kontrol uygulanır. Kök nedenler planlı biçimde giderilir. Ardından external ve internal retest ile zincirin gerçekten kırıldığı doğrulanır.

Retest nasıl yapılmalı?

Retest yalnızca scanner'ı yeniden çalıştırmak değildir. Önceki attack path'in bütün kritik adımları yeniden değerlendirilir.

Dış ağ retestinde

• Asset hâlâ internetten erişilebilir mi?
• Service kapatıldı mı, yoksa yalnızca farklı porta mı taşındı?
• Origin başka hostname veya IP üzerinden hâlâ açık mı?
• MFA bütün authentication path'lerinde uygulanıyor mu?
• Patch gerçek exposed version'a deploy edildi mi?
• Bypass varyasyonları kapandı mı?

İç ağ retestinde

• Başlangıç segment'inden reachability gerçekten kesildi mi?
• IPv4 kapatılırken IPv6 path açık kaldı mı?
• Secret rotate edildi mi ve eski credential geçersiz mi?
• Permission inheritance başka path oluşturuyor mu?
• Aynı local admin password başka host'larda sürüyor mu?
• Attack graph alternatif route üretiyor mu?
• Crown jewel için bağımsız authentication ve MFA uygulanıyor mu?

Bir zincirin tek halkası düzeltilmiş olabilir. Tester alternatif path'i araştırmadan “tamamen kapandı” sonucu vermemelidir.

Satın alma sürecinde sorulması gereken sorular

Hizmet adından çok yöntemi sorgulamak gerekir.

Dış ağ testi için

• Passive ve active attack surface discovery yapılacak mı?
• Yalnızca verilen IP'ler mi, ilişkili asset'ler de araştırılacak mı?
• Bulunan yeni asset'lerin scope'a alınma süreci nasıl işleyecek?
• Scanner bulguları manuel doğrulanacak mı?
• Exploitation hangi seviyeye kadar yapılacak?
• VPN, ZTNA ve SSO akışları dahil mi?
• Web application'lar ne kadar derin test edilecek?
• CDN ve origin exposure incelenecek mi?
• Third-party sınırları nasıl yönetilecek?
• Retest dahil mi?

İç ağ testi için

• Test hangi foothold ve user profile ile başlayacak?
• Unauthenticated ve authenticated senaryolar ayrı mı?
• Active Directory privilege path analizi yapılacak mı?
• AD CS dahil mi?
• Segmentation hangi source ve target zone'lar arasında test edilecek?
• Credential exposure ve reuse kontrollü olarak doğrulanacak mı?
• Lateral movement yapılacak mı?
• Cloud ve hybrid identity kapsamda mı?
• Crown jewel hedefleri önceden belirlenecek mi?
• SOC ve EDR ölçümü amaçlardan biri mi?
• Credential cleanup ve rotation desteği var mı?
• Retest attack path seviyesinde mi yapılacak?

“Otomatik ve manuel test yapılacaktır” cümlesi bu soruların yerine geçmez.

Yaygın yanlış kabuller

“Firewall varsa dış ağ testi yeterlidir”

Firewall yalnızca belirli traffic path'lerini kontrol eder. Phishing, stolen credential, cloud identity, third-party access ve compromised endpoint riskini ortadan kaldırmaz. Internal trust modeli ayrıca test edilmelidir.

“İç ağ zaten güvenilir”

Bir cihazın kurum network'ünde olması onun güvenilir olduğu anlamına gelmez. NIST Zero Trust yaklaşımının temel noktalarından biri de network location'a tek başına trust vermemektir. Internal service'ler authentication, authorization ve least privilege uygulamalıdır.

“Dışarıdan kritik açık çıkmadı, içeride de çıkmaz”

External ve internal attack surface farklıdır. Legacy system'ler ve management protocol'leri genellikle internete kapalıdır, fakat içeride geniş erişime sahip olabilir.

“İç testte Domain Admin olunamadıysa ağ güvenlidir”

Domain Admin tek başarı ölçütü değildir. Customer data, backup, source code, CI/CD veya payment system erişimi daha kritik olabilir. Ayrıca exploit edilmeyen configuration risk'leri ve segmentation açıkları kalabilir.

“Domain Admin olunduysa test tamamdır”

Bu da eksik bir yaklaşımdır. Domain Admin elde edildiğinde business impact, cloud trust, backup isolation ve detection gözlemleri henüz değerlendirilmemiş olabilir. Objective crown jewel üzerinden tanımlanmalıdır.

“Internal vulnerability scan iç ağ pentestidir”

Authenticated scanner patch gap'lerini gösterebilir, fakat credential reuse, privilege graph, lateral movement ve chained attack path'i aynı derinlikte değerlendirmez.

“Pentester'a account vermek gerçekçi değildir”

Threat scenario account compromise kabul ediyorsa standard account vermek tamamen gerçekçidir. Ama rapor verilen erişim ile testte kazanılan erişimi ayırmalıdır. Amaç phishing becerisini değil post-compromise blast radius'u ölçmek olabilir.

“Cloud kullanıyoruz, iç ağımız yok”

Private workload network, identity trust, management plane ve service-to-service authorization yine vardır. Fiziksel LAN küçülmüş olabilir, fakat internal trust problem'i ortadan kalkmaz.

Sonuç: Biri giriş ihtimalini, diğeri yayılma kapasitesini ölçer

Dış ağ ve iç ağ sızma testi arasındaki farklar yalnızca tester'ın firewall'ın hangi tarafında bulunduğuyla açıklanamaz.

Dış ağ sızma testi public attack surface'i, exposed service'leri, remote access katmanını ve internetten initial access olasılığını inceler. İç ağ sızma testi ise bir foothold'un network ve identity trust'i kullanarak ne kadar büyüyebildiğini, hangi segment'lere geçtiğini ve hangi crown jewel'e ulaşabildiğini gösterir.

Kurumun dış ağı güçlü, iç ağı zayıf olabilir. İç ağ iyi segment edilmişken internette forgotten asset bulunabilir. VPN MFA ile korunurken VPN sonrasında bütün server network'ü erişilebilir olabilir. Public web server compromise edilebilir, ancak iyi segmentation sayesinde saldırı orada tutulabilir.

Bu sonuçların her biri farklı bir güvenlik hikâyesidir.

Doğru yaklaşım şudur:

1. 1External initial access ve internal assumed breach senaryolarını ayrı tanımlayın.
2. 2Public attack surface ile crown jewel envanterini ilişkilendirin.
3. 3Dış ağ testinde internetten gerçek exposure'ı doğrulayın.
4. 4İç ağ testinde birden fazla gerçekçi foothold'un blast radius'unu ölçün.
5. 5Network location'a implicit trust verilip verilmediğini sınayın.
6. 6Bulguları tek tek değil attack path olarak değerlendirin.
7. 7Remediation sonrası hem entry point'i hem internal path'i yeniden test edin.

Secnodex, dış ağ ve iç ağ sızma testi çalışmalarını ayrı scanner çıktıları olarak değil, internetten başlayan ve kritik varlıklara uzanabilecek attack path'lerin iki farklı bölümü olarak ele alır. Kurumunuzun public exposure'ını, internal lateral movement riskini ve segmentation kontrollerini gerçekçi senaryolarla değerlendirmek için Secnodex ile iletişime geçebilirsiniz.

Kaynaklar

• NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
• NIST SP 800-207: Zero Trust Architecture
• MITRE ATT&CK: Network Service Discovery, T1046
• MITRE ATT&CK: Valid Accounts, T1078
• MITRE ATT&CK: Remote Services, T1021
• MITRE ATT&CK: Lateral Movement, TA0008
• PCI Security Standards Council: PCI DSS v4.0.1 Document Library
• PCI Security Standards Council: Penetration Testing Guidance