# Kurumsal DDoS Tatbikatı Nasıl Yapılır? Test, Raporlama ve DDoS Dayanıklılık Stratejisi

**URL:** https://securesys.com.tr/tr/bilgi-merkezi/ddos-simulasyonu/kurumsal-ddos-tatbikati-nasil-yapilir

![Kurumsal DDoS Tatbikatı Nasıl Yapılır? Test, Raporlama ve DDoS Dayanıklılık Stratejisi](/images/bilgi-merkezi/covers/cover-ddos-12.webp)

Bir kurumun DDoS saldırılarına karşı güçlü olduğunu söylemek için yalnızca teknik ürünlere sahip olması yeterli değildir.

Firewall bulunabilir.

WAF devrede olabilir.

CDN kullanılabilir.

Anti-DDoS hizmeti aktif olabilir.

Scrubbing Center erişimi tanımlı olabilir.

SOC 7/24 çalışıyor olabilir.

Ancak gerçek bir saldırı sırasında bütün bu bileşenlerin aynı anda ve doğru sırada çalışıp çalışmadığı bilinmiyorsa kurumun DDoS dayanıklılığı yalnızca varsayımdan ibaret kalır.

Bu nedenle modern siber güvenlik yaklaşımında **Kurumsal DDoS Tatbikatı**, yalnızca teknik saldırı simülasyonu değil; insan, süreç ve teknolojinin birlikte test edildiği kapsamlı bir **Cyber Resilience Exercise – Siber Dayanıklılık Tatbikatı** olarak ele alınmalıdır.

Kurumsal DDoS tatbikatının temel amacı sistemi çökertmek değildir.

Asıl amaç şudur:

**Gerçek bir DDoS saldırısı gerçekleştiğinde kurumun ne kadar hızlı tespit edebildiğini, ne kadar doğru müdahale ettiğini, hangi teknik katmanlarda dayanıklılık gösterdiğini ve hizmeti ne kadar sürdürebildiğini ölçmek.**

Bu nedenle profesyonel bir DDoS tatbikatı;

teknik simülasyon,

SOC doğrulaması,

Network operasyonu,

Application izleme,

Incident Response,

War Room,

Tabletop Exercise,

yönetim iletişimi,

raporlama

gibi farklı bileşenleri aynı senaryoda birleştirebilir.

#### Kurumsal DDoS Tatbikatı Nedir?

**Kurumsal DDoS Tatbikatı**, DDoS saldırılarına karşı kurumun teknik, operasyonel ve yönetsel hazırlık seviyesini kontrollü ve yetkilendirilmiş senaryolarla ölçen güvenlik çalışmasıdır.

Bu çalışma yalnızca yüksek trafik üretmekten ibaret değildir.

Amaç şu alanları birlikte değerlendirmektir:

- Network dayanıklılığı
- Firewall kapasitesi
- WAF etkinliği
- CDN davranışı
- Anti-DDoS ve Scrubbing Center
- DNS dayanıklılığı
- Application ve API performansı
- SOC tespit kabiliyeti
- Incident Response
- Yönetim iletişimi
- Business Continuity
- Recovery süreçleri

Böylece DDoS tatbikatı bir ürün testi olmaktan çıkar ve gerçek bir **DDoS Resilience Assessment** haline gelir.

### DDoS Tatbikatı ile DDoS Testi Aynı Şey midir?

Hayır.

**DDoS testi**, ağırlıklı olarak teknik kapasite ve güvenlik kontrollerinin değerlendirilmesine odaklanır.

Örneğin;

kaç Gbps,

kaç PPS,

kaç CPS,

kaç RPS

seviyesinde sistemin davranış gösterdiği ölçülebilir.

**DDoS tatbikatı** ise daha geniştir.

Teknik testi;

SOC,

Incident Response,

Network,

Application,

Management,

Service Provider

süreçleriyle birlikte değerlendirir.

Yani DDoS tatbikatı şu soruya cevap verir:

**“Saldırı yalnızca teknolojiyi değil, organizasyonu da zorladığında ne oluyor?”**

### DDoS Tatbikatının Temel Amaçları Nelerdir?

Profesyonel bir tatbikatın amaçları önceden net olarak belirlenmelidir.

Örneğin:

#### Detection Validation

Saldırı doğru tespit ediliyor mu?

#### Mitigation Validation

Anti-DDoS ve WAF doğru şekilde devreye giriyor mu?

#### Capacity Validation

Teknik altyapı hangi seviyeye kadar dayanıyor?

#### SOC Validation

SOC alarmı doğru yorumlayabiliyor mu?

#### Incident Response Validation

Doğru ekipler doğru zamanda devreye giriyor mu?

#### Business Continuity Validation

Kritik hizmetler erişilebilir kalıyor mu?

#### Recovery Validation

Sistem saldırı sonrasında hızlı şekilde normale dönebiliyor mu?

Bu amaçlar tatbikatın kapsamını belirler.

### DDoS Tatbikatı Nasıl Planlanır?

Profesyonel tatbikat birkaç temel aşamada planlanabilir:

#### \1. Scope belirleme

Hangi servislerin test edileceği belirlenir.

