# DDoS Incident Response Nedir? Saldırı Anında Kurumlar Ne Yapmalı?

**URL:** https://securesys.com.tr/tr/bilgi-merkezi/ddos-simulasyonu/ddos-incident-response-nedir

![DDoS Incident Response Nedir? Saldırı Anında Kurumlar Ne Yapmalı?](/images/bilgi-merkezi/covers/cover-ddos-11.webp)

Bir DDoS saldırısında teknik kapasite kadar önemli başka bir konu daha vardır:

**Müdahale hızı.**

Kurumun Anti-DDoS hizmeti olabilir.

WAF çalışıyor olabilir.

CDN devrede olabilir.

SOC saldırıyı görebilir.

Ancak saldırı sırasında kimin ne yapacağı belli değilse değerli dakikalar kaybedilebilir.

DDoS olaylarında özellikle ilk dakikalar önemlidir.

Çünkü saldırı kısa sürede;

internet hattını,

DNS servislerini,

web uygulamasını,

API'leri,

VPN altyapısını,

müşteri portalını

etkileyebilir.

Bu nedenle kurumların saldırı gerçekleşmeden önce hazırlanmış bir **DDoS Incident Response Planı**, **DDoS Playbook**, **Escalation Matrix** ve **War Room süreci** bulunmalıdır.

DDoS Incident Response'ın temel amacı yalnızca saldırı trafiğini durdurmak değildir.

Asıl hedef;

**kritik hizmetleri erişilebilir tutmak, saldırının iş etkisini sınırlandırmak, doğru ekipleri hızlı şekilde koordine etmek ve sistemi güvenli biçimde normale döndürmektir.**

#### DDoS Incident Response Nedir?

**DDoS Incident Response**, Distributed Denial of Service saldırısının tespit edilmesinden hizmetlerin normale dönmesine kadar yürütülen teknik ve operasyonel müdahale sürecidir.

Bu süreç genel olarak şu aşamalardan oluşur:

#### Detection

Saldırının tespit edilmesi.

#### Validation

Gerçek DDoS saldırısı olduğunun doğrulanması.

#### Classification

Volumetric, L3/L4, Layer 7 veya DNS gibi saldırı tipinin belirlenmesi.

#### Mitigation

Saldırı etkisini azaltacak kontrollerin devreye alınması.

#### Communication

Teknik ekipler, yönetim ve üçüncü taraflarla koordinasyon.

#### Recovery

Servislerin normal çalışma seviyesine döndürülmesi.

#### Post-Incident Review

Olayın analiz edilmesi ve iyileştirme çalışmalarının yapılması.

Bu yapı sayesinde DDoS müdahalesi plansız bir krizden kontrollü bir güvenlik operasyonuna dönüşür.

### DDoS Saldırısında İlk Yapılması Gereken Nedir?

İlk adım paniğe kapılmak veya hemen rastgele firewall kuralı yazmak değildir.

Öncelikle olay doğrulanmalıdır.

SOC ve Network ekipleri şu sorulara bakmalıdır:

#### Trafik gerçekten normalin üzerinde mi?

#### Hangi servis etkileniyor?

#### Gerçek kullanıcılar hizmet alamıyor mu?

#### Bandwidth mi yükseldi?

#### PPS veya CPS mi arttı?

#### HTTP RPS mi yükseldi?

#### DNS QPS anormal mi?

#### WAF veya Anti-DDoS alarm üretti mi?

Bu bilgiler saldırının türünü anlamaya yardımcı olur.

Yanlış sınıflandırma yanlış mitigation kararlarına yol açabilir.

### DDoS Saldırısının İlk 5 Dakikası

İlk dakikalarda amaç saldırının kapsamını hızlı şekilde belirlemektir.

Örneğin ilk 5 dakika içerisinde şu kontroller yapılabilir:

#### \1. Alarm doğrulanır

SOC alarmın gerçek olup olmadığını kontrol eder.

#### \2. Etkilenen servis belirlenir

Web sitesi mi?

API mi?

DNS mi?

VPN mi?

#### \3. Trafik profili incelenir

Gbps, PPS, CPS, RPS veya QPS değerleri kontrol edilir.

#### \4. Kullanıcı etkisi değerlendirilir

Latency, timeout ve error rate izlenir.

#### \5. Anti-DDoS durumu kontrol edilir

Mitigation devreye girdi mi?

