Red Team Senaryosu Nasıl Yazılır? Hedef, Kısıt ve Başarı Ölçütleri

Bir kurum Red Team çalışması için hazırlık toplantısı yapıyor. Yönetimin talebi kısa:

İlk bakışta objective belli gibi görünüyor. Internet'ten başlanacak, internal network'e ilerlenilecek ve yüksek yetki elde edilecek. Fakat birkaç soru sorulduğunda senaryonun aslında yazılmadığı ortaya çıkıyor:

• Domain Admin neden kurum için anlamlı son nokta?
• Hangi critical business function test ediliyor?
• Social engineering kullanılabilecek mi?
• Third-party tarafından işletilen VPN scope içinde mi?
• Production account lockout kabul edilebilir mi?
• EDR bir payload'ı block ederse farklı teknikle devam edilecek mi?
• SOC'un testi fark etmesi Red Team için başarısızlık mı?
• Domain Admin elde edilirse gerçek data'ya erişilecek mi?
• Kritik sistemde impact hangi güvenli kanıtla gösterilecek?
• Operasyon sırasında gerçek bir incident başlarsa kim deconfliction yapacak?
• Başarı yalnızca Red Team'in erişimiyle mi, Blue Team'in response performansıyla mı ölçülecek?

Bu soruların cevabı yoksa ortada bir Red Team senaryosu değil, saldırı ekibine bırakılmış belirsiz bir hedef vardır.

Belirsizlik bazen Red Team'e özgürlük sağlıyor gibi görünür. Gerçekte ise testin geçerliliğini zayıflatır. Ekip teknik olarak etkileyici bir attack path kurabilir fakat kurumun hangi riskini ölçtüğü açıklanamaz. Blue Team bir noktada saldırıyı görebilir fakat detection'ın zamanında ve yeterli olup olmadığı değerlendirilemez. Operasyon kesintisiz tamamlanabilir fakat bunun iyi tasarlanmış safety control'lerinden mi, saldırı yüzeyine hiç dokunulmamasından mı kaynaklandığı bilinmez.

Red Team senaryosu nasıl yazılır sorusunun kısa cevabı şudur:

İyi senaryo Red Team'e izlemesi gereken tek bir komut listesi vermez. Operator'a gerçekçi karar alanı bırakırken hukuki yetkiyi, production güvenliğini ve ölçüm tasarımını sabitler.

Bu rehberde bir Red Team senaryosunun business objective'den teknik plana nasıl dönüştürüleceğini, kısıtların nasıl yazılması gerektiğini, başarı ölçütlerinin neden pass/fail sonucuna indirgenemeyeceğini ve kullanılabilir bir scenario document'in hangi alanları içermesi gerektiğini ayrıntılı olarak ele alacağız.

Red Team senaryosu bir saldırı teknikleri listesi değildir

“Phishing yap, payload çalıştır, privilege escalation uygula, lateral movement gerçekleştir ve data exfiltration dene” şeklindeki bir sıra, senaryo gibi görünür. Ancak bu liste üç kritik unsuru açıklamaz:

1. 1Bu davranışlar hangi kurumsal riski temsil ediyor?
2. 2Neden bu saldırgan ve bu attack path gerçekçi kabul ediliyor?
3. 3Test sonucunda hangi güvenlik iddiası doğrulanacak?

MITRE ATT&CK technique'leri bir senaryonun ortak dilini oluşturabilir. Fakat matrix üzerinde kutu seçmek, threat model üretmez. Aynı technique farklı threat actor'lar tarafından farklı infrastructure, timing, tooling ve operational pattern ile uygulanabilir. Kurumun ilgili technique'i teorik olarak görmesi de senaryodaki implementation'ı göreceğini kanıtlamaz.

Senaryo, özünde bir test hipotezidir:

Bu cümledeki her bileşenin yazılı karşılığı bulunmalıdır.

Scenario document, Red Team test plan ve Rules of Engagement aynı şey mi?

Kurumlar bu dokümanları tek dosyada veya ayrı dosyalarda yönetebilir. İsimden çok işlevlerin kaybolmaması önemlidir.

Küçük bir engagement'ta bunların tamamı kontrollü tek bir dokümanda tutulabilir. Büyük veya regulated bir operasyonda ayrı belgeler, version control ve approval chain daha güvenli olur.

NIST, Rules of Engagement'ı test başlamadan önce oluşturulan, security testing'in yürütülmesine ilişkin ayrıntılı kural ve kısıtlar olarak tanımlar. TIBER-EU yaklaşımında da scoping, Target Threat Intelligence Report ve Red Team test planı birbirini besleyen fakat farklı işlevleri olan deliverable'lardır.

Bu ayrım yalnızca dokümantasyon düzeni değildir. Threat Intelligence değiştiğinde senaryo revize edilebilir. Bir production riski ortaya çıktığında Rules of Engagement değişebilir. Yeni bir IP eklendiğinde scope manifest güncellenebilir. Bu değişikliklerin hangisinin test hipotezini, hangisinin yalnızca operasyonel uygulamayı etkilediği izlenebilmelidir.

Senaryo yazmaya attack path'ten değil, business objective'den başlayın

Red Team toplantılarında teknik hedefler hızlı belirlenir:

• Domain Admin elde etmek
• EDR bypass etmek
• Cloud Global Administrator rolüne ulaşmak
• Kritik database'e bağlanmak
• Backup console'a erişmek
• Hassas dosya indirmek

Bunların her biri anlamlı bir intermediate veya terminal technical objective olabilir. Yine de tek başına business objective değildir.

Domain Admin yetkisi, merkezi identity altyapısının etkilenebildiğini gösterebilir. Fakat kurum için asıl risk ödeme süreçlerinin manipüle edilmesi, üretimin durması, customer data'nın açığa çıkması, recovery capability'sinin etkisiz kalması veya privileged access üzerinden kritik bir hizmetin yönetilebilmesi olabilir.

Senaryo şu sırayla kurulmalıdır:

Critical business function
        ↓
Kabul edilemez business impact
        ↓
Bu etkiyi oluşturabilecek adversary intent
        ↓
Technical objective ve proof condition
        ↓
Attack path hipotezleri
        ↓
Control expectation ve measurement

Teknik ekip zincire ortadan başladığında test, kurumsal riskten kopar.

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

Güçlü objective saldırgan davranışını, business function'ı, impact türünü ve güvenli proof yöntemini aynı cümlede buluşturur.

Confidentiality, integrity, availability ve authenticity nasıl kullanılmalı?

Senaryonun yalnızca “data erişimi” üzerine kurulması gerekmez. Critical function için hangi güvenlik özelliğinin sınandığı açıkça seçilmelidir:

• Confidentiality: Yetkisiz taraf belirli bilgiye erişebilir mi?
• Integrity: İşlem, kayıt, configuration veya karar girdisi yetkisiz değiştirilebilir mi?
• Availability: Kritik function kesintiye uğratılabilir veya recovery geciktirilebilir mi?
• Authenticity: Sistem, kullanıcı, işlem veya talimat sahte bir identity tarafından geçerli gibi üretilebilir mi?

