Red Team Maliyeti Hangi Değişkenlere Bağlıdır?

Bir kurum Red Team hizmeti için üç firmadan teklif alıyor.

İlk teklifte yalnızca toplam fiyat var.

İkinci teklif “iki uzman, üç hafta” diyor.

Üçüncü teklif ise daha pahalı görünüyor; fakat Threat Intelligence, iki end-to-end senaryo, dedicated attack infrastructure, operasyon süresi, technical evidence pack, detection and response timeline, raporlama ve Purple Team replay için ayrı efor gösteriyor.

Satın alma ekibinin önündeki soru doğal olarak şu oluyor:

Çoğu zaman cevap basittir: Tekliflerin üzerinde aynı hizmet adı yazsa da gerçekte aynı çalışma fiyatlandırılmıyordur.

Bir firma Red Team adı altında genişletilmiş bir sızma testi sunabilir. Bir diğeri assumed breach başlangıcıyla yalnızca Active Directory ve EDR kontrollerine odaklanabilir. Başka bir firma ise external attack surface'ten başlayıp social engineering, identity, endpoint, internal network, cloud ve kritik business function boyunca ilerleyen, Threat Intelligence ile şekillendirilmiş bir operasyon planlayabilir. Bu üç çalışmanın objective'i, süresi, ekip yapısı, operasyonel riski ve deliverable'ı aynı değildir.

Bu yazıda “Red Team kaç para?” sorusuna internette kısa süre yaşayacak rastgele bir fiyat aralığı vermeyeceğiz. Bunun yerine bir teklifin neden belirli bir maliyet ürettiğini, iki teklifin gerçekten karşılaştırılabilir olup olmadığını ve bütçeyi düşürürken testin geçerliliğini nasıl koruyabileceğinizi teknik olarak açıklayacağız.

Red Team'in neyi ölçtüğünü ve neden ileri seviye pentest olarak görülmemesi gerektiğini önce netleştirmek isterseniz Red Team kapsamlı rehberimiz bu yazı için doğru başlangıç noktasıdır.

Red Team maliyeti, fiyatı ve bütçesi aynı şey değildir

Bu üç kavram teklif görüşmelerinde sık sık birbirinin yerine kullanılır:

• Maliyet: Hizmeti üretmek için gereken uzman eforu, infrastructure, lisans, seyahat, proje yönetimi, QA ve diğer doğrudan kaynakların toplamıdır.
• Fiyat: Hizmet sağlayıcının bu maliyetin üzerine ticari koşullarını, kapasite planını, kur riskini, ödeme vadesini ve kurumsal sorumluluğunu ekleyerek müşteriye sunduğu bedeldir.
• Bütçe: Kurumun çalışma için ayırdığı finansal sınırdır.

Bir kurumun bütçesi düşük olabilir; bu durum operasyonun gerçek maliyetini otomatik olarak düşürmez. Yapılması gereken, aynı işi daha az eforla yapılıyormuş gibi göstermek değil, objective veya scope'u kontrollü biçimde yeniden tasarlamaktır.

Benzer şekilde yüksek fiyat da tek başına yüksek kalite kanıtı değildir. Teklifte hangi phase'in kaç person-day gerektirdiği, kim tarafından yürütüleceği ve hangi deliverable'ın üretileceği görünmüyorsa rakamın arkasındaki çalışma modeli değerlendirilemez.

Fiyat neden yalnızca person-day ile açıklanamaz?

Red Team operasyonunda person-day önemli bir ölçüdür fakat tek ölçü değildir.

Bir operator'ın on iş günü çalışması ile iki operator'ın beşer gün çalışması aritmetik olarak aynı eforu üretir. Operasyonel olarak her zaman aynı sonucu üretmez. Recon, initial access ve attack path geliştirme kısmen paralel yürütülebilir. Buna karşılık bir credential setinin nasıl elde edildiğini bilen operator'ın identity zincirindeki bağlamı koruması gerekebilir. İki farklı kişinin aynı anda aynı account veya business flow üzerinde çalışması state'i bozabilir. Stealth gerektiren operasyonlarda eş zamanlı aktivite defensive baseline'ı gereksiz biçimde değiştirebilir.

Bu nedenle teklif şu dört değeri ayırmalıdır:

1. 1Toplam person-day eforu
2. 2Aktif operasyonun takvim süresi
3. 3Eş zamanlı görev alacak operator sayısı
4. 4Test dışındaki Threat Intelligence, hazırlık, raporlama ve replay eforu

30 person-day ile 30 takvim günü aynı şey değildir.

Red Team maliyeti hangi çalışma kalemlerinden oluşur?

Red Team fiyatının tamamını “test günü × günlük ücret” şeklinde hesaplamak, testten önce ve sonra yapılan işi görünmez kılar. Profesyonel bir engagement en az altı cost center içerir.

Bazı teklifler Threat Intelligence'ı ayrı hizmet olarak yazar. Bazıları proje yönetimi ve attack infrastructure'ı toplam fiyata dahil eder. Bazıları Purple Team replay'i opsiyonel bırakır. Toplam rakam karşılaştırılmadan önce bu kalemlerin aynı kapsamda olup olmadığı görülmelidir.

Değişken 1: Business objective ve starting condition

Maliyeti en fazla değiştiren unsur çoğu zaman IP sayısı değil, operasyonun nereden başlayacağı ve nerede biteceğidir.

Şu iki objective aynı değildir:

İlk objective, external recon ve initial access için belirsiz bir problem alanı açar. İkinci objective, assumed breach leg-up ile başlangıçtaki belirsizliği azaltır ve iç savunma katmanlarına daha fazla zaman ayırır.

Full-scope Red Team maliyeti

Full-scope yaklaşımda ekip çoğunlukla gerçek bir dış saldırgan gibi sıfır veya sınırlı bilgiyle başlar. Scope izin veriyorsa attack surface discovery, credential exposure araştırması, social engineering, external service exploitation veya web application attack path'leri değerlendirilebilir.

