The Next Shift in Cyber Security: From Detection to State Reconstruction
For two decades the industry has operated on the assumption that if you collect enough logs and telemetry, you can understand what happened inside your environment. That assumption is breaking down. Modern systems are fragmented, short lived, identity driven, and full of places where truth is partial or missing entirely. Attackers have already adapted. They operate inside the blind spots defenders still treat as reliable.
Logs can be suppressed. Telemetry can be manipulated. Hooks can be bypassed. Cloud trails can be replayed or redirected. Identity movement across federated systems can remain technically legitimate while being operationally invisible. The problem is not the tools. It is the trust model. We continue to trust the system to tell us the truth about itself long after that trust stopped being justified.
This is not the first time the industry has had to rethink trust. We relied on whitelisting until attackers adapted and pushed us toward EDR and behavioural analysis. Each shift happened because the previous trust layer broke. We trusted binaries. Then process behaviour. Then the event stream. Now the environment itself is no longer reliable enough to report what actually happened. Every major transition in security has been triggered by a failure of trust, and this one is no different.
The next phase of cyber security will not be defined by more detections or more analytics. It will be defined by the ability to reconstruct state. By reconstruction, I mean rebuilding the actual conditions of memory, execution artifacts, identity graphs, persistence anchors, and system behaviour as they existed in reality, not as they were reported through the telemetry pipeline. This shifts the centre of gravity from prediction to evidence.
Once you start from state, the visibility model changes. Memory becomes the source of truth. Artifacts become the anchor for correlation. Execution paths can be rebuilt instead of inferred. Identity relationships become visible rather than implied. Logs still have value, but they describe intention rather than reality. Behavioural detection also has value, but it becomes far more accurate when grounded in evidence rather than statistical prediction. System truth becomes more important than system reporting.
Recommended by LinkedIn
We are already in an environment where workloads, identities, containers, and entire processes can exist for minutes. They appear, perform their function, and vanish. The only stable element is the evidence they leave behind. Logs describe intention. Telemetry provides interpretation. State provides proof.
I do not see the future of cyber security as a bigger alert pipeline. I see it as the operationalisation of forensic concepts at continuous scale. If you can reconstruct reality as it existed, you no longer depend on the honesty or survivability of the telemetry stack. Once you reach that point, the entire security model shifts into something very different from what the industry has repeated for the last twenty years.
-
I want to be clear about my own position in this space. I have believed for years that security needed to move toward state reconstruction, and I have been building a platform based on that model. Readers should know that I hold this view because I have seen its value firsthand and have already put it into practice.
To improve security ( and performance and effiency ) of any IT process, what I would ideally love to have is visibility of all the collectable parameters of every change/ event/ action. have it parsed by someone/something more aware than a human (wink*AI*) and find out anamolies/ correlations/ issues/ opportunities on something akin to recursive bayesian algos and bring to our attention the most salient features. Automatically act upon the events it is sure of and leave a number of insights for us. Big ask I know. :-) TL,DR; Rather than state reconstruction, the 'it' should not lose the system state ever and give us insights too. I know you are talking the next shift/ step and I am thinking of the ultimate / holy grail kind of a thing. Apologies for the meandering comment/s :-)
And then, even if the logs are collected within the SIEM, there are rules/ policies that act upon them. Some of the info is lost there. In most SOCs the rules are the default set only lightly tweaked because the security teams have a lot (alerts and more) already on their plates. After all, they have to generate the MIS reports and look good on them too. Lets say a log event or a correlation generated an alert. It reaches the poor L1 analyst who is already overworked, rather junior in experience, and has not slept the last night firefighting something else. So the L1s device smart , non threatening, politically correct language closing alerts as false positive or confirm with the user cursorily before closing it.
I have long believed logs are a lagging indicators of whatever is happening. If we base our security posture deductions based on logs, we are already behind. Look at how a typical/ traditional SOC works. Logs are collected from data sources. Because budgets are tight and the SIEMs themselves struggle with the deluge of data, only the critical / error/ warning levels are collected. Informational / debug logs are either not generated for high volume data sources, or not collected. Afterall, you have to keep within the EPS licensed / sanctioned :-) That is missed info right there. So the logs miss some info of the event.