Red Team Nedir? Kurumsal Red Team Simülasyonu Kapsamlı Rehber

Bir yönetim toplantısında Red Team gündeme geldiğinde beklenti bazen tek cümleyle anlatılır:

Bu cümle kulağa net gelir. Oysa iyi bir Red Team çalışmasını tanımlamak için yetersizdir.

Her büyük dijital yapıda yanlış configuration, unutulmuş bir trust relationship, gereğinden geniş bir permission veya kullanıcı davranışından kaynaklanan risk bulunabilir. Yeterli zaman, bütçe ve hareket alanı verilen yetkin bir ekip de çoğu kurumda bir erişim yolu geliştirebilir. Yalnızca “girebildiler mi?” sorusuna bakılırsa pahalı bir operasyonun sonunda zaten tahmin edilen bir cevap alınır.

Asıl sorular farklıdır:

• Kurum için gerçekçi bir threat actor hangi iş hedefini seçerdi?
• Saldırının ilk adımı engellenmezse sonraki hareketler görünür olur muydu?
• Bir telemetry kaydı oluşması, SOC’un olayı doğru yorumladığı anlamına gelir mi?
• Bir endpoint izole edildiğinde saldırganın diğer foothold’ları da bulunabilir miydi?
• Identity, endpoint, network, cloud ve application kontrolleri aynı attack chain içinde birlikte çalışıyor mu?
• Incident response ekibi teknik olayı kritik business function üzerindeki riskle ilişkilendirebiliyor mu?
• Containment kararı production güvenliği korunarak yeterince hızlı alınabiliyor mu?

Red Team’in kurumsal değeri bu sorulara gözleme ve evidence’a dayalı cevap üretebilmesidir. Amaç teknik bir gösteri yapmak değil, savunmaya ilişkin iddiaları gerçekçi bir adversary davranışı karşısında sınamaktır.

Bu kapsamlı rehberde Red Team nedir, neyi ölçer, sızma testinden nerede ayrılır, hangi kurumlar için doğru zamanda değer üretir ve iyi bir Red Team hizmeti nasıl seçilir sorularını ele alacağız. Metodolojiyi, MITRE ATT&CK kullanımını, TIBER-EU ve CBEST gibi threat-led penetration testing çerçevelerini, Rules of Engagement yapısını, SOC ölçümlerini, raporlamayı, süreyi ve maliyeti de teknik ayrıntılarıyla inceleyeceğiz.

1. Red Team nedir?

Red Team, gerçek bir adversary’nin hedef seçme ve ilerleme biçimini kontrollü olarak emüle ederek kurumun insan, süreç ve teknoloji katmanlarını birlikte değerlendiren objective odaklı bir güvenlik çalışmasıdır.

NIST, Red Team exercise kavramını gerçek dünya koşullarını yansıtan ve organizasyonun mission veya business process’lerini compromise etmeyi deneyen simüle edilmiş adversarial faaliyet olarak tanımlar. Bu tanımdaki iki ayrıntı önemlidir. Test edilen yalnızca bir sunucu veya uygulama değildir. Ulaşılmak istenen sonuç da yalnızca vulnerability bulmak değildir.

Bir Red Team operasyonu şu unsurları bir araya getirir:

• Kuruma ve sektöre anlamlı bir threat profile
• Korunması gereken critical business function
• Ölçülebilir bir business objective
• Başlangıç koşulları ve attack path hipotezleri
• Yazılı authorization ve Rules of Engagement
• Kontrollü adversary emulation
• Blue Team görünürlüğü ve response ölçümü
• Evidence tabanlı raporlama
• Remediation ve tekrar doğrulama planı

Red Team yalnızca “etik hacker ekibi” değildir

“Red Team eşittir çok yetenekli hacker” anlatısı, çalışmanın en önemli bölümünü görünmez hale getirir. Teknik kabiliyet gereklidir fakat tek başına yeterli değildir.

İyi bir operator bir erişim yolu geliştirebilir. İyi bir Red Team ise o erişim yolunun kurum için neden anlamlı olduğunu, hangi adversary davranışını temsil ettiğini, hangi safety boundary içinde kullanılabileceğini ve savunma tarafında hangi evidence’ın beklenmesi gerektiğini de bilir.

Bu yüzden kurumsal Red Team operasyonunda yalnızca exploitation yetkinliği aranmaz. Threat Intelligence, operational security, identity ve cloud bilgisi, detection engineering, incident response, production risk yönetimi, iletişim ve raporlama kabiliyeti de gerekir.

Red Team ile adversary emulation aynı şey mi?

Kavramlar pratikte sık sık birbirinin yerine kullanılır. Aralarında yine de yararlı bir vurgu farkı vardır.

Adversary emulation, belirli bir threat actor’ın veya threat profile’ın gözlemlenmiş davranışlarını mümkün olduğunca gerçekçi biçimde modellemeye odaklanır. Technique seçiminin arkasında Threat Intelligence gerekçesi bulunur.

Red Team daha geniş bir operasyon çerçevesidir. Belirli bir actor birebir emüle edilmese bile gerçekçi capability, intent ve attack path varsayımlarıyla kurumsal objective’e ilerlenebilir. Testin içinde OPSEC, control group, deconfliction, safety, response ölçümü ve executive reporting gibi bileşenler yer alır.

Her adversary emulation bir Red Team engagement’ın parçası olabilir. Her Red Team operasyonu ise belirli bir named actor’ın birebir kopyası olmak zorunda değildir.

Red Team’in hedefi mümkün olan en çok açığı bulmak değildir

Bir web uygulamasında yirmi farklı vulnerability bulunabilir. Fakat Red Team bunların yalnızca objective’e giden attack path içinde anlamlı olan biriyle ilgilenebilir. Diğer on dokuz vulnerability denenmeden kalabilir.

Bu bir kalite eksikliği değil, test sorusunun sonucudur. Red Team breadth yerine çoğu zaman end-to-end ilerlemeyi ve savunma davranışını önceler. Kurum bütün uygulama zafiyetlerini öğrenmek istiyorsa doğru hizmet sızma testi veya secure code review olabilir.

2. Red Team neyi ölçer?

Red Team’in ölçüm alanı dört kelimeyle özetlenebilir:

1. 1Prevention
2. 2Detection
3. 3Response
4. 4Containment

Bu dört alan birbirinden ayrı değerlendirilmelidir. Bir kontrolün attack step’i block etmesi ile aktiviteyi yalnızca loglaması aynı sonuç değildir. Alert oluşması ile analistin onu doğru sınıflandırması da aynı şey değildir.

Prevention: Saldırı hangi noktada durduruldu?

Prevention katmanı, saldırgan davranışının başarılı olmasını engelleyen kontrolleri değerlendirir.

Örnekler:

• Phishing içeriğinin e-mail gateway tarafından block edilmesi
• Stolen credential kullanımının conditional access ile engellenmesi
• Yetkisiz process’in application control tarafından çalıştırılmaması
• Lateral movement girişiminin network segmentation ile kesilmesi
• Privileged action’ın PAM veya step-up authentication gerektirmesi
• Hassas resource’a erişimin identity policy ile reddedilmesi

Red Team burada yalnızca “block oldu” demez. Kontrolün hangi koşulda çalıştığını da inceler. Örneğin aynı policy managed device üzerinde etkiliyken legacy authentication path’inde devre dışı kalabilir.

Detection: Davranış gerçekten görüldü mü?

Log bulunması detection anlamına gelmez. Detection için olayın anlamlandırılması ve ilgili güvenlik davranışıyla ilişkilendirilmesi gerekir.

Üç farklı durum düşünelim:

• Activity hiçbir telemetry üretmedi.
• Telemetry üretildi fakat bir detection rule çalışmadı.
• Alert üretildi fakat düşük öncelikli kabul edilerek araştırılmadı.

Üç durumda da saldırgan ilerleyebilir. Kök nedenleri ise birbirinden tamamen farklıdır. İlkinde visibility gap, ikincisinde detection logic eksikliği, üçüncüsünde triage veya process sorunu vardır.

Response: Doğru karar verildi mi?

Response yalnızca bir analyst’in alert’i açması değildir. Kurumun aşağıdaki sorulara ne kadar doğru ve hızlı cevap verdiği ölçülür:

• Aktivite gerçek incident olarak sınıflandırıldı mı?
• İlgili identity, endpoint ve cloud event’leri aynı vaka altında birleştirildi mi?
• Scope yalnızca ilk alarm veren host ile sınırlı mı kaldı?
• Business owner doğru zamanda sürece dahil edildi mi?
• Escalation seviyesi doğru belirlendi mi?
• Evidence korunarak investigation yürütüldü mü?
• Containment kararının operasyonel etkisi değerlendirildi mi?

Containment: Saldırganın hareket alanı sınırlandı mı?

Bir cihazı network’ten ayırmak her zaman containment değildir. Saldırgan geçerli token, ikinci account veya cloud foothold elde etmişse tek endpoint’in izolasyonu görünür bir aksiyon üretir fakat attack path’i kesmeyebilir.

Etkili containment şu sorularla değerlendirilir:

• Etkilenen bütün identity ve session’lar belirlendi mi?
• Aktif token ve credential’lar geçersiz kılındı mı?
• Persistence noktaları bulundu mu?
• Aynı tekniğin diğer sistemlerdeki izi arandı mı?
• Egress veya command and control channel kapatıldı mı?
• Kritik function için risk gerçekten ortadan kalktı mı?

Başarı yalnızca Red Team’in objective’e ulaşması değildir

Red Team objective’e ulaşamasa bile çalışma değerli olabilir. Güçlü prevention, erken detection veya etkili containment attack chain’i kesmiş olabilir. Buna karşılık Red Team objective’e ulaşsa dahi Blue Team’in saldırıyı erkenden fark edip kontrollü biçimde izlediği bir senaryoda savunma tamamen başarısız sayılmaz.

Bu nedenle sonuç şu iki cümleden biriyle kapatılamaz:

• “Red Team kazandı.”
• “Blue Team kazandı.”

Kurumsal çıktı, attack chain’in her aşamasındaki kontrol performansını ve karar kalitesini göstermelidir.

3. Red Team ile sızma testi arasındaki fark

Red Team ile sızma testi aynı tekniklerden bazılarını kullanabilir. Recon yapılabilir, vulnerability exploit edilebilir, credential elde edilebilir ve privilege escalation denenebilir. Fark yalnızca kullanılan aracın gelişmişliği veya çalışmayı yapan kişinin deneyimi değildir.

Fark, testin cevaplamaya çalıştığı soruda başlar.

Sızma testi şunu sorar:

Red Team ise şunu sorar:

Bu ayrımın teknik sonuçlarını Red Team ile sızma testi arasındaki fark gerçekten nerede başlar? yazımızda ayrıntılı biçimde ele alıyoruz.

Red Team, sızma testi ve Purple Team karşılaştırması

Red Team neden “ileri seviye pentest” değildir?

Bu ifade iki problemi doğurur.

İlk olarak, sızma testinin değerini yanlış tanımlar. İyi bir pentest kapsamlı ve derin teknik analiz gerektirir. Red Team’den daha düşük nitelikli bir iş değildir.

İkinci olarak, Red Team’in savunma ölçümü boyutunu ortadan kaldırır. Bir çalışma tüm zafiyetleri bulmaya çalışıyor, SOC performansını ölçmiyor ve yalnızca teknik bulgu listesi üretiyorsa ekip “Red Team” adı kullansa bile engagement büyük olasılıkla pentest karakterindedir.

4. Red Team ne zaman gerekir, ne zaman erkendir?

Red Team satın almak bir maturity rozeti değildir. Kurumun büyüklüğü, çalışan sayısı veya marka bilinirliği tek başına readiness göstermez.

Çalışma şu koşullarda güçlü değer üretir:

• Kritik business function’lar ve onları destekleyen varlıklar biliniyorsa
• Güncel asset inventory ve ownership modeli bulunuyorsa
• Temel vulnerability management süreci çalışıyorsa
• Merkezi logging ve kullanılabilir telemetry mevcutsa
• SOC veya karşılık gelen monitoring kapasitesi bulunuyorsa
• Incident response rolleri ile escalation kanalları tanımlıysa
• Önceki pentest bulguları takip ediliyor ve kapatılıyorsa
• Testten öğrenilenleri uygulayacak owner ve bütçe varsa
• Yönetim kontrollü bir başarısızlığı öğrenme fırsatı olarak görebiliyorsa

Red Team şu koşullarda erken olabilir:

• Internet-facing kritik açıklar biliniyor fakat kapatılmıyorsa
• Hangi sistemin kime ait olduğu bilinmiyorsa
• Loglar merkezi olarak toplanmıyorsa
• SOC’un hangi use case’leri izlediği belirsizse
• Incident response planı yalnızca doküman üzerinde bulunuyorsa
• Production güvenliği için stop condition ve deconfliction yapılamıyorsa
• Tek hedef “Domain Admin olabiliyor musunuz?” ise
• Sonuçları işleyecek remediation kapasitesi yoksa

Bu durumda adversarial testing gereksiz değildir. Yalnızca doğru başlangıç noktası Red Team olmayabilir. Sızma testi, attack surface review, incident response tabletop, detection assessment veya Purple Team daha fazla değer üretebilir.

Kararı daha ayrıntılı değerlendirmek için Her kurumun Red Team’e ihtiyacı var mı? rehberimizi inceleyebilirsiniz.

Olgunluk seviyesine göre “Red Team’e hazır mısınız?” matrisi

