Her Kurumun Red Team'e İhtiyacı Var mı?

Bir yönetim toplantısında şu cümle kuruluyor:

Security ekibi bütçe talebini hazırlıyor. Scope olarak bütün dış IP'ler, Active Directory ve kritik uygulamalar yazılıyor. Operasyonun hedefi ise belirsiz kalıyor. SOC hangi log source'ları izlediğini tam bilmiyor. Son pentest bulgularının önemli bir kısmı kapanmamış. Incident response planı dokümanda var fakat hiç denenmemiş. Kurumda kimlerin testi bileceği, production üzerinde hangi action'ların yasak olduğu ve kritik bir kesinti halinde kimin operasyonu durduracağı tanımlanmamış.

Böyle bir ortamda Red Team yapılabilir. Hatta Red Team büyük olasılıkla bir attack path de bulur. Fakat kurum, pahalı ve operasyonel riski yüksek bir çalışmadan alabileceği değerin önemli bölümünü kaybeder. Çünkü sonuç zaten bilinen bir gerçeği tekrar eder:

Bu nedenle her kurumun Red Team'e ihtiyacı var mı sorusunun dürüst cevabı şudur:

Red Team bir prestij satın alımı değildir. “Biz de yaptırdık” denecek bir audit maddesi de değildir. Kurumun gerçek bir saldırgan karşısında yalnızca ne kadar dayanabildiğini değil, saldırıyı görüp göremediğini, doğru karar verip vermediğini, saldırganı sınırlandırıp sınırlandıramadığını ve kritik işlevlerini sürdürüp sürdüremediğini ölçen kontrollü bir güvenlik operasyonudur.

Doğru zamanda yapıldığında güvenlik programının yıllardır göremediği varsayımları kırar. Yanlış zamanda yapıldığında ise bilinen zafiyetleri daha uzun bir attack story içinde tekrar raporlayan, Blue Team'in capability'sini ölçemeyen ve remediation backlog'una yeni maddeler ekleyen pahalı bir pentest'e dönüşür.

Bu yazıda hangi kurumların Red Team'e gerçekten ihtiyaç duyduğunu, hangi kurumların önce başka güvenlik çalışmalarına yatırım yapması gerektiğini ve readiness kararının hangi ölçülebilir kriterlerle verilebileceğini inceleyeceğiz.

Red Team gerçekte neyi test eder?

NIST, Red Team exercise kavramını gerçek dünya koşullarını yansıtan, organizasyonun mission veya business process'lerini compromise etmeye yönelik simulated adversarial attempt olarak tanımlar. Bu tanımda iki ayrıntı önemlidir:

1. 1Test edilen şey yalnızca bir sistem değildir.
2. 2Amaç yalnızca vulnerability bulmak değildir.

Klasik bir pentest belirli scope içindeki teknik zafiyetleri tespit etmeye ve mümkün olduğunda kontrollü biçimde doğrulamaya odaklanır. Red Team ise gerçek bir threat actor'ın hedefini, hareket biçimini ve operasyonel yaklaşımını modelleyerek birden fazla güvenlik katmanını birlikte sınar.

Bu katmanlar şunları içerebilir:

• Internet-facing attack surface
• E-mail ve identity controls
• Endpoint security
• Active Directory ve cloud identity
• Network segmentation
• Application ve API security
• Privileged access management
• Logging ve telemetry coverage
• SOC detection logic
• Alert triage
• Incident escalation
• Containment ve eradication
• Crisis communication
• Business continuity ve recovery
• İnsan, süreç ve teknoloji arasındaki handoff'lar

Red Team'in hedefi “domain admin olmak” şeklinde yazıldığında çalışma gereğinden dar tanımlanmış olur. Domain Admin bazı ortamlarda anlamlı bir technical objective olabilir. Asıl business objective ise örneğin ödeme talimatını değiştirmek, kritik üretim planına erişmek, customer data export etmek, backup recovery capability'sini etkisiz hale getirmek veya kurumun merkezi identity altyapısı üzerinden belirli bir işlevi durdurmak olabilir.

Bir Red Team operasyonunu pentest'ten ayıran temel nokta yalnızca kullanılan tekniklerin ileri seviye olması değildir. Fark, testin objective-based, threat-led ve end-to-end olmasıdır.

Bu ayrımı ayrıntılı olarak ele aldığımız Red Team ile sızma testi arasındaki fark gerçekten nerede başlar? yazımızı da inceleyebilirsiniz.

Red Team'in değeri hangi soruya cevap verdiğinde ortaya çıkar?

Red Team talebinden önce kurum tek cümlelik bir test sorusu yazabilmelidir. Örneğin:

Bu soru aşağıdaki belirsizlikleri aynı anda görünür hale getirir:

• Hangi threat actor veya capability seviyesi modelleniyor?
• Initial access hangi attack surface üzerinden aranıyor?
• Hangi critical function korunuyor?
• Başarı yalnızca Red Team'in erişimiyle mi ölçülüyor?
• Blue Team'in detection ve response performansı da değerlendiriliyor mu?
• Test production gerçekliğini ne ölçüde kapsıyor?

“Sistemlerimiz güvenli mi?” Red Team için kullanılabilir bir objective değildir. Güvenlik binary bir sonuç değildir. Aynı şekilde “bütün açıkları bulun” talebi de Red Team mantığıyla uyumlu değildir. Stealth ve objective önceliği nedeniyle Red Team, scope içindeki bütün host ve application'ları exhaustive biçimde test etmeyebilir.

Red Team şu tür sorulara daha iyi cevap verir:

• Mevcut security stack gerçek bir attack chain'i hangi aşamada kesiyor?
• SOC, imza veya bilinen malware olmadan çalışan davranışı görebiliyor mu?
• Cloud identity ile on-premises identity arasındaki trust kötüye kullanılabiliyor mu?
• Bir low-privilege foothold kritik business objective'e dönüştürülebiliyor mu?
• Segmentasyon kâğıt üzerinde mi, runtime'da da etkili mi?
• Alert doğru oluşsa bile triage ve escalation zinciri çalışıyor mu?
• Incident response ekibi saldırganın gerçek scope'unu belirleyebiliyor mu?
• Bir containment kararı business owner ile yeterince hızlı alınabiliyor mu?
• Backup var olsa bile attacker access sonrasında güvenli recovery yapılabiliyor mu?

Kurum bu sorulardan hiçbirini sormaya hazır değilse önce test objective'ini ve threat model'ini olgunlaştırmalıdır.

Her kurum neden aynı anda Red Team'e hazır değildir?

Red Team yüksek seviyede security maturity gerektiren bir ödül değildir. Fakat anlamlı ölçüm yapabilmek için ölçülecek bir capability bulunmalıdır.

Bir kurumda merkezi log yönetimi yoksa Red Team sonunda “aktivitenin büyük bölümü görülmedi” sonucuna ulaşmak şaşırtıcı değildir. Incident response owner'ı tanımlı değilse escalation süresini ölçmek anlamsızlaşır. Kritik varlıklar bilinmiyorsa Red Team objective'i rastgele seçilir. Açık ve bilinen external vulnerability'ler aylardır kapatılmıyorsa stealthy adversary emulation yerine önce temel attack surface azaltılmalıdır.

Bu, düşük maturity seviyesindeki kurumun güvenlik testine ihtiyacı olmadığı anlamına gelmez. Tam tersine test ihtiyacı yüksektir. Yalnızca en yüksek yatırım getirisi sağlayan test türü farklıdır.

Red Team bir başlangıç kontrolü değildir

Yeni kurulmuş bir security program için ilk ihtiyaçlar genellikle şunlardır:

• Asset inventory
• External attack surface discovery
• Secure configuration baseline
• Vulnerability management
• Patch ve remediation ownership
• Identity hygiene
• MFA coverage
• Privileged account kontrolü
• Backup ve recovery doğrulaması
• Merkezi logging
• Temel incident response planı
• Kritik application ve network pentest'leri

