Purple Team, Red Team ve BAS: Hangi Çalışma Neyi Ölçer?

Bir kurumun BAS dashboard'u endpoint kontrollerinin yüzde 94 başarılı olduğunu gösteriyor. Aynı kurumda yürütülen Red Team operasyonu, internet-facing bir sistemden başlayıp kritik finansal uygulamaya ulaşıyor. Operasyon sırasında SOC saldırı zincirini zamanında fark edemiyor.

Birkaç hafta sonra yapılan Purple Team çalışmasında ise Red Team'in kullandığı bazı teknikler anında alert üretirken bazıları yalnızca endpoint üzerinde log bırakıyor. Bir grup telemetry SIEM'e hiç ulaşmıyor. Alert üreten başka bir davranış ise yanlış queue'ya yönlendirildiği için analyst tarafından incelenmiyor.

Bu üç sonuç birbiriyle çelişiyor mu?

Hayır. Çünkü üç çalışma aynı şeyi ölçmüyor.

BAS platformundaki yüzde 94, seçilmiş test case'lerin belirli control configuration'ları karşısındaki sonucunu gösterebilir. Purple Team, aynı veya benzer davranışların telemetry, detection ve response zincirinde nerede kaybolduğunu ortaya çıkarabilir. Red Team ise gerçekçi bir adversary'nin belirsizlik, savunma ve operasyonel kısıtlar altında kritik hedefe ulaşıp ulaşamadığını sınar.

Üçünde de MITRE ATT&CK technique ID'leri, endpoint testleri, command execution, credential access veya lateral movement görülebilir. Aynı test library'si bile kullanılabilir. Buna rağmen amaç, çalışma biçimi, ölçüm birimi ve kanıt kalitesi farklıdır.

Yanlış seçim genellikle üç biçimde sonuçlanır:

• BAS satın alınır ve “Red Team artık gereksiz” denir
• Red Team raporundan bütün ATT&CK technique'leri için detection coverage beklenir
• Purple Team adı altında yalnızca attack script çalıştırılıp SOC'a alert gelip gelmediği sorulur

Bu yazıda Purple Team, Red Team ve BAS arasındaki farkı ürün etiketi üzerinden değil, ölçüm teorisi üzerinden ele alacağız. Hangi çalışmanın hangi soruya cevap verdiğini, hangi sonucu kanıtlayamadığını, metric'lerin nasıl yanlış yorumlandığını ve üçünün aynı security validation programında nasıl birleştirilebileceğini teknik ayrıntılarıyla inceleyeceğiz.

Önce doğru soruyu soralım: Neyi ölçmek istiyorsunuz?

Bir güvenlik çalışmasının adı, cevaplanacak sorudan sonra gelmelidir.

Kurum şu soruyu soruyorsa Red Team'e yaklaşıyordur:

Şu soruyu soruyorsa Purple Team'e yaklaşıyordur:

Şu soruyu soruyorsa BAS'e yaklaşıyordur:

Bu sorular birbirinin yerine geçmez.

Bir EDR policy update'inden sonra seçilmiş 200 endpoint testinin hâlâ block veya alert üretip üretmediğini her hafta doğrulamak için Red Team verimsizdir. BAS daha uygundur.

SOC'un belirli bir credential access tekniğine ait telemetry'yi neden göremediğini Red Team operasyonu sırasında canlı biçimde çözmeye çalışmak stealth ve zero-knowledge varsayımını bozar. Bu ihtiyaç Purple Team'e aittir.

Kritik ödeme sistemine giden beklenmeyen trust relationship'i, operator'ın savunmaya göre yöntem değiştirip ilerlemesini ve Control Team dışındaki ekiplerin gerçek response davranışını ölçmek için yalnızca prebuilt BAS testleri yeterli değildir. Burada Red Team gerekir.

Üç çalışmayı tek cümlede ayırmak mümkün mü?

Evet, fakat tanımların sınırını doğru çizmek gerekir.

Red Team

Gerçekçi bir adversary'yi, belirlenmiş mission objective doğrultusunda emüle eder. İnsan operator belirsizlik içinde karar verir, attack path kurar, gerektiğinde yöntem değiştirir ve prevention, detection ile response kontrollerini zincir halinde sınar.

Purple Team

Red Team, Blue Team, Detection Engineering, SOC, DFIR ve gerektiğinde Threat Intelligence rollerinin açık bilgi paylaşımıyla birlikte çalıştığı bir validation ve improvement modelidir. Odak yalnızca saldırının başarılı olması değil, her behavior için visibility ve response gap'inin bulunup aynı çalışma içinde iyileştirilmesidir.

BAS

Önceden tanımlanmış attack action veya scenario'ları güvenli, otomatik ve tekrarlanabilir biçimde çalıştıran security validation capability'sidir. Belirli control'lerin beklenen prevention, telemetry veya detection sonucunu üretip üretmediğini düzenli olarak doğrular.

Bu tanımlar arasında overlap vardır. Purple Team BAS kullanabilir. Red Team adversary emulation platformundan yararlanabilir. BAS platformu multi-step attack chain çalıştırabilir. Ayrım kullanılan tool'da değil, sonucu anlamlandıran çalışma modelindedir.

Purple Team bir ekip mi, çalışma biçimi mi?

Her kurumda aynı değildir.

Purple Team şu biçimlerde kurulabilir:

1. 1Belirli tarihlerde yapılan Purple Team Exercise
2. 2Red Team ile Blue Team'in düzenli validation süreci
3. 3Detection Engineering içinde kalıcı bir Purple Team function
4. 4BAS platformunu ve detection regression testlerini yöneten özel ekip
5. 5Red Team operasyonu sonrasındaki reveal ve replay aşaması

Purple Team Exercise Framework v3, Purple Team'i Threat Intelligence, Red Team ve Blue Team becerilerinin iş birliği olarak ele alır. Framework, ad hoc exercise'tan operationalized programa ve dedicated role modeline kadar farklı uygulama biçimleri tanımlar.

Dolayısıyla Purple Team için mutlaka organizasyon şemasında “Purple Team” adlı ayrı departman bulunması gerekmez. Fakat yalnızca Red Team'in tool çalıştırması da Purple Team değildir.

Gerçek Purple Team için en az şu etkileşim gerekir:

• Offensive action'ın ne yaptığı açıklanır
• Blue Team hangi telemetry'yi gördüğünü gösterir
• Beklenen data source ve field'lar kontrol edilir
• Detection logic incelenir
• Alert enrichment ve routing doğrulanır
• Analyst investigation adımları gözlemlenir
• Gap'in root cause'u bulunur
• Kural, sensor, parser veya process iyileştirilir
• Aynı test yeniden çalıştırılır
• İyileştirmenin kalıcı olması için regression kaydı oluşturulur

Bu feedback loop yoksa yapılan iş çoğunlukla attack simulation veya detection testidir.

BAS tam olarak nedir?

BAS, Breach and Attack Simulation ifadesinin kısaltmasıdır. Piyasadaki ürünler farklı capability setlerine sahip olsa da ortak fikir, saldırgan davranışlarını temsil eden testleri otomatik, güvenli ve tekrarlanabilir biçimde çalıştırmaktır.

BAS platformları şu katmanlardan birini veya birkaçını test edebilir:

• Endpoint prevention
• EDR telemetry ve detection
• Network security control'leri
• Email security gateway
• Web security ve proxy
• Data loss prevention
• Identity ve cloud control'leri
• SIEM analytic'leri
• SOAR automation
• Lateral movement path'leri
• Data exfiltration control'leri

Apache Caldera, autonomous adversary emulation ve automated security assessment için kullanılan açık kaynaklı örneklerden biridir. Atomic Red Team ise MITRE ATT&CK'e map edilmiş küçük, taşınabilir ve tekrarlanabilir testlerden oluşan açık bir library sunar.

Commercial BAS platformları bunlara ek olarak scheduling, agent management, safe payload, control integration, remediation recommendation, attack path, dashboard, trend ve multi-tenant yönetim sağlayabilir.

BAS'in güçlü tarafı aynı testi tekrar çalıştırabilmesidir.

Örneğin:

Test case: PT-EDR-017
Behavior: PowerShell üzerinden encoded command execution
Target profile: Windows 11 production image
Expected prevention: Process başlamadan block
Expected telemetry: Process, parent process ve command line
Expected alert: High-confidence execution analytic
Expected routing: SOC Endpoint queue
Maximum alert latency: 120 saniye

Bu test her EDR policy değişikliğinde, agent upgrade sonrasında veya haftalık schedule ile yeniden çalıştırılabilir. Sonuç değiştiğinde configuration drift erken görülebilir.

