Web Security Analytics overview

Web Security Analytics provides a unified and efficient platform to assess security events across products and capabilities, so that you can take informed actions.

You can build your own dashboard and see side-by-side the traffic for individual attack types and their corresponding dimensions over a specific date range of up to 31 days within the last 38 days.

Identify the dimensions that you most frequently work with and add the widgets to the Statistics view. Specify how the data is visualized and adjust the layout.

In addition to viewing dimensions, you can create alerts to monitor specified attack types and notify you when they are triggered. You can also view sampled logs of filtered traffic for further analysis at the request level.

To get acquainted with the user interface, view a recorded tour.

Understand Web Security Analytics data accuracy

Web Security Analytics is an analytics and reporting tool built to reveal attack patterns, traffic trends, and security configuration behavior at a macro level. To deliver fast, stable reporting at a massive global scale, Web Security Analytics displays a representative view of your traffic rather than a request-by-request record. As a result, you may occasionally notice that a specific individual request does not appear in Web Security Analytics, even though it was correctly inspected and acted on at the edge.

What it means for you:

• Your security enforcement is not affected. Web Security Analytics is separate from inline enforcement. If a request matched a policy, it was inspected and acted on at the edge, whether or not its telemetry appears in Web Security Analytics.
• Web Security Analytics is designed for trends. Web Security Analytics samples traffic by design so it can report quickly and stay stable under high volume. It is not a complete log repository.
• Use your SIEM integration or DataStream for per-request forensics. These are the comprehensive sources for request-by-request investigation and reconciliation.

👍

If a denied request you expected is missing

As a rule, Web Security Analytics does not sample out requests that trigger a mitigating action, including deny, tarpit, or challenge, so under normal conditions you can expect to see each one of these requests.

When a denied request (or any mitigated request) you expected is nevertheless absent, the cause is almost always normal telemetry loss in transit to Web Security Analytics, not a gap in protection. The request was still inspected and denied at the edge. Only its analytics telemetry was dropped on the way to the reporting layer. Confirm the enforcement action in your SIEM integration or DataStream.

Why a specific request may not appear in Web Security Analytics

Web Security Analytics is optimized for visibility and speed across your entire traffic landscape, not for storing every event. Three design characteristics mean the data in Web Security Analytics is a high-fidelity representation of your traffic rather than a one-to-one record of it:

• Sampling. Web Security Analytics analyzes a representative sample of ingested traffic. Sampling lets Web Security Analytics return accurate trends and patterns in seconds, even across very large query volumes. Because it is a sample, an individual low-frequency request may not be among the events retained. Note that requests that trigger a mitigating action (such as deny, tarpit, or challenge) are retained in full rather than sampled out.
• Throttling under high volume. During periods of exceptionally high traffic, Web Security Analytics throttles ingestion to protect service stability and preserve fast reporting. This is intentional and ensures that your broader threat picture remains available and responsive.
• Expected telemetry loss. Capturing 100% of telemetry perfectly across a distributed global network is not practically achievable. A minute, expected fraction of telemetry is dropped in transit before it reaches Web Security Analytics. This is normal packet loss, not an enforcement failure, and it is the most common reason that a specific denied request you expected to see is absent from Web Security Analytics.

None of these factors reduces the effectiveness of Web Security Analytics as an analytics tool, and none of them affects security enforcement.

Your security enforcement is unaffected

Web Security Analytics operates independently of inline security enforcement. Enforcement decisions, for example, a request denied by Bot Manager or your Web Application Firewall, are made and applied at the edge, in the request path. Analytics telemetry is generated separately, for reporting.

Because the two are independent, the absence of a request's telemetry in Web Security Analytics does not mean the request was missed. If a request matched an active policy, it was inspected and acted on at the edge, even if its telemetry was sampled out or did not reach Web Security Analytics.

Where to find complete, per-request records

Web Security Analytics and comprehensive logging serve different, complementary goals. Use each for what it does best:

For request-by-request analysis, use a comprehensive logging source such as your SIEM integration or DataStream, which are designed to capture complete event data. Because Web Security Analytics is a sampled analytics layer, it will always hold less data than a comprehensive logging source.

📘

Investigate a specific request

From within Web Security Analytics alone, a request that was sampled out and a request that never occurred cannot be distinguished. To investigate a specific request, start from a comprehensive source (your SIEM integration or DataStream), then use its details to search Web Security Analytics.

When a missing request may indicate a problem

The design characteristics above explain the large majority of cases where an individual request is absent from Web Security Analytics. However, we do not treat data gaps lightly, and we are always ready to investigate a request you believe is missing because of a defect.

A missing request is consistent with normal, expected telemetry loss when it cannot be reproduced and the missing requests do not follow a consistent pattern, that is, they do not consistently occur at the same time, on the same rule, or with the same traffic type.

A gap may indicate a defect worth investigating when the missing requests follow a clear, repeatable pattern (for example, they do not consistently occur at the same time, on the same rule, or with the same traffic type). If you observe such a pattern, contact your Akamai representative or support with specific examples (including the corresponding records from your SIEM integration or DataStream) so our team can investigate.