Bu ilk analiz saldırının sonraki müdahale adımını belirler.

### İlk 15 Dakikada Ne Yapılmalı?

Saldırı doğrulandıktan sonra teknik koordinasyon başlamalıdır.

Bu aşamada;

SOC,

Network,

Application,

ISP,

Anti-DDoS sağlayıcısı

iletişime geçebilir.

Özellikle volumetric saldırıda saldırının kurumun internet hattını tüketme riski varsa upstream mitigation hızlı şekilde değerlendirilmelidir.

Layer 7 saldırıda ise;

WAF,

Bot Management,

Rate Limiting,

application protection

mekanizmaları daha öncelikli olabilir.

### İlk 60 Dakika Neden Kritiktir?

Uzun süren DDoS saldırılarında yalnızca teknik filtering yeterli olmayabilir.

İlk bir saat içerisinde;

iş etkisi,

müşteri etkisi,

SLA durumu,

yedek servisler,

failover seçenekleri,

yönetim iletişimi

de değerlendirilmelidir.

Saldırı kritik dijital hizmetleri etkiliyorsa olay teknik incident'tan kurumsal kriz seviyesine çıkabilir.

### DDoS Severity Nasıl Belirlenir?

Bütün DDoS saldırıları aynı seviyede değildir.

Örneğin basit bir sınıflandırma şöyle olabilir:

#### Low

Saldırı tespit edildi ancak kullanıcı etkisi yok.

#### Medium

Performans düşüşü var ancak servis erişilebilir.

#### High

Kritik servislerde belirgin kullanıcı etkisi var.

#### Critical

Hizmet kesintisi, ciddi SLA ihlali veya geniş iş etkisi mevcut.

Severity belirlenirken sadece trafik hacmi kullanılmamalıdır.

En önemli kriter **business impact** olmalıdır.

### 100 Gbps Saldırı Her Zaman Critical mıdır?

Hayır.

Eğer edge Anti-DDoS platformu 100 Gbps saldırıyı tamamen temizliyor ve gerçek kullanıcılar etkilenmiyorsa operasyonel etki sınırlı olabilir.

Buna karşılık 100 Mbps Layer 7 saldırısı ödeme API'sini tamamen durdurabilir.

Bu nedenle:

#### Attack Size ≠ Business Impact

olarak düşünmek gerekir.

### DDoS Playbook Nedir?

**DDoS Playbook**, saldırı tespit edildiğinde izlenecek müdahale sürecini önceden tanımlar.

Playbook içerisinde;

alarm doğrulama adımları,

saldırı sınıflandırması,

escalation,

mitigation,

provider iletişimi,

recovery,

raporlama

süreçleri bulunabilir.

İyi bir playbook saldırı sırasında düşünme süresini azaltır.

### DDoS Runbook Nedir?

Runbook genellikle daha teknik ve adım adım işlemleri tanımlar.

Örneğin SOC analisti için:

**\1. Anti-DDoS portalını kontrol et.**

**\2. NetFlow verisini doğrula.**

**\3. Etkilenen destination IP'yi belirle.**

**\4. Application Health Dashboard'u kontrol et.**

**\5. Incident severity oluştur.**

gibi adımlar bulunabilir.

Playbook genel operasyonu, runbook ise belirli görevleri yönlendirebilir.

### Escalation Matrix Nedir?

**Escalation Matrix**, olayın hangi seviyede hangi ekip veya yöneticilere bildirileceğini belirleyen yapıdır.

Örneğin:

#### Severity 2

SOC + Network.

#### Severity 1

SOC + Network + Application + Management.

#### Critical

Executive Management + Legal + Communications + Provider.

Bu yapı özellikle büyük kurumlarda iletişim karmaşasını azaltır.

### DDoS Incident Commander Kim Olmalı?

Büyük güvenlik olaylarında koordinasyonu yöneten bir kişi bulunması faydalıdır.

Bu role **Incident Commander** denilebilir.

Incident Commander'ın görevi;

bütün teknik işlemleri kendisinin yapmak

değildir.

Görevi;

ekipleri koordine etmek,

kararları takip etmek,

öncelikleri belirlemek,

iletişimi yönetmek

olmalıdır.

DDoS sırasında bu rol özellikle önemlidir.

### War Room Nedir?

**War Room**, kritik olay sırasında farklı ekiplerin ortak çalışma ortamıdır.

