Skip to content
Cloud Security DeskSearch
Menu

Visual briefDetection & response

Cloud logs that never reach the SIEM

A dashboard can be healthy while the evidence behind it is incomplete. Coverage needs to be tested from event creation to searchable record.

Demonstration publication. The scenario and all numerical data are illustrative, not observed research findings.

By
Umair Akbar and Ahmed Elshekh
Published
Reading time
8 minutes
Coverage
AWS · Azure · Google Cloud

A visual brief using illustrative data to show where cloud telemetry can disappear between a provider service and an analyst query.

At a glance

Key findings

  • Configuration presence does not prove searchable delivery.
  • Collection gaps compound across routing, transformation, and indexing.
  • A small set of canary events can test the entire evidence path.

Test the evidence path

A logging control is not complete when a service checkbox is enabled. It is complete when a known event can be generated, routed, retained, transformed, indexed, and found with the query an analyst will actually use.

The demonstration data below intentionally uses fictional values. Its purpose is to show how a delivery test makes silent loss visible.

Figure 01 · Illustrative dataset

Illustrative event delivery by stage

The synthetic dataset loses 18 percentage points between event creation and searchable evidence.

Bars decline from 100 percent generated to 97 percent routed, 91 percent transformed, and 82 percent searchable.

Interactive chart loads as it approaches the viewport.

View accessible data table
Illustrative event delivery by stage
CategoryEvents retained
Generated100%
Routed97%
Transformed91%
Searchable82%

Source Cloud Security Desk demonstration dataset

Method Fictional rates for 1,000 generated canary events. The figures illustrate an assurance method and are not provider benchmarks.

Download source data (CSV) ↓

Latency is part of coverage

Evidence that arrives after an investigation window is operationally absent. Teams should define a time-to-search objective for high-value sources and test both typical and tail latency.

Figure 02 · Illustrative dataset

Illustrative time to searchable evidence

The example’s slowest pipeline is four times slower than its intended objective.

Grouped values show median and 95th-percentile search latency: pipeline A 3 and 8 minutes, B 5 and 19 minutes, C 7 and 32 minutes.

Interactive chart loads as it approaches the viewport.

View accessible data table
Illustrative time to searchable evidence
CategoryMedian95th percentile
Pipeline A3 min8 min
Pipeline B5 min19 min
Pipeline C7 min32 min

Source Cloud Security Desk demonstration dataset

Method Synthetic median and 95th-percentile latencies for three unnamed collection pipelines. Values are illustrative only.

Download source data (CSV) ↓

The minimum proof set

Keep the original event identifier, timestamps at each pipeline stage, the final query, the returned record, and any transformation rule that touched it. Repeat after routing or schema changes.

References

  1. AWS CloudTrail integrity validation
  2. Microsoft Sentinel data connectors
  3. Google Cloud log routing

From the desk

About the authors

This demonstration publication is attributed to Umair Akbar and Ahmed Elshekh, the publication’s owners and chief editors.

Owner & Chief Editor

Umair Akbar

Owner & Chief Editor

Ahmed Elshekh

Questions answered

  1. What does “Cloud logs that never reach the SIEM” investigate?

    A dashboard can be healthy while the evidence behind it is incomplete. Coverage needs to be tested from event creation to searchable record.

    Supporting context

    A visual brief using illustrative data to show where cloud telemetry can disappear between a provider service and an analyst query.

  2. What is the publication’s central conclusion?

    Configuration presence does not prove searchable delivery.

    Supporting context

    Collection gaps compound across routing, transformation, and indexing. A small set of canary events can test the entire evidence path.

  3. Who should use this analysis, and for what decision?

    The visual brief is most useful to practitioners evaluating Detection & response across AWS, Azure, and Google Cloud. It is designed to support a concrete review or operational decision, not to replace environment-specific testing.

  4. What mechanism or pattern does the analysis explain?

    Evidence that arrives after an investigation window is operationally absent. Teams should define a time-to-search objective for high-value sources and test both typical and tail latency.

    Supporting context
  5. What evidence supports the analysis?

    The publication explains its evidence or method in “Test the evidence path” and cites 3 numbered references that readers can inspect.

    Supporting context

    A logging control is not complete when a service checkbox is enabled. It is complete when a known event can be generated, routed, retained, transformed, indexed, and found with the query an analyst will actually use.

  6. What are the scope boundaries or limitations?

    The scenario and numerical values are illustrative, not observed provider benchmarks or measured customer findings. The publication demonstrates a review method and must not be treated as a prevalence estimate.

  7. Which cloud systems and security topics are in scope?

    The publication covers Detection & response with explicit scope across AWS, Azure, and Google Cloud.

  8. Does the publication include interactive charts or downloadable evidence?

    Yes. It includes 2 interactive charts with accessible descriptions and source or method notes; 1 supporting download is available on the page.

  9. Who wrote the publication, and when was it updated?

    Umair Akbar and Ahmed Elshekh wrote the visual brief, published on August 7, 2026. The estimated reading time is 8 minutes.