Detecting security anomalies with the Cisco Deep Time Series Model

Detecting anomalies in a single time series

This example detects anomalies in the overall volume of PDNS blocks across your environment.

index=dns_blocks
| timechart span=1h count
| apply CDTSM count mode=anomaly method=quantile conf_interval=60 multiplier=10 on_span=1 off_span=1 detection_window_latest=-1h

Because this is a single environment-wide series with a consistent daily and weekly pattern, method=quantile is the right choice. The model compares each observed value directly against the forecast band, and the seasonality handling means the band naturally widens during high-activity periods and tightens during quiet ones, reducing noise without any manual configuration.

A few parameter choices worth explaining:

• conf_interval=60 sets the base confidence band using the model's own forecast quantiles (p20–p80). This is the anomaly mode default, and it's already doing seasonality-aware work for you: the band's width shifts as the model's uncertainty changes throughout the day and week. You shouldn't need to change this for most security use cases.
• multiplier=10 is your sensitivity dial. Where conf_interval sets the shape of "normal", multiplier sets how many multiples of that band a point must clear before it's flagged. This is the one parameter to adjust when tuning: lower it to catch more, raise it to reduce noise.
• on_span=1 off_span=1 tells CDTSM to flag on any single anomalous point, rather than waiting for a run of consecutive breaches. For an hourly security search where you want to know about a single unusual hour immediately, this is the right default. The default behavior requires 2 of 3 consecutive points outside the band before starting a segment, which is better suited to smoothing noisy operational metrics than to catching a single spike.
• detection_window_latest=-1h excludes the current, still-filling hourly bucket from evaluation. Without this, a search that runs partway through the hour evaluates a bucket with only partial data, which structurally looks low and can get flagged as a false anomaly.

Running this search gives you a statistics table by default. To see an Anomaly Detection Chart, switch to the Visualization tab and select that chart type. It plots the observed series against the forecast band and shades any anomaly regions, which makes it much faster to judge the effect of a tuning change than reading anomaly_state values in a table.

The screenshots below show the effect of changing multiplier. The search and conf_interval=60 are the same in both; only the multiplier value changes.

With multiplier=20, no anomaly is flagged. The red threshold band is wide enough that even the sharp rise in blocked queries stays within tolerance.

With multiplier=10, an anomaly region appears (shown as a red rectangle). The tighter threshold band means the same rise in blocked queries now crosses it.

This is the core tuning loop for this use case: leave conf_interval alone, and adjust multiplier until the detection rate matches what your environment needs.

Turning the anomaly detection search into a correlation search

After you're happy with the tuning, the anomaly detection search becomes a correlation search like any other. The field that matters is anomaly_state, exposed after renaming CDTSM's count.* output fields:

index=dns_blocks earliest=-90d@d
| timechart span=1h count
| apply CDTSM count mode=anomaly method=quantile conf_interval=60 multiplier=10 on_span=1 off_span=1 detection_window_earliest=-4h detection_window_latest=-1h
| rename count.* AS *
| where anomaly_state="ANOMALOUS"

A few things worth being deliberate about when scheduling this:

• earliest=-90d@d gives the model enough history to forecast from. It isn't the detection window, just backfilling context, and can be set as a detection parameter rather than in the SPL.
• For high-volume data sources, running 90 days of raw search on every scheduled execution might not be practical. Consider pre-summarizing into a daily or hourly summary index or into an accelerated data model, and then pointing CDTSM at that instead of raw events.
• Keep the detection window the same width you tuned with. Per the caution above, a narrowed production window won't behave like the one you tuned at.
• Schedule hourly, offset a few minutes past the hour (for example, X:11), to give indexing lag some room and to avoid evaluating a partially-filled hour.
• Throttle by _time, with a 1-day window. Because the detection window spans several hours, the same anomalous bucket can appear in results across more than one consecutive run before it ages out. Throttling on _time stops a single anomaly from firing repeat alerts as it gets re-evaluated.