Why Log-Centric Thinking Fails in OT
The Visibility Illusion in Critical Infrastructure Cybersecurity
By Muhammad Ali Khan ICS/ OT Cybersecurity Specialist — AAISM | CISSP | CISA | CISM | CEH | ISO27001 LI | CHFI | CGEIT | CDCP
The Assumption That Logs Equal Truth
Modern cybersecurity is built on a powerful assumption:
If it’s important, it will be logged.
If it’s logged, it can be investigated.
If it can be investigated, it can be controlled.
In IT environments, this assumption largely holds. Systems are transactional, deterministic, and designed to narrate their own behavior.
In OT environments, especially in critical infrastructure, this assumption quietly collapses.
Logs do not represent reality.
They represent what the system managed to record after physics already acted.
Relying on log-centric visibility in OT does not just leave gaps; it creates a false sense of control.
Why Logs Work in IT — and Why That Logic Breaks in OT
IT systems are designed to:
- Record events before state changes complete
- Preserve logs for long periods
- Maintain accurate time synchronization
- Operate independently of physical consequences
OT systems are designed to:
- Maintain process stability
- Execute control actions immediately
- Suppress noise and transient data
- Prioritize uptime over observability
In OT, control comes first, explanation comes later, if at all.
This fundamental design difference makes log-centric thinking not just incomplete, but misleading.
The Inherent Limits of OT Logging
Even in well-instrumented environments, OT logs suffer from structural constraints:
- Many controllers log minimally or not at all
- Log buffers overwrite quickly
- Time synchronization is inconsistent across layers
- Events are logged after actions occur
- Safety systems often bypass logging paths entirely
A valve closes. A breaker opens. A trip occurs. The physical state changes instantly. The log, if generated, arrives late, fragmented, and stripped of context. In critical infrastructure, the most important events often leave the weakest digital traces.
Control Reality vs Log Reality
OT environments operate across multiple realities:
- Process reality (what physics is doing)
- Control reality (what the controller believes)
- Supervisory reality (what SCADA shows)
- Log reality (what gets recorded)
These realities are not always aligned. Historians smooth data. Controllers suppress noise. SCADA abstracts detail. Logs capture only what software chooses to narrate.
What gets logged is not what happened; it is what the system noticed after the fact.
How Log-Centric SOC Thinking Misdiagnoses OT Incidents
When incidents occur, investigations often begin in the SOC:
- Review logs
- Correlate alerts
- Reconstruct timelines
In OT incidents, this approach frequently diagnoses events backwards.
Common outcomes:
- Operators blamed for “procedural error.”
- Equipment faults assumed
- Cyber causes were dismissed due to “lack of evidence.”
- Root causes misattributed
Not because cyber activity wasn’t present, but because the evidence never existed in log form. Logs describe the software state. Incidents unfold in physical systems.
Why Attackers Prefer Log-Centric Defenders
Sophisticated attackers understand this gap.
They do not need to:
- Delete logs
- Tamper with audit trails
- Trigger alerts
They operate where logs never existed:
- Within control tolerances
- Inside sensor trust assumptions
- Across timing gaps
- During transient states
The attack succeeds not because defenders missed the logs, but because they trusted logs too much.
The Visibility Illusion in Critical Infrastructure
Critical infrastructure environments often believe they have visibility because:
- Logs are collected centrally
- Dashboards are populated
- Alerts are firing
But visibility that arrives after irreversible physical change is not controllable. It is documentation. This illusion becomes dangerous when organizations believe log completeness equals situational awareness.
What OT-Centric Visibility Actually Requires
Moving beyond log-centric thinking does not mean abandoning logs. It means re-scoping their role.
OT-centric visibility is built on principles:
- Process-state awareness, not event narration
- Physics-based validation, not log correlation
- Temporal coherence, not timestamp assumptions
- Drift as signal, not noise
The question shifts from:
“What do the logs say?”
To:
“What does the process prove?”
Industry 5.0 Perspective: Human-Centric Visibility Beyond Logs
Industry 5.0 emphasizes trust, resilience, and human-centric systems. That vision cannot be achieved solely through log-centric visibility.
Humans cannot meaningfully supervise autonomous systems if:
- The truth arrives late
- Context is missing
- Physical causality is abstracted away
Human-centric oversight requires visibility that reflects process reality, not just digital artifacts. Logs support understanding. They do not define it.
Closing Thought
Logs are not lies, but they are not the truth either.
In OT, especially in critical infrastructure, logs tell a story after the plot has already moved on. Organizations that continue to treat logs as the primary source of truth will keep explaining incidents they were never able to see forming. The future of OT cybersecurity does not belong to better logging. It belongs to a better understanding of physical reality.
Board-Friendly Thought Leadership Version
Why Log-Centric Security Fails in Critical Infrastructure
Key Insight:
OT incidents unfold in physical systems. Logs describe events after a physical change has already occurred.
Why It Matters to the Board:
Decisions based solely on logs create blind spots that lead to misdiagnosed incidents, regulatory exposure, and false confidence in cyber readiness.
Core Risk:
Log-centric visibility assumes reversibility and completeness — neither exists in physical systems.
Executive Question to Ask:
If the most dangerous action happened between log entries, would we know?
Bottom Line:
Logs support investigation.
They do not guarantee control.
.png)
Comments
Post a Comment