Reading DDoS Reports: The Evidence That Matters After an Attack

After a DDoS attack, a chart often draws attention to its highest peak. Operations teams and management need more answers: which services were affected, could customers use them, which action helped and what must change before another incident? A useful report connects these perspectives.

Start with the effect on the service

The first page should explain the affected service, the observation period and the impact in a few sentences. Separate a confirmed interruption from individual customer reports or an unresolved anomaly. A statement that no outages were observed needs to explain which checks were used and from which networks.

Consider an illustrative example: a customer portal is reachable from two monitoring locations, but the login workflow is not tested. This supports a statement about those reachability checks. It does not establish that users could sign in throughout the event. That precision also helps answer customer questions.

Every traffic chart needs a readable definition

• Measurement point: where was traffic observed, and does the display cover an IP address, a prefix or several services?
• Unit and direction: does the chart show bits, packets or requests per second, and incoming or outgoing traffic?
• Time basis: which time zone and aggregation interval apply?
• Traffic category: does the series show observed, discarded or forwarded traffic?
• Data quality: are there samples, missing observations or changes in collection?

Discarded and forwarded initially describe decisions made by a system. Forwarded traffic has not thereby been proven entirely legitimate. A decline at the measurement point alone also does not establish its cause. Keep interpretation separate from the measured value.

Read network observations alongside application checks

Passive measurements observe existing traffic. Active measurements use purpose-generated test connections or packets. RFC 7799 distinguishes these approaches. In an operational report, they answer complementary questions: traffic observations show load and treatment; a suitable application check shows whether a defined workflow succeeds from the test location.

RFC 7799: active and passive measurement methods

Document uncertainty explicitly. Five-minute averages can hide brief peaks, while a failed collector creates a data gap. RFC 2330 calls for measurement errors and their causes to be understood and documented. Missing values should therefore appear as missing, rather than as zero traffic.

RFC 2330, Section 6.3: measurement uncertainty and errors

Use one timeline to avoid premature conclusions

Record the first observed event, first user impact, detection, actions and confirmed recovery separately. Use a common time zone and flag imprecise timestamps. Activating a mitigation measure and restoring an application may happen at different times.

Keep the supporting logs and extracts with a clear record of their origin. Who created each export, and when? Which systems are absent? NIST SP 800-92 addresses log management planning and operation. A short reference to internally retained evidence is often sufficient for the report.

NIST SP 800-92: Guide to Computer Security Log Management

Turn the report into specific work

NIST SP 800-61 Revision 3 places lessons from incidents within continuous improvement of security practices. Apply that idea to a small number of actions with owners and deadlines. An unresolved reachability question might become an additional application check with a defined result.

NIST SP 800-61 Revision 3: incident response and continuous improvement

When selecting a protection service, discuss which data should be available during an incident and who will assemble it. This is a requirement for the working relationship. It does not by itself imply that a particular portal or automatically generated report is included.