Fiziksel veya sanal olabilir.

Katılımcılar;

SOC,

Network,

System,

Application,

Cloud,

ISP,

DDoS Provider,

Management

olabilir.

Amaç herkesin aynı veri ve incident timeline üzerinden çalışmasıdır.

### War Room'da Hangi Bilgiler Görülmelidir?

Ortak dashboard üzerinde;

#### Attack Volume

Gbps.

#### PPS

Packet rate.

#### CPS

Connection rate.

#### HTTP RPS

Application traffic.

#### DNS QPS

DNS load.

#### Application Health

Response time.

#### Mitigation Status

Anti-DDoS durumu.

#### Business Metrics

Login veya transaction success.

görülebilir.

Bu ortak görünüm ekipler arasındaki yanlış anlaşılmaları azaltır.

### Volumetric DDoS Olayında Ne Yapılmalı?

Volumetric saldırıda temel problem genellikle bandwidth tüketimidir.

Bu nedenle öncelikli kontroller;

ISP,

Anti-DDoS,

Scrubbing Center,

BGP diversion

olabilir.

Firewall üzerinde IP bloklamak çoğu zaman yeterli değildir.

Çünkü trafik hattı zaten dolduruyor olabilir.

Bu nedenle saldırı mümkün olduğunca upstream seviyede temizlenmelidir.

### Layer 3/4 DDoS Olayında Ne Yapılmalı?

Layer 3/4 saldırıda;

PPS,

CPS,

session table,

firewall CPU,

load balancer

değerleri incelenmelidir.

Saldırı tipine göre;

SYN protection,

connection limit,

protocol filtering,

scrubbing

gibi kontroller devreye alınabilir.

Ancak agresif limitler gerçek kullanıcıları etkileyebileceği için dikkatli uygulanmalıdır.

### Layer 7 DDoS Olayında Ne Yapılmalı?

Application Layer saldırılarında network bandwidth normal görünebilir.

Bu nedenle;

WAF,

CDN,

Bot Management,

API Gateway,

Application Monitoring

önemlidir.

Örneğin saldırı belirli endpoint'i hedefliyorsa;

rate limit,

temporary challenge,

request filtering,

load shedding

uygulanabilir.

### Rate Limiting Ne Zaman Devreye Alınmalı?

Rate limiting özellikle Layer 7 saldırılarda güçlü bir kontroldür.

Ancak saldırı sırasında aceleyle çok düşük threshold belirlemek gerçek müşterilerin bloklanmasına neden olabilir.

Bu nedenle mümkünse önceden hazırlanmış emergency rate-limit profilleri bulunmalıdır.

Örneğin normal:

1.000 request/minute

olan API için kriz anında farklı politika devreye alınabilir.

### Emergency WAF Rule Nedir?

Bazı kurumlar DDoS veya yoğun bot saldırıları için önceden hazırlanmış acil WAF kuralları oluşturabilir.

Örneğin;

belirli endpoint'e rate limit,

belirli geography için challenge,

şüpheli fingerprint için block

gibi.

Ancak acil kurallar production'a alınmadan önce etkileri bilinmelidir.

Aksi halde saldırgandan çok müşteriler etkilenebilir.

### Challenge Mode Ne Zaman Kullanılır?

Layer 7 saldırıda belirli trafik için;

CAPTCHA,

JavaScript Challenge,

browser verification

devreye alınabilir.

Bu yöntem bot trafiğini azaltabilir.

Ancak kullanıcı deneyimini etkiler.

Bu nedenle tüm siteye uygulamak yerine riskli trafik segmentlerine uygulanması daha uygun olabilir.

### API DDoS Incident Response

API saldırılarında;

API Gateway,

WAF,

application,

database

birlikte izlenmelidir.

Örneğin sadece RPS düşürmek yerine saldırganın hedeflediği endpoint geçici olarak kısıtlanabilir.

Ayrıca;

per-user,

per-tenant,

per-token

rate limit uygulanabilir.

Bu yöntem gerçek kullanıcı etkisini azaltabilir.

### DNS DDoS Incident Response

DNS saldırısında hızlı hareket etmek gerekir.

Çünkü DNS erişilemez olduğunda çok sayıda farklı servis aynı anda etkilenebilir.

Kontrol edilmesi gerekenler;

authoritative DNS,

QPS,

latency,

provider status,

secondary DNS,

Anycast nodes

