TIPS #41: The Clock Starts Before You Think It Does

Issue: Attackers are using automation and AI to outpace legacy detection and response.

Attacker tempo is accelerating, driven by automation and adaptive AI that allows attackers to continuously carry out reconnaissance, targeting, social engineering, malware development, credential theft, and escalation. Yet, the default monitoring and response model still depends on the latent, periodic processing of batched logs.

In TIPS #40, we examined critical active defenses that mitigate damage by continuously making systems hostile to agentic AI attackers. The evolution in attacker tempo also demands passive defenses that operate continuously, and closer to the action.

MTTD is the sum of compounding latencies, with downstream impacts on MTTR

To understand why the legacy model of detection and response no longer works, it’s first important to understand how mean time to detect (MTTD) and mean time to respond (MTTR) – core benchmarking metrics measuring how quickly security programs detect and respond to threats- operate in practice.

Most MTTD benchmarking treats detection as a single running clock that starts when an attack begins and stops when the SOC notices it; SOC response times then produce MTTR. In practice, though, MTTD is the sum of several smaller clocks.

Three latency gaps (clocks) impact every log and influence MTTD:

• Log ingestion latency: the gap between an event occurring on the source system and the parsed and normalized log landing in the SIEM or data lake.
• Rule processing latency: the gap between ingestion and a correlation rule or detection model firing.
• Case acknowledgment latency: the gap between an alert firing and a human or system picking it up (the bridge between detection and response).

Each of these clocks adds minutes to hours.

Take Microsoft’s Defender Portal as an example.* In a live cloud environment, Microsoft’s own raw security telemetry often streams near-instantaneously into the Microsoft Defender Portal via direct OS hooks and continuous security graph integration. However, there is usually a heavily delayed identity, compliance, and administrative log plane that follows, creating a significant operational gap:

• Microsoft’s Entra ID log latency documentation shows how a multi-step sign-in log pipeline is required before a record becomes searchable.
• Microsoft’s Purview data governance and security documentation states that audit record availability for core services including Exchange, SharePoint, OneDrive, and Teams occurs 60 to 90 minutes after an event occurs.
• External SIEMs add their own overhead on top of this, since they rely on asynchronous, throttled polling against the Graph or Management Activity APIs rather than receiving data as a push.

Adding to the complexity, each log feed is subject to interrelated latency gaps. Most environments today are federated and collaborative, meaning a single event crosses identity providers, cloud platforms, SaaS applications, and on-premises systems, with each generating its own log in its own format on its own schedule. Correlation across systems and logs creates its own latency on top of ingestion, rule processing, and case acknowledgment.

The cumulative effect is longer dwell times and longer MTTD. MTTR then inherits the lag from MTTD- a SOC can’t investigate, contain, or remediate a threat it hasn’t surfaced yet. An automated threat actor may be able to complete a multi-stage compromise before the primary correlation rules in a SIEM ever receive the data required to trigger an alert.

The tempo has changed, but the log pipeline hasn’t

These latency gaps exist because legacy detection and response pipelines were architected around batch collection, scheduled forwarding, and after-the-fact correlation. That was a reasonable design to address a slower attack tempo in the past, when there was more margin for detection and response. However, it no longer holds up given faster AI-enabled attacks, breaches, and compromises, where adaptive AI lets an attacker re-sequence, re-probe, and re-escalate continuously.

It’s a well-documented issue. Mandiant’s M-Trends 2026 report found that the median time between initial access and follow-on attacker activity has collapsed to 22 seconds. The same report showed that median dwell time, the amount of time attackers remain in systems undetected (functionally MTTD), rose to 14 days. In other words, attackers enter company systems and start follow-on activity before an event log has been ingested into a SIEM or data lake, with detection hours or days behind the curve.

To close detection and response gaps, companies need to shift from periodic and batch processing to continuous, event-driven processing that reduces latency gaps across MTTD and MTTR.

*We chose Microsoft as an example because most organizations depend on Microsoft for identity, productivity, and security telemetry at some scale; similar audit record delays occur in any system of comparable scale and the same dependency structure, including Google Workspace, Okta, AWS, and self-hosted SIEM stacks. This is an architectural problem, not a vendor-specific one.

Impact: Lagging detection causes longer response times and leads to more damage.

The longer detection takes, the more response inherits, and the more damage attackers do.

A comparison of a legacy case study and a modern one illustrates how much can happen in the gaps between an incident occurring, a detection pipeline surfacing it, and investigation and response- and how accelerating attacker tempo amplifies the damage.

Target breach (2013): Successful detection and broken response in the pre-AI era

In 2013, Target experienced a massive data breach that exposed millions of customers’ personal data. Attackers first breached Target’s systems in mid-November and the company’s malware detection tooling, supplied by FireEye, flagged data exfiltration attempts as they began on November 30. However, Target did not act upon the alerts, and attackers had time to move stolen card data out of the network for nearly two weeks. In mid-December, external parties notified Target of the breach, after which Target investigated and removed most of the malware. In the end, more than 40 million customers had their personal and financial information breached.

In this case, there was significant case acknowledgment latency. The attackers moved at human speed over multiple weeks and were detected in time (by pre-cloud era standards) for Target to respond and contain the data theft. The failure was the delayed response, not the detection.

GTG-1002 (2025): AI-enabled attacks outpace detection

In September 2025, Anthropic detected and disrupted a Chinese state-sponsored campaign that used Claude Code to autonomously execute attacks on roughly 30 target organizations, generating thousands of requests per second at peak. Notably, Anthropic’s own model-usage monitoring, not the victim organizations’ detection and response, first surfaced the attacks. Conventional enterprise log pipelines never had the chance to identify the operation given its tempo.

This case shows how AI-enabled attacks undermine a legacy detection model designed to correlate after the fact. An attack operation running at thousands of requests per second doesn’t leave a multiple-week window to act.

Action: Shift to event-based detection, data pipeline intelligence, and SOC hyperautomation.

The detection and response pipeline needs to operate at the tempo that attacker TTPs now demand, across the full MTTD and MTTR chain.

1) Implement real-time detection at the point of generation

The most direct solution to log ingestion latency is to utilize detection logic that runs where the event is generated, streaming results rather than batching raw telemetry back to a central store before anything is evaluated.

Synadia uses NATS to connect event data, services, and AI inference workloads across cloud and edge environments, enabling real-time anomaly detection that runs continuously on live streams instead of on forwarding intervals.

2) Reduce rule processing and correlation latency with pipeline intelligence

The data pipeline itself needs to become more active to limit processing and correlation delays, even if centralized SIEM ingestion remains the destination. Data processing- including interpretation, enrichment, classification, and decisioning- should shift up to the transport layer to enable faster detection.

DataBahn delivers intelligent pipeline tools to help companies gather, manage, and move data more quickly. The DataBahn platform performs intelligence work in transit instead of after delivery, ensuring data arrives normalized, classified, and ready for use. This transforms the telemetry data lifecycle from a source of detection delays to an enabler of real-time insights.

3) Close the case acknowledgment to response gap and lower MTTR with SOC hyperautomation

Faster ingestion and in-stream processing form a strong detection foundation for the SOC to build upon during response. However, SOCs must still pick up, triage, and handle each alert. There’s an inherent tempo mismatch between human SOC analysts working in a fixed queue and AI-enabled attackers- one that needs to be addressed with hyperautomation.

Qevlar AI’s autonomous AI agents investigate and triage every alert in under 3 minutes and suggest remediation steps. Qevlar’s platform helps companies close the gaps between a fired alert, an acknowledgment, and an actioned response.

Featured in this edition: DataBahn, Qevlar AI, and Synadia