Finans ve Fintek Şirketlerinde Red Team Kapsamı Nasıl Sınırlandırılır?

Bir Red Team operator'ının ödeme orchestration platformunda yönetim yetkisine ulaştığını düşünelim. Teknik olarak yeni bir beneficiary tanımlayabiliyor, transaction rule değiştirebiliyor ve belirli ödeme talimatlarını approval akışına gönderebiliyor. Senaryonun objective'i, saldırganın yetkisiz para hareketi oluşturup oluşturamayacağını ölçmek.

Burada iki kötü karar verilebilir.

İlki, “production sistemine dokunmayalım” diyerek ödeme platformunu tamamen kapsam dışında bırakmaktır. Bu durumda operasyon, kurumun en kritik riskini ölçmeden tamamlanır. İkincisi ise objective'i kanıtlamak adına gerçek bir ödeme talimatını geri döndürülemez aşamaya taşımaktır. Bu da güvenlik testi değil, kontrolsüz finansal ve operasyonel risk üretmektir.

Doğru kapsam bu iki uç arasında kurulur. Operator'ın payment control plane'e ulaşması, yetki sınırını aşması ve işlem oluşturabilecek capability'yi elde etmesi gerçek sistemlerde doğrulanabilir. Fakat kanıt; canary account, synthetic beneficiary, test ledger entry, önceden tanımlı flag veya settlement öncesinde zorunlu stop condition ile sınırlandırılır. Böylece attack path bozulmaz, gerçek para hareketi oluşmaz.

Bu yazıda finans red team kapsamını yalnız IP listesi veya “şunlara dokunmayın” maddeleri üzerinden değil; ölçüm geçerliliği, production safety, fraud risk, third-party bağımlılıkları, mevzuat ve güvenli evidence üretimi üzerinden ele alacağız.

Finans Red Team nedir ve neden ayrı kapsam disiplini gerektirir?

Finans Red Team; banka, ödeme kuruluşu, elektronik para kuruluşu, yatırım kuruluşu, sigorta şirketi veya finansal teknoloji sağlayıcısının gerçekçi threat profile karşısındaki prevention, detection, response ve recovery kabiliyetlerini ölçen adversary emulation çalışmasıdır.

Buradaki ayrım “finans sistemlerine pentest yapmak” değildir. Web, API, mobil veya iç ağ sızma testi belirli attack surface üzerindeki zafiyetleri geniş coverage ile değerlendirebilir. Red Team ise seçilmiş bir adversary objective doğrultusunda insan, süreç ve teknoloji katmanlarını birbirine bağlayan end-to-end attack path'i ilerletir.

Red Team ile sızma testi arasındaki fark, kullanılan araçlardan önce sorulan soruda başlar. Bir penetration test “Payment API hangi authorization zafiyetlerini içeriyor?” diye sorabilir. Finans Red Team ise “Düşük yetkili bir foothold, kimlik ve yönetim zincirleri üzerinden yetkisiz payment approval capability'sine dönüşebilir mi; SOC ve Fraud Operations bu ilerlemeyi zamanında ilişkilendirebilir mi?” sorusunu ölçer.

Finans sektöründe kapsam disiplinini zorlaştıran beş özellik vardır:

1. 1İşlem bütünlüğü: Küçük bir test değişikliği bile ledger, reconciliation veya downstream reporting üzerinde zincirleme etki oluşturabilir.
2. 2Hizmet sürekliliği: Ödeme, elektronik bankacılık ve müşteri kanalları çoğunlukla 7/24 çalışır; “gece test ederiz” varsayımı güvenli değildir.
3. 3Veri hassasiyeti: Müşteri sırrı, kişisel veri, cardholder data, authentication material ve transaction data aynı attack path üzerinde bulunabilir.
4. 4Third-party bağımlılığı: Cloud, payment processor, card scheme, KYC provider, antifraud platformu, SMS/OTP sağlayıcısı ve managed SOC farklı legal boundary'ler oluşturur.
5. 5Düzenleyici kapsam: Banka, fintek, ödeme kuruluşu ve kart verisi işleyen şirket aynı mevzuata tabi değildir. Teknik scope ile regulatory scope eş anlamlı kabul edilemez.

Bu nedenle finans Red Team'de kapsamı daraltmak, listeyi kısaltmak anlamına gelmez. Kapsam; gerçekçiliği kaybetmeden hangi capability'nin hangi proof level'a kadar ilerletilebileceğini tanımlamalıdır.

Kapsam asset listesinden değil kritik business function'dan başlamalıdır

“Şu IP'ler ve domain'ler scope içindedir” ifadesi bir finans Red Team için yetersizdir. Asset listesi gereklidir fakat başlangıç noktası değildir. Önce korunması gereken business function ve kabul edilemez sonuç belirlenmelidir.

Örnek kritik business function'lar şunlardır:

• Müşteri kimlik doğrulama ve account recovery
• Para transferi oluşturma, authorization ve settlement
• Card authorization ve transaction processing
• Elektronik para issuance ve redemption
• Core banking veya wallet ledger bütünlüğü
• Fraud detection ve transaction monitoring
• Open banking ve veri paylaşım servisleri
• Treasury, liquidity ve reconciliation süreçleri
• SWIFT messaging ve payment instruction kontrolü
• Müşteri onboarding, KYC ve identity verification
• Privileged access ve cryptographic key management
• Incident response ve müşteri hizmetlerinin fraud escalation süreci

Business function seçildikten sonra onu destekleyen teknoloji, identity, process ve third-party dependency'leri çıkarılır. Aksi halde yalnız ön yüz uygulaması scope'a alınır, fakat gerçek saldırganın kullanacağı CI/CD, help desk, cloud control plane, service account veya payment operations workstation zincirin dışında kalır.

Function-to-system mapping nasıl yapılır?

Her kritik fonksiyon için en az şu ilişki haritası çıkarılmalıdır:

Critical business function
  → customer ve operator channel'ları
  → API, queue ve integration service'leri
  → identity ve privileged access katmanı
  → database, ledger ve cryptographic service'ler
  → fraud, monitoring ve approval süreçleri
  → third-party ve intra-group provider'lar
  → SOC, IR, backup ve recovery bağımlılıkları

