# How Is a DDoS Attack Detected? SOC, SIEM, NDR and Traffic Analysis

**URL:** https://securesys.com.tr/en/learning/ddos-simulation/how-to-detect-a-ddos-attack-soc-siem-ndr

![How Is a DDoS Attack Detected? SOC, SIEM, NDR and Traffic Analysis](/images/bilgi-merkezi/covers/cover-ddos-10.webp)

The first few minutes of a DDoS attack can be critical.

Because when the attack begins, the organisation faces two fundamental questions:

#### Is this really a DDoS attack?

#### Or is it a sudden rise in normal user traffic?

A campaign, a product launch, a news event or intense customer interest can all raise traffic volume suddenly.

Saying only:

**“Traffic went up.”**

is therefore not enough for DDoS detection.

A correct DDoS detection approach must assess together;

- traffic volume,
- packet rate,
- connection behaviour,
- HTTP requests,
- DNS queries,
- application performance,
- source IP distribution,
- error rates.

None of them in isolation.

At this point it becomes critical that **SOC, SIEM, NDR, WAF, anti-DDoS, CDN and application monitoring** systems work together.

Modern DDoS detection is achieved not through a single alert but by analysing many technical signals in context.

One of the most important concepts is therefore:

#### Traffic Baseline – Normal Traffic Behaviour

and understanding it.

Because if you do not know what normal is, it is hard to identify the abnormal correctly.

#### What Is DDoS Detection?

**DDoS detection** is the process of identifying a distributed denial of service attack against a system or service at the earliest possible stage.

The aim is not merely to notice the attack.

It is also to be able to answer these questions quickly:

#### Which service is the attack targeting?

#### At which layer is it happening?

#### Is it volumetric?

#### Is it layer 3/4?

#### Is it layer 7?

#### Is DNS being targeted?

#### Are genuine users affected?

#### Is mitigation required?

These questions directly affect incident response and DDoS mitigation decisions.

### What Are the First Signs of a DDoS Attack?

The signs of a DDoS attack vary by attack type.

But in general these signals can appear:

#### Bandwidth increase

Network traffic rising above normal levels.

#### Packets Per Second (PPS) increase

An abnormal rise in packets per second.

#### Connections Per Second (CPS) increase

Large numbers of new connections forming.

#### Requests Per Second (RPS) increase

Web or API requests rising rapidly.

#### DNS QPS increase

An abnormal rise in DNS queries.

#### Rising latency

System response times lengthening.

#### Packet loss

Packet loss beginning on the network.

#### HTTP 5xx errors

The backend unable to respond because of the load.

None of these indicators is definitive proof of an attack on its own.

Context is required.

### What Is a Traffic Baseline?

A **traffic baseline** is the statistical and operational definition of an organisation's normal traffic behaviour.

A web application may normally see;

an average of 2,000 RPS,

a peak of 5,000 RPS,

an average of 1 Gbps of traffic,

250,000 PPS.

When these values are known, sudden changes are far easier to notice.

If the system suddenly takes 25,000 RPS at 03:00, that behaviour is abnormal.

But during Black Friday the same traffic can be entirely normal.

A baseline is therefore not simply an average value.

It must also include factors such as:

**time**

**day**

**season**

**campaign**

**user behaviour**

taken together.

### The Difference Between Static Thresholds and Behavioural Detection

DDoS detection can be done through two basic approaches.

#### Static Threshold

Predetermined fixed limits are used.

For example:

bandwidth > 5 Gbps → alert.

#### Behavioural Detection

Deviations from normal traffic behaviour are analysed.

For example:

rising 400% above normal night traffic → alert.

Static thresholds are simple.

But they generate false positives in organisations with variable traffic.

Behavioural detection is more dynamic and context-aware.

### What Is Anomaly Detection?

**Anomaly detection** is the analytical approach aimed at identifying deviations from normal behaviour.

For DDoS, variables such as;

traffic volume,

protocol distribution,

source IP diversity,

request patterns,

session behaviour

can be analysed.

If 85% of HTTP traffic is normally GET and POST requests suddenly climb to 70%, that is an anomaly.

But context must again be checked.

### How Is Gbps Used for DDoS Detection?

**Gbps – gigabits per second** is used to measure total traffic volume.

It matters particularly in volumetric attacks.

If the organisation's normal peak traffic is:

3 Gbps

and suddenly:

35 Gbps

appears, there is a serious anomaly.

But Gbps is not enough on its own.