Bu tablo bir sertifika sınavı değildir. Örneğin güçlü bir SOC’u olmayan kurum, yeni devraldığı şirket ağında assumed breach çalışmasıyla segmentasyon riskini değerlendirebilir. Önemli olan test türünü cevaplanacak soruya göre seçmektir.

5. Red Team metodolojisi

Tek bir evrensel Red Team metodolojisi yoktur. İyi operasyonlar farklı çerçevelerden yararlansa da ortak bir mantık izler:

Business objective
        ↓
Threat Intelligence ve scenario
        ↓
Scope, authorization ve Rules of Engagement
        ↓
Recon → Initial Access → Persistence
        ↓
Privilege Escalation → Discovery → Lateral Movement
        ↓
Command and Control → Objective
        ↓
Cleanup → Analysis → Reporting → Purple Team replay

Bu akış doğrusal bir komut listesi değildir. Gerçek bir operasyonda ekip discovery sonrasında farklı attack path’e dönebilir, prevention nedeniyle initial access yöntemini değiştirebilir veya safety gerekçesiyle objective’e ulaşmadan kanıt toplayıp durabilir.

Hazırlık ve Threat Intelligence

Operasyonun ilk teknik adımı port taramak değildir. Önce test hipotezi kurulur.

Hazırlık aşamasında:

• Critical business function belirlenir
• Kabul edilemez business impact tanımlanır
• İlgili threat actor davranışları araştırılır
• Objective ve proof condition yazılır
• Starting condition seçilir
• In-scope, conditional ve out-of-scope varlıklar belirlenir
• Control group oluşturulur
• Stop condition ve emergency contact tanımlanır
• Evidence ve data handling standardı kararlaştırılır

Threat Intelligence yalnızca actor adı seçmek değildir. Kaynağın güncelliği, sektörel alaka düzeyi, actor capability’si ve kurumun attack surface’i birlikte değerlendirilmelidir.

Recon

Recon, hedef hakkında dışarıdan veya yetkilendirilmiş kaynaklardan bilgi toplama aşamasıdır. Amaç yalnızca domain ve IP listesi çıkarmak değildir.

Ekip şunları değerlendirebilir:

• Internet-facing services
• Remote access ve identity entry point’leri
• Cloud footprint
• Public code ve secret exposure
• Teknoloji stack’i
• E-mail ve identity pattern’leri
• Third-party dependency’ler
• Çalışan rolleri ve olası social engineering context’i
• Acquisition, yeni domain veya unutulmuş legacy asset izleri

Recon çıktısı, initial access için en gerçekçi ve en düşük operasyonel riskli yolları belirler.

Initial Access

Initial Access, kurum sınırında ilk yetkisiz foothold’un elde edildiği aşamadır. Yöntem scenario ve Rules of Engagement’a bağlıdır.

Örnek yaklaşım sınıfları:

• Internet-facing application veya infrastructure weakness
• Valid account kullanımı
• Kontrollü phishing veya diğer social engineering yöntemleri
• Exposed secret veya yanlış yapılandırılmış cloud resource
• Third-party access path
• Önceden verilen foothold ile assumed breach başlangıcı

Social engineering otomatik olarak scope’a dahil değildir. Çalışanların kişisel verileri, iletişim kanalları, hedef rolleri ve hangi pretext’lerin yasak olduğu yazılı biçimde belirlenmelidir.

Persistence

Persistence, ilk erişim kaybedilse bile kontrollü biçimde yeniden erişebilme kabiliyetidir. Production ortamında gereksiz kalıcılık yüksek risk doğurabilir. Bu nedenle persistence technique’leri açıkça yetkilendirilmeli ve cleanup planına bağlanmalıdır.

Bazı operasyonlarda kalıcı değişiklik yapmak yerine inert marker, kısa ömürlü test account’u veya control group tarafından yerleştirilen synthetic artifact kullanılabilir.

Privilege Escalation ve Discovery

İlk erişimin değeri, erişilen hesabın veya sistemin yetkisiyle sınırlıdır. Operator, local ve merkezi privilege boundary’leri ile environment yapısını anlamaya çalışır.

Discovery aşamasında şu sorular önemlidir:

• Hangi identity hangi trust relationship içinde?
• Kritik business function hangi sistemlere bağlı?
• Network ve cloud boundary’leri nasıl kurulmuş?
• Hangi privileged role’ler objective’e erişebilir?
• Monitoring ve security control izleri neler?
• Daha fazla hareket production güvenliği açısından kabul edilebilir mi?

Discovery’nin kendisi de ölçülmesi gereken bir davranıştır. Çok yoğun ve gürültülü enumeration kolay görülebilir. Daha düşük hacimli, native capability kullanan davranışın görünürlüğü farklıdır.

Lateral Movement

Lateral Movement bir host’tan diğerine geçmekten ibaret değildir. Identity, session, management plane, application trust, cloud role ve remote service ilişkileri üzerinden farklı security boundary’lerin aşılmasıdır.

Bu aşama aşağıdaki kontrolleri sınayabilir:

• Network segmentation
• Tiering modeli
• Privileged access workstation kullanımı
• Local administrator yönetimi
• Service account güvenliği
• Remote management kısıtları
• Cloud ve on-premises identity trust’ı
• East-west telemetry

Objective

Objective, teknik yolculuğun kurumsal olarak anlamlı son noktasıdır. Domain Admin, Global Administrator veya database owner olmak bazı senaryolarda ara hedef olabilir. Gerçek objective şu tür bir iş etkisini temsil etmelidir:

• Kritik ödeme akışını yetkisiz etkileyebilme
• Belirli bir customer data set’ine erişebilme
• Backup management plane üzerinden recovery capability’sini riske atabilme
• Üretim planlama sürecinde integrity etkisi oluşturabilme
• Kritik hizmetin yönetim katmanına ilerleyebilme

Production impact çoğu zaman fiilen uygulanmamalıdır. Objective’e ulaşıldığı synthetic data, canary secret, marker, test transaction veya read-only evidence ile gösterilebilir.

Cleanup, analysis ve replay

Operasyon objective’e ulaşıldığında bitmez.

Cleanup aşamasında:

• Test account’ları kaldırılır
• Token ve credential’lar revoke edilir
• Persistence artifact’leri temizlenir
• Cloud resource ve firewall değişiklikleri geri alınır
• Red Team infrastructure’ı kapatılır
• Toplanan data retention politikasına göre işlenir
• Kalan indicator’lar control group ile doğrulanır

Ardından attack timeline, Blue Team evidence’ı ve control behavior birleştirilir. Mümkünse kritik TTP’ler Purple Team oturumunda tekrar çalıştırılarak detection ve response iyileştirmeleri doğrulanır.

6. MITRE ATT&CK Red Team’de nasıl kullanılır?

MITRE ATT&CK, gerçek dünya gözlemlerine dayanan adversary tactics ve techniques bilgi tabanıdır. Red Team için ortak dil sağlar. Fakat tek başına metodoloji, test planı veya başarı skoru değildir.

