Chapter 12 — Recovery Is a Dependency Problem

12.1 Recovery Is Sometimes Not Possible Even When a Backup Exists

In the chapters so far, we have looked at the properties of Backup data itself, and at its trustworthiness as a Recovery Point.

However, even when Backup data exists and can be technically Restored, that alone does not necessarily mean Recovery is complete.

An organization's Recovery capability is not just a property of the Backup data alone — it also depends on the recoverability of the various dependencies needed to use that data safely.

In this book, we organize this idea as follows:

An organization's Recoverability depends not only on the recoverability of the Backup data, but also on the recoverability of identity, network, assets such as cryptographic keys, configuration, tools, and other dependencies needed for Recovery.

This is a view that this book has organized by integrating multiple perspectives covered so far; no single authoritative document defines this whole picture as-is.

12.2 Being Available and Being Trustworthy

When a dependency obstructs Recovery, the reason is not always singular.

At minimum, the following two need to be distinguished as separate problems:

• when that dependency is unavailable
• when that dependency is available, but not yet trustworthy

For example, if the administrative path to a given system has not itself been recovered, that is an "unavailable" state. On the other hand, even if the administrative path itself is running, if it cannot be confirmed that the path, or the principal accessing through it, has not been compromised, that is a state that "cannot yet be called trustworthy."

Being available and being available in a way you can trust are separate problems.

Being "available" does not, by itself, mean being "trustworthy." In the same way, being "reachable" does not, by itself, mean being "safe." The material used throughout this book also treats both a normal administrative path being unavailable and it not yet being trustworthy as separate situations that can each obstruct Recovery.

12.3 How to Organize Recovery Dependency

As we have seen, Recovery can depend on various elements beyond Backup data.

This book presents one integrated perspective for organizing these dependencies.

This organization is something this book has put together by combining multiple perspectives covered so far; it is not a single official checklist defined by NIST or CISA.

The table below organizes representative groups of dependencies and how each can relate to Recovery.

This table is not a checklist for automatically determining Recovery dependency. Not every row necessarily applies to every organization's situation, and the classification given here does not represent a ranking of priority or importance.

12.4 Foundational Dependencies

Of the dependencies in the table above, Identity / Administrative Access and DNS / Network / Time have a foundational character, tending to be a precondition for using many of the other dependencies.

Recovery may require a functioning, trustworthy authentication/administrative path for accessing systems or data. If this path itself is unusable, there is no way to make use of the other dependencies, even if they are intact.

Similarly, reachability, name resolution, and time synchronization for needed services, while not necessarily advanced technical topics in themselves, can be a precondition for many other mechanisms. DNS may be used for the name resolution of needed services. Network may relate to reachability for needed systems or services. Time may be something that some systems or security mechanisms depend on having sufficiently correct information about.

This chapter does not go into the technical mechanisms or configuration methods for these elements. What matters here is holding onto the idea that these can become foundational dependencies.

Note also that the design of how to protect these paths — credential separation, MFA, Dual Authorization, Emergency Access — has already been covered in Chapters 9 and 10, and is not covered again in this chapter.

12.5 Dependencies for Using the Data

Even when the Backup data itself remains, several dependencies may be needed to actually make it usable.

Regarding storage, even if the Backup copy itself remains, if the storage needed to deploy and use it for Recovery is unavailable, it cannot actually be used. Regarding database, an application may depend on the availability and state of a database. Regarding the application/runtime, even if only the data comes back, that may not be sufficient if the application or runtime needed to work with it is unavailable.

Keys / Certificates / Secrets are also an important dependency in this context.

Even if the Backup data remains, can you use that data if the information needed for decryption or connection is unavailable?

Keys, certificates, and secrets are dependencies that each play a different role. This book sometimes groups them together for teaching purposes, but note that they are not the same concept, and their availability needs to be confirmed separately for each.

Configuration / Tools are also worth touching on here. Recovery may require the configuration information needed to restore and operate a system, and the tools used for the restoration work itself.

The technical internal structure of these — storage replication methods, the internal workings of database recovery, PKI architecture, CMDB or IaC design, and the like — is not covered in this chapter.

12.6 Monitoring / Validation / External Dependencies

Recovery may require a mechanism to observe and confirm whether the restored environment is functioning as expected.

Chapter 9 covered the idea of protecting logs as part of the Backup Infrastructure. Chapter 10 covered protecting audit information. Rather than covering these again, this chapter confirms only that the Monitoring/Logging mechanism itself can be a dependency needed to understand, operate, and confirm the post-restoration state.

Also, Recovery can depend on external services or communication means not included in the Backup copy itself. Hold onto this as a general idea, without assuming any specific service or product.

The architecture design of SIEM or SOC, and the individual mechanisms of specific external services, CAs, or cloud APIs, are not covered in this chapter.

Recovery does not necessarily complete through technical elements alone — the availability of the necessary personnel and procedures can also have an effect.

12.7 Dependency Is Not Necessarily a Simple Order

The dependencies covered so far can each obstruct Recovery, but there is not always one fixed order among them.

The existence of a dependency can constrain the order of Recovery. However, understanding the dependency relationships alone does not automatically determine the concrete order in which Recovery is carried out.

Furthermore, dependencies are not necessarily arranged in a simple straight line.

A circular dependency can also become a problem — for example, where one service needs another service to be restored, and that other service in turn needs the first service to be restored.

This chapter confirms only that this kind of circular dependency can exist, and does not cover how to resolve it. How to begin Recovery from a state where the normal access path is unusable is covered in a later chapter.

Understanding dependency relationships gives you material for thinking about the actual Recovery order. The concrete recovery plan and how to put together an execution order are covered in a later chapter.

12.8 Summary

This chapter organized the idea that Recovery is not just a problem of Backup data, but also a problem of dependencies.

The important points are these:

• An organization's Recoverability depends not only on the recoverability of the Backup data, but also on the recoverability of identity, network, assets such as cryptographic keys, configuration, tools, and other dependencies.
• A dependency can obstruct Recovery for at least two distinct reasons: being "unavailable," and being "available but not yet trustworthy."
• The organization of dependencies shown in this chapter is this book's own integrative perspective, not a single official checklist defined by NIST or CISA.
• Dependencies can constrain the order of Recovery, but that alone does not automatically determine the concrete execution order, and circular dependencies can also exist.

Questions to Consider After Reading Chapter 12

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

1. Why can Recovery sometimes not be possible even when Backup data exists?
2. Why are a dependency being "available" and being "trustworthy" separate perspectives?
3. Besides identity and keys, can you explain two or three other elements Recovery can depend on?
4. Why should this chapter's dependency list not be treated as an official NIST/CISA checklist?
5. Why does understanding dependencies alone not automatically determine the execution order of Recovery?

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.