2025 yılında yayımlanan DORA TLPT technical standardı, seçilen end-to-end threat scenario'lar arasında availability, integrity ve confidentiality etkilerini kapsayan senaryolar bulunmasını ister. Her kurum bu düzenlemeye tabi değildir. Yine de bu ayrım, senaryo portföyünün yalnızca data theft etrafında dönmesini engelleyen kullanışlı bir tasarım kontrolüdür.

Flag nedir ve neden gerçek impact'in yerine kullanılmalıdır?

Flag, objective'e ulaşıldığını production'a zarar vermeden kanıtlayan kontrollü işarettir. Basit bir text file olabilir fakat iyi tasarlanmış flag yalnızca dosya okumaktan daha fazlasını temsil eder.

Örnek flag türleri:

• Yalnızca hedef role atanmış synthetic kullanıcının görebildiği kayıt
• Gerçek ödeme üretmeyen test beneficiary kaydı
• Production data ile aynı authorization path'ini kullanan fakat hassas bilgi içermeyen marker
• Backup silmeden yalnızca belirli management capability'ye erişildiğini kanıtlayan read-only artifact
• Gerçek e-mail göndermeyen sandbox mailbox içindeki unique token
• Gerçek cloud secret yerine aynı access policy ile korunan canary secret
• OT process'e komut vermeden belirli engineering workstation boundary'sinin aşıldığını gösteren marker

Kötü flag hedef sistemin yakınına bırakılmış sıradan bir dosyadır. Operator flag'i okur fakat business objective'e gerçekten ulaşılıp ulaşılmadığı kanıtlanmaz.

İyi flag şu üç özelliğe sahiptir:

1. 1Objective ile aynı authorization veya trust path'ini kullanır
2. 2Production impact oluşturmaz
3. 3Erişim zamanı, identity ve yöntem evidence ile doğrulanabilir

Threat-led senaryo nasıl oluşturulur?

Gerçekçi senaryo, internette popüler olan saldırı tekniklerinin kuruma uyarlanması değildir. Threat-led tasarım, test edilen kurum için hangi adversary davranışının neden makul olduğunu kanıtlamaya çalışır.

Threat profile oluştururken şu sorular cevaplanmalıdır:

• Kurumun sektörü, coğrafyası ve iş modeli hangi threat actor sınıflarının ilgisini çekiyor?
• Adversary'nin amacı finansal kazanç, espionage, disruption, data theft, fraud veya supply chain access mi?
• Hedeflenen business function geçmiş olaylarda nasıl istismar edilmiş?
• Adversary hangi initial access yollarını kullanıyor?
• Hangi platform ve identity katmanlarında hareket ediyor?
• Public reporting içindeki TTP evidence ne kadar güncel ve güvenilir?
• Kurumun gerçek attack surface'i bu davranışları mümkün kılıyor mu?
• Senaryonun uygulanabilirliği ile threat fidelity arasında hangi trade-off var?

Threat Intelligence yalnızca actor adı üretmemelidir. “APT-X emüle edilecektir” cümlesi tek başına senaryoyu threat-led yapmaz.

Actor cosplay yerine davranış hipotezi

Bir threat actor'a ait bütün bilinen TTP'leri kopyalamak çoğu zaman mümkün veya gerekli değildir. Public reporting eksik olabilir. Kurumun technology stack'i farklı olabilir. Bazı yöntemler production üzerinde kabul edilemez risk taşıyabilir.

Bu nedenle scenario document'ta üç katman ayrılmalıdır:

1. 1Observed behavior: Güvenilir kaynaklarda actor veya campaign ile ilişkilendirilmiş davranış
2. 2Inferred behavior: Gözlenen capability ve amaçtan hareketle makul görülen fakat doğrudan kanıtı sınırlı davranış
3. 3Emulation substitute: Aynı defensive signal veya security claim'i güvenli biçimde test etmek için seçilen alternatif implementation

Örneğin threat report belirli bir proprietary malware'in process injection kullandığını söylüyorsa, Red Team'in aynı malware'i kullanması gerekmez. Savunmanın ilgili behavior karşısındaki visibility ve detection capability'sini ölçen güvenli bir emulation substitute seçilebilir. Ancak raporda “actor tam olarak emüle edildi” iddiası yerine hangi behavioral fidelity seviyesinin sağlandığı açıklanmalıdır.

Threat evidence için confidence yazın

Her scenario assumption aynı güven düzeyine sahip değildir. Basit bir confidence modeli kullanılabilir:

Bu kayıt, senaryo seçiminin “bize ilginç geldi” düzeyinde kalmasını engeller.

Kurumunuza özel threat profile üretimi ile generic actor listesi arasındaki farkı değerlendirmek için SECNODEX Tehdit İstihbaratı hizmetini inceleyebilirsiniz.

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

MITRE ATT&CK, adversary behavior için ortak dil sağlar. Senaryoda dört amaçla kullanılabilir:

1. 1Threat reporting içindeki behavior'ları normalize etmek
2. 2Expected attack path'i teknik düzeyde ifade etmek
3. 3İlgili telemetry ve detection requirement'larını ilişkilendirmek
4. 4Operasyon sonunda planned ve observed behavior arasındaki farkı göstermek

Fakat ATT&CK Navigator'da çok sayıda technique boyamak scenario coverage anlamına gelmez.

MITRE'in Adversary Emulation Plans yaklaşımı, public threat reporting içinden actor behavior'ı çıkarır ve operator'a belirli davranışı farklı implementation'larla gösterebilmesi için alan bırakır. Bu önemli bir dengedir. Senaryo ne operator'ı tek bir kırılgan komut dizisine kilitlemeli ne de actor davranışından tamamen bağımsız hareket etmesine izin vermelidir.

Technique ile procedure'ü ayırın

Örneğin T1059 – Command and Scripting Interpreter çok geniş bir technique'tir. Bu technique'in senaryoda yer alması tek başına aşağıdaki soruları cevaplamaz:

• Hangi interpreter?
• Hangi host profile?
• Parent-child process ilişkisi ne?
• Command line görünür mü?
• Remote execution mı, local execution mı?
• Signed binary veya script host kullanılıyor mu?
• Behavior block edilirse operator hangi alternate procedure'e geçebilir?
• Beklenen telemetry hangi sensor'dan gelmeli?

Measurement plan technique ID'de değil, procedure ve context seviyesinde yazılmalıdır.

ATT&CK coverage hedefe dönüşmemeli

Red Team'in amacı matrix coverage artırmak değildir. Bir operator objective'e ulaşmak için en kısa, en sessiz veya en güvenilir path'i seçebilir. Yalnızca 12 technique kullanılması, kalan technique'lerde kurumun güvenli olduğunu göstermez.

