Chapter 11 — Restorable Backup ≠ Safe Cyber Recovery

11.1 Being Able to Restore and Being Able to Adopt Are Not the Same

In Chapter 1, we saw that Restore success and Recovery success are not the same thing. This chapter takes that idea one step further.

Even if you can technically retrieve data from a Backup successfully, that does not necessarily mean it is acceptable to return that state to production as-is.

Being technically able to Restore does not, by itself, prove that it constitutes safe cyber recovery.

In this book, we organize this relationship as follows:

Restorable Backup ≠ Safe Cyber Recovery

This is an organization used to aid understanding in this book, not standard phrasing established by NIST or CISA.

The technical documentation published by NIST (the National Institute of Standards and Technology) also addresses the need to think separately about the act of restoration and the verification of a trustworthy state. This chapter follows that line of thinking.

11.2 "Newest" Is Not Always Best

In Chapter 1, we saw that, when deletion, logical corruption, or a malicious change has occurred, recovery may need to go to an older, known-good state, and that the newest state is not necessarily the correct recovery state.

This chapter digs further into this idea in the context of cyber recovery.

The newest Backup is not necessarily the correct cyber recovery state.

A Backup taken after a compromise may be holding a state such as:

• an encrypted state
• a corrupted state
• some other state that cannot be called safe

In this book, we organize this relationship as follows:

Latest Backup ≠ Correct Recovery State

This, too, is an organization used to aid understanding in this book, not standard terminology.

There is a point to note here. This idea does not mean "the newest Backup is dangerous." It means that "being newest" does not, by itself, automatically guarantee a correct recovery state. Which point in time is actually appropriate needs to be judged based on what is known about the state at that point in time; there is no uniform rule such as simply "choosing an older Backup is safe" or "going back a certain number of days is safe."

11.3 How to Verify the State of a Recovery Point

So how should you go about verifying the state of a Recovery Point?

NIST's technical documentation addresses verification at two stages in cyber recovery:

1. Verifying the assets used for restoration, before they are used
2. Verifying the restored system or data, before returning it to production

In other words, verification is needed not just once, but at least two distinct stages: first confirming that the Backup and related assets you intend to use for restoration do not themselves have a problem, and then, after actually restoring, verifying the result once more before putting it into production.

The concrete procedures for how to verify, or what tools to use, are not covered in this chapter. What matters here is the idea that a two-stage verification is needed: "before use" and "before returning to production."

11.4 On the Term "Clean Recovery Point"

For ease of understanding, this book sometimes uses the candidate term "Clean Recovery Point."

However, this is not standard terminology established by NIST or CISA. It is a candidate term used within this book.

Expressions actually used in authoritative technical documentation include the following:

• last known good configuration
• correct backup version
• backup free of malicious code
• secure or trusted state

Each of these expressions carries a slightly different nuance, and none of them is simply a synonym interchangeable with the single term "Clean Recovery Point." Whenever this book uses the term "Clean Recovery Point," keep in mind that it is a term used for teaching purposes, not a definition from a standard specification.

11.5 Handling Cases Where Uncertainty Remains

In cyberattacks, particularly incidents like ransomware, it can be unclear when and from where the problem actually began.

• It can be unknown exactly when a compromise began.
• Investigation can narrow the uncertainty, but it does not necessarily fully remove it.

There is an important idea to hold onto here.

Do not replace "not knowing" with "being safe."

For example, it is not appropriate to conclude that a Backup is "clean" or "safe" for reasons such as only the following:

• the Restore succeeded
• it was protected as Immutable
• the hash value matched
• it passed an antivirus scan
• it is a Backup taken before detection

Each of these can be a useful clue, but none of them alone proves "safety." What is not known needs to be treated as not known, with a clear distinction kept between what has been confirmed and what has not yet been confirmed.

11.6 Connecting to the Next Chapter

In Chapter 10, we saw that Backup itself can become an attack target. This chapter took that question further, considering, even when a copy is intact, which point in time you should actually trust and adopt for Recovery.

The ideas confirmed here also relate to elements such as the following.

Whether a Recovery Point actually turns out to be useful depends not only on the state of that Recovery Point itself, but also on whether the dependencies needed to use it are available. This point is covered again in a later chapter.

Also, how to begin Recovery from a state where the normal access path cannot be used, how to actually put together a recovery plan, and how prior testing can increase confidence in a Recovery Point are each covered in later chapters.

11.7 Summary

This chapter organized the idea of distinguishing between a Backup that can be technically Restored and a state that can safely be adopted for cyber recovery.

The important points are these:

• Being technically able to Restore does not, by itself, prove safe cyber recovery (Restorable Backup ≠ Safe Cyber Recovery).
• The newest Backup is not necessarily the correct cyber recovery state (Latest Backup ≠ Correct Recovery State). However, this does not mean "newest is dangerous" — it means that being newest does not automatically guarantee correctness.
• The state of a Recovery Point needs to be verified at least two stages: before use, and before returning to production.
• "Clean Recovery Point" is a candidate term used in this book, not standard NIST/CISA terminology.
• When something like the start of a compromise is unknown, that uncertainty must not be replaced with a conclusion of "safe."

Representative Perspectives to Confirm in This Chapter

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

This table is not a checklist for automatically determining a Recovery Point; it is an organization of representative perspectives covered in this chapter. Satisfying every row does not, by itself, prove that a given Recovery Point is automatically safe.

Questions to Consider After Reading Chapter 11

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

• Why can being able to Restore alone not prove safe Cyber Recovery?
• Why is the newest Backup not always the correct Recovery Point?
• Why is it necessary to verify both the assets used for restoration and the assets that result from restoration?
• Why should the term "Clean Recovery Point" not be treated as standard NIST/CISA terminology?
• When the start of a compromise is unknown, why must "not knowing" not be replaced with "safe"?

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.