Bu temellerin hiçbirinin kusursuz olması gerekmez. Fakat kurum en azından neyi koruduğunu, kritik risklerin owner'ını ve doğrulanmış bulguları nasıl kapatacağını bilmelidir.

Red Team mevcut capability'yi sınar

Red Team değerini şu karşılaştırmadan üretir:

Kurumun beklenen davranışı tanımlı değilse gap de ölçülemez. Örneğin bir credential dumping davranışında EDR'ın process'i block etmesi mi, SOC'a alert göndermesi mi, host'u isolate etmesi mi bekleniyor? Bu beklenti bilinmiyorsa “başarılı” veya “başarısız” değerlendirmesi yalnızca ürün ekranına bakılarak yapılamaz.

Red Team remediation kapasitesi ister

Red Team çıktıları çoğu zaman tek bir CVE veya configuration item değildir. Aşağıdaki gibi zincirler ortaya çıkabilir:

1. 1Unmanaged subdomain üzerinden initial access
2. 2Local credential reuse ile workstation access
3. 3Eksik endpoint telemetry nedeniyle görünmeden discovery
4. 4Service account delegation hatasıyla lateral movement
5. 5Flat management network üzerinden backup console access
6. 6Zayıf approval süreciyle privileged action

Bu zinciri kapatmak DNS ownership, IT operations, identity, endpoint, network, SOC, application ve business owner ekiplerinin birlikte çalışmasını gerektirir. Kurumun systemic remediation yapacak owner ve bütçesi yoksa rapor hızla eskir.

Şirket büyüklüğü Red Team ihtiyacını belirler mi?

Hayır. Çalışan sayısı veya ciro tek başına doğru gösterge değildir.

Elli kişilik bir SaaS şirketi binlerce müşterinin production credential'larını, source code'unu veya finansal verisini işliyorsa çok yüksek concentration risk taşıyabilir. Bu kurumun identity, CI/CD, cloud control plane ve tenant isolation attack path'lerini test etmesi kritik olabilir.

Buna karşılık binlerce çalışanı olan büyük bir kurum, temel asset inventory ve vulnerability remediation süreçlerinde ciddi eksiklere sahipse tam kapsamlı covert Red Team'den önce daha doğrudan testlere ihtiyaç duyabilir.

Red Team ihtiyacını belirleyen asıl faktörler şunlardır:

• Korunan business function'ın kritikliği
• Data sensitivity ve concentration
• Dijital hizmete bağımlılık
• Threat actor ilgisi
• Attack surface karmaşıklığı
• Identity ve trust relationship sayısı
• Third-party ve supply chain bağımlılığı
• Mevcut control investment
• Detection ve response capability'si
• Regülasyon ve contractual requirements
• Bir compromise olayının safety, financial ve reputational etkisi
• Kurumun remediation kapasitesi

Bu nedenle “KOBİ'lerin Red Team'e ihtiyacı yoktur” ifadesi de “büyük şirketlerin mutlaka her yıl Red Team yaptırması gerekir” ifadesi de doğru değildir.

Red Team, pentest, Purple Team ve tabletop exercise nasıl ayrılır?

Kurumların yanlış test satın almasının temel nedeni, farklı güvenlik çalışmalarının aynı soruya cevap verdiğini düşünmesidir.

Bu yöntemler birbirinin rakibi değildir. Olgun bir security assurance programında farklı zamanlarda ve farklı sorular için birlikte kullanılırlar.

Pentest ne zaman daha doğru seçimdir?

Kurumun asıl sorusu “Yeni customer portal'ındaki authentication ve authorization zafiyetleri neler?” ise web application pentest gerekir. “Internal network'te hangi misconfiguration'lar lateral movement sağlıyor?” sorusu için iç ağ sızma testi daha doğrudan ve geniş coverage sağlayabilir.

Red Team stealth amacıyla belirli bir application'ı yalnızca attack path üzerinde gerektiği kadar test edebilir. Bu nedenle uygulamadaki bütün zafiyet sınıflarını bulmasını beklemek yanlıştır.

Test türlerinin zamanlaması için Sızma testi ne zaman yaptırılmalı? Yayına çıkmadan önce mi, olay sonrası mı? rehberimize bakabilirsiniz.

Purple Team ne zaman daha doğru seçimdir?

SOC yeni kurulmuşsa, telemetry coverage bilinmiyorsa veya ekip MITRE ATT&CK technique'lerine karşı detection geliştirmek istiyorsa Purple Team daha hızlı öğrenme sağlayabilir. Red Team stealth'i korumaya çalışırken Blue Team ile anlık bilgi paylaşmaz. Purple Team ise her action sonrasında şu soruları birlikte inceler:

• Endpoint'te hangi artifact oluştu?
• Hangi log source bu davranışı kaydetti?
• SIEM'e doğru field'lar geldi mi?
• Detection rule neden alert üretmedi?
• Alert oluştuysa analyst doğru severity verdi mi?
• Query farklı tool veya living-off-the-land tekniğini de yakalıyor mu?
• Response playbook hangi noktada yetersiz kaldı?

Blue Team'in temel visibility'si henüz kuruluyorsa covert exercise yerine bu ortak çalışma daha yüksek dönüş sağlayabilir.

Tabletop exercise ne zaman daha doğru seçimdir?

Kurumun teknik control'lerinden çok crisis decision yapısı belirsizse production üzerinde attack simulation başlatmak gerekmez. Ransomware, cloud outage, data disclosure veya privileged insider senaryosu üzerinden tabletop exercise uygulanabilir.

Legal, privacy, communication, executive management, IT operations ve business owner'ların aynı olay karşısında nasıl karar verdiği görülür. Teknik izolasyon kararının üretimi durdurması halinde authority kimde, customer communication ne zaman başlar ve recovery priority nasıl seçilir gibi sorular test edilir.

Red Team readiness nasıl ölçülür?

Readiness “kurumda EDR ve SIEM var mı?” sorusundan ibaret değildir. Ürün sahibi olmak ile ürünü güvenlik sonucuna dönüştürmek farklıdır.

Aşağıdaki readiness alanları tam kapsamlı bir operasyon öncesinde değerlendirilmelidir.

1. Critical business function ve crown jewel tanımlı mı?

Red Team'in neyi korumaya çalıştığı bilinmelidir. Kritik varlık listesi yalnızca server isimlerinden oluşmamalıdır. Business function, ilgili data, identity dependency, upstream ve downstream service'ler birlikte haritalanmalıdır.

Örneğin “ERP kritik” demek yeterli değildir. Kritik objective, belirli bir vendor payment instruction'ını değiştirmek veya financial close process'ini durdurmak olabilir. Bu objective'e ulaşmak için ERP dışında e-mail, identity provider, integration account, file share ve approval workflow da önemli hale gelebilir.

Hazır olma işaretleri:

• Business owner bellidir
• Kabul edilemez impact tanımlıdır
• Supporting system ve identity'ler bilinmektedir
• Recovery priority belirlenmiştir
• Test objective'i business language ile yazılabilmektedir

2. Asset inventory ve attack surface yeterince biliniyor mu?

Red Team elbette bilinmeyen varlıkları keşfedebilir. Fakat kurum kendi scope boundary'sini bilmiyorsa testin yasal ve operasyonel sınırı güvenle çizilemez.

Third-party managed IP, acquired domain, forgotten VPN gateway, cloud subscription ve SaaS tenant ownership'i net olmalıdır. Aksi halde tester kuruma ait sanılan fakat başka müşterileri de barındıran bir service'e dokunabilir.

Asset inventory'nin yüzde yüz kusursuz olması beklenmez. Zaten external reconnaissance, kurumun görünmeyen attack surface'ini ölçmek için değerlidir. Ancak Control Team ownership doğrulaması yapabilecek kişilere ve sürece sahip olmalıdır.

