Backups Ransomware Cannot Reach: Locked Copies, Separate Permissions and Restore Drills

Suppose an organization has an accounting system and an ordering system that back up every night to a separate storage location. The IT team checks the report every morning and has seen "success" for months. One day the files on the server are all encrypted. The team opens the backup storage to recover, and finds that the earlier copies were deleted or encrypted overnight as well, because the account that administers the main system is the same account that administers the backups.

This scenario is hypothetical and did not happen to any particular organization, but its sequence shows a gap that our article on RPO and RTO did not cover. We wrote about restore drills on the assumption that the copies are still intact. This article answers the next question: if the attacker goes after the copies too, what lets some of them survive?

We write from the viewpoint of a team that designs and delivers systems, not as incident-response specialists. We will describe what CISA's guidance actually says, mark clearly which parts are our own conclusions, and suggest questions an owner can ask a developer to demonstrate at handover.

What CISA's guidance says about backups

CISA is the United States' cybersecurity agency. It publishes the #StopRansomware Guide, which is guidance on preparing for and responding to ransomware incidents. The version we read is dated September 2023 (see CISA's page for the document). The backup-related part, under preparing for an incident, says the following.

• Keep backups of critical data offline and encrypted. The reason the document gives is that many ransomware variants try to find accessible backups and then delete or encrypt them.

• Test the availability and integrity of backups in a recovery scenario, and test backup procedures regularly.

• Some cloud providers offer immutable storage, meaning data cannot be changed or deleted for a set period. The document advises using it with caution, because it may not meet certain compliance criteria and a misconfiguration is costly.

• Separate administrator accounts from ordinary user accounts, and apply least privilege to what the work needs.

There is one thing we should say plainly that this page does not address: separating the backup system's credentials from the main system's credentials directly. The closest points are separating administrator accounts from user accounts and least privilege. When we suggest that the backup system have its own administrators, that is our own reasoning building on that principle, not CISA's wording.

Who this document binds, and who it does not

The CISA document is guidance published by a US agency. It is not Thai law, and it does not bind Thai organizations directly. We are not claiming your organization must follow every point, and we are not quoting any figure for how often ransomware incidents occur in Thailand, because we could not open a source that confirms one.

What remains is its value as a practical observation. The document's main observation matches ordinary engineering logic: a copy the attacker can see and modify is not a copy you can rely on when you actually need it.

What lets a backup survive an attacker

Looking at a backup system from the designer's side, we look for three properties. The first and third come directly from CISA's guidance. The second is our own conclusion.

One: at least one copy sits out of the attacker's reach

CISA's guidance uses the word offline, which can be read in several ways, from media physically disconnected from the network to a copy the main system can write to but cannot delete. In our view, the easiest question to check is this: if the attacker already holds the main system's administrator rights, can they delete or encrypt this copy? If the answer is yes, that copy is not yet safe enough.

Common options are these: media or tape removed and stored separately, which is hardest to reach but needs a person and a procedure to run it; immutable cloud storage that locks deletion for a set period; and a copy in a different cloud account to which the main system has write-only permission. All three have different costs and limits, and we return to this in the limits section.

Two: the backup system's credentials are separate from the main system's

This is our own reasoning, drawn from the least-privilege principle the CISA document mentions. In practice, quite a few systems are set up so that one administrator holds every password, because it is convenient at installation. The result is that one compromised account compromises both the main system and its copies.

We suggest checking three things. First, the account that can delete or modify backups should not be the same account that administers the production servers. Second, sign-in to the backup system should use authentication that is not tied to the same user-management system as the main system, because if that system is taken over, everything tied to it goes with it. Third, you need to know who holds this access and how it changes hands when people change roles. We wrote about handing over access in our article on who really holds your organization's cloud account keys.

Three: a restore you have actually rehearsed from the safe copy

CISA's document says to test both the availability and the integrity of backups in a recovery scenario. This is more demanding than it sounds. Rehearsing a restore every month from a copy that sits in the same storage as the main system tells you nothing about whether the separately stored copy can be restored. Many organizations rehearse with the convenient copy but never with the one meant as the last resort.

We wrote about how to rehearse and how to measure real recovery time in our article on RPO, RTO and restore testing. What this article adds is to pick the safest copy and rehearse from it at least once, and to write down who has to do it, because an account that is safe from an attacker often means an account nobody uses regularly. As for who decides what when the system is actually down, we wrote about that in our article on a DR plan that survives the real day.

Gaps through which backups are often reachable by accident

From our side, the problem is seldom having no backup; it is a backup that leaves a door open without anyone intending it. The examples below are ones we think are worth checking, and they are observations from commonly seen configuration patterns, not events at any client.

• A backup folder or share that stays mounted on the production server. If the server's files are encrypted, that folder is encrypted too.

• Snapshots that live in the same cloud account as the machine they protect. Whoever gets administrator rights to that account can delete the snapshots along with the machine.

