How should denial-of-service impact be reported?¶
The practical answer¶
Denial-of-service impact should be reported by separating attack activity, technical effect, operational consequence and attribution.
The key evidential caution¶
The dangerous assumption is that one broad statement such as “the website was taken down” explains the incident.
It does not.
A defensible report should distinguish:
Key points¶
- traffic or requests observed
- resource exhausted
- service degraded or unavailable
- duration
- users or functions affected
- mitigation applied
- recovery time
- legitimate alternative causes
- source and infrastructure attribution
- remaining uncertainty
Use precise language.
“Traffic volume increased” is different from “network capacity was saturated.”
“Requests were blocked” is different from “the application became unavailable.”
“A botnet was suspected” is different from “the controller was identified.”
Record whether the outage was caused entirely by the attack or partly by containment, failover or dependency failure.
Where exact user impact cannot be counted, report the supported indicators, such as failed transactions, unavailable regions, delayed services or complaint volumes. Avoid converting technical downtime directly into business loss without a separate and evidenced impact assessment.
The report should also distinguish attempted attack from successful denial of service. Significant hostile traffic may be fully mitigated with no user impact, while modest traffic may expose a fragile service and cause serious disruption.
Also distinguish availability from performance. A service may remain technically reachable while becoming too slow or unreliable for its intended function. Record the service standard, failure symptoms and user effect rather than relying only on whether the system responded.
Operational takeaway¶
Report the attack pattern, exhausted resource, service effect, operational impact and attribution as separate conclusions supported by their own evidence.