#### \2. Risk analizi

Testin production etkisi değerlendirilir.

#### \3. Rules of Engagement

Teknik sınırlar tanımlanır.

#### \4. Baseline

Normal trafik ve sistem davranışı ölçülür.

#### \5. Senaryo tasarımı

Uygulanacak DDoS profilleri hazırlanır.

#### \6. Monitoring hazırlığı

Tüm telemetry kaynakları doğrulanır.

#### \7. Incident Response hazırlığı

SOC ve diğer ekiplerin rolleri belirlenir.

#### \8. Test execution

Kontrollü simülasyon gerçekleştirilir.

#### \9. Analysis

Sonuçlar değerlendirilir.

#### \10. Remediation & Retest

Eksikler giderilir ve tekrar test edilir.

### Scope Nasıl Belirlenmelidir?

Tatbikatın ilk adımı doğru kapsam oluşturmaktır.

Örneğin;

kurumsal web sitesi,

müşteri portalı,

internet bankacılığı,

e-ticaret platformu,

mobil backend,

API Gateway,

DNS,

VPN Gateway

kapsamda olabilir.

Ancak her servis aynı iş kritikliği seviyesine sahip değildir.

Bu nedenle önce **Critical Internet-Facing Services** belirlenmelidir.

### Crown Jewels DDoS Tatbikatında Nasıl Kullanılır?

Siber güvenlikte kritik varlıklar için sıklıkla **Crown Jewels** kavramı kullanılır.

DDoS bağlamında Crown Jewels;

müşteri giriş sistemi,

ödeme servisi,

sipariş platformu,

API,

DNS

gibi iş sürekliliği açısından kritik servisler olabilir.

Tatbikatın amacı tüm internet altyapısına rastgele yük vermek değil, kurum açısından en kritik servislerin ne kadar dayanıklı olduğunu anlamaktır.

### Business Impact Analysis Neden Gereklidir?

**Business Impact Analysis – BIA**, bir servisin kullanılamaz hale gelmesi durumunda oluşacak iş etkisini belirler.

Örneğin:

Kurumsal blog 30 dakika kapalı kalabilir.

Ama ödeme API'sinin 30 dakika kapanması ciddi gelir kaybına neden olabilir.

Bu nedenle DDoS tatbikatında teknik servisler iş etkisine göre önceliklendirilmelidir.

### Rules of Engagement Nasıl Hazırlanır?

**Rules of Engagement – RoE**, DDoS tatbikatının güvenli sınırlarını belirler.

RoE içerisinde şu bilgiler bulunabilir:

- Test edilen IP ve domain'ler
- İzin verilen protokoller
- Maksimum Gbps
- Maksimum PPS
- Maksimum CPS
- Maksimum RPS
- Test süresi
- Test saatleri
- Stop Condition
- Kill Switch
- Acil iletişim listesi

Bu sınırlar üretim ortamının güvenliği açısından kritik öneme sahiptir.

### Stop Condition Neden Tatbikatın En Kritik Unsurlarından biridir?

DDoS tatbikatında hedef gerçek kesinti oluşturmak değildir.

Bu nedenle test sırasında belirli güvenlik sınırları tanımlanmalıdır.

Örneğin:

Response time > 3 saniye

CPU > %90

Packet loss > %5

5xx rate > %10

Business transaction failure > %3

olduğunda test durdurulabilir.

Stop Condition sayesinde test kontrollü kalır.

### Kill Switch Nedir?

**Kill Switch**, test trafiğinin acil durumda anında durdurulmasını sağlayan mekanizmadır.

Örneğin beklenmeyen production problemi oluşursa Red Team veya test ekibi bütün trafik üretimini hemen kesebilir.

Yüksek hacimli DDoS testlerinde Kill Switch mutlaka doğrulanmalıdır.

### DDoS Tatbikatı Hangi Ekipleri İçermelidir?

Kurumun yapısına göre farklı ekipler dahil olabilir.

Örneğin;

#### Red Team / Security Testing

Saldırı simülasyonunu yürütür.

#### SOC

Saldırıyı tespit eder ve analiz eder.

#### Network

Network ve Anti-DDoS işlemlerini yönetir.

#### Application

Uygulama ve backend performansını izler.

#### Cloud

Cloud ve autoscaling bileşenlerini yönetir.

#### Incident Response

Olay koordinasyonunu yürütür.

#### Business Continuity

Kritik iş servislerini takip eder.

#### Management

İş etkisini değerlendirir.

Böylece tatbikat gerçek saldırı koşullarına daha yakın hale gelir.

### Red Team DDoS Tatbikatında Ne Yapar?

Red Team'in görevi güvenli ve önceden onaylanmış saldırı davranışlarını simüle etmektir.

Örneğin;

volumetric traffic,

Layer 3/4 flood,

Layer 7 HTTP Flood,

DNS query yoğunluğu

gibi farklı trafik profilleri uygulanabilir.

Ama Red Team'in başarı kriteri:

**“Sistemi çökerttik.”**

değildir.

Asıl başarı:

#### Savunma zincirinin gerçek sınırlarını ölçmek

olmalıdır.

