The Thesis
Security Information and Event Management systems are the backbone of enterprise security operations. They collect logs from hundreds of sources, normalize formats, correlate events, generate alerts, and power dashboards. They are indispensable for operational security. And they are architecturally incapable of proving governance integrity.
This is not a failure of any specific SIEM product. It is a category limitation. SIEMs are observability tools. They observe what systems report. They correlate those observations. They alert on patterns. But they do not and cannot verify that the observations are accurate, complete, or untampered.
Observability Is Not Proof
The distinction between observability and proof is precise:
- Observability tells you what a system reports about its behavior. It depends on the system reporting accurately and completely. If the system omits an event, the omission is invisible to the observer.
- Proof provides independently verifiable evidence that a specific state or transition occurred. It does not depend on the system's self-report. It is verifiable by any party using mathematical operations.
A SIEM that shows "all access reviews completed" means "all systems reported access review completion events." It does not mean all access reviews actually occurred. It does not mean the review events were not fabricated. It does not mean access reviews that failed were reported as failures rather than successes.
The Ingest Problem
SIEMs are downstream consumers. They receive log data after it has been generated, filtered, transformed, and transmitted by the source system. At each stage, information can be lost, modified, or fabricated:
- Generation — The source system decides what to log. Events that are not logged do not reach the SIEM.
- Filtering — Log pipelines often filter events before forwarding to reduce volume and cost. Filtered events are invisible.
- Transformation — Log normalization can alter event semantics. A "deny" event in the source may become an "access attempt" in the SIEM, losing the denial information.
- Transmission — Network issues can cause log loss. The SIEM has no mechanism to detect missing events unless it knows the expected event rate.
The SIEM processes whatever arrives. It has no ground truth against which to compare. It cannot distinguish "no events because nothing happened" from "no events because the source stopped logging."
Correlation Is Not Verification
SIEM correlation rules detect patterns across multiple log sources. "Alert if a user authenticates from two countries within one hour." "Alert if privilege escalation follows a failed login attempt." These are valuable operational security signals.
But correlation operates on the reported events, not on verified truth. If the authentication log reports a login from New York when the actual login was from Lagos, the SIEM does not detect the discrepancy. If the privilege escalation event was fabricated to cover a direct administrative bypass, the SIEM correlates the fabrication as if it were fact.
Correlation increases the sophistication of observation. It does not transform observation into verification.
| Capability | SIEM | Cryptographic Attestation |
|---|---|---|
| Data source | System-generated logs (self-reported) | Cryptographically signed attestation receipts |
| Completeness | Depends on source logging and pipeline | Every state change produces a receipt |
| Integrity | Trusts log content as received | Hash-chained; any modification detectable |
| Verification | Cannot verify log accuracy | Independent mathematical verification |
| Tamper detection | Heuristic (anomaly detection) | Structural (hash chain breaks) |
| Independence | Depends on source systems | Verifiable without trusting any source |
| Replay | Search and review logs (approximate) | Deterministic state reconstruction (exact) |
The Dashboard Illusion
A SIEM dashboard showing all green indicators communicates "all monitored metrics are within expected ranges based on reported data." This is useful for operations. It is misleading for governance.
The dashboard cannot show what is not reported. A control that silently fails produces no log events. No log events means no SIEM alerts. No alerts means the dashboard stays green. The dashboard shows green specifically when governance is failing silently — the most dangerous failure mode.
The most dangerous governance failure is the one that does not generate a log event. SIEMs cannot detect what is not reported. Cryptographic attestation chains detect missing attestations because the chain has a gap where a receipt should exist.
SIEM + Attestation
SIEMs are valuable tools. The argument is not to replace them. The argument is to stop treating their output as governance proof. SIEMs should ingest attestation receipts alongside traditional logs. When they do, the SIEM can verify the cryptographic integrity of each receipt, detect gaps in the attestation chain, and alert on missing or invalid attestations — capabilities it cannot have with traditional logs.
Frequently Asked Questions
Why can't a SIEM prove governance integrity?
SIEMs ingest, aggregate, and correlate logs. They do not generate logs, verify accuracy, or prove completeness. If a source omits events, the SIEM has no mechanism to detect the omission. SIEMs observe self-reported data.
What is the difference between observability and proof?
Observability shows what systems report about their behavior (trust-dependent). Proof provides independently verifiable evidence that behavior occurred as stated (mathematically verified). Observability can be incomplete. Proof is structurally complete.
Can a SIEM detect log tampering?
Heuristically, by detecting anomalies in log flow patterns. Not cryptographically, because logs lack inherent integrity. SIEM tamper detection is pattern-based, not mathematical. Sophisticated tampering that preserves patterns is undetectable.
How does cryptographic attestation complement a SIEM?
SIEMs can ingest attestation receipts and verify their cryptographic integrity, detect chain gaps, and alert on missing attestations. This transforms the SIEM from a log aggregator into a verifier of cryptographic evidence.
Is monitoring a substitute for cryptographic verification?
No. Monitoring detects anomalies in reported behavior. Verification proves behavior occurred as attested. Monitoring misses silent failures. Verification detects any deviation. Monitoring is operational awareness. Verification is governance evidence.