3. Temel vulnerability management çalışıyor mu?

Internet-facing sistemde bilinen critical vulnerability aylarca açık kalıyorsa Red Team'in özel bir zero-day veya gelişmiş evasion tekniği kullanmasına gerek kalmaz. Bu sonuç gerçekçi olabilir, fakat çoğu zaman kurumun cevaplamak istediği ileri seviye resilience sorusunu ölçmez.

Şu göstergeler aranabilir:

• Critical exposure için tanımlı SLA
• Internet-facing asset'ler için düzenli discovery
• False positive dışındaki bulgulara atanmış owner
• Patch uygulanamayan sistemler için compensating control
• Exception'ların süreli ve onaylı olması
• Retest ile closure doğrulaması
• Aynı root cause'un tekrar oranının izlenmesi

Red Team'den önce bütün zafiyetlerin kapanması gerekmez. Fakat bilinen açıkların neden açık kaldığı ve riskin kim tarafından kabul edildiği bilinmelidir.

4. Pentest bulguları gerçekten kapatılıyor mu?

Son iki yıldaki pentest raporları remediation bekliyorsa yeni ve daha karmaşık bir rapor satın almak faydayı artırmaz. Özellikle default credential, flat network, excessive privilege, MFA gap ve internet-facing management interface gibi temel bulgular tekrar ediyorsa önce bunlar ele alınmalıdır.

Closure yalnızca ticket'ın kapatılması değildir. Fix implementation doğrulanmalı, benzer asset'ler aranmalı ve mümkünse regression control eklenmelidir.

5. Identity baseline yeterli mi?

Modern attack path'lerin önemli bölümü identity üzerinden ilerler. Red Team readiness değerlendirmesinde en az şu alanlar incelenmelidir:

• Privileged account inventory
• MFA coverage ve bypass path'leri
• Dormant ve ownerless account'lar
• Service account yönetimi
• Local admin dağılımı
• Credential reuse
• Active Directory delegation
• Cloud role assignment
• Conditional access
• Break-glass account kontrolü
• Joiner, mover ve leaver süreçleri
• Third-party access

Bu alanlardaki her eksiklik operasyonu engellemez. Fakat bütün yollar açık ve ölçümsüzse Red Team kısa sürede beklenen sonuca ulaşır, detection ve response zincirini yeterince sınayamaz.

6. Telemetry ve log retention yeterli mi?

Blue Team'in Red Team davranışını görebilmesi için olayın izi toplanmalıdır. Endpoint, identity, DNS, proxy, firewall, VPN, cloud control plane, e-mail, application ve critical database log'larının kullanım senaryosuna göre erişilebilir olması gerekir.

Yalnızca log'un üretilmesi yetmez. Şunlar da önemlidir:

• Log SIEM'e zamanında geliyor mu?
• Timestamp ve timezone tutarlı mı?
• User, host, session ve process correlation yapılabiliyor mu?
• Gerekli field'lar parse ediliyor mu?
• Retention attack timeline'ını kapsıyor mu?
• Analyst raw log'a erişebiliyor mu?
• High-volume source maliyet nedeniyle filtrelenmiş mi?
• EDR tamper ve sensor health izleniyor mu?

Telemetry yokluğu da bir bulgudur. Fakat bütün operation boyunca hiçbir action'ın incelenememesi, öğrenme değerini ciddi biçimde düşürür.

7. SOC veya detection owner'ı var mı?

Kurumun 7/24 internal SOC kurması şart değildir. Managed SOC, MSSP veya mesai saatleri içinde çalışan internal security team de modele uygun olabilir. Önemli olan alert'i kimin göreceği, doğrulayacağı ve escalation başlatacağıdır.

Şu sorular cevapsızsa readiness düşüktür:

• Alert ilk olarak kime düşer?
• Triage için hangi context erişilebilir?
• False positive kararı kim tarafından verilir?
• Severity nasıl yükseltilir?
• Endpoint isolation yetkisi kimdedir?
• Identity disable işlemi için approval gerekir mi?
• MSSP ile kurum arasındaki handoff nasıl çalışır?
• Mesai dışı kritik olay kime iletilir?

Red Team yalnızca detection rule'u değil insan ve süreç latency'sini de test eder.

8. Incident response planı çalıştırılabilir mi?

Dokümanda incident response planı bulunması yeterli değildir. Contact list güncel olmalı, role'ler bilinmeli ve en azından tabletop veya teknik simulation ile denenmiş olmalıdır.

Red Team sırasında Blue Team testi gerçek incident sanabilir. Bu zaten birçok covert operation'ın tasarımının parçasıdır. Fakat gerçek saldırı ile test aynı anda gerçekleşirse ayrımı yapacak Control Team ve güvenli communication channel bulunmalıdır.

9. Control Team operasyonu güvenle yönetebilir mi?

Control Team, operasyonu bilen sınırlı kurum ekibidir. Scope, risk, legal authorization, deconfliction ve emergency stop sorumluluklarını taşır.

İyi bir Control Team şunları yapabilmelidir:

• Test ownership'ini doğrulamak
• Rules of Engagement'i onaylamak
• Critical business takvimini paylaşmak
• Gerçek incident ile test aktivitesini ayrıştırmak
• Third-party sınırlarını yönetmek
• Production riskini değerlendirmek
• Gerektiğinde pause veya stop kararı vermek
• Evidence handling ve disclosure sürecini kontrol etmek

Operasyonu kurumda onlarca kişiye duyurmak realism'i bozar. Tek bir kişiye bırakmak ise safety ve availability riski oluşturur.

10. Remediation owner ve bütçesi var mı?

Red Team raporunun gerçek değeri operation bittikten sonra üretilir. Her attack path için yalnızca teknik fix değil, systemic remediation planı gerekir.

Örneğin Red Team dormant service account ile ilerlediyse yalnızca o account'u disable etmek yeterli değildir. Account lifecycle, ownership, credential rotation, dependency discovery ve monitoring birlikte düzeltilmelidir.

Kurumda findings'i kabul edecek, önceliklendirecek, ilgili ekiplere dağıtacak ve retest planlayacak sponsor bulunmalıdır.

11. Threat model operation'a yön verebiliyor mu?

Threat-led çalışma, internetten rastgele APT raporu seçmek değildir. Kurumun sektörü, coğrafyası, teknoloji stack'i, data'sı, tedarik zinciri ve geçmiş incident'ları değerlendirilmelidir.

Threat Intelligence şu çıktıları üretmelidir:

• Kuruma ilgi gösterebilecek threat actor profilleri
• Olası motivation ve objective'ler
• Relevant TTP'ler
• Realistic initial access vector'leri
• Kuruma özgü attack surface bilgisi
• Critical function'larla bağlantılı senaryolar
• Test için uygulanabilir ve güvenli emulation seçenekleri

MITRE ATT&CK bir checklist gibi bütün technique'leri çalıştırmak için değil, adversary behavior'ı ortak bir dilde modellemek için kullanılmalıdır.

12. Yönetim testin gerçek amacını kabul ediyor mu?

Yönetim yalnızca “başarısız olmayacağımız” bir test istiyorsa Red Team doğru araç değildir. Aynı şekilde operasyonun amacı security ekibini suçlamak veya belirli bir ürün yatırımını haklı çıkarmak olmamalıdır.

Leadership şu gerçekleri kabul etmelidir:

• Red Team objective'e ulaşabilir
• Blue Team bazı action'ları göremeyebilir
• Mevcut ürünler beklenen sonucu üretmeyebilir
• Business process technical control'ü bypass edebilir
• Sonuç pass veya fail değildir
• Findings remediation için ekipler arası yatırım gerektirebilir

Olgun yaklaşım başarısızlığı saklamak değil, gerçek saldırgan gelmeden kontrollü ortamda öğrenmektir.