Bu mapping, testin bütün bileşenleri aktif olarak exploit edeceği anlamına gelmez. Hangi sistemin attack path içinde bulunduğunu, hangi sistemin yalnız evidence kaynağı olduğunu ve hangisinin ayrı authorization gerektirdiğini gösterir.

Güncel DORA TLPT teknik standardı da scope specification yaklaşımında kritik veya önemli fonksiyonların, bunları destekleyen ICT sistemlerinin, outsourcing durumunun, ilgili jurisdiction'ların ve confidentiality, integrity, availability ya da authenticity boyutunu temsil eden preliminary flag'lerin belirtilmesini ister. Bu çerçeve her Türk fintek şirketine doğrudan uygulanıyor kabul edilemez; ancak kapsam tasarımının neden business function'dan başlaması gerektiğini iyi gösterir.

İkili scope modeli neden yetersizdir?

Klasik in-scope / out-of-scope ayrımı, finansal sistemlerde operator'a yeterli karar alanı vermez. Örneğin payment API scope içinde olabilir; fakat beneficiary oluşturma serbest, transaction submission conditional, settlement ise yasak olabilir. Aynı asset üzerinde farklı action'ların farklı statüsü vardır.

Daha kullanışlı model dört sınıftan oluşur:

Bu modelde “asset scope içi” tek başına yeterli bir ifade değildir. Scope kaydı şu sorulara cevap vermelidir:

• Hangi identity ile test yapılabilir?
• Hangi transaction type kullanılabilir?
• Hangi environment ve tenant geçerlidir?
• Hangi action otomatik serbesttir?
• Hangisi just-in-time approval gerektirir?
• Proof hangi noktada tamamlanmış sayılır?
• Hangi state transition öncesinde durulmalıdır?
• Hangi telemetry'nin oluşması beklenir?
• Cleanup ve reconciliation kimin sorumluluğundadır?

“Production out-of-scope” güvenli ama geçersiz bir test üretebilir

Kritik production sistemlerini tümüyle dışarıda bırakmak ilk bakışta güvenli görünür. Fakat test yalnız staging üzerinde yürürse şu farklılıklar ölçümü bozabilir:

• Production identity ve role mapping farklıdır.
• Fraud rule ve transaction threshold'ları staging'de temsil edilmez.
• Network segmentation ve service-to-service trust farklıdır.
• HSM veya key management entegrasyonu mock service kullanır.
• SOC, production loglarını izlerken staging telemetry'si eksiktir.
• Third-party callback ve approval akışları devre dışıdır.
• Deployment, secrets ve break-glass süreçleri production'a özgüdür.

Çözüm production'ı sınırsız açmak değildir. Live path üzerindeki kritik edge'leri, önceden tanımlanmış canary ve evidence-only kontrollerle doğrulamaktır.

Finans Red Team için objective nasıl yazılmalıdır?

“Para transfer edilebiliyor mu?” ölçülebilir gibi görünür fakat gereğinden geniştir. Hangi başlangıç koşulundan, hangi account türüne, hangi authorization boundary üzerinden ve hangi transaction state'ine ulaşılacağı belli değildir.

Daha iyi objective şu yapıyı kullanır:

Starting condition
  + target business capability
  + allowed attack path
  + proof boundary
  + defensive measurement

Örnek:

Bu objective beş şeyi netleştirir:

• Başlangıç erişimi bellidir.
• Hedef teknik sistem değil business capability'dir.
• Gerçek para hareketi gerektirmez.
• Proof boundary önceden yazılmıştır.
• Başarı yalnız Red Team'in ilerlemesiyle ölçülmez.

Red Team senaryosu nasıl yazılır? rehberimizde objective, threat profile, constraint ve success criteria ilişkisini ayrıntılı biçimde açıklıyoruz. Finans senaryosunda bu alanlara transaction state ve financial impact boundary de eklenmelidir.

Flag tasarımı: Gerçek para hareketi olmadan capability nasıl kanıtlanır?

Flag, Red Team'in objective'e ulaştığını gösterecek önceden kararlaştırılmış ve güvenli kanıttır. Finans sistemlerinde iyi flag, saldırganın yapmak istediği son işlemi gerçekten tamamlamasını gerektirmez.

Güvenli flag örnekleri

Flag'in güvenli olması tek başına yeterli değildir. Evidence'in kim tarafından, hangi source'tan ve hangi anda üretildiği doğrulanmalıdır. Screenshot tek başına zayıf kalabilir. Daha güçlü evidence paketi şunları içerebilir:

• Engagement ve scenario ID
• Timestamp ve timezone
• Source identity ve source host
• Target asset ve object ID
• Transaction veya record'un canary olduğunu gösteren marker
• Öncesi ve sonrası state
• Request ve response'un secret içermeyen ilgili bölümü
• Evidence digest
• İlgili SOC/Fraud telemetry referansı
• Cleanup sonucu ve owner onayı

Örnek bir evidence kaydı şöyle tutulabilir:

engagement_id: FIN-RT-2026-04
scenario_id: SCN-PAYMENT-01
flag_id: FLAG-BENEFICIARY-CREATE
proof_level: conditional-active
target:
  asset_id: payment-orchestrator-prod
  object_type: synthetic-beneficiary
  object_id: RT-CANARY-8841
action:
  requested: create
  completed: true
  irreversible_financial_effect: false
evidence:
  timestamp: "2026-08-06T02:14:19+03:00"
  request_digest: "sha256:<redacted>"
  response_digest: "sha256:<redacted>"
controls:
  control_team_approval: CT-184
  stop_before_state: payment-submitted
cleanup:
  status: verified
  verified_by: payment-operations-control

Bu kayıt bir exploit tarifi değildir. Testin scope, approval, proof ve cleanup kararlarını denetlenebilir hale getiren engagement artefact'ıdır.

Transaction lifecycle sınırı açık yazılmalıdır

Finansal işlem tek adımlı değildir. “Transfer yapma yetkisi” ifadesi, çok farklı state'leri tek kavram altında toplar.

Genel bir payment lifecycle şu aşamaları içerebilir:

Draft
  → validation
  → fraud/risk assessment
  → authorization
  → queue
  → clearing veya routing
  → settlement
  → ledger posting
  → reconciliation
  → customer notification