ATT&CK şu amaçlarla kullanılabilir:

• Threat Intelligence içindeki davranışları normalize etmek
• Scenario için ilgili technique’leri seçmek
• Attack path’i ortak bir terminolojiyle göstermek
• Beklenen telemetry ve detection noktalarını eşleştirmek
• Red Team ile Blue Team evidence’ını karşılaştırmak
• Coverage gap’leri görünür hale getirmek
• Purple Team replay backlog’u oluşturmak

MITRE’nin adversary emulation planları, public threat reporting içindeki davranışları technique zincirlerine dönüştürerek savunmanın ve analytics’in test edilmesine yardım eder. Buradaki değer, matrix’te mümkün olan en çok kutuyu işaretlemek değil, kurum için anlamlı behavior sequence’i çalıştırmaktır.

MITRE ATT&CK tactic ve technique örnekleri

Bu örnekler bir çalışma scope’u değildir. Seçim threat profile, business objective ve safety sınırlarına göre yapılmalıdır.

ATT&CK coverage neden tek başına olgunluk ölçmez?

Bir SIEM ekranında yüzlerce ATT&CK technique’inin yeşil görünmesi yanıltıcı olabilir.

“T1059 covered” ifadesi şu soruların hiçbirine tek başına cevap vermez:

• Technique’in hangi implementation’ı test edildi?
• Hangi operating system ve identity context’i kullanıldı?
• Telemetry bütün endpoint’lerden geliyor mu?
• Alert production gürültüsü içinde fark ediliyor mu?
• Analyst doğru scope’u belirleyebiliyor mu?
• Response playbook ilgili attack path’i gerçekten kesiyor mu?

Coverage binary değildir. En az şu seviyelerde değerlendirilmelidir:

1. 1No visibility: İlgili behavior için telemetry yoktur.
2. 2Telemetry available: Kayıt vardır fakat detection yoktur.
3. 3Detection generated: Alert oluşur.
4. 4Triage successful: Analyst olayı doğru sınıflandırır.
5. 5Scope identified: İlgili asset, identity ve activity bulunur.
6. 6Containment effective: Attack path zamanında kesilir.
7. 7Repeatable: Aynı sonuç kontrollü replay ile tekrar alınabilir.

ATT&CK attack chain’i nasıl anlatır?

ATT&CK technique’leri tek tek göstermek, saldırının akışını kaybettirebilir. Bir initial access davranışının hangi credential access adımına, oradan hangi lateral movement yoluna ve hangi objective’e bağlandığı görülmelidir.

Bu nedenle raporda:

• Technique listesi
• Zaman sıralı attack timeline
• Identity ve asset ilişkileri
• Control decision point’leri
• Objective’e giden alternatif yollar

birlikte sunulmalıdır. MITRE CTID Attack Flow gibi modeller, technique’lerin sequence ve relationship içinde anlatılmasına yardımcı olabilir.

7. TIBER-EU, CBEST ve threat-led penetration testing çerçeveleri

Finansal sistemlerde kullanılan TIBER-EU ve CBEST, “daha uzun Red Team” paketleri değildir. Governance, Threat Intelligence, bağımsız gözetim, risk yönetimi, test yürütme ve closure beklentileri tanımlanmış threat-led penetration testing çerçeveleridir.

TIBER-EU nedir?

TIBER-EU, European Central Bank tarafından geliştirilen Threat Intelligence-based Ethical Red Teaming çerçevesidir. Kritik işlevleri destekleyen people, process ve technology katmanlarına yönelik kontrollü threat-led testleri ele alır.

Çerçevenin önemli yaklaşımı pass/fail etiketi üretmek yerine öğrenmeyi ve cyber resilience gelişimini desteklemektir. Test yalnızca teknik sistemlere değil, kritik function’ın korunmasına odaklanır.

TIBER-EU 2025 sürümü, DORA kapsamındaki Threat-Led Penetration Testing gereklilikleriyle uyumlu hale getirilmiştir. Bu durum, her Red Team operasyonunun TIBER-EU veya DORA TLPT sayılacağı anlamına gelmez.

DORA TLPT ile Red Team aynı şey mi?

Hayır. DORA kapsamındaki TLPT, belirli finansal kuruluşlar için düzenleyici teknik standartlara bağlı bir süreçtir. Provider gereklilikleri, scope, control team, risk assessment, testing phase ve reporting beklentileri mevzuatla tanımlanır.

Örneğin ilgili Avrupa Birliği teknik standardı kapsamındaki active testing phase için en az 12 haftalık bir dönem öngörülür. Bu süre, genel pazardaki her Red Team hizmeti için alt sınır değildir. Regulated TLPT’nin governance ve test gereksinimlerine özgüdür.

CBEST nedir?

CBEST, Bank of England tarafından finansal kuruluşların ve financial market infrastructure yapılarının cyber resilience seviyesini değerlendirmek amacıyla kullanılan threat intelligence-led assessment yaklaşımıdır.

Resmi implementation guide çalışmayı dört ana phase altında ele alır:

1. 1Initiation
2. 2Threat Intelligence
3. 3Penetration Testing
4. 4Closure

CBEST programları kapsam, düzenleyici katılım, Threat Intelligence çalışması, control group ve remediation planı nedeniyle aylar sürebilir. Rehberdeki yaklaşık süreler bütün lifecycle için 9 ila 12 aylık bir planlama ölçeğine işaret eder. Bu rakam, standart bir ticari Red Team operasyonunun süresi veya piyasa normu olarak kullanılmamalıdır.

Hangi çerçeve ne zaman kullanılır?

Kurum regulated bir çerçeveye tabi değilse bile bazı tasarım ilkelerinden yararlanabilir. Critical function odaklı scope, bağımsız Threat Intelligence, control group, risk assessment ve evidence standardı bunlar arasındadır. Ancak hizmeti yanlış biçimde “TIBER uyumlu” veya “CBEST testi” olarak adlandırmak yerine gerçek governance kapsamı açıkça belirtilmelidir.

8. Red Team senaryosu nasıl kurgulanır?

İyi senaryo bir technique listesinden başlamaz. Önce korunması gereken business function, kabul edilemez impact ve bunları hedefleyebilecek gerçekçi adversary intent tanımlanır.

Kullanılabilir bir Red Team senaryosunda şu bileşenler bulunur:

1. 1Business objective: Hangi kurumsal risk sınanıyor?
2. 2Threat rationale: Bu actor veya capability kurum için neden gerçekçi?
3. 3Starting condition: Internet’ten mi başlanıyor, credential mı veriliyor, foothold mu sağlanıyor?
4. 4Scope: Hangi system, identity, location ve third-party boundary yetkili?
5. 5Attack path hypothesis: Objective’e hangi olası yollarla ilerlenebilir?
6. 6Rules of Engagement: Hangi action serbest, koşullu veya yasak?
7. 7Flag veya proof condition: Objective’e zarar vermeden ulaşıldığı nasıl kanıtlanacak?
8. 8Control expectation: Hangi prevention, detection ve response davranışı bekleniyor?
9. 9Success criteria: Hangi metric ve evidence sonuç sayılacak?
10. 10Stop condition: Operasyon hangi durumda derhal duracak?

