Cold Logs, Warm Truth: The Value of Logging That Never Reached the SIEM

There is a moment in many serious incidents where the Security Operations Centre goes quiet. An analyst asks the most important question in the room: what actually happened? The honest answer, from colleagues staring at the SIEM, is often: we don’t know.

That is not because the team is weak, it is not because the tooling was cheap, it is because the data needed to answer the question never made it to the SIEM in the first place.

At that point, the team usually reaches for endpoint telemetry to close the gap. That is understandable, but it introduces another problem. In modern ransomware and destructive attacks, EDR is routinely degraded, evaded or blinded. Which means the team is not just dealing with missing information, but with a harder question: can they trust the information they still have? That is where the investigation starts to slow down. Not because nobody is working hard, but because the organisation has lost confidence in its own evidence.

The Fragility of Primary Telemetry

I’ve been in security operations for a few decades, I worked on helping develop one of the first SIEMs on-the-market and my prior consulting team built over 90 of the largest Security Operations Centres on the globe, and much of what we’ve been doing over this time has been built on a fairly clean assumption:

  • Logs are generated

  • Logs are forwarded or collected

  • Logs are stored centrally (in a log management solution, a SIEM or a data lake)

  • In a SIEM log events are normalised and correlated, or analysed by an AI model

  • Logs are queried when needed

This worked, right up until the moment it didn’t, because in a real attack, even ones executed by smash-and-grab Ransomware-as-a-Service:

  • Agents fail

  • Pipelines break

  • Logs get dropped under load

  • Storage limits kick in

  • Retention policies quietly age things out

And then there’s the more deliberate problem:

  • Logs are deleted

  • Logging is disabled

  • Telemetry is tampered with

  • EDR is blinded

At that point, your “single source of truth” becomes…partial truth at best…a complete fabrication at worst.

What Attackers Understand About Your Logs

Attackers do not just try to evade detection, they actively shape what you are able to see. They know which logs your team depends on, where those logs are stored, how long they are kept, and what tends to break when systems come under pressure. They typically know which logs you rely on, how they are collected, where they are stored, and how long they are retained.

Sometimes that understanding is even sharper than you would like. By the time a destructive attack is underway, the adversary may already have access to incident response documentation, administrative notes, or other internal material that tells them exactly how your teams investigate and which sources of evidence matter most.

That means they often do not need to do anything dramatic. They just need to create enough uncertainty to slow you down. A few missing logs. A little less fidelity. Just enough ambiguity that your team can no longer reconstruct the attack path with confidence. In reality they just need to:

  • Introduce gaps

  • Reduce fidelity

  • Create ambiguity

That is when the real damage starts to compound. Response becomes slower and less decisive. Recovery of important services, products or mission outcomes takes longer. And the gaps in evidence do not just hurt the investigation, they also create risk during eradication. Vulnerabilities can be missed. Persistence mechanisms can survive. Compromised systems can be brought back online carrying the seeds of the next outage.

The Data Your SOC Didn’t Know You Still Had

This is where something interesting happens.Even in environments where SIEM data is incomplete, degraded, or gone entirely, there is often another source of truth, it’s just not treated like one: backup. Not as a recovery tool, not as an insurance policy but as a secondary telemetry source.

Cold Logs: What They Are and Why They Matter

When people think about logs, they think about:

  • Streaming pipelines

  • Real-time ingestion

  • Correlation rules

  • Dashboards

Cold logs are the opposite: they are:

  • Logs captured inside system images and snapshots in the backup solution

  • Application logs sitting on disk

  • OS-level artefacts preserved in time

  • Data that never left the host

In other words they’re the logs that never made it to the SIEM… but still exist. More critically:

  • They haven’t been filtered

  • They haven’t been normalised

  • They haven’t been dropped due to ingestion limits

  • They are not reliant on a compromised end-point solution to access

They are often raw, complete and untouched by the compromises affecting live systems.

Why Backup Changes the Game

A backup platform, especially one with immutable snapshots, gives you something most security tooling cannot: time-separated, adversary-resistant copies of system state. That includes the system’s logs., and not just the logs you chose to collect centrally, but:

  • Logs that were never forwarded

  • Logs that were overwritten in production

  • Logs from systems that are now destroyed

  • Logs from before the attacker started manipulating visibility