Because a low-bandwidth, high-PPS attack can also affect the system.

### Why Should PPS Be Monitored?

**Packets per second (PPS)** shows the packet processing load on network devices.

Consider two attacks:

**A:** 8 Gbps / 500,000 PPS

**B:** 3 Gbps / 9 million PPS

The second attack generates lower bandwidth yet is far heavier for a firewall or router.

PPS must therefore always be monitored in SOC and network monitoring systems.

### Why Does CPS Matter in DDoS Detection?

**Connections per second (CPS)** shows the number of new connections opened per second.

In attacks such as SYN floods or TCP connection floods, CPS rises sharply.

If normal is:

10,000 CPS

the attack may bring:

500,000 CPS

instead.

This exhausts connection resources on the firewall or load balancer.

### What Do Concurrent Connections Tell You?

The number of connections open at the same time is also a critical indicator.

If a system normally runs with 100,000 active connections and climbs to millions in a short period, resource consumption follows.

But high concurrent connections are not always an attack.

Long-lived WebSocket or streaming services naturally have high connection counts.

### How Is HTTP RPS Used in DDoS Detection?

In layer 7 attacks, **requests per second (RPS)** is one of the most critical metrics.

If the application normally takes:

2,500 RPS

it may suddenly show:

40,000 RPS

instead.

But here it is not only the total request count that matters, but the endpoint-level distribution.

If all the traffic goes to:

/login

that is far more meaningful.

### Why Is Endpoint-Level Monitoring Necessary?

Application layer DDoS attacks generally target particular high-cost endpoints.

Monitoring can therefore be done separately for critical services such as;

/login

/search

/api/payment

/report

and similar.

The application's total RPS may look normal.

But the login service may be taking 20 times its usual traffic.

The total traffic metric hides that attack.

### Why Does HTTP Method Distribution Matter?

In normal application behaviour, GET, POST, PUT and other HTTP methods have a particular distribution.

During an attack that distribution changes.

For example:

POST is normally 10%.

During the attack POST is 65%.

This behaviour is an important signal on login or transaction endpoints in particular.

### How Are HTTP Status Codes Used in DDoS Detection?

The HTTP status code distribution provides important information about application health.

In particular:

#### 429 Too Many Requests

Rate limiting may have engaged.

#### 500 Internal Server Error

An application error may have occurred.

#### 502 Bad Gateway

There may be a backend access problem.

#### 503 Service Unavailable

There may be resource consumption or a service capacity problem.

#### 504 Gateway Timeout

Backend response time may have risen.

A rapid rise in 5xx rates during a DDoS attack indicates service exhaustion.

### Are 429 Errors an Indicator of Attack?

Not always.

A 429 error code shows the rate limiting mechanism is working.

That can be positive security behaviour.

But if the rate is very high, it can mean genuine users are hitting the limits too.

For that reason:

#### 429 rate + legitimate user success rate

must be assessed together.

### Why Does Latency Matter in DDoS Detection?

A system generally slows down before becoming entirely unreachable.

Normal response time may be:

200 ms

and rise to:

1,500 ms

during the attack.

This can be an early signal in layer 7 attacks in particular.

Uptime monitoring alone is therefore not enough.

Performance telemetry is required too.

### Why Are P95 and P99 Latency More Valuable?

Average latency can hide certain problems.

Most users may receive fast responses while a particular group has a very poor experience.

For that reason:

#### P95

and

#### P99

response time metrics can be monitored.

If the P99 value has risen to 8 seconds, a definite portion of users is having serious performance problems.

### Is Packet Loss a Sign of DDoS?

During a heavy network attack, network devices or links start dropping packets.

Packet loss can indicate;

internet link saturation,

router saturation,

firewall overload.

But network faults also cause packet loss.

It must therefore be analysed alongside attack telemetry.

### What Is Source IP Diversity?

**Source IP diversity** expresses how many different source IPs the traffic comes from.

In distributed botnet attacks, source diversity is very high.

Thousands of different IPs can appear within seconds.

But high IP diversity can also be seen in normal traffic because of CDN, proxy and mobile network use.

Source diversity is therefore not proof of attack on its own.

### What Is Source ASN Analysis?

The **autonomous system number (ASN)** information for IP addresses can be used in attack analysis.

Most of the attack traffic may originate from;

hosting providers,

residential ISPs,

cloud providers.

The ASN distribution gives an idea about the botnet or proxy infrastructure.

### Is Geo-Location Analysis Used in DDoS Detection?