Maliyet artar çünkü:

• Initial access kesin değildir.
• Birden fazla hipotezin paralel araştırılması gerekebilir.
• Internet infrastructure daha uzun süre ayakta tutulur.
• Recon bulgularının ownership ve scope doğrulaması zaman alır.
• External foothold bulunamaması halinde leg-up kararı için önceden tasarlanmış escalation modeli gerekir.
• Ekip, objective'e ulaşmadan önce daha fazla dead end ile karşılaşabilir.

Belirsizlik Red Team'in doğasında vardır; fakat fiyatlandırılmayan belirsizlik daha sonra coverage kaybı olarak geri döner.

Assumed breach maliyeti

Assumed breach çalışmasında kurum, Red Team'e tanımlı bir başlangıç erişimi verir. Bu bir standard user account, workstation, VPN erişimi, cloud identity veya belirli segmentte foothold olabilir.

Bu yaklaşım genellikle external initial access phase'ini daraltır. Ancak “daha ucuz Red Team” anlamına gelmek zorunda değildir. Tasarruf edilen efor şu alanlara aktarılabilir:

• Active Directory attack path analizi
• Credential exposure ve session riskleri
• EDR visibility ve prevention
• Lateral movement
• Hybrid identity ve cloud pivot
• Privileged access boundary
• Critical application objective
• Detection, investigation ve containment ölçümü

Özellikle identity zincirine odaklanan çalışmalarda assumed breach daha az gerçekçi değil, farklı bir hipotezi ölçen bilinçli bir test tasarımıdır. Active Directory odaklı Red Team'de zincirlenen zafiyetler yazısında bu attack path mantığını ayrıntılı biçimde ele alıyoruz.

Hybrid başlangıç ne zaman kullanılır?

Hybrid modelde ekip external phase ile başlar. Önceden belirlenen zaman kutusu içinde qualifying foothold oluşmazsa kontrollü bir leg-up devreye girer. Böylece bütün bütçe initial access arayışında tüketilmeden internal detection and response objective'leri de ölçülebilir.

Bu modelin maliyeti doğru hesaplanmak isteniyorsa teklif şunları yazmalıdır:

• External phase için ayrılan azami süre
• Leg-up koşulu ve onay yetkisi
• Verilecek erişimin privilege seviyesi
• Leg-up sonrasında ölçülecek objective'ler
• External phase başarısızlığının nasıl raporlanacağı

Leg-up, sonucu güzelleştirmek için saklanan bir kolaylık değil; coverage'ı koruyan açık bir scenario control'dür.

Starting condition maliyet etkisi tablosu

“Göreli maliyet” kalite sıralaması değildir. Doğru başlangıç modeli, kurumun hangi güvenlik iddiasını test etmek istediğine göre seçilir.

Değişken 2: Scope büyüklüğü değil, trust boundary sayısı

Red Team scope'u yalnızca IP, domain veya çalışan sayısıyla ölçülemez. Bir adet domain'in arkasında birden fazla identity provider, cloud tenant, application, API, partner integration ve critical business service bulunabilir. Yüz IP ise aynı network segmentinde, aynı control setiyle yönetilen homojen bir ortam oluşturabilir.

Eforu asıl artıran, aşılması ve ölçülmesi gereken trust boundary'lerdir.

Örnek boundary'ler:

• Internet ile corporate identity arasındaki sınır
• User workstation ile privileged administration katmanı
• On-premises Active Directory ile Entra ID veya başka bir cloud identity sistemi
• Corporate network ile production segment
• Standard user ile finance approver role'ü
• Application tenant'ları arasındaki authorization sınırı
• Organization ile managed service provider
• Primary environment ile backup management plane
• IT ile OT ağı
• Employee mailbox ile privileged workflow

Her boundary farklı telemetry, owner, response playbook ve safety riski getirir. Dolayısıyla tek bir attack chain içinde beş boundary geçmek, beş ayrı fakat yüzeysel hedefe dokunmaktan daha maliyetli olabilir.

Scope manifest hangi bilgileri içermeli?

Maliyet hesabından önce en az şu alanlar hazırlanmalıdır:

Scope manifest yoksa hizmet sağlayıcı iki yoldan birini seçmek zorunda kalır: Belirsizliği fiyatın içine risk payı olarak koymak veya dar bir scope varsayarak düşük teklif vermek. İkinci durumda düşük fiyat cazip görünür; çalışma başladığında kapsam dışı tartışmaları ve change request'ler ortaya çıkar.

Değişken 3: Senaryo sayısı ve attack path derinliği

İki Red Team senaryosu her zaman iki kat maliyet üretmez. Aynı recon, infrastructure ve planning çıktıları paylaşılabilir. Buna karşılık farklı business function, farklı initial access channel ve farklı technology stack kullanan iki senaryo neredeyse iki ayrı operasyon gibi çalışabilir.

Şu üç senaryoyu düşünün:

1. 1Phishing üzerinden corporate identity compromise ve finance application'a ilerleme
2. 2Internet-facing web application üzerinden production data boundary'sine ilerleme
3. 3Third-party remote access üzerinden backup management plane'e ulaşma

Bu senaryoların ortak target organization'ı aynı olsa da attack surface, operator skill set'i, infrastructure, safety ve evidence ihtiyacı farklıdır.

Senaryo derinliği nasıl ölçülür?

Senaryo sayısına ek olarak şu sorular sorulmalıdır:

• Yalnızca initial access mi test edilecek?
• Persistence izinli mi?
• Privilege escalation objective'in parçası mı?
• Lateral movement kaç segment veya identity boundary boyunca sürdürülebilir?
• Cloud ve on-premises arasında pivot bekleniyor mu?
• Critical application'da yalnızca erişim mi, business action capability'si mi kanıtlanacak?
• Data access synthetic flag ile mi, gerçek kayda dokunarak mı doğrulanacak?
• Exfiltration simulation yapılacak mı?
• Blue Team containment sonrasında re-entry test edilecek mi?
• Aynı objective için alternatif attack path aranacak mı?