Geniş ve repeatable technique coverage isteniyorsa Red Team yerine veya Red Team sonrasında Purple Team ya da BAS daha doğru olabilir. Bu üç modelin neyi ölçtüğünü Purple Team, Red Team ve BAS: hangi çalışma neyi ölçer? yazımızda karşılaştırıyoruz.

Başlangıç koşulu senaryonun sonucunu nasıl değiştirir?

Aynı objective, farklı assumed breach veya initial access koşullarında tamamen farklı security claim'leri test eder.

Zero-knowledge external başlangıç

Red Team yalnızca kuruma ait olduğu doğrulanmış public bilgiler ve onaylı Internet-facing attack surface ile başlar. Credential, internal access veya employee listesi verilmez.

Bu model şu alanları ölçebilir:

• External reconnaissance exposure
• Attack surface ownership
• Internet-facing vulnerability ve misconfiguration
• Remote access ve external identity control'leri
• Public cloud veya SaaS exposure
• Initial access sonrasında segmentation ve internal progression

Dezavantajı, bütün test süresinin initial access üzerinde harcanabilmesidir. Kurumun asıl sorusu internal detection ve response ise hiçbir foothold elde edilmemesi downstream capability'leri test edilmeden bırakabilir.

Assumed breach başlangıcı

Red Team'e controlled workstation access, düşük yetkili test account veya belirli segmentte foothold verilir.

Bu bir kolaylık veya hile değildir. Açıkça yazıldığında farklı bir test hipotezidir:

Assumed breach özellikle EDR, identity, Active Directory, segmentation ve SOC capability'lerini daha derin test etmek için değerlidir.

Credentialed başlangıç

Senaryoya standard user, contractor, service account, cloud user veya belirli application role ile başlanabilir. Credential'ın:

• Yetki seviyesi
• MFA durumu
• Device trust gereksinimi
• Network location koşulu
• Account lifecycle'ı
• Monitoring expectation'ı

belgelenmelidir.

Physical veya social engineering başlangıcı

Badge tailgating, removable media, vishing, phishing veya help desk manipulation gibi yöntemler insan ve süreç katmanını kapsayabilir. Ancak yalnızca “phishing serbest” demek yeterli değildir.

Target population, message theme, pretext, credential collection sınırı, attachment type, call recording, personal data, working hour, senior executive exclusion, sağlık ve güvenlik riski ile escalation modeli ayrıca yazılmalıdır.

Leg-up ne zaman kullanılmalı?

Leg-up, scenario progression'ın belirli noktada kontrollü destekle devam ettirilmesidir. Örneğin external initial access belirlenen süre içinde elde edilemezse Control Team test account veya internal foothold sağlar.

Leg-up kullanılması gizlenmemelidir. Sonuç iki ayrı güvenlik iddiası olarak raporlanmalıdır:

1. 1External initial access objective'i doğal attack path ile elde edilemedi
2. 2Assumed foothold sonrasında internal objective'e ilerleme sonucu

Bu ayrım yapılmazsa rapor, Red Team'in bütün attack chain'i bağımsız tamamladığı izlenimini verir.

Leg-up için önceden şu alanlar yazılmalıdır:

• Activation trigger
• Earliest activation time
• Approval owner
• Verilecek access seviyesi
• Red Team'e açıklanacak context
• Hangi metric'lerin leg-up sonrasında yeniden başlayacağı
• Raporlama etiketi

Scope asset listesi değil, yetkilendirilmiş bir trust boundary modelidir

Red Team scope'u yalnızca IP, domain ve application listesi olarak yazıldığında attack path'in önemli bölümü belirsiz kalır.

Gerçek bir objective şu bağımlılıklardan geçebilir:

• Internet-facing application
• Identity provider
• MFA service
• Endpoint fleet
• Active Directory
• Cloud tenant
• CI/CD platformu
• Secrets manager
• VPN ve remote access altyapısı
• E-mail tenant
• Backup platformu
• Network management plane
• Third-party integration
• Managed service provider
• SaaS application
• Physical location

Scope bu trust relationship'leri dikkate almalıdır.

Üç seviyeli scope modeli

Her asset şu sınıflardan birine alınabilir:

“Out-of-scope fakat gözlemlenebilir” kategorisi de yararlı olabilir. Red Team public reconnaissance sırasında third-party asset'i pasif olarak görebilir, relationship'i kaydedebilir fakat aktif action uygulamaz.

Scope manifest hangi alanları içermeli?

En az şu bilgiler tutulmalıdır:

Asset ID
Asset type
FQDN / IP / CIDR / Tenant ID / Application ID
Environment
Business owner
Technical owner
Legal owner
Hosting veya service provider
In-scope / Conditional / Out-of-scope
Allowed actions
Prohibited actions
Test window
Data classification
Criticality
Approval reference
Notes

Cloud subscription, SaaS tenant ve third-party managed service için yalnızca müşteri yöneticisinin “biz kullanıyoruz” demesi testing authority oluşturmaz. Contract, provider policy ve gerçek asset ownership kontrol edilmelidir.

Kısıtlar nasıl yazılmalı?

Kısıtların amacı Red Team'i etkisiz hale getirmek değildir. Amaç hangi riski hangi safety envelope içinde alacağınızı önceden kararlaştırmaktır.

Zayıf kısıt:

Bu cümle niyeti anlatır fakat operator'a karar verdirmez. Account lockout zarar sayılır mı? AV quarantine production agent'ı etkiler mi? Test e-mail'i gerçek mail gateway'den geçebilir mi? Bir file share'e marker yazmak değişiklik sayılır mı?

Kısıtlar action ve outcome seviyesinde yazılmalıdır.

Allowed action

Örnekler:

• Onaylı public asset'lerde non-destructive reconnaissance
• Test account'larda authentication attempt
• Rate limit ve lockout threshold içinde credential testing
• Onaylı endpoint'lerde controlled payload execution
• Synthetic marker ile data access validation
• Belirlenen egress destination'a küçük ve inert test artifact aktarımı
• Conditional asset üzerinde Control Team approval sonrası read-only access

Prohibited action

Örnekler:

• Gerçek müşteri verisinin dışarı aktarılması
• Production kaydının değiştirilmesi veya silinmesi
• Ransomware encryption
• Destructive malware
• Denial-of-service ve resource exhaustion
• Safety system'e komut gönderme
• Onaysız persistence
• Shared third-party infrastructure'a aktif test
• Test dışı kişilere gerçek credential gönderme
• Executive, healthcare veya personal emergency temalı social engineering

Conditional action

Bazı action'lar tamamen yasaklanmak yerine ayrı approval gate'e bağlanabilir:

• Privileged account kullanımı
• Production'da payload execution
• Password hash erişimi
• E-mail tenant üzerinde rule oluşturma
• Cloud role assignment
• Backup console'a erişim
• Physical access denemesi
• Gerçek Blue Team containment action'ını tetikleme

