Red Team ile Sızma Testi Arasındaki Fark Gerçekten Nerede Başlar?

Bir kurumun teklif dokümanında onlarca IP adresi, birkaç web uygulaması ve bir Active Directory ortamı yer alıyor. Çalışmanın black-box yapılması, mümkün olduğunca az iz bırakılması ve bulunan zafiyetlerin CVSS skoruyla raporlanması isteniyor. Dokümanın başlığında ise “Red Team” yazıyor.

Bu çalışma gerçekten Red Team midir?

Olabilir, fakat yalnızca bu bilgilerle söylemek mümkün değildir. Çünkü Red Team ile sızma testi arasındaki fark kullanılan exploit’te, test ekibinin kıdeminde, Kali Linux kullanılıp kullanılmamasında veya çalışmanın kaç hafta sürdüğünde başlamaz. Gerçek fark, kurumun cevap aradığı soruda başlar.

Sızma testi çoğunlukla “Tanımlı sistemlerde hangi güvenlik açıkları var, bunlar gerçekten exploit edilebilir mi ve etkileri nedir?” sorusuna cevap verir. Red Team ise “Gerçekçi bir threat actor, belirli başlangıç koşulları altında kritik iş hedefine ulaşabilir mi, mevcut prevention ve detection kontrolleri bunu nerede durdurur, Blue Team olayı fark edip doğru biçimde karşılık verebilir mi?” sorusunu araştırır.

Red Team ve sızma testi neden sürekli karıştırılıyor?

İki çalışma da yetkilendirilmiş offensive security faaliyetidir. İkisinde de reconnaissance, exploitation, privilege escalation veya lateral movement görülebilir. Aynı uzmanlar, aynı araçlar ve aynı teknik altyapı kullanılabilir. Bir pentester web uygulamasındaki SSRF üzerinden cloud credential elde edebilir. Bir Red Team operator da aynı zafiyeti operasyon hedefine ulaşmak için kullanabilir.

Dışarıdan bakıldığında yapılan işlem benzer görünür. Ayrım, teknik kullanıldıktan sonra ortaya çıkar.

Pentester, SSRF’nin hangi endpoint’te bulunduğunu, hangi kaynaklara erişebildiğini, severity seviyesini, PoC’yi ve remediation adımını raporlar. Test kapsamındaki benzer endpoint’leri de kontrol ederek zafiyet sınıfının ne kadar yayıldığını anlamaya çalışır.

Red Team operator için aynı SSRF, saldırı zincirindeki bir adımdır. Asıl soru bu erişimin kritik hedefe ilerlemeyi sağlayıp sağlamadığı, cloud monitoring tarafından görülüp görülmediği, üretilen telemetry’nin SIEM’e ulaşıp ulaşmadığı ve SOC’un olaya nasıl tepki verdiğidir. Red Team raporu zafiyeti yine içerebilir, fakat operasyonun değeri tek finding’den değil bütün attack path’ten doğar.

Piyasadaki karışıklığın bir başka nedeni de “Red Team” ifadesinin daha ileri seviye veya daha prestijli görünmesidir. Bazı geniş kapsamlı pentest’ler yalnızca uzun sürdükleri, stealth beklentisi taşıdıkları veya post-exploitation içerdiği için Red Team olarak adlandırılır. Oysa crown jewel, threat scenario, operasyon hedefi, Blue Team ölçümü ve attack path temelli başarı kriteri yoksa çalışma büyük ihtimalle gelişmiş bir pentest’tir.

Bu kötü bir şey değildir. Yanlış olan, kuruma ihtiyacı olmayan bir hizmeti daha güçlüymüş gibi sunmak veya ihtiyacı olan savunma ölçümünü sıradan bir zafiyet raporuyla tamamlanmış saymaktır.

Sızma testi nedir?

Sızma testi, tanımlanmış application, system veya network bileşenlerindeki güvenlik kontrollerini aktif yöntemlerle değerlendiren yetkilendirilmiş bir testtir. Amaç yalnızca potansiyel zafiyetleri scanner ile listelemek değil, uygun güvenlik sınırları içinde exploitability’yi doğrulamak ve teknik etkinin ne kadar ilerleyebildiğini göstermektir.

NIST, penetration testing’i gerçek saldırıları taklit ederek bir application, system veya network üzerindeki güvenlik kontrollerini aşma yollarını belirlemeye çalışan security testing olarak tanımlar. NIST ayrıca pentest’in tek bir zafiyet yerine birden fazla weakness’in birleşimiyle elde edilebilecek erişimi de değerlendirebileceğini belirtir.

Bu nedenle iyi bir sızma testi yalnızca port taraması veya vulnerability scan değildir. Manuel doğrulama, authentication ve authorization testleri, business logic analizi, configuration review, kontrollü exploitation ve gerektiğinde post-exploitation içerebilir.