Yes, but it must be used carefully.

An organisation operating only in Türkiye suddenly receiving traffic from 120 countries is an anomaly.

But for a globally serving organisation the same behaviour is normal.

Geography must therefore always be assessed in the organisation's context.

### User-Agent Analysis

In layer 7 attacks the User-Agent headers can be analysed.

If all the traffic uses the same:

User-Agent

that can be bot behaviour.

But modern bots can imitate genuine browser User-Agent values.

User-Agent filtering alone is therefore not enough.

### How Is Browser Fingerprinting Used in DDoS Detection?

Browser fingerprinting can build a client profile from signals such as;

TLS characteristics,

browser behaviour,

JavaScript capabilities,

header combinations.

Even when many IPs differ, the fingerprint of the same automation framework can be similar.

That helps correlate botnet traffic.

### Why Does TLS Fingerprinting Matter?

Because of HTTPS, HTTP content is encrypted at certain network points.

But some metadata signals are visible during the TLS handshake.

These signals help classify particular client behaviours.

They are valuable for bot and automation detection in particular.

### How Is Session Behaviour Analysed?

Genuine users generally follow a particular navigation flow.

For example:

home page

↓

product page

↓

basket

↓

payment

A bot, by contrast, may send requests continuously only to:

/search

as an endpoint.

Session path analysis is therefore extremely valuable in layer 7 DDoS detection.

### How Is Human Behaviour Distinguished from Bot Behaviour?

A genuine user;

waits,

scrolls,

moves between pages,

creates a session.

Bot traffic is usually;

very regular,

very fast,

repetitive,

narrow in endpoint distribution.

But advanced bots try to imitate human behaviour.

Several telemetry sources must therefore be used.

### What Is a Flash Crowd?

A **flash crowd** is a sudden rise in traffic volume caused by genuine user interest.

It can occur during;

Black Friday,

a ticket sale,

a critical news event,

a product launch.

Technically a flash crowd and DDoS look similar at first glance.

Traffic rises in both.

But the traffic behaviour differs.

### How Is a Flash Crowd Distinguished from DDoS?

This is one of the hardest areas of DDoS detection.

These signals help:

#### User Journey

Genuine users move between different pages.

#### Session Duration

Genuine session durations look more natural.

#### Conversion

Genuine users make purchases or complete transactions.

#### Source Reputation

Botnet sources are risky.

#### Request Repetition

An attack behaves more repetitively.

#### Cookie/JavaScript Behavior

Genuine browser characteristics are visible.

No single signal gives a definitive result.

### Can Genuine Campaign Traffic Be Blocked by Mistake?

Yes.

This is one of the serious risks of DDoS defence.

During a product launch the genuine user count can rise tenfold.

A static rate limit can treat it as an attack and block users.

Connecting DDoS protection systems to the business calendar is therefore useful.

### Why Does Business Context Matter for the SOC?

The SOC must see more than packets and logs.

If the marketing team shares the information:

**“The national campaign starts at 20:00.”**

with the SOC, the expected traffic increase can be interpreted correctly.

Business context therefore matters in cyber security operations.

### How Does NDR Detect a DDoS Attack?

**Network detection and response (NDR)** analyses traffic behaviour on the network.

For DDoS it can detect;

bandwidth anomalies,

PPS spikes,

source diversity,

protocol anomalies,

flow patterns.

NDR provides important visibility in network-level attacks in particular.

### How Is NetFlow Used in DDoS Analysis?

**NetFlow** provides a flow-level summary of network traffic.

Information such as;

source,

destination,

port,

protocol,

packet count,

byte count

can be analysed.

It is valuable during a DDoS attack for understanding which target IP, port and protocol the traffic is concentrating on.

**What Is sFlow?**

**sFlow** is one of the technologies that helps monitor network traffic through sampling.

It can be used to analyse high-volume traffic in large networks.

It contributes to detecting sudden traffic changes during a DDoS attack.

### How Does a SIEM Detect a DDoS Attack?

A SIEM centrally collects and correlates events from different security systems.

For example:

firewall → a high SYN rate

WAF → HTTP flood

NDR → a bandwidth anomaly

application → 503 errors

anti-DDoS → an attack alert

The SIEM can relate these under a single incident.

This approach lets the SOC analyst understand the attack faster.

### How Should a SIEM Correlation Rule Be Thought About?

A good correlation should not be merely:

#### Traffic > X

as a condition.

Logically, for example:

a traffic spike

connection failures

application latency