Fakat bu test gerçek bir operator'ın hangi initial access yolunu seçeceğini, başarısız olduğunda nasıl adapte olacağını veya aynı behavior'ı farklı tradecraft ile nasıl gizleyeceğini tek başına ölçmez.

Red Team nedir ve temel ölçüm birimi neden technique değildir?

Red Team, mission objective temelli bir adversary emulation çalışmasıdır. Scope yalnızca IP ve application listesiyle değil, crown jewel, critical function, threat scenario, başlangıç varsayımı, Rules of Engagement ve operasyon hedefiyle tanımlanır.

Örnek objective:

Operator şu kararlardan birini verebilir:

• Internet-facing application üzerinden initial access aramak
• Exposed identity service ve credential weakness'lerini araştırmak
• Third-party trust relationship'i değerlendirmek
• Cloud control plane üzerinden ilerlemek
• DMZ ile internal network arasındaki segmentation'ı test etmek
• Service account permission'larıyla lateral movement yapmak
• Farklı bir route daha az riskli görünüyorsa attack path'i değiştirmek

Bu nedenle Red Team'in temel ölçüm birimi tek ATT&CK technique'i değildir. Asıl ölçüm birimleri şunlardır:

• Objective'e erişim
• Attack path'in uzunluğu ve gerekli precondition'lar
• Trust boundary'lerin aşılması
• Prevention noktaları
• Detection ve response davranışı
• Time to Detect
• Time to Scope
• Time to Contain
• Control Team escalation'ları
• İnsan, process ve technology failure'larının birleşimi
• Adversary'nin hangi aşamada durdurulduğu

Bir Red Team operasyonu yalnızca 18 technique kullanmış olabilir. Bu, geri kalan ATT&CK technique'lerinde kurumun güvenli olduğunu göstermez. Operator mission için en uygun path'i seçmiştir, matrix coverage çalışması yapmamıştır.

MITRE ATT&CK'in Adversary Emulation Plans kaynağı, gerçek threat reporting üzerinden adversary behavior modelleyerek defender'ların network ve savunmalarını daha etkili sınamasını amaçlar. ATT&CK ortak dil sağlar, fakat Red Team'in mission modelini tek başına oluşturmaz.

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

Purple Team neyi ölçer?

Purple Team'in merkezinde saldırı zincirini gizlemek değil, savunma zincirini görünür hale getirmek vardır.

Seçilmiş bir behavior çalıştırıldığında şu sorular sırayla sorulur:

1. 1Test teknik olarak beklenen biçimde çalıştı mı?
2. 2Prevention control davranışı durdurdu mu?
3. 3Endpoint, identity, network veya cloud sensor telemetry üretti mi?
4. 4Telemetry merkezi platforma ulaştı mı?
5. 5Gerekli field'lar parse ve normalize edildi mi?
6. 6Detection analytic beklenen koşulda çalıştı mı?
7. 7Alert doğru severity ve context ile oluştu mu?
8. 8Alert doğru queue ve owner'a yönlendirildi mi?
9. 9Analyst davranışı doğru sınıflandırdı mı?
10. 10Investigation attack chain'i scope edebildi mi?
11. 11Containment playbook doğru ve zamanında uygulandı mı?
12. 12Improvement sonrasında aynı test geçti mi?

Purple Team bu zincirin her aşamasında evidence toplar.

Purple Team'in temel ölçüm birimleri

• Test execution validity
• Local telemetry availability
• Central telemetry availability
• Parser ve field completeness
• Detection analytic sonucu
• Alert fidelity
• Alert enrichment
• Case creation
• Case routing
• Analyst confirmation
• Investigation completeness
• Containment süresi
• Detection improvement
• Retest sonucu
• Regression durability

Bu nedenle Purple Team'in raporu yalnızca “detected” ve “not detected” kolonlarından oluşmamalıdır.

Örneğin davranış endpoint'te doğru log üretmiş, log collector tarafından alınmış, SIEM'e ulaşmış fakat CommandLine field'ı yanlış parse edilmiş olabilir. Detection rule ilgili field'a baktığı için alert oluşmaz.

Bu finding'in kök nedeni “EDR görmedi” değildir. Sensor gördü. Telemetry taşındı. Parser context'i kaybetti. Doğru remediation detection rule'u rastgele genişletmek değil parsing pipeline'ını düzeltmektir.

Başka bir örnekte alert oluşmuş ve SOC ekranına gelmiş olabilir. Ancak alert asset criticality, user identity ve parent process bilgisini taşımıyorsa analyst yanlış öncelik verebilir. Burada teknik detection var, operational detection zayıftır.

Purple Team'in değeri tam olarak bu ayrımı üretmesidir.

BAS neyi ölçer?

BAS, seçilmiş test definition'larının belirli environment ve control configuration'ı karşısındaki sonucunu ölçer.

İyi tasarlanmış BAS programı şu sorulara cevap verebilir:

• Test action hedefte gerçekten çalıştı mı?
• Prevention control test action'ı durdurdu mu?
• İlgili telemetry oluştu mu?
• Detection rule tetiklendi mi?
• Beklenen control integration'ı çalıştı mı?
• Aynı test farklı endpoint profile'larında farklı sonuç veriyor mu?
• Dün çalışan detection bugün neden kayboldu?
• Policy veya agent update sonrasında regression oluştu mu?
• Critical technique setinin ne kadarı düzenli doğrulanıyor?
• Hangi control gap'leri tekrar ediyor?

BAS'in asıl gücü frequency ve repeatability'dir.

Bir Red Team operator aynı exact procedure'ü her gün yüzlerce endpoint'te çalıştırmaz. Purple Team de her SIEM deployment'ından sonra bütün regression setini manual olarak tekrar etmek için pahalı kalabilir. BAS bu operasyonel boşluğu doldurur.

BAS'in ölçemediği veya sınırlı ölçtüğü alanlar

• İnsan operator'ın keşif ve adaptasyon kalitesi
• Unknown attack path
• Novel vulnerability
• Business logic abuse
• Gerçek social engineering behavior
• Long-term stealth ve operational security
• Defense'in saldırgan üzerindeki psikolojik veya stratejik etkisi
• Birden fazla başarısızlıktan yeni route üretme
• Kurumun gerçek incident pressure altındaki bütünsel davranışı
• Kapsam dışı olduğu için test library'de hiç bulunmayan exposure
• Safe simulation'ın üretmediği gerçek tool ve protocol semantics

BAS platformu multi-step chain çalıştırsa bile chain önceden tanımlıdır. Operator autonomy ile aynı şey değildir.

Purple Team, Red Team ve BAS karşılaştırma tablosu

Aynı technique üç çalışmada nasıl farklı kullanılır?

Örnek olarak PowerShell behavior'ını ele alalım.

Red Team içinde

Operator, mevcut erişim ve environment'a göre PowerShell kullanıp kullanmamaya karar verir. EDR'ın behavior'ı block ettiğini görürse farklı execution route seçebilir. Amaç PowerShell test etmek değil, mission objective'e ilerlemektir.

Ölçülenler:

• Operator behavior'ı kullanabildi mi?
• Prevention attack path'i gerçekten durdurdu mu?
• Alternative route mümkün müydü?
• SOC behavior'ı attack chain içinde ilişkilendirdi mi?
• Containment objective'e ulaşmadan geldi mi?

Purple Team içinde

Red Team belirli PowerShell procedure'ünü açık biçimde çalıştırır. Blue Team endpoint event, script block logging, process tree, network signal ve alert logic'i birlikte inceler. Eksik alan düzeltilir ve behavior yeniden oynatılır.

Ölçülenler:

• Gerekli telemetry field'ları var mı?
• Obfuscation varyasyonları detection'ı etkiliyor mu?
• Detection rule general behavior'ı mı, tek string'i mi arıyor?
• Alert context investigation için yeterli mi?
• Düzeltme sonrası aynı test ve variation'lar yakalanıyor mu?

BAS içinde

Platform seçilmiş PowerShell test case'lerini schedule ile çalıştırır. Sonuç endpoint profile, EDR policy ve SIEM integration'a göre kaydedilir.

Ölçülenler:

• Test başarıyla execute edildi mi?
• Block oldu mu?
• Telemetry ve alert üretildi mi?
• Result önceki run'a göre değişti mi?
• Hangi endpoint segment'inde regression var?

Üç çalışmada kullanılan command benzer olabilir. Fakat üretilen kanıt aynı değildir.

Adversary emulation ile attack simulation aynı şey mi?

Bu iki ifade piyasada sık sık birbirinin yerine kullanılır. Yine de teknik fidelity açısından ayrım yapmak yararlıdır.

Emulation

