After a ransomware attack, the first priority is usually to bring systems back online. Teams look for an available backup, pick a date before the incident, and start the restore.
This step is necessary. It does not, however, answer the harder question: can the restored data actually be trusted?
The attack often starts before the encryption
Visible file encryption rarely marks the start of the incident. An attacker may have been present for days, sometimes weeks. During that time, they can create accounts, modify permissions, drop tools, alter configurations, or set up persistence mechanisms.
The last backup taken before the ransomware triggered may therefore already contain a compromised environment.
Restoring that backup would bring back readable files, but it could also reintroduce the conditions that made the attack possible.
The backup answers a first question: what data can we recover? Trusted recovery asks another one: which state should we choose, and why can we trust it?
Three dates that do not necessarily coincide
After an incident, three points in time must be distinguished:
- the last available state
- the last technically intact state
- the last state whose trustworthiness can be reasonably established
The most recent is not necessarily the safest.
A version can carry a perfectly consistent fingerprint while still containing a malicious change. Cryptographic integrity shows that this version has not been altered since it was recorded. It does not show that its content was safe at the moment it was recorded.
Choosing a restore point therefore requires more than the date and the state of the files.
Rebuilding the context of each state
To assess a past state, an organization needs to retrieve the information that surrounded it at the time:
- the exact version of the data
- the identities and rights that were active
- accounts recently created or modified
- the applicable security policies
- the events observed by protection tools
- the operations that modified the data
- the dependencies with other files or systems
- human approvals and decisions made
This information is usually spread across storage, backups, the directory service, the SIEM, business applications and various technical logs. Each one keeps part of the story, but none can necessarily rebuild the whole of it at a precise date.
This continuity is often exactly what is missing when it becomes indispensable.
Selecting before restoring
Selecting a candidate state and executing its restoration are two different operations.
The first belongs to investigation and governance. It involves comparing several states, examining their context and qualifying the available evidence.
The second belongs to backup, replication and disaster recovery tools. It actually brings the data and systems back into service.
Conflating the two steps amounts to asking the backup to make a decision it was never designed to make.
A backup knows how to restore bytes. It does not always know how to explain whether the associated rights were legitimate, whether the applied policy was still valid, or whether a change came from an authorized user, a normal process, or an attacker.
Giving data a memory
KARL Core was designed to preserve the identity, versions and governed context of data over time. It links each state to the events, actors, policies and evidence actually captured.
This temporal memory does not replace backup, S3 storage, or cybersecurity tools. It gives them a shared continuity.
When an incident occurs, the goal is not for KARL to automatically declare a version safe. Such a conclusion would remain impossible if some events were never observed or retained.
Instead, KARL helps the organization select a candidate state, document the reasons for that choice, and expose any gaps. The conclusion stays bounded to the governed scope and the evidence actually available.
Coming back at the right moment, for the right reasons
A resilience strategy should therefore not only measure restore speed. It should also measure the ability to answer more demanding questions:
- Why was this version chosen?
- What events precede it?
- Who could modify it?
- Which rules were applicable?
- What evidence suggests it is more trustworthy than the following versions?
An organization returns to normal when it can use its data without rebuilding the conditions of the incident.
The Swedish outlet Aktuell Säkerhet covers this question following StratoFoundry's presentation at the IT Press Tour in Ljubljana: after a ransomware attack, which version of the data can genuinely be considered trustworthy?