Sızma testinin scope’u çoğunlukla varlıklarla ifade edilir:

• Belirli domain ve subdomain’ler
• Web uygulamaları ve API’ler
• Mobile application’lar
• External ve internal IP aralıkları
• VPN ve remote access sistemleri
• Active Directory ortamı
• Wireless network
• Cloud account ve servisler

Çalışmanın amacı bu kapsam içindeki zafiyetleri mümkün olan yeterli coverage ile tespit etmek, doğrulamak ve remediation için aksiyon alınabilir bir rapora dönüştürmektir. Pentester kritik hedefe giden bir yol bulduğunda bunun etkisini gösterir. Ancak testin başarısı yalnızca tek bir hedefe erişmekle sınırlı değildir. Kapsamdaki diğer önemli zafiyetlerin bulunması da beklenir.

Red Team nedir?

Red Team, gerçekçi bir adversary davranışını yetkilendirilmiş ve kontrollü biçimde emüle ederek kurumun security posture’unu, kritik iş fonksiyonlarını ve savunma kabiliyetlerini değerlendiren objective-based bir operasyondur.

NIST’in Red Team tanımı iki önemli noktaya odaklanır. Birincisi, ekip potansiyel bir adversary’nin attack veya exploitation kabiliyetlerini emüle eder. İkincisi, amaç yalnızca başarılı saldırının etkisini göstermek değil, savunma tarafında hangi kontrollerin gerçekten çalıştığını da ortaya çıkarmaktır.

Bu nedenle Red Team çalışmasının merkezinde genellikle şu bileşenler bulunur:

• Korunması gereken kritik iş fonksiyonu veya crown jewel
• Kuruma ve sektöre uygun threat profile
• Gerçekçi initial access ve attack scenario
• Ulaşılması hedeflenen önceden tanımlı objective veya flag
• Prevention, detection ve response ölçümü
• Operasyon güvenliği ve gerektiğinde stealth
• Blue Team davranışı ve telemetry analizi
• Attack path, TTP ve root cause odaklı raporlama
• Replay, Purple Team veya remediation validation aşaması

MITRE ATT&CK, Red Team ve adversary emulation çalışmaları için ortak bir TTP dili sağlar. Ancak ATT&CK technique’lerini sırayla çalıştırmak tek başına Red Team değildir. Technique seçimi threat intelligence, kurumun architecture yapısı ve operasyon hedefiyle ilişkilendirilmelidir.

Gerçek fark ilk olarak amaçta başlar

Aynı kuruma iki farklı çalışma planlandığını düşünelim.

İlk çalışmada amaç, internet-facing VPN, web application ve API’lerde exploitable zafiyetleri belirlemektir. Ekip mümkün olan kapsamı tarar, manual test yapar, bulguları doğrular ve her birini remediation bilgisiyle raporlar. Bu bir sızma testidir.

İkinci çalışmada amaç, dışarıdan başlayan gerçekçi bir saldırganın kritik finansal raporlama sistemine erişip belirli bir dosyayı temsil eden flag’e ulaşabilmesidir. Ekip, threat profile’a uygun yöntemlerle initial access arar, erişimi genişletir ve hedefe ilerler. Aynı zamanda SOC’un hangi aşamada alarm ürettiği, analyst’in olayı doğru sınıflandırıp sınıflandırmadığı ve containment kararının ne kadar sürede geldiği ölçülür. Bu bir Red Team operasyonudur.

İki ekip aynı RCE’yi kullanabilir. Fakat pentest RCE’nin kendisini ve benzer zafiyetlerin coverage’ını merkeze alır. Red Team ise RCE’yi mission objective’e giden bir araç olarak görür.

Bu ayrım önemli bir sonucu da beraberinde getirir. Red Team, kapsam içinde gördüğü her zafiyeti ayrıntılı biçimde test etmek zorunda değildir. Kritik hedefe ilerlemek için güvenilir bir yol bulduğunda operasyonunu o yol üzerinden sürdürebilir. Pentest ise kullanılmayan fakat ciddi risk taşıyan diğer zafiyetleri de bulmaya ve değerlendirmeye çalışır.

Dolayısıyla Red Team raporunda daha az sayıda klasik finding bulunması, testin yüzeysel olduğu anlamına gelmez. Benzer şekilde yüzlerce zafiyet içeren bir rapor da çalışmanın Red Team olduğunu kanıtlamaz.

Red Team ile sızma testi arasındaki temel farklar

Bu tablo iki hizmet arasında duvar olduğu anlamına gelmez. İyi bir pentest attack chain kurabilir. İyi bir Red Team de ciddi teknik zafiyetleri ayrıntılı raporlayabilir. Fark, hangi çıktının çalışmayı başarılı saydırdığıdır.