Her conditional action için onayı verecek rol, communication channel ve maksimum bekleme süresi yazılmalıdır. Gece 02.00'de kimin karar vereceği bilinmiyorsa approval gate operasyon sırasında çalışmaz.

Kısıtlar senaryoyu geçersiz hale getirebilir

Kurum bütün realistic initial access yollarını yasaklayıp yine de “external adversary emulation” sonucu bekleyebilir. Örneğin phishing, external exploitation, credential attack, third-party path ve cloud attack surface tamamen yasakken Red Team'in Internet'ten başlaması istenebilir.

Bu durumda dürüst yaklaşım iki seçenekten biridir:

1. 1Objective ve test iddiası daraltılır
2. 2Assumed breach veya leg-up ile downstream capability ayrı ölçülür

Kısıtların çokluğu başarı değildir. Kısıtın test validity üzerindeki etkisi scenario document'ta açıkça yazılmalıdır.

Stop condition, pause condition ve notification threshold aynı değildir

Bu üç kavram sık karıştırılır.

Notification threshold

Operasyon devam eder fakat Control Team bilgilendirilir.

Örnek:

• Privileged role elde edildi
• Unexpected sensitive data görüldü fakat erişilmedi
• Blue Team activity'si gözlendi
• Conditional asset'e yaklaşan attack path oluştu
• Yeni ve kritik bir vulnerability bulundu

Pause condition

İlgili action veya scenario branch geçici olarak durdurulur. Control Team değerlendirmesi olmadan devam edilmez.

Örnek:

• Production latency belirlenen threshold'u aştı
• Target ownership konusunda belirsizlik oluştu
• Third-party boundary'ye geçiş ihtimali görüldü
• Test account yerine gerçek kullanıcı account'ı etkilendi
• Beklenmeyen security control degradation meydana geldi

Stop condition

Operasyonun tamamı derhal sonlandırılır veya kill switch uygulanır.

Örnek:

• Gerçek incident ile test aktivitesi ayırt edilemiyor
• Production outage veya safety impact oluştu
• Yazılı authorization geçerliliğini kaybetti
• Hassas veri kontrolsüz biçimde dışarı çıktı
• C2 infrastructure compromise edildi
• Law enforcement veya regulator kaynaklı acil talep geldi
• Control Team lead operasyonu durdurdu

Stop condition yalnızca bir liste olmamalıdır. Her condition için detection source, karar sahibi, iletişim sırası, operator action'ı, cleanup ve resume authority tanımlanmalıdır.

Rules of Engagement hangi teknik maddeleri içermeli?

Profesyonel bir Rules of Engagement en az aşağıdaki alanları kapsamalıdır.

1. Yazılı authorization

• Yetki veren tüzel kişi
• İmza yetkilisi
• Yetkinin kapsadığı asset'ler
• Tarih ve saat aralığı
• Tester ve provider kimliği
• Third-party approval'ları
• Applicable law, contract ve provider policy

NDA gizliliği düzenler. Testing authority yerine geçmez.

2. Katılımcılar ve bilgi modeli

• Executive sponsor
• Control Team lead
• Control Team üyeleri
• Red Team lead ve operator'lar
• Legal ve privacy contact
• Emergency infrastructure contact
• Gerekirse regulator veya test manager
• Blue Team'in bilgi seviyesi

Blue Team'in testten habersiz olması, kurum içinde kimsenin bilmemesi anlamına gelmez. Dar bir Control Team güvenli yürütme ve deconfliction için operasyondan haberdar olmalıdır.

3. Communication plan

• Normal update channel
• Emergency channel
• PGP veya güvenli dosya aktarımı
• Günlük veya haftalık reporting cadence
• Critical finding notification SLA
• Out-of-band contact
• Primary ve secondary contact
• Contact unavailable olduğunda fallback

4. Source infrastructure

• Red Team source IP'leri
• Redirector ve C2 domain'leri
• E-mail infrastructure
• Test phone number'ları
• Payload signing ve checksum bilgisi
• Deconfliction marker'ları
• Infrastructure shutdown yöntemi

Bu bilgiler herkese dağıtılmamalıdır. Control Team tarafından güvenli biçimde tutulmalıdır.

5. Data handling

• Hangi data görüntülenebilir?
• Hangi data kopyalanabilir?
• Maksimum sample boyutu nedir?
• Encryption standardı nedir?
• Evidence nerede tutulur?
• Kim erişebilir?
• Retention süresi nedir?
• Secure deletion nasıl kanıtlanır?
• Credential ve secret'lar operasyon sonunda nasıl revoke edilir?

6. Cleanup ve restoration

• Oluşturulan account'lar
• Değiştirilen configuration
• Dropped file ve payload'lar
• Persistence mechanism'leri
• Scheduled task ve service'ler
• Cloud token ve access key'ler
• Test mailbox rule'ları
• C2 ve redirector altyapısı
• Backup içinde kalabilecek artifact'ler

Cleanup yalnızca “payload'lar silindi” cümlesiyle kapatılmamalıdır. Asset bazlı evidence ve müşteri doğrulaması gerekir.

Red Team satın alma dokümanında bu sınırların nasıl güvence altına alınacağını ayrıca Sızma testi teklifinde hangi teknik maddeler olmalı? yazımızdaki authorization ve acceptance yaklaşımıyla birlikte değerlendirebilirsiniz.

End-to-end attack path nasıl tasarlanır?

Senaryo ne tek bir doğrusal yol olmalı ne de “operator istediğini yapar” kadar sınırsız bırakılmalıdır.

En kullanışlı model, attack path hipotezlerini branch'lerle tanımlamaktır:

Entry condition
├── Path A: External application → workload identity → cloud control plane
├── Path B: Remote access → endpoint foothold → enterprise identity
└── Path C: Third-party trust → integration account → critical application
                              ↓
                       Objective boundary
                              ↓
                         Safe proof / flag

Bu diyagram kesin yürütme sırası değildir. Threat-informed ve scope içindeki makul yolları gösterir.

IN, THROUGH ve OUT modeli

TIBER-EU ve DORA TLPT yaklaşımında Red Team test planı üç operasyonel phase üzerinden ele alınır:

• IN phase: Kurumun ICT sistemlerine giriş
• THROUGH phase: Sistemler içinde ilerleme
• OUT phase: Actions on objectives ve sistemlerden güvenli çıkış

Bu ayrım senaryo tasarımında güçlüdür.

IN phase soruları

• Initial access hangi surface üzerinden denenebilir?
• Zero-knowledge mi, assumed condition mı?
• Birden fazla entry path var mı?
• Initial access başarısızsa leg-up ne zaman devreye girer?
• External prevention ve detection nasıl ölçülür?

THROUGH phase soruları

• Hangi trust boundary'ler aşılabilir?
• Identity, endpoint, network ve cloud arasında nasıl geçiş olabilir?
• Discovery ne kadar serbesttir?
• Privilege escalation için hangi action'lar conditional'dır?
• Segmentation ve monitoring hangi noktada sınanır?

