Red Team Sonrası Savunma Ekibi Ne Yapmalı? Aksiyon Planı

Red Team operasyonu sona eriyor. Yönetim sunumu yapılıyor, kritik attack path ekrana yansıtılıyor ve rapor ilgili ekiplere dağıtılıyor. Birkaç gün içinde onlarca ticket açılıyor:

• PowerShell kullanımını kısıtla
• Local administrator yetkilerini kaldır
• EDR policy'sini sıkılaştır
• Firewall kuralını değiştir
• SIEM use case'i yaz
• Service account parolasını değiştir

Üç ay sonra ticket'ların büyük bölümü Closed durumunda. Buna rağmen aynı attack path küçük bir varyasyonla yeniden çalıştırıldığında savunma ekibi saldırıyı yine zamanında göremiyor.

Buradaki sorun çoğu zaman çalışmanın teknik kalitesi değildir. Sorun, Red Team raporunun bir zafiyet listesi gibi ele alınmasıdır.

Red Team yalnızca tek tek hataları göstermez. İnsan, process ve technology katmanlarının aynı saldırı zinciri içinde nerede birbirini tamamlamadığını gösterir. Bir account'ın gereğinden fazla yetkili olması bulgudur; bu account'ın ele geçirilmesinin fark edilmemesi, lateral movement sırasında doğru telemetry'nin üretilmemesi, alert'in yanlış queue'ya düşmesi ve containment kararının gecikmesi ise savunma sisteminin birlikte ürettiği sonuçtur.

Başarılı kapanış, “kaç bulgu kapandı?” sorusuyla ölçülmez. Asıl soru şudur:

Bu rehber, Red Team bittikten sonraki ilk saatlerden 90 günlük iyileştirme programına kadar savunma ekibinin uygulayabileceği teknik ve yönetsel aksiyon planını adım adım ele alıyor.

Red Team'in temel amacını ve pentest'ten ayrıldığı noktayı önce netleştirmek isterseniz Red Team kapsamlı rehberimiz ile Red Team ve sızma testi arasındaki farkı anlattığımız yazı bu içeriğin doğal başlangıç noktalarıdır.

Red Team raporu teslim edilince çalışma bitmiş sayılır mı?

Hayır. Teknik operasyon bitmiş olabilir; kurumsal öğrenme süreci henüz başlamıştır.

Red Team'in aktif phase'i şu sorulara veri üretir:

• Saldırgan hangi başlangıç koşulundan ilerledi?
• Hangi trust boundary'leri aşabildi?
• Hangi control attack path'i durdurdu veya yavaşlattı?
• Hangi davranış telemetry üretti?
• Hangi telemetry merkezi platforma ulaşmadı?
• Hangi alert oluştu fakat işlenmedi?
• Analyst hangi noktada doğru hipotezi kurdu?
• Containment kararı saldırının hangi aşamasında geldi?
• Critical business objective'e ulaşılabildi mi?

Rapor bu soruların cevabını taşır. Ancak cevapların control değişikliğine, process iyileştirmesine ve doğrulanmış savunma yeteneğine dönüşmesi kurumun sorumluluğundadır.

Avrupa Merkez Bankasının güncel TIBER-EU Remediation Plan Guidance dokümanı da kapanış yaklaşımını yalnızca teknik bulgu düzeyinde bırakmaz. Her gözlem için eksiklik, önceliklendirilmiş remediation, beklenen tamamlanma zamanı, root cause, sorumlu ekip ve aksiyon alınmamasının riski gibi alanları ister. İngiltere Merkez Bankasının CBEST Implementation Guide yaklaşımı ise tactical ve strategic remediation'ın yönetişim, yönetim katılımı ve scope dışındaki benzer alanlara yapılacak read-across değerlendirmesiyle ele alınmasını bekler.

Her Red Team çalışması TIBER-EU veya CBEST kapsamında yürütülmez. Yine de bu kapanış disiplini, regülasyona tabi olmayan kurumlar için de güçlü bir modeldir.

Kapanışın kaliteli olabilmesi için ölçüm modelinin operasyon başlamadan yazılması gerekir. Business objective, success criteria, defensive observation noktaları ve evidence standardı sonradan belirlenirse ekipler sonucu aynı referansla değerlendiremez. Bu hazırlığın nasıl yapılacağını Red Team senaryosu yazma rehberimizde ele alıyoruz. Remediation workshop, replay ve retest eforunun teklif kapsamına dahil edilmesi de önemlidir; Red Team maliyetini etkileyen değişkenler yazımızda çalışma sonrası bu kalemlerin neden ayrı planlanması gerektiğini açıklıyoruz.

İlk 24 saat: Önce ortamı güvenli ve kanıtı kullanılabilir hale getirin

Red Team sonrası ilk refleks bütün domain'leri blocklamak, test account'larını silmek ve logları temizlemek olmamalıdır. Önce operasyonun kontrollü biçimde kapandığı doğrulanmalı, savunma analizi için gereken evidence korunmalı ve gerçek tehdit ile test aktivitesi birbirinden ayrılmalıdır.

1. Operasyonun resmen sona erdiğini teyit edin

Control Team veya engagement owner şu bilgileri yazılı olarak doğrulamalıdır:

• Active testing'in bitiş zamanı
• Red Team infrastructure'ının artık action üretmediği
• Son kullanılan source IP, domain, redirector ve callback değerleri
• Açılmış test account ve mailbox'lar
• Oluşturulan service, scheduled task, API key, OAuth consent, token veya cloud resource'lar
• Değiştirilen configuration ve geri alma durumu
• Sistemde bırakılmış olabilecek dosya, payload veya persistence artifact'leri
• Devam eden fakat Red Team ile ilişkili olmayan güvenlik olayları

Bu kayıt cleanup checklist'i olduğu kadar deconfliction kaydıdır. SOC, operasyon bittikten sonra aynı IOC'yi görmeye devam ediyorsa bunun gecikmiş telemetry, unutulmuş bir artifact veya gerçek bir üçüncü taraf activity olup olmadığını araştırabilmelidir.

2. Evidence'ı korumadan cleanup yapmayın

Test artifact'lerinin kaldırılması gerekir; fakat önce savunma analizinde kullanılacak minimum evidence korunmalıdır.

Korunması gereken veri çalışmaya göre değişse de genellikle şunları içerir:

• Red Team action log'u ve kesin timestamp'ler
• Source ve destination bilgileri
• Account, host, process, session ve cloud principal kimlikleri
• EDR raw event'leri
• Identity provider sign-in ve audit log'ları
• DNS, proxy, firewall, VPN ve network flow kayıtları
• SIEM alert ve case history
• SOAR action log'ları
• Analyst note, escalation ve karar zamanları
• Ticket, chat ve incident bridge kayıtları
• Payload hash'i ve güvenli örnek metadata'sı
• İlgili configuration snapshot'ları

Evidence'ın erişimi need-to-know modeliyle sınırlandırılmalı; sensitive data redacted veya şifreli tutulmalı; saklama süresi sözleşme, Rules of Engagement ve kurum politikasına göre belirlenmelidir. Red Team'in elde ettiği gerçek credential, personal data veya production data gereksiz yere rapora kopyalanmamalıdır.

3. Test erişimlerini ve geçici artifact'leri kontrollü biçimde kapatın

Cleanup yalnızca C2 binary'sini silmek değildir. Aşağıdaki katmanlar tek tek kontrol edilmelidir:

Red Team gerçek bir credential'a eriştiyse yalnızca parolanın değiştirilmesi yeterli olmayabilir. Active session, refresh token, Kerberos ticket, application token, SSH key veya derived secret yaşamaya devam edebilir. Credential lifecycle, erişimin hangi platformlarda kullanılabildiği dikkate alınarak kapatılmalıdır.

4. “Bunların hepsi testti” varsayımını doğrulayın

Red Team çalışması sırasında görülen her anomali Red Team'e ait olmayabilir. Test, savunma ekibinin dikkatini artırdığı için daha önce başlamış gerçek bir activity görünür hale gelebilir. Ayrıca gerçek bir saldırgan, test infrastructure'ını veya meydana gelen gürültüyü taklit edebilir.

Bu nedenle SOC şu ayrımı yapmalıdır:

1. 1Red Team'in doğruladığı action'lar
2. 2Red Team activity'sinin beklenen yan etkileri
3. 3Red Team tarafından yapılmadığı teyit edilen şüpheli activity
4. 4Kaynağı henüz bilinmeyen activity

Üçüncü ve dördüncü kategori normal Incident Response sürecine alınmalıdır. Red Team operasyonu, gerçek incident'i otomatik olarak açıklayan bir cover story değildir.

NIST'in Nisan 2025'te yayımladığı SP 800-61 Revision 3, Incident Response'u ayrı bir teknik ekip işi olarak değil, NIST CSF 2.0'ın tüm function'ları boyunca kurumsal risk yönetimine entegre bir yetenek olarak ele alır. Red Team sonrasında gerçek activity şüphesi oluşuyorsa test kapanışı ile incident yönetimi açıkça ayrılmalıdır.

İlk 24 saat kontrol listesi

İki timeline oluşturun: Saldırgan ne yaptı, savunma ne gördü?

Red Team sonrası en değerli çalışma, Red Team raporunu okumak değil; offensive ve defensive timeline'ı aynı masada birleştirmektir.

Red Team timeline'ında şu bilgiler bulunmalıdır:

• Action zamanı
• Hedef asset ve identity
• Kullanılan behavior veya ATT&CK technique/sub-technique
• Ön koşul
• Action sonucu
• Üretilmesi beklenen telemetry
• Objective'e etkisi
• Safety nedeniyle uygulanmayan action'lar

Blue Team timeline'ında ise şu anlar ayrılmalıdır:

• Telemetry'nin source'ta oluştuğu an
• Collector'a ulaştığı an
• Parser/normalizer tarafından işlendiği an
• Detection analytic'in çalıştığı an
• Alert'in oluştuğu an
• Analyst'in alert'i açtığı an
• Malicious/benign kararının verildiği an
• Incident'ın declare edildiği an
• Scope'un çıkarıldığı an
• Containment kararının ve uygulamasının zamanı

Bu iki timeline eşleştirilmeden “SOC gördü” veya “EDR yakalamadı” gibi cümleler fazla yüzeysel kalır.

Örneğin EDR event'i endpoint'te oluşmuş, data lake'e 18 dakika geç ulaşmış, SIEM rule'u beş dakikalık pencere kullandığı için correlation üretmemiş olabilir. Buradaki root cause “kural yok” değil, ingestion latency ile analytic tasarımının uyumsuzluğudur. Başka bir olayda alert zamanında oluşmuş fakat asset criticality bilgisi enrichment'a eklenmediği için düşük priority'li queue'da beklemiş olabilir. Bu da visibility değil triage ve routing problemidir.

Birleştirilmiş timeline için örnek kayıt modeli

event_id: RT-2026-042
scenario: SCN-02
attack_step: 11
attack_time_utc: "2026-07-18T19:42:16Z"
asset:
  hostname: APP-SRV-17
  criticality: high
identity:
  principal: svc-reporting
  privilege: service-account
attack:
  tactic: Lateral Movement
  technique: T1569.002
  behavior: remote-service-execution
  outcome: successful
defense:
  source_event_created: "2026-07-18T19:42:18Z"
  siem_ingested: "2026-07-18T19:42:41Z"
  alert_created: null
  analyst_opened: null
  incident_declared: null
assessment:
  prevention: failed
  visibility: passed
  detection: failed
  investigation: not_tested
  containment: not_tested
root_cause_hypothesis:
  - "Service creation telemetry mevcut ancak ilgili server grubunda analytic kapsamı yok."
evidence_refs:
  - EDR-RAW-8821
  - WIN-SYSTEM-7045-1917

Bu kayıt formatı belirli bir ürüne bağlı değildir. Önemli olan her attack step'in tek satırlık “detected/not detected” sonucundan daha zengin bir savunma durumuna sahip olmasıdır.

Detection and Response sonucu nasıl sınıflandırılmalı?

Her adım için savunma zinciri altı ayrı kontrol noktasında değerlendirilmelidir:

Bu ayrım iki yanlış sonucu önler.

Birincisi, “EDR görmüş” ifadesinin savunma başarısı sayılmasıdır. Raw telemetry'nin varlığı detection değildir. Alert'in oluşması da tek başına response değildir.

İkincisi, prevention başarısız olduğunda bütün zincirin başarısız sayılmasıdır. Red Team'in bir action'ı gerçekleştirebilmesi önemlidir; fakat kurum bunu saniyeler içinde algılayıp doğru scope'u çıkararak saldırganı critical objective'e ulaşmadan containment altına aldıysa savunmanın diğer katmanları çalışmıştır.

Red Team sonucu pass/fail yerine control-point bazında ele alındığında hangi yatırımın gerçekten gerekli olduğu daha iyi anlaşılır.

Debrief toplantısını suçlama oturumuna çevirmeyin

İlk ortak toplantının amacı “SOC neden bunu görmedi?” sorusuyla bir ekip bulmak değildir. Amaç, saldırı zincirini kanıtlarla yeniden kurmak ve savunma kararlarının hangi veriyle alındığını anlamaktır.

Toplantıda en az şu roller bulunmalıdır:

• Control Team veya engagement owner
• Red Team operator'ları
• SOC analyst ve team lead
• Detection Engineering
• Incident Response / DFIR
• Endpoint, IAM, network ve cloud owner'ları
• Etkilenen application veya business service owner'ı
• Risk ve governance temsilcisi
• Gerekli olduğunda third-party service owner

Debrief üç turda yapılabilir:

Tur 1: Blind savunma anlatımı

Önce Blue Team, Red Team'in tüm ayrıntıları açıklanmadan kendi gördüğü olayı anlatır. Hangi signal ile başladığını, nasıl scope çıkardığını ve hangi kararları verdiğini gösterir. Bu, rapora bakarak geçmişi yeniden yazma riskini azaltır.

Tur 2: Red Team reveal

Red Team başlangıç koşulunu, seçtiği attack path'i, başarısız denemeleri, alternatifleri, safety kararlarını ve objective'e nasıl ulaştığını timestamp'lerle açıklar. Yalnızca başarılı action'ların anlatılması doğru değildir; savunmanın saldırganı vazgeçirdiği veya başka route'a zorladığı anlar da kaydedilmelidir.

Tur 3: Ortak gap analizi

Her action için şu sorular sorulur:

1. 1Hangi control'ün çalışması bekleniyordu?
2. 2Beklenen data source neydi?
3. 3Telemetry gerçekten oluştu mu?
4. 4Oluştuysa pipeline'ın hangi katmanında kayboldu?
5. 5Alert oluştuysa analyst neden doğru kararı veremedi?
6. 6Containment hangi asset, identity ve session'ları kapsadı?
7. 7Aynı davranış farklı tool veya protocol ile yapılsa sonuç değişir miydi?
8. 8Bu gap yalnızca test edilen asset'te mi, benzer bütün ortamlarda mı var?

Debrief sonunda yalnızca meeting note değil, doğrulanabilir gap register oluşmalıdır.

Bulguları attack path üzerinden önceliklendirin

Red Team bulgularını yalnızca CVSS veya Critical/High/Medium etiketiyle sıralamak, zincir etkisini kaçırabilir.

Tek başına orta seviyede görünen bir misconfiguration, saldırganın privileged identity'ye ulaşmasını sağlayan merkezi bağlantı olabilir. Buna karşılık kritik severity'li bir zafiyet, güçlü segmentation nedeniyle objective'e giden hiçbir route üzerinde bulunmayabilir. İkisi de ele alınmalıdır; fakat öncelik yalnızca severity'den türetilmemelidir.

Önceliklendirmede şu değişkenler birlikte değerlendirilmelidir:

• Critical business function'a etkisi
• Attack path üzerindeki merkezi rolü
• Exploit veya abuse'un tekrar edilebilirliği
• Gerekli privilege ve precondition
• Internet, partner, employee veya assumed-breach exposure'ı
• Blast radius
• Prevention ve detection eksikliğinin birlikte bulunması
• Containment'ın gecikmesi halinde oluşacak etki
• Aynı root cause'un kaç asset veya business process'te bulunduğu
• Active threat ve kurumun threat model'iyle uyumu
• Düzeltmenin bağımlılıkları ve change riski

Attack-path öncelik matrisi

Basit bir puan modeli kullanılabilir mi?

Kurumlar karşılaştırılabilirlik için puanlama kullanabilir; ancak formül kararın yerini almamalıdır. Örnek bir model şöyle kurulabilir:

Öncelik =
  (Business Impact × 3)
  + (Attack-Path Centrality × 3)
  + (Repeatability × 2)
  + (Exposure × 2)
  + (Detection Gap × 2)
  + (Blast Radius × 2)
  - (Fix Risk × 1)

Her değer örneğin 1–5 arasında tanımlanabilir. Fakat iki önemli kural vardır:

1. 1Formülün ağırlıkları kurumun risk appetite'ına göre kalibre edilmelidir.
2. 2Safety, regulatory obligation veya aktif exploitation gibi durumlar otomatik escalation kuralına sahip olmalıdır.

Semptomu değil root cause'u kapatın

Red Team sonrası sık yapılan hata, raporda görülen tek artifact'e müdahale etmektir.

Örnek:

Gözlem: Red Team, APP-SRV-17 üzerinde geçici bir service oluşturarak code execution sağladı.

Zayıf aksiyon:
- Kullanılan binary hash'ini blockla.

Daha iyi tactical aksiyon:
- Binary'yi kaldır.
- Test credential ve session'larını revoke et.
- İlgili remote service behavior'ı için detection ekle.

Structural aksiyon:
- Service account'ın remote logon hakkını kaldır.
- Server grubundaki local administrator membership modelini düzelt.
- Privileged remote management route'larını jump host ile sınırla.
- Service creation telemetry'sini bütün server fleet'inde standardize et.
- Aynı entitlement pattern'ini benzer account'larda ara.

Hash blocklamak saldırının yalnızca testte kullanılan implementation'ına karşılık verir. Root cause ise credential privilege'i, remote access route'u, service creation yetkisi ve fleet genelindeki visibility eksikliğinin birleşimidir.

Root cause analizi üç katmanda yapılmalı

Tek bir gap bu katmanların birden fazlasına dayanabilir. “Analyst kaçırdı” ifadesi çoğu zaman root cause değildir. Analyst'e eksik context verilmiş, alert yanlış severity ile gelmiş veya runbook ilgili identity türünü kapsamamış olabilir.

Read-across analizi yapın

Red Team belirli scope'ta çalıştığı için bulunan problem yalnızca test edilen host veya account ile sınırlı kabul edilmemelidir.

Şu sorular sorulmalıdır:

• Aynı configuration başka hangi asset'lerde var?
• Aynı role template'i kaç account'a uygulanmış?
• Aynı CI/CD pattern'i başka application'larda kullanılıyor mu?
• Aynı logging policy farklı region veya tenant'larda açık mı?
• Aynı third-party access modeli başka provider'larda var mı?
• Aynı business approval açığı benzer süreçlerde bulunuyor mu?

Bir service account bulgusunu tek account'ta düzeltmek remediation'dır; bütün service account modelini incelemek kurumsal öğrenmedir.

Aksiyonları tactical, structural ve validation olarak ayırın

Her finding için tek bir “çözüm” satırı yerine üç farklı iş paketi oluşturmak daha sağlıklıdır.

Tactical containment

Riskin kısa sürede azaltılmasını hedefler:

• Exposed service'i sınırlandırmak
• Credential ve token revoke etmek
• Temporary deny veya conditional access kuralı uygulamak
• Kritik asset üzerinde ek monitoring açmak
• Vulnerable path'i feature flag ile kapatmak

Tactical aksiyon kalıcı çözüm gibi raporlanmamalıdır. Bir WAF rule veya IOC block, root cause giderilene kadar compensating control olabilir.

Structural remediation

Problemin tekrar üretildiği sistemi değiştirir:

• IAM entitlement modelini yeniden tasarlamak
• Privileged access tiering uygulamak
• Network trust boundary'yi daraltmak
• Secure baseline'ı fleet genelinde enforce etmek
• Application authorization modelini merkezileştirmek
• Log pipeline ve schema'yı düzeltmek
• Incident Response onay ve escalation sürecini güncellemek

Validation

Düzeltmenin gerçekten etkili olduğunu kanıtlar:

• Configuration verification
• Detection unit test
• Purple Team replay
• Reasonable variation testi
• Attack-path retest
• Security regression testi

Validation işi ayrı owner ve tarih taşımıyorsa ticket'ın Done olması riskin kapandığını göstermez.

Kullanılabilir bir remediation kaydı nasıl görünür?

“EDR iyileştirilecek” ifadesi plan değildir. İyi bir kayıt, problemi ve kapanış kanıtını aynı yerde tutar.

remediation_id: REM-RT-2026-017
source:
  engagement: RT-2026-Q3
  scenario: SCN-02
  attack_steps: [9, 10, 11]
finding:
  title: "Service account üzerinden server fleet'ine lateral movement"
  business_impact: "Raporlama platformundan finansal veri katmanına erişim"
  root_cause:
    people: "Privileged service identity owner'lığı tanımlı değil"
    process: "Service account access review kapsam dışında"
    technology:
      - "Remote logon hakkı gereğinden geniş"
      - "Local admin membership merkezi enforce edilmiyor"
      - "Service creation analytic server grubunda aktif değil"
risk:
  priority: critical
  attack_path_centrality: 5
  blast_radius: 4
actions:
  tactical:
    owner: "IAM Operations"
    due: "2026-08-10"
    action: "Account session'larını revoke et ve remote logon'ı sınırla"
  structural:
    owner: "PAM Program"
    due: "2026-09-30"
    action: "Service identity'yi managed credential ve tiered access modeline taşı"
  detection:
    owner: "Detection Engineering"
    due: "2026-08-22"
    action: "Remote service creation analytic ve enrichment geliştir"
  validation:
    owner: "Purple Team"
    due: "2026-10-07"
    action: "Original behavior ve iki varyasyonu replay et"
dependencies:
  - "Legacy reporting agent compatibility testi"
compensating_controls:
  - "APP-SRV segmentinden yalnızca jump host kaynaklı management trafiğine izin"
closure_evidence:
  - "IAM policy diff"
  - "Fleet entitlement query"
  - "Detection test result"
  - "Purple Team replay record"
risk_acceptance:
  required: false

Bu şema doğrudan ticketing sistemine, GRC platformuna veya basit bir spreadsheet'e uyarlanabilir. Önemli olan action, owner, due date ve closure evidence alanlarının birbirinden ayrılmasıdır.

Detection Engineering ekibi nereden başlamalı?

Red Team sonrası “her technique için bir SIEM kuralı yazalım” yaklaşımı hem gürültü üretir hem yanlış bir coverage hissi verir. Detection önce behavior, data ve karar modeli üzerinden tasarlanmalıdır.

1. Önce visibility'yi doğrulayın

Bir analytic yazmadan önce şu zinciri test edin:

Action
  -> source event
  -> sensor/agent
  -> collector
  -> transport
  -> parser
  -> normalized schema
  -> enrichment
  -> analytic
  -> alert
  -> queue
  -> analyst

Event source'ta yoksa SIEM kuralı yazmak problemi çözmez. Event var fakat önemli field parse edilmiyorsa yalnızca raw log saklanmış olur. Alert oluşuyor fakat asset owner, identity privilege veya business criticality ile zenginleştirilmiyorsa analyst doğru priority'yi belirleyemeyebilir.

MITRE ATT&CK artık yalnızca technique açıklamaları sunmaz; detection strategy, analytic ve data component katmanlarıyla belirli behavior'ların hangi telemetry ve correlation üzerinden ele alınabileceğine dair savunma dili sağlar. Örneğin güncel DET0419 Detection Strategy sayfası DNS behavior'ını yalnızca bir IOC listesiyle değil, process ve network data component'lerini birleştiren analytics ve ayarlanabilir threshold'larla açıklar. Bu yapı doğrudan kopyalanacak hazır kural değildir; kurumun data modeline uyarlanacak bir detection hypothesis kaynağıdır.

2. Tool yerine behavior'ı hedefleyin

Red Team belirli bir binary kullandı diye yalnızca filename, hash veya User-Agent aramak kolaydır. Ancak saldırgan implementation'ı değiştirdiğinde detection kaybolur.

Daha dayanıklı analytic şu bileşenleri bir araya getirir:

• Beklenmeyen parent-child process ilişkisi
• Identity'nin normal rolüyle uyuşmayan action
• Yönetim protocol'ünün alışılmadık source'tan kullanılması
• Service veya task oluşturma ile hemen ardından başlayan network connection
• Kısa zaman aralığında credential access ve lateral movement zinciri
• Crown jewel asset üzerinde nadir görülen administrative action

IOC'ler yine değerlidir; özellikle hızlı containment ve historical search için kullanılır. Fakat kalıcı detection programının tamamı IOC'ye bağlanmamalıdır.

3. Her detection için test edilebilir bir sözleşme yazın

test_case_id: DET-RT-031
name: "Remote service creation on protected server"
attack_reference:
  technique: T1569.002
  source_step: RT-2026-Q3/SCN-02/11
preconditions:
  - "Test identity is not in approved deployment principals"
  - "Target belongs to protected-server asset group"
expected_telemetry:
  - "Windows Service Control Manager service creation event"
  - "Process creation with service process lineage"
expected_detection:
  severity: high
  max_alert_latency_seconds: 120
  required_fields:
    - source_identity
    - target_hostname
    - service_name
    - image_path
    - asset_criticality
expected_response:
  - "Analyst validates service legitimacy"
  - "Identity and neighboring targets are scoped"
  - "Containment owner is paged"
pass_conditions:
  - "Telemetry arrives with required fields"
  - "Alert is created within latency objective"
  - "Runbook produces correct scope query"
  - "No approved deployment activity is classified as malicious"

Bu sözleşme detection'ın yalnızca query metnini değil, data ve response bağımlılıklarını da test eder.

4. Güvenli bir Sigma başlangıç örneği

Aşağıdaki kural production'a doğrudan kopyalanacak nihai analytic değildir. Red Team sırasında geçici veya kullanıcı tarafından yazılabilir path'ten oluşturulan service behavior'ı görülmüşse, log schema ve legitimate deployment araçları dikkate alınarak uyarlanabilecek başlangıç örneğidir:

title: Service Creation From User-Writable or Temporary Path
id: 5da9b726-f696-4e7e-9ae1-67d2019e8b65
status: test
description: Detects a newly installed Windows service whose image path points to commonly user-writable or temporary locations.
references:
  - https://attack.mitre.org/techniques/T1569/002/
logsource:
  product: windows
  service: system
detection:
  selection_event:
    Provider_Name: 'Service Control Manager'
    EventID: 7045
  selection_path:
    ImagePath|contains:
      - '\Windows\Temp\'
      - '\Users\Public\'
      - '\AppData\Local\Temp\'
  condition: selection_event and selection_path
falsepositives:
  - Authorized software deployment packages using temporary staging paths
  - Legacy installers approved by change management
level: high
tags:
  - attack.lateral_movement
  - attack.t1569.002

Kuralın kaliteli hale gelmesi için en az şu çalışmalar yapılmalıdır:

• Gerçek environment field adlarına dönüştürme
• Authorized software deployment principal ve source'larını belirleme
• Asset criticality enrichment
• Service name, signer, hash ve parent telemetry ile correlation
• Baseline ve false positive analizi
• Positive ve negative test
• Rule owner, version ve rollback tanımı
• Alert routing ve runbook entegrasyonu

Yalnızca Sigma dosyasının repository'ye eklenmesi detection'ın çalıştığını kanıtlamaz. Event üretildiğinde uçtan uca alert ve analyst akışı replay edilmelidir.

Investigation ve containment playbook'larını güncelleyin

Detection'ın görevi yalnızca alarm üretmek değildir. Analyst'in doğru kararı verebilmesi için alert'in bir investigation path'i olmalıdır.

Her Red Team gap'i için playbook şu alanları içermelidir:

1. 1Signal doğrulama: Event gerçekten oluştu mu, data eksik mi?
2. 2Entity context: Account privilege'i, asset criticality'si, owner ve normal behavior nedir?
3. 3Scope query: Aynı identity, hash, service, source ve destination başka nerede görüldü?
4. 4Sequence analizi: Öncesinde credential access, discovery veya initial access sinyali var mı?
5. 5Containment seçenekleri: Host isolate, account disable, session revoke, token revoke, network block veya application action hangisi gerekli?
6. 6Approval: Production impact yaratacak action için kim onay verir?
7. 7Escalation: Hangi koşulda DFIR, legal, privacy, fraud veya business continuity sürece dahil olur?
8. 8Recovery: Containment sonrası güvenli dönüş ve monitoring nasıl yapılır?

Containment tek bir asset'e indirgenmemeli

Red Team bir service account ile beş server'a ilerlediyse yalnızca son host'u isolate etmek yeterli değildir. Şunlar birlikte değerlendirilebilir:

• Identity'nin aktif session ve token'ları
• Aynı credential'ın kullanıldığı diğer service'ler
• Account'ın erişebildiği fakat henüz dokunulmamış asset'ler
• Parent-child identity ilişkileri
• Cloud ve on-premises federation bağlantıları
• Aynı source host'tan başlayan diğer connection'lar
• Credential'ın backup, automation veya deployment sistemlerindeki kopyaları

Containment'ın hedefi görünen son IOC'yi susturmak değil, saldırganın sürdürebileceği control plane'i daraltmaktır.

Production güvenliği için containment rehearsal yapın

Bazı ekipler kritik bir identity'yi disable etmeleri gerektiğini bilir fakat iş etkisinden çekindiği için karar gecikir. Red Team sonrası şu sorular tabletop veya Purple Team ile çalışılmalıdır:

• Bu service account disable edilirse hangi service durur?
• Break-glass access gerçekten çalışıyor mu?
• Token revoke işlemi kaç dakikada bütün platformlara yansır?
• Host isolation yönetim bağlantısını da kesiyor mu?
• Network block backup veya monitoring akışını etkiliyor mu?
• Cloud key rotate edilince dependent workload nasıl güncellenir?

Containment yeteneği, yalnızca butona sahip olmak değil; butona ne zaman ve hangi etkiyle basılacağını bilmektir.

Control domain'lerine göre Red Team sonrası teknik aksiyonlar

Her attack path farklıdır. Yine de savunma backlog'u çoğunlukla aşağıdaki domain'lerde toplanır.

Identity ve Active Directory

• Privileged group membership ve nested group read-across
• Stale, shared ve owner'ı bilinmeyen account'lar
• Service account logon rights ve credential lifecycle
• Local administrator standardı
• Delegation ve privilege path'leri
• Tier-0/Tier-1/Tier-2 ayrımı
• Privileged session exposure
• MFA coverage ve phishing-resistant authentication
• Legacy protocol ve authentication fallback'leri
• Hybrid identity ile cloud role zincirleri

Burada yalnızca Red Team'in kullandığı account'ı kapatmak yerine attack graph üzerindeki alternatif yollar değerlendirilmelidir. Active Directory odaklı Red Team'de en sık zincirlenen zafiyetler yazımız, tekil configuration hatalarının nasıl privilege path'e dönüştüğünü ayrıntılı biçimde ele alıyor.

Endpoint ve server

• EDR coverage, health ve policy consistency
• Tamper protection
• Script, command-line ve process telemetry
• Application control
• Credential material exposure
• Remote administration route'ları
• Service, task, WMI ve management event'leri
• Secure configuration baseline
• Unsupported operating system ve agent version'ları

Fleet coverage sayısı tek başına yeterli değildir. Agent installed görünürken event üretmiyor, policy almıyor veya isolated network'ten collector'a erişemiyor olabilir. Health check, gerçek telemetry üretimiyle doğrulanmalıdır.

Network

• Trust boundary ve segmentation
• East-west traffic visibility
• Administrative protocol source restriction
• DNS, proxy ve egress logging
• Cloud-to-on-premises route'lar
• Third-party ve remote access
• Management plane separation
• Firewall rule owner ve expiry mekanizması

Red Team'in bir route'u kullanmamış olması o route'un güvenli olduğunu göstermez. Objective'e ulaşmak için en uygun path seçilmiş olabilir. Remediation sırasında benzer route'lar read-across ile aranmalıdır.

Cloud ve SaaS

• IAM role ve policy kombinasyonları
• Long-lived access key'ler
• Workload identity ve metadata exposure
• Cross-account/cross-tenant trust
• OAuth application ve consent
• Audit log coverage ve retention
• Control plane action detection'ları
• Public exposure ve egress
• CI/CD identity'leri
• Secret manager erişimi

Cloud containment yalnızca access key silmeye indirgenmemelidir. Active session, federation, role chaining ve workload credential'ları ayrı lifecycle'lara sahip olabilir.

Application ve API

• Authorization ve tenant boundary
• Privileged business action'lar
• Session ve token invalidation
• Audit trail yeterliliği
• Admin function exposure
• Secret ve integration credential yönetimi
• High-risk workflow için step-up control
• Abuse ve anomaly detection

Red Team bir web application üzerinden initial access sağladıysa düzeltme yalnızca WAF rule olmamalıdır. Root cause source code, authorization tasarımı veya deployment configuration içindeyse kaynak kod analizi ve hedefli application retest gerekebilir.

SOC ve Incident Response

• Data source completeness
• Parser ve field quality
• Enrichment ve asset context
• Detection logic ve threshold
• Alert severity ve routing
• Analyst playbook
• Case management
• Escalation ve on-call modeli
• Containment automation
• Evidence handling
• Executive communication

Savunma ekibi yalnızca yeni use case sayısını artırmak yerine attack path boyunca gerekli kararları destekleyen minimum kaliteli signal setini oluşturmalıdır.

MITRE ATT&CK mapping nasıl kullanılmalı, nasıl kullanılmamalı?

MITRE ATT&CK ortak dil sağlar. Red Team action'larını tactic, technique ve sub-technique düzeyinde map etmek; detection owner, data component ve test case bağlamak için değerlidir.

Fakat şu cümle yanıltıcıdır:

Neden?

• Test bütün ATT&CK matrix'ini kapsamaz.
• Aynı technique farklı platform ve implementation'larda farklı telemetry üretir.
• Bir technique'in tek varyasyonunu görmek tüm varyasyonları görmek değildir.
• Raw telemetry, detection ve response aynı şey değildir.
• Technique sayısı business objective'e ulaşma riskini göstermez.

Daha doğru mapping şu ilişkileri kurar:

Attack step
  -> ATT&CK behavior
  -> gerekli data component
  -> source ve field
  -> detection hypothesis
  -> analytic/test case
  -> alert/runbook
  -> owner
  -> replay sonucu

MITRE'ın Adversary Emulation Plans kaynağı da ATT&CK'i yalnızca checklist olarak değil, threat reporting'den türetilen davranışların zincirlenmesi ve savunmaların ölçülmesi için kullanır. Bu yüzden ATT&CK mapping'in değeri renkli heatmap'ten değil, test edilebilir savunma backlog'una dönüşmesinden gelir.

Purple Team replay nasıl planlanmalı?

Purple Team replay, Red Team raporunun sunumunu yeniden yapmak değildir. Offensive action ile defensive control'ün aynı oturumda, gözlemlenebilir ve tekrarlanabilir biçimde çalıştırılmasıdır.

ECB'nin Ocak 2025 tarihli TIBER-EU Purple Teaming Guidance dokümanı closure phase'teki Purple Team'i Red Team'in gizli operasyonunun yerine koymaz. Onu, seçilmiş zafiyetleri, test edilemeyen adımları, alternatif senaryoları, PoC'leri ve beklenen remediation'ı ortaklaşa inceleyen bir öğrenme aşaması olarak konumlandırır.

Replay sırası

1. 1Original action'ı yeniden üretin. İlk bulgunun teknik olarak doğru anlaşılması sağlanır.
2. 2Telemetry'yi source'tan doğrulayın. Event'in nerede ve hangi field'larla oluştuğu görülür.
3. 3Pipeline'ı izleyin. Ingestion, parsing, normalization ve enrichment doğrulanır.
4. 4Detection'ı çalıştırın. Alert latency, severity ve routing ölçülür.
5. 5Analyst investigation'ını yürütün. Runbook ve scope query test edilir.
6. 6Containment kararını rehearse edin. Gerçek impact yaratmadan karar ve onay akışı sınanır.
7. 7Makul varyasyonları deneyin. Tool, path, account, protocol veya sequence değiştiğinde analytic'in davranışı görülür.
8. 8Negative test yapın. Legitimate administration activity'sinin yanlış alarm üretip üretmediği kontrol edilir.
9. 9Sonucu version'layın. Rule, parser, data source ve test case sürümü kaydedilir.

Replay başarı tablosu

Purple Team, Red Team ve BAS'in hangi farklı soruları ölçtüğünü Purple Team, Red Team ve BAS karşılaştırmamızda ayrıntılı biçimde ele alıyoruz.

BAS ve detection regression nerede devreye girer?

Red Team belirli bir tarihte gerçekçi bir attack path'i ortaya çıkarır. Purple Team gap'i anlamaya ve control'ü iyileştirmeye yardım eder. BAS veya başka bir güvenli validation mekanizması ise seçilmiş test case'lerin düzenli tekrarlanmasını sağlayabilir.

Örnek lifecycle:

Red Team finding
  -> Purple Team replay
  -> detection/fix geliştirme
  -> positive + negative test
  -> test case repository
  -> haftalık/aylık regression
  -> drift alarmı
  -> periyodik adversary emulation

Regression test şu değişikliklerden sonra özellikle değerlidir:

• EDR agent veya policy upgrade
• SIEM migration
• Parser/schema değişikliği
• Cloud log source değişimi
• Network sensor relocation
• IAM policy redesign
• SOAR playbook güncellemesi
• Major operating system build değişimi
• Asset group veya routing değişikliği

BAS sonucu “kontrol yeşil” dedi diye Red Team ihtiyacı ortadan kalkmaz. Otomatik test, tanımlı davranışın bilinen koşullarda tekrarını ölçer. İnsan operator'ın belirsizlik içinde route seçmesini, savunmaya adapte olmasını ve business objective'e zincir kurmasını aynı biçimde ölçmez.

Retest neyi doğrulamalı?

Red Team sonrası bütün doğrulamalar aynı değildir.

Bir detection replay'in başarılı olması privilege problemine çözüm değildir. Bir account'ın yetkisini kaldırmak da SOC'un benzer behavior'ı görebildiğini kanıtlamaz. Prevention ve detection aksiyonları ayrı doğrulanmalıdır.

Pentest bulgularında olduğu gibi retest'in doğru zamanda başlatılması gerekir. Fix'in henüz deploy edilmediği, scope'un hazır olmadığı veya test data'nın eksik olduğu durumda yapılan kontrol yanlış kapanış üretebilir. Retest ne zaman yapılmalı, ne zaman beklemeli? rehberimizde readiness ve closure evidence yaklaşımını daha ayrıntılı bulabilirsiniz.

Bir finding ne zaman gerçekten kapanmış sayılır?

Ticket'ın Resolved olması yeterli değildir. Kapanış için aşağıdaki kanıt seti kullanılabilir:

1. 1Root cause açıkça tanımlandı.
2. 2Tactical exposure azaltıldı veya gerekçeli biçimde kabul edildi.
3. 3Structural fix ilgili bütün scope'a uygulandı.
4. 4Read-across analizi tamamlandı.
5. 5Configuration veya code değişikliği version/diff ile kanıtlandı.
6. 6Gerekli telemetry ve detection çalışıyor.
7. 7Investigation ve containment runbook'u güncellendi.
8. 8Positive test geçti.
9. 9Negative test kabul edilebilir false positive seviyesi gösterdi.
10. 10Original attack behavior ve makul varyasyon replay edildi.
11. 11Risk owner sonucu kabul etti.
12. 12Regression kaydı oluşturuldu.

Her finding bütün bu maddeleri gerektirmeyebilir. Örneğin yalnızca process eksikliği için code diff beklenmez. Ancak closure criteria finding açılırken tanımlanmalıdır; sonunda geriye dönük icat edilmemelidir.

0–7–30–60–90 günlük Red Team sonrası yol haritası

Takvim, kurumun riskine ve change kapasitesine göre değişir. Aşağıdaki plan evrensel SLA değil, uygulanabilir bir başlangıç modelidir.

0–7 gün: Hızlı risk azaltma

• Critical attack path üzerindeki exposed account ve route'ları sınırlandırın.
• Test artifact'lerini kaldırın ve session/token cleanup'ını doğrulayın.
• Detection olmayan kritik action'lar için temporary monitoring oluşturun.
• Red ve Blue timeline'larını birleştirin.
• Business owner'a teknik olmayan etki anlatımını hazırlayın.
• Fix uygulanana kadar compensating control ve residual risk'i yazın.

8–30 gün: Kök neden ve backlog

• Findings'i attack path ve business impact ile gruplayın.
• People, process ve technology root cause'larını ayırın.
• Scope dışındaki benzer alanlar için read-across query'leri çalıştırın.
• Tactical ve structural work package'leri oluşturun.
• Detection test case'lerini version-controlled repository'ye alın.
• Yüksek öncelikli gap'ler için Purple Team replay başlatın.

31–60 gün: Uygulama

• IAM, network, endpoint, cloud ve application değişikliklerini change process'e alın.
• Logging, parser, enrichment ve rule zincirini uçtan uca doğrulayın.
• Analyst runbook ve containment onaylarını güncelleyin.
• Tabletop ve controlled containment rehearsal yapın.
• Fix'in yalnızca test asset'ine değil gerekli population'a yayıldığını ölçün.

61–90 gün: Kanıt ve sürdürülebilirlik

• Original behavior ve reasonable variation'ları replay edin.
• Attack-path retest ile zincirin gerçekten kırıldığını doğrulayın.
• Detection regression schedule'ını başlatın.
• Açık residual risk'leri yönetim seviyesinde kabul veya eskale edin.
• Bir sonraki exercise için threat scenario backlog'u oluşturun.

RACI: Kim hangi işin sahibi olmalı?

Red Team sonrası bütün ticket'ların SOC'a atanması doğru değildir. SOC her teknolojinin owner'ı değildir; savunma sonucu çok sayıda ekibin ortak ürünüdür.

RACI kurum yapısına göre değiştirilebilir. Değişmemesi gereken ilke, aksiyonun gerçek uygulama yetkisine sahip owner'a atanmasıdır.

Red Team sonrası hangi metrikler izlenmeli?

“Toplam 47 bulgunun 39'u kapandı” tek başına iyi bir yönetim metriği değildir. Sekiz düşük etkili madde kapanırken objective'e giden merkezi identity gap'i açık kalmış olabilir.

Timeline metrikleri

Savunma timeline'ı aşağıdaki timestamp'lerle ölçülebilir:

T0 = Offensive action başladı
T1 = İlk gerekli telemetry source'ta oluştu
T2 = Telemetry merkezi platforma ulaştı
T3 = Alert oluştu
T4 = Analyst incelemeye başladı
T5 = Activity doğru sınıflandırıldı
T6 = Incident declare edildi
T7 = Scope yeterli seviyeye ulaştı
T8 = Containment kararı verildi
T9 = Containment tamamlandı

Bunlardan şu süreler türetilebilir:

• Telemetry latency: T2 - T1
• Alert latency: T3 - T0
• Analyst pickup: T4 - T3
• Qualification time: T5 - T4
• Time to Scope: T7 - T5
• Decision latency: T8 - T6
• Containment execution: T9 - T8
• End-to-end containment: T9 - T0

Her metric için tek ve evrensel “iyi süre” yoktur. Identity abuse, ransomware precursor, low-and-slow data collection ve web application attack aynı hız beklentisine sahip değildir. Hedef süre business impact ve attack progression ile tanımlanmalıdır.

Remediation metrikleri

• Critical attack-path gap kapanış süresi
• Root cause tanımlanma süresi
• Tactical control'den structural fix'e geçiş süresi
• Read-across tamamlanma oranı
• Replay edilen yüksek öncelikli action oranı
• Replay'de ilk seferde geçen control oranı
• Detection regression kapsamı
• Reopened finding oranı
• Compensating control altında bekleyen residual risk sayısı
• Owner veya due date'i olmayan aksiyon sayısı

Kalite metrikleri

• Zorunlu field'ları eksiksiz telemetry oranı
• Detection'ın tool-specific IOC'ye bağımlılık oranı
• Alert'ten doğru scope'a ulaşma oranı
• False positive nedeniyle kapanan alert oranı
• Containment playbook'unun gerekli bütün identity/session türlerini kapsama oranı
• Production değişikliği sonrasında bozulan regression test sayısı

Metriklerin amacı savunma ekibini cezalandırmak değil, sistemdeki gecikmenin ve kalite kaybının nerede oluştuğunu göstermektir.

Yönetim kuruluna ne anlatılmalı?

Yönetim sunumu yalnızca screenshot, tool adı ve ATT&CK heatmap'ten oluşmamalıdır. Şu beş soruya cevap vermelidir:

1. 1Hangi critical business function test edildi?
2. 2Red Team hangi attack path ile ne kadar ilerleyebildi?
3. 3Savunma hangi aşamada çalıştı, hangi aşamada yetersiz kaldı?
4. 4İlk olarak hangi business risk azaltılacak?
5. 5Kalan risk ne zaman ve hangi kanıtla yeniden değerlendirilecek?

İyi bir yönetim özeti şu formatta olabilir:

Objective:
Yetkisiz bir dış kaynaktan başlayarak ödeme onay fonksiyonunu etkileyebilme.

Sonuç:
Red Team, exposed identity akışından standard user access elde etti; service account privilege path'i üzerinden finans uygulamasına ulaştı. Ödeme işlemi gerçekleştirilmedi, önceden tanımlı flag ile impact güvenli biçimde doğrulandı.

Savunma sonucu:
Initial access alert'i oluştu fakat düşük severity ile yönlendirildi. Lateral movement telemetry üretti, analytic çalışmadı. Critical application erişimi application audit log'unda görüldü fakat SOC'a aktarılmadı.

İlk risk azaltma:
Identity route sınırlandı, ilgili session'lar revoke edildi ve application audit log'u merkezi platforma alındı.

Kalıcı plan:
Service identity modelinin yeniden tasarlanması, üç detection use case'i, containment playbook'u ve 60 gün içinde Purple Team replay.

Residual risk:
Legacy agent bağımlılığı nedeniyle iki server 30 gün compensating control altında kalacak; risk owner onayı mevcut.

Bu anlatım teknik ayrıntıyı saklamaz; onu karar verilebilir business risk'e dönüştürür.

En sık yapılan 12 hata

1. Raporu doğrudan ticket listesine çevirmek

Attack path ve ortak root cause kaybolur. Önce timeline ve gap analizi yapılmalıdır.

2. Her şeyi SOC'a atamak

Identity, network, application ve platform owner'ları kendi control alanlarının sorumluluğunu taşımalıdır.

3. Yalnızca IOC blocklamak

Hash, domain veya IP hızlı fayda sağlar; behavior ve root cause kapanmadıkça kalıcı savunma oluşmaz.

4. “Log vardı” demeyi detection başarısı saymak

Visibility, detection, investigation ve response ayrı ayrı ölçülmelidir.

5. Yalnızca Red Team'in başarılı adımlarına bakmak

Savunmanın operator'ı route değiştirmeye zorladığı anlar da güçlü control kanıtıdır.

6. CVSS ile Red Team backlog'unu sıralamak

Attack-path centrality, business impact ve blast radius ayrıca değerlendirilmelidir.

7. Tek asset'i düzeltip fleet'i unutmamak

Her bulgu için read-across sorusu sorulmalıdır.

8. Detection rule'u yazıp uçtan uca test etmemek

Rule repository'de olabilir fakat data gelmiyor, routing çalışmıyor veya analyst runbook'u eksik olabilir.

9. Positive test yapıp negative test yapmamak

Detection test activity'sini görürken legitimate deployment'ı sürekli alarm üretiyor olabilir.

10. Compensating control'ü kalıcı fix gibi kapatmak

Temporary control için expiry, owner ve residual risk kaydı bulunmalıdır.

11. Red Team'i hemen aynı senaryoyla tekrar etmek

Önce fix ve replay tamamlanmalıdır. Aksi halde bütçe bilinen gap'i yeniden kanıtlamak için harcanır.

12. Sonucu kişi performansına indirgemek

Red Team, process ve technology ile birlikte insan kararını ölçer. Suçlayıcı ortam, gerçek gap'lerin saklanmasına neden olur.

Red Team sonrası aksiyon planı için tek sayfalık kontrol listesi

Operasyon kapanışı

• [ ] Active testing bitişi teyit edildi.
• [ ] Artifact ve access envanteri alındı.
• [ ] Evidence korundu.
• [ ] Test account, token ve session'lar kapatıldı.
• [ ] Persistence ve temporary rule'lar temizlendi.
• [ ] Unattributed activity ayrı hunt/incident olarak değerlendirildi.

Analiz

• [ ] Red ve Blue timeline birleştirildi.
• [ ] Her attack step için prevention/visibility/detection/investigation/containment sonucu yazıldı.
• [ ] Başarılı savunma noktaları kaydedildi.
• [ ] Root cause people/process/technology olarak ayrıldı.
• [ ] Read-across kapsamı belirlendi.

Planlama

• [ ] Bulgular attack path ve business impact ile önceliklendirildi.
• [ ] Tactical, structural ve validation işleri ayrıldı.
• [ ] Her aksiyona owner, tarih, bağımlılık ve kapanış kanıtı atandı.
• [ ] Compensating control ve residual risk yazıldı.
• [ ] Risk acceptance yetkili owner tarafından verildi.

Doğrulama

• [ ] Telemetry source'tan analyst'e kadar test edildi.
• [ ] Detection positive ve negative testten geçti.
• [ ] Investigation ve containment runbook'u replay edildi.
• [ ] Original behavior ve reasonable variation doğrulandı.
• [ ] Regression test case'i oluşturuldu.
• [ ] Attack-path retest sonucu yönetim raporuna işlendi.

SECNODEX Red Team sonrası süreci nasıl ele alır?

SECNODEX'te Red Team teslimatını yalnızca attack narrative ve bulgu listesiyle sınırlamayız. Çalışmanın başında tanımlanan business objective'i, operation sırasında izlenen attack path'i ve savunmanın verdiği karşılığı aynı modelde ele alırız.

OSCP ve OSWE yetkinliklerine sahip uzmanlarımızın yürüttüğü çalışmalarda teknik evidence'ın yanında şu çıktıları hedefleriz:

• Timestamp'li attack timeline
• Trust boundary ve attack-path analizi
• Prevention, visibility, detection ve response değerlendirmesi
• Root cause ve read-across önerileri
• Tactical ve structural remediation ayrımı
• MITRE ATT&CK mapping
• Purple Team replay için öncelikli test case'ler
• Retest ve kapanış kanıtı beklentileri
• Teknik ekip ve yönetim için ayrıştırılmış raporlama

Buradaki amaç mümkün olduğunca uzun bulgu listesi üretmek değildir. Kurumun critical function'larına giden yolları, bu yollardaki control gap'lerini ve hangi iyileştirmenin saldırı zincirini gerçekten kıracağını görünür hale getirmektir.

SECNODEX Red Team hizmeti kapsamında operasyon tasarımı, Rules of Engagement, teknik execution, savunma değerlendirmesi ve çalışma sonrası validation beklentileri scope aşamasında birlikte planlanır. Böylece remediation ve replay, rapor tesliminden sonra sonradan eklenen belirsiz işler olmaktan çıkar.

Sonuç: Raporu kapatmayın, saldırı yolunu kapatın

Red Team sonrası savunma ekibinin önündeki asıl iş, raporda bulunan her satırı bir ticket'a dönüştürmek değildir. Saldırının neden mümkün olduğunu, hangi control'ün hangi aşamada yetersiz kaldığını ve kurumun aynı davranışla yeniden karşılaştığında daha iyi bir sonuç üretip üretemeyeceğini ortaya koymaktır.

İyi bir kapanış süreci:

• Evidence'ı korur ve test artifact'lerini güvenli biçimde temizler.
• Red Team ile Blue Team timeline'ını birleştirir.
• Visibility, detection ve response'u birbirinden ayırır.
• Bulguları attack path ve business impact ile önceliklendirir.
• Semptom yerine root cause'u ve benzer ortamları ele alır.
• Tactical kontrolü structural remediation'dan ayırır.
• Owner, tarih ve kapanış kanıtı belirler.
• Purple Team replay ve retest ile sonucu yeniden doğrular.
• Öğrenilenleri regression programına taşır.

Red Team'in değeri saldırganın hedefe ulaşıp ulaşmamasıyla sınırlı değildir. Gerçek değer, kurumun bu bilgiyi kalıcı savunma yeteneğine dönüştürmesinde ortaya çıkar.

Kurumunuz için attack path, detection and response değerlendirmesi ve çalışma sonrası uygulanabilir remediation planı içeren bir Red Team kapsamı oluşturmak isterseniz SECNODEX ile iletişime geçebilirsiniz.

Kaynaklar ve ileri okuma

• NIST SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NIST Cybersecurity Framework 2.0
• ECB — TIBER-EU Remediation Plan Guidance, January 2025
• ECB — TIBER-EU Purple Teaming Guidance, January 2025
• Bank of England — CBEST Implementation Guide
• MITRE ATT&CK — Adversary Emulation Plans
• MITRE ATT&CK — Detection Strategies