Is your SIEM provider creating risks through mutable logs?

Put yourself in the shoes of a detective.

 

You walk into a crime scene looking for clues about how a crime was committed. You search for footprints, fingerprints, disturbed objects and any signs of forced entry. Every detail matters because it helps establish what happened and who was responsible.

 

But what happens if somebody has already entered the scene before the detective arrives? What happens if evidence has been moved, altered, overwritten or contaminated?

 

Suddenly the investigation becomes far more difficult. Confidence in the evidence disappears.

 

In cyber-security, this crime-scene equivalent exists inside digital logs.

 

Logs constantly record activity across enterprise environments. They track employee actions, system behaviour, authentication attempts, application events and attacker activity. They are among the most important sources of evidence in breach forensics and cyber investigations.

 

Logs are supposed to provide the truth. They show what happened, when it happened, who was involved and how an attacker moved through an environment.

 

Yet one of the biggest, and largely unknown, problems in modern security operations is that many logs are routinely altered after they are collected, and it is the SIEM providers themselves that are responsible for this activity.

 

Tampering with evidence

Many SIEM platforms today use mutable logging architectures, meaning logs can be altered after they are ingested into the platform.

 

This is often done as part of standard platform operations. Vendors enrich logs with metadata, apply scoring, correlate events together, attach user context, and continuously update records as detections evolve.

 

While on one level this sounds beneficial, on another it means that every time a platform rewrites or modifies a log, it also introduces risk.

 

The original evidence is no longer being preserved exactly as it was received; instead, it becomes blended with the platform’s interpretation of events.

 

Instead of separating the evidence layer from the decision layer, many SIEM platforms merge the two together. The raw log becomes intertwined with enrichment data, scoring systems and detection logic.

 

This means trust in logs becomes difficult.

 

Are analysts investigating what actually happened, or are they investigating the platform’s interpretation of what happened?

 

Part of the reason mutable logging has become so widespread is that it simplifies platform architecture.

 

It is easier to continuously update a single record than maintain completely separate evidence and decision layers.

 

Most organisations assume all SIEM platforms handle logs in fundamentally the same way. In reality, the underlying architecture can vary significantly. Some platforms preserve logs immutably while others continuously rewrite them.

 

However, from a customer perspective, these are questions they rarely ask during procurement stages.

 

When selecting a SIEM platform, buyers typically focus on dashboards, integrations, automation features, detection capabilities and cost. Very few ask whether the underlying evidence itself is ever altered.

 

But just as at a physical crime scene, if investigators discover that multiple people have already walked through the room, moved evidence, adjusted markers, or altered the environment, confidence in the evidence declines.  

 

The benefits of immutable logs

Immutable logging works differently.

 

In an immutable architecture, the original log is stored exactly as it was received and cannot be altered. Detection engines, enrichment layers and correlation systems operate separately from the evidence itself.

 

This allows analysts to benefit from advanced detection capabilities without modifying the underlying source of truth.

 

This delivers important benefits to organisations.

 

If an organisation investigates an incident months later, analysts can still return to the original evidence knowing it has not been tampered with, overwritten, corrupted, or unintentionally modified by software updates.

 

This level of integrity is increasingly important as investigations become more complex and regulatory scrutiny increases.

 

It also matters during insider threat investigations, legal disputes and compliance reviews where evidence reliability can be challenged.

 

Questions to ask SIEM providers

So, when it comes to identifying a SIEM partner, what questions should organisations be asking to ensure they can have confidence that their logs remain in their original format and are never tampered with?

 

Here are the top five questions organisations should be asking their SIEM provider:

1. How are logs stored?
2. Can they be altered after ingestion?
3. Is the evidence layer separated from the detection layer?
4. What protections exist against corruption, failed updates, or unauthorised modification?
5. Most importantly, can the organisation confidently prove its logs remain an accurate reflection of what originally happened?

Logs are supposed to provide the truth, yet if the truth itself becomes mutable, investigations become far harder to trust.

 

In cyber-security, this is critical because when no one can trust the evidence, visibility becomes opaque and no one can ever know for sure exactly what is happening within the environment and, most importantly, what can and can’t be trusted.

 

---

 

Simon Phillips is CTO of CybaVerse

 

Main image courtesy of iStockPhoto.com and Inimma-IS