OUT phase soruları

• Objective hangi flag ile kanıtlanır?
• Gerçek impact yerine hangi safe substitute kullanılacak?
• Data egress gerekiyor mu?
• Persistence veya recovery impact'i nasıl güvenli doğrulanacak?
• Cleanup ve evidence handover nasıl yapılacak?

Attack path'in ön koşullarını yazın

Her path için precondition açık olmalıdır.

Örnek:

Path ID: PATH-CLOUD-02
Hypothesis:
  External workload compromise sonrasında bağlı managed identity,
  yanlış privilege boundary nedeniyle target secret'a erişebilir.

Preconditions:
  - Workload production ile aynı identity modelini kullanıyor
  - Managed identity target secret için indirect permission taşıyor
  - Egress onaylı test destination'a açık

Invalidation:
  - Identity relationship test başlamadan kaldırılmışsa
  - Workload yalnızca isolated test tenant'ta ise
  - Target secret farklı policy path'i kullanıyorsa

Safe proof:
  - Gerçek secret yerine aynı policy ile korunan canary secret

Precondition yazılmadığında başarısız path yanlış yorumlanabilir. Operator'ın exploit edememesi kontrolün çalıştığını gösterebilir. Fakat gerekli dependency'nin hiç bulunmaması da aynı sonucu üretir.

Kullanılabilir bir Red Team senaryosu için YAML örneği

Aşağıdaki örnek doğrudan attack command içermez. Amaç senaryoyu version control altında, machine-readable ve denetlenebilir biçimde yönetmektir.

scenario:
  id: RT-2026-PAYMENT-01
  version: 1.3
  classification: CONFIDENTIAL
  owner: Security Assurance
  approved_by:
    - Executive Sponsor
    - Control Team Lead
    - Legal

  mission:
    critical_function: Supplier Payment Approval
    business_concern: >
      Yetkisiz bir tarafın ödeme talimatı oluşturması veya onay akışını
      güvenilir bir identity üzerinden manipüle etmesi.
    objective: >
      Internet-facing attack surface'ten başlayarak payment approval
      workflow'undaki synthetic beneficiary kaydına yetkisiz değişiklik
      capability'sini production işlemi üretmeden doğrulamak.
    impact_dimensions:
      confidentiality: false
      integrity: true
      availability: false
      authenticity: true

  threat_profile:
    actor_class: Financially motivated intrusion set
    intent: Payment fraud
    capability: Intermediate to advanced
    confidence: high
    evidence_cutoff: 2026-06-30
    behavioral_requirements:
      - external_initial_access
      - identity_abuse
      - internal_discovery
      - privilege_progression
      - business_application_access

  starting_condition:
    type: zero_knowledge_external
    provided_access: none
    leg_up:
      enabled: true
      earliest_day: 8
      approval: Control Team Lead
      access_profile: standard_user_on_managed_endpoint
      reporting_label: ASSUMED_BREACH

  scope:
    in_scope:
      - id: EXT-APP-01
        type: web_application
        environment: production
      - id: IDP-01
        type: identity_provider
        environment: production
      - id: PAY-APP-01
        type: business_application
        environment: production
    conditional:
      - id: PAY-DB-01
        condition: read_only_after_control_team_approval
    out_of_scope:
      - customer_accounts
      - shared_third_party_infrastructure
      - payment_execution_gateway

  rules:
    allowed:
      - non_destructive_reconnaissance
      - test_account_authentication
      - controlled_execution_on_approved_endpoints
      - synthetic_flag_access
    prohibited:
      - denial_of_service
      - real_payment_creation
      - real_customer_data_exfiltration
      - destructive_malware
      - unapproved_third_party_testing
    conditional:
      - privileged_role_use
      - production_payload_execution
      - configuration_change

  safety:
    test_window_timezone: Europe/Istanbul
    stop_conditions:
      - confirmed_production_outage
      - uncontrolled_sensitive_data_access
      - loss_of_target_ownership_confidence
      - real_incident_deconfliction_failure
    emergency_contact_role: Control Team Lead
    kill_switch_owner: Red Team Lead

  proof:
    flag_id: FLAG-PAYMENT-01
    type: synthetic_beneficiary_record
    required_evidence:
      - UTC_timestamp
      - source_identity
      - target_object_id
      - minimal_screenshot
      - sanitized_request_or_audit_event

  measurement:
    offensive:
      - objective_state
      - trust_boundaries_crossed
      - leg_ups_used
      - attack_path_preconditions
    defensive:
      - prevention_result
      - telemetry_presence
      - confirmed_detection_time
      - scope_completion_time
      - containment_time
    safety:
      - unplanned_outage_count
      - uncontrolled_data_event_count
      - rules_of_engagement_deviation_count

  closure:
    cleanup_evidence_required: true
    credential_rotation_required: true
    purple_team_replay: planned
    remediation_owner_required: true

Bu format tek başına yeterli değildir. Her ID'nin asset register, evidence repository, ATT&CK mapping ve approval record ile ilişkilendirilmesi gerekir. Yine de dağınık e-mail kararlarını tek bir kontrollü modelde toplamak için güçlü bir başlangıçtır.

Başarı ölçütleri nasıl yazılmalı?

Red Team senaryosundaki en yaygın hata başarıyı tek cümleye indirmektir:

Bu yaklaşım Red Team'in teknik sonucunu ölçer. Kurumun savunma performansını, test güvenliğini veya öğrenme sonucunu ölçmez.

Başarı en az üç ayrı düzlemde değerlendirilmelidir:

1. 1Offensive objective sonucu
2. 2Defensive capability sonucu
3. 3Safety ve governance sonucu

Red Team objective state

Binary sonuç yerine progression seviyesi kullanılabilir:

Bu seviyeler her scenario için özelleştirilmelidir. R5'e ulaşılamaması, R3'te bulunan systemic identity weakness'in önemsiz olduğu anlamına gelmez.

Blue Team için detection pipeline

“SOC gördü” ifadesi ölçüm değildir. Aşağıdaki zincir ayrı ayrı incelenmelidir:

Adversary action
      ↓
Local telemetry
      ↓
Central ingestion
      ↓
Parsing ve enrichment
      ↓
Detection analytic
      ↓
Alert creation
      ↓
Triage
      ↓
Confirmed detection
      ↓
Attack scope
      ↓
Containment

Bir endpoint event'i oluşmuş fakat SIEM'e gelmemiş olabilir. SIEM'e gelmiş fakat parser field'ları bozuk olabilir. Detection rule alert üretmiş fakat yanlış queue'ya yönlenmiş olabilir. Analyst alert'i görmüş fakat isolated event sanarak attack chain'i scope edememiş olabilir.

Bu durumların tamamına “detected” demek root cause'u görünmez hale getirir.

Temel zaman metric'leri

Timestamp tanımları önceden yazılmalıdır:

Time to Alert =
  alert_created_at - qualifying_action_at