Belirli adversary'nin veya campaign'in gözlemlenmiş behavior, sequencing, tool kullanım mantığı ve procedure özelliklerini mümkün olduğunca gerçekçi biçimde yeniden üretmeye çalışır.

Simulation

Belirli risk, signal veya control behavior'ını güvenli bir abstraction ile temsil edebilir. Gerçek malware yerine benign file, gerçek exfiltration yerine canary data transferi veya destructive action yerine harmless marker kullanılabilir.

Simulation düşük değerli değildir. Production safety için çoğu zaman gereklidir. Fakat simulation sonucunun neyi kanıtladığı açık yazılmalıdır.

Örnek:

• EICAR benzeri test file'ının block edilmesi generic file prevention'ı gösterebilir
• Bu sonuç gerçek malware chain'inin memory behavior, persistence, command and control ve credential access aşamalarını ölçmez
• Benign DNS callback network visibility'yi doğrulayabilir
• Bu sonuç encrypted, domain-fronted veya protocol-specific C2 detection'ını kanıtlamaz

Test fidelity raporda belirtilmezse BAS score olduğundan daha geniş yorumlanır.

ATT&CK coverage neden tek başına güvenilir bir metric değildir?

Bir dashboard'da ATT&CK matrix'in yüzde 80'i yeşil görünebilir. Bu görsel güçlüdür, fakat denominator belirsizse yanıltıcıdır.

Şu sorular cevaplanmalıdır:

• Yeşil renk technique seviyesinde mi, sub-technique seviyesinde mi?
• Bir technique için kaç procedure variation test edildi?
• Hangi platformlarda test edildi?
• Test gerçekten execute oldu mu?
• Prevention mı, telemetry mi, alert mi yeşil sayıldı?
• Bir endpoint profile'ındaki başarı bütün estate'e mi yayıldı?
• Detection tek bir tool hash'ine mi bağlı?
• Alert analyst tarafından görüldü mü?
• Test ne zaman son kez çalıştı?
• ATT&CK version değiştiğinde denominator güncellendi mi?

MITRE ATT&CK v19, Nisan 2026 itibarıyla güncel release'tir. ATT&CK içeriği değişir, technique ve detection nesneleri güncellenir. Bu nedenle sabit bir percentage zaman içinde anlamını kaybedebilir.

Daha önemlisi, ATT&CK technique bir test case değildir.

T1059.001 PowerShell altında birçok procedure, command pattern, parent process, execution context ve telemetry kombinasyonu bulunabilir. Bir atomic testin başarıyla algılanması bütün technique'i kapsamaz.

Coverage en az şu boyutlarla tutulmalıdır:

Technique
Sub-technique
Procedure variation
Platform
Asset profile
Security control profile
Telemetry source
Detection analytic
Test timestamp
Execution validity
Result

Tek bir yeşil kare bu boyutları saklar.

Önce testin çalıştığını kanıtlamadan control sonucu ölçülemez

BAS ve Purple Team ölçümündeki en önemli kalite kontrolü execution validity'dir.

Bir test neden geçersiz olabilir?

• Dependency kurulmamıştır
• Test yanlış privilege ile çalışmıştır
• Target platform uyumsuzdur
• Command syntax runtime version ile eşleşmez
• Payload download edilmemiştir
• Network route yoktur
• Test harness error üretmiştir
• Cleanup önce çalışıp artifact'i silmiştir
• Agent task'i hiç almamıştır
• Target endpoint offline'dır

Bu durumda “alert oluşmadı” sonucu detection failure değildir. Behavior gerçekleşmemiştir.

Benzer biçimde test action EDR tarafından prevent edildiyse downstream behavior gerçekleşmemiş olabilir. Aynı run üzerinden hem “prevention başarılı” hem “detection başarılı” sonucu beklemek doğru değildir.

Prevention ve detection iki ayrı deney olarak tasarlanabilir:

1. 1Normal production policy ile prevention testi
2. 2Onaylı test host'unda kontrollü allow mode veya farklı safe procedure ile telemetry ve detection testi

İkinci deney production control'ünü kalıcı olarak gevşetmek anlamına gelmez. Test window, isolated target, approval ve rollback ile yönetilir.

Visibility, detection ve response aynı metric değildir

Bir behavior için şu durumların her biri farklı finding'dir:

1. 1Endpoint'te telemetry yok
2. 2Endpoint'te telemetry var, collector almıyor
3. 3Collector alıyor, central platform'a ulaşmıyor
4. 4Central platform'a ulaşıyor, parser gerekli field'ı kaybediyor
5. 5Data doğru, analytic yok
6. 6Analytic var, query yanlış
7. 7Alert oluşuyor, enrichment yetersiz
8. 8Alert yanlış queue'ya gidiyor
9. 9Case açılıyor, analyst yanlış kapatıyor
10. 10Analyst doğruluyor, containment gecikiyor

Bunların hepsini not detected etiketi altında toplamak remediation'ı zorlaştırır.

Doğru model bir detection funnel kullanır:

Valid execution
    ↓
Local telemetry
    ↓
Central telemetry
    ↓
Detection analytic
    ↓
Alert
    ↓
Case
    ↓
Analyst confirmation
    ↓
Containment

Her ok ayrı dependency'dir. Purple Team bu dependency'yi açıklamak için en uygun çalışma modelidir. BAS ise aynı funnel'ın ilk teknik katmanlarını sık ve otomatik doğrulayabilir. Red Team bütün zinciri gerçekçi mission baskısı altında sınar, fakat her drop-off'u operasyon sırasında birlikte düzeltmez.

Prevention, detection ve response score tek sayıya indirilmeli mi?

Genellikle hayır.

Şu örneği düşünelim:

Bu tabloya tek bir yüzde vermek için farklı güvenlik sonuçlarına keyfi weight atanması gerekir.

Örneğin A testinde behavior prevent edilmiştir. Bu güçlü sonuçtur. Fakat detection path test edilmemiştir.

B testinde prevention kaçırmış, defense in depth zinciri çalışmıştır.

C testinde visibility var, detection gap bulunur.

D testinde hem visibility hem detection gap vardır.

Tek score bu farkları saklar.

Executive dashboard gerekiyorsa üst seviye indicator gösterilebilir. Ancak altında prevention, visibility, detection ve response ayrı kalmalıdır.

Doğru denominator kullanılmazsa bütün metric bozulur

Security validation dashboard'larında en sık yapılan hata numerator'a odaklanıp denominator'ı tanımlamamaktır.

Execution validity rate

Valid biçimde çalışan test sayısı / planlanan test sayısı

Bu oran düşükse diğer sonuçlar güvenilir değildir. Test harness ve target readiness problemi, control failure gibi görünebilir.

Prevention rate

Prevent edilen test sayısı / valid test sayısı

Buradaki valid test, prevention control'e gerçekten ulaşmış testtir.

Central visibility rate

Merkezi telemetry oluşan test sayısı / target behavior'a ulaşan test sayısı

Prevention tarafından daha önce durdurulan testler bu denominator'a otomatik eklenmemelidir. Downstream behavior gerçekleşmediyse merkezi visibility'nin yokluğu detection gap değildir.

Alert rate

Beklenen alert'i oluşturan test sayısı / detection aşamasına ulaşan valid test sayısı

Alert expectation tanımlanmamış behavior'ları denominator'a eklemek de hatalıdır. Her behavior high-severity alert üretmek zorunda değildir. Bazıları hunt query, correlation input veya investigation telemetry olarak kalabilir.

Analyst confirmation rate

Analyst tarafından doğru sınıflandırılan test sayısı / analyst'e ulaşması beklenen test sayısı

Case hiç açılmadıysa analyst'in performansına failure yazmak doğru root cause üretmez. Önce alert routing ve case creation incelenmelidir.

Containment rate

Beklenen containment action'ı tamamlanan case sayısı / doğrulanmış ve containment gerektiren case sayısı

Her detection containment gerektirmez. Test expectation use case bazında tanımlanmalıdır.

MTTD tek başına neden yanıltıcıdır?

Mean Time to Detect veya Median Time to Detect yalnızca detected örnekler üzerinden hesaplanır.

On testten ikisi alert üretmiş ve bu iki alert 30 saniyede oluşmuşsa dashboard şu sonucu gösterebilir:

Median Time to Alert: 30 saniye

Bu sayı matematiksel olarak doğrudur. Fakat sekiz missed test belirtilmezse savunma olduğundan güçlü görünür.

Doğru sunum:

Detected sample: 2
Missed sample: 8
Detection rate: %20
Median Time to Alert: 30 saniye

Timing metric her zaman sample count ve miss count ile birlikte verilmelidir.

Başka bir sorun da başlangıç timestamp'idir.