Bu tasarımın nasıl yapılacağını örnek scenario document, ölçüm modeli ve yanlış objective örnekleriyle Red Team senaryosu nasıl yazılır? yazımızda anlatıyoruz.

Zayıf ve güçlü senaryo arasındaki fark

Zayıf bir talep şöyledir:

Daha güçlü bir senaryo şöyle yazılabilir:

İkinci örnek:

• Hangi business function’ın test edildiğini açıklar
• Threat rationale gerektirir
• Technical objective’i iş etkisine bağlar
• Gerçek data kullanımını sınırlar
• Savunma ölçümünü tanımlar

Red Team başarısı için tek eşik neden yetmez?

“Objective’e ulaştı veya ulaşamadı” sonucu fazla kabadır. En az şu scorecard kullanılmalıdır:

9. Assumed breach ile full-scope Red Team farkı

İki yaklaşım arasındaki temel fark başlangıç koşuludur.

Full-scope Red Team

Full-scope operasyonda ekip gerçekçi dış başlangıç noktasından ilerlemeye çalışır. Recon ve Initial Access testin önemli parçalarıdır.

Avantajları:

• External attack surface ve initial access kontrollerini değerlendirir
• Gerçek threat actor yolculuğuna daha yakın olabilir
• E-mail, identity, perimeter ve endpoint katmanlarını birlikte test edebilir

Sınırlamaları:

• Initial access sağlanamazsa internal detection ve response yeterince test edilemeyebilir
• Daha uzun zaman ve daha geniş authorization gerektirir
• Social engineering veya third-party sınırları operasyonu daraltabilir
• Sonuç tek bir giriş yöntemine fazla bağımlı kalabilir

Assumed breach

Assumed breach modelinde Red Team’e önceden tanımlanmış bir foothold, low-privilege account, workstation veya cloud identity verilir. “İlk savunma katmanı aşıldı” varsayımıyla iç ilerleme test edilir.

Avantajları:

• Süreyi internal attack path ve savunma ölçümüne ayırır
• Initial access başarısına bağımlılığı azaltır
• Identity, lateral movement, privilege ve objective katmanlarını derinleştirir
• Belirli SOC use case’lerini daha kontrollü ölçer

Sınırlamaları:

• Recon ve initial access gerçekçiliğini ölçmez
• Verilen foothold gerçek threat profile ile uyumsuzsa yapay sonuç üretebilir
• Başlangıç ayrıcalığı gereğinden yüksek seçilirse kritik trust boundary’ler atlanabilir

Hybrid yaklaşım

Birçok kurum için en verimli model hybrid olabilir. Red Team belirli süre boyunca full-scope initial access dener. Tanımlı checkpoint’e kadar erişim sağlanamazsa control group önceden kararlaştırılmış bir leg-up verir.

Bu yaklaşım perimeter başarısını görünür tutarken internal detection ve response ölçümünün de yapılmasını sağlar. Leg-up kullanıldığı raporda açıkça belirtilmeli ve sonraki sonuçlar “Internet’ten kesintisiz compromise” gibi sunulmamalıdır.

10. Purple Team ve BAS ile ilişkisi

Red Team, Purple Team ve Breach and Attack Simulation aynı probleme farklı ölçüm biçimleriyle yaklaşır.

Purple Team

Purple Team ayrı renkte üçüncü bir saldırı ekibi değildir. Red ve Blue tarafların belirli behavior’ları birlikte çalıştırdığı, telemetry ve detection sonucunu hızlı feedback döngüsüyle geliştirdiği iş birliği modelidir.

Red Team operasyonundan sonra:

• Görülmeyen technique tekrar çalıştırılabilir
• Eksik telemetry source devreye alınabilir
• Detection rule geliştirilebilir
• Analyst query ve playbook iyileştirilebilir
• Containment action kontrollü biçimde doğrulanabilir

Bu yüzden Purple Team çoğu zaman Red Team’in doğal devamıdır.

BAS

BAS platformları önceden tanımlanmış attack action’larını tekrar edilebilir biçimde çalıştırarak control validation sağlar. Sürekli veya yüksek frekanslı testlerde değerlidir.

Fakat BAS:

• İnsan operator’ın adaptif kararını
• Yeni attack path geliştirmesini
• Threat Intelligence yorumunu
• Social engineering ve gerçekçi OPSEC’i
• Karmaşık business objective muhakemesini

tek başına yerine koymaz.

Red Team yeni ve beklenmeyen yolları ortaya çıkarabilir. Purple Team belirli boşluğu birlikte kapatır. BAS ise seçilmiş kontrollerin zaman içinde bozulup bozulmadığını tekrar tekrar kontrol eder.

Üç yaklaşımın hangi güvenlik iddiasını ölçtüğünü Purple Team, Red Team ve BAS: hangi çalışma neyi ölçer? rehberimizde karşılaştırıyoruz.

11. Red Team kapsamı ve Rules of Engagement

Red Team kapsamı yalnızca IP veya domain listesi değildir. Objective’e ulaşmak için kullanılabilecek ve etkilenebilecek bütün trust boundary’leri içerir.

Kapsam şu katmanlarda tanımlanmalıdır:

• Business function
• Legal entity
• Domain, IP ve CIDR
• Cloud tenant ve subscription
• Application ve API
• Identity provider ve directory
• Endpoint sınıfı
• Network segment
• E-mail domain
• Physical location
• Third-party service
• Kullanıcı ve rol grubu
• Test window

In-scope, conditional ve out-of-scope

İkili scope modeli Red Team için çoğu zaman yetersizdir.

In-scope asset ve action’lar doğrudan test edilebilir.

Conditional scope belirli onay, zaman veya safety koşuluyla test edilebilir. Örneğin production database üzerinde read-only validation veya belirli executive role’e yönelik social engineering ayrı onay gerektirebilir.

Out-of-scope varlık ve action’lar açık biçimde yasaktır.

Bu ayrım, operator’ın gerçek zamanlı kararlarında belirsizliği azaltır.

Rules of Engagement neleri içermeli?

NIST, Rules of Engagement kavramını security testing yürütülmeden önce belirlenen ayrıntılı kural ve kısıtlar olarak tanımlar. Red Team bağlamında doküman en az şu alanları kapsamalıdır:

• Yazılı authorization ve yetkili tüzel kişiler
• Objective ve success criteria
• In-scope, conditional ve out-of-scope varlıklar
• İzin verilen ve yasaklanan TTP’ler
• Social engineering sınırları
• Physical security sınırları
• Kullanılabilecek account ve data türleri
• Production impact toleransı
• Test günleri ve saatleri
• Rate limit ve kaynak tüketimi sınırları
• Control group üyeleri
• Emergency contact ve iletişim kanalı
• Deconfliction yöntemi
• Stop condition ve kill switch
• Third-party izinleri
• Evidence toplama ve data minimization
• Encryption, retention ve secure deletion kuralları
• Cleanup sorumluluğu
• Disclosure ve raporlama süreci