### Blue Team DDoS Tatbikatında Ne Yapar?

Blue Team veya SOC tarafı saldırıyı tespit etmeye ve müdahale etmeye çalışır.

Şu sorular ölçülür:

Alarm geldi mi?

Saldırı doğru sınıflandırıldı mı?

Hangi servis hedeflendi?

Mitigation ne zaman başladı?

Network ekibi ne zaman bilgilendirildi?

Bu süreç savunmanın gerçek operasyonel performansını gösterir.

### Purple Team DDoS Tatbikatında Nasıl Kullanılır?

DDoS simülasyonu sonrasında Red Team ve Blue Team birlikte sonuçları analiz edebilir.

Örneğin:

Red Team UDP Flood gönderdi.

NDR gördü.

SIEM alarm üretmedi.

Bu durumda bir detection gap bulunmuştur.

Purple Team bu eksikliği giderir.

Ardından aynı saldırı tekrar test edilir.

Bu yaklaşım **Continuous Security Improvement** sağlar.

### SOC'a Tatbikat Önceden Söylenmeli mi?

Tatbikat amacına bağlıdır.

İki temel model olabilir.

#### White Team / Informed Exercise

SOC tatbikatın zamanını ve kapsamını bilir.

Amaç teknik kontrolleri doğrulamaktır.

#### Blind / Semi-Blind Exercise

SOC tüm detayları bilmez.

Amaç gerçek tespit ve Incident Response performansını ölçmektir.

Her iki model de farklı değer sağlar.

### White Team Nedir?

White Team tatbikatın güvenli ve kontrollü yürütülmesinden sorumlu koordinasyon ekibidir.

Genellikle;

scope,

test timing,

stop condition,

risk management

konularını yönetir.

White Team gerektiğinde tatbikatı durdurabilir.

### Blind DDoS Exercise Nedir?

Blind tatbikatta SOC saldırının hangi zamanda başlayacağını bilmeyebilir.

Bu model gerçek detection performansını ölçmek için değerlidir.

Ancak production riskleri nedeniyle kontrollü yürütülmelidir.

Üst yönetim ve ilgili White Team her zaman tatbikatı bilmeli ve onaylamalıdır.

### Tabletop Exercise Nedir?

**Tabletop Exercise**, gerçek saldırı trafiği üretmeden ekiplerin DDoS senaryosu üzerinden karar süreçlerini test ettiği tatbikattır.

Örneğin moderatör:

**“Saat 09:12'de ödeme servisine 40 Gbps saldırı başladı ve müşteri hataları %20 arttı.”**

der.

Ekipler ne yapacaklarını açıklar.

Bu yöntem özellikle;

Incident Response,

Management,

Communication,

Business Continuity

süreçlerini test etmek için faydalıdır.

### Teknik DDoS Testi ile Tabletop Nasıl Birleştirilir?

En güçlü tatbikat modellerinden biri ikisini aynı anda kullanmaktır.

Örneğin teknik test ekibi gerçek kontrollü Layer 7 trafik üretir.

SOC alarmı görür.

Network ekibi mitigation başlatır.

Incident Commander War Room açar.

Yönetim bilgilendirilir.

Bu sayede:

**People + Process + Technology**

aynı anda test edilmiş olur.

### DDoS Tatbikat Senaryosu Nasıl Tasarlanır?

Senaryo kurumun risk profiline göre hazırlanmalıdır.

Örneğin:

#### Senaryo 1 – Volumetric DDoS

Amaç:

Upstream ve Anti-DDoS kapasitesini test etmek.

#### Senaryo 2 – SYN Flood

Amaç:

Firewall ve connection kapasitesini ölçmek.

#### Senaryo 3 – HTTP Flood

Amaç:

WAF ve application dayanıklılığını ölçmek.

#### Senaryo 4 – API DDoS

Amaç:

API Gateway ve backend'i değerlendirmek.

#### Senaryo 5 – DNS DDoS

Amaç:

DNS resilience seviyesini test etmek.

Bu senaryolar tek tek veya aşamalı uygulanabilir.

### Multi-Vector DDoS Tatbikatı Nedir?

Gerçek saldırılar tek bir yöntem kullanmak zorunda değildir.

Örneğin:

#### UDP Flood

#### SYN Flood

#### HTTP Flood

aynı anda gerçekleştirilebilir.

Multi-Vector tatbikatı savunma ekiplerinin aynı anda birden fazla saldırı tipini yönetme kabiliyetini ölçer.

Bu model özellikle gelişmiş kurumlar için değerlidir.

### Attack Ramp-Up Nasıl Yapılmalıdır?

Trafik bir anda maksimum seviyeye çıkarılmamalıdır.

Örneğin:

Aşama 1 → düşük trafik

Aşama 2 → orta trafik

Aşama 3 → yüksek trafik

Aşama 4 → hedef kapasite

şeklinde ilerlenebilir.

Her aşamada güvenlik ve performans telemetry'si kontrol edilir.

Bu yaklaşım güvenli test sağlar.

### Burst Scenario Neden Test Edilmelidir?

Gerçek saldırgan her zaman trafiği yavaş artırmaz.