“Domain Admin olunca test biter” yaklaşımı, business objective farklı bir sistemdeyse attack chain'i erken kesebilir. Tersi durumda her bulunan yolu sonuna kadar yürütmek de gereksiz risk ve maliyet üretir. Senaryonun terminal condition'ı tekliften önce tanımlanmalıdır.

İyi bir scenario document'in nasıl yazıldığını Red Team senaryosu hazırlama rehberimizde objective, flag, Rules of Engagement ve başarı ölçütleriyle birlikte gösteriyoruz.

Değişken 4: Initial access kanalları

“Red Team her şeyi deneyebilir” cümlesi fiyatlandırılabilir bir scope değildir. Hangi initial access kanallarının izinli olduğu açıkça yazılmalıdır.

Phishing tek başına Red Team değildir. Ayrı bir awareness veya email control ölçümü için daha dar ve düşük maliyetli bir çalışma yeterli olabilir. Oltalama simülasyonu ile Red Team arasındaki fark yazısı, bu iki hizmetin scope ve başarı kriterlerini neden ayrı tutmak gerektiğini açıklıyor.

Bir kanalı scope'a eklemek yalnızca operator'ın o tekniği deneyeceği birkaç saat anlamına gelmez. Infrastructure hazırlanır, test data üretilir, allow/deny sınırları yazılır, legal ve privacy kontrolleri değerlendirilir, telemetry expectation belirlenir ve sonuç ayrıca raporlanır.

Değişken 5: Threat Intelligence ve threat fidelity seviyesi

Generic Red Team ile threat-led engagement aynı maliyet yapısına sahip değildir.

Threat-led çalışmada ekip, internette popüler technique'leri rastgele sıralamaz. Kurumun sektörü, coğrafyası, kritik function'ları, technology exposure'ı ve gerçekçi adversary profili üzerinden threat scenario geliştirir. TIBER-EU bu yaklaşımı entity'nin critical function'larına uyarlanmış bespoke Threat Intelligence ve gerçek saldırgan TTP'lerini taklit eden kontrollü test olarak ele alır.

CBEST modelinde de Threat Intelligence Service Provider ile Penetration Testing Service Provider rolleri ve deliverable'ları ayrıştırılır. Her kurumsal Red Team'in bu kadar formal bir modele ihtiyacı yoktur. Ancak “threat-led” ifadesi kullanılıyorsa en azından şu üretim süreci görünür olmalıdır:

1. 1Intelligence requirement'ların belirlenmesi
2. 2Sector ve organization-specific collection
3. 3Threat actor ve capability değerlendirmesi
4. 4Targeting assessment
5. 5Threat scenario üretimi
6. 6TTP ve procedure seviyesinde emulation plan
7. 7Confidence ve intelligence gap kaydı
8. 8Operasyon sırasında yeni intelligence ile scenario update

MITRE ATT&CK technique seçimi bu sürecin yalnızca bir parçasıdır. MITRE'nin adversary emulation planları da açık kaynak threat report'lardan davranış zinciri üretmeye çalışır; ancak kaynak raporların sınırlılıklarını taşır. Bir ATT&CK heatmap oluşturmak tek başına bespoke Threat Intelligence değildir.

Threat fidelity hangi seviyelerde fiyatlandırılabilir?

Threat Intelligence bütçesini tamamen çıkarmak mümkündür; fakat bu durumda hizmet “threat-led adversary emulation” olarak değil, objective-based Red Team veya control assessment olarak doğru adlandırılmalıdır.

Değişken 6: Stealth, evasion ve realism beklentisi

“SOC bizi fark etmesin” cümlesi bir stealth requirement değildir. Hangi defensive capability'nin, hangi süre ve confidence eşiğinde ölçüleceği tanımlanmadığında ekip iki uçtan birine savrulur:

• Gereksiz derecede sessiz hareket ederek çok az coverage üretir.
• Objective'e hızla ulaşmak için gürültülü davranır ve gerçekçi detection ölçümünü bozar.

Stealth seviyesi maliyeti doğrudan etkiler. Düşük ve yavaş activity, her adımdan sonra defensive response'u gözlemleme, infrastructure rotation, domain aging, protocol/profile uyarlaması, payload engineering ve fallback channel hazırlığı daha fazla takvim süresi ister.

Stealth maliyetini artıran teknik ihtiyaçlar

• Ayrı redirector ve egress profile'ları
• Domain registration, reputation ve warm-up süreci
• Traffic profile'ın kurumun normal davranışına uyarlanması
• Custom veya değiştirilmiş tooling
• Endpoint control'lerine göre payload delivery tasarımı
• Her phase için fallback infrastructure
• Operational security ve attribution control
• Düşük request rate nedeniyle uzayan recon
• Telemetry üretimini kontrollü tutan execution planı
• Detection oluştuğunda burn edilmiş infrastructure'ın değiştirilmesi

Burada kritik ayrım şudur: Custom tooling her zaman kalite göstergesi değildir. Hazır bir aracın behavior'ı senaryodaki threat profile'a uyuyor ve beklenen kontrolü ölçüyorsa yeniden araç yazmak gereksiz maliyet olabilir. Buna karşılık bilinen tool signature'larını çalıştırıp “EDR gördü” sonucuna ulaşmak da olgun bir EDR capability değerlendirmesi değildir.

Control group'un haberdar olma modeli maliyeti etkiler mi?

Evet. Çalışmadan haberdar kişi sayısı azaldıkça gerçekçi detection and response ölçümü güçlenebilir; fakat deconfliction ve safety sorumluluğu küçük bir ekip üzerinde yoğunlaşır.

Control group şu görevleri yürütür:

• Gerçek incident ile Red Team activity'sini ayırmak
• Stop veya pause condition kararını vermek
• Scope değişikliğini onaylamak
• Critical system owner ile gerektiğinde kapalı koordinasyon kurmak
• Gerçek data exposure durumunda güvenli aksiyonu belirlemek
• Operasyonun secrecy'sini korumak

Bu rollerin gece veya hafta sonu erişilebilir olması gerekiyorsa hem kurum tarafında hem hizmet sağlayıcı tarafında ek operasyon maliyeti doğar.

Değişken 7: Attack infrastructure ve operasyon süresi

Red Team infrastructure'ı tek bir VPS ve domain'den ibaret değildir. Scope ve realism seviyesine göre farklı bileşenler gerekebilir:

Operator access
      ↓
Management / logging plane
      ↓
C2 veya test orchestration layer
      ↓
Redirector / relay katmanı
      ↓
Delivery ve callback domain'leri
      ↓
Yetkilendirilmiş target

Email channel varsa mail infrastructure ve landing environment; web delivery varsa content hosting; exfiltration simulation varsa kontrollü sink ve measurement katmanı gerekebilir. Bütün bu bileşenlerin oluşturulması, hardening'i, logging'i, segregated storage'ı ve engagement sonunda teardown'u efor üretir.

Takvim süresi neden infrastructure maliyetini artırır?

Bir ay açık kalan environment ile üç ay açık kalan environment aynı değildir. Uzun operasyonda:

• Hosting ve domain maliyetleri devam eder.
• Certificate, DNS ve redirector sağlığı izlenir.
• Infrastructure'ın blacklist veya reputation durumu takip edilir.
• Log retention süresi uzar.
• Access key ve operator credential yönetimi gerekir.
• Patch ve availability sorumluluğu devam eder.
• Engagement'a ayrılmış resource başka projede kullanılamaz.

Infrastructure doğrudan gideri çoğu kurumsal projede toplam bütçenin en büyük kalemi olmayabilir. Fakat onu kuran, izleyen ve güvenli biçimde kapatan uzman eforu göz ardı edilmemelidir.

Üçüncü taraf platform ve lisanslar

Commercial Threat Intelligence, phishing delivery, disposable infrastructure, secure evidence exchange veya specialized testing tool lisansları teklife dahil edilebilir. Satın alma ekibi şu ayrımı istemelidir:

• Lisans proje için zorunlu mu?
• Kurumun mevcut lisansı kullanılabilir mi?
• Maliyet tek seferlik mi, kullanıcı veya ay bazlı mı?
• Ham data veya report provider'da kalıyor mu?
• Test sonunda tenant ve data nasıl kapatılıyor?

Araç adı yerine ihtiyacın ve data flow'un açıklanması daha değerlidir.

Değişken 8: Ekip yapısı, kıdem ve görev ayrımı

Red Team maliyetinde day rate farkının önemli bir bölümü, işi yapan kişilerin kıdeminden ve ekip içinde hangi rollerin gerçekten bulunduğundan gelir.

Tek bir senior operator küçük bir assumed breach çalışmasını başarıyla yürütebilir. Ancak geniş ve threat-led bir operasyonda aynı kişinin Threat Intelligence, scenario design, infrastructure, phishing, web exploitation, Active Directory, cloud, project management, safety, raporlama ve QA görevlerinin tamamını eşit derinlikte yürütmesini beklemek gerçekçi değildir.

Tipik rol dağılımı

İki operator içeren teklif, tek operator içeren teklifin otomatik olarak iki katı değildir. Aynı şekilde iki kişi yazılması gerçekten iki senior operator'ın aktif görev aldığı anlamına gelmez. Teklifte role, seniority ve person-day dağılımı görünür olmalıdır.

Sertifikalar fiyatı belirlemeli mi?

OSCP, OSWE, OSEP, CRTO, CRTO II, CCSAS veya benzeri bireysel sertifikalar belirli bilgi ve uygulama alanlarına ilişkin sinyal sağlayabilir. Ancak sertifika sayısı doğrudan fiyat formülü değildir.

Red Team için ayrıca şu deneyimler aranmalıdır:

• Uzun süreli operasyon yönetimi
• Active Directory ve hybrid identity
• Web application ve API attack path'leri
• Endpoint ve EDR behavior'ı
• Cloud control plane
• Social engineering safety
• Threat Intelligence'ı procedure seviyesine dönüştürme
• Production üzerinde kontrollü çalışma
• Reproducible evidence ve executive narrative
• Detection and response ölçümü

SECNODEX yaklaşımında ekipte görev alan uzmanların OSCP ve OSWE gibi bireysel yetkinlikleri teknik temeli destekler; fakat Red Team teklifi yalnızca sertifika logolarıyla gerekçelendirilmez. Objective, operator planı, manuel çalışma disiplini, evidence standardı ve savunma ölçümü birlikte açıklanır.

Ucuz teklif hangi durumda pahalıya gelir?

Düşük day rate avantajlı olabilir. Fakat aşağıdaki durumlarda toplam sahip olma maliyeti artar:

• Attack path kurulmadan tekil bulgular raporlanır.
• SOC ölçülmeden yalnızca erişim kanıtı sunulur.
• Evidence eksik olduğu için ekipler bulguyu yeniden üretmek zorunda kalır.
• False positive veya varsayım düzeyindeki riskler remediation backlog'u şişirir.
• Production safety zayıf olduğu için iş kesintisi riski doğar.
• Rapor teknik ekip, yönetim ve denetim için tekrar yazılır.
• Cleanup doğrulanmadığı için kalıcı artifact riski oluşur.
• Replay yapılmadığı için yapılan düzeltmenin detection gap'i kapatıp kapatmadığı bilinmez.

Red Team'de kalite farkı, “sisteme girebildik” anından çok bütün operasyonun kontrollü ve ölçülebilir yürütülmesinde görülür.

Değişken 9: Rules of Engagement ve production safety