olabilir.

Gerekirse secondary veya multi-provider DNS mimarisi devreye alınmalıdır.

### ISP ile Ne Zaman İletişime Geçilmelidir?

Volumetric saldırılarda mümkün olduğunca erken.

Özellikle saldırı kurum hattının kapasitesine yaklaşıyorsa ISP ile koordinasyon kritik hale gelir.

DDoS playbook içerisinde;

ISP NOC iletişim bilgileri,

support ticket yöntemi,

emergency phone,

customer ID

önceden bulunmalıdır.

Saldırı sırasında bu bilgilerin aranması zaman kaybettirir.

### Anti-DDoS Sağlayıcısıyla Koordinasyon

Managed Anti-DDoS hizmeti kullanılıyorsa saldırı sırasında sağlayıcıyla açık iletişim kanalı bulunmalıdır.

Örneğin;

saldırı tipi,

hedef IP,

attack peak,

mitigation status,

false positive

bilgileri paylaşılabilir.

Ayrıca SLA kapsamında provider'ın hangi sürede müdahale etmesi gerektiği önceden tanımlanmalıdır.

### On-Demand Scrubbing Ne Zaman Aktifleştirilmelidir?

On-Demand modelde trafik normalde kurumun kendi hattına gelir.

Saldırı threshold'u aşıldığında Scrubbing Center'a yönlendirilir.

Buradaki en kritik risk geç aktivasyondur.

Eğer hattın kapasitesi:

5 Gbps

ve saldırı:

20 Gbps

ise bağlantı çok hızlı doyabilir.

Bu nedenle diversion threshold gerçek trafik verilerine göre belirlenmelidir.

### Always-On Korumanın Incident Response Avantajı

Always-On modelde trafik zaten koruma altyapısından geçtiği için ayrıca yönlendirme beklenmez.

Bu nedenle Time to Mitigate daha düşük olabilir.

Özellikle bankacılık, e-ticaret veya kritik SaaS servislerinde bu avantaj önemli olabilir.

### RTBH Ne Zaman Kullanılır?

**Remotely Triggered Black Hole – RTBH**, belirli hedefe giden bütün trafiğin upstream seviyede drop edilmesini sağlayabilir.

Bu durumda saldırı kurumun diğer network altyapısını etkilemez.

Ancak hedef servis de erişilemez olur.

Bu nedenle çoğunlukla son çare olarak düşünülmelidir.

Özellikle tek servisin saldırısı bütün kurum bağlantısını tehdit ediyorsa değerlendirilebilir.

### Geo-Blocking Acil Durumda Kullanılabilir mi?

Evet, bazı durumlarda.

Örneğin şirket yalnızca Türkiye'de hizmet veriyor ve saldırının %95'i kurumun hiçbir kullanıcısının bulunmadığı bölgelerden geliyorsa geçici geo-filtering değerlendirilebilir.

Ancak;

VPN kullanıcıları,

yurt dışındaki çalışanlar,

global müşteriler

etkilenebilir.

Bu nedenle iş birimleriyle koordinasyon gerekir.

### DDoS Sırasında Firewall Kuralı Yazmak Riskli midir?

Evet.

Acil durumda yapılan yanlış firewall değişikliği saldırıdan daha büyük kesinti yaratabilir.

Bu nedenle production değişiklikleri mümkün olduğunca;

onaylı,

kayıtlı,

geri alınabilir

olmalıdır.

Emergency Change Management süreci bulunması faydalıdır.

### Emergency Change Management Nedir?

Kritik olay sırasında standart değişiklik süreci çok yavaş olabilir.

Bu nedenle önceden tanımlı acil değişiklik prosedürü kullanılabilir.

Örneğin;

kim onay verir,

hangi değişiklik yapılabilir,

rollback nasıl yapılır

belirlenir.

DDoS sırasında WAF, firewall veya routing değişiklikleri için önemlidir.

### Rollback Plan Neden Gereklidir?

Acil mitigation kuralı yanlış sonuç verebilir.

Örneğin gerçek kullanıcıların büyük bölümü bloklanabilir.

Bu nedenle her değişiklik için:

#### Nasıl geri alınacak?

sorusu önceden cevaplanmalıdır.

Rollback planı olmayan kriz değişiklikleri yüksek risklidir.

### DDoS Saldırısı Sırasında Service Prioritization

Tüm servisleri aynı anda korumak mümkün olmayabilir.

