A flood is easy to see once a service is down and hard to see in the minutes before, unless something is counting inbound connections against a known baseline. MITRE D3FEND names this countermeasure Inbound Session Volume Analysis (D3-ISVA) and defines it as "Analyzing inbound network session or connection attempt volume." It sits under the Detect tactic as a child of Network Traffic Analysis (D3-NTA) and analyses Inbound Internet Network Traffic. This card covers how the counting works, which ATT&CK techniques D3FEND relates it to, where it is implemented in hosts, sensors and cloud DDoS services, how to verify the thresholds, and where volume analysis fails. It is for network security engineers and SOC leads; strategy, capacity and provider choice are in the DDoS Protection Guide.
Key takeaways
- Count, window, threshold. D3FEND's description is simple: identify packet types typical of denial of service (it names ICMP and SYN), count them over a sampling period, and alert when the count exceeds a predefined limit.
- Inferred ATT&CK links are mostly floods. D3FEND relates D3-ISVA through the Inbound Internet Network Traffic artefact to Direct Network Flood (T1498.001), Reflection Amplification (T1498.002), Service Exhaustion Flood (T1499.002) and Exploit Public-Facing Application (T1190), plus two phishing sub-techniques through inbound mail traffic.
- Scale is the stated limit. D3FEND's own consideration is that a single server may not have the memory and storage to analyse high-volume attack traffic, which is why large floods are measured upstream at the provider edge.
- Track by the right key. Counting per source finds a single noisy host; counting per destination or per service finds distributed floods. Most deployments need both.
- Baselines beat fixed numbers. A threshold that suits a quiet weekday fails on a sale day. Cloud services increasingly learn per-resource baselines; self-managed rules need seasonal review.
D3-ISVA at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-ISVA (d3f:InboundSessionVolumeAnalysis) |
| Tactic | Detect |
| Parent technique | Network Traffic Analysis (D3-NTA) |
| Digital artefact | Inbound Internet Network Traffic (D3FEND relation: analyzes) |
| D3FEND references | An academic paper on detecting DDoS with Snort, and patents from Cisco, Cloudflare, Juniper Networks and Riorey on flood detection |
| Typical data sources | Firewall and load balancer connection counters, IDS rule counts, NetFlow or IPFIX records, host TCP statistics, cloud DDoS service metrics |
| Typical outputs | Rate alert, attack start and end events, per-protocol counts, mitigation trigger |
| Main limitation | Volume shows that something is happening, not whether it is hostile; low-and-slow attacks stay under thresholds |
How it works
D3FEND's knowledge base article describes network appliances configured to alert on packets typically involved in denial of service, with ICMP packets and SYN requests as its examples. A sampling period defines a time window, the matching packets are counted within it, and an alert is generated when the count exceeds a predefined limit. The references show variations on the same idea.
- Signature plus count: the Snort paper deploys an IDS as a network sensor and counts matching packets, the pattern still used with IDS threshold keywords today.
- Per-target attribution: the Cloudflare patent describes a cloud proxy determining that a DoS attack is directed at one of its IP addresses, then identifying which of the many domains resolving to that address is the target.
- Staged analysis: the Juniper patent describes monitoring connections to a protected device first, then the transactions within sessions, to separate malicious clients from busy legitimate ones.
- Statistical timing: the Riorey patent detects UDP floods from the spectral density of packet timing intervals rather than a raw count.
- Source validation: the Cisco patent assesses whether a source address is authentic using the hop count implied by the packet, which helps separate spoofed flood traffic.
Counting keys and what they find
| Track by | Finds | Misses |
|---|---|---|
| Source address | A single host scanning, brute forcing or flooding | Distributed floods where each source sends little |
| Destination address or service | Distributed floods and reflection aimed at one target | Which sources to block |
| Protocol and flag (SYN, UDP, ICMP) | Protocol floods such as SYN floods and reflection traffic | Application floods made of valid HTTP requests |
| Application key (URI, header, session) | HTTP floods and abuse of a single expensive endpoint | Network-layer floods that never reach the application |
ATT&CK techniques D3FEND relates to D3-ISVA
Relationship type: inferred only. D3FEND lists no hand-made ATT&CK mapping for D3-ISVA. The rows below are relations D3FEND infers because D3-ISVA analyses Inbound Internet Network Traffic and these techniques produce or create that traffic or one of its sub-artefacts. D3FEND labels such relations "inferred and experimental" (D3FEND 1.6.0, checked November 2026). Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | D3FEND relation (inferred via artefact) | What volume analysis can show |
|---|---|---|---|
| T1498.001 | Direct Network Flood | Same artefact: Inbound Internet Network Traffic | Packet or connection rates to a target far above baseline |
| T1498.002 | Reflection Amplification | Same artefact | Large volumes of unsolicited responses (for example UDP from many reflectors) to one target |
| T1499.002 | Service Exhaustion Flood | Same artefact | Request or session counts to one service rising until it saturates |
| T1190 | Exploit Public-Facing Application | Same artefact | Weak signal only: bursts of inbound sessions from scanning that precedes exploitation |
| T1566.001, T1566.002 | Spearphishing Attachment, Spearphishing Link | Sub-artefact: Inbound Internet Mail Traffic | Weak signal only: unusual inbound mail connection volume from one source during a campaign |
The flood rows are where D3-ISVA genuinely detects the technique. The T1190 and phishing rows follow from the shared artefact, but a volume count rarely identifies exploitation or a targeted phish; content analysis and reputation do that work. Deeper treatment of the techniques is in MITRE ATT&CK T1498 Network Denial of Service, MITRE ATT&CK T1499 Endpoint Denial of Service and the T1190 Exploit Public-Facing Application Defensive Guide.
Where it is implemented
Platforms are listed alphabetically; the order is not a ranking. Each row describes the feature from the vendor's or project's own documentation.
| Implementation class | Example feature (documentation) | What is counted |
|---|---|---|
| Cloud DDoS service | AWS Shield: service-level and resource-level detection; events labelled with the attack vector name or Volumetric; attack vector dimensions in the DDoSDetected CloudWatch metric | Layer 3, 4 and (Shield Advanced) layer 7 traffic to protected resources |
| Cloud DDoS service | Google Cloud Armor Adaptive Protection: learns a baseline per backend service (at least one hour before alerting) and alerts on high-frequency layer 7 attacks such as HTTP floods, with a confidence score and, on Enterprise, an attack signature and suggested rule | HTTP requests to backend services behind the load balancer |
| Cloud DDoS service | Microsoft Azure DDoS Protection: per public IP metrics such as Under DDoS attack or not (IfUnderDDoSAttack), Inbound SYN, TCP and UDP packets to trigger DDoS mitigation (DDoSTriggerSYNPackets and similar) and Inbound packets dropped DDoS, sampled each minute; Defender for Cloud alerts "DDoS Attack detected for Public IP" and "DDoS Attack mitigated for Public IP" | Packets and bytes per protocol to public IP addresses |
| Host operating system | Linux tcp_syncookies (default 1: send syncookies when a socket's SYN backlog overflows) and tcp_max_syn_backlog; SYN flood warnings in the kernel log are the host-level volume signal | Half-open TCP connections per listener |
| Network IDS | Suricata threshold (type threshold, limit, both or backoff) and detection_filter, tracked by_src, by_dst, by_rule, by_both or by_flow over a count and seconds window | Rule matches per tracking key |
Availability: AWS documents layer 7 detection under Shield Advanced. Google Cloud documents the full Adaptive Protection alert (signature and suggested rule) under Cloud Armor Enterprise, with a basic alert otherwise. Microsoft documents that the alerts require DDoS Network Protection on a virtual network or DDoS IP Protection on the public IP. Check each vendor's current documentation before planning.
Flow telemetry fills the gap between host counters and provider services: NetFlow or IPFIX records counted per destination give an independent view of inbound volume. See the NetFlow and IPFIX Flow Telemetry Guide and the Suricata IDS Guide.
Implementation steps
- Map the inbound paths. List every internet-facing address and service, where traffic first lands (provider edge, CDN, load balancer, host), and which of those points can count connections. Count as far upstream as possible, in line with D3FEND's scale consideration.
- Collect a baseline. Record at least several weeks of per-service connection, packet and request rates, including peak business events. Keep the hour-of-day and day-of-week shape, not only an average.
- Set two tiers of thresholds. An early warning (for example twice the normal peak, an NHI Mgmt Group example, not a standard) that alerts the SOC, and a mitigation trigger that engages scrubbing or rate limiting. Track by destination for distributed floods and by source for single-host abuse.
- Run in count mode first. Use alert-only thresholds or a Count action in the WAF for two to four weeks and compare alerts against known traffic events.
- Connect to response. Route alerts to the runbook in the DDoS Response Playbook with the provider contact path, the scrubbing switch and the decision owner named.
- Review after every event. Retune thresholds after real attacks, marketing events and capacity changes, and record why.
- Roll back cleanly. Each enforcing rate rule should have a documented switch back to count mode so a false positive during a traffic spike can be removed in minutes.
How to verify it works
- Authorised load test: generate controlled inbound traffic from approved sources against a test endpoint and confirm the early warning and mitigation alerts fire at the expected rates. Cloud providers publish policies for stress and DDoS simulation tests; follow them and notify the provider where required.
- Metric plot check: for provider services, plot the trigger metrics against the attack flag during a test (for Azure, DDoSTrigger metrics against IfUnderDDoSAttack) to learn where mitigation actually engages.
- Host check: confirm SYN flood warnings from the kernel log reach the SIEM; a host that silently falls back to syncookies is under attack without anyone knowing.
- Alert path check: confirm provider alerts (CloudWatch alarms, Security Command Center findings, Defender for Cloud alerts) are routed to the on-call queue and not only to a console.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Internet-facing services with a volume baseline and threshold | 100% | Coverage of the attack surface |
| Time from flood start to SOC alert | Within a few minutes | Early warning before customer impact |
| Volume alerts per month later judged legitimate traffic | Falling after each review | Shows thresholds track real demand |
| Thresholds reviewed after a traffic event or attack | 100% | Keeps baselines current |
| Successful authorised load tests per year | At least one per critical service | Proves detection and mitigation end to end |
Limits, bypasses and failure patterns
- Counting where it is too late: a host or on-premises sensor saturates before it can report, which is the scale limit D3FEND names. Large volumetric attacks must be measured upstream.
- Low-and-slow attacks: slow HTTP or connection-holding attacks keep session counts modest while exhausting resources. Add per-session duration and concurrency signals.
- Distributed sources under per-source limits: a botnet in which each node sends a few requests stays below every per-IP threshold. Per-destination and per-URI counts are needed.
- Static thresholds on seasonal traffic: a fixed number set in a quiet month alerts on every legitimate peak and teaches the SOC to ignore it.
- Shared front ends: behind a proxy or CDN, every request appears to come from a few edge addresses. Count on the trusted client address header, or the source key is meaningless.
- Floods as cover: volume alerts can absorb the SOC while a quieter intrusion happens. Keep normal detection staffed during a DDoS response.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-5 Denial-of-service Protection | Detecting and limiting denial of service events |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring; SI-4(4) Inbound and Outbound Communications Traffic | Monitoring inbound traffic for unusual conditions |
| NIST SP 800-53 Rev 5 | SC-7 Boundary Protection | Edge points where volume is counted and limited |
| NIST CSF 2.0 | DE.CM-01, PR.IR-04 | Networks monitored for adverse events; capacity to maintain availability |
| MITRE D3FEND | D3-NTA, D3-ISVA | Parent and technique |
Related countermeasures
- Session Duration Analysis (D3-SDA): catches connection-holding attacks that stay under volume thresholds. See D3-SDA Session Duration Analysis.
- IP Reputation Analysis (D3-IPRA): adds known-bad context to sources found in a flood. See D3-IPRA IP Reputation Analysis.
- Network Intrusion Prevention (M1031) and Filter Network Traffic (M1037): the ATT&CK mitigations that act on what volume analysis finds. See M1031 Network Intrusion Prevention and M1037 Filter Network Traffic.
- Rate limiting at the application: per-client quotas for APIs and agents. See the Rate Limiting and API Abuse Guide.
Practitioner checklist
- List every internet-facing service and the furthest upstream point that can count its traffic.
- Record baselines that include peak events and day-of-week shape.
- Set an early-warning threshold and a separate mitigation trigger per critical service.
- Count by destination as well as by source.
- Use the trusted client address, not the proxy address, for per-source limits.
- Forward host SYN flood warnings and provider DDoS alerts to the SIEM and on-call queue.
- Run new rate rules in count mode before enforcing.
- Run an authorised load test per critical service at least yearly, within the provider's testing policy.
- Retune thresholds after every attack and major traffic event.
Standards and references
- MITRE D3FEND: Inbound Session Volume Analysis (D3-ISVA)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SC-5)
- Linux kernel documentation: IP sysctl (tcp_syncookies, tcp_max_syn_backlog)
- Suricata: Thresholding keywords
- AWS: Shield event detection
- Google Cloud: Cloud Armor Adaptive Protection overview
- Microsoft Learn: Azure DDoS Protection monitoring data reference
- Microsoft Learn: View Azure DDoS Protection alerts in Defender for Cloud
Related NHI Mgmt Group resources: DDoS Protection Guide · DDoS Response Playbook · NDR Guide · NetFlow and IPFIX Flow Telemetry Guide · MITRE D3FEND Guide