Bazen saniyeler içerisinde yoğun saldırı başlayabilir.

Bu nedenle kısa süreli **Burst Scenario** uygulanabilir.

Bu senaryo özellikle;

Anti-DDoS detection time,

autoscaling,

rate limit

performansını ölçer.

### Sustained DDoS Scenario Neden Önemlidir?

Bazı saldırılar saatlerce devam edebilir.

Sistem ilk 5 dakika dayanabilir.

Ama 40 dakika sonra;

memory,

connection backlog,

database,

cloud cost

problemleri oluşabilir.

Bu nedenle belirli bir trafik seviyesinin kontrollü olarak daha uzun süre korunması da değerlendirilebilir.

### DDoS Tatbikatında Baseline Nasıl Kullanılır?

Test öncesi normal değerler kayıt altına alınmalıdır.

Örneğin:

Normal bandwidth: 1,5 Gbps

Normal PPS: 180.000

Normal RPS: 2.200

Normal response time: 220 ms

Normal 5xx rate: %0,2

Test sırasında bunlarla karşılaştırma yapılır.

Bu sayede saldırının gerçek etkisi daha net görülür.

### DDoS Tatbikatında Hangi KPI'lar Ölçülmelidir?

Önemli teknik ve operasyonel KPI'lar şunlardır:

#### Maximum Sustainable Gbps

#### Maximum Sustainable PPS

#### Maximum CPS

#### Maximum RPS

#### Maximum DNS QPS

#### Time to Detect

#### Time to Mitigate

#### Time to Recover

#### Legitimate Traffic Success Rate

#### False Positive Rate

#### Service Availability

Bu metrikler tatbikat sonucunu objektif hale getirir.

### Maximum Sustainable Capacity Nedir?

Bu kavram sistemin SLA sınırları içerisinde sürdürülebilir şekilde taşıyabildiği maksimum saldırı seviyesini ifade eder.

Örneğin uygulama:

12.000 RPS

taşıyor olabilir.

Ama 8.000 RPS üzerinde response time SLA dışına çıkıyorsa gerçek sürdürülebilir kapasite:

8.000 RPS

olarak değerlendirilebilir.

Bu nedenle kapasite sadece “çökme noktası” değildir.

### Time to Detect Nasıl Ölçülür?

Örneğin:

09:15:00 → saldırı başladı.

09:15:24 → Anti-DDoS alarm verdi.

09:15:41 → SOC incident açtı.

Bu durumda farklı detection süreleri raporlanabilir.

Amaç SOC'un saldırıyı ne kadar erken gördüğünü ölçmektir.

### Time to Mitigate Nasıl Ölçülür?

Saldırı başladıktan sonra gerçek etkili filtrelemenin ne zaman başladığı ölçülür.

Örneğin:

09:15 → saldırı başladı.

09:16 → tespit edildi.

09:17:30 → Scrubbing aktif.

09:18 → servis normal.

Bu değer DDoS protection sisteminin gerçek operasyonel hızını gösterir.

### Time to Recover Neden Ayrı Bir KPI'dır?

Mitigation çalışmaya başladıktan sonra sistem hemen normal hale dönmeyebilir.

Örneğin;

database queue,

connection backlog,

autoscaling,

cache

gibi kaynakların normale dönmesi zaman alabilir.

Bu nedenle Recovery Time ayrıca ölçülmelidir.

### Legitimate Traffic Success Rate Nasıl Ölçülür?

Tatbikat sırasında gerçek kullanıcı davranışını simüle eden synthetic transaction'lar çalıştırılabilir.

Örneğin;

login,

ürün arama,

ödeme,

API işlem

sürekli denenebilir.

Saldırı altında bu işlemlerin başarı oranı ölçülür.

Amaç saldırının değil, kullanıcı deneyiminin etkisini anlamaktır.

### Synthetic User Nedir?

**Synthetic User**, otomatik olarak gerçek kullanıcı işlemlerini simüle eden test istemcisidir.

Örneğin her 30 saniyede;

web sitesini açabilir,

login olabilir,

işlem gerçekleştirebilir.

DDoS tatbikatında bu trafik saldırıdan bağımsız tutulur.

Böylece legitimate user availability ölçülür.

### Real User Monitoring Kullanılmalı mı?

Production ortamındaki kontrollü testlerde **Real User Monitoring – RUM** çok değerli olabilir.

RUM;

gerçek kullanıcı response time,

page load,

error,

transaction

bilgilerini gösterir.

Infrastructure sağlıklı görünürken kullanıcı deneyiminin bozulduğunu ortaya çıkarabilir.

### APM DDoS Tatbikatında Nasıl Kullanılır?

Application Performance Monitoring;

backend response,

database query,

thread pool,

dependency latency

gibi metrikleri gösterir.

Layer 7 testlerde gerçek darboğazın bulunması açısından kritiktir.

### DDoS Tatbikatında War Room Açılmalı mı?

Kapsamlı tatbikatlarda evet.

War Room içerisinde;

Incident Commander,

SOC,

Network,

Application,

Cloud,

Business

ekipleri birlikte çalışabilir.

Amaç herkesin aynı incident timeline ve dashboard üzerinden karar vermesidir.