Hangi kurumlar Red Team'i şimdi değerlendirmeli?

Readiness tek başına yeterli değildir. Kurumun adversarial exercise ile azaltabileceği anlamlı bir riski de bulunmalıdır. Aşağıdaki işaretlerden birkaçı birlikte görülüyorsa Red Team yatırımı güçlü bir aday haline gelir.

Kritik işlevler doğrudan dijital sistemlere bağlıysa

Üretim, ödeme, sağlık hizmeti, lojistik, e-commerce, energy operation veya customer-facing platform uzun süre durduğunda ciddi business impact oluşuyorsa teknik compromise doğrudan kurumsal krize dönüşebilir.

Bu kurumlar yalnızca vulnerability var mı sorusunu değil, bir saldırganın kritik işlevi gerçekten etkileyip etkileyemeyeceğini sınamalıdır. Test objective'i availability üzerinde riskli action gerektiriyorsa simulation veya proof boundary önceden belirlenebilir. Production'a zarar vermek Red Team'in başarı koşulu değildir.

Kurum yüksek değerli veya yoğunlaşmış data işliyorsa

Financial record, health data, intellectual property, source code, authentication secret, customer tenant data veya strategic document gibi varlıkların tek platformda yoğunlaşması attacker motivation'ını artırabilir.

Özellikle multi-tenant service sağlayıcılarında tek bir cloud role veya CI/CD compromise yüzlerce müşteriye erişim sağlayabilir. Çalışan sayısı az olsa bile blast radius büyüktür.

Security control yatırımı yüksek, etkinliği belirsizse

Kurum EDR, NDR, SIEM, SOAR, PAM, e-mail security ve managed SOC için ciddi bütçe ayırmış olabilir. Dashboard'ların yeşil olması attack chain'in durdurulduğunu kanıtlamaz.

Red Team şu investment validation sorusuna cevap verebilir:

Bu durumda amaç ürünü test etmekten çok ürün, process ve analyst bileşiminin güvenlik sonucunu test etmektir.

Pentest sonuçları tekrarlanabilir biçimde iyi, sistemik risk hâlâ belirsizse

Application ve network pentest'leri düzenli yapılıyor, critical bulgular kapatılıyor ve baseline controls çalışıyorsa bir sonraki soru doğal olarak değişir:

Red Team tam olarak bu boşluğu inceler. Low-severity görünen bir information disclosure, yanlış cloud permission ve zayıf help desk verification süreci zincirlendiğinde high-impact objective'e dönüşebilir.

Hybrid ve complex identity ortamı varsa

On-premises Active Directory, Entra ID, multiple cloud, SaaS, VPN, third-party access, M&A ile gelen domain'ler ve farklı privileged access modelleri birlikte çalışıyorsa trust boundary sayısı artar.

Her platform kendi audit'inde doğru görünebilir. Risk platformlar arası geçişte ortaya çıkar. Cloud token'ın on-premises erişime, help desk sürecinin MFA bypass'a veya CI/CD secret'ın production control plane'e dönüşmesi bu sınıfa girer.

SOC gerçek incident görmeden uzun süredir çalışıyorsa

Incident yaşanmamış olması iyi olabilir. Fakat detection ve response capability'sinin gerçekçi pressure altında denenmediği anlamına da gelebilir. Red Team kontrollü bir saldırı akışı sağlayarak analyst'in alert'i araştırma, scope belirleme, escalation ve containment davranışını ölçebilir.

Önemli architecture değişiklikleri yaşandıysa

Cloud migration, identity provider değişikliği, büyük acquisition, yeni remote access modeli, data center consolidation, SOC outsourcing veya network redesign yeni trust relationship'ler oluşturur.

Component-level testler tamamlandıktan sonra end-to-end attack path doğrulaması anlamlı olabilir. Red Team change assurance'ın yerine geçmez, fakat yeni mimarinin attack altında nasıl davrandığını gösterir.

Board ölçülebilir cyber resilience kanıtı istiyorsa

Yönetimin “Kaç vulnerability var?” sorusundan “Kritik işlevimizi hedefleyen saldırıyı ne kadar erken görüyor ve durduruyoruz?” sorusuna geçmesi maturity işaretidir.

Red Team doğru tasarlanırsa board'a teknik exploit listesi yerine şu tür sonuçlar sunabilir:

• Hangi critical function test edildi
• Hangi attack path kontrol edildi
• Hangi katmanda prevention gerçekleşti
• Hangi action'lar detect edildi
• Escalation ve containment ne kadar sürdü
• Hangi systemic gap business risk üretti
• Remediation sonrasında capability nasıl değişti

Regülasyon veya müşteri beklentisi bulunuyorsa

Bazı sektörlerde threat-led penetration testing belirli kurumlar için regulatory requirement olabilir. Avrupa Birliği'nin DORA kapsamındaki TLPT modeli buna örnektir. Ancak burada da “finans sektöründeki her şirket aynı testi yapar” sonucu çıkarılamaz. İlgili otoritenin belirleme kriterleri, kurumun statüsü, jurisdiction ve uygulanabilir teknik standartlar değerlendirilmelidir.

Regülasyon minimum scope'u belirleyebilir. Kurumun amacı yalnızca attestation almak değil gerçek resilience artışı sağlamak olmalıdır.

Hangi kurumlar Red Team'i ertelemeli?

Erteleme, güvenlik testinden vazgeçmek değildir. Bütçeyi önce daha fazla risk azaltacak kontrollere yönlendirmektir.

Internet-facing kritik açıklar zaten biliniyor ve kapanmıyorsa

External attack surface üzerinde unsupported VPN, exposed management panel, default credential veya doğrulanmış RCE varken saldırgan davranışını gizli biçimde modellemek öncelik değildir.

Önce ownership ve remediation blockage çözülmeli, external pentest ile closure doğrulanmalıdır. Aksi halde Red Team operation'ın ilk saatlerinde bilinen yolu kullanır ve yeni bilgi üretmez.

Kurum neye sahip olduğunu bilmiyorsa

Asset inventory'nin ciddi biçimde eksik olduğu, domain ve cloud account ownership'inin bilinmediği ortamda full-scope Red Team safety riski taşır. Önce attack surface management, cloud inventory ve architecture discovery çalışmaları gerekir.

Merkezi telemetry yoksa

Red Team hiçbir şekilde görülmeyecekse kurum yalnızca offensive report alır. Bu rapor yararlı olabilir, fakat aynı sonucu daha düşük risk ve maliyetle pentest sağlayabilir.

Önce critical log source'lar açılabilir, SIEM parsing doğrulanabilir ve Purple Team ile temel detection coverage oluşturulabilir.

Incident response rol ve yetkileri belirsizse

Kimsenin endpoint isolate etme, account disable etme veya business owner'a escalation yapma yetkisi yoksa Red Team response capability'sini değil governance eksikliğini tekrar kanıtlar.

Önce tabletop exercise, contact tree validation ve targeted response simulation daha doğru olur.

Remediation backlog'u yönetilemiyorsa

Security team yeni finding almaktan çok mevcut finding'leri kapatmaya ihtiyaç duyuyorsa Red Team ertelenmelidir. Kapanmayan rapor sayısını artırmak assurance sağlamaz.

Operasyonun tek hedefi sertifika veya yönetim gösterisi ise

“Red Team yaptırdık” logosu, tek sayfalık executive report veya ürün satın alma gerekçesi için operasyon yapılması gerçek değeri düşürür. Test sonucu önceden istenen narrative'e göre şekillendirilecekse bağımsız adversarial assessment yapılamaz.

Rules of Engagement için karar verilemiyorsa

Social engineering serbest mi, production data erişiminde proof nasıl gösterilecek, third-party sistemlere yaklaşım ne olacak, persistence hangi süre tutulabilir, hangi saatlerde riskli action yapılabilir gibi konular karara bağlanamıyorsa operasyon başlamamalıdır.