Aynı teknik iki çalışmada nasıl farklı kullanılır?

Reconnaissance

Pentest sırasında reconnaissance, scope içindeki varlıkları, endpoint’leri, servisleri ve attack surface’i mümkün olduğunca eksiksiz çıkarmak için yapılır. Coverage önemlidir.

Red Team sırasında reconnaissance, threat actor’ın kurum hakkında elde edebileceği bilgileri toplamak ve objective’e ulaşabilecek en gerçekçi initial access yolunu seçmek için kullanılır. Shadow IT, sızdırılmış credential, çalışanlara ait public bilgi veya third-party trust relationship scenario’nun parçası olabilir.

Password attack

Pentest’te amaç password policy, account lockout, MFA coverage veya weak credential riskini ölçmek olabilir. Bulgular etkilenen servis ve hesap türüne göre raporlanır.

Red Team’de password spray veya credential reuse, initial access elde etmek ya da erişimi genişletmek için kullanılan bir adımdır. Asıl ölçüm bu aktivitenin identity telemetry’sinde görülüp görülmediği, alarmın oluşup oluşmadığı ve Blue Team’in nasıl tepki verdiğidir.

Web application exploitation

Pentester SQL injection, IDOR, SSRF, file upload veya RCE gibi zafiyetleri kapsamlı test eder. Aynı zafiyet sınıfının farklı endpoint’lerde tekrar edip etmediğini araştırır.

Red Team operator web zafiyetini internal network’e geçiş, credential elde etme veya target system’e erişim amacıyla kullanabilir. Objective’e hizmet etmeyen diğer web bulguları operasyon sırasında ikincil kalabilir.

Privilege escalation

Pentest’te privilege escalation, local veya domain-level etkiyi doğrular ve yanlış configuration’ın riskini gösterir.

Red Team’de aynı teknik attack path üzerindeki bir engeli aşar. Buna ek olarak EDR’ın davranışı, alert enrichment, SOC triage ve containment adımları gözlemlenir.

Lateral movement

Internal pentest de lateral movement içerebilir. Amaç segmentation, credential hygiene, Active Directory permission ve trust relationship zafiyetlerini göstermek olabilir.

Red Team’de lateral movement, crown jewel’a giderken adversary emulation’ın bir parçasıdır. Hangi tekniklerin sessiz kaldığı, hangilerinin telemetry ürettiği ve savunmanın saldırı zincirini birleştirip birleştiremediği değerlendirilir.

Black-box çalışma otomatik olarak Red Team midir?

Hayır. Black-box, grey-box ve white-box ifadeleri test ekibine başlangıçta ne kadar bilgi verildiğini anlatır. Hizmetin amacını tanımlamaz.

Bir web application pentest’i yalnızca URL verilerek black-box yürütülebilir. Yine de amaç kapsam içindeki zafiyetleri bulmaksa bu çalışma pentest’tir. Tersine bir Red Team operasyonu assumed breach modeliyle başlayabilir. Ekibe internal foothold veya test hesabı verilebilir. Buna rağmen amaç gerçekçi bir adversary’nin belirli bir aşamadan sonra crown jewel’a ilerleyip ilerleyemediğini ve savunmanın bunu görüp göremediğini ölçmekse çalışma Red Team niteliğini korur.

Başlangıç bilgisinin az olması testi her zaman daha kaliteli yapmaz. Bazen günlerce zaten bilinen bir perimeter kontrolüne takılmak yerine kontrollü bir leg-up verilmesi, kurumun asıl ölçmek istediği lateral movement ve detection kabiliyetine daha fazla zaman ayrılmasını sağlar.

Kaliteli test, en az bilgiyle yapılan değil, doğru güvenlik sorusuna en güçlü evidence’i üreten testtir.

Stealth kullanılması bir çalışmayı Red Team yapar mı?

Tek başına yapmaz. Pentest sırasında da rate limit’e dikkat etmek, WAF block’larını azaltmak veya production etkisini sınırlamak için kontrollü ve düşük profilli yöntemler kullanılabilir.

Red Team’de stealth daha farklı bir amaca hizmet eder. Eğer emüle edilen threat actor detection’dan kaçınma teknikleri kullanıyorsa operasyonun gerçekçiliği için benzer davranışlar planlanabilir. Fakat her Red Team tamamen görünmez kalmayı hedeflemez. Bazen kurum belirli telemetry ve alert’lerin üretilmesini, SOC’un bunları ilişkilendirmesini ve response playbook’un çalışmasını ölçmek ister.

Blue Team’in saldırıyı erken tespit edip durdurması Red Team’in başarısız olduğu anlamına gelmez. Tam tersine operasyon kurumsal kontrolün çalıştığını doğrulamış olur. Red Team’in amacı “ne pahasına olursa olsun kazanmak” değil, savunma hakkında doğru ve tekrarlanabilir sonuç üretmektir.