### War Room Performansı Nasıl Ölçülür?

Tatbikatta sadece teknik performans değil iletişim performansı da değerlendirilebilir.

Örneğin:

Saldırıdan kaç dakika sonra War Room açıldı?

Incident Commander belirlendi mi?

Network ekibine ne kadar sürede ulaşıldı?

Yönetim ne zaman bilgilendirildi?

Bu metrikler süreç olgunluğunu gösterir.

### DDoS Tatbikatında Yönetim Nasıl Dahil Edilmelidir?

Yönetimin packet analizine katılması gerekmez.

Ancak iş etkisi üzerinden karar vermesi gereken senaryolar oluşturulabilir.

Örneğin:

Müşteri portalı 15 dakikadır yavaş.

Gelir etkisi artıyor.

CDN emergency challenge açılırsa kullanıcı deneyimi etkilenebilir.

Yönetim hangi riski kabul edecek?

Bu tür kararlar Tabletop Exercise için değerlidir.

### Crisis Communication Test Edilmeli mi?

Özellikle kritik kurumlarda evet.

Tatbikatta;

müşteri bildirimi,

status page,

yönetim update,

partner communication

gibi süreçler simüle edilebilir.

Ama gerçek müşterilere yanlışlıkla test mesajı gönderilmemelidir.

Tatbikat kanalları ayrıştırılmalıdır.

### ISP ve Anti-DDoS Sağlayıcısı Tatbikata Dahil Edilmeli mi?

Mümkünse evet.

Çünkü gerçek saldırıda bu ekiplerle koordinasyon gerekecektir.

Örneğin;

ISP NOC,

Scrubbing provider,

Cloud Security provider

süreçleri test edilebilir.

Bu sayede SLA'ların gerçekten çalışıp çalışmadığı da görülür.

### Third-Party SLA Testi Neden Önemlidir?

Sözleşmede:

**“15 dakika içinde müdahale.”**

yazıyor olabilir.

Ama gerçek tatbikatta sağlayıcıya ulaşmak 40 dakika sürüyorsa operasyonel risk vardır.

Bu nedenle DDoS tatbikatı aynı zamanda üçüncü taraf hizmet kalitesini de doğrular.

### DDoS Tatbikatında Cloud Maliyeti Ölçülmeli mi?

Cloud uygulamalarında mutlaka değerlendirilmelidir.

Tatbikat sırasında;

instance sayısı,

serverless invocation,

data transfer,

database consumption

artabilir.

Bu değerler EDoS riskini gösterir.

Tatbikat raporunda teknik performansla birlikte maliyet etkisi de gösterilebilir.

### Tatbikatta Üretim Ortamına Zarar Vermeden Nasıl Test Yapılır?

Bunun temel yolları;

kademeli trafik artırımı,

Stop Condition,

Kill Switch,

dar kapsam,

kısa süre,

sürekli monitoring

kullanımıdır.

Ayrıca kritik iş saatleri dışı tercih edilebilir.

Ancak bazı kurumlar gerçek peak dönem davranışını test etmek isteyebilir.

Bu durumda risk kabulü ve yönetim onayı açık olmalıdır.

### DDoS Tatbikatında Loglama Neden Kritik?

Test sırasında bütün telemetry'nin kayıt altında olması gerekir.

Örneğin;

WAF logs,

Firewall logs,

Anti-DDoS logs,

NetFlow,

Application logs,

DNS logs,

SOC timeline

saklanmalıdır.

Bu veriler post-exercise analysis için kullanılır.

### Tatbikat Sonrası Timeline Nasıl Oluşturulur?

Örneğin:

**10:00:00** Test başladı.

**10:00:18** NDR alarm üretti.

**10:00:26** Anti-DDoS saldırıyı sınıflandırdı.

**10:01:02** SOC incident oluşturdu.

**10:01:45** Network bilgilendirildi.

**10:02:10** Mitigation başladı.

**10:02:55** Kullanıcı başarısı normale döndü.

Bu timeline sürecin gerçek performansını gösterir.

### Detection Gap Nedir?

Tatbikat sırasında gerçekleştirilen bir saldırı tekniği hiçbir alarm üretmiyorsa **Detection Gap – Tespit Boşluğu** bulunabilir.

Örneğin:

HTTP Flood backend'i etkiledi.

Ama WAF ve SIEM alarm üretmedi.

Bu durumda detection use case geliştirilmelidir.

Tatbikatın en değerli çıktılarından biri bu boşluklardır.

### Control Gap Nedir?

Bir güvenlik kontrolünün bulunması ancak saldırıya karşı etkisiz kalması durumunda **Control Gap** ortaya çıkabilir.

Örneğin WAF var.

Ama API endpoint'i WAF kapsamına alınmamış.

Bu bir ürün eksikliğinden çok konfigürasyon boşluğudur.

### Process Gap Nedir?

Teknik kontroller doğru çalışıyor olabilir.

Ama süreç gecikmiş olabilir.

Örneğin Anti-DDoS saldırıyı 20 saniyede tespit etti.

SOC alarmı 12 dakika sonra gördü.