Gerçek sistemde sıra ve isimler farklı olabilir. Kapsam hazırlanırken kurumun gerçek state machine'i çıkarılmalıdır. Her scenario için stop_before_state veya maximum_reachable_state tanımlanmalıdır.

Örneğin Red Team'in authorization-ready state'ine kadar ilerlemesi yeterli olabilir. Operator'ın doğru role ve API capability'ye sahip olduğu, transaction'ın canary olduğu ve bir sonraki çağrının settlement sürecini başlatacağı kanıtlandığında objective tamamlanır. “Bir adım daha atalım, kesin görelim” yaklaşımı burada kabul edilemez.

Reversibility tek başına güvenlik ölçütü değildir

“İşlemi sonra geri alırız” düşüncesi yanıltıcıdır. Reversal yapılabilse bile şu etkiler oluşabilir:

• Fraud modelinin öğrenme verisi bozulabilir.
• Reconciliation exception açılabilir.
• Müşteri bildirimi tetiklenebilir.
• Downstream third-party bir işlemi gerçek kabul edebilir.
• Regulatory veya financial reporting verisi etkilenebilir.
• Investigation ekibi gerçek fraud incident başlatabilir.
• Ledger'da silinmeyen audit trail kalabilir.

Bu nedenle proof boundary yalnız finansal tutara değil, downstream process etkisine göre belirlenmelidir.

Müşteri verisi ve cardholder data nasıl sınırlandırılmalıdır?

Finans Red Team sırasında “data access doğrulandı” demek için gerçek müşteri verisini toplu biçimde çıkarmak gerekmez. Data minimization, testin kanıt gücünü düşürmeden exposure'ı azaltmalıdır.

Evidence hiyerarşisi

En düşük riskli yöntemden başlayarak şu sıra kullanılabilir:

1. 1Permission ve effective access analizi
2. 2Metadata veya schema görünürlüğü
3. 3Canary record'a erişim
4. 4Sentetik dataset üzerinde sınırlı query
5. 5Masked veya tokenized örnek veri
6. 6Gerçek veride yalnız record count veya digest
7. 7Son çare olarak Control Team onaylı, minimum gerçek kayıt

Bir alt seviye objective'i yeterince kanıtlıyorsa üst seviyeye geçilmemelidir.

Yasakların ölçülebilir yazılması gerekir

“Müşteri verisi alınmayacak” ifadesi iyi niyetlidir fakat operasyonel değildir. Şu soruları açıkta bırakır:

• Query çalıştırmak veri alma sayılır mı?
• Bir record ekranda görüntülenebilir mi?
• Screenshot alınabilir mi?
• Schema ve row count kaydedilebilir mi?
• Loglarda bulunan masked identifier saklanabilir mi?
• Backup snapshot metadata'sı görülebilir mi?

Daha iyi kural şöyledir:

Cardholder data için Red Team ile PCI DSS aynı şey değildir

PCI DSS v4.0.1 Requirement 11.4, tanımlı penetration testing ve segmentation testing beklentileri içerir. Red Team bu testlerden farklı bir güvenlik iddiasını ölçer. Finans Red Team çıktısı PCI programına kanıt sağlayabilir; fakat yıllık PCI penetration test'i veya segmentation validation yerine otomatik olarak geçmez.

Cardholder Data Environment scope'a temas ediyorsa Red Team planında en az şu ayrımlar yapılmalıdır:

• CDE'ye giden attack path
• PAN ve sensitive authentication data exposure sınırı
• Tokenization ve masking katmanı
• Segmentation control'ünün test içindeki rolü
• QSA veya compliance owner ile evidence paylaşım biçimi
• Test artefact'larının PCI scope'u genişletip genişletmediği

Red Team altyapısına gerçek PAN kopyalamak, test için yeni bir hassas data store oluşturabilir. Bu nedenle canary veya tokenized proof varsayılan olmalıdır.

HSM, key management ve signing sistemleri nasıl ele alınmalıdır?

HSM veya key management plane, finansal sistemlerde çoğu zaman testin en kritik objective'lerinden biridir. Aynı zamanda aktif doğrulamanın en fazla sınırlandırılması gereken alandır.

Sık görülen attack path'ler şunlardır:

• Privileged workstation compromise sonrası HSM management access
• CI/CD veya configuration management üzerinden signing service etkisi
• Ortak kullanılan admin identity veya weak separation of duties
• Backup, monitoring veya vendor support account üzerinden indirect control
• Application service account'tan key operation capability'sine geçiş
• Cloud IAM permission üzerinden managed HSM administration

HSM'nin out-of-scope ilan edilmesi bu yolları görünmez hale getirir. Buna karşılık production key export, gerçek payment instruction signing veya key destruction gibi işlemler de varsayılan proof yöntemi olamaz.

HSM için proof level örneği

Key material hiçbir koşulda rapora, ticket sistemine veya genel engagement storage'a yazılmamalıdır. Test sırasında secret'a istemeden erişilirse containment ve rotation kararı Control Team, cryptography owner ve Incident Response tarafından birlikte verilmelidir.

Third-party ve cloud sistemleri scope'a nasıl alınır?

Fintek mimarileri çoğu zaman kurumun kendi altyapısından daha geniş bir trust chain'e sahiptir. Cloud provider, KYC service, antifraud SaaS, card processor, SMS/OTP provider, call center, managed SOC ve grup içi teknoloji şirketi aynı critical function'a destek verebilir.

Teknik dependency, hukuki authorization anlamına gelmez.

Bir uygulamanın third-party API key'ine erişmek Red Team'e o sağlayıcının altyapısını test etme yetkisi vermez. Benzer şekilde kurumun cloud subscription sahibi olması, kullanılan her managed service için her test action'ının serbest olduğu anlamına gelmez. Provider security testing policy, sözleşme ve teknik owner birlikte kontrol edilmelidir.

Third-party scope kaydında bulunması gerekenler

• Sağlayıcının legal name'i
• Sunulan service ve desteklediği critical function
• Asset veya tenant ownership
• Contract'taki security testing ve notification maddeleri
• Provider'ın yazılı authorization durumu
• İzin verilen test action'ları
• Rate limit ve maintenance window
• Provider incident escalation contact'i
• Data residency ve cross-border evidence kısıtları
• Cleanup ve log retention sorumluluğu
• Test fark edilirse uygulanacak deconfliction süreci