Threat Intelligence farkı nerede devreye girer?

Sızma testi güncel threat landscape’den yararlanabilir. İnternete açık teknoloji yığınına yönelik yeni CVE’ler, yaygın attack pattern’leri ve sektörel tehditler scope önceliklendirmesini iyileştirir. Ancak klasik pentest çoğu zaman belirli bir threat actor’ı uçtan uca emüle etmek zorunda değildir.

Threat-led Red Team çalışmasında ise intelligence scenario’nun temel girdisidir. Kurumun sektörünü, coğrafyasını, teknoloji yapısını ve kritik iş fonksiyonlarını hedefleyen aktörler incelenir. Bu aktörlerin kullandığı initial access yolları, TTP’ler ve objective’ler değerlendirilerek kuruma özel scenario oluşturulur.

MITRE ATT&CK bu davranışları ortak bir dilde ifade etmeye yardımcı olur. Yine de bir threat actor’ın ATT&CK sayfasındaki bütün technique’leri test etmek doğru yaklaşım değildir. Intelligence kalitesi, tekniklerin güncelliği, kurum ortamındaki uygulanabilirlik ve operasyon güvenliği birlikte değerlendirilmelidir.

Avrupa Merkez Bankası tarafından yayımlanan güncel TIBER-EU framework de threat intelligence-based ethical red teaming yaklaşımını kritik iş fonksiyonları, kontrollü production testing, Control Team, Red Team, Blue Team ve remediation adımlarıyla ele alır. Bu model özellikle finansal kuruluşlar ve DORA kapsamındaki threat-led penetration testing çalışmaları için önemli bir referanstır. Her kurumun otomatik olarak TIBER-EU kapsamına girdiği varsayılmamalıdır.

Scope farkı neden belirleyicidir?

Pentest scope’u genellikle “Neleri test edeceğiz?” sorusuyla başlar. Red Team scope’u ise önce “Neyi koruduğumuzu ve hangi adversary davranışına karşı ölçüm yapacağımızı” sorar.

Sızma testi scope örneği

• 3 web application
• 2 mobile application
• 45 external IP
• 6 API servisi
• Belirli internal subnet’ler
• Bir Active Directory forest

Bu tanım test ekibine coverage sınırını verir. Bulgular scope içindeki varlıklarla ilişkilendirilir.

Red Team scope örneği

• Objective: Kritik ödeme talimatı sistemine yetkisiz erişimi temsil eden flag’e ulaşmak
• Threat profile: Kurumu hedefleme motivasyonu ve kabiliyeti bulunan belirli actor davranışları
• Initial access: Internet-facing attack surface ve açıkça izin verilen diğer vector’ler
• Crown jewel: Ödeme talimatı oluşturma ve onay süreci
• Measurement: Prevention, identity, endpoint, network ve SOC response kabiliyeti
• Constraints: Kullanılamayacak teknikler, etki sınırları, third-party sistemler ve test durdurma kriterleri

Red Team scope’unun objective-based olması sınırsız olduğu anlamına gelmez. Tam tersine production üzerinde yürütülen her operasyon güçlü sınırlar gerektirir. Domain, IP, çalışan grubu, fiziksel lokasyon, third-party, veri erişimi ve yasaklı işlemler Rules of Engagement içinde açıkça tanımlanmalıdır.

Rules of Engagement her iki çalışma için de neden zorunlu?

Yetkilendirme yalnızca “test yapabilirsiniz” e-postasından ibaret olmamalıdır. Rules of Engagement, test ekibinin hangi faaliyetleri hangi sınırlar içinde yürütebileceğini belirler. NIST de ROE’yi test başlamadan önce oluşturulan ayrıntılı kural ve kısıtlar olarak tanımlar.

İyi hazırlanmış bir ROE en az şu başlıkları içerir:

• Testin yasal sahibi ve yazılı yetkilendirme
• Scope içi ve scope dışı varlıklar
• Objective ve başarı kriterleri
• İzin verilen initial access vector’leri
• Social engineering ve physical security durumu
• Production sistemlerinde uygulanabilecek teknikler
• DoS, data destruction ve service interruption yasakları
• Hassas veriye erişim, kanıtlama ve saklama yöntemi
• Test hesabı ve controlled payload kuralları
• Third-party sistemler için gerekli izinler
• Deconfliction ve emergency contact modeli
• Testi durdurma ve kill switch kriterleri
• Log ve telemetry’nin nasıl korunacağı
• Operation cleanup ve artifact removal adımları