Bu durumda sorun teknik değil süreç veya operasyon olabilir.

Bu bir **Process Gap** olarak değerlendirilebilir.

### People Gap Nedir?

Ekiplerin rollerinin veya uzmanlığının yetersiz olduğu durumlar da tatbikatta ortaya çıkabilir.

Örneğin SOC alarmı gördü ama hangi provider ile iletişime geçileceğini bilmiyor.

Bu durumda eğitim veya runbook ihtiyacı olabilir.

Dolayısıyla DDoS tatbikatı sadece teknolojiyi değil insan faktörünü de ölçer.

### Tatbikat Sonrası Hot Wash Nedir?

**Hot Wash**, tatbikat tamamlandıktan hemen sonra ekiplerin kısa değerlendirme toplantısı yapmasıdır.

Sorular basittir:

Ne iyi çalıştı?

Ne zorladı?

Nerede zaman kaybettik?

Ne beklediğimiz gibi çalışmadı?

Bu bilgiler daha sonra detaylı Post-Exercise Report'a dönüştürülebilir.

### Post-Exercise Review Nasıl Yapılmalıdır?

Tatbikat sonrası tüm telemetry ve ekip geri bildirimleri değerlendirilir.

Amaç şu sorulara cevap vermektir:

#### Saldırıları doğru tespit ettik mi?

#### Mitigation yeterli miydi?

#### Gerçek kullanıcılar etkilendi mi?

#### Kritik darboğaz neydi?

#### İletişim süreçleri çalıştı mı?

#### Hangi kontroller geliştirilmelidir?

Bu analiz tatbikatı gerçek güvenlik yatırımına dönüştürür.

### DDoS Tatbikat Raporunda Neler Olmalıdır?

Profesyonel rapor hem teknik ekip hem yönetim tarafından kullanılabilmelidir.

Önerilen yapı:

#### Executive Summary

Genel dayanıklılık sonucu.

#### Objectives

Tatbikatın amaçları.

#### Scope

Test edilen servisler.

#### Architecture

DDoS savunma mimarisi.

#### Attack Scenarios

Uygulanan senaryolar.

#### Traffic Metrics

Gbps, PPS, CPS, RPS ve QPS.

#### Attack Timeline

Kronolojik saldırı hikâyesi.

#### Detection Results

SOC ve güvenlik ürünlerinin performansı.

#### Mitigation Results

Savunmanın etkinliği.

#### Business Impact

Kullanıcı ve servis etkisi.

#### Detection / Control / Process Gaps

Tespit edilen boşluklar.

#### Remediation Roadmap

İyileştirme planı.

### Executive Summary Nasıl Yazılmalıdır?

Yönetim için özet teknik detaylardan çok risk ve sonuç odaklı olmalıdır.

Örneğin:

**“Gerçekleştirilen DDoS tatbikatında kritik müşteri platformu volumetric saldırı senaryolarında erişilebilirliğini korumuştur. Layer 7 API senaryosunda ise 7.200 RPS üzerinde response time SLA dışına çıkmış ve API Gateway üzerinde kapasite darboğazı tespit edilmiştir. Anti-DDoS tespit süresi 24 saniye, SOC doğrulama süresi 2 dakika 18 saniye olarak ölçülmüştür.”**

Bu çıktı yönetim için anlamlıdır.

### DDoS Attack Path Kavramı Kullanılır mı?

DDoS saldırıları klasik privilege escalation attack path mantığından farklıdır.

Ancak hizmet kesintisine giden teknik yol görselleştirilebilir.

Örneğin:

#### Botnet

↓

#### Internet

↓

#### CDN

↓

#### WAF

↓

#### API Gateway

↓

#### Authentication Service

↓

#### Database

↓

#### Service Degradation

Bu görsel hangi noktada savunmanın başarısız olduğunu göstermeye yardımcı olur.

### Bottleneck Map Nedir?

Tatbikat sonucunda sistemin kapasite sınırlarını gösteren bir harita oluşturulabilir.

Örneğin:

ISP → 20 Gbps

Firewall → 8 Mpps

WAF → 20.000 RPS

Application → 12.000 RPS

Database → 8.500 RPS

Bu durumda Layer 7 saldırısındaki asıl darboğaz database olabilir.

Bu bilgi yatırım kararını doğrudan etkiler.

### DDoS Resilience Score Oluşturulabilir mi?

Evet.

Ancak skor gerçek teknik ölçümlere dayanmalıdır.

Örneğin şu alanlar puanlanabilir:

#### Network Resilience

#### Application Resilience

#### DNS Resilience

#### Detection Capability

#### Mitigation Capability

#### Incident Response

#### Recovery

#### Business Continuity

Sonuç örneğin:

#### DDoS Resilience Score: 78/100

şeklinde verilebilir.

Ama altındaki teknik bulgular mutlaka raporda bulunmalıdır.

### RAG – Red Amber Green Modeli Kullanılabilir mi?

Yönetim sunumlarında basit durum gösterimi için kullanılabilir.

Örneğin:

#### Network Protection – Green

#### Layer 7 Protection – Amber

#### DNS Resilience – Green

#### SOC Response – Amber

#### Incident Communication – Red