Stop condition örnekleri

Operasyon şu durumlarda otomatik veya control group onayıyla durdurulabilir:

• Production availability etkisi gözlenmesi
• Gerçek customer data’ya beklenmeyen erişim
• Sağlık, safety veya fiziksel güvenlik riski
• Gerçek incident ile test aktivitesinin çakışması
• Yetkisiz third-party boundary’ye geçiş
• Account lockout veya kaynak tüketiminin belirlenen eşiği aşması
• EDR ya da SOC’un test infrastructure’ını gerçek saldırgan sanarak dış aksiyon başlatması
• Hukuki veya düzenleyici sınırın belirsiz hale gelmesi

Stop condition yazılması Red Team’in etkisini azaltmaz. Production üzerinde kontrollü çalışma yapılabilmesinin ön şartıdır.

Control group neden küçük tutulur?

Testi bilen kişi sayısı arttıkça observer effect oluşur. SOC analyst’i veya system owner davranışını farkında olmadan değiştirebilir.

Control group yalnızca şu işlevler için gerekli kişilerden oluşmalıdır:

• Authorization
• Safety ve risk yönetimi
• Deconfliction
• Acil durdurma
• Third-party koordinasyonu
• Gerekli leg-up ve flag yönetimi

SOC’un tamamının testi bilmesi gerekmez. Ancak bu, savunma ekibinden herkesi her koşulda habersiz bırakmak anlamına gelmez. Hukuki, operasyonel ve çalışan güvenliği gereksinimleri önceliklidir.

12. SOC, EDR ve SIEM Red Team’de nasıl test edilir?

Bir ürünün kurulmuş olması, ilgili attack behavior’a karşı etkili olduğu anlamına gelmez. EDR agent aktif görünebilir fakat policy belirli server grubunda audit mode’da olabilir. SIEM log alabilir fakat timestamp normalization bozuk olabilir. Detection rule alert üretebilir fakat case enrichment eksik olduğu için analyst yanlış karar verebilir.

Red Team ürün isimlerini değil, end-to-end control outcome’u test etmelidir.

EDR için ölçülebilecek alanlar

• Sensor coverage ve health
• Prevention policy sonucu
• Process ve thread telemetry
• Parent-child process ilişkisi
• Memory ve credential access visibility
• Network connection telemetry
• Tamper protection
• Host isolation ve response action
• Analyst’in raw telemetry’ye erişimi

SIEM için ölçülebilecek alanlar

• Log source coverage
• Event ingestion gecikmesi
• Field normalization
• Identity ve asset enrichment
• Cross-source correlation
• Detection rule logic’i
• Suppression ve threshold etkisi
• Case creation ve severity
• Retention
• Query performansı

SOC için ölçülebilecek alanlar

• Alert triage doğruluğu
• Benign positive ile incident ayrımı
• Investigation derinliği
• Attack chain korelasyonu
• Scope belirleme
• Escalation
• Business context kullanımı
• Containment kararı
• İletişim ve handoff
• Evidence preservation

Kullanılabilir zaman ölçümleri

Tek bir Mean Time to Detect değeri bütün süreci açıklamaz. Aşağıdaki timestamp’ler ayrı tutulmalıdır:

Metric tanımları engagement başlamadan yazılmalıdır. “Detected” kelimesi bir ekip için alert oluşumu, başka bir ekip için analyst doğrulaması anlamına gelirse sonuç karşılaştırılamaz.

Red Team’in amacı SOC’u utandırmak değildir

Blame odaklı bir çalışma, analyst’lerin test evidence’ını savunmacı biçimde yorumlamasına ve gerçek öğrenmenin kaybolmasına neden olur.

Rapor:

• “SOC görmedi” demekle yetinmemeli
• Gerekli telemetry’nin bulunup bulunmadığını göstermeli
• Detection rule’un neden çalışmadığını ayırmalı
• Alert varsa triage kararını incelemeli
• Process, ownership ve tooling nedenlerini farklılaştırmalı
• Uygulanabilir düzeltmeyi owner ve priority ile eşleştirmeli

İnsan hatası görünen birçok problem aslında eksik context, aşırı alert yükü, kötü case enrichment veya belirsiz escalation criteria kaynaklıdır.

13. Red Team raporu neleri içerir?

Red Team raporu uzun bir pentest bulgu listesi olmamalıdır. Yönetimin, security leadership’in, SOC’un, detection engineering ekibinin ve teknik owner’ların aynı operasyonu kendi karar alanları açısından anlayabilmesi gerekir.

İyi bir rapor en az iki katmanlıdır.

Executive rapor

Executive bölüm şunları açıklar:

• Test edilen critical business function
• Threat scenario ve neden seçildiği
• Objective sonucu
• En önemli attack path’ler
• Prevention, detection, response ve containment sonucu
• Olası business impact
• Systemic control gap’ler
• Öncelikli yatırım ve karar alanları
• Risk acceptance gerektiren konular

Bu bölüm teknik ayrıntıyı tamamen kaldırmamalı, fakat tool ve command listesine de dönüşmemelidir.

Teknik rapor

Teknik bölümde şu bileşenler bulunmalıdır:

1. 1Engagement scope ve Rules of Engagement özeti
2. 2Starting condition ve kullanılan leg-up’lar
3. 3Threat Intelligence ve scenario rationale
4. 4Zaman damgalı attack timeline
5. 5Attack chain ve alternatif path’ler
6. 6MITRE ATT&CK TTP eşlemesi
7. 7Kullanılan infrastructure ve artifact’ler
8. 8Elde edilen access ve privilege seviyeleri
9. 9Objective proof’u
10. 10Red Team evidence’ı
11. 11EDR, SIEM ve SOC evidence’ı
12. 12Prevention, visibility, detection, investigation ve containment sonucu
13. 13IOC listesi
14. 14Cleanup doğrulaması
15. 15Remediation ve validation planı

IOC ve TTP neden birlikte verilmelidir?

IOC kısa ömürlü olabilir. Domain, IP, file hash veya certificate test sonrasında değişebilir. Bunlar incident hunting ve cleanup için yine de gereklidir.

TTP ise davranışın daha kalıcı tarafını açıklar. Valid account kullanımını yalnızca test IP’sini block ederek kapatmak, asıl identity kontrol açığını çözmez.

Rapor hem “ne kullanıldı?” hem “hangi behavior ve control gap istismar edildi?” sorusuna cevap vermelidir.

Her bulgu CVSS ile puanlanmalı mı?

Red Team’de bazı teknik vulnerability’ler CVSS ile değerlendirilebilir. Fakat attack chain ve response gap’leri yalnızca CVSS’e indirgemek doğru değildir.

