Behavioral DDoS Engine (BDE)

TL;DR

What is it?

BDE learns normal traffic patterns for each hostname and uses those baselines to detect anomalies. It additionally uses both malicious signals (e.g. Platform DDoS Intelligence) and benign signals (e.g. the DAN table) to enhance precision.

How does it work?

BDE profiles provide a shared administrative framework where sensitivity, exceptions and mitigation actions are defined, but each hostname always builds and enforces its own independent baseline and thresholds daily. This dual structure delivers efficiency at the profile level while preserving precision at the protection level.

Sensitivity can be adjusted to traffic behaviour: conservative for bursty endpoints, moderate for most production services, and strict for stable or low-volume hostnames/endpoints such as login or payment portals.

Instead of static thresholds it adapts dynamically and detects anomalies across multiple dimensions: HTTP method, hostname, path, country source, TLS patterns (a subset of TLS information), connecting IP and TLS fingerprint. When the solution flags a suspicious actor it does so within a defined scope (HTTP method + hostname + path). This increases effectiveness and sensitivity while keeping false positives very low in case of misclassification.

BDE versus Rate Controls

BDE is not directly comparable with DoS Rate Control, but for reference:

*HTTP method buckets: GET, POST, Others (PUT, DELETE, etc.)

Why does it matter?

Unlike traditional rate controls that apply static, shared thresholds, BDE reduces false positives and provides accurate protection by understanding what “normal” looks like for each hostname. It enables proactive defence that adapts in real time, preserving availability and customer trust even during unpredictable traffic events. When a potential attack occurs, only the targeted endpoint is affected by the mitigation — which reduces the blast radius of false positives and gives you far more confidence when switching to blocking mode.

Not suitable candidates for BDE protection

BDE depends heavily on data collection to learn expected behaviour from legitimate user traffic. Attempting to protect sites with little or no traffic results in inefficient or no protection.

• Static sites — a few static HTML pages plus static resources are unlikely to generate enough traffic. BDE ignores most static requests such as images, JavaScript and stylesheet files.
• Redirect hostnames — redirects handled at the CDN level mean no real traffic is forwarded to origin.
• Non-production hostnames, or production hostnames with little-to-no traffic — by nature these will not see enough traffic over several days, preventing baseline generation.
• Temporary hostnames / failover — no steady multi-day traffic with a good representation of legitimate users, so no baseline can be built.

Deployment best practices

• Begin in alert mode with moderate sensitivity to allow learning.
• Let BDE observe clean traffic for 7–14 days before enabling mitigation.
• Review the BDE and WSA reports to validate stability, identify anomalies (e.g. outlier paths) and fine-tune exceptions.
• If there are legitimate outlier paths, override them with a lower sensitivity level to reduce false positives.
• If there are irrelevant endpoints to protect (e.g. logging, analytics), make an exception.
• For endpoints that are not good BDE candidates (e.g. highly variable or high-volume traffic), rely on rate controls instead.
• Reuse your Rate Control bypass Client List/Network to exclude trusted populations.
• Gradually enforce mitigation, starting with critical hostnames in strict mode.

Key takeaways

BDE profile scope drives administrative efficiency, while hostname baselines preserve fidelity. Group hostnames within a profile according to their traffic type or nature, since each group shares the same sensitivity level; within that profile every hostname still builds and enforces its own independent baseline. Continuous monitoring and tuning remain essential for long-term value. BDE is not a reactive firefighting tool but a proactive, adaptive system that outperforms traditional rate-based controls through data collection, precision and intelligence.

1. Key concepts

Hostname-centric profiling

BDE creates individual traffic baselines per hostname, so protection thresholds are tailored to the specific traffic patterns of each hostname. Even if multiple hostnames are included in a single BDE profile, the actual baselining and anomaly detection are defined per hostname.

Example
  host1.com and host2.com are both in BDE Profile A with Strict sensitivity.
  Each is protected based on its OWN historical traffic, despite sharing a profile.

Profile scope vs protection scope

It is important to distinguish the Profile Scope, which governs shared configuration settings, from the Protection Scope, which reflects how each hostname is individually protected.

Profile scope — centralised configuration

The BDE profile is the administrative layer defining shared operational parameters for one or more hostnames:

• Sensitivity level (Strict, Moderate, Conservative)
• Exception lists (path + hostname pairs excluded from mitigation only)
• Mitigation options (Not Used, Alert, Deny, Custom Deny)
• False positive customisation:
  • path + hostname level sensitivity overrides
  • suspend mitigation for a set time period
  • selective sensitivity override

Protection scope — hostname-centric defence

Each hostname builds its own adaptive baseline using up to 14 days of production traffic. This means:

• Protection is independent, even if multiple hostnames share the same BDE profile.
• Thresholds are not shared across hostnames, unlike traditional rate-based controls.
• ML builds a fingerprint of what “normal” traffic behaviour looks like per hostname, reducing false positives and enabling precise mitigation.

The result: a shared profile enables administrative efficiency, while individual baselines preserve protection fidelity.

Traffic profiling & detection framework

BDE profiles traffic using multi-dimensional criteria that go far beyond IP and volume metrics.

Profiling scope dimensions