Bu durumda kritik iş servisleri önceliklendirilmelidir.

Örneğin;

ödeme API'si,

login,

müşteri portalı

yüksek öncelikli olabilir.

Blog veya raporlama gibi düşük öncelikli servisler geçici olarak sınırlandırılabilir.

Bu yaklaşım **Graceful Degradation** ile ilişkilidir.

### Graceful Degradation Nedir?

Sistem tamamen çökmeden bazı ikincil fonksiyonların devre dışı bırakılmasıdır.

Örneğin saldırı sırasında;

öneri sistemi kapatılır,

yüksek maliyetli search azaltılır,

raporlama devre dışı bırakılır,

temel transaction servisleri korunur.

Amaç kritik business function'ları ayakta tutmaktır.

### Load Shedding Nedir?

**Load Shedding**, sistem aşırı yük altındayken düşük öncelikli isteklerin kontrollü biçimde reddedilmesidir.

Bu yöntem backend'in tamamen çökmesini önleyebilir.

Örneğin bazı anonim kullanıcı istekleri reddedilirken authenticated müşteriler hizmet almaya devam edebilir.

### Failover Ne Zaman Kullanılmalıdır?

Kurumun;

secondary data center,

second cloud region,

backup site

altyapısı varsa belirli durumlarda failover düşünülebilir.

Ancak DDoS saldırısı aynı public endpoint'i hedefliyorsa sadece backend değiştirmek problemi çözmeyebilir.

Failover mimarisinin saldırı tipine uygun olması gerekir.

### DNS Failover Saldırı Sırasında İşe Yarar mı?

Evet, bazı mimarilerde.

Ancak DNS TTL süreleri nedeniyle geçiş anlık olmayabilir.

Ayrıca DNS'in kendisi saldırı altındaysa DNS tabanlı failover çalışmayabilir.

Bu nedenle failover önceden test edilmelidir.

### Autoscaling DDoS Olayında Kullanılmalı mı?

Autoscaling kısa süreli yük artışını absorbe etmeye yardımcı olabilir.

Ancak saldırı olduğu doğrulanmışsa sadece kapasite artırmak doğru strateji olmayabilir.

Çünkü saldırgan daha fazla kaynak tüketmeye devam edebilir.

Özellikle cloud ortamlarında maliyet artışı oluşabilir.

Bu nedenle autoscaling ile mitigation birlikte kullanılmalıdır.

### DDoS Sırasında Cloud Cost İzlenmeli mi?

Evet.

Özellikle Layer 7 veya serverless saldırılarda hizmet ayakta kalabilir ancak cloud maliyeti ciddi şekilde artabilir.

Bu nedenle Incident Response dashboard'unda;

instance count,

serverless invocation,

network egress,

cost anomaly

gibi metrikler de bulunabilir.

### DDoS Saldırısında SOC'un Rolü

SOC;

saldırıyı doğrular,

logları korele eder,

incident timeline oluşturur,

severity belirler,

diğer güvenlik olaylarını kontrol eder,

teknik ekiplere escalation yapar.

Ancak network değişikliklerinin tamamını SOC'un kendisinin yapması gerekmez.

Roller net ayrılmalıdır.

### Network Ekibinin Rolü

Network ekibi;

routing,

firewall,

BGP,

ISP,

Anti-DDoS,

load balancer

tarafını yönetebilir.

Volumetric ve L3/L4 saldırılarda özellikle kritik rol oynar.

### Application Ekibinin Rolü

Layer 7 saldırılarda application ekibi;

endpoint performansı,

backend,

database,

cache,

rate limiting

durumunu analiz eder.

Gerekirse düşük öncelikli özellikleri devre dışı bırakabilir.

### Cloud Ekibinin Rolü

Cloud ekibi;

WAF,

load balancer,

autoscaling,

API Gateway,

regional health,

cloud-native DDoS

kontrollerini değerlendirebilir.

Ayrıca maliyet etkisini de izlemelidir.

### Yönetimin Rolü

Yönetimin görevi teknik paketi analiz etmek değildir.

Yönetim;

iş etkisini,

müşteri etkisini,

finansal riski,

iletişim ihtiyacını

değerlendirmelidir.

Teknik ekip yönetimi kısa ve anlaşılır bilgilerle beslemelidir.

### Yönetim DDoS Saldırısında Hangi Bilgiyi İster?