large numbers of source IPs

together form a far stronger signal.

This approach reduces the false positive rate.

### How Does the SOC Classify a DDoS Incident?

At the first stage this distinction can be made:

#### Volumetric

A bandwidth-focused attack.

#### L3/L4

A PPS, TCP, UDP or connection-focused attack.

#### Layer 7

An HTTP/API-focused attack.

#### DNS

An attack targeting the DNS infrastructure.

#### Multi-Vector

More than one attack type.

This classification determines the mitigation decision.

### How Do Anti-DDoS Systems Detect an Attack?

Anti-DDoS platforms can use techniques such as;

traffic baselines,

protocol analysis,

packet rate,

signatures,

behavioural anomalies.

The system learns normal traffic behaviour and detects deviations.

Some attacks are mitigated automatically while others require manual verification.

### How Does a WAF Detect Layer 7 DDoS?

On application traffic, a WAF can analyse information such as;

request rate,

URL,

HTTP method,

client fingerprint,

cookies,

session,

bot score.

A WAF therefore produces critical telemetry for layer 7 attacks invisible at network level.

### Why Does CDN Telemetry Matter?

A CDN can have very wide traffic visibility at the edge.

For example;

requests per second,

cache hits,

edge location,

client distribution,

origin traffic

can be analysed.

During a DDoS attack, the traffic the CDN sees can be compared with the traffic passing to the origin.

That shows how successful the mitigation is.

### Why Should Origin Traffic Be Monitored?

The CDN may be absorbing very high attack traffic.

But if the traffic reaching the origin is still above capacity, the service is affected.

For that reason:

#### Edge Traffic

and

#### Origin Traffic

must be monitored separately.

### How Is Application Performance Monitoring Used in DDoS Detection?

**APM – application performance monitoring** provides data such as;

response time,

transaction latency,

database query time,

backend dependencies.

During a layer 7 DDoS attack the network can look entirely normal.

But APM reveals the application bottleneck.

Integration between the SOC and the application team therefore matters.

### Why Does Database Monitoring Matter for DDoS Detection?

In an HTTP flood attack the real target may be the database.

The search endpoint is called heavily, for instance.

The web server is up.

But database CPU hits 100%.

The values for;

query latency,

connection pool,

CPU,

IO

must therefore be monitored.

### Is Cache Hit Ratio Used in DDoS Detection?

Yes.

If a system with a normally high cache hit ratio sees that ratio fall sharply during an attack, the attacker may be using cache busting behaviour.

The load on the origin then rises.

CDN and application telemetry must be analysed together in particular.

### How Is DNS QPS Used in DDoS Detection?

For DNS;

QPS,

NXDOMAIN rate,

unique subdomain count,

response latency

can be monitored.

If the proportion of unique random subdomains rises alongside a QPS increase, DNS water torture-like behaviour should be investigated.

### Why Is Alert Fatigue a Problem During DDoS?

A DDoS attack can generate thousands of alerts.

The firewall,

the WAF,

NDR,

the SIEM,

application monitoring

can all raise alerts at once.

If analysts treat every alert as a separate incident, understanding the real one becomes difficult.

Alert correlation and incident grouping therefore matter.

### The Difference Between an Event and an Incident

A firewall alert is an **event**.

When thousands of events are understood to relate to the same attack, that becomes an **incident**.

The SOC's aim is not to count events but to understand the attack story.

This distinction matters particularly during DDoS.

### How Is a DDoS Detection Timeline Built?

A timeline can be constructed during professional incident analysis.

For example:

**14:02:00** – traffic rose abnormally.

**14:02:18** – NDR generated an anomaly.

**14:02:25** – anti-DDoS raised an alert.

**14:02:40** – the WAF detected an HTTP flood.

**14:03:10** – the SOC opened an incident.

**14:03:35** – mitigation began.

**14:04:05** – user experience returned to normal.

This timeline is extremely valuable for measuring the effectiveness of the DDoS operation.

### What Is Time to Detect?

**Time to detect (TTD)** is the period between the attack starting and the first correct detection.

The shorter the TTD, the faster the response can begin.

But overly sensitive detection creates false positives.

A balance must therefore be struck between speed and accuracy.

### What Is Mean Time to Detect (MTTD)?

**MTTD** can be used to measure the average detection time across different incidents.

Separate MTTD values can be kept for different attack vectors in DDoS operations.

For example;

volumetric MTTD

layer 7 MTTD

DNS DDoS MTTD

and so on.