Üç farklı third-party yaklaşımı

1. 1Directly in-scope: Sağlayıcı açık yazılı authorization verir; ilgili sistem plan dahilinde test edilir.
2. 2Dependency-only: Sağlayıcının kendisi test edilmez, fakat kurumdaki credential, integration ve access path değerlendirilir.
3. 3Simulated substitute: Gerçek provider yerine mock endpoint veya canary tenant kullanılır; kurumun control'leri ölçülür.

Güncel DORA TLPT RTS, critical function'ı destekleyen outsourced ICT system'lerin scope specification içinde tanımlanmasını ister. Pooled veya joint TLPT modellerinde third-party ve grup içi provider'ların ilgili sistem, süreç ve teknolojileri belirli koşullarda scenario kapsamına girebilir. Bu yaklaşım, third-party'yi sessizce test etmek anlamına gelmez; tarafların rolü, yetkisi ve risk yönetimi önceden tanımlanır.

Social engineering kapsamı finans sektöründe nasıl sınırlandırılmalıdır?

Finansal saldırganlar yalnız teknik sistemleri hedeflemez. Help desk, call center, payment operations, treasury, executive assistant, vendor management ve fraud analyst rolleri yüksek değerli insan hedefleridir. Bu nedenle social engineering'i otomatik olarak kapsam dışı bırakmak gerçekçiliği azaltabilir.

Ancak “phishing serbest” ifadesi de yetersizdir. Şunlar ayrı ayrı kararlaştırılmalıdır:

• Hangi çalışan population'ı hedeflenebilir?
• Executive ve privileged role'ler dahil mi?
• Third-party çalışanları için izin var mı?
• Customer-facing call center akışları test edilecek mi?
• Credential capture yerine synthetic form kullanılacak mı?
• MFA approval prompt üretmek serbest mi?
• Gerçek parola girilirse saklanacak mı, anında discard mı edilecek?
• Attachment ve payload sınıfı nedir?
• Mail gateway bypass veya allowlist kullanılacak mı?
• Physical delivery, QR code, voice call ve messaging channel'ları dahil mi?
• Çalışan performansı bireysel olarak raporlanacak mı?

İyi uygulama, çalışanı “başarısız kişi” olarak etiketlemek değildir. Control tasarımını ölçmektir: e-mail security, browser isolation, identity protection, help desk verification, payment callback, dual control ve escalation davranışı.

Gerçek müşteriyle social engineering, açık ve ayrı bir hukuki yetki olmadan Red Team kapsamına alınmamalıdır. Müşteri account'ı, kartı, telefonu veya kişisel verisi canary yerine kullanılamaz.

ATM, şube ve fiziksel erişim scope'u

Fiziksel Red Team finans sektöründe önemli olabilir; fakat kapsamı “şubelere girilebilir” seviyesinde bırakılamaz.

Şunlar ayrı action olarak değerlendirilmelidir:

• Tailgating veya badge control testi
• Network port ve kiosk erişimi
• ATM çevresinde fiziksel observation
• Production ATM'ye cihaz takma veya müdahale
• Cash area, safe veya restricted operation room erişimi
• Printed document ve disposal process değerlendirmesi
• Visitor management ve security desk escalation
• Data center veya disaster recovery site erişimi

Production ATM'ye fiziksel cihaz bağlamak, cash dispenser veya card reader'a müdahale etmek, müşteri kullanımını etkilemek ve kolluk kuvveti müdahalesini tetikleyebilecek davranışlar ayrı risk sınıfındadır. Çoğu engagement'ta bu objective; decommissioned cihaz, lab ATM, canary şube bölgesi veya evidence-only physical access proof ile sınırlandırılmalıdır.

Physical operator için arrest/deconfliction letter bulunması tek başına yeterli değildir. Belgenin kim tarafından ve hangi doğrulama kanalıyla teyit edileceği, güvenlik görevlisinin sahte bir belgeyi kabul etmesini önleyecek biçimde tasarlanmalıdır.

Operational safety: Finans Red Team'de hangi eylemler varsayılan olarak yasaklanmalıdır?

Her kurumun risk toleransı farklıdır; ancak aşağıdaki action'lar açık ve istisnai onay bulunmadıkça yasak kabul edilmelidir:

• Gerçek para veya menkul kıymet hareketi
• Gerçek customer, merchant veya beneficiary üzerinde değişiklik
• Production ledger balance veya transaction record modification
• HSM production key export, rotation, destruction veya unauthorized signing
• Cardholder data veya customer data bulk extraction
• Fraud, AML veya transaction monitoring control'ünü devre dışı bırakma
• DDoS, stress test ve kapasite tüketimi
• Production queue'yu dolduracak message üretimi
• Gerçek account lockout veya customer authentication disruption
• Irreversible database, storage veya infrastructure change
• Backup silme, restore chain bozma veya ransomware encryption
• Audit log silme ya da retention policy değiştirme
• Third-party'yi yazılı authorization olmadan test etme
• Gerçek malware'i kontrolsüz yayma
• Executive veya employee üzerinde maddi, itibari ya da psikolojik risk oluşturma

Bu yasaklar testin “yumuşak” olduğu anlamına gelmez. Attack path'i mümkün olduğunca gerçek ilerletip son etkide safe substitute kullanmak, kontrolsüz zarar vermekten daha olgun bir Red Team disiplinidir.

Stop condition nasıl yazılmalıdır?

Stop condition, “sorun olursa dururuz” cümlesi değildir. Operator'ın ve Control Team'in yoruma ihtiyaç duymadan karar verebileceği observable trigger'dır.

Finansal stop condition örnekleri