Örneğin:

• SIEM log source eksikliği tek bir vulnerability değildir
• SOC escalation gecikmesi CVSS vektörüne sığmaz
• İki düşük riskli configuration’ın attack path içinde birleşmesi yüksek business impact oluşturabilir
• Critical identity trust’ın abuse edilmesi ürün açığından kaynaklanmayabilir

Bu nedenle raporda teknik severity yanında:

• Business impact
• Attack path contribution
• Exploit precondition
• Detection durumu
• Control ownership
• Remediation dependency

gösterilmelidir.

Aksiyon planı nasıl önceliklendirilir?

Öneriler yalnızca “EDR kuralı yazın” veya “MFA kullanın” seviyesinde kalmamalıdır.

Her aksiyon için:

• Kök neden
• Etkilenen attack path
• Beklenen control outcome
• Owner
• Öncelik
• Bağımlılık
• Kısa ve uzun vadeli çözüm
• Validation yöntemi
• Hedef tarih

tanımlanmalıdır.

En iyi çıktı, rapor teslim toplantısıyla kapanmaz. Kritik attack step’ler için Purple Team replay ve gerekiyorsa hedefli retest planlanır.

14. Red Team süresi ve maliyetini etkileyen faktörler

“Red Team ne kadar sürer?” ve “Red Team fiyatı nedir?” sorularına scope görülmeden verilen kesin cevaplar güvenilir değildir.

Bir adet assumed breach senaryosuyla iki network segmentini değerlendirmek ile çok ülkeli bir kurumda external recon, social engineering, cloud, on-premises identity ve kritik işlevleri kapsayan full-scope operasyon aynı çalışma değildir.

Süreyi değiştiren temel faktörler

1. 1Objective sayısı: Her objective farklı attack path ve evidence gerektirebilir.
2. 2Full-scope veya assumed breach seçimi: External Initial Access için ayrılan süre büyük fark yaratır.
3. 3Threat Intelligence derinliği: Kuruma özel target threat assessment ayrı hazırlık ister.
4. 4Kapsam büyüklüğü: Domain, tenant, ülke, business unit ve technology çeşitliliği süreyi artırır.
5. 5Social engineering ve physical scope: Hazırlık, approval ve safety gereksinimleri farklıdır.
6. 6Testing window: Yalnızca belirli saatlerde çalışma yapılabilmesi operasyonu uzatabilir.
7. 7Third-party bağımlılıkları: Yazılı izin ve koordinasyon gerekir.
8. 8Control group ve approval hızı: Conditional action kararları gecikirse operasyon bekler.
9. 9Stealth beklentisi: Düşük hacimli ve adaptif yaklaşım daha fazla zaman gerektirir.
10. 10Raporlama ve replay kapsamı: Teknik rapor, executive workshop ve Purple Team doğrulaması ayrı efor oluşturur.
11. 11Regulatory framework: TIBER-EU, DORA TLPT veya CBEST gibi çerçeveler ek governance gerektirir.
12. 12Temizleme ve data handling: Çoklu environment ve test infrastructure daha kapsamlı closure ister.

Genel süre aralıkları nasıl yorumlanmalı?

Regulated olmayan ticari çalışmalarda:

• Dar kapsamlı assumed breach operasyonu birkaç hafta sürebilir
• Tek veya sınırlı objective içeren kurumsal Red Team çoğu zaman yaklaşık 4 ila 8 haftalık takvim gerektirebilir
• Geniş full-scope, çoklu scenario veya cross-domain operasyonlar 8 ila 12 haftayı aşabilir

Bunlar garanti veya sektör standardı değildir. Hazırlık, Threat Intelligence, aktif operasyon, bekleme pencereleri, analiz ve raporlama dahil edilip edilmediğine göre aynı “6 hafta” ifadesi farklı şeyler anlatabilir.

Regulated TLPT programları daha uzun olabilir. DORA teknik standardındaki 12 haftalık active testing phase veya CBEST lifecycle planı genel Red Team tekliflerine doğrudan kıyas olarak kullanılmamalıdır.

Maliyeti belirleyen gerçek değişkenler

Maliyet yalnızca kişi/gün sayısı değildir. Şunlardan etkilenir:

• Operator sayısı ve uzmanlık dağılımı
• Threat Intelligence ekibinin kapsamı
• Proje yönetimi ve control group koordinasyonu
• Test infrastructure’ı
• Cloud, Active Directory, application, mobile veya OT uzmanlığı
• Social engineering içeriği ve hedef sayısı
• Fiziksel lokasyon ve seyahat gereksinimi
• Gece veya hafta sonu testing window’u
• Third-party koordinasyonu
• Regulated framework gereksinimleri
• Rapor ve workshop sayısı
• Purple Team replay veya retest
• Data residency ve ek güvenlik yükümlülükleri

En düşük fiyatı seçmek, özellikle scope ve deliverable belirsizse, pahalı bir “erişim sağlandı” hikâyesi satın almakla sonuçlanabilir. Tekliflerin aynı objective, başlangıç koşulu, active testing süresi, ekip yapısı ve çıktı seti üzerinden karşılaştırılması gerekir.

15. Red Team ekibinde hangi yetkinlikler olmalı?

Red Team tek bir “star hacker” etrafında kurulmaz. Objective’e göre farklı uzmanlıkların birleşmesi gerekir.

Teknik yetkinlik alanları

• External reconnaissance ve attack surface analizi
• Web application ve API exploitation
• Active Directory ve Windows enterprise security
• Linux ve infrastructure security
• Cloud identity ve control plane
• Endpoint ve EDR davranışı
• Network pivoting ve segmentation
• Credential ve session security
• Social engineering, yalnızca kapsamdaysa
• Command and control ve operasyonel güvenlik
• Detection engineering ve incident response
• Scripting ve güvenli tool geliştirme
• Evidence toplama ve cleanup

Operasyonel yetkinlikler

• Rules of Engagement yorumlama
• Production risk değerlendirmesi
• Düşük etkili proof tasarımı
• Deconfliction
• Control group iletişimi
• Hukuki ve etik sınır farkındalığı
• Threat Intelligence analizi
• Teknik ve executive raporlama
• Workshop yürütme

OSCP, OSEP ve CRTO ne gösterir?

Sertifikalar belirli bilgi alanları için sinyal olabilir:

• OSCP, hands-on penetration testing ve temel exploitation yetkinliğine ilişkin bir gösterge olabilir.
• OSEP, advanced evasion, enterprise network ve adversary-style tradecraft alanında ilgili bir gösterge olabilir.
• CRTO, Active Directory, command and control ve Red Team operasyonlarına yönelik pratik deneyimi işaret edebilir.
• OSWE, web application ve source-assisted exploitation derinliği açısından özellikle application-heavy attack path’lerde değerlidir.

