Chapter 9 — Protecting the Backup Infrastructure Itself

9.1 A Copy Being Intact Is Not Enough on Its Own

In Chapters 7 and 8, we looked at the placement and properties of the Backup copy itself. Distributing copies across multiple locations, and confirming properties such as Off-site, Offline, Isolated, and Immutable, were all about how to protect the copy itself.

However, no matter how appropriately a copy is protected, if the mechanisms used to operate it, manage it, and actually use it for Recovery share the same weaknesses, Backup as a whole may in the end not be sufficiently protected.

The central idea covered in this chapter is the following:

Recoverability depends not just on the Backup data itself, but also on the administrative authority, credentials, keys, and tools needed to use it safely.

In this book, we use Recoverability to refer to an organization or system being in a state where it can actually carry out Recovery. Recovery capability, as used in the body text, is also used in this same broad sense unless a specific technical distinction is indicated.

Let's look at the Backup infrastructure itself as one of the things that needs to be protected.

9.2 Separating the Credentials Used to Manage Backup

The first thing to consider is the credentials used to manage Backup.

It is important not to let the credentials used to manage Backup depend on the same credentials used for normal production-environment or network administration.

If the authority to manage Backup is tied to the same account as the day-to-day administrative authority over the production system, then when the production environment's administrative authority is compromised, the Backup administrative authority could be compromised along with it.

Related elements to this idea include the following:

• granting only the minimum privilege necessary (least privilege)
• administering it through a path different from the normal network (network segregation)
• adding extra protection (such as MFA) for destructive operations such as deletion

These are touched on only lightly here, as elements that reinforce the idea of separating the credentials used to manage Backup. This chapter does not cover concrete credential values or configuration steps for specific products.

9.3 Confirming Who Can Disable a Protection

Even once credentials are separated, there is still something to confirm.

Even if an authorization-separation or additional-protection mechanism exists, if the administrator being protected against still holds sufficient authority to disable or reconfigure that mechanism, the effect of the protection can be limited.

For example, even if a mechanism requiring additional approval for critical operations has been introduced, if the Backup administrator that mechanism is meant to constrain still holds the authority to disable it, the intended separation does not actually hold.

The question worth holding onto here is:

"Who holds the authority to disable this protection?"

For example, in Azure, a mechanism called Resource Guard can establish an authorization boundary separate from the normal Backup administrator for critical operations. However, if the Backup administrator being protected against is also given strong authority over managing Resource Guard itself, the intended separation can be weakened.

For example, AWS provides a mechanism called multi-party approval, in which approval is distributed across multiple approvers.

These are only bounded implementation examples for specific products. The implementation mechanism differs by product, and neither one is the only solution for every situation.

9.4 Key Management as a Separate Object of Administration

In Chapter 8, we saw the need to confirm "who can remove a protection."

This chapter takes that question one step further: how is that administrative authority itself protected?

As we saw in Chapter 8, even if the backup data itself remains, if the cryptographic material needed to decrypt it — such as a key — is lost, changed, or becomes unavailable, that data may in practice be unusable for recovery.

What we want to newly consider in this chapter is: who holds the authority to manage, change, or delete that key?

Not just the data, but also the authority to manage the key needed for decryption, is an administrative matter that affects Recovery. Even if the key itself is stored securely, if the authority to handle that key is the same as the production environment's administrative authority, this can become the same structural weakness we saw in 9.2.

The concrete design of a key management system, or key rotation procedures, are not covered in this chapter.

9.5 Logs and Administrative Tools Can Also Be Objects of Protection

The elements that make up the Backup Infrastructure are not limited to credentials, administrative authority, and keys.

Logs and Audit Trails

Logs and audit trails can also be important elements for later confirming the state of the Backup Infrastructure, and who performed what operation.

The detailed design of exactly which operations should be logged, or how long logs should be retained, is not covered in this chapter. Here, hold onto the point that it is important to be conscious of logs themselves as one of the things that need to be protected.

Tools Needed for Recovery / Backup

If the tools or administrative functions needed for Recovery are not available, then even if Backup data exists, the actual recovery work may not be able to proceed.

The tools themselves needed for Backup/Recovery also need to be considered part of the Backup Infrastructure. What tooling is actually needed differs by system, so this chapter does not go into individual product configurations.

Dependence on Foundational Services

The administration of Backup itself can also depend on the availability of foundational services such as identity and authentication. When thinking about Recovery planning, the availability and trustworthiness of these foundational services also need to be taken into account. That said, identity and authentication are not the only example of this kind of foundational dependency.

Representative Elements to Confirm in This Chapter

Let's organize what we've covered so far into a simple table.

This table is an organization of representative points to confirm in this chapter, not an official list of required items defined by an industry standard. How important a given element actually becomes depends on the system's configuration.

9.6 The Idea of Protecting the Backup Infrastructure as a Whole

The credentials, administrative authority, keys, logs, and tools we have covered so far are all elements separate from the Backup data itself. However, if any of these shares the same weakness as the production environment, actual Recovery may not be protected no matter how appropriately the Backup copy itself is protected.

This idea also matters when thinking about attacks aimed at disabling Backup. An attacker targeting Backup itself may target not just the copy, but also the authority and infrastructure that manage it.

Also, given the possibility that normal credentials or administrative tools may become unavailable, the Backup Infrastructure itself needs to be protected in normal times, in advance. How to respond when the normal administrative path becomes unusable is covered again in a later chapter.

9.7 Summary

This chapter organized the idea of treating the Backup Infrastructure itself as something to protect.

The important points are these:

• Even if the Backup copy itself is protected, that alone does not necessarily mean Recovery is protected.
• The credentials used to manage Backup should be separated from the credentials used for normal production-environment and network administration.
• Even where an authorization-separation mechanism exists, if the administrator being protected against holds the authority to disable it, the protective effect can be limited.
• Even if data remains, if the authority to manage or change the key needed for decryption is not protected, the same kind of structural weakness can result.
• Logs, audit trails, and the tools needed for Recovery/Backup can also be objects of protection, as part of the Backup Infrastructure.

In the next chapter, we look in more detail at how threats such as Ransomware and insider threats can directly target the Backup Infrastructure.

Questions to Consider After Reading Chapter 9

Thinking about the systems you are responsible for, can you answer the following questions?

• Why is it not enough, on its own, that the Backup copy is intact, to say that Recovery is protected?
• Can you explain the reason for separating the credentials used to manage Backup from the normal administrative credentials?
• Why does it matter to confirm who holds the authority to disable a protection?
• Can you explain why key management is a concern even when Backup data remains?
• Why can logs and Recovery tools also be objects of protection?

You do not need to be able to answer all of them.

Rather, if there is a point where you get stuck, that is exactly the point this chapter is meant to help you check.