• Canary dışındaki bir customer veya account üzerinde write oluşması
• Transaction'ın kararlaştırılan maximum_reachable_state değerini aşması
• Gerçek clearing, settlement veya card network'e message gönderilmesi
• Ledger ile reconciliation sistemi arasında beklenmeyen mismatch oluşması
• Fraud Operations'ın testi gerçek fraud olarak dış kuruma escalate etmesi
• Customer notification, SMS, push veya e-mail tetiklenmesi
• Production service error rate'inin belirlenen baseline üstüne çıkması
• Queue depth, CPU, latency veya transaction failure threshold'unun aşılması
• HSM'de production key operation çağrısının oluşması
• Test artefact'ının canary segment dışına yayılması
• Gerçek personal data veya secret material'ın engagement storage'a yazılması
• Third-party incident response veya regulator notification sürecinin tetiklenme riski
• Blue Team containment'ının business continuity'yi etkileyen aksiyona dönüşmesi
• Control Team iletişim kanalının kaybedilmesi

Her stop condition için şu alanlar yazılmalıdır:

Control Team nasıl kurulmalıdır?

Finans Red Team'de Control Team yalnız proje koordinasyon ekibi değildir. Operasyonun güvenliğini, secrecy'sini ve hukuki sınırını yöneten küçük ve yetkili gruptur.

Ekipte role göre şu temsilciler bulunabilir:

• Executive Sponsor
• Control Team Lead
• Cybersecurity veya Red Team owner
• SOC/Incident Response için sınırlı deconfliction contact'i
• Fraud Operations veya payment risk temsilcisi
• Critical function owner
• Legal, compliance ve privacy temsilcisi
• Third-party veya cloud liaison
• Business continuity contact'i

Herkesin bütün senaryoyu bilmesi gerekmez. Need-to-know ilkesi korunmalıdır. Ancak kill switch kullanacak veya gerçek para hareketini durduracak kişi erişilemez olmamalıdır.

TIBER-EU ve DORA TLPT modellerinde Control Team'in küçük tutulması, yeterli seniority'ye ve yönetim organına erişime sahip olması özellikle vurgulanır. Blue Team'in testten haberdar edilmesi ölçüm gerçekçiliğini değiştirebilir. Buna karşılık Control Team'in testin varlığını, risklerini ve escalation yolunu bilmemesi kabul edilemez.

Fraud Operations neden ayrı düşünülmelidir?

SOC bir endpoint veya identity anomaly'sini görebilir. Fraud Operations ise aynı anda beneficiary change, unusual payment preparation veya device-risk sinyali görebilir. Gerçek saldırı bu iki görünürlük alanının arasında ilerleyebilir.

Finans Red Team, şu korelasyon sorularını ölçmelidir:

• Compromised employee identity ile açılan payment operation aynı incident'a bağlanıyor mu?
• Privileged role change Fraud Operations'a context olarak gidiyor mu?
• SOC, account takeover sinyalini transaction monitoring ile ilişkilendiriyor mu?
• Fraud analyst şüpheli işlem gördüğünde cyber escalation başlatabiliyor mu?
• Containment yalnız user account'ı mı kilitliyor, active session ve token'ları da sonlandırıyor mu?
• Customer communication ve regulatory reporting kararı doğru owner'a ulaşıyor mu?

Deconfliction, testin başarısını bozmadan nasıl yürütülür?

Blue Team testi fark ettiğinde iki uç davranış görülür. Birincisi, “testmiş” denilip bütün alert'lerin kapatılmasıdır. İkincisi, testin devam etmesine bakılmadan geniş containment uygulanmasıdır. İlk yaklaşım measurement'ı bozar; ikincisi operasyonel risk yaratabilir.

Daha iyi deconfliction modeli şöyledir:

1. 1Blue Team normal incident process'i izler.
2. 2Yalnız önceden belirlenen senior contact, şüpheli incident'ı Control Team'e codeword veya case reference ile sorar.
3. 3Control Team, scenario ayrıntısı vermeden continue, constrain, pause veya terminate kararı verir.
4. 4Mümkünse Blue Team'in investigation ve containment kararı doğal biçimde devam eder.
5. 5Business impact riski oluşursa secrecy'den önce güvenlik gelir.

Testin “yakalanmamak” için güvenlik ekibini manipüle etmesi doğru değildir. Detection gerçekleştiyse bu Red Team başarısızlığı değil, savunma sonucu olarak kaydedilir. Gerekirse Control Team'in onayıyla leg-up verilerek sonraki control katmanı ölçülür.

Rules of Engagement hangi teknik alanları içermelidir?

NIST SP 800-115, Rules of Engagement'i test başlamadan önce belirlenen ayrıntılı yetki ve kısıtlar olarak tanımlar. Finans sektörü için RoE, genel bir pentest izin yazısından daha ayrıntılı olmalıdır.

En az şu alanlar bulunmalıdır:

1. 1Yetki veren legal entity ve authorized signatory
2. 2Engagement objective ve business risk hypothesis
3. 3Starting condition
4. 4Critical function'lar
5. 5In-scope, conditional, evidence-only ve out-of-scope asset/action'lar
6. 6Domain, IP, cloud tenant, subscription ve application listesi
7. 7Identity ve user population kapsamı
8. 8Transaction type ve state sınırları
9. 9Canary customer, account, card, merchant ve beneficiary listesi
10. 10Data access, screenshot ve retention kuralları
11. 11Cardholder data ve personal data proof limit'leri
12. 12HSM, key management ve signing sınırları
13. 13Social engineering channel ve population'ı
14. 14Physical security ve ATM sınırları
15. 15Third-party authorization matrisi
16. 16İzin verilen ve yasaklanan TTP'ler
17. 17Payload, C2 ve persistence standardı
18. 18Rate limit ve resource consumption sınırları
19. 19Test window ve blackout dönemleri
20. 20Fraud, treasury, settlement ve reconciliation takvimi
21. 21Control Team ve emergency contact'ler
22. 22Deconfliction procedure
23. 23Stop condition ve kill switch
24. 24Leg-up approval modeli
25. 25Evidence encryption ve storage
26. 26Cross-border data handling
27. 27Incident, breach ve regulator notification ayrımı
28. 28Cleanup ve credential rotation sorumluluğu
29. 29Reporting, classification ve distribution listesi
30. 30Retest ve Purple Team acceptance criteria

Machine-readable scope kaydı

Uzun RoE dokümanına ek olarak operator'ın kullanabileceği machine-readable bir scope kaydı hazırlanabilir:

engagement: FIN-RT-2026-04
default_policy: deny