Kurumunuz için Red Team karar matrisi

Aşağıdaki model formal risk assessment'ın yerine geçmez. Yönetim, security ve IT ekiplerinin aynı readiness fotoğrafı üzerinde konuşmasını sağlar.

Her soruya 0, 1 veya 2 puan verilebilir:

• 0: Yok, bilinmiyor veya çalışmıyor
• 1: Kısmen mevcut, coverage ya da consistency sınırlı
• 2: Tanımlı, uygulanıyor ve evidence ile doğrulanabiliyor

Toplam puan için pratik yorum:

Puan tek başına karar değildir. Bir alandaki 0, toplam yüksek olsa bile blocker olabilir. Örneğin asset ownership doğrulanamıyorsa yasal scope çizilemez. Emergency stop authority yoksa production risk yönetilemez.

Diğer yönde, puanı orta seviyede olan fakat yüksek riskli bir fintech veya critical supplier dar kapsamlı assumed breach ile başlayabilir.

Tam kapsamlı Red Team tek seçenek değildir

Kurumlar çoğu zaman Red Team'i dışarıdan başlayıp Domain Admin ile biten tek bir operation türü olarak düşünür. Oysa objective ve readiness seviyesine göre farklı engagement modelleri uygulanabilir.

Full-scope adversary emulation

External reconnaissance ile başlar. Yetki verilmiş scope içinde gerçekçi initial access, persistence, privilege escalation, lateral movement ve objective action zinciri modellenir. Blue Team genellikle Control Team dışında operation'dan haberdar değildir.

Bu model en yüksek realism'i sağlar. Aynı zamanda en fazla planlama, süre, threat intelligence ve risk control'ü gerektirir.

Assumed breach

Red Team'e önceden tanımlı bir foothold verilir. Örneğin standard user account, managed workstation veya belirli network segment içinde access sağlanır.

Amaç kolay ve bilinen external path'leri tekrar etmek yerine post-compromise capability'yi test etmektir:

• Internal discovery
• Identity escalation
• Segmentation bypass
• Privileged access path
• Detection ve response
• Critical objective'e erişim

External perimeter maturity düşük fakat internal resilience ölçülmek isteniyorsa iyi bir ara model olabilir.

Objective-limited Red Team

Operation tek bir business objective ve sınırlı attack surface etrafında tasarlanır. Örneğin cloud control plane üzerinden customer data export riski veya e-mail compromise sonrasında payment fraud senaryosu test edilir.

Kapsam daraldığı için full-scope operation'a göre daha yönetilebilir olabilir. Yine de objective'e giden zincirde farklı sistem ve ekipleri sınayabilir.

Detection-focused adversary emulation

Amaç erişim kazanmaktan çok threat modeldeki belirli TTP'lere karşı telemetry, analytics ve analyst response'u ölçmektir. Covert phase kısa tutulabilir ve ardından Purple Team'e geçilebilir.

SOC yatırımının etkinliği belirsizse bu model yüksek değer üretir.

Application-centric Red Team

Kritik bir digital platform yalnızca klasik web pentest ile değil, identity, API, business process, cloud, CI/CD ve support workflow ilişkileriyle hedeflenir.

Bu çalışma exhaustive web pentest değildir. Platformu gerçek bir business objective'e ulaşmak için attack ecosystem içinde ele alır.

Cloud ve identity Red Team

Entra ID, AWS IAM, GCP IAM, federation, workload identity, secrets management ve CI/CD trust ilişkilerine odaklanır. Initial foothold assumed breach olarak verilebilir veya authorized external path üzerinden aranabilir.

Cloud environment'ta control plane action'larının blast radius'i yüksek olduğundan proof, cleanup ve provider policy'leri ayrıntılı biçimde tanımlanmalıdır.

Ransomware resilience exercise

Amaç production data'yı gerçekten encrypt etmek değildir. Initial access sonrasında privileged path, security tool tampering, backup erişimi, segmentation, high-value file discovery ve response decision'ları güvenli proof'larla değerlendirilir.

File canary, simulated encryption, pre-approved test share ve recovery tabletop bileşimi kullanılabilir. “Ransomware testi yaptık” diyebilmek için business interruption yaratmak gerekmez.

Red Team senaryosu nasıl seçilmeli?

İyi senaryo hem kuruma özgü hem de uygulanabilir olmalıdır. Sadece popüler bir threat actor adını rapora yazmak threat-led yaklaşım oluşturmaz.

Senaryo seçiminde beş kaynak

1. 1Business impact: Kurum için gerçekten kritik olan confidentiality, integrity veya availability sonucu nedir?
2. 2Threat Intelligence: Hangi actor ve TTP'ler sektör, coğrafya ve technology stack ile ilişkilidir?
3. 3Attack surface: Kurumun gerçek external ve internal exposure'ı hangi yolları mümkün kılar?
4. 4Incident history: Kurumun veya sektörün geçmiş olaylarında hangi access pattern'leri görülmüştür?
5. 5Control uncertainty: Yönetim ve security team hangi güvenlik varsayımından emin değildir?

Bu kaynaklar bir araya getirildiğinde örneğin şu senaryo üretilebilir:

Burada actor profile, initial access, target business process ve proof boundary bellidir.

Senaryo ne kadar gerçekçi olmalı?

Gerçekçilik, her tehlikeli action'ı production'da yapmak değildir. Bir saldırgan backup silebilir diye test sırasında gerçek backup silinmez. Bunun yerine authorization, erişim ve action capability'si güvenli bir canary object üzerinde kanıtlanabilir.

İyi emulation, actor'ın TTP mantığını korurken gereksiz impact üretmez. Safety kısıtları attack path'i değiştiriyorsa bu durum raporda belirtilir.

MITRE ATT&CK nasıl kullanılmalı?

MITRE ATT&CK ortak bir behavior taxonomy sağlar. Senaryo planlama, coverage mapping ve Blue Team debrief için faydalıdır. Ancak teknik sayısını artırmak kalite göstergesi değildir.

MITRE'nin adversary emulation planları da threat report'lardan behavior chain üretmeyi ve defender'ların network ile defenses'ı daha etkili test etmesini amaçlar. Bu yaklaşım checklist çalıştırmaktan farklıdır.

Bir operation'da 60 technique yüzeysel biçimde çalıştırmak yerine gerçekçi bir objective'e bağlı 12 technique'i doğru sequence ve operational context içinde emüle etmek daha değerli olabilir.

Red Team operasyonu hangi aşamalardan oluşmalı?

Kaliteli Red Team yalnızca tester'ların aktif olduğu exploitation döneminden ibaret değildir. Planlama, Threat Intelligence, risk management, debrief ve remediation aşamaları operasyon kadar önemlidir.

1. Initiation ve governance

İlk aşamada test sponsor'u, Control Team, provider ve gerekli business owner'lar belirlenir. Amaç, budget ve high-level objective aynı noktada buluşturulur.

Bu aşamada şu sorular cevaplanır:

• Test neden şimdi yapılıyor?
• Hangi business risk ölçülüyor?
• Sonuç kime raporlanacak?
• Risk kabul authority'si kimde?
• Provider ile hangi confidential data paylaşılacak?
• Test evidence'ı nerede ve ne kadar süre saklanacak?
• Gerçek incident ile test nasıl ayrıştırılacak?

Executive sponsor yalnızca bütçe onaylayan kişi olmamalıdır. Ekipler arası remediation engellerini kaldırabilecek authority'ye sahip olmalıdır.

2. Scoping ve Rules of Engagement

Scope yalnızca IP listesi değildir. Allowed ve prohibited action'lar, operating window, third-party dependency, safety boundary ve communication path birlikte yazılmalıdır.

Rules of Engagement en az şu başlıkları içermelidir:

• In-scope domain, IP, application, tenant, office ve identity'ler
• Out-of-scope asset ve business function'lar
• Social engineering ve physical access durumu
• Phishing payload ve credential handling kuralları
• Production exploitation sınırı
• Denial of service yasağı veya özel koşulları
• Data access, download ve exfiltration simulation sınırı
• Persistence ve cleanup şartları
• Cloud ve SaaS provider policy'leri
• Third-party hosted service yaklaşımı
• Working hour ve blackout period'lar
• Emergency contact ve stop word
• Deconfliction yöntemi
• Evidence encryption, transfer, retention ve deletion
• Test infrastructure attribution yaklaşımı
• Legal authorization ve subcontractor koşulları

“Her şey serbest” ifadesi geniş scope değil, yetersiz risk management işaretidir.

3. Threat Intelligence ve target development

Threat Intelligence provider veya Red Team, kuruma özgü threat landscape ve attack surface üzerinde çalışır. Bu aşama yalnızca public breach raporlarının özetlenmesi değildir.

Relevant actor behavior, exposed asset, employee footprint, technology dependency, third-party relationship ve critical function bağlantısı analiz edilir. Elde edilen bilgi operasyon için scenario, objective ve emulation planına dönüşmelidir.

Recon sırasında bulunan sensitive data'nın kullanımı Rules of Engagement'e tabi olmalıdır. Public erişilebilir olması sınırsız kullanım izni vermez.

4. Scenario ve attack plan

Red Team olası attack path'leri, initial access seçeneklerini, decision point'leri ve fallback'leri planlar. Blue Team'e açıklanmayacak olsa bile Control Team safety açısından gerekli high-level bilgiyi bilmelidir.

Plan deterministic olmamalıdır. Gerçek adversary control response'a göre yol değiştirir. Fakat improvisation, scope dışına çıkma yetkisi vermez.

5. Active testing

Operation sırasında Red Team objective'e ilerlerken action timeline'ını ve evidence'ı tutar. Control Team business risk ve gerçek incident sinyallerini takip eder.

High-risk decision point'lerde pre-approved proof yöntemi uygulanır. Örneğin production customer data'yı indirmek yerine belirli record'a query capability gösterilebilir. Payment workflow'da gerçek transfer yerine test beneficiary veya approval öncesi durma noktası kullanılabilir.

6. Deconfliction

SOC gerçek bir alarm oluşturduğunda Control Team hemen “bu test” diyerek investigation'ı durdurmamalıdır. Aksi halde response capability ölçülemez. Ancak destructive containment, law enforcement bildirimi, customer communication veya ciddi operational impact gündeme geliyorsa uygun aşamada deconfliction yapılır.

Gerçek attacker ile Red Team aynı anda ortamda bulunabilir. Red Team beklenmeyen malicious artifact, unknown C2 veya kendisine ait olmayan persistence görürse Control Team'e güvenli kanaldan haber vermelidir.

7. Technical debrief ve Blue Team reconstruction

Operation bittikten sonra yalnızca final report gönderilmemelidir. Red ve Blue ekipler timeline'ı birlikte reconstruct etmelidir.

Her action için şu karşılaştırma yapılabilir:

Bu karşılaştırma sensor gap, analytics gap ve process gap'i birbirinden ayırır.

8. Purple Team ve remediation validation

ECB'nin güncel TIBER-EU yaklaşımı içinde Purple Team bileşeni öğrenme ve remediation değerini artıran önemli bir aşamadır. Red Team action'larının kontrollü biçimde tekrar edilmesi, yeni detection'ların denenmesi ve Blue Team'in artifact'ları anlaması sağlanır.

Her technique'i tekrar etmek gerekmez. Critical attack path ve görünmeyen action'lar önceliklendirilir.

9. Closure ve retest

Closure toplantısında technical findings, attack path, detection coverage, response performance ve systemic root cause ayrı ayrı ele alınmalıdır. Remediation planında owner, deadline, dependency ve validation yöntemi bulunmalıdır.

Retest yalnızca ilk payload'ın artık çalışmadığını göstermekle kalmamalıdır. Attack path'in başka branch üzerinden devam edip etmediği ve yeni detection'ın production telemetry içinde güvenilir çalışıp çalışmadığı doğrulanmalıdır.

Red Team sırasında production riski nasıl yönetilir?

Red Team canlı sistemlere dokunduğu ölçüde gerçekçi, aynı zamanda yanlış action halinde riskli olabilir. Risk sıfırlanamaz, fakat tasarım yoluyla kabul edilebilir seviyeye indirilebilir.

Proof ile impact birbirinden ayrılmalı

Tester'ın bir action'ı yapabildiğini kanıtlaması için business impact'i gerçekten üretmesi gerekmez.

Örnek güvenli proof yöntemleri:

• Critical table'da read capability için önceden yerleştirilmiş canary record
• Write access için test object üzerinde değişiklik
• Data exfiltration için synthetic file ve limitli transfer
• Ransomware için isolated share üzerinde simulated encryption
• Backup delete capability için delete öncesi authorization proof
• Payment change için test vendor veya final approval öncesi durma
• E-mail access için Control Team'e ait canary mailbox

Bu yöntemlerin her biri kurumun architecture ve riskine göre uyarlanmalıdır.

Emergency stop kriteri somut olmalı

“Bir sorun olursa dururuz” yeterli değildir. Aşağıdaki gibi trigger'lar önceden tanımlanabilir:

• Beklenmeyen service degradation
• Customer data üzerinde öngörülmeyen access
• Gerçek fraud veya active attacker sinyali
• Safety-critical system'e yaklaşım
• Test account'unun scope dışı privilege kazanması
• Backup veya recovery capability üzerinde risk
• Third-party complaint
• Control Team communication kaybı

Stop kararı sonrasında evidence korunmalı, kullanılan persistence kaldırılmalı ve sistem owner'larıyla health validation yapılmalıdır.

Test data ve credential güvenliği sağlanmalı

Red Team operation boyunca privileged credential, architecture detail, detection gap ve exploitable path toplar. Bu bilgi sıradan rapor dosyası gibi taşınamaz.

Access least privilege ile sınırlandırılmalı, transfer encrypted channel üzerinden yapılmalı, tester endpoint'leri korunmalı ve retention sonunda doğrulanabilir deletion uygulanmalıdır. Provider'ın subcontractor, offshore storage, cloud collaboration ve breach notification yaklaşımı sözleşmede görünmelidir.

Red Team başarısı nasıl ölçülür?

Bir operation'ın başarısını yalnızca Red Team objective'e ulaştı mı sorusuyla ölçmek ciddi bir hatadır.

Red Team objective'e ulaşamazsa kurumun güvenli olduğu otomatik olarak kanıtlanmaz. Scope, süre, chosen scenario, tester path ve safety constraint sonucu etkilemiş olabilir. Red Team objective'e ulaşırsa da security programının bütünü başarısız sayılmaz. Belki SOC attack chain'i erken detect etmiş, doğru scope belirlemiş ve containment uygulamış olabilir.

Red Team için ölçülebilir çıktılar

• Initial access için kullanılan exposure
• Objective'e kadar gereken attack steps
• Kırılan veya bypass edilen trust boundary sayısı
• Elde edilen privilege düzeyi
• Erişilen critical function
• Kullanılan fallback path'ler
• Her action'ın prevention sonucu
• Her action'ın detection sonucu
• Attack path üzerindeki choke point'ler
• Safety constraint nedeniyle simüle edilen action'lar

Blue Team ve response metric'leri

• Detection coverage
• Mean Time to Detect
• Mean Time to Triage
• Mean Time to Escalate
• Mean Time to Scope
• Mean Time to Contain
• Correct severity assignment oranı
• Alert'ten incident'a dönüşüm kalitesi
• Etkilenen user ve host scope'unun doğruluğu
• Evidence preservation kalitesi
• Cross-team handoff süresi
• Recovery decision süresi