Bu yapı öncelikleri hızlı biçimde görünür hale getirir.

### Remediation Roadmap Nasıl Oluşturulmalıdır?

Tüm bulgular aynı öncelikte değildir.

Örneğin;

#### Critical

Origin IP doğrudan erişilebilir.

#### High

Layer 7 API rate limit bulunmuyor.

#### Medium

SOC alarm escalation süresi yüksek.

#### Low

Dashboard görünürlüğü geliştirilebilir.

Her aksiyon için;

owner,

priority,

target date

belirlenmelidir.

### Quick Wins Nedir?

Bazı iyileştirmeler düşük maliyetle yüksek risk azaltımı sağlayabilir.

Örneğin;

origin IP erişimini sınırlandırmak,

acil iletişim listesini güncellemek,

WAF rate limit eklemek,

SIEM alarmını düzenlemek

quick win olabilir.

DDoS raporunda bu aksiyonlar ayrı gösterilebilir.

### Strategic Improvements Nedir?

Bazı eksikler daha uzun vadeli yatırım gerektirir.

Örneğin;

yeni Anti-DDoS sağlayıcısı,

multi-region architecture,

Anycast DNS,

ikinci ISP,

yeni WAF platformu

stratejik iyileştirme olabilir.

Rapor kısa ve uzun vadeli aksiyonları ayırmalıdır.

### Retest Neden Gereklidir?

Bir bulgunun düzeltildiğini söylemek yeterli değildir.

Tekrar test edilmelidir.

Örneğin API Gateway rate limit geliştirildi.

Aynı Layer 7 senaryosu yeniden uygulanır.

Eğer service availability korunuyorsa remediation doğrulanmış olur.

Bu yaklaşım **Security Validation** sürecini tamamlar.

### Continuous DDoS Security Validation Nedir?

Tek bir yıllık test yerine güvenlik kontrollerinin düzenli olarak tekrar doğrulanmasıdır.

Özellikle;

WAF rule değişikliği,

firewall değişimi,

cloud migration,

yeni uygulama,

yeni ISP,

Anti-DDoS değişimi

sonrasında yeniden test yapılabilir.

Çünkü DDoS dayanıklılığı sabit değildir.

### DDoS Tatbikatı Ne Sıklıkla Yapılmalıdır?

Tek bir evrensel süre yoktur.

Kurumun riskine göre belirlenir.

Kritik dijital servisler için periyodik tatbikat yapılması mantıklıdır.

Ayrıca;

büyük mimari değişiklik,

yeni cloud geçişi,

provider değişikliği

sonrasında tatbikat tekrarlanabilir.

### Threat Intelligence Tatbikat Senaryolarını Nasıl Güçlendirir?

Sektörde görülen güncel DDoS yöntemleri takip edilerek senaryolar güncellenebilir.

Örneğin threat intelligence;

belirli botnet'lerin,

Layer 7 saldırı trendlerinin,

Ransom DDoS faaliyetlerinin

arttığını gösteriyorsa tatbikatta bu alanlara daha fazla ağırlık verilebilir.

Bu yaklaşım **Threat-Informed DDoS Testing** olarak değerlendirilebilir.

### DDoS Tatbikatı Regülasyon ve Denetim Açısından Faydalı mıdır?

Kuruma ve sektöre bağlı olarak erişilebilirlik, iş sürekliliği ve siber dayanıklılık gereksinimlerinin doğrulanmasına katkı sağlayabilir.

Ancak bir DDoS tatbikatı tek başına belirli bir standardın bütün gereksinimlerini karşıladığı anlamına gelmez.

Asıl değer teknik kontrollerin ve iş sürekliliği süreçlerinin gerçekten uygulanabilir olduğunun gösterilmesidir.

### DDoS Tatbikatı Penetrasyon Testinin Yerine Geçer mi?

Hayır.

İki çalışma farklı riskleri ölçer.

Pentest ağırlıklı olarak;

security weakness,

unauthorized access,

data exposure

risklerini değerlendirir.

DDoS tatbikatı ise;

availability,

resilience,

capacity,

response

üzerinde yoğunlaşır.

Bu nedenle güvenlik programında birbirini tamamlayan çalışmalar olarak düşünülmelidir.

### DDoS Tatbikatı ile Business Continuity Exercise Arasındaki İlişki

DDoS tatbikatı teknik siber saldırı simülasyonudur.

Ancak hizmet etkisi oluştuğunda Business Continuity süreçlerini de tetikleyebilir.

Örneğin;

müşteri portalı çalışmıyor.

Alternatif kanal devreye alınacak mı?

Call center kapasitesi artırılacak mı?

Status page kullanılacak mı?

Bu sorular BCP süreçleriyle ilişkilidir.

### DDoS Tatbikatı Siber Dayanıklılığı Nasıl Ölçer?

Gerçek siber dayanıklılık dört temel soruyla düşünülebilir:

#### Prevent

Saldırıyı engelleyebiliyor musunuz?

#### Detect

Saldırıyı görebiliyor musunuz?

#### Respond

Doğru müdahaleyi yapabiliyor musunuz?

#### Recover