Time to Confirmed Detection =
  incident_confirmed_at - qualifying_action_at

Time to Scope =
  material_scope_identified_at - incident_confirmed_at

Time to Contain =
  effective_containment_at - incident_confirmed_at

Buradaki qualifying_action_at senaryonun ilk günü olmak zorunda değildir. Ölçülen detection use case'i için teknik olarak gözlemlenebilir ilk ilgili action'dır.

Saatlerin NTP ile senkronize edilmesi, timezone'un sabitlenmesi ve Red Team timeline ile SOC case timeline'ın ortak referansa dönüştürülmesi gerekir. Aksi halde dakikalar üzerinden yapılan karşılaştırma sahte hassasiyet üretir.

Prevention ile detection ayrı ölçülmeli

Bir action endpoint üzerinde block edildiyse prevention control çalışmış olabilir. Downstream behavior oluşmadığı için o davranışın detection pipeline'ı test edilmemiş olabilir.

Sonuç şöyle yazılmalıdır:

Execution validity: Valid
Prevention: Blocked
Local telemetry: Present
Central telemetry: Present
Detection analytic: Not evaluated for post-execution behavior
Operational response: Not triggered by design

“Saldırı başarısız, dolayısıyla bütün kontroller başarılı” sonucu çıkarılamaz.

Detection rate nasıl hesaplanmalı?

Basit oran:

Confirmed Detection Rate =
  Confirmed detections / Valid detection opportunities

Asıl sorun denominator'dadır. Red Team'in attığı her komut detection opportunity değildir. Birden fazla action aynı analytic'e ait olabilir. Block edilen action downstream opportunity oluşturmamış olabilir. Test sırasında geçersiz kalan execution metric'e dahil edilmemelidir.

Bu nedenle her opportunity için şu context tutulmalıdır:

• Test case veya attack step ID
• Procedure
• Target profile
• Execution validity
• Expected data source
• Expected analytic
• Expected response
• Prevention sonucu
• Detection sonucu
• Exclusion gerekçesi

Tek bir yüzde yerine missed opportunity'lerin iş etkisine göre ayrılması daha değerlidir.

Safety başarı ölçütleri

Red Team teknik objective'e ulaşsa bile Rules of Engagement ihlal edilmişse engagement başarılı kabul edilemez.

Örnek safety metric'leri:

• Unplanned outage count: 0
• Gerçek customer data exfiltration: 0
• Unauthorized third-party interaction: 0
• Unapproved persistence: 0
• Lost test artifact: 0
• RoE deviation: 0
• Cleanup completion: %100
• Compromised test credential rotation: %100
• Critical incident deconfliction SLA: ≤ 15 dakika

Safety metric'leri “hiç kesinti olmadı” ifadesinden daha güçlüdür çünkü hangi undesirable outcome'un izlendiğini gösterir.

Tam bir Red Team senaryo örneği

Aşağıdaki örnek, finans sektörüne özel bir zorunluluk varsaymadan ödeme süreci üzerinden oluşturulmuştur.

Business concern

Kurumun tedarikçi ödeme talimatları e-mail, identity provider ve finans application'ı arasında ilerlemektedir. Management concern, external bir adversary'nin güvenilir bir employee identity'si üzerinden beneficiary bilgisini değiştirebilmesi ve onay sürecinde sahte talimatı meşru gösterebilmesidir.

Senaryo sorusu

Objective

Gerçek ödeme oluşturmadan, production ile aynı authorization path'ini kullanan synthetic beneficiary kaydının yetkisiz değiştirilebildiğini veya değiştirilemediğini doğrulamak.

Threat rationale

• Actor class: Financially motivated intrusion set
• Intent: Payment fraud
• Capability: Intermediate to advanced
• Relevant behavior: External initial access, credential access, identity abuse, internal discovery, business application access
• Confidence: High for actor intent, medium for kuruma özel initial access route

Starting condition

• Primary phase: Zero-knowledge external
• Social engineering: Kapsam dışı
• Password spraying: Test account ve onaylı threshold ile conditional
• Day 8'e kadar foothold yoksa: Managed endpoint üzerinde standard test user leg-up

Scope

In-scope:

• Public application ve API
• Kurumsal identity provider
• Onaylı workstation grubu
• Internal identity service
• Payment approval application
• Synthetic beneficiary object

Conditional:

• Production database read-only access
• Privileged role kullanımı
• Cloud audit configuration'a yalnızca görüntüleme

Out-of-scope:

• Gerçek payment gateway
• Customer ve supplier account'ları
• Third-party bank infrastructure
• Production record deletion
• Denial-of-service

Attack path hipotezleri

1. 1External application weakness üzerinden workload veya identity context elde edilmesi
2. 2Remote access veya exposed identity flow üzerinden standard user context elde edilmesi
3. 3Unmanaged integration veya stale credential üzerinden trusted application access
4. 4Initial foothold sonrasında internal identity ve role assignment weakness'leriyle progression
5. 5Payment application authorization boundary'sine erişim
6. 6Synthetic beneficiary flag'iyle objective proof

Bu yolların tamamının yürütülmesi gerekmez. Operator threat fidelity, stealth, safety ve elde edilen evidence'a göre path seçebilir.

Red Team success criteria

• R1: Valid external foothold veya önceden onaylı leg-up
• R2: Internal identity context
• R3: Payment application'a erişebilen role progression
• R4: Synthetic beneficiary kaydına unauthorized write capability
• R5: Unique flag değeriyle kontrollü proof

Leg-up kullanıldıysa external ve internal sonuçlar ayrı raporlanır.

Blue Team success criteria

• Initial access'a ait qualifying event merkezi telemetry'de mevcut
• İlgili behavior için alert hedef SLA içinde oluşuyor
• Analyst olayın test olduğunu bilmeden malicious activity olarak sınıflandırıyor
• Investigation yalnızca ilk host'u değil, identity ve application scope'unu belirliyor
• Compromised account ve endpoint doğru containment action'larıyla sınırlandırılıyor
• Payment application owner'a tanımlı escalation path üzerinden ulaşılıyor
• Synthetic objective gerçekleşmeden veya tanımlı risk window içinde response tamamlanıyor

Safety success criteria

• Gerçek ödeme oluşmuyor
• Gerçek beneficiary kaydı değişmiyor
• Hassas finans verisi Red Team altyapısına çıkmıyor
• Production outage oluşmuyor
• Test account dışındaki account'larda lockout oluşmuyor
• Bütün artifact'ler closure aşamasında kaldırılıyor

Evidence

• Red Team timestamp'li operation log
• Target ve source identity
• Sanitized screenshot
• İlgili audit event
• SOC alert ve case ID
• Analyst action timeline
• Containment evidence
• Leg-up ve approval kayıtları
• Cleanup manifest