Örneğin şu format yararlı olabilir:

**Saldırı başladı:** 14:02

**Etkilenen servis:** Müşteri Portalı

**Kullanıcı etkisi:** %12 timeout

**Mitigation başladı:** 14:04

**Mevcut durum:** Stabil

**Tahmini iş etkisi:** Düşük/Orta

Bu bilgi:

“18 milyon PPS SYN/ACK anomalisi.”

ifadesinden yönetim açısından çok daha değerlidir.

### Kurumsal İletişim Ne Zaman Devreye Girmeli?

Uzun süreli müşteri etkisi varsa iletişim ekibi devreye girebilir.

Web status page,

müşteri bildirimi,

sosyal medya açıklaması

gibi kanallar kullanılabilir.

Ancak açıklamalar doğrulanmış bilgi içermelidir.

Saldırgan hakkında doğrulanmamış attribution yapılmamalıdır.

### Status Page DDoS Sırasında Neden Önemlidir?

Ana web platformu erişilemezse müşteriler bilgi alamayabilir.

Bağımsız bir status page üzerinden;

servis durumu,

incident update,

recovery

bilgileri paylaşılabilir.

Status page'in aynı altyapıya bağımlı olmaması faydalıdır.

### Hukuk Ekibi DDoS Olayında Gerekli midir?

Saldırının kapsamına göre evet.

Özellikle;

şantaj,

Ransom DDoS,

müşteri etkisi,

sözleşmesel SLA,

regülasyon

konuları varsa hukuk ekibi sürece dahil olabilir.

### Ransom DDoS Nedir?

**Ransom DDoS – RDoS**, saldırganın DDoS tehdidi veya saldırısı üzerinden ödeme talep etmesidir.

Saldırgan bazen kısa süreli saldırı gerçekleştirerek kapasitesini göstermeye çalışabilir.

Ardından daha büyük saldırı tehdidi gönderebilir.

Bu durumda teknik hazırlık, hukuk ve kriz yönetimi birlikte ele alınmalıdır.

### DDoS Fidyesi Ödenmeli mi?

Bu tür kararlar teknik ekip tarafından tek başına verilmemelidir.

Hukuki, finansal, yaptırım ve operasyonel boyutları olabilir.

Kurumsal kriz yönetimi ve ilgili profesyonel danışmanlık süreçleri doğrultusunda değerlendirilmelidir.

Teknik ekip esas olarak sistemin korunması ve saldırının doğrulanmasına odaklanmalıdır.

### DDoS Sırasında Başka Saldırılar Kontrol Edilmeli mi?

Kesinlikle.

DDoS başka aktiviteleri gizlemek için kullanılabilir.

SOC aynı zaman diliminde;

şüpheli login,

malware alert,

privileged activity,

data transfer,

WAF exploit attempt

olup olmadığını kontrol etmelidir.

Bu yaklaşım olayın daha geniş bir saldırının parçası olup olmadığını anlamaya yardımcı olur.

### DDoS Biter Bitmez Incident Kapatılmalı mı?

Hayır.

Trafik normale döndü diye olay tamamlanmış kabul edilmemelidir.

Öncelikle;

service health,

backlog,

database,

cache,

autoscaling,

security events

kontrol edilmelidir.

Bazı sistemler saldırı sonrası birkaç dakika veya saat boyunca dengesiz kalabilir.

### Recovery Phase Nedir?

**Recovery**, mitigation sonrasında sistemin normal çalışma durumuna güvenli şekilde döndürülmesidir.

Bu aşamada;

geçici firewall kuralları,

rate limit,

challenge,

routing değişiklikleri

gözden geçirilir.

Acil kontroller kalıcı hale gelmeden önce değerlendirme yapılmalıdır.

### DDoS Sonrası Cache Problemleri Olabilir mi?

Evet.

Yoğun saldırı cache yapısını değiştirmiş veya cache hit oranını düşürmüş olabilir.

Recovery sırasında;

cache warming,

origin load,

application response

izlenebilir.

Bir anda tüm cache'in temizlenmesi origin üzerinde ikinci yük dalgası oluşturabilir.

### Autoscaling Ne Zaman Geri Düşürülmeli?

Cloud saldırısı sonrasında yüzlerce ek instance açılmış olabilir.

Scale-down çok hızlı yapılırsa gerçek kullanıcı trafiğinde tekrar kapasite problemi yaşanabilir.