Rules of Engagement yalnızca hukuki koruma belgesi değildir. Testin nasıl yapılabileceğini ve dolayısıyla ne kadar efor gerektireceğini belirleyen teknik bir girdidir.

NIST, Rules of Engagement'ı security testing'in yürütülmesine ilişkin ayrıntılı kural ve kısıtlar olarak tanımlar; test ekibine tanımlı action'ları tekrar izin almadan yürütme yetkisi sağlar. Belirsiz RoE ise her kritik adımda yeni onay ihtiyacı, bekleme ve takvim kayması üretir.

Maliyeti artırabilen operasyonel kısıtlar

• Yalnızca mesai dışı test yapılabilmesi
• Production request rate'in çok düşük tutulması
• Belirli account veya subnet'lere yalnızca onayla dokunulabilmesi
• Destructive action yerine özel synthetic flag tasarlanması
• Payload veya binary için ön onay zorunluluğu
• Her privilege escalation adımında control group bildirimi
• Third-party sistemler için ayrı authorization süreci
• Veri örneğinin cihazda tutulamaması
• Evidence'ın yalnızca kurum içi ortamda işlenmesi
• Operator'ın müşterinin jump host'u üzerinden çalışması
• Recording veya ekran görüntüsü sınırlamaları
• Gece ve hafta sonu emergency contact zorunluluğu

Bu kısıtların bazıları gereklidir. Özellikle finans, üretim, sağlık ve kritik altyapıda safety, maliyeti azaltmak uğruna gevşetilecek bir alan değildir. Ancak kısıtlar senaryoyu ölçülemez hâle getiriyorsa çalışma yeniden tasarlanmalıdır.

Stop condition, pause condition ve notification threshold

Üç kavramın ayrı yazılması bekleme maliyetini azaltır:

• Notification threshold: Operasyon devam ederken belirli bir olayın control group'a bildirilmesini gerektirir.
• Pause condition: Belirli scope veya phase geçici olarak durur; açıklama ve onay sonrası devam edebilir.
• Stop condition: Operasyonun tamamı veya ilgili senaryo sonlandırılır.

Gerçek incident, beklenmeyen production degradation, gerçek customer data exposure veya scope dışı third-party etkisi için hangi koşulun geçerli olduğu önceden belirlenmelidir.

Değişken 10: Regulated framework ve bağımsız koordinasyon

Her Red Team çalışması TIBER-EU, DORA TLPT veya CBEST değildir. Bu çerçeveler formal governance, provider kriterleri, Threat Intelligence, test phase'leri, deliverable, authority interaction ve remediation beklentileri nedeniyle standart bir kurumsal Red Team'den farklı maliyet üretir.

2025'te yayımlanan EU 2025/1190 Delegated Regulation; DORA kapsamındaki TLPT için entity selection, internal tester koşulları, scope, methodology, test phase'leri, sonuç, closure, remediation ve supervisory cooperation alanlarını ayrıntılandırır. TIBER-EU çerçevesi de 2025 yılında bu RTS ile tam hizalı olacak şekilde güncellenmiştir.

Bu tür engagement'larda ek efor şu alanlarda oluşabilir:

• Test manager veya authority ile planning
• Critical function scope'unun formal onayı
• Ayrı Threat Intelligence ve Red Team provider rolleri
• Provider accreditation ve personel yeterliliği
• Project Initiation Document ve risk management plan
• Scenario approval
• Purple Team veya replay zorunluluğu
• Regulator formatında deliverable
• Cross-border veya mutual recognition koordinasyonu
• Formal remediation plan ve closure evidence

Bir kurum regulated TLPT'ye tabi değilse bu sürecin tamamını kopyalamak zorunda değildir. Yine de critical function, threat-led scenario, control group, safety, evidence ve remediation discipline'i iyi bir kurumsal Red Team'e uyarlanabilir.

Finans ve fintek ortamlarında test sınırlarının nasıl kurulması gerektiğini finans kuruluşları için Red Team kapsamı yazısında ayrıca inceliyoruz.

Değişken 11: Raporlama, evidence ve executive output

Raporlama, aktif test bittikten sonra bir scanner çıktısına logo eklemek değildir. İyi bir Red Team raporu, farklı audience'lar için aynı gerçeği üç seviyede anlatır:

1. 1Yönetim için business objective, impact ve savunma sonucu
2. 2SOC ve security engineering için attack timeline, TTP, telemetry ve response gap
3. 3System owner için root cause, evidence ve uygulanabilir remediation

Minimum deliverable seti

Raporun Türkçe ve İngilizce hazırlanması, regulator template'ine uyarlanması veya her finding için ayrı remediation workshop yapılması ek efor üretir. Bunlar “aynı PDF'in farklı export'u” değildir.

Her Red Team bulgusu CVSS almalı mı?

Hayır. Tekil bir vulnerability CVSS ile değerlendirilebilir. Ancak missed detection, zayıf containment, eksik telemetry, procedure gap veya çok adımlı attack path tek bir CVSS skoruna iyi oturmaz.

Raporlama modeli şu ayrımı korumalıdır:

• Technical vulnerability severity
• Attack path içindeki rol
• Objective'e katkı
• Defensive control gap
• Business impact
• Remediation priority

Bu ayrım rapor QA eforunu artırır; fakat yönetimin yanlış öncelik vermesini engeller.

Değişken 12: Purple Team replay, retest ve remediation validation

Red Team raporunun teslimi, savunma gelişiminin tamamlandığı anlamına gelmez. Bir alert rule yazılmış olabilir fakat doğru telemetry gelmiyordur. EDR policy güncellenmiş olabilir fakat aynı behavior farklı child process üzerinden hâlâ mümkündür. Bir privileged group temizlenmiş olabilir fakat eşdeğer attack path başka delegation üzerinden devam ediyordur.

Bu nedenle teklif şu kapanış modellerinden hangisini içerdiğini belirtmelidir:

Purple Team ve BAS'in Red Team ile aynı sonucu üretmediğini Purple Team, Red Team ve BAS karşılaştırmamızda ayrıntılı olarak açıklıyoruz.

Replay opsiyonel olabilir; fakat tekliften çıkarıldığında kimin, hangi ortamda ve hangi evidence ile düzeltmeyi doğrulayacağı yazılmalıdır.

Red Team maliyeti için şeffaf hesaplama modeli

Sektörde herkesin kullandığı tek bir fiyat formülü yoktur. Yine de teklifin arkasındaki efor aşağıdaki modelle şeffaflaştırılabilir:

Toplam efor =
    Scoping ve planning
  + Threat Intelligence ve scenario design
  + Attack infrastructure hazırlığı ve teardown
  + Technical execution
  + Project management ve deconfliction
  + Reporting ve independent QA
  + Replay / retest / remediation validation

Ticari fiyat ise bunun üzerine doğrudan giderleri ve hizmet sağlayıcının ticari koşullarını ekler:

Teklif bedeli =
    Σ (rol bazlı person-day × rol bazlı day rate)
  + infrastructure ve lisans giderleri
  + seyahat / saha giderleri
  + vergi ve sözleşmesel ticari koşullar

Bu formül rakamı otomatik olarak “doğru” yapmaz. Önce her efor kaleminin hangi coverage sözünü karşıladığı görülmelidir.

Örnek efor modeli

Aşağıdaki tablo fiyat teklifi değildir. Aynı kurumda üç farklı objective'in neden farklı person-day üretebileceğini göstermek için hazırlanmış örnektir.

Bu örnekte technical execution şu şekilde düşünülebilir:

• Targeted assumed breach: 2 operator × 8 gün
• Hybrid Red Team: 2 operator × 18 gün
• Threat-led full-scope: 3 operator × 20 gün

Toplam takvim süresi person-day toplamından farklıdır. Threat Intelligence phase'i teknik operasyondan önce başlayabilir; raporlama aktif testten sonra devam eder; replay ise remediation takvimine bağlı olarak haftalar sonra yapılabilir.

Basit bir person-day hesaplayıcı

Aşağıdaki Python örneği fiyat üretmez. Scope workshop'unda efor varsayımlarını görünür hâle getirmek için kullanılabilir:

from dataclasses import dataclass, field
from decimal import Decimal


@dataclass(frozen=True)
class WorkPackage:
    name: str
    people: int
    days: Decimal

    @property
    def person_days(self) -> Decimal:
        if self.people < 1 or self.days < 0:
            raise ValueError(f"Invalid work package: {self.name}")
        return Decimal(self.people) * self.days


@dataclass
class RedTeamEstimate:
    packages: list[WorkPackage] = field(default_factory=list)

    def total_person_days(self) -> Decimal:
        return sum((item.person_days for item in self.packages), Decimal("0"))

    def breakdown(self) -> list[tuple[str, Decimal]]:
        return [(item.name, item.person_days) for item in self.packages]


estimate = RedTeamEstimate(
    packages=[
        WorkPackage("Scoping and Rules of Engagement", 2, Decimal("2.5")),
        WorkPackage("Threat Intelligence and scenario design", 2, Decimal("3")),
        WorkPackage("Attack infrastructure", 1, Decimal("4")),
        WorkPackage("Technical execution", 2, Decimal("18")),
        WorkPackage("Reporting and QA", 2, Decimal("4")),
        WorkPackage("Purple Team replay", 2, Decimal("3")),
    ]
)

for name, effort in estimate.breakdown():
    print(f"{name}: {effort} person-day")

print(f"Total: {estimate.total_person_days()} person-day")

Örnek çıktı:

Scoping and Rules of Engagement: 5.0 person-day
Threat Intelligence and scenario design: 6 person-day
Attack infrastructure: 4 person-day
Technical execution: 36 person-day
Reporting and QA: 8 person-day
Purple Team replay: 6 person-day
Total: 65.0 person-day

Burada özellikle people × days ayrımı korunur. “Threat Intelligence üç gün sürüyor” denildiğinde bu işi iki analist yürütüyorsa efor altı person-day'dir.

Red Team, sızma testi, Purple Team ve BAS maliyetleri neden karşılaştırılamaz?

Aynı bütçe kalemi altında satın alınabilseler de bu çalışmalar farklı sorulara cevap verir.

Sızma testinin Red Team'den hangi noktada ayrıldığını Red Team ile sızma testi arasındaki fark yazısında daha ayrıntılı inceleyebilirsiniz.

Bir provider üç günlük vulnerability assessment'a “Red Team” adı verirse fiyat düşük görünebilir. Bu, gerçek Red Team'in pahalı olduğu sonucunu değil, satın alınan hizmetlerin yanlış adlandırıldığını gösterir.

İki Red Team teklifi nasıl karşılaştırılır?

Toplam fiyatı yan yana yazmak yeterli değildir. Önce iki teklifin coverage sözünü normalize edin.

Karşılaştırma tablosu

İki teklif ancak aynı objective, starting condition, scenario, scope, deliverable ve kapanış modeline sahipse fiyat üzerinden doğrudan karşılaştırılabilir.

Day rate karşılaştırması neden yanıltabilir?

Firma A'nın senior operator day rate'i yüksek, fakat 30 person-day öneriyor olabilir. Firma B'nin day rate'i düşük, fakat 55 person-day yazabilir. Ya da Firma B daha düşük toplam eforla aynı işi vaat ediyor gibi görünürken Threat Intelligence, independent QA ve replay'i kapsam dışında bırakmış olabilir.

Şu değerleri birlikte isteyin:

Role → Seniority → Person-day → Phase → Deliverable

Örnek:

Lead Operator → Senior → 12 person-day → Execution / QA → Attack path + technical QA
Operator → Mid/Senior → 15 person-day → Execution → Evidence + timeline
TI Analyst → Senior → 5 person-day → Threat Intelligence → Scenario input
Project Lead → Senior → 4 person-day → Planning / closure → RoE + management readout

Bu görünürlük provider'ın çalışan isimlerini teklif aşamasında açıklamasını gerektirmez. Ancak projenin junior ağırlıklı mı, senior ağırlıklı mı tasarlandığını gösterir.

Red Team bütçesi kaliteyi bozmadan nasıl düşürülür?

Maliyeti azaltmanın en iyi yolu operator gününü körlemesine kesmek değildir. Belirsizliği ve boşa giden eforu azaltmaktır.

1. Önce doğru objective'i seçin

“Her yere bakın” yerine tek bir critical business function ve ölçülebilir impact seçmek scope'u daraltırken testin değerini artırabilir.

2. Starting condition'ı risk sorusuna göre belirleyin

Kurumun asıl sorusu “internal identity compromise sonrasında EDR ve SOC ne yapıyor?” ise bütçeyi haftalarca external foothold aramaya harcamak yerine assumed breach daha doğru olabilir.

3. Scope manifest'i testten önce tamamlayın

Ownership, third-party, tenant, domain, CIDR, cloud subscription ve criticality bilgileri hazırsa operator test sırasında idari doğrulama beklemez.

4. Synthetic flag ve test data hazırlayın

Gerçek customer data'ya dokunmadan objective'i kanıtlayan flag; hem safety'yi hem onay süresini iyileştirir.

5. Control group'u küçük fakat erişilebilir tutun

Geniş dağıtım listesi secrecy'yi bozar. Tek kişilik control group ise 7/24 karar darboğazı oluşturur. Bir primary ve bir backup contact çoğu operasyonda daha dengelidir.

6. Readiness gate uygulayın

Testten önce VPN, account, MFA, test workstation, allowlist gereksinimi, communication channel ve evidence exchange doğrulanmalıdır. Operator'ın ilk gününü erişim sorunu çözerek geçirmesi bütçe kaybıdır.

7. Senaryolar arasında ortak altyapıyı planlayın

Aynı engagement içinde ortak recon, infrastructure ve reporting framework kullanılabilecek senaryolar birlikte tasarlanabilir.

8. Rapor formatını önceden onaylayın

Executive, technical, regulator veya iki dil beklentisi test sonunda ortaya çıkarsa yeniden yazım maliyeti oluşur.

9. Purple Team replay'i seçili gap'lere odaklayın

Her action'ı tekrar etmek yerine objective'e etkisi yüksek ve detection gap oluşturan procedure'ler önceliklendirilmelidir.

10. Change freeze veya change visibility sağlayın

Test sırasında büyük deployment ve security policy değişiklikleri gözlemi belirsizleştirir. Tam freeze mümkün değilse change log Red Team lead ile kontrollü paylaşılmalıdır.

11. Mevcut Threat Intelligence'ı kullanılabilir hâle getirin

Kurumun onaylı actor profile'ı, intelligence requirement'ı ve sector assessment'ı varsa provider'ın araştırma eforu hedefe yöneltilebilir. Ham feed veya yüzlerce IOC, scenario input yerine geçmez.

12. Önce temel kontrolleri düzeltin

External attack surface envanteri yoksa, critical vulnerability backlog'u kontrolsüzse ve SOC temel telemetry'ye sahip değilse Red Team erken olabilir. Bu durumda bütçeyi önce sızma testi, zafiyet yönetimi ve detection foundation'a ayırmak daha fazla değer üretir. Her kurumun Red Team'e ihtiyacı var mı? yazısı bu readiness kararını ayrıntılı biçimde ele alıyor.

Maliyeti düşürürken yapılmaması gerekenler

Threat Intelligence'ı çıkarıp “threat-led” demeye devam etmek

Bu yalnızca etiketi korur, yöntemi korumaz. Çalışma objective-based olacaksa açıkça öyle adlandırılmalıdır.

Raporlama ve QA gününü aktif test gününe çevirmek

Daha fazla execution saati elde edilir; fakat evidence, root cause ve remediation kalitesi düşer. Kurum sonradan aynı bilgiyi çıkarmak için daha fazla iç efor harcar.

Tek operator'a sınırsız scope vermek

Scope kağıt üzerinde genişler, gerçek coverage incelir. “Bakıldı” ile “yeterli derinlikte test edildi” birbirine karışır.

Safety ve control group eforunu kaldırmak

Bu tasarruf değil, production ve hukuki riskin kuruma transferidir.

Bütün objective'leri aynı anda test etmek

Identity, ransomware, payment fraud, cloud compromise, insider ve physical access senaryolarını tek operasyona sıkıştırmak odak kaybı üretir. Yıllık scenario roadmap daha doğru olabilir.

Replay'i tamamen kaldırmak

Bütçe yetmiyorsa tüm technique'ler yerine en kritik üç veya beş defensive gap replay edilebilir. Hiç doğrulama yapılmaması, remediation'ın etkisini varsayıma bırakır.

Red Team teklifindeki alarm işaretleri

Aşağıdaki ifadeler tek başına kesin kalite problemi kanıtlamaz; fakat açıklama gerektirir:

• Scope sorulmadan sabit fiyat verilmesi
• “Sınırsız hedef” denmesi
• Business objective yerine yalnızca “Domain Admin” hedefi yazılması
• Threat Intelligence olmadan APT emulation iddiası
• Operator sayısı ve person-day bilgisinin bulunmaması
• Üç-beş günlük takvimde full-scope, stealth ve end-to-end Red Team vaat edilmesi
• Infrastructure ve data handling modelinin açıklanmaması
• RoE'nin yalnızca “sistemlere zarar verilmeyecektir” cümlesinden oluşması
• Social engineering yapılacağı hâlde target selection ve privacy sınırının yazılmaması
• Rapor örneğinde yalnızca vulnerability listesi bulunması
• SOC, EDR veya SIEM için measurement plan olmaması
• Retest ile Purple Team replay'in aynı şey gibi sunulması
• Cleanup ve artifact inventory'nin deliverable olmaması
• Sertifikaların bireysel uzmanlara mı, şirkete mi ait olduğunun belirsiz bırakılması