Bu yapı sonunda “Red Team ödeme sistemine girdi” gibi tek cümlelik bir sonuç yerine, hangi path'in çalıştığı, hangi control'ün nerede devreye girdiği ve remediation'ın hangi owner'a ait olduğu görülebilir.

Scenario design workshop nasıl yürütülmeli?

Senaryo yalnızca Red Team provider ile security manager arasında yazılmamalıdır. Critical business function'ı ve gerçek operasyonel sınırları bilen kişiler sürece katılmalıdır.

Gerekli roller

• Executive sponsor
• Business function owner
• Security assurance veya Red Team owner
• Threat Intelligence
• Control Team lead
• Infrastructure ve cloud owner
• Identity owner
• Application owner
• SOC veya Detection Engineering temsilcisi
• Incident Response
• Legal ve privacy
• Business continuity
• Gerekirse physical security ve third-party owner

Blue Team'in covert testten habersiz kalması isteniyorsa workshop'a tüm SOC ekibi katılmaz. Detection expectation'ları Control Team içinde gerekli gizlilikle temsil edilebilir.

Workshop sırası

1. Critical function'ı seçin

“ERP”, “Active Directory” veya “cloud” function değildir. Ödeme onayı, üretim planlama, müşteri kimlik doğrulama, order fulfillment, settlement veya recovery gibi business outcome seçilmelidir.

2. Kabul edilemez etkiyi yazın

Hangi confidentiality, integrity, availability veya authenticity kaybı kurum için kritik?

3. Threat profile'ı doğrulayın

Actor class, intent, capability ve evidence değerlendirilir. Popüler actor adı yerine kurumla ilişkili behavior seçilir.

4. Starting condition'ı kararlaştırın

External, assumed breach, credentialed, physical veya hybrid modelden hangisi asıl security claim'i test ediyor?

5. Trust boundary'leri çizin

Objective'e giden identity, application, network, cloud ve third-party bağımlılıkları belirlenir.

6. Scope ve safety envelope'u sabitleyin

In-scope, conditional ve out-of-scope target'lar yazılır. Stop condition ve emergency contact doğrulanır.

7. Flag ve evidence'ı tasarlayın

Production impact yerine objective'i hangi safe proof temsil edecek?

8. Metric'leri önceden tanımlayın

Red Team progression, Blue Team pipeline ve safety sonuçları ayrılır.

9. Leg-up ve change control belirleyin

Senaryo hangi noktada destekle ilerleyecek? Hangi değişiklik kim tarafından onaylanacak?

10. Tabletop walkthrough yapın

Operasyon başlamadan scenario document masa üzerinde yürütülür. “Şu gerçekleşirse kim aranır?” sorusu her critical branch için cevaplanır.

Senaryo yazarken yapılan en yaygın 12 hata

1. Objective'i “Domain Admin olmak” diye bırakmak

Technical privilege business impact'e bağlanmadığında yönetim sonucu doğru yorumlayamaz.

2. Generic bir APT adı seçmek

Actor adı vardır fakat kuruma özgü threat rationale, intent ve TTP evidence yoktur.

3. MITRE ATT&CK heatmap'i senaryo sanmak

Technique listesi attack flow, precondition, objective ve measurement sağlamaz.

4. Scope'u yalnızca IP listesiyle yazmak

Cloud tenant, SaaS, identity, third-party trust ve critical function bağımlılıkları kaybolur.

5. Social engineering'i tek satırda serbest bırakmak

Target population, pretext, veri toplama ve etik sınırlar belirlenmez.

6. “Zarar verilmemeli” dışında safety control yazmamak

Operator gerçek zamanlı karar için action-level kısıt bulamaz.

7. Stop condition ile notification threshold'u karıştırmak

Her kritik olay tüm operasyonu gereksiz durdurabilir veya durması gereken olay yalnızca e-mail olarak kalabilir.

8. Leg-up kullanımını başarısızlık gibi görmek

Downstream control'ler hiç ölçülemez. Daha kötüsü, kullanılan leg-up final report'ta açıklanmaz.

9. Başarıyı yalnızca Red Team'e göre tanımlamak

Blue Team'in doğru detection ve containment performansı “Red Team başarısız oldu” diye değersizleştirilir.

10. Alert'i detection kabul etmek

Alert oluşur fakat triage, scope ve response gerçekleşmez.

11. Gerçek data'yı proof olarak kullanmak

Objective'in kanıtı için gereksiz privacy, legal ve operational risk alınır.

12. Cleanup'ı proje kapanışında hatırlamak

Credential, persistence, cloud token ve payload inventory'si eksik kalır.

Operasyon sırasında senaryo değiştirilebilir mi?

Evet. Red Team gerçek bir operator davranışını emüle ettiği için yeni attack surface, beklenmeyen trust relationship veya güncel Threat Intelligence ortaya çıkabilir. Ancak senaryo değişikliği kayıt dışı yapılamaz.

Her değişiklik için şu sorular cevaplanmalıdır:

• Değişiklik objective'i etkiliyor mu?
• Yeni asset için yazılı authorization var mı?
• Safety risk'i değişiyor mu?
• Yeni TTP Rules of Engagement içinde mi?
• Measurement baseline bozuluyor mu?
• Blue Team awareness seviyesini etkiliyor mu?
• Ek third-party approval gerekiyor mu?
• Change'i kim onayladı?
• Hangi tarih ve saatte yürürlüğe girdi?

Basit bir change record:

Change ID: CHG-RT-014
Requested at: 2026-08-12T21:40:00+03:00
Requested by: Red Team Lead
Reason: Newly discovered identity trust path
Affected scope: IDP-02
Authorization verified: Yes
Safety impact: Medium
Measurement impact: New conditional branch
Approved by: Control Team Lead
Effective at: 2026-08-12T22:05:00+03:00

Bu kayıt operator'ı bürokrasiye boğmak için değil, test sonucunun sonradan yeniden oluşturulabilmesi için tutulur.

Red Team raporu senaryoya nasıl geri bağlanmalı?

Rapor yalnızca vulnerability listesi sunmamalıdır. Scenario design ile sonuç arasında traceability kurulmalıdır.

1. Scenario summary

• Business concern
• Threat profile
• Objective
• Starting condition
• Scope
• Test period
• Leg-up kullanımı

2. Planned ve observed attack path

Planlanan hipotezler ile fiilen kullanılan path ayrı gösterilir. Operator'ın neden branch değiştirdiği açıklanır.

3. Objective state

R0-R5 gibi önceden tanımlanmış progression modeline göre sonuç ve flag evidence verilir.

4. Defensive timeline

Her material attack step için:

• Action timestamp
• Prevention
• Local telemetry
• Central telemetry
• Detection
• Alert
• Analyst action
• Scope
• Containment

5. Root cause

“EDR yakalamadı” tek başına root cause değildir. Sensor eksikliği, logging policy, parser, analytic logic, alert routing, triage kararı, identity context veya ownership gap'i ayrıştırılmalıdır.

6. Safety ve deviation

