If backups can be reached with production administrator credentials, then what?

Start

Production administrator credentials can reach your backups

A backup is only as safe as the weakest sign-in that can reach it. Attackers look for the backups first. If a stolen production administrator account can delete or change them, the copies you rely on go with everything else. This flow checks the four things that stop that: separate identity, no network route, a copy nobody can change, and a lock that credentials alone cannot remove.

• Then: Is an attack under way, or has a backup been touched?

Decision

Is an attack under way, or has a backup been touched?

If a backup copy has been deleted, changed or reached by someone who should not have it, or an attack is under way, this is an incident, not a review finding. The incident manager decides what is protected and when jobs stop; the backup administrator carries it out. Answer yes if you cannot tell.

• Yes, or not known: Tell the incident manager at once; P09 protects the backups
• No, and nothing has been touched: Is backup admin on production accounts, or missing a second factor?

Outcome

Tell the incident manager at once; P09 protects the backups

Under the incident plan the backups are protected first: confirm one copy is offline or immutable and out of reach, disconnect the backup system from the affected network and the shared sign-in directory, change the console credentials from a clean device and turn on any second approval for deletion. The incident manager decides; this flow changes none of that. Until the incident closes, treat any backup the attacker might have reached as unverified.

Decision

Is backup admin on production accounts, or missing a second factor?

Look at who can sign in to the backup system, its storage and its consoles. Backup administration needs its own named accounts, held outside the production sign-in directory, used only for backup work and protected by multi-factor authentication. No one should hold both production domain administrator rights and the right to delete an immutable copy or shorten its retention. Answer yes if any backup account sits in the production directory, if a console has no second factor, or if you have not checked.

• Yes, or not known: Move backup admin to separate named accounts with a second factor
• No, separate accounts with a second factor: Can user or server networks reach the backup storage?

Step

Move backup admin to separate named accounts with a second factor

Create named backup administrator accounts that are not in the production directory, switch on multi-factor authentication for the backup system and its storage consoles, and remove backup rights from production administrator accounts. Split the roles so that no one holds both domain administrator rights and the right to delete an immutable copy. Where a supplier runs a console, ask for the setting in writing.

• Then: Can user or server networks reach the backup storage?

Decision

Can user or server networks reach the backup storage?

Ransomware spreads across every network it can reach, and a volume mounted on a production system looks like a local disk to it. Read the firewall rules, then try to reach the storage and its management systems from a user device and from a production server. Both attempts must fail. A route that works, a mounted or mapped backup volume, or a test you have not run all mean yes.

• Yes, or not known: Close the routes and keep the failed test connections as evidence
• No, they cannot reach it: Does each critical data set have a copy that is immutable or offline?

Step

Close the routes and keep the failed test connections as evidence

Cut the backup storage and its management systems off from user and server networks, and unmount any backup storage from production systems. An offline copy is connected only while it is written or restored, and each connection is recorded. Repeat the test from a user device and a production server and keep the failed attempts.

• Then: Does each critical data set have a copy that is immutable or offline?

Decision

Does each critical data set have a copy that is immutable or offline?

The pack's rule of thumb is three copies counting the live data, on two kinds of storage, one offsite and one immutable or offline. It is a practice used in industry, not a legal requirement. The immutable or offline copy is the one that survives an attacker holding administrator credentials. A second copy in the same cloud account, reachable with the same credentials, does not count.

• No, or not known: Add an immutable or offline copy for each data set that lacks one
• Yes, each has one: Can administrator credentials alone remove the lock or the copy?

Step

Add an immutable or offline copy for each data set that lacks one

Start with the critical data sets, listed in your coverage matrix. Add a copy that neither production administrator credentials nor the everyday credentials of the backup administrators can change or delete: an online copy under a retention lock, or an offline copy. Record it in the matrix and check the copies rule again.

• Then: Can administrator credentials alone remove the lock or the copy?

Decision

Can administrator credentials alone remove the lock or the copy?

A copy is immutable only if it carries a retention lock for its full retention period and removing or shortening that lock needs two named people and a recorded reason. A lock that administrator credentials alone can remove does not make a copy immutable. Prove it on a test set: try the action with one account and confirm it is refused. Answer yes if the lock is shorter than the retention or you have not tried it.

• Yes, or not known: Lock for the full retention; two named people to change it
• No, it needs two people and holds: Was any control above unmet or not checked?

Step

Lock for the full retention; two named people to change it

Set the retention lock for each immutable copy to its full retention period from the coverage matrix. Make shortening or removing it, or deleting a backup set, need two named people and a recorded reason. Add an alert to someone outside backup administration when a set is deleted, retention changes or the backup administrators change.

• Then: Was any control above unmet or not checked?

Decision

Was any control above unmet or not checked?

Count the controls from the checks above that were not met, or that you could not check yourself. An unchecked protection is an unproven one, so it counts. If a supplier runs a console and has not shown you the setting, answer yes.

• Yes, or not known: Raise a finding for each control that was not met or not checked
• No, all met and checked: Prove it by restoring from the protected copy; review yearly

Step

Raise a finding for each control that was not met or not checked

Each unmet or unchecked protection control is a finding with an owner, a severity and a due date. In the pack's default the owner agrees a plan within 10 working days and a High finding is fixed within 90 days. The checklist rates the multi-factor control, the two-person lock, network reach, the offline connection record and the immutable copy as High if not met, and the owner sets the severity. A High finding is told to the owner of the risk it bears on, and the risk is reassessed. Your own standard may change the days.

• Then: Prove it by restoring from the protected copy; review yearly

Outcome

Prove it by restoring from the protected copy; review yearly

A copy you have not restored is unverified. At the next restore test, alternate to the immutable or offline copy and restore it into an isolated place, never onto production. Review the protection checklist once a year and after any change to the backup system or its supplier, by a reviewer who cannot change that system. Report counts of controls met, not met and not checked, never a score.