Satın alma ekibi teknik teklifte ne araması gerektiğini ayrıca sızma testi teklifindeki teknik maddeler rehberindeki sözleşme ve scope kontrolleriyle birlikte değerlendirebilir. Red Team'de bunlara scenario, secrecy, control group ve detection measurement katmanları eklenir.

Red Team fiyat teklifi istemeden önce hazırlanacak bilgi seti

Sağlayıcıya yalnızca “500 çalışanımız, 200 sunucumuz var” bilgisi gönderilirse teklif varsayımlarla dolar. Daha doğru bir bütçe için aşağıdaki kısa brief yeterlidir:

engagement:
  objective: "Kritik ödeme onay sürecine yetkisiz ilerleme riskini ölçmek"
  critical_function: "Kurumsal ödeme işlemleri"
  starting_condition: "hybrid"
  external_phase_timebox: "10 business days"
  leg_up: "standard domain user and managed workstation"

scenarios:
  count: 2
  channels:
    - external_attack_surface
    - phishing
  terminal_conditions:
    - "synthetic finance approver flag accessed"
    - "approved containment completed"

scope:
  identity: "1 on-prem AD forest + 1 cloud tenant"
  applications: 2
  network_segments: 3
  third_party_dependencies: 1
  production_testing: true

operations:
  stealth: "behavior-aware, low-and-slow"
  control_group: "primary + backup"
  test_window: "24x7, disruptive actions by approval"
  data_policy: "synthetic data only"

deliverables:
  executive_report: true
  technical_report: true
  defensive_timeline: true
  attack_path_diagram: true
  purple_team_replay: true
  retest_rounds: 1
  language:
    - tr

Bu dosya bir RoE değildir; provider'ın karşılaştırılabilir bir ilk efor hesabı yapması için scoping input'udur.

Red Team bütçesi yıllık programa nasıl yerleştirilir?

Tek seferde çok geniş bir Red Team satın almak yerine yıllık program aşağıdaki gibi kademelendirilebilir:

1. 1Readiness assessment: Asset, identity, logging, incident response ve control group hazırlığı
2. 2Targeted assumed breach: Internal identity ve endpoint savunması
3. 3Purple Team replay: Kritik TTP'lerde telemetry ve detection tuning
4. 4Full-scope Red Team: External başlangıçtan critical function objective'ine ilerleme
5. 5Remediation validation: Attack path ve containment sonucunun yeniden doğrulanması

Bu sıralama her kurum için zorunlu değildir. Kurum olgunluğu ve threat model'e göre değişir. Ancak bütçenin yalnızca “yılda bir kez saldırı simülasyonu” kalemine dönüşmesini engeller.

SECNODEX Red Team kapsamını nasıl fiyatlandırır?

SECNODEX'te Red Team eforu, yalnızca IP veya kullanıcı sayısına göre hesaplanmaz. Scoping görüşmesinde önce korunacak business function, test edilecek adversary hypothesis, starting condition, trust boundary'ler ve güvenli proof condition belirlenir.

Ardından teklif şu yapıda hazırlanır:

• Planning ve Rules of Engagement
• Threat Intelligence ve scenario design seviyesi
• Operator rolleri ve person-day dağılımı
• Aktif operasyon ve takvim süresi
• Attack infrastructure
• Reporting ve independent QA
• Purple Team replay veya retest kapsamı
• Açık varsayımlar, exclusions ve change control

Bu yaklaşımın amacı teklifi gereksiz ayrıntıyla uzatmak değil, müşterinin hangi coverage için ödeme yaptığını görünür kılmaktır. SECNODEX Red Team hizmeti, erişim elde etmeyi tek başarı ölçütü saymaz; prevention, visibility, detection, investigation ve containment sonuçlarını attack chain bağlamında değerlendirir.

Sonuç: Red Team fiyatı, coverage sözünün finansal karşılığıdır

Red Team maliyeti “kaç IP var?” veya “kaç gün hacker çalışacak?” sorularıyla doğru hesaplanamaz. Kurum aslında şunlar için bütçe ayırır:

• Gerçekçi bir risk hipotezinin kurulması
• Bu hipotezi sınayacak güvenli ve yetkilendirilmiş operasyon
• Yeterli süre ve doğru yetkinlikte operator ekibi
• Threat Intelligence ve attack infrastructure
• Production safety ve deconfliction
• Attack chain boyunca savunma performansının ölçülmesi
• Yönetim ve teknik ekip için kullanılabilir evidence
• Remediation'ın replay veya retest ile doğrulanması

Ucuz veya pahalı teklif yerine, açıklanabilir teklif aranmalıdır. Hangi phase için kaç person-day ayrıldığı, starting condition'ın ne olduğu, kaç senaryonun hangi terminal condition'a kadar yürütüleceği ve rapor sonrasında ne yapılacağı görünürse fiyat anlam kazanır.

Kurumunuz için gerçekçi bir Red Team scope'u ve karşılaştırılabilir efor modeli oluşturmak istiyorsanız Red Team hizmetimizi inceleyebilir veya objective, mevcut savunma olgunluğu ve bütçe sınırını birlikte değerlendirmek için SECNODEX ile iletişime geçebilirsiniz.

Kaynaklar ve ileri okuma

• European Central Bank — What is TIBER-EU?
• European Central Bank — TIBER-EU Framework updated to align with DORA
• EUR-Lex — Commission Delegated Regulation (EU) 2025/1190
• Bank of England — CBEST Threat Intelligence-Led Assessments Implementation Guide
• MITRE ATT&CK — Adversary Emulation Plans
• NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment