Oltalama Simülasyonu Ayrı, Red Team Ayrı · Phishing vs Red Team

Bir kurum çalışanlarına kontrollü bir e-posta gönderiyor. Mesaj içindeki linke tıklayanların oranı ölçülüyor, kullanıcılar eğitim sayfasına yönlendiriliyor ve birkaç hafta sonra yönetim sunumuna şu sonuç yazılıyor:

Oysa yapılan şey bir oltalama simülasyonu.

Ne kurumsal bir objective belirlenmiş ne attack path ilerletilmiş ne de SOC'un initial access sonrasındaki davranışları tespit edip edemediği sınanmış. Endpoint üzerinde execution gerçekleşmemiş, identity abuse denenmemiş, internal discovery ve lateral movement yapılmamış, kritik iş fonksiyonuna erişim ölçülmemiş. Yüzde 6 click rate'in düşük mü yüksek mi olduğu bile gönderilen e-postanın zorluk seviyesi ve çalışan context'i bilinmeden yorumlanmış.

Tersi de yaşanıyor. Red Team engagement'ında hedefli bir phishing scenario kullanılıyor. E-posta güvenlik kontrolünden geçiyor, kullanıcı linke tıklıyor ve kontrollü initial access kanıtı oluşuyor. Kurum, çalışmayı yalnız “farkındalık testi” olarak raporluyor. Böylece e-mail gateway, identity, endpoint, SOC, incident response ve containment zincirinde üretilen asıl bulgular görünmez hale geliyor.

İki çalışmada da bir mesaj veya link bulunabilir. Ayrım kullanılan araçta değil, sorulan soruda başlar.

Bu yazıda phishing vs red team ayrımını yalnız tanım üzerinden değil, scope, Rules of Engagement, payload güvenliği, employee privacy, SOC visibility, metric, raporlama ve satın alma kriterleri üzerinden kuracağız.

Oltalama simülasyonu ile Red Team neden karıştırılıyor?

Karışıklığın üç temel nedeni vardır.

İlki, her iki çalışmada da social engineering kullanılabilmesidir. MITRE ATT&CK, phishing'i T1566 altında Initial Access tekniği olarak ele alır ve attachment, link, third-party service ve voice alt tekniklerini ayırır. Bu sınıflandırma phishing'in adversary behavior içindeki yerini gösterir. Her phishing çalışmasının Red Team olduğu anlamına gelmez.

İkincisi, birçok hizmet tanımının activity üzerinden yazılmasıdır:

E-posta gönderilecek
Link kullanılacak
Tıklayanlar ölçülecek
Rapor hazırlanacak

Bu liste çalışmanın amacını açıklamaz. Aynı e-posta activity'si iki farklı engagement'ta çok farklı sorulara cevap verebilir.

Üçüncüsü, “gerçekçi görünme” ile “adversary emulation” kavramlarının birbirine karıştırılmasıdır. Bir e-postanın kurumsal şablona benzemesi veya domain'in ikna edici olması Red Team kapsamı oluşturmaz. Red Team'de gerçekçilik objective, threat profile, attack path, savunma görünürlüğü ve operational constraint'lerle birlikte kurulur.

Tek tabloda temel fark

Oltalama simülasyonu gerçekte neyi ölçer?

İyi tasarlanmış bir oltalama simülasyonu “kaç kişi kandı?” sorusuna indirgenmez. İnsanların, süreçlerin ve mesaj güvenliği kontrollerinin birlikte nasıl davrandığını gösterir.

1. Şüpheli mesajı fark etme davranışı

Çalışan şu sinyalleri değerlendirebiliyor mu?

• Sender ve reply-to uyumsuzluğu
• Beklenmeyen urgency
• Olağan dışı payment veya credential talebi
• Link destination ile görünen metin farkı
• Beklenmeyen attachment
• İş süreci dışında onay isteği
• Third-party service üzerinden gelen beklenmeyen paylaşım
• Voice veya collaboration channel üzerinden baskı

Ama her campaign aynı zorlukta değildir. Açık yazım hataları, alakasız konu ve dış sender banner'ı taşıyan bir mesajla, çalışanın günlük iş akışına tam oturan hedefli bir mesajın click rate'i doğrudan karşılaştırılamaz.

NIST Phish Scale tam olarak bu problemi ele alır. Click ve report oranlarını yorumlarken e-postadaki observable cue sayısını ve çalışan için taşıdığı premise alignment seviyesini dikkate alır. Bir campaign'in yüzde 3 click rate üretmesi tek başına “olgunluk yüksek” sonucu vermez. Mesaj çok kolaysa yüzde 3 bile beklenenden kötü olabilir. Zor ve güçlü context'e sahip başka bir scenario'da yüzde 8 farklı anlam taşıyabilir.

2. Doğru kanaldan bildirme davranışı

Çalışanın linke tıklamaması önemlidir. Fakat saldırının kurumsal ölçekte durdurulabilmesi için mesajı hızla bildirmesi de gerekir.

Report action şu sonuçları tetikleyebilmelidir:

Çalışan mesajı bildirir
        ↓
Mail security veya SOC olayı alır
        ↓
Message ID, sender, URL ve attachment indicator çıkarılır
        ↓
Benzer mesajlar tenant genelinde aranır
        ↓
Gerekirse purge veya quarantine uygulanır
        ↓
Etkileşim ve downstream activity araştırılır

Bu nedenle report rate ve time-to-first-report, click rate kadar değerlidir. NCSC de olumlu security culture için yalnız hataya değil, başarılı report davranışına odaklanan metric'leri önerir.

3. Reporting channel'ın kullanılabilirliği

Kullanıcı mesajı şüpheli bulsa bile ne yapacağını bilmiyorsa human control tamamlanmış sayılmaz.

Test edilmesi gerekenler:

• Mail client içinde report button var mı?
• Mobile client'ta aynı capability çalışıyor mu?
• Shared mailbox ve external user senaryosu destekleniyor mu?
• Report sonrası kullanıcıya anlaşılır feedback veriliyor mu?
• SOC ticket'ı doğru priority ve context ile açılıyor mu?
• Bildirilen mesaj güvenli biçimde header ve attachment bilgisiyle taşınıyor mu?
• Help desk ile SOC arasında escalation path tanımlı mı?

Bir campaign'de çalışanların mesajı reply ederek güvenlik ekibine forward etmesi, report davranışı var gibi görünebilir. Fakat forward işlemi original header ve attachment context'ini bozuyorsa investigation yavaşlayabilir.

4. E-mail security kontrollerinin davranışı

Oltalama simülasyonu yalnız çalışanı ölçmemelidir. Mesajın delivery path'i de görünür olmalıdır:

• SPF, DKIM ve DMARC sonucu
• Secure email gateway verdict'i
• URL rewriting veya sandbox sonucu
• Attachment detonation
• External sender banner
• Impersonation ve lookalike detection
• Tenant-wide campaign clustering
• Post-delivery remediation

Ancak campaign infrastructure'ı baştan allowlist'e eklenirse e-mail security kontrolü doğal davranışını göstermez. Böyle bir allowlist operasyonel zorunluluksa raporda açıkça belirtilmeli ve mail control ölçümü scope dışı kabul edilmelidir.

5. Eğitim ve kültürün zaman içindeki değişimi

Tek campaign kurumun kalıcı riskini ölçmez. Sonuçlar aynı employee population, benzer zorluk ve aynı denominator ile zaman serisi olarak karşılaştırılmalıdır.

Campaign A
Kolay zorluk, Finance grubu, e-mail channel

Campaign B
Orta zorluk, Finance grubu, e-mail channel

Campaign C
Zor zorluk, bütün kurum, collaboration channel

Bu üç campaign'in ham click oranlarını yan yana koymak yanıltıcıdır. Segment, channel, scenario difficulty ve exposure denominator ayrı tutulmalıdır.

Click rate neden tek başına kötü bir metric'tir?

Click rate çoğunlukla şu formülle hesaplanır:

unique click / delivered message × 100

Basit görünür fakat denominator ve event kalitesi sorunludur.

Link scanner insan tıklaması gibi görünebilir

Secure e-mail gateway, URL sandbox, browser prefetch veya privacy proxy linki kullanıcıdan önce açabilir. Tracking endpoint'e gelen her GET request'ini human click saymak false positive üretir.

Event'ler ayrılmalıdır:

{
  "eventType": "link_fetch_observed",
  "campaignId": "camp-2026-08-finance",
  "targetRef": "hmac:2eb7...",
  "messageRef": "msg-7f42",
  "observedAt": "2026-08-01T10:14:22Z",
  "sourceClass": "email_security_scanner",
  "confidence": "high"
}

{
  "eventType": "landing_interaction_confirmed",
  "campaignId": "camp-2026-08-finance",
  "targetRef": "hmac:2eb7...",
  "messageRef": "msg-7f42",
  "observedAt": "2026-08-01T10:16:03Z",
  "sourceClass": "user_browser",
  "confidence": "medium"
}

Bu ayrım yine yüzde 100 kesin insan attribution sağlamaz. Metric'in confidence sınırı raporda belirtilmelidir.

Open rate güvenilir değildir

Tracking pixel, image proxy, automatic image loading ve privacy feature'ları nedeniyle open event hem false positive hem false negative üretebilir. Ayrıca gereksiz kişisel veri işleme yaratabilir. Open rate ana risk metric'i yapılmamalıdır.

Click ile compromise aynı şey değildir

Bir linkin açılması şu sonuçların gerçekleştiğini kanıtlamaz:

• Credential girildi
• OAuth consent verildi
• Attachment çalıştırıldı
• Endpoint control atlandı
• Session ele geçirildi
• Attacker internal access kazandı

Oltalama simülasyonunda güvenli tasarım gereği bu adımların çoğu zaten çalıştırılmaz. Buna rağmen raporda “yüzde 8 compromise oldu” denmesi teknik olarak yanlış olabilir.

Daha anlamlı metric seti

Zorlukla normalize edilmiş sonuç

Basit bir rapor modeli campaign result ile difficulty rating'i yan yana tutabilir:

{
  "campaignId": "camp-2026-08-finance",
  "population": "finance",
  "delivered": 184,
  "confirmedInteractions": 11,
  "reports": 63,
  "medianReportSeconds": 248,
  "difficulty": {
    "cueCount": 2,
    "premiseAlignment": "high",
    "rating": "very_difficult"
  }
}

Amaç herkesi tek puana sıkıştırmak değil, ham oranların context'ini korumaktır.

Red Team gerçekte neyi ölçer?

NIST, Red Team'i potansiyel adversary'nin attack ve exploitation capability'lerini kurumun security posture'una karşı emüle etmek üzere yetkilendirilmiş ekip olarak tanımlar. Red Team exercise ise gerçek dünya koşullarını yansıtan ve kurumsal mission veya business process'leri compromise etmeye yönelik simüle adversarial attempt olarak ele alınır.

Bu tanımın merkezinde e-posta yoktur. Objective vardır.

Örnek objective'ler:

• Kritik payment workflow'unda yetkisiz transaction başlatabilmek
• Ransomware öncesi erişim seviyesine ulaşarak containment kabiliyetini ölçmek
• Domain veya cloud identity üzerinde belirlenmiş privileged role'e erişebilmek
• Kritik üretim planlama verisine kontrollü erişim kanıtı üretmek
• SOC'u önceden haberdar etmeden belirli attack chain'i ilerletebilmek

Phishing, objective'e ulaşmak için seçilen initial access path olabilir. Threat Intelligence başka bir path'i daha olası gösteriyorsa external application, exposed identity service, trusted relationship, valid account veya assumed breach başlangıcı tercih edilebilir.

Phishing olmadan Red Team yapılabilir mi?

Evet. Aşağıdaki starting condition'lar mümkündür:

• Full-scope external başlangıç
• Internet-facing asset üzerinden initial access
• Assumed breach workstation
• Controlled standard user credential
• Cloud identity başlangıcı
• Third-party trust başlangıcı
• Internal network foothold

Her kurumun phishing ile başlamak zorunda olmadığını, hatta savunma olgunluğu düşük kurumlarda Red Team'in erken olabileceğini her kurumun Red Team'e ihtiyacı var mı? yazımızda açıklıyoruz.

Phishing Red Team içinde kullanıldığında ne değişir?

Oltalama simülasyonu çoğunlukla interaction veya report noktasında biter. Red Team scenario ise izin verilen ölçüde bundan sonrasını sorar:

Delivery
  ↓
User interaction
  ↓
Controlled execution veya identity event
  ↓
Initial foothold
  ↓
Persistence veya session continuity
  ↓
Discovery
  ↓
Privilege veya lateral movement
  ↓
Critical objective
  ↓
Detection, investigation ve containment ölçümü

Bu zincirin her adımı engagement scope'una bağlıdır. Red Team adı kullanılması gerçek credential toplama, kontrolsüz malware çalıştırma veya sınırsız hareket yetkisi vermez. Allowed, conditional ve prohibited action'lar Rules of Engagement içinde açıkça yazılmalıdır.

Aynı e-posta iki çalışmada nasıl farklı anlam taşır?

Örnek scenario, çalışanlara document paylaşımı bildirimi gönderilmesi olsun.

Oltalama simülasyonunda

Amaçlar:

• Çalışan sender ve link sinyallerini fark ediyor mu?
• Report button kullanılıyor mu?
• Bildirim SOC veya mail security workflow'una ulaşıyor mu?
• Campaign zorluğuna göre report ve interaction trend'i ne?

Güvenli bitiş:

Link açılır
    ↓
İmzalı campaign token doğrulanır
    ↓
Pseudonymous interaction event'i yazılır
    ↓
Kullanıcı eğitim ve report guidance sayfasına yönlendirilir

Red Team engagement'ında

Amaçlar:

• Targeted social engineering e-mail security katmanını geçebiliyor mu?
• Controlled initial access artifact'i endpoint üzerinde görünür mü?
• EDR, identity ve network telemetry zinciri oluşuyor mu?
• SOC alert'i doğru attack context'iyle araştırıyor mu?
• Control Team stop condition oluşmadan objective'e ilerlenebiliyor mu?

E-posta aynı görünebilir. Fakat devam eden operation, risk, telemetry ve başarı ölçütü tamamen farklıdır.

Scope ve Rules of Engagement farkı

Oltalama simülasyonu scope'u

İyi bir scope en az şu alanları içerir:

• Hedef population ve hariç tutulan gruplar
• Channel
• Campaign window
• Scenario theme ve difficulty
• Delivery infrastructure
• Toplanacak event'ler
• Veri minimization ve retention
• Eğitim landing page'i
• Reporting integration
• Help desk hazırlığı
• Gerçek incident deconfliction
• Acil durdurma yetkilisi

Örnek güvenli campaign policy:

campaign:
  id: camp-2026-08-finance
  purpose: awareness-and-reporting-validation
  population: finance-pseudonymous-list
  window_utc:
    start: 2026-08-10T07:00:00Z
    end: 2026-08-12T15:00:00Z

allowed_events:
  - delivered
  - quarantined
  - link_fetch_observed
  - landing_interaction_confirmed
  - user_reported
  - training_viewed

prohibited:
  - real_credential_collection
  - oauth_consent_request
  - executable_payload
  - attachment_macro
  - remote_access_tool
  - public_employee_ranking

retention:
  individual_event_days: 30
  aggregate_metrics_days: 365

Değerler örnektir. Retention ve hukuki dayanak kurumun privacy ve hukuk değerlendirmesine göre belirlenmelidir.

Red Team Rules of Engagement

Red Team RoE daha geniştir:

engagement:
  objective: demonstrate-controlled-access-to-payment-approval-context
  threat_profile: approved-ti-summary-v3
  control_team_contact: control-team@example.test

initial_access:
  phishing_link: allowed
  controlled_attachment: conditional
  voice_pretext: prohibited
  third_party_messaging: prohibited

post_access:
  credential_access: conditional
  persistence: approved-techniques-only
  lateral_movement: named-segments-only
  data_access: synthetic-canary-only
  exfiltration: proof-token-only

stop_conditions:
  - production_instability
  - real_sensitive_data_encountered
  - third_party_boundary_reached
  - active_real_incident
  - authorization_uncertainty
  - control_team_requests_stop

İyi Red Team senaryosunun bir saldırı listesi değil, ölçüm tasarımı olduğunu Red Team senaryosu nasıl yazılır? yazımızda teknik örneklerle ele alıyoruz.

Control Team neden gereklidir?

Control Team veya klasik kullanımdaki White Team:

• Yetkilendirmeyi doğrular
• Scope ve stop condition'ları izler
• Gerçek incident ile exercise'i ayırır
• Production safety kararını verir
• Üçüncü taraf boundary'lerini korur
• Gerekli deconfliction'ı yönetir
• Cleanup ve evidence saklama sürecini takip eder

Oltalama simülasyonunda da benzer bir koordinasyon rolü gerekir. Ancak Red Team'de operational risk ve attack path daha geniş olduğu için Control Team'in sorumluluğu daha ağırdır.

Çalışan verisi ve etik sınır nasıl korunur?

Oltalama simülasyonu employee behavior hakkında veri üretir. E-posta adresi, department, delivery, interaction ve reporting timestamp'i belirli veya belirlenebilir bir çalışanla ilişkilendirilebiliyorsa kişisel veri niteliği taşıyabilir.

KVKK'nın genel ilkeleri veri işlemenin belirli, açık ve meşru amaçla yapılmasını, amaçla bağlantılı, sınırlı ve ölçülü olmasını ve gerekli süre kadar saklanmasını gerektirir. Bu nedenle “security için topluyoruz” ifadesi tek başına tasarım değildir.

Kurumun hukuk, insan kaynakları, privacy ve employee relations ekipleri şu konuları engagement öncesinde değerlendirmelidir:

• İşleme amacı ve uygun hukuki dayanak
• Aydınlatma yaklaşımı
• Campaign detayını açıklamadan genel program şeffaflığı
• Hangi event'lerin gerçekten gerekli olduğu
• Bireysel ve aggregate rapor erişimi
• Retention ve automatic deletion
• Çalışan itiraz ve destek süreci
• Yurt dışı service veya altyapı kullanımı
• Data processor sözleşmeleri
• Yetki matrisi ve audit log

Parola neden toplanmamalıdır?

Gerçek password veya MFA code toplamak awareness metric'i için gerekli değildir. Kullanıcı gerçek credential girerse kurum yeni bir credential riskini kendisi üretmiş olur.

Güvenli landing page şu kuralları uygulayabilir:

• Gerçek login formunu taklit etmez
• Password field bulundurmaz
• URL içinde e-mail veya employee ID taşımaz
• Signed ve kısa ömürlü pseudonymous token kullanır
• Cache-Control: no-store döner
• Third-party analytics yüklemez
• Event'i minimum alanla kaydeder
• Eğitim ve report guidance gösterir

Örnek token payload:

{
  "campaignId": "camp-2026-08-finance",
  "targetRef": "tgt_bx7Q2K",
  "messageRef": "msg_7f42",
  "purpose": "simulation-link",
  "issuedAt": 1786345200,
  "expiresAt": 1786604400
}

Token imzalı olmalı, tahmin edilebilir employee identifier içermemeli ve başka campaign için tekrar kullanılamamalıdır.

import crypto from "node:crypto";

function verifyCampaignToken(token: string, secret: Buffer) {
  const [payloadPart, signaturePart] = token.split(".");
  if (!payloadPart || !signaturePart) throw new Error("Invalid token");

  const expected = crypto
    .createHmac("sha256", secret)
    .update(payloadPart)
    .digest("base64url");

  const actual = Buffer.from(signaturePart, "base64url");
  const wanted = Buffer.from(expected, "base64url");

  if (actual.length !== wanted.length || !crypto.timingSafeEqual(actual, wanted)) {
    throw new Error("Invalid token");
  }

  const payload = JSON.parse(
    Buffer.from(payloadPart, "base64url").toString("utf8")
  );

  if (payload.purpose !== "simulation-link") throw new Error("Invalid purpose");
  if (Date.now() / 1000 >= payload.expiresAt) throw new Error("Expired token");

  return payload;
}

Production implementation schema validation, key rotation, maximum lifetime, replay policy ve malformed input limitleri de içermelidir.

Public shaming güvenlik kültürünü bozar

“Tıklayanlar listesi”ni departmanlara yaymak kısa vadede caydırıcı görünebilir. Uzun vadede çalışanların gerçek incident'i saklamasına neden olabilir. NCSC'nin no-blame yaklaşımı, raporları kişiyi suçlama değil öğrenme ve iyileştirme fırsatı olarak konumlandırır.

No-blame, accountability olmadığı anlamına gelmez. Kasıtlı policy ihlali ile zor ve iyi hazırlanmış bir social engineering mesajına verilen insan tepkisi aynı şekilde ele alınmamalıdır.

Phishing simulation SOC'u ölçebilir mi?

Evet. Oltalama simülasyonu yalnız awareness metric'i üretmek zorunda değildir. Report button, mail security ve SOC workflow'u scope'a alınırsa detection ve response sürecinin belirli bir bölümü test edilebilir.

Fakat bu özellik tek başına çalışmayı Red Team yapmaz.

Örnek bir simulation objective'i şöyle yazılabilir:

Bu objective değerlidir. Ancak initial access sonrasında endpoint, identity ve internal environment üzerinde adversary progression yapılmadığı için kapsam hâlâ oltalama simülasyonudur.

SOC önceden haberdar edilmeli mi?

Tek bir doğru cevap yoktur. Seçim ölçülmek istenen capability'ye bağlıdır.

SOC'un bilmediği her çalışma Red Team değildir. Blind yürütülen kısa bir phishing campaign yine yalnız phishing simulation olabilir. Gizlilik modeli ile engagement türü aynı kavram değildir.

Telemetry zinciri nasıl kurulmalıdır?

MITRE ATT&CK'in güncel phishing detection stratejileri, tek bir mail event'inden çok davranış korelasyonuna odaklanır:

Inbound message metadata
        ↓
URL veya attachment interaction
        ↓
Browser, Office veya file event'i
        ↓
Process creation veya identity event
        ↓
Outbound network activity
        ↓
Alert, investigation ve containment

Awareness-only campaign'de execution ve process creation bilinçli olarak bulunmayabilir. Bu durumda beklenen telemetry daha kısa olur:

Delivery → Report → Triage → Similar-message search → Purge decision

Red Team scenario'sunda controlled initial access izinliyse zincir endpoint ve identity telemetry'sine kadar genişleyebilir.

Campaign event'lerini SIEM'e güvenli taşımak

SIEM'e raw e-mail address yerine pseudonymous reference gönderilebilir:

{
  "eventType": "user_reported",
  "campaignId": "camp-2026-08-finance",
  "targetRef": "hmac:2eb7...",
  "messageRef": "msg-7f42",
  "channel": "email-report-button",
  "eventTime": "2026-08-01T10:18:11Z",
  "scenarioDifficulty": "very_difficult",
  "environment": "production-simulation"
}

Custom simulation event'leri için KQL benzeri korelasyon:

let Window = 30m;
let Delivered = SimulationEvents_CL
| where EventType_s == "delivered"
| project CampaignId_s, MessageRef_s, TargetRef_s, DeliveredAt=TimeGenerated;

let Reported = SimulationEvents_CL
| where EventType_s == "user_reported"
| project CampaignId_s, MessageRef_s, TargetRef_s, ReportedAt=TimeGenerated;

Delivered
| join kind=inner Reported on CampaignId_s, MessageRef_s, TargetRef_s
| extend TimeToReport = ReportedAt - DeliveredAt
| where TimeToReport between (0s .. Window)
| summarize
    Reports=count(),
    MedianTimeToReport=percentile(TimeToReport, 50)
  by CampaignId_s

Table ve field adları örnektir. Production schema, timezone, duplicate event, late arrival ve retention davranışına göre uyarlanmalıdır.

Report button çalıştı fakat SOC görmedi

Bu sonuç “çalışan başarısız” değildir. Aksine human control çalışmış, teknik veya operasyonel zincir kopmuştur.

Kök nedenler şunlar olabilir:

• Report mailbox yanlış routing kullanıyor
• Mobile report action header'ları taşımıyor
• Ticket integration failed
• Mail security API permission'ı eksik
• SOC queue için yanlış severity atanıyor
• Message trace ve URL extraction yapılmıyor
• On-call ownership belirsiz
• Playbook yalnız attachment scenario'sunu kapsıyor

Rapor insan, süreç ve teknoloji sonuçlarını ayrı vermelidir.

Red Team'de phishing başarısı nasıl ölçülür?

Red Team'de “kaç kişi tıkladı?” ana başarı metric'i değildir. Bir kullanıcı interaction'ı initial access için yeterli olabilir. Asıl değer, bundan sonra saldırı ve savunma zincirinin nasıl ilerlediğidir.

Offensive progression metric'leri

• Message delivery gerçekleşti mi?
• Initial access artifact'i oluştu mu?
• Foothold güvenli ve scope içinde doğrulandı mı?
• Required privilege veya identity context'e erişildi mi?
• Attack path hangi control tarafından durduruldu?
• Critical objective'e ulaşıldı mı?
• Objective yalnız synthetic canary ile mi kanıtlandı?

Defensive metric'ler

• E-mail control mesajı işaretledi mi?
• User report oluştu mu?
• EDR veya identity telemetry üretildi mi?
• Detection analytic tetiklendi mi?
• Alert doğru severity ve context ile açıldı mı?
• Analyst attack chain'i kurabildi mi?
• Containment doğru identity, endpoint ve message scope'unu kapsadı mı?
• Revoke ve isolation etkisi bounded sürede yayıldı mı?

Timeline metric'leri

T0   Message delivered
T1   User reported
T2   Controlled initial access
T3   First telemetry
T4   First alert
T5   Analyst triage
T6   Incident declared
T7   Containment action
T8   Red Team access invalidated

Bu event'lerden şu süreler hesaplanabilir:

Time to Report      = T1 - T0
Time to Detect      = T4 - T2
Time to Triage      = T5 - T4
Time to Contain     = T8 - T5
Adversary Dwell     = T8 - T2

Red Team'in objective'e ulaşması savunmanın tamamen başarısız olduğu anlamına gelmez. Blue Team attack chain'in büyük bölümünü görmüş fakat containment policy nedeniyle geç kalmış olabilir. Tersi durumda objective'e ulaşılamamış olsa bile bunun nedeni Red Team infrastructure problemi veya Control Team kısıtı olabilir.

TIBER-EU yaklaşımı da sonucu basit pass veya fail olarak değil, cyber resilience önlemlerinin güçlü ve zayıf taraflarını ortaya çıkaran bir öğrenme çalışması olarak konumlandırır.

Örnek attack timeline kaydı

{
  "eventId": "rt-evt-0042",
  "scenarioId": "rt-2026-identity-01",
  "timestamp": "2026-08-14T09:31:12Z",
  "team": "red",
  "technique": "T1566.002",
  "action": "controlled-link-initial-access",
  "assetRef": "endpoint-canary-17",
  "result": "succeeded",
  "safety": {
    "realCredentialCollected": false,
    "realDataAccessed": false,
    "persistenceInstalled": false
  },
  "evidenceRef": "evd-sha256-9b6f..."
}

Bu kayıt reporting ve deconfliction için yararlıdır. Kullanılan altyapı secret'ları, gerçek employee identity ve re-usable access token'lar rapor event'ine konulmamalıdır.

Red Team'in sızma testinden farkının araçta değil, sorulan soruda başladığını Red Team ile sızma testi arasındaki fark gerçekten nerede başlar? yazımızda ayrıntılı olarak açıklıyoruz.

Oltalama simülasyonunda teknik güvenlik baseline'ı

Simulation platform'u kendisi yeni bir risk üretmemelidir.

Campaign domain ve e-mail authentication

Kullanılan domain kurum tarafından onaylanmalı, yasal ve marka kullanım sınırları doğrulanmalı, campaign bitiminde ownership ve DNS lifecycle'ı yönetilmelidir. Infrastructure'ın kontrolsüz biçimde başka taraflara devredilmesi sonraki gerçek saldırılar için güven problemi oluşturabilir.

SPF, DKIM ve DMARC sonuçları campaign objective'ine göre belgelenmelidir:

Authentication-Results:
  spf=pass smtp.mailfrom=simulation.example.test
  dkim=pass header.d=simulation.example.test
  dmarc=pass header.from=simulation.example.test

Bu header örneği “mesaj güvenlidir” anlamına gelmez. SPF, DKIM ve DMARC domain authentication sağlar. Mesajın business intent'ini veya içeriğinin zararsız olduğunu kanıtlamaz.

Tracking token içinde PII taşımayın

Riskli URL:

https://training.example.test/click?email=ad.soyad@example.com&department=finance

Daha güvenli URL:

https://training.example.test/s/tkn_4xB7q2...

Mapping ayrı, encryption at rest uygulanan ve dar yetkili store'da tutulabilir. Campaign analysis tamamlandığında mapping silinip aggregate sonuç korunabilir.

Landing endpoint secret field kabul etmemeli

app.post("/simulation/:token/interaction", json({ limit: "8kb" }), async (req, res) => {
  const payload = verifyCampaignToken(
    req.params.token,
    campaignSigningKey.current
  );

  if (Object.keys(req.body ?? {}).length !== 0) {
    securityLogger.warn({ campaignId: payload.campaignId }, "Unexpected form data rejected");
    return res.status(400).send("Unsupported input");
  }

  await eventStore.append({
    eventType: "landing_interaction_confirmed",
    campaignId: payload.campaignId,
    targetRef: payload.targetRef,
    messageRef: payload.messageRef,
    observedAt: new Date().toISOString()
  });

  res
    .set("Cache-Control", "no-store, max-age=0")
    .set("Referrer-Policy", "no-referrer")
    .status(204)
    .end();
});

Örneğin amacı, simulation endpoint'inin herhangi bir form data kabul etmemesi ve gerçek credential alma kabiliyetine sahip olmamasıdır. Production code CSRF modelini, rate limit'i, proxy trust ayarını, replay'i ve log redaction'ı ayrıca ele almalıdır.

Token URL path'inde bulunduğu için web server, reverse proxy, CDN, WAF ve APM access log'larında maskelenmelidir. Token raw halde loglanırsa kısa lifetime içinde campaign event'i başka bir kişi adına tetiklenebilir. Correlation için token'ın HMAC fingerprint'i kullanılabilir.

function campaignTokenFingerprint(token: string, logKey: Buffer) {
  return crypto
    .createHmac("sha256", logKey)
    .update(token)
    .digest("base64url")
    .slice(0, 20);
}

Signing key ile log fingerprint key aynı olmamalıdır.

Küçük cohort raporları yeniden tanımlamaya yol açabilir

Rapor employee name içermese bile “Ankara gece vardiyası satın alma ekibi” gibi üç kişilik bir segment sonucu bireyleri dolaylı biçimde görünür kılabilir. Aggregate reporting için minimum cohort eşiği belirlenmelidir.

PostgreSQL örneği:

WITH campaign_population AS (
  SELECT
    campaign_id,
    cohort_id,
    target_ref,
    MAX((event_type = 'delivered')::int) AS delivered,
    MAX((event_type = 'landing_interaction_confirmed')::int) AS interacted,
    MAX((event_type = 'user_reported')::int) AS reported
  FROM simulation_events
  WHERE campaign_id = $1
  GROUP BY campaign_id, cohort_id, target_ref
)
SELECT
  campaign_id,
  cohort_id,
  COUNT(*) FILTER (WHERE delivered = 1) AS delivered_count,
  COUNT(*) FILTER (WHERE interacted = 1) AS interaction_count,
  COUNT(*) FILTER (WHERE reported = 1) AS report_count
FROM campaign_population
GROUP BY campaign_id, cohort_id
HAVING COUNT(*) FILTER (WHERE delivered = 1) >= $2;

$2 kurumun onayladığı minimum group size'dır. Küçük cohort'lar daha geniş bir parent group ile birleştirilebilir. Eşik, tek başına anonymity garantisi değildir. Rare role, location ve shift kombinasyonları da incelenmelidir.

Infrastructure separation

• Production identity provider kullanılmamalı
• Landing page third-party script yüklememeli
• Simulation log'ları application analytics'e karışmamalı
• Campaign secret'ları merkezi secret manager'da tutulmalı
• Admin panel MFA ve least privilege ile korunmalı
• Operator action'ları audit edilmeli
• Export'lar encrypted ve süreli olmalı
• Vendor tenant'ı kurumlar arasında data isolation sağlamalı
• Campaign bittiğinde DNS, certificate ve storage cleanup yapılmalı

Safety testleri campaign'den önce çalıştırılmalı

[ ] Link gerçek credential formuna gitmiyor
[ ] URL token'ı başka target için kullanılamıyor
[ ] Expired token event yazmıyor
[ ] Password benzeri field reddediliyor
[ ] Security scanner fetch'i human click sayılmıyor
[ ] Landing page no-store dönüyor
[ ] Report button event'i doğru queue'ya ulaşıyor
[ ] Emergency stop yeni delivery'yi durduruyor
[ ] Mapping retention sonunda siliniyor

Scenario teması gereksiz zarar üretmemeli

Gerçekçi bir e-posta ile çalışanı kişisel olarak sarsan bir e-posta aynı şey değildir. Sağlık sonucu, işten çıkarılma, maaş kesintisi, aile acil durumu veya kişisel travma temaları sırf click oranını yükseltmek için kullanılmamalıdır.

Scenario review şu soruları içermelidir:

• Mesaj iş context'iyle ilgili mi?
• Çalışanda gereksiz korku veya utanç yaratıyor mu?
• Dil ve accessibility ihtiyacı dikkate alındı mı?
• Shift worker ve mobile-only kullanıcılar eşit biçimde ölçülüyor mu?
• External contractor'lar için farklı bilgilendirme veya hukuki sınır var mı?
• Eğitim sayfası suçlayıcı mı, öğretici mi?

Zorluk, manipülasyonun duygusal sertliğiyle değil, gerçek saldırı sinyallerinin çalışan context'i içinde ne kadar belirgin olduğuyla değerlendirilmelidir.

Red Team phishing scenario'sunda safety nasıl korunur?

Red Team daha gerçekçi olabilir fakat “gerçekçilik” kontrolsüz payload anlamına gelmez.

Controlled artifact kullanımı

Scenario objective'ine göre şu kanıt modelleri tercih edilebilir:

• Harmless callback ve unique canary
• Scope içindeki test identity ile controlled sign-in event
• İzole test document'i
• Execution yerine security control verdict'i
• Synthetic data access token'ı
• Önceden tanımlı endpoint canary file

Gerçek password, customer data veya kalıcı access toplamak yerine objective'i kanıtlayacak minimum artifact kullanılmalıdır.

Conditional action approval

Bazı action'lar engagement başında genel olarak onaylanmak yerine koşula bağlı tutulabilir:

Action: Controlled attachment execution
Status: Conditional
Approval trigger: Mail delivery confirmed and Control Team available
Allowed target: Named test endpoints only
Maximum runtime: 10 minutes
Network destination: Approved callback domain only
Persistence: Prohibited
Cleanup evidence: Required

Bu yapı Red Team'in hızını tamamen durdurmadan production safety sağlar.

Deconfliction

Control Team gerçek incident'i simulation'dan ayırabilmelidir. Bunun için defender'a açık olmayan fakat Control Team'in doğrulayabileceği marker kullanılabilir:

• Campaign-specific message reference
• Approved source infrastructure inventory
• Signed operation event
• Unique callback correlation ID
• Control Team doğrulama runbook'u

Marker Blue Team'in detection'ını yapay biçimde kolaylaştırmamalıdır.

Phishing simulation mı, Red Team mi seçilmeli?

Oltalama simülasyonu seçin, eğer soru şunlardan biriyse

• Çalışanlar şüpheli mesajı bildiriyor mu?
• Report button kullanılabilir mi?
• Awareness programı zaman içinde gelişiyor mu?
• Belirli department veya channel daha fazla desteğe ihtiyaç duyuyor mu?
• Mail security ile user reporting workflow'u çalışıyor mu?
• Campaign purge playbook'u tetikleniyor mu?

Red Team seçin, eğer soru şunlardan biriyse

• Threat actor benzeri bir scenario kritik objective'e ulaşabilir mi?
• Initial access sonrasında endpoint ve identity kontrolleri saldırıyı durduruyor mu?
• SOC attack chain'i birleştirebiliyor mu?
• Alert'ten containment'a kadar süre nedir?
• Human, process ve technology kontrolleri birlikte çalışıyor mu?
• Known vulnerability olmadan gerçek attack path bulunabiliyor mu?

Purple Team seçin, eğer amaç birlikte geliştirmekse

Detection analytic, log source ve playbook geliştirmek öncelikliyse Purple Team daha doğru olabilir. Red Team bilinmeyen path ve mission baskısını ölçer. Purple Team adım adım görünürlük ve response kalitesini geliştirir. BAS ise tekrarlanabilir control validation sağlar.

Bu üç çalışma arasındaki farkı Purple Team, Red Team ve BAS hangi çalışma neyi ölçer? yazımızda karşılaştırıyoruz.

Karar matrisi

İki çalışma birlikte nasıl programlanır?

Olgun bir program bunları birbirinin yerine kullanmaz.

1. Baseline awareness ve reporting simulation
        ↓
2. Mail control ve SOC workflow doğrulaması
        ↓
3. Purple Team ile telemetry ve playbook iyileştirmesi
        ↓
4. Threat Intelligence tabanlı Red Team
        ↓
5. Red Team bulgularının Purple Team replay'i
        ↓
6. Periyodik safe simulation ve control regression

Red Team sonrası yalnız rapor teslim edilmemelidir. Attack timeline'daki eksik detection'lar Purple Team oturumlarında replay edilmeli, remediation owner ve tarihleri atanmalı, ilgili control daha sonra tekrarlanabilir biçimde doğrulanmalıdır.

Red Team'in amacı ve yöntemlerini uçtan uca Red Team nedir? Kapsamlı Rehber içeriğimizde inceleyebilirsiniz.

Teklifte hangi maddeler açıkça yazılmalıdır?

“Phishing testi yapılacaktır” ifadesi yeterli değildir.

Oltalama simülasyonu teklifinde

• Hedef population ve segment sayısı
• Campaign ve channel sayısı
• Scenario difficulty değerlendirmesi
• Delivery ve reporting integration'ı
• Toplanacak event'ler
• Scanner ve prefetch classification yaklaşımı
• Credential ve MFA data toplama yasağı
• Privacy, retention ve deletion yaklaşımı
• Individual ve aggregate rapor kapsamı
• Training landing page ve feedback modeli
• Emergency stop ve support planı
• Retest veya follow-up campaign

Red Team teklifinde

• Business objective
• Threat Intelligence ve scenario development
• Starting condition
• Social engineering'in allowed, conditional veya prohibited durumu
• İnsan, identity, endpoint, network, cloud ve application scope'u
• Control Team ve deconfliction modeli
• Stop condition'lar
• Payload ve infrastructure safety
• Detection ve response metric'leri
• ATT&CK mapping
• Cleanup ve evidence handling
• Purple Team replay ve remediation workshop

Tedarikçiye sorulacak kritik sorular

1. 1Click ile scanner fetch'i nasıl ayırıyorsunuz?
2. 2E-posta difficulty'sini hangi yöntemle değerlendiriyorsunuz?
3. 3Gerçek credential veya MFA data topluyor musunuz?
4. 4Individual result'lara kim erişebiliyor?
5. 5Veriler nerede ve ne kadar süre tutuluyor?
6. 6Campaign infrastructure başka müşterilerle paylaşılıyor mu?
7. 7Report button ve SOC integration'ını test ediyor musunuz?
8. 8Red Team'de phishing sonrasında hangi action'lar devam ediyor?
9. 9Rules of Engagement ve stop condition kim tarafından onaylanıyor?
10. 10Gerçek incident deconfliction nasıl yapılıyor?
11. 11Attack timeline ve detection gap raporu veriliyor mu?
12. 12Cleanup'ın tamamlandığını nasıl kanıtlıyorsunuz?

Sadece “kaç e-posta gönderilecek?” üzerinden fiyatlanan çalışma, ihtiyacı yanlış tanımlayabilir.

Rapor çıktıları nasıl ayrışır?

Oltalama simülasyonu raporu

• Executive summary
• Population ve denominator açıklaması
• Scenario ve difficulty değerlendirmesi
• Delivery, quarantine ve bounce sonucu
• Adjusted interaction rate
• Report rate ve time-to-report
• Mail control ve SOC workflow sonucu
• Channel ve segment trend'i
• Privacy ve data quality sınırlamaları
• Awareness ve process improvement planı
• Follow-up ölçüm önerisi

Red Team raporu

• Executive attack narrative
• Objective ve business impact
• Threat profile ve scenario rationale
• Attack timeline
• Initial access ve attack path
• ATT&CK technique mapping
• Prevention, telemetry ve detection sonucu
• Investigation ve containment timeline'ı
• IOC ve artifact listesi
• Finding ve root cause
• Remediation roadmap
• Cleanup statement
• Purple Team replay planı

Red Team raporunda “kaç kişi tıkladı?” yardımcı bir campaign verisi olabilir. Ana sonuç objective ve savunma davranışıdır.

Sonuçlardan hangi çıkarımlar yapılmamalıdır?

“Tıklayan herkes compromise oldu”

Yanlıştır. Click, credential access veya code execution değildir. Campaign yalnız güvenli landing interaction ölçtüyse sonuç da bu sınırda adlandırılmalıdır.

“Kimse tıklamadı, phishing riskimiz yok”

Yanlıştır. Mesaj delivery kontrolünde engellenmiş, scenario kolay seçilmiş, tracking scanner tarafından bozulmuş veya population campaign'i önceden öğrenmiş olabilir. Başka bir channel, daha iyi premise veya compromised trusted account farklı sonuç üretir.

“Çalışan bildirdi, SOC olayı gördü”

Otomatik değildir. Report event'in ticket, investigation, similar-message search ve purge action'a ulaşıp ulaşmadığı ayrıca kanıtlanmalıdır.

“Red Team objective'e ulaştı, çalışan hatalı”

Red Team sonucu tek bir kullanıcının davranışına indirgenemez. E-mail security, browser isolation, endpoint control, identity policy, segmentation, SOC detection ve containment zincirinin tamamı değerlendirilmelidir. Defense in depth yaklaşımı insan hatasının tek başına compromise'a dönüşmesini engellemelidir.

“Alert oluşmadı, SOC başarısız”

Önce telemetry'nin üretilip üretilmediği kontrol edilmelidir. Gerekli log source yoksa detection analytic'in çalışması mümkün değildir. Telemetry gap, analytic gap ve analyst decision ayrı finding'lerdir.

“Red Team phishing yaptı, bütün awareness programını ölçtü”

Targeted Red Team e-postası küçük bir population ve objective için tasarlanmış olabilir. Bütün çalışanların farkındalık trend'ini temsil etmez. Aynı şekilde geniş bir awareness campaign de target-specific adversary emulation'ın yerine geçmez.

Ölçülebilir acceptance criteria örneği

PH-01
Campaign sonucunda gerçek password, MFA code, access token veya OAuth consent
toplanmamalıdır. Landing endpoint secret benzeri field'ları fail-closed
reddetmelidir.

PH-02
Tracking URL e-mail address, employee ID veya department bilgisini açık veya
kolayca decode edilebilir biçimde taşımamalıdır.

PH-03
Security scanner, prefetch ve privacy proxy kaynaklı fetch event'leri confirmed
human interaction metric'ine doğrudan dahil edilmemelidir.

PH-04
Click, report ve time-to-report değerleri campaign difficulty, delivered
denominator ve population context'iyle birlikte raporlanmalıdır.

PH-05
Report button event'i message reference ve gerekli header context'iyle SOC veya
mail security workflow'una en fazla iki dakika içinde ulaşmalıdır.

PH-06
Individual event mapping'i onaylanan retention süresi sonunda automatic olarak
silinmeli, aggregate sonuç kimliği belirlenebilir veri taşımamalıdır.

PH-07
Campaign emergency stop çağrısından sonra yeni message delivery en fazla beş
dakika içinde durmalıdır.

RT-PH-01
Red Team phishing action'ı yalnız Rules of Engagement içinde adı geçen channel,
population ve time window üzerinde yürütülmelidir.

RT-PH-02
Initial access artifact'i yalnız approved callback infrastructure ile iletişim
kurmalı ve persistent access oluşturmamalıdır.

RT-PH-03
Gerçek sensitive data ile karşılaşıldığında evidence minimization uygulanmalı
ve Control Team stop veya devam kararını vermelidir.

RT-PH-04
Logout, credential revoke veya endpoint isolation sonrasında Red Team access'in
gerçekten kesildiği doğrulanmalıdır.

RT-PH-05
Final rapor delivery, initial access, first telemetry, first alert, triage,
containment ve access invalidation zamanlarını ayrı göstermelidir.

Değerler örnektir. Kurumun risk profiline ve operasyonuna göre belirlenmelidir.

Uygulama kontrol listesi

Amaç ve çalışma türü

• [ ] Oltalama simülasyonu ile Red Team ayrı tanımlandı
• [ ] Business objective tek cümlede açık
• [ ] Awareness, SOC validation ve adversary emulation hedefleri karışmıyor
• [ ] Phishing'in Red Team içinde yalnız olası initial access path olduğu açık
• [ ] Başarı pass veya fail olarak indirgenmiyor

Campaign tasarımı