Red Team operasyonunda ayrıca küçük bir Control Team bulunur. Bu ekip operasyon güvenliğini, yetkilendirmeyi ve beklenmeyen üretim etkilerini yönetir. Blue Team’den bilgi saklanabilir, fakat kurum içinde hiç kimsenin operasyondan haberdar olmaması güvenli bir model değildir.

Red Team operasyonu nasıl planlanır?

Her operasyon farklıdır. Yine de olgun bir çalışma aşağıdaki mantıksal aşamalardan geçer.

1. İş hedefi ve crown jewel belirlenir

“Bizi hackleyin” ölçülebilir bir hedef değildir. Kritik ödeme süreci, müşteri verisi, üretim kontrol sistemi, yönetici iletişimi veya cloud control plane gibi korunması gereken somut iş fonksiyonu belirlenmelidir.

2. Threat profile hazırlanır

Kuruma karşı gerçekçi motivasyon ve kabiliyete sahip threat actor’lar, bilinen campaign’ler ve TTP’ler incelenir. Scenario yalnızca popüler tekniklere göre değil, kuruma yönelik anlamlı threat intelligence üzerinden oluşturulur.

3. Objective ve flag’ler tanımlanır

Operasyonun neyi başarmaya çalışacağı açık olmalıdır. Gerçek veriyi kopyalamak yerine belirli bir test dosyasına erişim, controlled transaction oluşturma veya ayrı bir honey object’e ulaşma gibi güvenli flag’ler kullanılabilir.

4. Rules of Engagement ve Control Team kurulur

Operasyon sınırları, yasaklı teknikler, iletişim modeli, third-party onayları, data handling ve durdurma kriterleri belirlenir. Beklenmeyen incident ile test aktivitesini ayıracak deconfliction süreci oluşturulur.

5. Scenario ve Red Team Test Plan hazırlanır

Initial access alternatifleri, planlanan attack path’ler, gerekli altyapı, telemetry beklentileri ve objective’e ulaşılamazsa kullanılabilecek leg-up noktaları tasarlanır. Plan, script gibi değişmez olmamalıdır. Gerçek ortamdan elde edilen bilgilere göre kontrollü biçimde adapte edilebilir.

6. Operasyon yürütülür

Red Team gerçekçi TTP’lerle objective’e ilerler. Her işlem timestamp, hedef, kullanılan technique, elde edilen sonuç ve safety etkisiyle kaydedilir. Operasyonun kontrollü olması evidence kalitesini azaltmaz.

7. Blue Team performansı değerlendirilir

Hangi adım prevention kontrolü tarafından durduruldu? Hangi aktivite telemetry üretti? Alert oluştu mu? Analyst doğru severity verdi mi? Farklı sinyaller tek incident altında birleştirildi mi? Escalation ve containment kararı çalıştı mı? Bu sorular attack timeline ile ilişkilendirilir.

8. Replay ve Purple Team yapılır

Operasyon sonrasında Red Team ve Blue Team adımları birlikte inceler. Kaçırılan technique’ler kontrollü biçimde replay edilebilir, detection query’leri geliştirilebilir ve telemetry gap’leri doğrulanabilir.

9. Remediation planı oluşturulur

Yalnızca teknik zafiyetler değil process, ownership, logging, alert logic, playbook ve decision-making eksikleri için aksiyon yazılır. Aksiyonların sahibi, önceliği ve doğrulama yöntemi belirlenir.

Sızma testi süreci nasıl farklı ilerler?

Sızma testinde planlama yine kritiktir, ancak çalışma akışı coverage ve vulnerability validation etrafında kurulur:

1. 1Scope ve test türü belirlenir.
2. 2Rules of Engagement ve test hesapları hazırlanır.
3. 3Asset discovery ve attack surface mapping yapılır.
4. 4Automated araçlar destekleyici olarak kullanılır.
5. 5Manual testlerle authentication, authorization, input handling, business logic ve configuration değerlendirilir.
6. 6Bulgular controlled exploitation ile doğrulanır.
7. 7İş etkisi ve attack chain ihtimali belirlenir.
8. 8Teknik ve yönetici raporları hazırlanır.
9. 9Remediation sonrasında retest yapılır.

Pentest sırasında SOC’un bir payload’ı görüp görmediği faydalı bir gözlem olabilir. Fakat çalışma baştan detection ve response ölçümü için tasarlanmadıysa SOC performansı hakkında güçlü sonuç çıkarılamaz. Aynı şekilde Red Team operasyonunda tek attack path kullanılmış olması da application’ın diğer bütün endpoint’lerinde zafiyet bulunmadığını göstermez.

Her test yalnızca tasarlandığı soruya güvenilir cevap verir.

Red Team raporu ile pentest raporu nasıl ayrılır?

Sızma testi raporunda beklenenler