Tek başına süre de yeterli değildir. Beş dakikada alert oluşması, analyst bunu benign saydıysa detection sonucu üretmez.

Control ve process metric'leri

• Hangi control beklenen şekilde block etti?
• Hangi control telemetry üretti fakat alert üretmedi?
• Hangi alert context eksikliği nedeniyle araştırılamadı?
• Hangi response action approval bekledi?
• Hangi business owner'a ulaşılamadı?
• Hangi containment adımı aşırı business impact yaratacaktı?
• Hangi recovery dependency bilinmiyordu?

Remediation metric'leri

• Critical attack path closure süresi
• Root cause düzeyinde kapatılan finding oranı
• Compensating control ile yönetilen finding sayısı
• Retest başarı oranı
• Purple Team sonrasında detection coverage artışı
• Aynı TTP'nin sonraki testte görünme oranı
• Repeat finding oranı
• Policy ve architecture değişikliğine dönüşen finding sayısı

Raporun kalitesi bulgu sayısıyla değil, kurumun davranışında ürettiği ölçülebilir değişimle değerlendirilmelidir.

Red Team raporunda ne bulunmalı?

Executive management ile teknik ekip aynı raporun farklı katmanlarına ihtiyaç duyar.

İyi bir Red Team deliverable seti şu bileşenleri içerebilir:

Executive narrative

• Test edilen business objective
• Threat scenario
• High-level attack path
• Critical function üzerindeki kanıtlanmış impact
• Prevention, detection ve response sonucu
• En önemli systemic risk'ler
• Yönetim kararı gerektiren remediation alanları

Attack path timeline

Her action için timestamp, source, target, technique, outcome ve evidence bulunmalıdır. Blue Team log'larıyla correlation yapılabilecek kadar kesin olmalıdır.

Technical findings

Tekil vulnerability ve misconfiguration'lar root cause, precondition, impact, affected scope ve remediation ile açıklanmalıdır. Finding'in attack path içindeki rolü gösterilmelidir.

Detection and response assessment

Hangi activity'nin block, detect, investigate ve contain edildiği ayrı ayrı gösterilmelidir. “EDR görmedi” gibi genel ifadeler yerine sensor, telemetry, analytics ve analyst aşamaları ayrıştırılmalıdır.

ATT&CK mapping

Technique mapping operation'ı anlamaya yardımcı olmalı, raporu kalabalıklaştıran checkbox listesine dönüşmemelidir. Data source ve detection opportunity ile ilişkilendirilmesi daha faydalıdır.

Remediation roadmap

Quick fix, tactical improvement ve strategic architecture değişikliği ayrılmalıdır. Her recommendation'ın attack path'i hangi noktada kestiği belirtilmelidir.

Evidence appendix

Sensitive screenshot, command output, request ve response gibi evidence kontrollü appendix içinde sunulabilir. Secret ve personal data gereksiz biçimde çoğaltılmamalıdır.

Red Team ne sıklıkla yapılmalı?

“Her yıl bir Red Team” kolay bütçelenebilir bir takvimdir, fakat her kurum için doğru değildir. Frequency risk, change rate, regulatory requirement ve remediation cycle ile belirlenmelidir.

Yeni operation için anlamlı trigger'lar şunlardır:

• Önceki attack path'ler systemic olarak kapatıldıysa
• Yeni critical function devreye alındıysa
• Büyük cloud veya identity migration tamamlandıysa
• Acquisition sonrası trust environment birleştiyse
• SOC provider veya detection architecture değiştiyse
• Threat landscape kurum için önemli biçimde değiştiyse
• Gerçek incident sonrasında response capability yeniden doğrulanacaksa
• İlgili otorite veya sözleşme belirli periyot istiyorsa

Önceki rapor kapanmadan aynı scenario'yu her yıl tekrarlamak bütçeyi verimsiz kullanır. Bunun yerine yıl içinde targeted Purple Team, control validation ve focused pentest yapılabilir. Full Red Team, remediation'ın etkisini ve yeni attack path'leri ölçmek için uygun noktada tekrarlanır.

Yüksek maturity ve hızlı değişen attack surface'e sahip kurumlarda sürekli internal adversary emulation programı anlamlı olabilir. Bu model dış provider'ın bağımsız assessment'ını tamamen ortadan kaldırmaz.

Red Team provider seçerken hangi sorular sorulmalı?

Provider seçimi yalnızca sertifika listesi ve günlük ücret karşılaştırmasıyla yapılamaz. Red Team teknik capability kadar operational safety, reporting ve stakeholder management gerektirir.

1. Threat Intelligence nasıl senaryoya dönüşüyor?

Provider'ın hazır APT template'i kullanıp kullanmadığı, kuruma özgü threat research'i nasıl yaptığı ve actor TTP'lerini business objective ile nasıl eşleştirdiği sorulmalıdır.

2. Operation ekibi hangi experience'a sahip?

Web, Active Directory, cloud, identity, social engineering, detection engineering ve operational security aynı kişide bulunmak zorunda değildir. Proposed team'in scope ile ilgili gerçek delivery experience'ı görülmelidir.

3. Production safety nasıl yönetiliyor?

Proof boundary, high-risk action approval, cleanup, deconfliction, emergency stop ve gerçek incident ayrımı için somut process istenmelidir.

4. Custom tradecraft var mı?

Tamamen public tool ve bilinen default profile kullanmak bazı objective'ler için yeterli olabilir. Ancak advanced detection capability test edilecekse provider'ın payload customization, infrastructure management ve OPSEC yaklaşımı önemlidir.

Buradaki hedef “antivirus atlatan araç gösterisi” değildir. Threat actor'a uygun behavior üretirken gereksiz indicator tekrarını azaltmaktır.

5. Blue Team değerlendirmesi yapabiliyor mu?

Provider yalnızca offensive timeline mı sunuyor, yoksa detection opportunity, telemetry gap, alert quality ve response process'i de analiz ediyor mu? Purple Team facilitation capability'si var mı?

6. Rapor attack path ve root cause gösteriyor mu?

Sample report içinde executive narrative, technical evidence, timeline, ATT&CK mapping, detection assessment ve systemic recommendation bulunmalıdır. Sadece screenshot ve CVSS tablosu Red Team deliverable'ı değildir.

7. Evidence nasıl korunuyor?

Data location, encryption, access control, retention, deletion, subcontractor ve incident notification süreçleri doğrulanmalıdır.

8. Scope dışı bulgu ve gerçek incident nasıl yönetiliyor?

Tester active compromise işareti görürse hangi kanaldan ve ne kadar hızlı bildirir? Scope dışı kritik exposure'a rastlarsa veri toplamadan nasıl escalation yapar?

9. Retest ve remediation desteği var mı?

Operation sonrası technical workshop, Purple Team, detection validation ve retest kapsamı teklif içinde net olmalıdır.

10. Başarı kriteri nasıl tanımlanıyor?

“Kesin Domain Admin oluruz” diyen provider yanlış teşvik üretir. İyi provider başarıyı kontrollü testing, objective evidence, defense learning ve actionable remediation üzerinden tanımlar.

Red Team satın alırken scope dokümanında ne yazmalı?

Teklif talebinde yalnızca IP sayısı ve user sayısı vermek provider'ların aynı işi fiyatlamasını sağlamaz.

RFP veya scope dokümanı şu bilgileri içermelidir:

• Business background ve critical function'lar
• Test motivation
• Desired objective'ler
• Relevant threat concern'ler
• High-level technology environment
• External, internal, cloud ve identity boundary'leri
• Social engineering ve physical testing beklentisi
• Assumed breach access durumu
• Blue Team awareness seviyesi
• Expected test window
• Production ve safety constraint'leri
• Third-party dependency'ler
• Control Team modeli
• Required deliverable'lar
• Purple Team ve retest beklentisi
• Data handling requirement'ları
• Regulatory framework varsa ilgili gereksinimler
• Provider qualification ve reference kriterleri