• Rules of Engagement deviation
• Pause ve stop event'leri
• Unexpected impact
• Deconfliction
• Cleanup sonucu

7. Remediation ve replay

Her finding için:

• Root cause
• Business impact
• Remediation owner
• Due date
• Validation yöntemi
• Purple Team replay
• Regression test adayı

Red Team'in bir attack story üretmesi değerlidir. Fakat çalışma, aynı path'in kapandığını kanıtlayan validation planına dönüşmediğinde hikâye olarak kalır.

Kopyalanabilir Red Team senaryo şablonu

Aşağıdaki iskelet kickoff öncesinde kullanılabilir:

# Red Team Scenario: [Scenario Name]

## 1. Document control
- Scenario ID:
- Version:
- Classification:
- Owner:
- Approvers:
- Validity period:

## 2. Business context
- Critical business function:
- Business owner:
- Unacceptable impact:
- CIAA dimension:

## 3. Mission objective
- Scenario question:
- Primary objective:
- Secondary objectives:
- Safe proof / flag:

## 4. Threat profile
- Actor class:
- Intent:
- Motivation:
- Capability:
- Relevant TTPs:
- Evidence sources:
- Confidence:
- Intelligence cutoff date:

## 5. Starting condition
- Zero-knowledge / Assumed breach / Credentialed / Physical:
- Provided access:
- Initial constraints:
- Leg-up trigger:
- Leg-up approval:

## 6. Scope
### In-scope
### Conditional
### Out-of-scope
### Observable but not testable
### Third-party dependencies

## 7. Attack path hypotheses
- Path A:
- Path B:
- Path C:
- Preconditions:
- Invalidation conditions:

## 8. Rules of Engagement
### Allowed actions
### Prohibited actions
### Conditional actions
### Test window
### Source infrastructure
### Social engineering boundaries
### Data handling

## 9. Safety
- Notification thresholds:
- Pause conditions:
- Stop conditions:
- Emergency contacts:
- Kill switch:
- Deconfliction process:

## 10. Measurement
### Red Team objective states
### Prevention expectations
### Telemetry expectations
### Detection expectations
### Response expectations
### Safety metrics
### Timestamp standard

## 11. Evidence
- Required artifacts:
- Storage:
- Encryption:
- Access:
- Retention:
- Secure deletion:

## 12. Reporting and closure
- Update cadence:
- Critical notification SLA:
- Cleanup manifest:
- Credential rotation:
- Purple Team replay:
- Remediation owner:
- Retest criteria:

Bu şablon her kuruma aynı biçimde uygulanmamalıdır. OT, cloud, payment, healthcare, SaaS ve physical security senaryolarının safety boundary'leri farklıdır. Şablon düşünmeyi standartlaştırır, sonucu değil.

Red Team senaryosu için son kontrol listesi

Objective

• [ ] Critical business function tanımlı
• [ ] Kabul edilemez business impact açık
• [ ] Technical objective business outcome'a bağlı
• [ ] Safe proof veya flag hazır
• [ ] Primary ve secondary objective ayrılmış

Threat fidelity

• [ ] Actor class ve intent tanımlı
• [ ] Kuruma özel relevance açıklanmış
• [ ] TTP evidence güncel
• [ ] Confidence belirtilmiş
• [ ] Observed, inferred ve substitute behavior ayrılmış

Scope

• [ ] Asset ownership doğrulanmış
• [ ] In-scope, conditional ve out-of-scope ayrılmış
• [ ] Cloud ve SaaS tenant'lar eklenmiş
• [ ] Third-party boundary kontrol edilmiş
• [ ] Data classification yazılmış

Rules of Engagement

• [ ] Yazılı authorization var
• [ ] Allowed, prohibited ve conditional action'lar açık
• [ ] Test window ve timezone belli
• [ ] Social engineering sınırları belirli
• [ ] Data handling ve retention tanımlı
• [ ] Source infrastructure Control Team'de kayıtlı

Safety

• [ ] Notification threshold tanımlı
• [ ] Pause condition tanımlı
• [ ] Stop condition tanımlı
• [ ] Emergency contact test edildi
• [ ] Kill switch uygulanabilir
• [ ] Real incident deconfliction süreci var

Measurement

• [ ] Red Team progression state'leri belli
• [ ] Blue Team detection pipeline ayrı ölçülüyor
• [ ] Metric başlangıç ve bitiş event'leri tanımlı
• [ ] Execution validity kaydediliyor
• [ ] Prevention ve detection ayrılmış
• [ ] Safety metric'leri var

Closure

• [ ] Cleanup manifest hazırlanmış
• [ ] Credential ve token rotation planlanmış
• [ ] Evidence handover tanımlı
• [ ] Secure deletion doğrulanacak
• [ ] Purple Team replay planlanmış
• [ ] Remediation ve retest owner'ı belli

Sonuç: İyi senaryo saldırıyı tarif etmez, ölçümü tasarlar

Red Team senaryosu yazmanın en zor kısmı hangi tool'un veya technique'in kullanılacağını seçmek değildir. Zor olan, teknik saldırıyı kurumun gerçek business risk'ine bağlamak ve sonuç ne olursa olsun yorumlanabilir bir ölçüm üretmektir.

İyi hazırlanmış bir senaryoda:

• Objective kritik bir business function'a bağlıdır
• Threat profile'ın neden seçildiği kanıtlanabilir
• Starting condition ve assumption'lar gizlenmez
• Scope asset kadar trust boundary'leri de kapsar
• Operator'a karar alanı bırakılır
• Allowed, prohibited ve conditional action'lar nettir
• Stop condition uygulanabilir durumdadır
• Gerçek impact yerine güvenli flag kullanılır
• Red Team ve Blue Team başarısı ayrı ölçülür
• Leg-up, deviation ve change kayıt altına alınır
• Cleanup ve replay daha operasyon başlamadan planlanır

En zayıf senaryo “bize saldırın ve yakalanmayın” der. En güçlü senaryo ise şu soruyu ölçülebilir hale getirir:

SECNODEX, Red Team çalışmalarını generic attack checklist'leriyle değil, kuruma özgü critical function, Threat Intelligence, objective, Rules of Engagement ve evidence modeli üzerinden tasarlar. OSCP ve OSWE sertifikalarına sahip uzman kadromuz, teknik attack path'i business impact ve defensive response ile birlikte değerlendirir. Kurumunuz için ölçülebilir ve güvenli bir adversary emulation planı hazırlamak üzere SECNODEX Red Team hizmetini inceleyebilir veya bizimle iletişime geçebilirsiniz.

Kaynaklar

• NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment
• NIST CSRC – Rules of Engagement
• MITRE ATT&CK – Adversary Emulation Plans
• MITRE ATT&CK – Adversary Emulation and Red Teaming
• MITRE Center for Threat-Informed Defense – Adversary Emulation Library
• 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
• CISA – Atomic Red Team
• NCSC – Could Your Choice of Metrics Be Harming Your SOC?