This approach helps measure SOC maturity.

### Why Should Time to Mitigate Be Measured Separately?

Seeing an attack and stopping it are not the same thing.

The SOC may notice the attack in 20 seconds.

But mitigation may not begin for 10 minutes.

For that reason:

#### Detection Time

and

#### Mitigation Time

must be separate KPIs.

### Is Machine Learning Used for DDoS Detection?

Machine learning models can be used for anomaly detection.

By learning;

normal traffic patterns,

seasonality,

client behaviour,

deviations can be identified.

But the presence of ML does not automatically mean correct detection.

Model quality depends on;

data quality,

baseline duration,

traffic structure.

### Can AI Be Used in DDoS Detection?

AI-based systems can help in areas such as;

traffic classification,

anomaly detection,

bot behaviour,

event correlation.

But for critical mitigation decisions in particular, human verification or strong security guardrails matter.

A wrong model decision can block genuine customers.

### What Is DDoS Detection Engineering?

**Detection engineering** is the systematic development of the telemetry, thresholds, correlation and alerting logic needed to detect DDoS attacks.

The team can ask, for example:

**“When a SYN flood begins, which signals should we see from which systems?”**

Detection scenarios are then built on;

NetFlow,

the firewall,

NDR,

anti-DDoS.

### What Is a Use Case?

In the SOC world a **use case** is a scenario aimed at detecting particular attack behaviour.

For example:

#### DDoS – High SYN Rate

or

#### Layer 7 – Login Endpoint Flood

can each be a detection use case.

For every use case;

the data source,

the threshold,

the severity,

the response action

must be defined.

### A DDoS Detection Use Case Example

A layer 7 scenario can use this logic:

RPS > 300% of the baseline

concentration on the same endpoint

rising backend latency

a rising bot score

→ high severity DDoS alert

Multi-signal correlation of this kind reduces the false positive rate.

### What Is a SOC Runbook?

A **SOC runbook** explains which checks an analyst should perform when an alert arrives.

For a DDoS alert, for example:

- The traffic increase is verified.
- The affected service is identified.
- The layer is classified.
- Application impact is checked.
- The anti-DDoS status is examined.
- The network team is informed.
- Mitigation escalation is performed if needed.

This structure increases response speed.

### The Difference Between a DDoS Detection Playbook and a Runbook

A runbook contains more specific analyst steps.

A playbook covers the broader incident response flow.

Coordination between;

the SOC,

network,

application,

the ISP,

management

can be defined inside the playbook.

### How Are Other Threats Monitored During a DDoS Attack?

During a DDoS attack, security teams can give all their attention to the availability problem.

But attackers can use that intensity to hide other activity.

The SOC must therefore continue monitoring other events such as;

suspicious logins,

data transfers,

privileged account activity,

malware alerts

at the same time.

### Can DDoS and Data Exfiltration Happen Simultaneously?

Yes.

The DDoS attack itself does not have to steal data.

But data exfiltration can take place at another stage of the same campaign.

In a DDoS incident, therefore, the scope must not be closed early on the assumption:

**“It's just an availability attack.”**

### Can DDoS Attack Attribution Be Done?

Determining definitively which actor carried out an attack can be difficult.

Botnets,

spoofed traffic,

proxies,

compromised devices

can hide the source identity.

Threat intelligence can make an assessment based on;

infrastructure,

campaign,

timing,

threat messages.

But definitive claims must be avoided without a high confidence level on attribution.

### How Does Threat Intelligence Help DDoS Detection?

Threat intelligence can provide information about;

active botnets,

DDoS groups,

RDoS campaigns,

the infrastructure in use.

That information can be added to SOC monitoring.

But in DDoS detection, behavioural analysis is generally more important than IOC-based detection.

Because botnet IPs change constantly.

### How Do DDoS Tests Improve Detection Quality?

Controlled DDoS attack simulations measure whether the existing detections genuinely work.

During the test, for example;

did NDR raise an alert?

did the SIEM correlate?

did the SOC assign the right severity?

was the application team informed?

These results provide input to detection engineering.

### Can a Purple Team Approach Be Used for DDoS?

Yes.

The DDoS test team carries out a controlled attack scenario.

The SOC and network teams try to detect it.

Telemetry is then analysed together.

Missing detections are developed.

The test is repeated.

This is a DDoS-focused **purple team / security validation** approach.

### What Should a DDoS Monitoring Dashboard Look Like?

Having these metrics visible on a single dashboard is useful:

#### Gbps