• Yönetici özeti ve genel risk görünümü
• Scope, metodoloji ve test kısıtları
• Her finding için etkilenen varlık
• Teknik root cause
• Kontrollü PoC ve evidence
• Exploitability ve iş etkisi
• CVSS gibi teknik severity bilgisi
• Uygulanabilir remediation önerileri
• Retest sonucu ve kapanış durumu

Red Team raporunda beklenenler

• Operasyon amacı, threat profile ve scenario
• Crown jewel, objective ve kullanılan flag’ler
• Timestamp içeren uçtan uca attack timeline
• Initial access’ten objective’e kadar attack path
• Kullanılan TTP’ler ve uygun ATT&CK mapping
• Başarılı ve başarısız bütün önemli operasyon adımları
• Prevention kontrollerinin davranışı
• Telemetry, alert ve detection sonuçları
• Blue Team triage, escalation ve containment gözlemleri
• Detection gap ve process gap’lerin root cause’u
• Elde edilen erişimin business impact’i
• Replay ve Purple Team sonuçları
• Teknik, süreçsel ve yönetsel remediation planı

Red Team raporunu yalnızca MITRE ATT&CK technique listesine çevirmek önemli context’i kaybettirir. Bir technique’in “test edildi” olarak işaretlenmesi hangi data source’un çalıştığını, alert’in kaliteli olup olmadığını veya analyst’in doğru aksiyon alıp almadığını açıklamaz.

Başarı nasıl ölçülür?

Pentest için anlamlı metrikler

• Scope coverage ve test edilen attack surface
• Doğrulanmış critical ve high risk finding sayısı
• False positive ayıklama oranı
• Birleştirilebilen attack path’ler
• Remediation SLA uyumu
• Retest sonrasında kapanan finding oranı
• Tekrarlayan root cause ve regression durumu

Red Team için anlamlı metrikler

• Objective’e ulaşılıp ulaşılmadığı
• Objective’e giden attack path’in uzunluğu ve kritik trust boundary’leri
• Hangi adımların prevent edildiği
• Hangi adımlar için gerekli telemetry’nin bulunduğu
• Telemetry’nin merkezi sisteme zamanında ulaşıp ulaşmadığı
• Alert üretimi ve alert kalitesi
• Detection latency ve doğru incident classification
• Analyst’in attack chain’i ilişkilendirme başarısı
• Escalation, containment ve recovery kararlarının etkinliği
• Kaçırılan TTP’ler için detection engineering sonucu
• Replay sonrasında kontrollerin doğrulanma durumu

Red Team’in objective’e ulaşamaması iki farklı anlama gelebilir. Güvenlik kontrolleri saldırıyı doğru şekilde engellediyse bu kurum için olumlu bir sonuçtur. Operasyon planı, test altyapısı veya verilen süre yetersiz kaldıysa savunma hakkında aynı güvenle sonuç çıkarılamaz. Rapor bu farkı açıkça göstermelidir.

Purple Team bu iki çalışmanın neresinde?

Purple Team yalnızca Red Team ve Blue Team personelinin aynı toplantıya girmesi değildir. Amaç offensive ve defensive ekiplerin belirli TTP’leri birlikte test ederek telemetry, detection ve response kontrollerini hızlı feedback ile geliştirmesidir.

Red Team operasyonunda stealth ve bağımsız ölçüm önemli olabilir. Purple Team çalışmasında ise iş birliği bilinçli olarak artırılır. Red Team bir technique’i uygular, Blue Team log ve alert davranışını inceler, detection geliştirilir ve technique yeniden çalıştırılır.

Purple Team özellikle şu durumlarda faydalıdır:

• EDR veya SIEM use case’lerini doğrulamak
• Yeni detection rule’larını test etmek
• Belirli threat actor TTP’leri için coverage geliştirmek
• Red Team’de kaçırılan adımları replay etmek
• Telemetry gap’lerini hızlı biçimde kapatmak
• SOC analyst’lerine gerçekçi fakat kontrollü pratik sağlamak

Purple Team, pentestin veya Red Team’in otomatik yerine geçen daha üstün bir hizmet değildir. Farklı bir feedback modelidir. Kurumun ölçmek istediği soruya göre bağımsız Red Team operasyonundan önce, sonra veya ayrı bir çalışma olarak planlanabilir.

Her kurum Red Team yaptırmalı mı?

Hayır. Red Team her zaman sızma testinden daha iyi veya daha ileri bir seçim değildir. Temel güvenlik süreçleri çalışmıyorsa kapsamlı bir Red Team operasyonu zaten bilinen açıklar üzerinden hızla ilerleyebilir ve kuruma sınırlı yeni bilgi sağlar.

Red Team’den önce en azından şu temellerin bulunması beklenir:

• Güncel asset inventory ve external attack surface görünürlüğü
• Düzenli vulnerability management ve patch süreci
• Kritik sistemler için güncel sızma testi
• Merkezi log toplama ve yeterli retention
• EDR, identity, network ve cloud telemetry’si
• SOC veya tanımlı monitoring sorumluluğu
• Incident Response planı ve escalation modeli
• Kritik iş fonksiyonları ve crown jewel tanımı
• Executive sponsor ve risk owner
• Remediation aksiyonlarını sahiplenebilecek ekipler

Bu unsurlar eksikse önce gap assessment, sızma testi, configuration review, segmentation testi veya Purple Team daha yüksek değer üretebilir.

Hangi durumda sızma testi seçilmeli?

Aşağıdaki ihtiyaçlarda sızma testi genellikle daha doğru başlangıçtır:

• Yeni web application, API veya mobile application production’a çıkacaksa
• Belirli bir sistemin teknik zafiyetleri bilinmek isteniyorsa
• Yıllık veya change-based security assessment gerekiyorsa
• Compliance scope’u için internal ve external testing yapılacaksa
• Yeni VPN, cloud veya network architecture doğrulanacaksa
• Authentication, authorization veya business logic kapsamlı test edilecekse
• Bulunan zafiyetlerin remediation ve retest süreci yönetilecekse
• Geniş asset scope’unda vulnerability coverage hedefleniyorsa

Pentest, “önce teknik hijyen ve exploitable riskleri netleştirelim” sorusuna güçlü yanıt verir.

Hangi durumda Red Team seçilmeli?

Aşağıdaki sorular gündemdeyse Red Team daha uygun olabilir:

• SOC gerçek bir saldırı zincirini fark edebiliyor mu?
• EDR, SIEM, IAM ve network yatırımları birlikte çalışıyor mu?
• Kritik veriye veya iş fonksiyonuna hangi attack path üzerinden ulaşılabilir?
• Kurumu hedefleyen threat actor TTP’lerine karşı ne kadar hazırlıklıyız?
• Initial access sonrasında lateral movement ne kadar erken görülüyor?
• Incident Response ekibi gerçekçi baskı altında doğru karar alabiliyor mu?
• Prevention kontrolü aşıldığında defense-in-depth çalışıyor mu?
• Yönetim, kritik iş hedefi üzerinden ölçülebilir cyber resilience sonucu istiyor mu?

Red Team, “hangi açıklarımız var?” sorusundan çok “mevcut savunmamız gerçekçi bir adversary karşısında görevini yapıyor mu?” sorusuna yanıt verir.

Satın alma dokümanında gerçek Red Team nasıl anlaşılır?

Bir hizmetin adından çok Statement of Work içeriğine bakılmalıdır. Aşağıdaki sorulara net cevap yoksa teklifin Red Team olarak yeniden kapsamlandırılması gerekebilir:

• Operasyonun business objective’i nedir?
• Korunması gereken crown jewel veya critical function hangisidir?
• Scenario hangi threat intelligence’e dayanıyor?
• Başarı hangi flag veya measurable outcome ile belirlenecek?
• Blue Team’in prevention, detection ve response davranışı nasıl ölçülecek?
• Control Team kimlerden oluşacak?
• Need-to-know ve deconfliction modeli nasıl işleyecek?
• Initial access için hangi vector’ler izinli?
• Social engineering veya physical testing var mı?
• Third-party varlıklar için yazılı izin mevcut mu?
• Production safety ve kill switch nasıl yönetilecek?
• Objective’e ulaşılamazsa leg-up kullanılacak mı?
• Operasyon timeline’ı ve TTP evidence’i nasıl teslim edilecek?
• Blue Team report ve Purple Team replay kapsamda mı?
• Remediation planının sahibi ve doğrulama modeli nedir?

Scope yalnızca IP listesi, portlar ve teslim edilecek CVSS tablosundan oluşuyorsa bu yapı pentest’e daha yakındır. Red Team’de teknik scope yine bulunur, fakat objective ve defense measurement tarafından yönlendirilir.

Red Team adı altında sık yapılan hatalar

Geniş pentest’i Red Team olarak sunmak

External, internal, web ve Active Directory testlerinin aynı projede bulunması çalışmayı otomatik olarak Red Team yapmaz. Objective ve adversary emulation modeli yoksa bu kapsamlı bir sızma testidir.

Başarıyı Domain Admin olmakla sınırlamak

Domain Admin bazı scenario’larda anlamlı bir ara hedef olabilir. Ancak her kurumun crown jewel’ı Active Directory değildir. Kritik SaaS data, cloud control plane veya iş uygulamasındaki onay yetkisi daha önemli olabilir.

Blue Team’i tamamen dışarıda bırakmak

Blue Team’den operasyonu gizlemek bağımsız ölçüm sağlayabilir. Fakat closure aşamasında detection ve response davranışı analiz edilmiyorsa Red Team’in en önemli değeri kaybedilir.