MTTD şu noktalardan hangisine göre hesaplanıyor?

• Operator'ın command'i gönderdiği an
• Target process'in başladığı an
• İlk malicious artifact'in oluştuğu an
• İlk sensor event'inin üretildiği an
• İlk central event'in ingest edildiği an
• Attack chain'in başlangıcı

Bu seçimler farklı sonuç verir.

Metric contract içinde başlangıç ve bitiş event'leri açıkça tanımlanmalıdır:

Time to Telemetry
Target behavior execution → central event ingest

Time to Alert
Target behavior execution → alert creation

Time to Case
Alert creation → case creation

Time to Analyst Confirmation
Case assignment → correct classification

Time to Containment
Correct classification → approved containment completion

Timestamp'ler timezone içermeli, clock synchronization doğrulanmalı ve event pipeline latency ayrıca ölçülmelidir.

Purple Team ve BAS sonucu için güvenilir state modeli

Boolean passed=true alanı yetersizdir. Bir testin minimum state modeli aşağıdaki gibi olabilir:

{
  "test_id": "PT-2026-0042",
  "technique_id": "T1059.001",
  "procedure_id": "powershell-encoded-command-v3",
  "platform": "Windows 11",
  "asset_profile": "finance-user-endpoint",
  "execution_valid": true,
  "prevented": false,
  "telemetry_local": true,
  "telemetry_central": true,
  "alerted": true,
  "case_created": true,
  "analyst_confirmed": true,
  "contained": true,
  "executed_at": "2026-07-24T08:00:00+03:00",
  "alert_at": "2026-07-24T08:01:14+03:00",
  "control_profile": "EDR-PROD-7.4",
  "detection_version": "DET-PS-019@8",
  "evidence_refs": [
    "endpoint-event-1182",
    "siem-alert-77261",
    "case-IR-2026-882"
  ]
}

Bu model şu soruları cevaplayabilir:

• Test gerçekten çalıştı mı?
• Hangi procedure variation kullanıldı?
• Hangi asset ve control profile test edildi?
• Behavior nerede görüldü?
• Detection rule'un hangi version'ı çalıştı?
• İnsan response zinciri tamamlandı mı?
• Sonucu doğrulayan evidence nerede?

technique_id tek başına bu soruların hiçbirini cevaplamaz.

Test edilmiş Python metric hesaplama örneği

Aşağıdaki örnek, Purple Team veya BAS result kayıtlarından temel funnel metric'lerini hesaplar. Kod bilinçli olarak prevention ile downstream detection testini aynı record içinde birleştirmez.

Önemli tasarım kararları:

• Her test_id unique olmalıdır
• Invalid execution security failure sayılmaz
• Prevent edilen behavior detection denominator'ından çıkarılır
• Alert, central telemetry olmadan geçerli kabul edilmez
• Case, alert olmadan geçerli kabul edilmez
• Analyst confirmation, case olmadan geçerli kabul edilmez
• Containment, analyst confirmation olmadan geçerli kabul edilmez
• Timestamp timezone içermek zorundadır
• MTTD yalnızca detected sample üzerinde hesaplanır
• Missed sample sayısı ayrıca korunur
• Sıfır denominator olduğunda sahte yüzde yerine None döner

from __future__ import annotations

from datetime import datetime
from statistics import median
from typing import Any


BOOLEAN_FIELDS = (
    "execution_valid",
    "prevented",
    "telemetry_local",
    "telemetry_central",
    "alerted",
    "case_created",
    "analyst_confirmed",
    "contained",
)


def parse_time(
    value: str | None,
    field: str,
    test_id: str,
) -> datetime | None:
    if value is None:
        return None

    parsed = datetime.fromisoformat(value.replace("Z", "+00:00"))
    if parsed.tzinfo is None or parsed.utcoffset() is None:
        raise ValueError(
            f"{test_id}: {field} must include a timezone"
        )
    return parsed


def validate_record(record: dict[str, Any]) -> None:
    test_id = record.get("test_id")
    technique_id = record.get("technique_id")
    if not isinstance(test_id, str) or not test_id:
        raise ValueError("test_id is required")
    if not isinstance(technique_id, str) or not technique_id:
        raise ValueError(f"{test_id}: technique_id is required")

    for field in BOOLEAN_FIELDS:
        if not isinstance(record.get(field), bool):
            raise ValueError(f"{test_id}: {field} must be boolean")

    if not record["execution_valid"]:
        if any(record[field] for field in BOOLEAN_FIELDS[1:]):
            raise ValueError(
                f"{test_id}: invalid execution cannot have results"
            )
        return

    if record["prevented"]:
        downstream = (
            "telemetry_local",
            "telemetry_central",
            "alerted",
            "case_created",
            "analyst_confirmed",
            "contained",
        )
        if any(record[field] for field in downstream):
            raise ValueError(
                f"{test_id}: prevention and downstream results "
                "must be separate test cases"
            )
        return

    hierarchy = (
        ("telemetry_central", "alerted"),
        ("alerted", "case_created"),
        ("case_created", "analyst_confirmed"),
        ("analyst_confirmed", "contained"),
    )
    for prerequisite, outcome in hierarchy:
        if record[outcome] and not record[prerequisite]:
            raise ValueError(
                f"{test_id}: {outcome} requires {prerequisite}"
            )

    executed_at = parse_time(
        record.get("executed_at"),
        "executed_at",
        test_id,
    )
    alert_at = parse_time(
        record.get("alert_at"),
        "alert_at",
        test_id,
    )
    if record["alerted"] and (
        executed_at is None or alert_at is None
    ):
        raise ValueError(
            f"{test_id}: alerted tests require timestamps"
        )
    if (
        executed_at is not None
        and alert_at is not None
        and alert_at < executed_at
    ):
        raise ValueError(
            f"{test_id}: alert_at cannot precede executed_at"
        )


def rate(numerator: int, denominator: int) -> float | None:
    if denominator == 0:
        return None
    return round(numerator / denominator * 100, 2)


def measure(records: list[dict[str, Any]]) -> dict[str, Any]:
    seen_ids: set[str] = set()
    for record in records:
        validate_record(record)
        test_id = record["test_id"]
        if test_id in seen_ids:
            raise ValueError(f"duplicate test_id: {test_id}")
        seen_ids.add(test_id)

    valid = [
        record
        for record in records
        if record["execution_valid"]
    ]
    prevented = [
        record
        for record in valid
        if record["prevented"]
    ]
    reached_target = [
        record
        for record in valid
        if not record["prevented"]
    ]

    central = [
        record
        for record in reached_target
        if record["telemetry_central"]
    ]
    alerted = [
        record
        for record in reached_target
        if record["alerted"]
    ]
    cases = [
        record
        for record in reached_target
        if record["case_created"]
    ]
    confirmed = [
        record
        for record in reached_target
        if record["analyst_confirmed"]
    ]
    contained = [
        record
        for record in reached_target
        if record["contained"]
    ]

    detection_seconds = []
    for record in alerted:
        executed_at = parse_time(
            record["executed_at"],
            "executed_at",
            record["test_id"],
        )
        alert_at = parse_time(
            record["alert_at"],
            "alert_at",
            record["test_id"],
        )
        detection_seconds.append(
            (alert_at - executed_at).total_seconds()
        )

    return {
        "counts": {
            "planned": len(records),
            "valid": len(valid),
            "invalid": len(records) - len(valid),
            "prevented": len(prevented),
            "reached_target": len(reached_target),
            "telemetry_central": len(central),
            "alerted": len(alerted),
            "case_created": len(cases),
            "analyst_confirmed": len(confirmed),
            "contained": len(contained),
        },
        "rates": {
            "execution_validity": rate(
                len(valid),
                len(records),
            ),
            "prevention": rate(
                len(prevented),
                len(valid),
            ),
            "central_visibility": rate(
                len(central),
                len(reached_target),
            ),
            "alert": rate(
                len(alerted),
                len(reached_target),
            ),
            "analyst_confirmation": rate(
                len(confirmed),
                len(reached_target),
            ),
            "containment_after_confirmation": rate(
                len(contained),
                len(confirmed),
            ),
        },
        "timing": {
            "median_time_to_alert_seconds": (
                median(detection_seconds)
                if detection_seconds
                else None
            ),
            "detected_sample_count": len(detection_seconds),
            "missed_sample_count": (
                len(reached_target) - len(alerted)
            ),
        },
    }

Kod Python 3.12 üzerinde altı test senaryosuyla doğrulandı:

1. 1Prevention ve detection için farklı denominator kullanılması
2. 2MTTD yanında detected ve missed sample sayısının korunması
3. 3Funnel içinde impossible state'in reddedilmesi
4. 4Timezone içermeyen timestamp'in reddedilmesi
5. 5Duplicate test_id değerinin reddedilmesi
6. 6Denominator sıfırken yanıltıcı yüzde üretilmemesi

