Building a Recovery Design from an Organization-Wide Ransomware Compromise

The Purpose of This Chapter

From Chapter 1 through Chapter 18, we have confirmed, one by one, various perspectives concerning Backup, Recovery, and Archive.

This chapter adds almost no new ideas. Instead, it confirms how to actually put the ideas organized so far into practice, by applying them to the case of a single fictional organization.

Each section considers a given tension in the following order:

1. What tension exists
2. Which chapter's ideas apply
3. What happens when applied to this case
4. What remains unknown even so (UNKNOWN)

About the Fictional Organization

The organization covered in this chapter is a fictional one, with only the following premises:

• roughly 50 to 150 employees
• a small-to-midsize organization using a hybrid/cloud combination
• the assumed scenario of an organization-wide ransomware and destructive intrusion having occurred

Candidate services under consideration include the following (only examples — not everything is necessarily in scope):

• identity / directory
• DNS / network
• file services
• line-of-business applications
• database
• email / collaboration
• a public website

Candidate data under consideration include the following (also only examples):

• business data
• personal data
• configuration
• credentials / secrets
• keys / certificates
• logs
• records requiring long-term retention

This chapter does not go further into a specific company name, country/region, exact staff count, exact RTO/RPO, exact retention period, exact legal obligation, exact attack timeline, specific product names, data volume, budget, exact recovery time, or exact organizational structure. These are not given as premises of this fictional case.

Premises Regarding the Assumed Threat

This case assumes that the following could occur. These are only premises of this fictional case, not statements presented as general facts about ransomware.

• privileged authority may have been compromised
• identity / the administrative path may be compromised, or may not yet be trustworthy
• accessible Backup infrastructure may have been targeted
• credentials may have been stolen
• the most recent Backup state may also include a compromised state

The concrete techniques used by an attacker, the implementation of malware, and the details of forensic investigation are not covered in this chapter.

CT-01 — The Tension Between Business Priority and Technical Recovery Order

What tension exists.

The business side wants the most important services recovered first. However, the technically executable order does not necessarily follow that.

Which chapter's ideas apply.

Chapter 12 showed that Recovery is a problem of dependencies. Chapter 14 confirmed the organization Business Priority ≠ Technical Recovery Order.

Applied to this case.

In this organization too, a business-critical application may depend on other technical elements (such as identity or a database). In that case, it is not necessarily possible to simply bring back the application first, in order of business priority.

What remains unknown even so.

The concrete configuration of this organization's actual dependencies is not given as a premise of this case. Therefore, what order Recovery should actually proceed in remains UNKNOWN. We do not fix a specific order here.

CT-02 — The Tension Between Retention / Immutability / Privacy / Contract

What tension exists.

Retention under an Immutable setting can conflict with a deletion request or a contractual deletion obligation.

Which chapter's ideas apply.

Chapter 17 showed that an Archive's lifecycle management can include disposition as well as Retention. Chapter 18 showed that, before handling a retention/deletion request, its Authority, Scope, conditions, and exceptions need to be confirmed.

Applied to this case.

If, for some part of this organization's data, a retention/deletion request based on law or contract exists, it first needs to be confirmed which Authority it comes from, who it is imposed on, which data it concerns, and under what conditions.

What remains unknown even so.

Which country/region this organization operates in, and what laws or contracts it is subject to, are not given as premises of this case. Therefore, which obligation actually applies, and whether the Immutable setting or the deletion obligation takes priority, remain UNKNOWN. This chapter, too, does not decide which one wins.

CT-03 — The Tension Between the Newest Recovery Point and a Safe Recovery Point

What tension exists.

The newest Backup is not necessarily a Recovery Point that can be safely adopted as-is.

Which chapter's ideas apply.

As we saw in Chapter 11, selecting a Recovery Point requires considering not just how recent it is, but also whether its state is trustworthy.

Applied to this case.

This organization operates under the premise that the most recent Backup state may also include a compromised state. For that reason, rather than mechanically choosing "the newest Backup," you need to confirm whether that state is trustworthy.

What remains unknown even so.

Which point in time's Backup is actually in a trustworthy state cannot be known from this case's premises alone. This chapter does not make a judgment such as a particular point in time being safe, or an older Backup being safer.

CT-04 / CT-05 — The Tension Between Privileged Administration and Administrative Isolation

What tension exists.

If Backup administrative authority is not separated from normal administrative authority, both can be compromised at the same time. There is also the question of how to prevent a destructive operation by a single authority holder acting alone.

Which chapter's ideas apply.

Chapter 9 showed the idea of protecting credentials, keys, and tools as part of the Backup Infrastructure. Chapter 10 showed that Separation of Duties and Dual Authorization can create a mechanism where a destructive operation cannot be completed through a single path alone.

Applied to this case.