Çok geç yapılırsa gereksiz maliyet oluşur.

Bu nedenle recovery kontrollü yapılmalıdır.

### Temporary Mitigation Rule'lar Ne Yapılmalı?

Saldırı sırasında;

geo-block,

rate limit,

WAF rule,

firewall ACL

gibi geçici önlemler alınmış olabilir.

Incident sonrasında bunlar tek tek değerlendirilmelidir.

Gereksiz olanlar kaldırılmalıdır.

Aksi halde aylar sonra kullanıcı erişim sorunları oluşturabilir.

### Post-Incident Review Nedir?

**Post-Incident Review – PIR**, saldırı sona erdikten sonra olayın sistematik şekilde analiz edilmesidir.

Amaç suçlu bulmak değildir.

Amaç şu soruları cevaplamaktır:

#### Ne oldu?

#### Ne zaman fark ettik?

#### Ne işe yaradı?

#### Ne işe yaramadı?

#### Nerede zaman kaybettik?

#### Bir sonraki saldırıda neyi değiştireceğiz?

Bu süreç DDoS dayanıklılığının gelişmesini sağlar.

### Root Cause Analysis DDoS'ta Kullanılır mı?

DDoS saldırısının “root cause”u dış saldırgan olabilir.

Ancak kurum açısından root cause analysis daha farklı sorulara odaklanabilir.

Örneğin:

Neden servis 2 Gbps'te çöktü?

Neden Anti-DDoS geç devreye girdi?

Neden SOC alarmı görmedi?

Neden origin IP açıktı?

Bu sorular asıl iyileştirme alanlarını ortaya çıkarır.

### Lessons Learned Nasıl Oluşturulur?

Örneğin olay sonunda şu sonuçlar çıkabilir:

Anti-DDoS doğru çalıştı.

Ancak SOC bildirimi geç aldı.

ISP iletişim bilgisi güncel değildi.

API rate limit eksikti.

Management communication başarılıydı.

Bu çıktılar aksiyon planına dönüştürülmelidir.

### Action Item Takibi Neden Önemlidir?

Post-Incident toplantısı yapılıp raporun rafa kaldırılması en yaygın hatalardan biridir.

Her bulgu için;

sorumlu,

hedef tarih,

öncelik,

durum

belirlenmelidir.

Örneğin:

#### Origin IP kapatılması – Network – Critical – 7 gün

gibi.

### DDoS Incident Metrics Nelerdir?

Ölçülebilecek önemli metrikler:

#### Time to Detect – TTD

#### Mean Time to Acknowledge – MTTA

#### Time to Mitigate – TTM

#### Recovery Time

#### Attack Peak

#### Legitimate Traffic Success Rate

#### Service Availability

#### Customer Impact Duration

Bu metrikler saldırıdan saldırıya karşılaştırılabilir.

### Customer Impact Duration Neden Önemlidir?

Teknik ekip saldırıyı 2 dakika içerisinde tespit etmiş olabilir.

Ancak müşteriler 40 dakika boyunca hizmete erişememişse Incident Response yine geliştirilmelidir.

Bu nedenle güvenlik metriğinin sonunda iş etkisi mutlaka ölçülmelidir.

### DDoS Incident Report Nasıl Olmalıdır?

Profesyonel olay raporu şu bölümleri içerebilir:

#### Executive Summary

Olayın yönetim özeti.

#### Incident Timeline

Kronolojik akış.

#### Attack Characteristics

Gbps, PPS, CPS, RPS, QPS.

#### Affected Services

Etkilenen sistemler.

#### Mitigation Actions

Uygulanan önlemler.

#### Business Impact

Müşteri ve hizmet etkisi.

#### Detection Analysis

Hangi sistemlerin alarm ürettiği.

#### Communication Timeline

Kimin ne zaman bilgilendirildiği.

#### Lessons Learned

Çıkarılan sonuçlar.

#### Remediation Plan

İyileştirme aksiyonları.

### DDoS Incident Response Test Edilmeli mi?

Evet.

Playbook'un var olması yeterli değildir.

Tatbikat yapılmalıdır.

Örneğin kontrollü DDoS saldırı simülasyonu sırasında;

SOC alarmı görür,

Network ekipleri müdahale eder,

provider bilgilendirilir,

War Room açılır,

management update gönderilir.

Bu sayede hem teknik altyapı hem süreç aynı anda test edilir.