• [ ] Population ve exclusion list onaylı
• [ ] Scenario business context'e uygun
• [ ] Difficulty rating belgeli
• [ ] Channel ve campaign window belli
• [ ] Delivered denominator güvenilir
• [ ] Scanner ve prefetch davranışı test edilmiş
• [ ] Open rate ana metric değil
• [ ] Report button mobile dahil çalışıyor
• [ ] Eğitim landing page'i hazır
• [ ] Scenario teması gereksiz korku veya kişisel zarar üretmiyor
• [ ] Dil ve accessibility gereksinimleri incelendi
• [ ] Help desk ve Control Team iletişim planı var

Veri ve privacy

• [ ] İşleme amacı ve hukuki değerlendirme tamamlandı
• [ ] Toplanan event'ler minimum düzeyde
• [ ] URL içinde PII yok
• [ ] Target reference pseudonymous
• [ ] Gerçek credential toplanmıyor
• [ ] Third-party analytics kullanılmıyor
• [ ] Tracking token access log'larında maskeleniyor
• [ ] Log correlation ayrı HMAC key ile üretiliyor
• [ ] Individual result erişimi role-based
• [ ] Retention ve automatic deletion var
• [ ] Export'lar encrypted
• [ ] Minimum cohort reporting eşiği var
• [ ] Rare group kombinasyonları re-identification açısından incelendi
• [ ] Public employee ranking yapılmıyor
• [ ] Program communication no-blame yaklaşımını koruyor

Teknik altyapı

• [ ] Domain ownership ve lifecycle tanımlı
• [ ] SPF, DKIM ve DMARC sonucu belgeli
• [ ] Signing key secret manager içinde
• [ ] Token purpose ve expiration doğrulanıyor
• [ ] Token başka campaign'de kullanılamıyor
• [ ] Landing page Cache-Control: no-store dönüyor
• [ ] Secret benzeri input reddediliyor
• [ ] Admin panel MFA kullanıyor
• [ ] Operator action audit log'u var
• [ ] Emergency stop test edilmiş
• [ ] Campaign sonrası DNS, storage ve certificate cleanup planlı

Metric ve raporlama

• [ ] Delivery, quarantine ve bounce ayrılıyor
• [ ] Link fetch ile confirmed interaction ayrılıyor
• [ ] Report rate delivered denominator kullanıyor
• [ ] Time-to-first-report hesaplanıyor
• [ ] Median time-to-report hesaplanıyor
• [ ] Difficulty sonucu metric'lerle birlikte veriliyor
• [ ] Human, process ve technology bulguları ayrılıyor
• [ ] Data quality ve attribution limitleri açıklanıyor
• [ ] Benzer campaign trend'i normalize ediliyor

SOC integration

• [ ] Report event'i doğru queue'ya gidiyor
• [ ] Message ID ve header context korunuyor
• [ ] Similar-message search playbook'u var
• [ ] Purge veya quarantine authority belli
• [ ] Incident severity mapping tanımlı
• [ ] Gerçek incident deconfliction runbook'u var
• [ ] First alert ve first triage timestamp'i kaydediliyor
• [ ] Simulation indicator'ları Blue Team'e gereksiz yere açılmıyor

Red Team ek kontrolleri

• [ ] Threat Intelligence scenario'yu gerekçelendiriyor
• [ ] Objective kritik business function'a bağlı
• [ ] Starting condition açık
• [ ] Allowed, conditional ve prohibited action'lar yazılı
• [ ] Named target ve trust boundary'ler belli
• [ ] Synthetic canary kullanımı tanımlı
• [ ] Controlled artifact'in maksimum runtime'ı var
• [ ] Persistence policy açık
• [ ] Third-party boundary stop condition
• [ ] Production instability stop condition
• [ ] Control Team kesintisiz ulaşılabilir
• [ ] Attack timeline tutuluyor
• [ ] Cleanup evidence zorunlu
• [ ] Purple Team replay planı var

Sonuç: Aynı link, aynı çalışma değildir

Oltalama simülasyonu ile Red Team'in ortak bir artifact kullanabilmesi, aynı problemi çözdükleri anlamına gelmez.

Oltalama simülasyonu şu soruya cevap verir:

Red Team ise daha geniş bir soru sorar:

Doğru programda:

• Campaign difficulty metric'lerle birlikte raporlanır
• Click rate tek başarı göstergesi yapılmaz
• User reporting olumlu davranış olarak ölçülür
• Scanner fetch'i human interaction sayılmaz
• Gerçek credential toplanmaz
• Employee data minimum ve süreli tutulur
• Awareness sonucu SOC workflow'undan ayrılmaz
• Red Team objective ve Threat Intelligence ile gerekçelendirilir
• Phishing, Red Team'de yalnız bir initial access seçeneğidir
• Rules of Engagement production safety'yi belirler
• Offensive ve defensive timeline birlikte raporlanır
• Bulgular Purple Team replay ve remediation'a bağlanır

SECNODEX, oltalama ve social engineering scope'unu çalışmanın gerçek amacı üzerinden tasarlar. Awareness odaklı simülasyonlarda difficulty, report behavior, privacy ve mail workflow'u ölçülür. Red Team engagement'larında ise social engineering yalnız onaylı scenario ve Rules of Engagement kapsamında, kritik objective ile savunma kabiliyetini sınayan attack path'in parçası olarak ele alınır. OSCP ve OSWE sertifikalarına sahip uzmanlarımız teknik kanıtı attack timeline, iş etkisi ve uygulanabilir remediation ile ilişkilendirir.

Kurumunuzun objective, readiness ve uygun çalışma türünü belirlemek için SECNODEX Red Team hizmetini, daha geniş güvenlik yol haritası için Siber Güvenlik Danışmanlığı hizmetimizi inceleyebilir veya bizimle iletişime geçebilirsiniz.

Kaynaklar

• NIST CSRC – Red Team
• NIST CSRC – Red Team Exercise
• NIST Technical Note 2276 – Phish Scale User Guide
• NIST – The Phish Scale User Guide Is Now Available
• MITRE ATT&CK – Phishing T1566
• MITRE ATT&CK – Detection Strategy for Phishing DET0070
• MITRE ATT&CK – Detection Strategy for Spearphishing Links DET0107
• European Central Bank – TIBER-EU Framework
• European Central Bank – TIBER-EU Updated to Align with DORA
• NCSC – Developing a Positive Cyber Security Culture
• NCSC – Guidance for High-Risk Individuals
• Kişisel Verileri Koruma Kurumu – Kişisel Verilerin İşlenmesine İlişkin Temel İlkeler
• RFC 7208 – Sender Policy Framework
• RFC 6376 – DomainKeys Identified Mail
• RFC 7489 – Domain-based Message Authentication, Reporting, and Conformance