This case assumes that privileged authority may have been compromised. For that reason, we position, as a point that needs to be confirmed, how far this organization's Backup administrative authority is separated from its normal administrative authority, and whether a destructive operation requires multiple authorizing parties.

What remains unknown even so.

This organization's actual organizational chart, division of roles, and authority design are not given as premises of this case. We do not construct specific job titles or a RACI-style framework here.

CT-06 — The Tension Between Backup Existing and Actually Being Usable

What tension exists.

A Backup copy existing does not, by itself, necessarily mean it is in a state that can actually be used for Recovery.

Which chapter's ideas apply.

This relates to Chapter 9's idea of protecting the Backup Infrastructure, and Chapter 12's idea of dependency. The simplification "a copy exists = Recovery is possible" needs to be avoided.

Applied to this case.

This case assumes that accessible Backup infrastructure may have been targeted. Even if the Backup copy itself is intact, if the path to access it, or the key needed for decryption, is unavailable, it may in practice be unusable.

What remains unknown even so.

The detailed configuration of this organization's actual Backup path and key management is not given as a premise of this case. This chapter does not make a judgment such as a particular Backup configuration being safe or dangerous.

CT-07 — The Tension Between Restore Success and Business Recovery

What tension exists.

A Restore technically succeeding, and business actually having been recovered, are not the same thing.

Which chapter's ideas apply.

Chapter 15 distinguished Backup creation, Data Restore, System Recovery, Service Recovery, Multi-system / Business Recovery, and Trusted-state validation as different verification results. This organization is this book's own teaching perspective, not a standard taxonomy.

Applied to this case.

Even if this organization is able to restore a given system's data, that alone does not confirm that the system actually operates, that the related service functions, or that it is actually usable for business. Each requires a separate confirmation.

What remains unknown even so.

The concrete completion criteria for what stage of confirmation would let this organization say "business has been recovered" are not given as a premise of this case.

CT-08 — The Tension of the Normal Administrative Path Being Unusable

What tension exists.

This is the problem of how to begin Recovery from a state in which normal identity, the administrative path, credentials, keys, documentation, and administrative tools are unavailable or untrustworthy.

Which chapter's ideas apply.

Chapter 12 showed that Recovery is a problem of dependencies; Chapter 13 organized the path for beginning Recovery (bootstrap path, Emergency Access) from a state where the normal administrative path is unusable.

Applied to this case.

This case assumes that identity / the administrative path may be compromised, or may not yet be trustworthy. For that reason, we position it as a point this organization's design needs to consider in advance: how to begin Recovery when normal identity or the administrative path cannot be used.

What remains unknown even so.

Whether this organization actually has such an alternative path (Emergency Access) available, and, if so, whether it would actually function in a real incident, cannot be known from this case's premises alone. We do not specify a particular implementation approach here (such as a break-glass product or a specific emergency account design).

Evaluating the Suitability of a Recovery Copy Along Multiple Dimensions

As we have seen, Recovery involves many different perspectives. As one perspective for organizing them, this book presents the idea that the suitability of a Recovery Copy should be evaluated across multiple dimensions.

Concretely, the following dimensions can be considered:

• location (where it is stored)
• network reachability (whether it can be reached over the network)
• identity (what the authentication for accessing it looks like)
• administrative authority (what the administrative authority over it looks like)
• authorization (what the authorization for using it looks like)
• storage (the state of the storage medium)
• cryptographic dependencies (dependencies such as cryptographic keys)
• retention (the state of retention)
• actual restore accessibility (whether it is actually in a state usable for Restore)

This organization is a teaching perspective that this book has put together by combining perspectives from multiple chapters covered so far; it is not a standard taxonomy defined by NIST, ISO, or any other body.

This can be understood as a further, teaching-oriented organization of the Failure Domain perspective covered in Chapter 7, applied here to confirm whether there are any shared weaknesses across a Recovery Copy, from multiple angles.

We do not assign scores or rankings to these dimensions. Nor do we claim that these nine dimensions exhaustively cover everything.

Let's apply this to the case. For the multiple Backup copies this organization holds, questions such as the following can be posed, for example:

• Is that copy under the same administration as the production environment, or is it in a separate location (location)?
• Can that copy be reached over the network (network reachability)?
• Does the authentication for accessing that copy depend on the same identity as normal (identity)?
• Is the administrative authority over that copy the same as the production environment's administrators, or different (administrative authority)?
• Where, and how, are the keys needed to decrypt or use that copy stored (cryptographic dependencies)?

In this case, concrete answers to these questions are not given. The purpose of this chapter is not to provide the answers, but to organize the questions themselves that need to be asked.

Organizing Recovery's Dependencies

As we saw in Chapter 12, an organization's Recoverability depends not only on the recoverability of Backup data, but also on the recoverability of identity, network, assets such as cryptographic keys, configuration, tools, and other dependencies.