Bu örnek bir SIEM connector veya BAS integration değildir. Measurement contract'in nasıl fail closed kurulacağını gösterir. Production modelinde schema version, expected outcome, evidence integrity, asset identity, test authorization, cleanup result ve data retention alanları da eklenmelidir.

Alert precision BAS testlerinden hesaplanabilir mi?

Tek başına hesaplanamaz.

BAS veya Purple Team çoğunlukla positive test case üretir. Yani belirli behavior'ın gerçekten test olarak çalıştırıldığı bilinir. Bu set detection recall hakkında signal verebilir.

Precision için benign population da gerekir:

Precision = True Positive / (True Positive + False Positive)

Sadece attack testlerinin bulunduğu bir dataset'te false positive denominator'ı yoktur. Bu nedenle “detection precision yüzde 100” iddiası üretilemez.

Benzer şekilde gerçek production prevalence bilinmeden positive predictive value yorumlanamaz.

Purple Team sırasında detection rule'un benign business activity üzerinde ne kadar noise ürettiği ayrıca test edilmelidir. Historical SIEM search, shadow mode, sampled analyst review ve production alert volume bu değerlendirmeye katılabilir.

Bir detection'ın var olması ile dayanıklı olması farklıdır

Bir analytic tek test case'i yakalayabilir. Fakat küçük variation'larda kayboluyorsa behavior coverage zayıftır.

Detection robustness için şu variation'lar değerlendirilebilir:

• Farklı parent process
• Farklı command line tokenization
• Case ve whitespace değişimi
• Alternative binary path
• Renamed tool
• Signed binary proxy execution
• Remote ve local execution farkı
• User ile service account context'i
• IPv4 ve IPv6
• Cloud portal, CLI ve API
• Single event ve chain-level correlation

Amaç bypass öğretmek değil, detection'ın tek indicator'a mı yoksa anlamlı behavior'a mı bağlı olduğunu görmektir.

MITRE CTID'nin 2026 tarihli minimum telemetry araştırması log source değerlendirmesinde fidelity, noise, timeliness, robustness, coverage ve context gibi boyutları öne çıkarır. Bu yaklaşım Purple Team metric'lerinin yalnızca “log var” düzeyinde kalmaması gerektiğini gösterir.

Red Team hangi metric'lerle ölçülmeli?

Red Team'i BAS dashboard'una benzer bir technique pass rate ile ölçmek hatalıdır.

1. Objective result

Objective'e ulaşıldı mı?

Bu binary sonuç tek başına yeterli değildir. Şu state'ler ayrılabilir:

• Objective achieved
• Objective partially achieved
• Objective prevented
• Objective detected before impact
• Objective detected after impact
• Objective not reached due to time
• Objective not tested due to safety constraint
• Objective invalidated by scope dependency

“Ulaşılmadı” ile “savunma durdurdu” aynı değildir. Operator süre nedeniyle başka path deneyemediyse control success kanıtlanmış olmaz.

2. Attack path

Hangi trust relationship'ler ve precondition'lar birleşti?

Örnek:

Internet-facing application weakness
    ↓
DMZ workload identity
    ↓
Internal secrets service access
    ↓
Over-privileged service account
    ↓
Finance application session
    ↓
Objective

Bu zincirde beş ayrı product bulunabilir. Fakat systemic failure, trust boundary'ler arasındaki fazla yetkidir.

3. Detection point

SOC saldırıyı hangi aşamada gördü?

• Reconnaissance
• Initial access
• Execution
• Persistence
• Privilege escalation
• Credential access
• Discovery
• Lateral movement
• Collection
• Exfiltration
• Impact

Geç detection teknik olarak başarılı olabilir, fakat iş etkisini engelleyememiş olabilir.

4. Time-based response

• Time to first telemetry
• Time to first alert
• Time to analyst acknowledgement
• Time to correct scope
• Time to containment decision
• Time to containment
• Time to recovery

Red Team için yalnızca MTTD değil, Time to Objective de önemlidir. Savunma containment uygulamadan önce operator objective'e ulaştıysa zamanlama iş riskini belirler.

5. Path resistance

Operator kaç ayrı defense boundary ile karşılaştı?

• MFA
• EDR prevention
• Network segmentation
• Privilege boundary
• Application authorization
• Secrets isolation
• Conditional access
• Manual approval

Bir control operator'ı yavaşlatmış fakat tamamen durdurmamış olabilir. Bu yine değerli signal'dir.

6. Response quality

• Alert'ler tek incident altında correlate edildi mi?
• Analyst affected asset scope'unu doğru çıkardı mı?
• Compromised identity disable edildi mi?
• Containment başka critical service'i bozdu mu?
• Evidence korundu mu?
• Escalation doğru paydaşlara gitti mi?
• Communication kararları zamanında alındı mı?

7. Systemic finding

Red Team finding'leri yalnızca individual CVE listesi değildir.

Örnek systemic finding:

Bu finding asset, identity ve segmentation remediation'ı gerektirir.

Red Team hangi sonucu kanıtlayamaz?

İyi bir Red Team bile şu iddiaları tek başına kanıtlamaz:

• Kapsamda başka zafiyet yoktur
• Test edilmeyen ATT&CK technique'leri detect edilir
• Bütün endpoint'lerde aynı control sonucu vardır
• Her threat actor aynı attack path'i kullanır
• Objective'e ulaşılamadıysa objective güvenlidir
• Bir kez detected olan behavior her zaman detected olur
• SOC'un routine alert load altında aynı response'u vereceği kesindir
• Test süresinde kullanılmayan third-party route güvenlidir

Red Team güçlü ama örneklemli bir measurement'tır.

Bu nedenle her kurumun otomatik olarak Red Team'e ihtiyacı olmadığını Her kurumun Red Team'e ihtiyacı var mı? yazımızda ayrı olarak inceliyoruz.

Purple Team hangi metric'lerle ölçülmeli?

Purple Team metric'leri improvement loop'u görünür hale getirmelidir.

Visibility metric'leri

• Local event oluşma oranı
• Central ingestion oranı
• Required field completeness
• Ingest latency
• Sensor health
• Asset coverage
• Identity context availability
• Network ve endpoint event correlation

Detection metric'leri

• Expected analytic fire rate
• Detection latency
• Procedure variation coverage
• Alert fidelity
• Alert severity accuracy
• Duplicate alert count
• Correlation success
• Rule dependency health
• Benign activity noise

Investigation metric'leri

• Case creation rate
• Routing accuracy
• Analyst acknowledgement time
• Correct classification rate
• Scope completeness
• Evidence completeness
• Related entity pivot success
• Escalation accuracy

Response metric'leri

• Containment decision time
• Containment execution time
• Playbook completion
• Identity revoke effectiveness
• Host isolation effectiveness
• Business impact of response
• Recovery readiness

Improvement metric'leri

• Gap'ten action item'a dönüşüm oranı
• Owner atanma süresi
• Fix completion süresi
• Retest pass rate
• Regression-free duration
• Reopened gap sayısı
• Detection rule version traceability

Purple Team'in başarısı exercise sonunda kaç alert çıktığıyla değil, hangi gap'lerin kalıcı kapandığıyla değerlendirilmelidir.

BAS hangi metric'lerle ölçülmeli?

BAS için coverage ve repeatability önemlidir. Fakat product dashboard'undaki score'un arkasındaki data model görülmelidir.

Test health

• Scheduled test count
• Executed test count
• Invalid test count
• Dependency failure
• Agent health
• Cleanup success
• Target availability

Control result

• Prevention pass rate
• Telemetry pass rate
• Alert pass rate
• Control-specific failure
• Policy-specific failure
• Asset-profile difference

Coverage

• Test edilen technique ve sub-technique
• Procedure variation sayısı
• Platform coverage
• Asset tier coverage
• Security control profile coverage
• Cloud, identity, endpoint ve network coverage

Drift

• Önceki run'a göre değişen sonuç
• İlk failure zamanı
• Policy change correlation
• Agent version correlation
• Detection rule version correlation
• Environment segment farkı

Program health

• Failed test remediation SLA
• Retest süresi
• Recurring failure
• Waiver ve exception sayısı
• Test library age
• Unsupported platform count
• Stale expected result

BAS başarısı “kaç attack çalıştırıldı?” değildir. Geçerli testlerin doğru control expectation ile eşleştirilmesi ve failure'ın remediation'a dönüşmesidir.

BAS score neden kolayca yanlış yorumlanır?

