In Safeguard 11.2, we talked about making sure backups happen automatically and frequently enough to meet the needs of the business. Once those copies exist, however, another question immediately follows. How are you protecting them?
CIS Safeguard 11.3, Protect Recovery Data, addresses that question. The basic expectation is that recovery data should receive protections equivalent to the original data. If sensitive information requires encryption, restricted access, or other safeguards in production, creating a backup doesn’t eliminate those requirements. That sounds obvious when you say it out loud. In practice, it isn’t always treated that way.
The backup contains the same data
Organizations spend a great deal of time protecting production systems. They restrict access to financial applications, protect employee information, encrypt sensitive databases, and carefully manage intellectual property. Then they copy all of that information into a backup repository.
The classification of the information didn’t change just because the location did. A backup of sensitive data is still sensitive data. A backup containing Social Security numbers still contains Social Security numbers. Intellectual property doesn’t stop being intellectual property because it was copied to another storage device.
In some cases, the backup environment may actually represent a more concentrated target than the production environment. Instead of compromising several individual systems, an attacker who gains sufficient access to the backup infrastructure may find copies of information from across the organization in one place. That makes recovery data worth protecting in its own right.
The requirements follow the data
I’m currently helping a client prepare for CMMC requirements. Their recovery environment contains Controlled Unclassified Information (CUI), along with technical information subject to export-control requirements.
That creates an important limitation. We can’t simply decide that sending the backups to any convenient cloud storage provider solves the problem. If the recovery data is moved to an external provider, that environment has to satisfy the contractual, regulatory, and export-control requirements applicable to the information.
The specific requirements depend on the data, the contract, and the environment, but the underlying lesson is much broader than CMMC or ITAR.
The backup inherited the requirements of the information stored inside it. Moving CUI from a production server to a backup appliance doesn’t make it ordinary business data. Moving regulated information into a cloud repository doesn’t remove the organization’s obligation to protect it. The location may change. The sensitivity doesn’t. That’s the heart of this safeguard.
Production shouldn’t be the only thing protected
It’s easy for security controls to become concentrated around production systems because that’s where people work every day. Production systems get attention. They’re patched. Access is restricted. Logging is enabled. Sensitive information may be encrypted.
Backup infrastructure can quietly receive less scrutiny because it’s viewed as something that sits in the background until needed. That’s dangerous.
Access to recovery data should be limited to the people and systems that legitimately require it. Administrative access to the backup platform should be treated carefully. Recovery repositories shouldn’t become convenient file shares where anyone in IT can browse around because they happen to have credentials.
The same principle we’ve discussed throughout these controls still applies: access should exist because there’s a business or technical requirement for it, not simply because granting broad access is convenient.
Encryption matters here too
Encryption is another obvious example. If the organization determined that particular information requires encryption in the production environment, storing an unencrypted copy of that same information in the backup environment defeats much of the purpose.
Recovery data may need protection while it’s stored and while it’s being transferred between systems or locations. The exact implementation will depend on the technology being used, but encryption should be part of the conversation whenever backups contain information that requires it.
The important thing is consistency. It doesn’t make much sense to carefully encrypt a production database only to create an unprotected copy of it every night.
Protect the integrity of the backup
Confidentiality isn’t the only concern. Recovery data also needs to remain trustworthy. If someone can modify backup data without authorization, the organization may not discover the problem until it needs to recover. That could turn an already difficult incident into something much worse.
Organizations should therefore think about who can change or delete backup data in addition to who can read it. Administrative accounts, backup service credentials, and permissions around recovery repositories all matter.
The goal isn’t simply to prevent someone from stealing the backup. It’s also to preserve the integrity of the information you’re depending on to rebuild the environment.
We’ll get deeper into maintaining an isolated recovery copy in Safeguard 11.4. That’s related, but it’s a different problem. Safeguard 11.3 is about making sure the recovery data itself is appropriately protected wherever it resides.
Third parties don’t remove the responsibility
Cloud services and managed backup providers can make recovery substantially easier, but outsourcing backup infrastructure doesn’t outsource responsibility for the information. Organizations should understand how their providers protect recovery data, including how access is controlled, how information is encrypted, and what security commitments are included in the service.
This becomes especially important when regulated or contractually protected information is involved. The correct question isn’t simply, “Does the vendor provide backups?” It’s, “Can we store this information there, and does the service protect it in a way that meets our requirements?” Those are very different questions.
Don’t forget physical media
Not every backup resides in the cloud. Organizations still use removable drives, storage appliances, tapes, and other physical media. Older technologies haven’t completely disappeared, and sometimes there’s a good business or technical reason for using them.
The same rules apply. A tape containing sensitive information needs to be protected just as surely as a cloud repository containing the same information. Physical access, storage, transportation, and eventual disposal all become part of protecting the data. The medium changes. The organization’s responsibility doesn’t.
A place to start
If you’re evaluating Safeguard 11.3, begin by looking at what your backups actually contain. Determine whether the recovery environment includes regulated information, employee data, customer information, intellectual property, financial records, or other sensitive data. Then compare the protections applied to the backup environment with the controls protecting the original information.
Who can access the backups? Who can administer the platform? Is sensitive recovery data encrypted appropriately? Are third-party providers authorized to store the types of information you’re sending them? Could someone modify or delete recovery data without appropriate authorization? Those questions usually tell you quickly whether recovery data is being treated as part of the security environment or simply as storage.
Safeguard 11.2 made sure the backup was created. Safeguard 11.3 makes sure that creating it didn’t also create another place for sensitive information to be exposed. A backup is still your data. Protect it accordingly.
