Chapter 10 — Ransomware and Privileged / Insider Risk

10.1 Backup Itself Becomes an Attack Target

In Chapter 9, we saw that administrative authority itself is also something that needs protection. This chapter considers how far Recovery capability can be affected if that privileged authority is abused or compromised.

The first point to hold onto is this:

In a destructive ransomware incident, the Backup infrastructure and any accessible Backup data can themselves become attack targets.

Backup is a mechanism for recovery, but that does not mean it falls outside the scope of attack. Attackers may try to impair or disable Recovery capability itself. Backup data that is in an accessible state, and the infrastructure that supports it, can be targeted.

This chapter does not cover the concrete techniques of an attack or the technical mechanics of malware. What matters here is the perspective that, rather than "we're fine because we have Backup," "Backup itself is also something that needs to be protected."

10.2 The Impact of Privileged Authority

What carries particularly great significance for Backup / Recovery capability is privileged authority.

Whether privileged authority is abused or compromised, it can have a major impact on Backup / Recovery capability.

There is a point to note here. Within the range of evidence that could be confirmed for this book, no description was found that rigorously distinguishes "a malicious insider," "a compromised privileged account," and "an unintended operational mistake" from one another. This chapter therefore does not finely classify these, and instead treats them broadly as "privileged authority becoming, for some reason, a dangerous path for Backup/Recovery."

This also does not mean "every administrator is a threat." In most cases, administrators exercise their authority legitimately. What we want to consider here is the perspective of how much impact could result if that privileged path were, in fact, abused or compromised.

10.3 Adding Additional Authorization for Destructive Operations

There is risk in a state where a critical operation can be completed through a single privileged path alone.

You can add authorization for destructive operations, such as deleting or destroying a Backup, so that they cannot be completed by one person's authority alone.

Ideas for achieving this include the following:

• Separation of Duties: the idea of not concentrating the authority to complete a destructive operation in a single role, a single person, or a single path.
• Dual Authorization: the idea of requiring approval from multiple authorizing parties for a single critical operation.

There is a concept here that is easily confused with Dual Authorization.

MFA (multi-factor authentication) is an authentication enhancement to confirm that a single user is who they claim to be. Dual Authorization is the idea of requiring multiple authorizing parties for a single critical operation. The two are different things. Configuring MFA does not, by itself, create an independent multi-person approval mechanism.

The security controls catalog published by NIST (the National Institute of Standards and Technology) directly presents a control that requires Dual Authorization for the deletion or destruction of Backup information the organization has designated.

For example, in Azure, Multi-user authorization (MUA), which uses the Resource Guard mechanism touched on in Chapter 7, can be configured to require additional approval for critical operations. AWS Backup's multi-party approval, touched on in Chapter 9, is also an implementation example corresponding to this idea. These are only bounded implementation examples for specific products, and the implementation details differ by product.

10.4 Additional Approval Also Has Its Limits

Separation of Duties and Dual Authorization are useful, but they are not a cure-all.

Separation of Duties and Dual Authorization help reduce the situation where a single privileged party alone can complete a destructive operation. However, they do not necessarily fully prevent a case where every one of the required authorizing parties is compromised, or where they collude with one another.

In other words, increasing the number of approvers is an effective means of reducing risk, but it is not, by itself, an absolute guarantee. This book does not treat collusion itself in detail as an independent threat, but it is important to hold onto the point that it is not correct to think "insider risk is completely solved if there is multi-person approval."

10.5 Protecting the Audit Trail Itself

To confirm whether a destructive operation was carried out, and who did what, an audit trail becomes important.

Audit information and audit tools themselves also need to be protected from unauthorized access, tampering, and deletion.

What we want to note here is not to simply reduce this protection to a single label such as "immutable audit." Protecting an audit trail has several distinct aspects. Who can access it, who can change its contents, and who can delete it are each matters that need to be confirmed separately.

The detailed design of exactly which events should be logged, or how logs should be stored and analyzed, is not covered in this chapter.

10.6 Personnel and Account Lifecycle Also Matter

Technical protection alone cannot address every risk related to privileged access.

For example, if a person's access authority or account is not properly revoked when they transfer to a different role or leave the organization, that in itself becomes a risk.

Account management tied to personnel transfers and departures is a separate control that addresses risks that Backup immutability or multi-person approval alone cannot handle.

The relationship described here between this kind of personnel control and Backup's technical protections (immutability, Dual Authorization) is this book's own organization, not presented as a single official classification. The organizational framework of personnel security itself is not covered in this chapter.

10.7 Emergency Access Also Carries Its Own Risk

Finally, there is one more situation worth considering.

You also need to plan for the case where the normal administrative path becomes unusable. For example, if the identity mechanism itself experiences a failure, or becomes untrustworthy, the administrative path normally used may itself become unavailable.

Preparing an out-of-band path — one different from the normal path — or a dedicated emergency Recovery Access, for situations like this can help maintain recoverability.

However, caution is needed here. Because this Emergency Access itself is a mechanism holding powerful privilege, it requires its own bounded lifecycle management and independent control. It should not be left unguarded simply because it is not normally used.

The design of concretely how to begin Recovery from a state where normal identity cannot be used is not covered in this chapter. This point is covered again in a later chapter.

10.8 Summary

This chapter organized how destructive intrusions such as Ransomware, and the abuse or compromise of privileged authority, can threaten Backup / Recovery capability itself.

The important points are these:

• The Backup infrastructure and any accessible Backup data can themselves become targets of a destructive incident.
• Privileged authority, whether abused or compromised, can have a major impact on Backup / Recovery capability.
• Separation of Duties and Dual Authorization can create a mechanism where a destructive operation cannot be completed through a single path alone. MFA and Dual Authorization are distinct concepts.
• Separation of Duties / Dual Authorization also do not necessarily fully prevent the compromise or collusion of every authorizing party involved.
• The audit trail itself also needs to be protected from multiple aspects, not reduced to a single label.
• Personnel and account lifecycle management address risks that technical protection alone cannot handle.
• Emergency Access helps recoverability, while itself being a powerful privilege that requires its own independent control.

Representative Perspectives 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 perspectives covered in this chapter, not a fixed classification defined by an industry standard.

In the next chapter, we look at how to judge whether a Backup that could be Restored is actually a trustworthy recovery point.

Questions to Consider After Reading Chapter 10

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

• Why can Backup itself become a target of Ransomware or a destructive intrusion?
• Can you explain the difference between MFA and Dual Authorization?
• Why can Separation of Duties or Dual Authorization alone not completely solve insider risk?
• Why does the audit trail itself also need to be an object of protection?
• Why does Emergency Access, while helping Recovery, also require its own independent control?

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.