Scope hazırlığı sırasında bütün environment detail'i ilk e-mail ile paylaşmak gerekmez. Hassas bilgi NDA ve secure channel sonrasında aktarılabilir.

Red Team hakkında en yaygın yanlış kabuller

“Red Team en ileri pentest olduğu için her zaman daha iyidir”

Yanlıştır. Daha geniş ve daha gerçekçi olması her soruya daha iyi cevap verdiği anlamına gelmez. Bir API'nin bütün authorization flaw'larını bulmak için derinlemesine API pentest daha doğrudur.

“Red Team başarılıysa Blue Team başarısızdır”

Yanlıştır. Red Team'in bir foothold elde etmesi defense-in-depth modelinde beklenebilir. Önemli olan attack chain'in hangi aşamada görüldüğü, sınırlandığı ve objective impact'in önlenip önlenmediğidir.

“Hiç alert oluşmadıysa Red Team çok iyidir”

Bu yalnızca bir ihtimaldir. Scope yanlış seçilmiş, telemetry hiç toplanmamış veya SOC'a test penceresinde yeterli kaynak verilmemiş olabilir. Amaç gösteri değil gap'in nedenini bulmaktır.

“Domain Admin olunmadıysa risk yoktur”

Modern cloud ve SaaS ortamlarında Domain Admin nihai objective olmayabilir. Source code secret, customer export, payment approval, CI/CD control veya cloud subscription owner çok daha kritik olabilir.

“Red Team bütün açıkları bulur”

Red Team attack path'e odaklanır. Exhaustive coverage sağlamaz. Düzenli vulnerability assessment, application pentest, code review ve configuration review devam etmelidir.

“Blue Team testi bilirse bütün değer kaybolur”

Covert phase için bilgi sınırlaması önemlidir. Fakat kurumun readiness seviyesi düşükse Purple Team daha doğru yöntem olabilir. Realism tek kalite ölçütü değildir.

“Test ne kadar uzun sürerse o kadar iyidir”

Süre objective, scope, stealth ve environment complexity ile ilişkilidir. Plansız uzun test daha fazla değer üretmez. Çok kısa çalışma ise threat research ve response observation için yetersiz kalabilir.

“Red Team yalnızca çok büyük şirketler içindir”

Risk concentration, critical dependency ve threat profile büyüklükten daha önemlidir. Küçük bir managed service provider büyük müşterilere giden supply chain path'i taşıyabilir.

Red Team'e hazır olmayan kurum için 12 aylık yol haritası

Aşağıdaki sıra her kuruma aynen uygulanmaz. Ama full Red Team öncesinde capability oluşturmanın nasıl aşamalı ilerleyebileceğini gösterir.

İlk 90 gün

• Critical function ve asset owner'ları belirleyin
• Internet-facing attack surface'i çıkarın
• Critical exposure'ları kapatın
• Privileged account inventory hazırlayın
• MFA gap'lerini azaltın
• Incident contact tree'yi güncelleyin
• Backup recovery için temel restore testi yapın

3–6 ay

• Critical application ve network pentest'lerini tamamlayın
• Finding remediation SLA ve retest sürecini kurun
• Endpoint, identity, VPN, DNS ve cloud log'larını merkezi hale getirin
• SOC escalation ve containment authority'sini netleştirin
• Ransomware veya identity compromise tabletop exercise yapın
• High-risk service account ve third-party access'leri gözden geçirin

6–9 ay

• Threat model ve ATT&CK-aligned detection priority oluşturun
• Purple Team ile seçili TTP'lerde telemetry ve detection doğrulayın
• Alert triage ve incident scope kalitesini ölçün
• Network segmentation ve privileged path testlerini yapın
• Critical attack path'ler için canary ve safe proof tasarlayın

9–12 ay

• Readiness assessment'ı yenileyin
• Dar business objective seçin
• Control Team ve Rules of Engagement hazırlayın
• Assumed breach veya objective-limited Red Team ile başlayın
• Debrief sonrasında Purple Team ve remediation retest planlayın

Bu yol haritasının amacı takvim doldurmak değildir. Her aşamanın evidence ile bir sonraki aşamaya hazır olduğunu göstermektir.

Sonuç: Her kuruma aynı test değil, doğru güvenlik sorusuna doğru yöntem gerekir

Her kurumun Red Team'e ihtiyacı var mı?

Her kurumun bugün full-scope, covert ve threat-led bir Red Team operation'a ihtiyacı yoktur. Her kurumun ise kendi riskine uygun biçimde security assumptions'ını adversarial yöntemlerle doğrulamaya ihtiyacı vardır.

Temel attack surface bilinmiyor, critical vulnerability'ler kapanmıyor ve log'lar toplanmıyorsa Red Team ilk yatırım olmamalıdır. Bu ortamda external pentest, application security assessment, identity review, vulnerability management ve incident response hazırlığı daha fazla risk azaltabilir.

Kurum critical function'larını biliyor, temel kontrol yatırımlarını yapmış, pentest findings'lerini kapatıyor, telemetry topluyor ve incident response capability'sini gerçekçi bir saldırı altında sınamak istiyorsa Red Team doğru adımdır.

Karar şu sırayla verilmelidir:

1. 1Hangi business risk hakkında belirsizlik var?
2. 2Hangi threat actor veya attack behavior gerçekçi?
3. 3Mevcut control'lerin hangi sonucu üretmesi bekleniyor?
4. 4Bu sonucu ölçmek için pentest, Purple Team, tabletop veya Red Team seçeneklerinden hangisi en doğrudan yöntem?
5. 5Kurum operation'ı güvenle yönetmeye ve bulguları kapatmaya hazır mı?

Red Team bir başarı gösterisi değildir. NIST tanımındaki gibi kurumun mission ve business process'lerine karşı gerçek dünya koşullarını yansıtan simulated adversarial assessment'tır. ECB'nin TIBER-EU yaklaşımında da vurgulandığı üzere sonuç pass veya fail değil, cyber resilience hakkında öğrenme ve improvement üretmektir.

En iyi Red Team raporu saldırganın ne kadar yetenekli olduğunu anlatan rapor değildir. Kurumun hangi varsayımının kırıldığını, hangi control'ün işe yaradığını, hangi activity'nin görülmediğini, response'un nerede geciktiğini ve aynı attack path'in yeniden çalışmaması için neyin değişmesi gerektiğini kanıtlayan rapordur.

Secnodex, Red Team ihtiyacını doğrudan operasyon satışıyla başlatmaz. Critical function, threat profile, existing test coverage, telemetry, SOC, incident response ve remediation readiness alanlarını değerlendirerek pentest, Purple Team, assumed breach veya full-scope Red Team seçeneklerinden hangisinin gerçek değer üreteceğini belirler. Operasyonları Threat Intelligence, kontrollü adversary emulation, detection-response assessment ve retest bileşenleriyle yürütür. Kurumunuz için doğru test modelini belirlemek üzere Secnodex ile iletişime geçebilirsiniz.

Kaynaklar

• NIST CSRC – Red Team Exercise Glossary
• NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment
• NIST Cybersecurity Framework 2.0
• NIST SP 800-61 Revision 3 – Incident Response Recommendations and Considerations
• MITRE ATT&CK – Adversary Emulation Plans
• European Central Bank – What is TIBER-EU?
• European Central Bank – TIBER-EU Framework Updated to Align with DORA
• Commission Delegated Regulation (EU) 2025/1190 – TLPT Regulatory Technical Standards
• G7 Fundamental Elements for Threat-Led Penetration Testing
• UK NCSC – Detection Practices
• UK NCSC – CHECK Penetration Testing
• Microsoft Security Incident Management – Preparation