In Safeguard 11.3, we talked about protecting recovery data with controls appropriate to the information it contains. A backup containing sensitive information is still sensitive information, and moving that data somewhere else doesn’t reduce the organization’s responsibility to protect it. Safeguard 11.4 asks a different question. What happens if the same event that takes down your production environment can also take down your backup?

CIS Safeguard 11.4, Establish and Maintain an Isolated Instance of Recovery Data, requires organizations to maintain at least one recovery copy separated from the primary environment. That separation might be physical, logical, or both. The concept is pretty simple. A backup isn’t much of a recovery option if the same incident can destroy both copies.

 

A backup isn’t necessarily isolated

 

I work with a small family-run business that maintains sensitive information about its clients. They have a backup. In fact, it’s stored on a USB drive connected directly to their physical server in a colocation facility.

That’s certainly better than having no backup at all. From one perspective, it’s even physically separated from their office. If something happens to the business location, their server and backup are sitting somewhere else.

But look at it from the perspective of the server itself. The USB drive is plugged directly into the machine it’s protecting. If that server is compromised and an attacker can reach the attached storage, the backup may be compromised as well. Ransomware that can encrypt the server may be able to encrypt the backup. Someone with sufficient administrative access may be able to delete both.

And if something catastrophic happens to the colocation facility, production and recovery data are sitting in the same place. They have a backup. What they don’t really have is isolation.

 

Think in terms of failure domains

 

That’s the larger idea behind this safeguard. When you’re evaluating a recovery strategy, ask what events could affect both the production system and the recovery copy at the same time. A fire is an obvious physical example. So are flood, theft, electrical damage, or another event affecting the facility.

Cyber incidents create a different kind of shared failure domain. Production and backup systems may be in different buildings but still use the same credentials, administrative environment, or network access. An attacker who compromises one may be able to reach the other.

Simply moving a backup somewhere else doesn’t necessarily solve the problem. The objective is to create enough separation that losing one environment doesn’t automatically mean losing the other.

 

Off-site, isolated, immutable, and offline aren’t the same thing

 

These terms sometimes get used interchangeably, but they’re solving slightly different problems.

• An off-site backup provides geographic separation. If something happens to the primary facility, the recovery copy is somewhere else.
• An offline backup isn’t continuously accessible from the production environment. Traditional tape rotation is a simple example. Once the tape leaves the drive, malware on the network can’t encrypt the tape sitting on a shelf.
• An isolated backup is separated in a way that makes it difficult for the same compromise to affect production and recovery data. That might involve separate infrastructure, separate administrative boundaries, different credentials, or another security domain.
• An immutable backup can’t be altered or deleted during a defined retention period. Even an administrator or attacker with significant access may be prevented from changing that recovery copy until the immutability period expires.

None of these concepts automatically guarantees the others. A backup can be off-site but accessible with the same compromised credentials. An immutable backup can reside in the same general environment as production. An isolated system isn’t necessarily immutable. Good recovery architecture often uses more than one of these protections because they’re addressing different risks.

 

Sometimes the better answer isn’t immediately available

 

I’m currently working with another organization where the situation is almost the opposite. They’re preparing to meet CMMC requirements and handle sensitive government information. They have a Datto backup appliance on-site that maintains a local recovery copy and also replicates recovery data to the cloud.

From a recovery perspective, the cloud replication provides an important second location. Losing the local environment doesn’t automatically mean losing the recovery copy. Unfortunately, the information they’re protecting is also subject to regulatory and contractual requirements that limit where that data can be stored. Their existing cloud backup arrangement doesn’t satisfy the requirements we’re working under, so we’re having to disable that portion of the backup architecture.

That creates a real problem. The remaining on-site backup still provides recovery capability, but we’ve intentionally removed some of the separation that previously existed. Replacing that cloud capability with an appropriately compliant alternative is possible, but it isn’t inexpensive.

We’ve talked through the risk. They understand it. For now, they’re comfortable accepting that additional exposure while they determine what the longer-term solution should look like. That’s an important part of risk management too.

The answer isn’t always, “Buy the perfect solution tomorrow.” Sometimes the organization understands the risk, documents it, and makes a deliberate business decision about when and how to address it. What’s important is that the decision is informed. Nobody should believe an on-site backup provides the same resilience as a properly isolated recovery copy when it doesn’t.

 

Ransomware changed the backup conversation

 

Years ago, backup planning focused heavily on hardware failure and physical disaster. Those risks haven’t gone away, but modern attackers have added another concern. They know backups matter.

If ransomware encrypts production but the organization has a clean recovery copy, the attacker’s leverage is substantially reduced. That makes backup infrastructure an attractive target. An attacker who gains sufficient privileges may try to delete recovery points, disable backup jobs, compromise backup repositories, or otherwise remove the organization’s ability to recover.

That’s why logical separation matters just as much as geographic separation. If the same administrative account controls production and backup environments, compromising that account may provide access to both. Separate credentials, administrative boundaries, immutability, and other controls can make it much harder for one compromise to eliminate every recovery option.

 

The old ideas still work

 

The technology has changed, but the principle isn’t new. For years, organizations used some variation of the 3-2-1 backup concept: maintain multiple copies of important data, use different storage approaches, and keep at least one copy separated from the primary environment.

That might once have meant rotating tapes to an off-site storage company. Today it may mean cloud storage, immutable repositories, separate backup environments, or a combination of technologies. The implementation changes but the goal doesn’t. Don’t let one event take everything.

 

A place to start

 

If you’re evaluating Safeguard 11.4, start by looking at your current recovery copies and asking a few uncomfortable questions. If ransomware compromises the production environment, can it reach the backups? If an administrator’s credentials are stolen, can those credentials delete production data and recovery data? If the building containing your primary systems is lost, where is the recovery copy? If your cloud environment is compromised, is there another copy outside that environment? And if your recovery data is supposed to be immutable, what actually prevents someone from changing or deleting it?

You don’t necessarily need the most complicated architecture available. You need enough separation that the risks you’re trying to recover from can’t easily eliminate the recovery data at the same time.

Safeguard 11.2 made sure backups happen.

Safeguard 11.3 made sure those backups are protected.

Safeguard 11.4 asks whether they’ll still be there after the incident you needed them for. Because having a backup is useful. Having a backup the disaster can’t reach is what gives you a way back.