### Tabletop Exercise Nedir?

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

Örneğin moderatör:

**“Saat 10:05'te internet bankacılığına 50 Gbps saldırı başladı.”**

der.

Ekipler;

kimi arayacaklarını,

hangi sistemi kontrol edeceklerini,

hangi kararı vereceklerini

anlatır.

Bu yöntem özellikle yönetim ve kriz iletişim süreçlerini test etmek için faydalıdır.

### Teknik DDoS Testi ile Tabletop Birlikte Yapılabilir mi?

Evet ve oldukça değerlidir.

Teknik ekip gerçek kontrollü trafik simülasyonu yürütür.

Aynı anda Incident Response ekibi olayı gerçek incident gibi yönetir.

Böylece;

**Technology + People + Process**

birlikte doğrulanır.

Bu gerçek siber dayanıklılık yaklaşımına daha yakındır.

### DDoS Incident Response Ne Sıklıkla Test Edilmeli?

Kurumun risk seviyesine göre değişir.

Ancak;

yeni Anti-DDoS hizmeti,

ISP değişikliği,

cloud geçişi,

büyük application değişikliği,

organizasyon değişikliği

sonrasında yeniden test yapılması faydalı olabilir.

Ayrıca kritik kurumlar periyodik DDoS tatbikatları gerçekleştirebilir.

### DDoS Playbook Güncel Tutulmazsa Ne Olur?

Incident Response dokümanları çok hızlı eskir.

Personel ayrılır.

Telefon numaraları değişir.

ISP değişir.

Yeni cloud provider gelir.

Uygulama mimarisi değişir.

Bu nedenle playbook düzenli olarak review edilmelidir.

Özellikle acil iletişim bilgileri sürekli güncel tutulmalıdır.

### DDoS Incident Response'ta En Büyük Hatalar

En sık görülen hatalar arasında;

saldırı tipini anlamadan bloklama yapmak,

ISP iletişimine geç kalmak,

sadece bandwidth'e bakmak,

gerçek kullanıcı etkisini ölçmemek,

çok agresif WAF kuralı uygulamak,

management iletişimini ihmal etmek,

geçici kuralları saldırı sonrası kaldırmamak,

post-incident review yapmamak

bulunabilir.

Bu hataların çoğu teknoloji değil süreç problemidir.

### DDoS Incident Response ve Cyber Resilience

DDoS saldırısını tamamen engellemek her zaman mümkün olmayabilir.

Ancak kurum saldırı altında;

hizmeti sürdürebiliyor,

etkiyi sınırlandırabiliyor,

hızlı müdahale ediyor,

hızlı toparlanabiliyorsa

yüksek siber dayanıklılığa sahiptir.

Bu nedenle DDoS Incident Response, Cyber Resilience'ın en somut uygulamalarından biridir.

### Sonuç: DDoS Saldırısı Sırasında En Değerli Kaynak Zamandır

DDoS saldırısı başladığında kurumun yeni bir süreç tasarlamak için zamanı yoktur.

Kimin aranacağı.

Hangi alarmın doğrulanacağı.

Anti-DDoS'ın ne zaman devreye alınacağı.

ISP'ye nasıl ulaşılacağı.

Hangi WAF politikasının uygulanacağı.

Yönetimin nasıl bilgilendirileceği.

Bunların tamamı önceden düşünülmüş olmalıdır.

Güçlü bir DDoS Incident Response yaklaşımı şu yapıya dayanır:

#### Detect

↓

#### Validate

↓

#### Classify

↓

#### Mitigate

↓

#### Communicate

↓

#### Recover

↓

#### Improve

Teknoloji burada çok önemlidir.

Ancak tek başına yeterli değildir.

DDoS sırasında başarılı olan kurumlar genellikle yalnızca güçlü Anti-DDoS platformuna sahip olanlar değil;

**teknolojiyi, insanı ve süreci birlikte hazırlayan kurumlardır.**

Bu nedenle gerçek dayanıklılık ancak tatbikatla doğrulanabilir.

Ve bu bizi serinin son aşamasına getirir.

Bir kurum DDoS saldırısına karşı sadece ürün satın alıp playbook hazırlamakla yetinmemelidir.

Bütün savunma zincirini kontrollü biçimde test etmeli, sonuçları raporlamalı ve düzenli olarak tekrar doğrulamalıdır.