Bir product yüzde 92 “security effectiveness” gösterebilir. Bu sayıyı değerlendirmek için calculation method bilinmelidir.

Şu sorular sorulmalıdır:

1. 1Score'da prevention ile detection aynı weight'e mi sahip?
2. 2Invalid ve not-run testler denominator'dan çıkarılıyor mu?
3. 3Unsupported testler nasıl ele alınıyor?
4. 4Test library'nin ne kadarı environment için relevant?
5. 5Aynı technique altındaki onlarca benzer test score'u şişiriyor mu?
6. 6Critical asset ile lab endpoint aynı weight'te mi?
7. 7Sonuç yalnızca vendor API response'una mı dayanıyor?
8. 8Raw telemetry ve independent evidence var mı?
9. 9Test action'ın gerçekten çalıştığı nasıl kanıtlanıyor?
10. 10Score bütün estate'e mi, seçilmiş agent'lara mı ait?
11. 11Historical trend aynı test seti üzerinden mi hesaplanıyor?
12. 12Product update test definition'ı değiştirince trend kırılıyor mu?

Score ancak methodology ile birlikte anlamlıdır.

BAS, automated pentest ve vulnerability scanner aynı şey mi?

Hayır.

Vulnerability scanner

Known vulnerability, missing patch, exposed service ve configuration weakness arar. Ana ölçüm birimi asset ve finding'dir.

Automated pentest

Belirli attack path'leri otomatik keşfetmeye, exploitability'yi doğrulamaya veya reachable impact göstermeye çalışabilir. Capability ürüne göre çok değişir.

BAS

Önceden tanımlı adversary behavior veya control testlerini çalıştırır. Ana amaç bilinmeyen vulnerability keşfetmek değil, security control'ün beklenen davranışını doğrulamaktır.

Red Team

İnsan operator mission objective'e ulaşmak için keşif, judgment ve adaptasyon kullanır.

Purple Team

Offensive action ile defensive improvement arasında açık feedback loop kurar.

Bir ürün bu capability'lerden birkaçını birleştirebilir. Yine de satın alma sırasında her module'ün neyi gerçekten yaptığı ayrı doğrulanmalıdır.

BAS, Red Team'in yerini alabilir mi?

Hayır. Doğru kullanıldığında Red Team'in zamanını daha değerli hale getirebilir.

BAS şu temel gap'leri önceden temizleyebilir:

• EDR agent çalışmıyor
• SIEM connector durmuş
• Basic telemetry eksik
• Detection rule deploy edilmemiş
• Email gateway test file'ını geçirmiş
• Known control policy yanlış uygulanmış
• Critical endpoint test agent'ı almıyor

Bu sorunlar Red Team sırasında bulunabilir, fakat Red Team'in kıt zamanını basic control health kontrolüne harcamak zorunda kalması verimsizdir.

BAS ile rutin failure'lar temizlendiğinde Red Team daha zor sorulara odaklanır:

• Unknown trust relationship
• Multi-stage attack path
• Identity ve application boundary birleşimi
• Detection evasion
• Human response
• Critical function impact
• Third-party dependency

Bu ilişki replacement değil preparation ve regression ilişkisidir.

Purple Team, Red Team'in gerçekçiliğini bozar mı?

Aynı anda yapılıyorsa evet, bu nedenle phase'ler ayrılmalıdır.

Zero-knowledge veya limited-knowledge Red Team sırasında Blue Team'e her command'in gösterilmesi operasyonun ölçmek istediği detection ve response davranışını bozar.

Sağlam model:

1. 1Red Team operasyonu need-to-know biçimde yürütülür
2. 2Operation timeline ve evidence tamamlanır
3. 3Detection ve response result'ları çıkarılır
4. 4Reveal session yapılır
5. 5Attack path adım adım replay edilir
6. 6Blue Team telemetry ve decision'ları gösterir
7. 7Gap'ler Purple Team formatında düzeltilir
8. 8Detection regression testleri BAS veya test harness'a aktarılır

Böylece önce gerçekçi assessment, sonra açık improvement yapılır.

TIBER-EU 2025, Threat Intelligence temelli ethical red teaming ile protection, detection ve response capability'lerini gerçekçi controlled attack üzerinden sınamayı ele alır. DORA TLPT'nin closure ve remediation aşamaları da test sonucunun yalnızca raporda kalmamasını gerektirir.

Üç çalışma birlikte nasıl işletilmeli?

En güçlü program lineer değil döngüseldir.

Threat Intelligence
    ↓
BAS ile temel control validation
    ↓
Purple Team ile visibility ve detection improvement
    ↓
Red Team ile blind mission assessment
    ↓
Purple Team reveal ve replay
    ↓
Detection regression testleri
    ↓
BAS ile sürekli doğrulama

BAS'in rolü

Known ve repeatable test setini sık çalıştırır. Basic control drift'i yakalar.

Purple Team'in rolü

Gap'in nedenini açık biçimde çözer. Telemetry, analytic ve response'u iyileştirir.

Red Team'in rolü

Defender'ın beklemediği path ve operator adaptation karşısında bütünsel dayanıklılığı ölçer.

Threat Intelligence'ın rolü

Hangi adversary behavior, platform ve objective'in kurum için relevant olduğunu belirler. ATT&CK matrix'i rastgele doldurmak yerine öncelik üretir.

Örnek operating cadence

Her kurum için aynı schedule doğru değildir. Yine de model şu şekilde kurulabilir:

Critical merger, cloud migration, identity redesign, EDR replacement veya major incident sonrasında takvim beklenmeden yeni test yapılabilir.

Ransomware senaryosunda üç çalışma ne yapar?

BAS

Seçilmiş ransomware-relevant behavior'ları güvenli test case'lerle çalıştırabilir:

• Script execution
• Credential access signal
• Remote service behavior
• Backup discovery
• File modification pattern
• Network share access
• Data staging

Her testin prevention ve detection sonucu düzenli doğrulanır.

Purple Team

Blue Team ile birlikte attack chain'in detection architecture'ını inceler:

• Endpoint event SIEM'e geliyor mu?
• Identity event ile correlate ediliyor mu?
• Backup discovery behavior'ı meaningful alert üretiyor mu?
• Lateral movement birden fazla hostta chain olarak görülüyor mu?
• Analyst affected user ve asset scope'unu çıkarabiliyor mu?
• Isolation playbook test hostunu doğru sınırlıyor mu?

Red Team

Gerçekçi başlangıç koşulundan critical data ve backup management path'ine ilerlemeye çalışır. Operator environment'a göre route seçer. Amaç seçilmiş ransomware testlerini sırayla çalıştırmak değil, kurumun impact öncesi saldırıyı kesip kesemediğini ölçmektir.

Sonuçlar:

• BAS basic control consistency gösterir
• Purple Team detection ve response gap'ini düzeltir
• Red Team gerçekçi path altında resilience'i sınar

Cloud identity senaryosunda üç çalışma ne yapar?

BAS

Approved test account ile belirli identity ve cloud action'larını çalıştırır:

• Suspicious login condition
• Privilege change
• New access key
• Unusual API call
• Storage access
• Security configuration change

Expected cloud log, analytic ve case result'ı ölçülür.

Purple Team

Identity provider, cloud audit, SaaS ve endpoint telemetry'sini birlikte inceler. Alert'in user risk, device context, session, role ve asset criticality ile enrich edilip edilmediğini doğrular.

Red Team

Onaylı scope içinde identity trust relationship'lerini, token path'lerini, over-privileged role'leri ve cross-account route'ları mission objective için araştırır. Predefined API listesiyle sınırlı kalmaz.

Cloud testlerinde production impact, billing, destructive action, data access ve third-party tenant sınırları Rules of Engagement içinde açıkça tanımlanmalıdır.

Web application'dan internal network'e uzanan senaryoda fark

BAS endpoint ve network testlerini çalıştırabilir, fakat custom web business logic weakness'ini keşfetmeyebilir.

Purple Team bilinen web-to-host behavior'ı ve sonrasındaki telemetry'yi birlikte replay edebilir. Ancak exercise sırasında Blue Team activity'yi bildiği için gerçek detection surprise ölçülmez.

Red Team internet-facing attack surface'ten başlayıp web application, workload identity, internal route ve Active Directory trust ilişkilerini objective doğrultusunda birleştirebilir.

Bu nedenle external ve internal test ayrımının architecture üzerindeki etkisini Dış ağ ve iç ağ sızma testi arasındaki farklar yazımızdaki scope yaklaşımıyla birlikte değerlendirmek yararlıdır.

Hangi durumda hangisi seçilmeli?

Red Team seçin

Şu sorular öncelikliyse:

• Critical objective'e gerçekçi attack path var mı?
• Existing controls birlikte çalıştığında adversary durduruluyor mu?
• SOC ve Incident Response sürpriz altında nasıl davranıyor?
• İnsan, process ve technology failure'ları nasıl birleşiyor?
• Third-party ve identity trust path'leri gerçek risk üretiyor mu?
• Yönetimin kabul ettiği threat scenario karşısında resilience ne durumda?

Purple Team seçin

Şu ihtiyaçlar varsa:

• Detection coverage'in neden çalışmadığı bilinmiyor
• Telemetry ve parser gap'leri ayrıştırılmalı
• SOC analyst'leri behavior üzerinde eğitilmeli
• Detection rule birlikte geliştirilmeli
• Red Team finding'i adım adım replay edilmeli
• New threat behavior hızlı biçimde validation'a alınmalı
• Detection Engineering ile offensive ekip arasında feedback loop kurulmalı

BAS seçin

Şu ihtiyaçlar varsa:

• Aynı control testleri sık tekrarlanmalı
• Configuration drift erken görülmeli
• EDR, email, network veya cloud policy update'i doğrulanmalı
• Critical test pack düzenli çalışmalı
• Detection regression CI/CD benzeri süreçle yönetilmeli
• Farklı asset profile'ları karşılaştırılmalı
• Manual test maliyeti düşürülmeli

Birlikte kullanın

Kurumda yeterli maturity, asset inventory, telemetry ownership ve remediation capacity varsa üçü birbirini tamamlar.

Henüz temel telemetry yoksa Red Team mi yapılmalı?

Çoğu durumda önce Purple Team veya targeted validation daha fazla değer üretir.

SOC hangi endpoint'lerin log gönderdiğini bilmiyorsa, critical data source'lar central platform'a ulaşmıyorsa ve alert ownership belirsizse uzun bir Red Team operasyonu beklenen sonucu verecektir:

Bu sonuç sürpriz değildir ve root cause çok geniş kalır.

Önce:

• Asset inventory
• Logging baseline
• Sensor health
• Time synchronization
• Detection ownership
• Case routing
• Response playbook
• Test endpoint

hazırlanabilir.

Ardından Purple Team ile birkaç critical behavior zinciri doğrulanır. Basic visibility oluştuğunda Red Team daha zor ve daha değerli soruları cevaplar.

Tool satın almak Purple Team programı kurar mı?

Hayır.

BAS veya adversary emulation tool'u execution sağlar. Purple Team programı ise planning, Threat Intelligence, role, evidence, metric, remediation ve retest operating modelidir.

Tool şu işleri kolaylaştırabilir:

• Test library yönetimi
• Repeatable execution
• Scheduling
• Agent orchestration
• Evidence collection
• ATT&CK mapping
• Dashboard
• Regression

Fakat şu kararları tek başına veremez:

• Hangi threat scenario kurum için relevant?
• Hangi behavior high-fidelity emüle edildi?
• Hangi alert business context içinde yeterli?
• Noise kabul edilebilir mi?
• Analyst neden yanlış karar verdi?
• Hangi remediation risk açısından öncelikli?
• Test sonucu bütün estate'e genellenebilir mi?

Tool programın parçasıdır, programın kendisi değildir.

BAS ürün değerlendirmesinde sorulması gereken teknik sorular

Test fidelity

1. 1Test gerçek behavior mı üretir, yalnızca indicator mı bırakır?
2. 2Procedure source ve version görülebiliyor mu?
3. 3Testin success kriteri nedir?
4. 4Execution validity hangi evidence ile doğrulanır?
5. 5Test variation oluşturulabilir mi?
6. 6Custom test yazılabilir mi?
7. 7Cleanup doğrulanıyor mu?

Safety

1. 1Production-safe guarantee hangi constraint'lere dayanıyor?
2. 2Kill switch var mı?
3. 3Scope ve target allowlist nasıl enforce ediliyor?
4. 4Destructive command'ler nasıl engelleniyor?
5. 5Credential ve payload nasıl korunuyor?
6. 6Agent permission modeli nedir?
7. 7Test approval workflow var mı?

Detection integration

1. 1Platform raw telemetry görüyor mu?
2. 2SIEM alert'ini hangi API ile doğruluyor?
3. 3Alert correlation delay nasıl ele alınıyor?
4. 4Case creation ve analyst action ölçülebiliyor mu?
5. 5Detection rule version result'a bağlanıyor mu?
6. 6Multiple SIEM ve EDR destekleniyor mu?

Metric

1. 1Denominator nasıl tanımlanıyor?
2. 2Invalid ve not-run test ne oluyor?
3. 3Prevention ile detection ayrılıyor mu?
4. 4Unique technique ile test case sayısı ayrılıyor mu?
5. 5Trend aynı test version'ı üzerinden mi hesaplanıyor?
6. 6Raw evidence export edilebiliyor mu?
7. 7Vendor score bağımsız olarak yeniden hesaplanabiliyor mu?

Operation

1. 1On-premise deployment var mı?
2. 2Test data dışarı çıkıyor mu?
3. 3Role-based access control var mı?
4. 4Immutable audit log bulunuyor mu?
5. 5Multi-tenant isolation nasıl sağlanıyor?
6. 6API ve automation capability'si var mı?
7. 7Test failure issue tracker'a bağlanabiliyor mu?

Red Team hizmeti alınırken sorulması gereken sorular

1. 1Objective ve crown jewel nasıl belirlenecek?
2. 2Threat scenario hangi Threat Intelligence ile oluşturulacak?
3. 3Control Team kimlerden oluşacak?
4. 4Rules of Engagement hangi safety boundary'leri içerecek?
5. 5Production impact nasıl sınırlandırılacak?
6. 6Third-party ve cloud provider izinleri nasıl yönetilecek?
7. 7Operation evidence nasıl korunacak?
8. 8Detection ve response nasıl ölçülecek?
9. 9Time to Objective hangi timestamp ile hesaplanacak?
10. 10Deconfliction ve emergency stop süreci nedir?
11. 11Attack path systemic finding'e nasıl dönüştürülecek?
12. 12Purple Team reveal ve replay dahil mi?
13. 13Remediation validation nasıl yapılacak?

Sadece kaç IP test edileceğini soran bir teklif, Red Team objective'ini tanımlamak için yetersizdir.

Purple Team hizmeti alınırken sorulması gereken sorular

1. 1Hangi stakeholder'lar exercise'a katılacak?
2. 2Behavior seçimi Threat Intelligence ile nasıl ilişkilendirilecek?
3. 3Procedure fidelity nasıl doğrulanacak?
4. 4Test environment production control profile'ını temsil ediyor mu?
5. 5Local ve central telemetry ayrı ölçülecek mi?
6. 6Parser ve field completeness incelenecek mi?
7. 7Detection rule exercise sırasında düzeltilecek mi?
8. 8Analyst investigation gerçek case workflow'u kullanacak mı?
9. 9Metric contract önceden paylaşılacak mı?
10. 10Retest aynı exercise içinde mi yapılacak?
11. 11Detection artifact'leri version control'e alınacak mı?
12. 12Regression testleri BAS veya CI/CD'ye aktarılacak mı?

Purple Team output'u yalnızca ATT&CK heatmap ise çalışma büyük ihtimalle eksiktir.

En sık yapılan yanlış başarı kabulleri

“BAS score yüksekse Red Team'e gerek yoktur”

Yanlış. BAS known test setini ölçer. Red Team unknown path, operator adaptation ve mission-level response'u sınar.

“Red Team objective'e ulaşamadıysa savunma başarılıdır”

Her zaman değil. Timebox, scope, safety constraint veya eksik starting condition sonucu etkilemiş olabilir. Durdurma noktası evidence ile gösterilmelidir.

“Purple Team'de bütün alert'ler görüldüyse SOC hazırdır”

Exercise full knowledge olabilir. Analyst test zamanını ve behavior'ı biliyorsa routine operation'daki signal-to-noise koşulu ölçülmez.

“ATT&CK coverage yüzde 90 ise detection güçlüdür”

Technique-level renk, procedure variation, platform, telemetry ve analytic fidelity'yi saklayabilir.

“Prevent edilen test aynı zamanda detected sayılmalıdır”

Downstream behavior gerçekleşmediyse detection path test edilmemiş olabilir. Prevention event için ayrı detection expectation tanımlanabilir.

“Telemetry varsa detection vardır”

Telemetry potential'dır. Analytic, context ve alert workflow yoksa actionable detection oluşmayabilir.

“Alert varsa response vardır”

Alert yanlış queue'da bekleyebilir, analyst yanlış kapatabilir veya containment uygulanmayabilir.

“Bir kez geçen test kalıcı olarak geçer”