#### PPS

#### CPS

#### RPS

#### QPS

#### Latency

#### Packet Loss

#### HTTP Error Rate

#### Anti-DDoS Status

#### WAF Block Rate

#### Application Health

This structure gives teams a shared view during an attack.

### Why Does a War Room View Matter?

In large DDoS incidents, different teams work on the same incident.

If the SOC is looking at one dashboard,

the network team at another screen,

and the application team at a different monitoring system,

coordination becomes difficult.

A shared war room dashboard helps show the attack's technical and business impact in one place.

### Can Business Metrics Be Used in DDoS Detection?

Yes.

On an e-commerce platform, values such as;

successful checkouts,

login success,

payment success,

active users

can be monitored.

If the technical systems look healthy while the business transaction rate falls, there is a genuine user problem.

Modern observability is therefore not only an infrastructure metric.

### How Should the DDoS Alert Severity Be Determined?

Severity can be set by these factors:

#### Traffic Volume

#### Service Criticality

#### User Impact

#### Mitigation Status

#### Attack Duration

A low-volume attack that entirely halts the payment API can be critical.

A high-volume attack entirely filtered at the edge has far lower operational impact.

### What Is the Biggest Mistake in DDoS Detection?

One of the biggest mistakes is relying on a bandwidth threshold alone.

An organisation may say:

**“Raise an alert above 5 Gbps.”**

But a 200 Mbps layer 7 attack can halt the login service entirely.

Detection must therefore include the context of:

**network + application + identity + business**

### How Is a DDoS Attack Verified?

When an alert arrives, the SOC can look at these questions:

#### Has the normal traffic baseline been exceeded?

#### Do several telemetry sources show the same anomaly?

#### Is genuine user experience affected?

#### Is the traffic concentrating on a particular endpoint?

#### Is there bot behaviour?

#### Did anti-DDoS classify it as an attack?

This assessment reduces false positives.

### What Should a DDoS Detection Report Contain?

A professional DDoS detection assessment can include these areas:

#### Traffic Baseline

Normal traffic behaviour.

#### Detection Sources

SOC, SIEM, NDR, WAF, CDN and anti-DDoS sources.

#### Attack Timeline

The chronological flow of events.

#### Detection Gaps

Attack behaviour that went unseen.

#### MTTD

Detection time.

#### Mitigation Time

How long the defence took to engage.

#### False Positive Analysis

False alerts.

#### Business Impact

Genuine user impact.

#### Improvement Plan

Detection engineering recommendations.

### What Are the DDoS Detection KPIs?

The main measurable KPIs are:

#### Mean Time to Detect (MTTD)

#### Mean Time to Acknowledge (MTTA)

#### Time to Mitigate (TTM)

#### False Positive Rate

#### Legitimate Traffic Success Rate

#### Detection Coverage

#### Incident Escalation Time

These metrics allow SOC and DDoS operations to be measured over time.

### DDoS Detection and DDoS Prevention Are Not the Same Thing

This distinction is important.

Detection sees the attack.

Prevention or mitigation reduces the attack's impact.

An organisation may detect attacks very well.

But its mitigation capacity may be inadequate.

Another organisation may block attacks automatically while the SOC sees nothing at all.

In the ideal model the two work together:

**Detect → understand → mitigate → monitor → recover**

### Conclusion: You Cannot Manage a DDoS Attack You Cannot See

Being strong against DDoS attacks is not merely a matter of owning a high-capacity anti-DDoS platform.

You have to be able to understand;

when the attack started,

which layer it targets,

which service it affects,

how it differs from genuine user behaviour.

Looking at a single metric is not enough for that.

**Gbps** shows volumetric behaviour.

**PPS** shows packet processing load.

**CPS** shows the level of connection pressure.

**RPS** shows application request intensity.

**QPS** reveals a DNS attack.

**Latency and error rate** show the real service impact.

Modern DDoS detection combines these signals through;

**SOC + SIEM + NDR + WAF + anti-DDoS + CDN + APM**

working together.

But seeing the attack correctly is only the first step.

The real operation begins once the attack is confirmed.

Who is called?

When is anti-DDoS engaged?

When is the ISP informed?

Will WAF rules be changed?

Will rate limiting be applied?

How will it be checked whether genuine user traffic is affected?

Who informs senior management?

Which checks are carried out once the attack ends?

The answers to these questions must not be worked out during the attack.

They must be prepared in advance.

The next critical topic in DDoS security is therefore the **incident response** process.