assets:
  - id: payment-api-prod
    scope: conditional
    allowed_actions:
      - authenticated-recon
      - authorization-validation
      - canary-beneficiary-create
    forbidden_actions:
      - real-customer-write
      - payment-submit
      - settlement-message
    constraints:
      identities:
        - rt-canary-operator
      source_cidrs:
        - 198.51.100.24/32
      max_requests_per_minute: 30
      approval_reference: CT-184

  - id: core-ledger-prod
    scope: evidence-only
    allowed_actions:
      - permission-review
      - canary-record-read
    forbidden_actions:
      - record-update
      - bulk-query

  - id: hsm-prod
    scope: evidence-only
    allowed_actions:
      - role-path-validation
    forbidden_actions:
      - key-export
      - key-rotate
      - key-destroy
      - production-sign

stop_conditions:
  - real-customer-write-observed
  - transaction-state-exceeds-authorization-ready
  - service-error-rate-over-baseline
  - control-channel-unavailable

Bu dosya tek başına authorization değildir. İmzalı RoE ve hukuki yetkinin teknik uygulamasını kolaylaştıran operational control'dür. Operator tooling'i destekliyorsa request göndermeden önce asset, action, identity ve approval alanlarını policy olarak kontrol edebilir.

Assumed breach mi, full-scope mu?

Finansal kurumlar bazen “phishing ve initial access riskli, standard user verelim” diyerek assumed breach tercih eder. Bu yaklaşım geçerlidir; ancak ölçülen iddia doğru yazılmalıdır.

Assumed breach “daha kolay Red Team” değildir. Objective internal payment control, Active Directory, cloud IAM veya CI/CD path'iyse test zamanını daha değerli aşamalara ayırabilir. Active Directory odaklı Red Team'de zincirlenen zafiyetler yazımız, standard user foothold'undan Tier 0 ve hybrid identity path'lerinin nasıl ele alınması gerektiğini ayrıca açıklar.

DORA TLPT ve TIBER-EU kapsam tasarımına ne söylüyor?

Avrupa Birliği'nde DORA kapsamındaki belirli financial entity'ler için threat-led penetration testing ayrı bir regulatory test modelidir. 2025/1190 sayılı Delegated Regulation; entity selection, internal/external tester şartları, scope, threat intelligence, aktif testing, closure, remediation ve mutual recognition ayrıntılarını düzenler.

Bu gereksinimler her finans Red Team engagement'ına veya Türkiye'deki her fintek şirketine otomatik olarak uygulanmaz. Kurumun legal entity'si, faaliyet gösterdiği jurisdiction ve ilgili otorite kararı ayrıca değerlendirilmelidir.

Bununla birlikte kapsam tasarımı açısından güçlü ilkeler sunar:

• Scope kritik veya önemli function'lardan başlar.
• Function'ı destekleyen ICT sistemleri ve third-party provider'lar tanımlanır.
• Dahil edilmeyen kritik function için gerekçe yazılır.
• Live production riskleri preparation aşamasında değerlendirilir.
• Confidentiality, integrity, availability ve authenticity için flag'ler tanımlanır.
• İzin verilen ve yasaklanan TTP'ler test planına yazılır.
• En az üç end-to-end threat scenario seçilir.
• Aktif Red Team fazı TLPT kapsamında en az 12 hafta sürer.
• Control Team, tester ve threat intelligence provider rollerinin ayrımı korunur.
• Test sonrası replay, Purple Team ve remediation planı bulunur.

Özellikle son madde önemlidir. DORA TLPT için belirtilen 12 haftalık aktif test süresi, her Red Team'in 12 hafta sürmesi gerektiği anlamına gelmez. Regulatory TLPT ile kurumun kendi risk bazlı Red Team engagement'ı aynı satın alma kalemi gibi ele alınmamalıdır.

ECB'nin güncel TIBER-EU çerçevesi, DORA TLPT RTS ile uyumlu hale getirilmiştir. TIBER-EU; gerçek threat intelligence'a dayalı kontrollü saldırılarla critical function'ların insan, süreç ve teknoloji katmanlarında test edilmesini, sonucu basit pass/fail yerine öğrenme ve cyber resilience gelişimi olarak konumlandırır.

Türkiye'de banka ve fintek aynı regulatory scope'a sahip değildir

Türkiye'de banka, ödeme kuruluşu ve elektronik para kuruluşunun bilgi sistemleri yükümlülükleri aynı kaynak üzerinden yönetilmez.

• Bankalar için BDDK'nın bilgi sistemleri ve elektronik bankacılık düzenlemeleri ile Bilgi Sistemlerine İlişkin Sızma Testleri Hakkında Genelge dikkate alınır.
• Ödeme ve elektronik para kuruluşları için 6493 sayılı Kanun çerçevesindeki TCMB düzenlemeleri ve bilgi sistemleri Tebliği değerlendirilir.
• Cardholder data işleyen yapılarda PCI DSS yükümlülükleri ayrıca doğabilir.
• SWIFT kullanıcısı olan kurumlarda güncel Customer Security Controls Framework ve bağımsız assessment süreci ayrı bir control set oluşturur.

Buradaki kritik nokta şudur: Regulatory penetration test, compliance assessment ve Red Team birbirinin yerine geçen çalışmalar değildir. Aynı teknik evidence birden fazla programa katkı sağlayabilir; ancak engagement objective, bağımsızlık, methodology, scope ve rapor formatı farklıdır.

Kapsam hazırlanırken Legal ve Compliance ekibinden “hangi standarda tabiyiz?” cevabından fazlası alınmalıdır:

• Hangi legal entity test ediliyor?
• Hangi lisans veya faaliyet kapsamı etkileniyor?
• Hangi regulator veya scheme owner'a bildirim gerekebilir?
• Test sırasında incident eşiği aşılırsa hangi notification clock başlar?
• Evidence hangi ülke veya ortamda saklanabilir?
• Third-party ve grup şirketleri için kim authorization verebilir?

Bu bölüm hukuki görüş yerine teknik scoping yaklaşımı sunar. Bağlayıcı yükümlülükler kurumun hukuk, uyum ve ilgili otorite ekipleriyle güncel metin üzerinden teyit edilmelidir.