Ancak sertifika engagement kalitesini tek başına kanıtlamaz. Gerçek iş örnekleri, ekip rol dağılımı, production güvenliği, threat-led scenario tasarımı, detection bilgisi ve raporlama standardı birlikte değerlendirilmelidir.

SECNODEX ekibindeki OSCP ve OSWE sertifikalı uzmanların katkısı da yalnızca logolarla anlatılmaz. Network ve application katmanlarını aynı attack path içinde okuyabilmek, erişimi iş etkisine bağlamak ve teknik kanıtı uygulanabilir remediation’a dönüştürmek hizmet kalitesinin asıl göstergesidir.

Red Team ile Threat Intelligence ekibi ayrılmalı mı?

Regulated programlarda Threat Intelligence ve Red Team provider’ları için belirli bağımsızlık veya yeterlilik beklentileri olabilir. Kuruma özel ticari çalışmalarda model değişebilir.

Önemli olan:

• Threat assessment’ın kanıta dayanması
• Technique seçiminin gerekçesinin yazılması
• Varsayım ile doğrulanmış bilginin ayrılması
• Operator’ın yalnızca alışkın olduğu yöntemi scenario’ya zorlamaması
• Intelligence güncellendiğinde test planının revize edilebilmesi

16. Red Team hizmeti alırken 10 kontrol maddesi

Kurumsal Red Team hizmeti seçerken yalnızca sertifika logolarına, tool listesine veya “tespit edilmeden ilerleriz” iddiasına bakılmamalıdır.

1. Objective nasıl tanımlanıyor?

Provider ilk toplantıda yalnızca IP sayısını ve domain listesini soruyorsa çalışma pentest mantığında kalabilir. Critical business function, threat scenario ve success criteria konuşulmalıdır.

2. Sızma testi ile Red Team ayrımı açık mı?

Teklif coverage, zafiyet sayısı ve standart test checklist’i üzerinden yazılmışsa Red Team adı verilmiş bir pentest olabilir. SECNODEX Red Team hizmeti, objective ve savunma ölçümünü engagement’ın merkezine alır.

3. Threat Intelligence nasıl kullanılıyor?

“APT benzeri saldırı” yeterli değildir. Actor behavior’ının kurumun sektörü, teknolojisi ve iş riskiyle neden ilişkili olduğu açıklanmalıdır.

4. Scope ve Rules of Engagement yeterince ayrıntılı mı?

In-scope asset listesi tek başına yetmez. Conditional action’lar, prohibited techniques, test window, stop condition, third-party izinleri ve data handling yazılmalıdır.

5. Production güvenliği nasıl korunuyor?

Provider’ın kill switch, emergency contact, deconfliction, rate limit, synthetic data, safe proof ve cleanup yaklaşımı sorulmalıdır.

6. Ekipte hangi roller bulunuyor?

Lead, operator, Threat Intelligence analyst, project manager ve gerekli uzmanlık alanları açıklanmalıdır. CV’deki sertifikadan çok engagement’taki gerçek rol sorulmalıdır.

7. SOC ve response nasıl ölçülüyor?

Yalnızca “EDR bizi yakaladı mı?” yaklaşımı yetersizdir. Visibility, alert, triage, investigation, scope ve containment için ayrı ölçümler bulunmalıdır.

8. Rapor hangi evidence’ı içeriyor?

Örnek raporda attack timeline, TTP mapping, control decision point, Red Team ve Blue Team evidence’ı, business impact ve uygulanabilir aksiyon planı aranmalıdır.

9. Data protection ve cleanup nasıl yönetiliyor?

Toplanan verinin minimization, encryption, access, retention ve secure deletion kuralları sözleşmede yer almalıdır. Test account, token, persistence ve infrastructure kapanışı doğrulanmalıdır.

10. Çalışma raporla mı bitiyor?

Kritik bulgular için remediation workshop, Purple Team replay veya retest seçeneği bulunmalıdır. Amaç etkileyici bir attack story teslim etmek değil, savunmada ölçülebilir değişiklik oluşturmaktır.

Teklifte istenebilecek somut deliverable’lar

• Scoping document
• Threat Intelligence summary veya Target Threat Intelligence Report
• Scenario document
• Red Team test plan
• Rules of Engagement
• Contact ve deconfliction matrix
• Daily veya exception-based status modeli
• Executive report
• Technical report
• Attack timeline ve attack flow
• MITRE ATT&CK mapping
• IOC ve artifact listesi
• Cleanup statement
• Remediation workshop
• Purple Team replay planı

İhtiyacınızın Red Team mi yoksa daha kapsamlı teknik vulnerability değerlendirmesi mi olduğundan emin değilseniz SECNODEX sızma testi hizmetini de karşılaştırabilirsiniz.

18. Sonuç: Red Team bir saldırı gösterisi değil, savunma ölçümüdür

Red Team’in etkileyici kısmı exploit, command and control veya lateral movement olabilir. Kurumsal değer ise başka yerde oluşur:

• Hangi güvenlik varsayımının yanlış olduğu
• Attack chain’in nerede görünmez hale geldiği
• Hangi alert’in bağlama dönüşmediği
• Incident scope’unun neden eksik kaldığı
• Containment kararının hangi bağımlılık yüzünden geciktiği
• Teknik erişimin hangi business objective’i riske attığı
• Hangi düzeltmenin attack path’i gerçekten keseceği

net biçimde gösterildiğinde.

İyi Red Team operasyonu “biz girdik” cümlesiyle bitmez. Kurumun bir sonraki gerçek saldırıda daha erken görmesini, daha doğru karar vermesini ve kritik işlevini daha güvenli sürdürmesini sağlayacak ölçülebilir bir gelişim planı bırakır.

SECNODEX, Red Team çalışmalarını hazır bir technique listesi üzerinden değil, kurumun critical business function’ı, threat profile’ı ve savunma hedefleri üzerinden tasarlar. OSCP ve OSWE sertifikalı uzmanların network, identity, web application ve API güvenliği deneyimi, attack path’in farklı katmanlarda teknik olarak doğrulanmasına katkı sağlar. Çalışma boyunca Rules of Engagement, production güvenliği, evidence standardı ve savunma ölçümü birlikte ele alınır.

Kurumunuzun Red Team’e hazır olup olmadığını değerlendirmek, doğru objective’i belirlemek ve uygulanabilir bir scope oluşturmak için SECNODEX ile iletişime geçebilirsiniz.

Kaynaklar ve ileri okuma

• NIST CSRC — Red Team Exercise
• NIST CSRC — Rules of Engagement
• MITRE ATT&CK — Adversary Emulation and Red Teaming
• MITRE ATT&CK — Adversary Emulation Plans
• MITRE Center for Threat-Informed Defense — Attack Flow
• European Central Bank — TIBER-EU
• European Central Bank — TIBER-EU Framework 2025
• EUR-Lex — Commission Delegated Regulation (EU) 2025/1190
• Bank of England — CBEST Implementation Guide