Hizmeti normale döndürebiliyor musunuz?

DDoS tatbikatı bu dört alanı aynı anda ölçebilir.

### Kurumsal DDoS Dayanıklılık Stratejisi Nasıl Oluşturulur?

Güçlü bir strateji şu katmanlardan oluşabilir:

#### \1. Asset Discovery

Kritik internet servisleri belirlenir.

#### \2. Risk Assessment

DDoS tehditleri analiz edilir.

#### \3. Protection Architecture

Firewall, WAF, CDN ve Anti-DDoS planlanır.

#### \4. Detection

SOC, SIEM ve NDR use case'leri oluşturulur.

#### \5. Incident Response

Playbook ve Escalation Matrix hazırlanır.

#### \6. Testing

DDoS saldırı simülasyonu yapılır.

#### \7. Business Continuity

Kritik hizmet sürekliliği planlanır.

#### \8. Improvement

Sonuçlar doğrultusunda mimari geliştirilir.

#### \9. Retest

Kontroller tekrar doğrulanır.

Bu döngü DDoS güvenliğini tek seferlik projeden çıkarıp sürekli güvenlik sürecine dönüştürür.

### DDoS Protection Maturity Nedir?

Kurumların DDoS güvenliği farklı olgunluk seviyelerinde olabilir.

Örneğin:

#### Seviye 1 – Reactive

Saldırı olunca müdahale edilir.

#### Seviye 2 – Protected

Anti-DDoS ve WAF gibi kontroller vardır.

#### Seviye 3 – Monitored

SOC ve SIEM üzerinden sürekli izlenir.

#### Seviye 4 – Validated

Düzenli DDoS testleri gerçekleştirilir.

#### Seviye 5 – Resilient

Teknik, operasyonel ve business continuity süreçleri birlikte sürekli doğrulanır.

Amaç yalnızca ürün sahibi olmak değil, doğrulanmış dayanıklılık seviyesine ulaşmaktır.

### Kurumsal DDoS Tatbikatının En Büyük Değeri Nedir?

Tatbikat size saldırının mümkün olup olmadığını söylemekten daha fazlasını sağlar.

Şunu gösterir:

#### Saldırı gerçekleştiğinde gerçekten ne oluyor?

Kağıt üzerinde 100 Gbps Anti-DDoS olabilir.

Ancak 3 milyon PPS'te firewall darboğaza giriyor olabilir.

WAF aktif olabilir.

Ama API endpoint'i kapsam dışında olabilir.

SOC çalışıyor olabilir.

Ama alarm yanlış severity ile açılıyor olabilir.

ISP anlaşması bulunabilir.

Ama acil telefon numarası güncel olmayabilir.

Tatbikat bu görünmeyen boşlukları ortaya çıkarır.

### Sonuç: DDoS Dayanıklılığı Satın Alınmaz, Test Edilerek Oluşturulur

Kurumsal DDoS güvenliğinde en büyük hata bir teknoloji satın alındığında problemin çözüldüğünü düşünmektir.

Anti-DDoS önemlidir.

CDN önemlidir.

WAF önemlidir.

Firewall önemlidir.

NDR ve SIEM önemlidir.

Ancak bunların hiçbiri tek başına **DDoS Resilience** anlamına gelmez.

Gerçek dayanıklılık şu sorulara verilen cevaplarda ortaya çıkar:

#### Saldırıyı ne kadar hızlı gördünüz?

#### Hangi noktada filtrelediniz?

#### Gerçek kullanıcılar hizmet almaya devam etti mi?

#### İlk darboğaz nerede oluştu?

#### SOC doğru zamanda harekete geçti mi?

#### ISP ve Anti-DDoS sağlayıcısına ulaşabildiniz mi?

#### Yönetim doğru bilgiyi zamanında aldı mı?

#### Saldırı bittiğinde sistem ne kadar hızlı toparlandı?

Ve en önemlisi:

#### Aynı saldırı bir ay sonra tekrar edilirse sonuç daha iyi olacak mı?

İşte kurumsal DDoS tatbikatının gerçek değeri bu son sorudadır.

Çünkü güvenlikte olgunluk yalnızca saldırıyı engellemek değildir.

**Her testten sonra daha dayanıklı hale gelmektir.**

Kurumsal bir DDoS dayanıklılık programı;

#### DDoS Risk Assessment

↓

#### Protection Architecture

↓

#### DDoS Simulation

↓

#### SOC & Incident Response Validation

↓

#### Business Impact Analysis

↓

#### Remediation

↓

#### Retest

döngüsüyle yönetildiğinde, DDoS güvenliği tek seferlik bir teknik çalışma olmaktan çıkar.

**Sürekli ölçülen bir siber dayanıklılık kabiliyetine dönüşür.**

Ve böylece 12 bölümlük **Kurumsal DDoS Saldırı Simülasyonu** yazı dizisinin temel sorusuna cevap vermiş oluruz:

#### Kurumunuz bir DDoS saldırısına ne kadar dayanabilir?

Bu sorunun cevabı ürün kataloğunda bulunmaz.

**Gerçekçi, kontrollü ve ölçülebilir bir DDoS tatbikatında bulunur.**