Agent, policy, parser, rule, asset image ve infrastructure değişebilir. Regression gerekir.

“Daha fazla test daha iyi coverage demektir”

Birbirinin varyasyonu olan yüzlerce düşük relevance test, critical behavior gap'ini saklayabilir.

“BAS otomasyonu tamamen risksizdir”

Yanlış target, fazla yetkili agent, unsafe custom test, cleanup failure ve production load risk oluşturabilir. Scope, approval, audit ve kill switch gerekir.

Evidence standardı nasıl olmalı?

Her test sonucu en az üç evidence katmanı taşımalıdır.

Execution evidence

• Command veya action ID
• Target identity
• Start ve end timestamp
• Return code
• Created artifact
• Test harness log
• Cleanup result

Defensive evidence

• Local event
• Central event
• Parsed field'lar
• Detection analytic ID ve version
• Alert ID
• Case ID
• Analyst action
• Containment action

Context evidence

• Asset criticality
• User veya service identity
• Control profile
• Environment
• Test authorization
• Expected outcome
• Procedure version

Screenshot tek başına zayıf evidence'dir. Machine-readable event reference ve immutable timestamp ile desteklenmelidir.

Detection-as-code bu modele nasıl bağlanır?

Purple Team sırasında geliştirilen detection rule version control altında tutulabilir. Sigma gibi açık detection formatları rule metadata ve logic'i taşımak için kullanılabilir.

Örnek lifecycle:

Purple Team gap
    ↓
Detection rule change
    ↓
Code review
    ↓
Static validation
    ↓
Test environment deployment
    ↓
BAS veya atomic regression
    ↓
Expected alert validation
    ↓
Production rollout
    ↓
Scheduled regression

Rule deploy edildiği için finding kapanmamalıdır. Test behavior yeniden çalıştırılmalı, telemetry'den analyst workflow'una kadar expected result doğrulanmalıdır.

Bu yaklaşım CI/CD'deki security gate mantığına benzer. Detection pipeline'ında da rule validity, deployment health, test result ve exception lifecycle birlikte yönetilmelidir.

Program maturity nasıl ilerler?

Seviye 1: Ad hoc testing

• Testler plansız çalışır
• Evidence screenshot'tır
• ATT&CK ID manual eklenir
• Owner belirsizdir
• Retest düzensizdir

Seviye 2: Repeatable exercise

• Test case ID vardır
• Expected result tanımlıdır
• Purple Team exercise planlıdır
• Gap owner'a atanır
• Retest yapılır

Seviye 3: Operationalized validation

• Threat Intelligence önceliği belirler
• BAS critical pack düzenli çalışır
• Detection rule version'lanır
• Metric denominator nettir
• Drift izlenir
• Red Team sonrası replay standarddır

Seviye 4: Continuous improvement

• Asset ve control profile otomatik ilişkilidir
• Change event'i targeted regression tetikler
• Purple Team micro exercise düzenlidir
• Red Team systemic finding'leri architecture değişikliğine dönüşür
• Executive metric teknik evidence'e kadar izlenebilir

Maturity'nin göstergesi attack sayısı değil, evidence'den remediation'a ve retest'e uzanan zincirin güvenilirliğidir.

Güvenli execution için minimum kontrol listesi

Authorization

• [ ] Written authorization mevcut
• [ ] Scope machine-readable biçimde tanımlı
• [ ] Target owner onayı var
• [ ] Third-party sınırları doğrulandı
• [ ] Test window tanımlı

Safety

• [ ] Destructive action yasakları açık
• [ ] Test account ve canary data kullanılıyor
• [ ] Maximum resource limit tanımlı
• [ ] Cleanup procedure test edildi
• [ ] Kill switch doğrulandı
• [ ] Emergency contact aktif

Technical readiness

• [ ] Clock synchronization doğrulandı
• [ ] Target profile kaydedildi
• [ ] Sensor health kontrol edildi
• [ ] Test dependency'leri hazır
• [ ] Control version'ları kaydedildi
• [ ] Test harness log üretiyor

Measurement

• [ ] Expected prevention tanımlı
• [ ] Expected telemetry tanımlı
• [ ] Expected alert tanımlı
• [ ] Response expectation tanımlı
• [ ] Denominator kuralları yazılı
• [ ] Invalid state ayrı

Closure

• [ ] Action item owner'ı var
• [ ] Remediation due date var
• [ ] Retest planlandı
• [ ] Regression test oluşturuldu
• [ ] Evidence retention uygulandı
• [ ] Exception expiry tanımlandı

Hangi kurum hangi sırayla başlamalı?

SOC yeni kurulmuşsa

Önce asset, logging ve sensor health baseline. Ardından dar Purple Team exercise. Sonra critical BAS regression. Basic visibility oturduğunda Red Team.

EDR ve SIEM olgun fakat test edilmiyorsa

Critical BAS pack ile mevcut state ölçülür. Gap'ler Purple Team'de çözülür. Sonra blind Red Team ile gerçekçi assessment yapılır.

Düzenli Red Team yapılıyor fakat aynı finding'ler tekrarlıyorsa

Purple Team replay ve detection regression eksiktir. Red Team finding'leri BAS test case'lerine dönüştürülmelidir.

BAS var fakat dashboard'a bakılmıyorsa

Owner, SLA, evidence ve retest workflow'u kurulmalıdır. Platform çalışıyor olması programın işlediği anlamına gelmez.

Regulated financial entity ise

TLPT ve ilgili authority requirement'ları ayrıca değerlendirilmelidir. BAS, regulatory Red Team veya TLPT'nin yerine geçmez. Ancak readiness ve remediation regression için değerli olabilir.

Sonuç: Aynı tekniği çalıştırmak, aynı şeyi ölçmek değildir

Purple Team, Red Team ve BAS aynı security stack'e dokunabilir. Aynı ATT&CK technique'lerini, aynı endpoint'leri ve hatta aynı execution framework'ünü kullanabilir.

Fakat üçü farklı güvenlik sorularını cevaplar:

1. 1Red Team: Gerçekçi adversary objective'e ulaşabilir mi ve kurum onu zamanında durdurabilir mi?
2. 2Purple Team: Seçilmiş behavior'ı nerede görüyor, nerede kaybediyor ve savunmayı nasıl iyileştiriyoruz?
3. 3BAS: Tanımlı testler bugün beklenen control sonucunu veriyor mu ve bu sonuç zaman içinde bozuluyor mu?

En büyük hata üçünü aynı maturity merdiveninin alt, orta ve üst basamağı gibi görmektir. BAS düşük seviye Red Team değildir. Purple Team yarım Red Team değildir. Red Team de daha pahalı BAS değildir.

Doğru program her birine kendi işini verir:

• BAS rutin ve repeatable validation yapar
• Purple Team telemetry, detection ve response'u geliştirir
• Red Team bilinmeyen path ve gerçekçi mission baskısını sınar
• Threat Intelligence test önceliğini belirler
• Regression loop düzeltmenin kalıcı olup olmadığını gösterir

Bir kurumun ihtiyacı “daha çok attack çalıştırmak” değildir. İhtiyacı, her attack action için hangi security claim'in test edildiğini, testin gerçekten çalışıp çalışmadığını ve sonucun hangi evidence ile kanıtlandığını bilmektir.

Secnodex, Red Team, Purple Team ve security control validation çalışmalarını aynı isim altında sunulan tek tip paketler olarak ele almaz. Önce critical function, threat scenario, asset ve control maturity değerlendirilir. Ardından objective-based Red Team, collaborative Purple Team exercise veya repeatable BAS validation modelinden hangisinin doğru güvenlik sorusunu cevaplayacağı belirlenir. Mevcut BAS yatırımınızın gerçekten neyi ölçtüğünü incelemek, Red Team operasyonunuzu doğru metric'lerle tasarlamak veya Purple Team programı kurmak için Secnodex ile iletişime geçebilirsiniz.

Kaynaklar

• MITRE ATT&CK – Adversary Emulation Plans
• MITRE ATT&CK – Adversary Emulation and Red Teaming
• MITRE ATT&CK – Data and Tools
• MITRE ATT&CK – Version Updates
• MITRE CTID – Adversary Emulation Library
• MITRE CTID – Micro Emulation Plans
• MITRE CTID – Sensor Mappings to ATT&CK
• MITRE CTID – Context to Confidence
• Purple Team Exercise Framework v3
• Apache Caldera – Automated Adversary Emulation Platform
• Atomic Red Team – Official Repository
• Sigma Detection Format – Rules
• NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment
• NIST SP 800-53 Revision 5 – Security and Privacy Controls
• 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 2024
• CREST – A Guide to Penetration Testing