A distributed denial-of-service attack uses traffic or requests from multiple sources to interfere with a service’s availability. Understanding the constrained resource is essential: network capacity, connection handling and application work fail in different ways.
What it is
Denial of service concerns preventing legitimate use of a system. DDoS distributes the activity across multiple sources. Attacks can consume bandwidth, exhaust connection or protocol resources, or force expensive application work. The number of sources is less useful operationally than understanding which resource is becoming unavailable.
Availability incidents can have nonmalicious causes as well. A successful launch, a faulty client retry loop or a dependency outage can overwhelm a service. Response should restore availability while using evidence to determine whether malicious activity is involved.
How it works
A service has finite capacity at several layers. Network links carry traffic; infrastructure tracks connections; application workers process requests; databases and downstream services perform additional work. A bottleneck at any of these layers can prevent legitimate users from completing a transaction.
Volumetric pressure
Large traffic volumes can exceed the capacity of a network path. Controls applied only at the application may be too late if traffic cannot reach that layer reliably. Upstream providers and suitable traffic-handling services become important to the response.
Protocol and connection pressure
A service can run out of connection or protocol-handling resources even without saturating all available bandwidth. Network and infrastructure telemetry help distinguish that condition from an application function that is simply slow.
Application pressure
Requests that cause expensive work can exhaust application or dependency capacity. Total request counts alone may not explain the impact: two endpoints can have very different costs. Review latency, errors, worker utilization and downstream behavior alongside traffic volume.
Technical references: CISA, FBI and MS-ISAC · Understanding and responding to DDoS attacks · NIST SP 800-61 Rev. 3 · Incident Response
How attackers use it
An attacker may seek disruption, extortion pressure or interference with a specific service. They can target a visible frontend or a less obvious dependency such as DNS. A protected homepage does not ensure the availability of every function needed to complete a business transaction.
Response should avoid assuming that all unrelated activity during an outage is part of the same attack. Continue appropriate security monitoring, but connect events through evidence rather than treating disruption as automatic proof of a broader intrusion.
Warning signs
Investigate sharp increases in errors, latency, exhausted resources and traffic patterns inconsistent with expected demand. Compare affected and unaffected services. Determine whether failures occur during resolution, connection establishment, application processing or a downstream dependency.
Measurement needs consistent units
Requests per second, connections, bandwidth and application work describe different quantities. A large number in one metric is not directly comparable with another. Record the baseline, sampling period and measurement point so the response team can identify the actual bottleneck.
Business impact
Availability loss can interrupt revenue, customer access and internal operations. Secondary effects include support demand, delayed transactions and failed integrations. Impact depends on timing and business criticality, not only traffic volume or attack duration.
Mitigation can also affect legitimate users if rules are too broad. The response should monitor both abuse reduction and successful customer activity. A lower request rate is not a complete success measure if real users can no longer complete necessary actions.
Prevention and remediation
Understand critical dependencies and establish provider contacts before an incident. Use capacity and protective services appropriate to the architecture, constrain unnecessary public paths and design application work with suitable limits. Practice identifying which layer is under pressure and who can change it.
Response and verification
- Identify the constrained resource and affected business workflows. - Coordinate with the relevant network, hosting or application provider. - Apply controls appropriate to the observed layer and monitor their side effects. - Check alternate origin paths and supporting services where relevant. - Verify legitimate transactions, latency and error recovery. - Review capacity, configuration and response lessons after the immediate event.
How Ariema detects or handles it
Ariema’s external asset and dependency context can help identify the services, DNS and hosting relationships involved in an availability review. Changes in those observations can support the investigation timeline.
The documented product does not provide live traffic scrubbing, DDoS blocking or network-capacity telemetry. Those functions require the appropriate hosting and network systems. Ariema should not display illustrative traffic figures as measured protection outcomes; its role here is external context and related evidence.
Common questions
Does a traffic spike prove DDoS?
No. Legitimate demand, retry storms and operational faults can produce similar symptoms. Compare traffic behavior with service and infrastructure evidence.
Can an application firewall stop every DDoS attack?
No. A network path may be saturated before application controls can help. Protection needs to match the affected layer and available upstream capacity.
Does using a CDN remove all availability risk?
No. Origin paths, DNS, identity services and third-party dependencies can remain relevant. Review the complete service architecture.
Sources & further reading
Primary technical references for this guide. Scenarios are illustrative; they are not customer observations.
CISA, FBI and MS-ISAC · Understanding and responding to DDoS attacksNIST SP 800-61 Rev. 3 · Incident ResponseOWASP · Attack Surface Analysis