Each profile is uniquely scoped per Akamai region, and only the maximum value is retained, using:

• HTTP method (GET, POST, Others: PUT, DELETE, etc.)
• Hostname
• Path

Ultimately, the average of the maximum rates per scope + dimension is calculated and propagated to the Edge daily. Dimension here means: TLS pattern, country source, TLS fingerprint, and IP.

This results in 12 profiles per hostname (4 primary behavioural profiles × 3 HTTP method buckets):

*HTTP method buckets: GET, POST, Others (PUT, DELETE, etc.)

Sensitivity levels

• Strict — for hostnames with stable traffic and low variability (e.g. login pages, low-traffic sites).
• Moderate (default) — balanced sensitivity for most production hostnames.
• Conservative — for high-volume, bursty APIs or unknown traffic patterns (less aggressive).

The sensitivity level can be overridden or tuned based on the hostname–path pair.

Fine-tuning for false positives

• Exceptions: add specific hostname–path pairs as exceptions from mitigation actions (e.g. health checks, logging/analytics endpoints, known bot paths). Adding a hostname–path pair to Exceptions does not impact its contribution to the baseline — the baseline calculation only adjusts when the system detects an outlier path. Only mitigation is exempted.
• Sensitivity override: override sensitivity per hostname–path pair. If a section of the application is more bursty, or the BDE report flags certain paths as outliers, first try applying a sensitivity override at a lower sensitivity level before taking more drastic actions such as creating an exception or changing the hostname's default sensitivity.
• Suspend mitigation temporarily for specific events (e.g. flash sales, product launches).
• Review reports regularly to identify outlier paths with traffic rates significantly higher than others. Exclude these paths from BDE protection only after confirming they are not true positives by correlating findings with WSA. This maintains baseline accuracy and reduces excessive false positives.
• Be aware that legitimate traffic spikes (e.g. after a code release) may temporarily exceed baselines; adjust sensitivity or exclusions proactively. Prepare guidance for handling traffic-pattern changes such as releases or new endpoints to minimise operational disruption.

BDE baseline generation process

Once BDE is enabled on any scope, the baseline profile continues to collect and consider all paths for that hostname. It is independent of the match target, which only defines the scope of counting and mitigation actions at the Edge — not the scope of baseline computation.

Baseline computation is performed asynchronously and entirely in the backend, using the previous day's traffic data in addition to the baselines generated over the last 14 days. It is generated offline, without any interaction with the Edge processing workflow. Once computed, the baseline is pushed to the Edge once every 24 hours for live enforcement.

Multiple traffic types are excluded to sanitise the data prior to baseline generation. This list is not exhaustive:

• Outlier paths automatically detected by the system
• Error status codes (e.g. 400, 404, 500)
• Redirect status codes (e.g. 301, 302, 307)
• Actions applied with Deny, Custom Deny, Tarpit or Allow
• Static resource extensions (e.g. jpg, png, js, css)
• Internal requests (e.g. Prefetch, BMP requests, SCF requests)

Key takeaways for professional services teams

2. Initial configuration

Step-by-step setup

1. Create a BDE profile
   • Group together hostnames with similar sensitivity and exception requirements.
   • Keep the number of hostnames manageable (the limited-availability limit is 10 hostnames per contract).
2. Set initial parameters
   • Sensitivity level: Moderate
   • Action: Alert
   This lets the engine observe real-world traffic without enforcement. There is no BDE trigger in WSA until the baseline reaches a ready state (~5 days).
3. Include hostnames
   • Wildcards are not allowed; hostnames must be specified explicitly.
   • All hostnames share profile settings but build independent behavioural baselines.
4. Let BDE learn
   • Allow 7–10 days for the baseline to stabilise.
   • During this phase no mitigation is performed — only observation and tuning.

Strategic implementation advice

The BDE system cannot determine whether constant noise, tolerated (non-blocking action) by customers for several days, is good or bad bot traffic. Ensuring long-lived noise is not included in the BDE system is pre-work that must be done if you want to increase the likelihood of proper detection by BDE.

Implementation decisions should align with the customer's risk tolerance, traffic stability and the business criticality of each hostname. If you are not familiar with the customer context, start with a moderate level.

For non-critical hostnames or services with variable traffic patterns (e.g. marketing pages, bursty APIs):

• Sensitivity: Moderate
• Action: Alert (initially)

This gives visibility into behavioural anomalies without prematurely triggering mitigation, helping teams understand baseline stability before applying relaxed controls.

For critical or sensitive hostnames (e.g. authentication portals, payment systems, admin interfaces) where availability and integrity are paramount:

• Sensitivity: Strict
• Action: Alert (initially)

This applies tighter thresholds to high-value assets while still giving operators time to evaluate behavioural data before enforcing mitigation.

Regardless of sensitivity level, always allow at least 7–14 days of clean traffic learning before enabling mitigation. Use BDE reports to assess stability, identify legitimate traffic bursts and fine-tune exceptions. Compare BDE triggers with rate control triggers to understand which attacks each system is catching.

After confidence is built in baseline accuracy and tuning is complete:

• Transition select hostnames to Mitigation mode.
• Continue monitoring through reports and alert logs.
• Adjust profiles based on production events or evolving traffic trends.