• Backup software that runs under an account with the domain's highest privileges, because it was set up once and nobody came back to reduce its rights.

• Passwords or keys for the backup system stored in a document on the machine being backed up, which lets an attacker read them from the same place.

• A retention policy that is too short. If the oldest copy is only a few days old and the encryption of files began before that, every remaining copy may already be bad. How far back you keep copies is part of the answer.

None of this comes directly from CISA's document. It is our own observation, and we do not claim the list is complete.

Questions to ask the developer to demonstrate at handover

We suggest that owners ask the developer or provider to show these things, not to answer verbally, because a demonstration reveals whether the system is what is claimed.

1. Which copy can the main system's administrator not delete? Show what mechanism locks it and for how long.

2. Who holds the right to delete or modify backups? Is it a different account from the production administrator, and how many people hold it?

3. Are the copies encrypted, and where are the keys kept? If the keys sit in the same system as the data, encryption does not help once the whole system is taken over.

4. When was the last restore, from which copy, and how long did it take? Ask to see the drill record, not just a report that the backup succeeded.

5. If a backup fails or is deleted, who is notified? Without an alert, a deleted backup can stay silent until the day it is needed, which connects to our article on setting up monitoring and alerts.

These questions should be in the handover list and the maintenance agreement. We wrote about what to check in a maintenance contract in our article on what to check before signing an annual maintenance contract, and the questions above complement it.

Things not to do just because you read this article

There are three things we do not recommend. The first is buying immutable storage and configuring it yourself without trying it on test data first. CISA's document itself warns that misconfiguration is costly; an example we can imagine is locking data you want to delete for longer than you intended. The second is changing the permissions of a live backup system all at once without going through the normal change process. If the backup software has been running under a high-privilege account, reducing its rights might make tonight's job fail without anyone knowing. The third is believing that one locked copy settles the matter, because a copy that has never been restored is only a belief.

Limits we should state plainly

First, not every organization needs every layer. An organization with a few systems, data that changes little and a small IT team might choose one undeletable copy in a separate account plus a restore drill a few times a year, and that already covers the main risk. Rushing to buy every layer at once may exceed the team's capacity and leave no layer properly looked after.

Second, immutable storage can conflict with requirements to delete data on schedule, such as personal data that must be deleted when its retention period ends. If copies are locked for longer than the retention period the organization has announced, you must agree clearly when the copies will expire and be deleted. This is a trade-off between two risks that legal or whoever is responsible for personal data should help decide. We are not giving legal advice.

Third, we can confirm only what the version of CISA's document we read says. We did not open a source giving a figure for how often attackers target backups, so we do not include one, and the list of gaps above is our observation, not a survey. If you need to plan seriously or you are handling an incident now, consult an incident-response specialist who can assess your system directly.

Finally, having a backup that survives does not stop a system from being attacked; it only lets you return to work. Preventing attacks at the front door is a separate body of work that this article does not cover.

Objections we often hear

The first objection is that we use a cloud service that already provides backups, so there is nothing more to think about. That may be partly true, but the question to ask is whether the copies the provider keeps can be deleted by our account administrator, and whether they survive if our account is taken over. The answer is in each provider's service documents and settings. We did not check any particular provider's terms for this article, so we suggest asking the provider in writing.

The second is that we have a report showing the backup succeeded every night. That report says the job finished. It does not say the copy can be restored, and it does not say an attacker cannot delete it, so it is necessary but not sufficient. The third is that separating permissions slows the team down. That is true and we do not deny it: separating permissions adds steps during recovery. But on the day you actually need to recover, those extra steps usually cost less than having no copy, and it is a trade-off each organization has to decide for itself.

Where to start

1. List the systems and data that would stop the business if lost, then see how many copies each has and where they are.

2. Ask every copy the same question: if the attacker had the main system's administrator rights, could they delete this copy? Mark the ones where the answer is yes.

3. Check whether the account that can delete backups is the same as the main administrator account. If so, plan to separate them and decide who holds each.

4. Pick the safest copy and rehearse one restore from it. Record the time, who did it and the problems found, then fix the steps that broke.

5. Add the five handover questions to the handover documents and the maintenance contract, and set a review date, such as whenever the administrator or provider changes.

Summary

The version of CISA's guidance we read says backups should be kept offline and encrypted, tested regularly, and that immutable storage should be used with caution, because many ransomware variants try to delete or encrypt backups they can reach. If you take one thing from this article, ask every copy whether an attacker who holds the main system's administrator rights could delete it. The answer tells you how many real copies you have.

If you would like to talk through the details of a project, you can reach us at 088-983-9386 or [email protected]. Our office is in Bang Kapi, Bangkok. For organizations still drafting a scope of work, we are glad to arrange a conversation to understand the problem first, without needing complete documents. And if we find that the problem is not yet at the point of needing a new system, we will say so plainly, because starting a project at the wrong time costs more than waiting another quarter.