ATT&CK technique sayısını kalite göstergesi yapmak

Yüz technique çalıştırmak gerçekçi bir scenario oluşturmaz. Az sayıda fakat kuruma ve threat actor’a uygun technique, güçlü evidence ile test edildiğinde daha değerlidir.

Yalnızca başarılı adımları raporlamak

Engellenen, hata veren veya Blue Team tarafından yakalanan adımlar da önemlidir. Bunlar hangi kontrollerin çalıştığını gösterir ve savunma yatırımının değerini ortaya koyar.

Production safety’yi stealth ile karıştırmak

Görünmez kalmak ile güvenli çalışmak aynı şey değildir. Kontrollü payload, veri sınırı, durdurma kriteri ve deconfliction olmadan stealth operasyon production riskini artırabilir.

Remediation ve replay planlamamak

Operasyonun sonunda etkileyici bir attack path sunup detection gap’leri doğrulamadan bırakmak kalıcı iyileştirme sağlamaz. Closure ve validation proje scope’una baştan dahil edilmelidir.

Sızma testi ile Red Team birlikte nasıl konumlandırılmalı?

En sağlıklı model hizmetleri yarışan seçenekler olarak değil farklı güvence katmanları olarak görür:

1. 1Asset inventory ve attack surface management ile neyin korunacağı belirlenir.
2. 2Vulnerability scanning ile bilinen ve tekrarlanabilir riskler sık aralıklarla izlenir.
3. 3Sızma testi ile application, API, network ve identity katmanındaki exploitable zafiyetler doğrulanır.
4. 4Remediation ve retest ile temel açıklar kapatılır.
5. 5Threat modeling ve Detection Engineering ile kritik attack path’ler hazırlanır.
6. 6Purple Team ile belirli TTP’ler ve telemetry kontrol edilir.
7. 7Red Team ile objective-based, gerçekçi ve daha bağımsız savunma ölçümü yapılır.
8. 8Closure sonrasında replay ve remediation validation gerçekleştirilir.

Bu sıra her kurumda birebir aynı olmak zorunda değildir. Ancak kritik pentest bulguları yıllardır açıkken Red Team yaptırmak, zaten bilinen bir kapının hâlâ açık olduğunu daha pahalı bir yöntemle yeniden öğrenmeye dönüşebilir.

Sonuç: Fark araçta değil, sorulan sorudadır

Red Team ile sızma testi arasındaki farkın başladığı yer exploitation seviyesi değildir. Bir ekip zero-day kullanmadan da güçlü bir Red Team operasyonu yürütebilir. Başka bir ekip gelişmiş exploit chain kurmasına rağmen hâlâ pentest yapıyor olabilir.

Gerçek ayrım dört noktada ortaya çıkar:

1. 1Amaç: Zafiyet bulmak mı, kritik objective’e karşı kurumsal savunmayı ölçmek mi?
2. 2Scope: Asset listesi mi, crown jewel ve threat scenario mu?
3. 3Başarı kriteri: Finding coverage mı, attack path ile prevention, detection ve response sonucu mu?
4. 4Çıktı: Zafiyet ve remediation raporu mu, yoksa uçtan uca operasyon, Blue Team ve cyber resilience analizi mi?

Kurumun ihtiyacı yeni bir application’ın güvenliğini doğrulamaksa doğru hizmet sızma testidir. SOC, EDR, SIEM, IAM ve Incident Response yatırımlarının gerçek adversary davranışı karşısında nasıl çalıştığını görmek istiyorsa Red Team gündeme gelmelidir. İhtiyaç doğru tanımlandığında iki çalışma birbirini zayıflatmaz. Birlikte kurumun teknik riskini ve operasyonel savunmasını farklı açılardan ölçer.

Secnodex, sızma testi ve Red Team hizmetlerini aynı paket altında isim değiştirilmiş çalışmalar olarak ele almaz. Sızma testlerinde web, mobile application, API, network ve Active Directory kapsamındaki zafiyetleri manuel olarak doğrular. Red Team operasyonlarında ise kuruma özel threat scenario, objective, attack path, MITRE ATT&CK mapping, SOC görünürlüğü ve response performansını birlikte değerlendirir. Kurumunuz için doğru çalışma modelini belirlemek üzere Secnodex ile iletişime geçebilirsiniz.

Metodoloji ve referanslar

• NIST Red Team Tanımı
• NIST Penetration Testing Tanımı
• NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
• NIST Rules of Engagement Tanımı
• MITRE ATT&CK: Adversary Emulation and Red Teaming
• MITRE ATT&CK Adversary Emulation Plans
• CISA Red Team Assessment Bulguları
• TIBER-EU Framework 2025
• OWASP Penetration Testing Methodologies