This creates a very different investigation model: instead of asking: “What logs do we have?”, you can ask “What did this system look like at each point in time?” That’s a fundamentally more powerful question.

From Detection to Reconstruction

Most security operations is built around detection: find the signal, raise the alert and respond. In a destructive attack, detection is often already behind you. What you really need is reconstruction.

  • How did the attacker get in?

  • Where did they move?

  • What did they change?

  • What regulated data did they access?

  • What still persists?

Cold logs, preserved in backup, allow you to:

  • Rebuild timelines

  • Compare system states across time

  • Identify when artefacts first appeared

  • Validate whether changes were malicious or legitimate

This is not just visibility, it is forensic depth that live telemetry often can’t provide.

When the SIEM Goes Dark

In multiple incidents I’ve dealt with over the years I’ve seen variations of the same failure modes:

  • Logging pipelines overwhelmed

  • SIEM ingestion throttled

  • Critical logs missing at key moments

Or worse:

  • Logging disabled as part of the attack

  • Security tooling degraded or killed

At that point, the investigation team is working with partial timelines, conflicting signals and assumptions instead of evidence, but when backup is integrated into the security operations workflow:

  • Historical snapshots can be mounted

  • Logs can be extracted directly from disk

  • Pre-attack states can be analysed

Suddenly, those gaps close. Not perfectly, not instantly but enough to move from guessing to knowing.

The Advantage Attackers Can’t Easily Remove

Here’s the asymmetry, adversaries can tamper with live telemetry, disable agents and delete logs in production. What they struggle to do, if you’ve designed it right, is: reach into immutable backups, rewrite historical system states and remove artefacts that were captured before they acted.

That makes backup-derived telemetry one of the few sources of evidence that exists outside the attacker’s control plane during an attack., and that’s exactly what empowers a high-confidence investigation.

Why This Isn’t Standard Practice (Yet)

If this capability is so powerful, why is it still so underused? Usually for a handful of very familiar reasons.

First, backup tends to sit with IT Operations, not Security Operations, so it is rarely treated as part of the investigative toolkit, it is seen as infrastructure, not intelligence.

Second, backup does not always have the glamour factor that attracts attention in security teams. It does not arrive wrapped in a new category name or marketed as the latest AI-powered silver bullet. Many analysts would understandably rather spend time on the tools that look more obviously security-centric. The interesting thing is that this usually changes very quickly once they see what a modern backup platform can actually do in an investigation. Once they understand the ability to look backwards in time, examine historical system states, recover logs that never made it to the SIEM and analyse evidence outside the attacker’s reach, it tends to stop looking like backup and start looking like a serious investigative advantage.

Third, many security teams have simply not yet built these use cases into their workflows. That is not unusual. Most incident response processes were designed around SIEM, EDR and forensic tooling, not around using a data management platform as a source of evidence. Bridging that gap is largely an operating model problem.

Then there is the practical side. Security teams are often not trained to investigate using backup-derived evidence. The tooling may not be integrated into standard workflows. The hand-offs between backup administrators, infrastructure teams and security analysts may be clumsy or undefined.

But these are organisational problems, not technical ones.

In many organisations, the capability is already there. The platform is already deployed. The licensing is already in place. The hard part of collecting and protecting the data has already been done by the backup team. In other words, the evidence is often already sitting there, waiting to be used. The challenge is not whether the organisation owns the capability. It is whether the organisation has recognised what it already has.

What Good Looks Like

If you want to use backup as a secondary telemetry source, a few things need to change:

  1. Treat backup as part of the security architecture, not just recovery infrastructure.

  2. Give Security Operations access to backup-derived data. Controlled and auditable, but available.

  3. Build Workflows for Snapshot Analysis: mount, extract, compare, investigate

  4. Integrate with existing Digital Forensics & Incident Response processes. Backup shouldn’t be an escalation path, it should be part of the standard playbook.

  5. Test access, workflows and integrations before you need them. The worst time to figure this out…is when your primary telemetry has already failed.

Final Thought

Most organisations assume that if something wasn’t logged in the SIEM.…it didn’t happen.

It did, you just weren’t looking in the right place, because the truth is still there. Sitting quietly in the background: cold, preserved, and waiting to be investigated.

Next
Next

Ransomware Turns Strategy Decks into Real-World Consequences Overnight