Finans Red Team'de en sık yapılan 10 kapsam hatası

1. Kritik olan her şeyi out-of-scope yapmak

Payment, ledger, identity ve HSM tümüyle kapsam dışıysa gerçek business risk ölçülemez. Active exploitation yerine conditional veya evidence-only proof kullanılmalıdır.

2. Production'ı sınırsız test alanı kabul etmek

Live testing gerçekçilik sağlar; sınırsız yetki vermez. Transaction state, data ve availability limit'leri asset bazında yazılmalıdır.

3. Scope'u yalnız IP ve domain listesiyle tanımlamak

Cloud tenant, identity provider, SaaS, branch, user population, payment rail ve third-party dependency eksik kalır.

4. “Gerçek veri alınmayacak” gibi ölçülemeyen yasaklar yazmak

Record, field, query, screenshot, export ve retention için ayrı sınır gerekir.

5. Third-party erişimini kurum yetkisi sanmak

Credential veya API integration, provider üzerinde security testing authorization oluşturmaz.

6. Objective'i gerçek transaction ile kanıtlamak

Capability; canary, pre-settlement state, test partition veya signed marker ile doğrulanabilir.

7. Fraud Operations'ı kapsam tasarımına almamak

Cyber ve fraud signal'ları birleşmediğinde finansal attack path'in en önemli savunma katmanı ölçülmez.

8. Stop condition'ı yoruma açık bırakmak

“Impact oluşursa dur” yerine threshold, observer, action ve restart authority yazılmalıdır.

9. Cleanup'ı yalnız Red Team'e bırakmak

Account, role, beneficiary, certificate, scheduled task, cloud object ve log artefact'ları system owner ile çift taraflı doğrulanmalıdır.

10. Compliance testini Red Team diye adlandırmak

Yıllık sızma testi, PCI testi veya configuration assessment; threat-led, objective odaklı ve savunmayı ölçen Red Team'in otomatik karşılığı değildir.

Örnek finans Red Team kapsam matrisi

Bu tablo doğrudan kopyalanacak bir template değildir. Kurumun mimarisi, threat profile'ı ve risk toleransı üzerinden yeniden yazılmalıdır.

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

“Red Team para transfer edemedi, test başarılı” sonucu tek başına anlamlı değildir. Red Team objective'e ulaşamamış olabilir; fakat hiçbir control tarafından görülmeden yanlış path denemiş de olabilir. Tersi durumda objective'e ulaşılsa bile SOC saldırıyı erken tespit edip doğru containment uygulamış olabilir.

Prevention metric'leri

• Phishing veya initial access prevention oranı
• MFA ve device trust enforcement
• Privilege escalation edge'lerinin bloklanma oranı
• Transaction state boundary enforcement
• Dual control ve separation of duties başarısı
• HSM ve signing policy enforcement
• Third-party access restriction

Visibility ve detection metric'leri

• Attack step telemetry coverage
• Identity, endpoint, cloud ve transaction log korelasyonu
• Mean time to detect
• Mean time to correlate cyber ve fraud signal'ları
• Canary ve flag telemetry görünürlüğü
• Detection'ın doğru user, host ve transaction context'i üretmesi

Response metric'leri

• Mean time to triage
• Mean time to contain
• Session, token ve credential invalidation kapsamı
• Fraud hold veya transaction prevention doğruluğu
• Third-party escalation süresi
• Customer impact olmadan containment başarısı
• Incident classification ve notification decision süresi

Safety metric'leri

• Gerçek customer record'a istemsiz erişim sayısı
• Production incident veya degradation sayısı
• Stop condition'a uyum
• Cleanup verification oranı
• Test artefact'ı kalan asset sayısı
• Yetkisiz third-party interaction sayısı
• Canary dışı financial effect sayısı

İyi finans Red Team sonucu, objective'i ve test güvenliğini aynı raporda gösterir. Operasyon hiçbir zarar üretmedi diye attack path zayıf sayılmaz; zarar üretmeden güçlü kanıt sunmak zaten profesyonel uygulamanın parçasıdır.

Rapor hangi çıktıları içermelidir?

Finans Red Team raporu vulnerability listesi gibi yazılmamalıdır. Her scenario için business function, attack path, financial proof boundary ve savunma sonucu birlikte gösterilmelidir.

Executive narrative

Assumed breach olarak sağlanan standard employee identity, ödeme yetkisi
içermiyordu. Cloud IAM delegation ve CI/CD service connection hakları
zincirlenerek payment orchestration platformunda canary beneficiary oluşturma
capability'si doğrulandı.

Gerçek transaction oluşturulmadı. RoE gereği objective, payment submission
öncesindeki flag ile tamamlandı. SOC privilege escalation adımını tespit etti;
ancak aynı identity'nin payment control plane erişimini Fraud Operations olayıyla
ilişkilendiremedi. Containment 41 dakika sonra yalnız user account üzerinde
uygulandı; mevcut session token'ı 18 dakika daha geçerli kaldı.

Her scenario kaydında bulunması gerekenler

1. 1Critical business function
2. 2Threat profile ve objective
3. 3Starting condition
4. 4Scope ve approval reference
5. 5Attack path ve MITRE ATT&CK mapping
6. 6Ulaşılan ve ulaşılamayan flag'ler
7. 7Proof boundary ve neden seçildiği
8. 8Financial effect sonucu
9. 9Data access özeti
10. 10Prevention ve telemetry sonucu
11. 11Detection, investigation ve response timeline
12. 12Fraud Operations korelasyonu
13. 13Third-party etkisi
14. 14Stop condition veya deviation
15. 15Cleanup ve reconciliation doğrulaması
16. 16Root cause
17. 17Tactical ve structural remediation
18. 18Owner, target date ve dependency
19. 19Retest acceptance criteria

Red Team raporu gerçek customer identifier, PAN, secret, key material veya gereksiz transaction detail içermemelidir. Executive report, technical evidence ve restricted annex farklı access control ile dağıtılabilir.

Cleanup ve recovery nasıl doğrulanmalıdır?

“Araçlar kaldırıldı” cleanup için yeterli değildir. Finans ortamında test artefact'ları business record, identity, queue veya third-party loglarında kalabilir.

Cleanup checklist şu alanları kapsamalıdır:

• Canary dışı account veya object oluşturulmadığının doğrulanması
• Oluşturulan canary beneficiary, merchant veya transaction draft'larının kapatılması
• Temporary role, group ve IAM policy'lerin kaldırılması
• Session, token, credential ve certificate'ların revoke edilmesi
• Scheduled task, service, persistence ve C2 artefact'larının kaldırılması
• Test key ve test partition artefact'larının yönetilmesi
• CI/CD secret ve service connection değişikliklerinin geri alınması
• Cloud resource, snapshot ve log export'larının silinmesi
• Fraud case ve customer service ticket'larının test olarak kapatılması
• Ledger ve reconciliation owner'ının “financial effect yok” onayı
• Third-party tarafındaki artefact'ların temizlendiğine dair teyit
• Backup içinde test artefact'ı kalmışsa future restore riskinin kaydı
• Evidence retention süresi sonunda secure deletion

Güncel DORA TLPT RTS de compromised password, credential ve secret key bilgilerinin güvenli yönetimi ve silinmesi; C2 deactivation, kill switch, backdoor/malware removal ve backup restoration risklerinin ele alınmasını ister. Cleanup, kapanış toplantısındaki sözlü beyan değil, evidence üreten ayrı bir workstream olmalıdır.

Retest ve Purple Team ne zaman devreye girmelidir?

Finans Red Team sonrasında her attack path aynı biçimde yeniden oynatılmamalıdır.

• Permission veya configuration düzeltmesi için targeted retest yapılabilir.
• Detection eksikliği için Purple Team replay daha değerlidir.
• Fraud-SOC korelasyonu için ortak use case ve tabletop gerekebilir.
• Transaction state control'ü değiştiyse canary üzerinden end-to-end regression yapılmalıdır.
• Third-party contract veya integration değiştiyse authorization ve dependency scope'u yeniden değerlendirilmelidir.

Purple Team, Red Team ve BAS arasındaki fark yazımızda hangi çalışmanın hangi güvenlik iddiasını ölçtüğünü ayrıntılı olarak karşılaştırıyoruz. Finansal attack path için Red Team gerçeğe yakın zinciri gösterir; Purple Team detection ve response'u birlikte iyileştirir; BAS ise seçilmiş control behavior'larını daha sık ve tekrarlanabilir biçimde ölçebilir.

Finans Red Team hizmeti seçerken 12 kontrol maddesi

1. 1Scope asset listesinden önce critical business function'lara bağlanıyor mu?
2. 2Kurum tipi ve applicable regulatory framework doğru ayrıştırılmış mı?
3. 3Red Team ile yıllık penetration test birbirine karıştırılıyor mu?
4. 4Payment lifecycle ve irreversible state sınırı yazılmış mı?
5. 5Canary customer, account, beneficiary ve transaction modeli var mı?
6. 6HSM, ledger ve cardholder data için proof level tanımlanmış mı?
7. 7Third-party authorization matrisi hazırlanmış mı?
8. 8SOC ile Fraud Operations birlikte ölçülüyor mu?
9. 9Stop condition observable threshold içeriyor mu?
10. 10Tester'ın finans sektörü, risk management ve production safety deneyimi var mı?
11. 11Cleanup, reconciliation ve secure deletion çift taraflı doğrulanıyor mu?
12. 12Rapor attack path, financial effect, detection timeline ve remediation dependency'lerini birlikte gösteriyor mu?

SECNODEX'in kurumsal Red Team hizmeti, finansal sistemleri yalnız vulnerability checklist üzerinden değerlendirmez. Objective, Rules of Engagement, transaction boundary, canary evidence, third-party yetki ve SOC/Fraud visibility aynı engagement tasarımında ele alınır. Daha geniş zafiyet coverage'ı gereken web, API, mobil veya ağ bileşenleri için sızma testi hizmeti ayrı veya tamamlayıcı çalışma olarak planlanabilir.

Sonuç: Kapsamı daraltmak gerçek riski görünmez yapmak değildir

Finans Red Team'in en zor kısmı exploitation tekniği seçmek değil, gerçek attack path'i korurken geri döndürülemez sonucu sınırlandırmaktır.

Payment platformunu, ledger'ı, HSM'yi veya third-party dependency'leri tamamen kapsam dışı bırakmak güvenli görünebilir. Ancak saldırganın hedeflediği business function'lar test edilmediğinde kurum yalnız çevresindeki sistemler hakkında güvence üretir. Tersi şekilde gerçek para, gerçek müşteri ve gerçek key material üzerinde sınırsız proof istemek de profesyonel Red Team yaklaşımı değildir.

Doğru tasarım; business function'dan başlar, transaction lifecycle'ı modeller, her asset ve action için scope class belirler, canary flag kullanır, Control Team'e gerçek yetki verir ve stop condition'ı ölçülebilir yazar. Sonuçta rapor yalnız “nereye ulaşıldığını” değil, hangi finansal etkinin oluşmadığını, hangi control'ün çalıştığını ve SOC ile Fraud Operations'ın attack path'i nasıl karşıladığını gösterir.

Red Team nedir kapsamlı rehberimizde vurguladığımız gibi amaç havalı bir saldırı gösterisi değil, savunma olgunluğuna ilişkin güvenilir evidence üretmektir. Finans ve fintek ortamınıza uygun objective, Rules of Engagement ve production-safe proof modelini planlamak için SECNODEX ile iletişime geçebilirsiniz.

Kaynaklar

• EUR-Lex: Regulation (EU) 2022/2554 — Digital Operational Resilience Act
• EUR-Lex: Delegated Regulation (EU) 2025/1190 — DORA TLPT Regulatory Technical Standards
• European Central Bank: TIBER-EU Framework
• European Central Bank: TIBER-EU framework updated to align with DORA
• BDDK: Bilgi Sistemleri ve İş Süreçlerine İlişkin Düzenlemeler
• TCMB: Ödeme Sistemleri ile İlgili Tebliğler
• PCI Security Standards Council: PCI DSS v4.0.1 Document Library
• SWIFT: Customer Security Programme Document Centre
• NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
• NIST: Rules of Engagement definition
• MITRE ATT&CK: APT38
• MITRE ATT&CK: Cobalt Group