For this organization too, organizing which service depends on which dependency is the starting point for Recovery design. That said, not every system necessarily has the same dependency structure. Caution is needed: one service's dependencies do not necessarily apply as-is to a different service.

Preparing for When the Normal Path Is Unusable

As we saw in Chapter 13, beginning Recovery from a state where the normal administrative path is unavailable, or not yet trustworthy, may require a means such as an independently controlled Emergency Access.

In this organization's design too, it is worth posing questions such as the following:

• If normal identity cannot be used, how do you take the first step?
• What do you do if credentials cannot be trusted?
• What do you do if a needed key is unavailable?
• What do you do if you cannot access the procedure documentation itself?
• What do you do if normal administrative tools cannot be used?

Answers specific to this organization for these questions are not given as a premise of this case.

About BIA, RTO, and RPO

As we already saw in Chapters 4 and 5, BIA is the starting point for confirming business impact, and RTO and RPO are objectives representing acceptable downtime and acceptable data loss, respectively. RTO is not simply the time a Restore takes, and RPO is not simply the Backup capture interval.

What this organization's actual RTO and RPO values would be is not given as a premise of this case. As an organization-specific input, this remains UNKNOWN. This chapter does not present concrete numeric examples.

About Archive / Retention

As we saw in Chapter 17, just because something has been stored for a long time does not automatically make it an Archive. In this case too, rather than deciding a classification based only on the name "records requiring long-term retention," it needs to be confirmed for what purpose, and how, it is retained and managed.

This organization also has a candidate data type called "records requiring long-term retention." However, how it would actually be classified as an Archive, and what lifecycle management it would be subject to, is not given as a premise of this case.

About Legal / Privacy / Contract

In Chapter 18, we saw that, for retention/deletion requests, Authority and Scope need to be distinguished, and applicability conditions and exceptions need to be confirmed, before being reflected in design.

Which country/region this organization operates in, and what laws, regulations, or contracts it is subject to, are not given as a premise of this case. We do not assume that a specific law or regulation applies to this organization. If this organization is subject to some legal retention/deletion obligation, confirming the seven items covered in Chapter 18 is the starting point. No more concrete conclusion than that can be reached from this case's premises alone.

How to Verify This Design

So far, we have considered this fictional organization's case from various perspectives. However, what has been organized here is, at most, an organization of design-level thinking — whether it actually works is a separate question.

As we saw in Chapter 16, a written Plan, or a single past success, does not by itself prove actual Recovery capability. In this book, we organized this confirmation flow as the cycle Plan → Test / Exercise → Gap → Improve Plan / Dependency / Procedure → Retest. This cycle is this book's own organization, not a standard cycle defined by NIST or CISA.

For this organization's design as well, what has been organized here needs to actually be verified through Test and Exercise, with any Gap found being reflected in improvements to the Plan, Dependency, and Procedure. This chapter does not go as far as designing the concrete Test/Exercise itself.

Summary

This chapter brought together the ideas organized from Chapter 1 through Chapter 18, applying them to the case of a single fictional organization.

The important points are these:

• This case is fictional. It is not a validation of a real organization, a reference architecture, a product selection, or legal advice.
• Multiple tensions exist, including Business Priority, Retention/Immutability/Privacy/Contract, the trustworthiness of a Recovery Point, privileged administration, the actual usability of Backup, Restore success versus Business Recovery, and preparing for the normal administrative path being unusable.
• Each of these tensions can be examined by applying the ideas from its related chapter, but this chapter does not uniformly decide which one takes priority, or exactly how it plays out.
• The suitability of a Recovery Copy is evaluated across multiple dimensions — location, network reachability, identity, administrative authority, authorization, storage, cryptographic dependencies, retention, and actual restore accessibility — as this book's own organization.
• This organization's actual dependencies, RTO/RPO, retention periods, applicable law, whether a bootstrap path exists, and whether Recovery would actually function, cannot be known from this case's premises alone, and are left as UNKNOWN.
• Remaining UNKNOWN is not a failure for this chapter — it is the intended outcome.

Questions to Consider After Reading the Whole Book

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

1. When Business Priority and the actually executable Technical Recovery Order differ, how should you think about it?
2. When Retention or Immutability could conflict with a deletion request, what do you need to confirm first?
3. Why does the suitability of a Recovery Copy need to be evaluated across multiple dimensions, such as location, identity, and cryptographic dependencies?
4. Why does how to begin Recovery from a state where the normal administrative path is unusable need to be thought through in advance?
5. Why is a separate mechanism needed to confirm whether the design organized in this chapter actually works?

As we have confirmed repeatedly throughout this book, you must not replace "not knowing" with "having figured out." Keeping what should remain unknown clearly unknown is also part of Recovery design.