Most backup security reviews die in the planning stage. Someone proposes a control framework, the mapping exercise takes three weeks, and nothing is ever tested. A small IT team has a better option. A handful of deliberate attempts against the live backup system, each with a predicted outcome written down first, reveals more about survivability than any questionnaire, and three people can finish that work in a day.
The distinction that matters is between a review that reads configuration and one that attempts actions. Reading configuration confirms a setting has the value someone intended. Attempting an action confirms what the system does when a credential that already exists inside the environment is used against it. Those answers diverge more often than teams expect, usually because a permission was granted somewhere other than the screen being read.
The attacker being modeled is not an outsider at the perimeter. It is someone operating with credentials the environment already trusts, most often the backup service account, since that account has a documented reason to talk to the backup storage. The question the day answers is narrow. If that account is taken, what can it destroy, and does anyone find out.
Start in the backup software, where retention is usually managed. Edit a job so it keeps seven restore points instead of thirty, and apply the change. The expected result is that the edit succeeds, because retention there is job policy and the software is built to let an administrator change it.
The second half of the attempt is the one that matters. Check whether the restore points already written to object storage lost their protection when that policy changed. They should not have. An object level retention date is stamped at write time and lives with the object version, not with the job that produced it. Shortening a job policy may mark older points obsolete in the software database while the underlying object versions stay locked until their own dates pass.
Then attempt the change at the storage layer with the credential the backup software holds. Try to reduce the default retention on the bucket, then try to set an earlier retain until date on a locked object version. Under compliance mode the second attempt should fail for every identity on the system, including the account that created the bucket. Under governance mode it should fail unless the identity holds an explicit permission to lift governance retention and sends the matching request header. This is where an assumption about what Object Lock actually guarantees becomes an observed result.
Pull the access key from the backup repository configuration, not from an administrator's password manager. The point is to use the identity the backup server holds continuously, since that is the identity an attacker inherits when the backup server falls.
Issue a delete against a specific object version under retention. The expected result is an access denied response. Then delete the same object without naming a version. On a versioned bucket that usually returns success, because it creates a delete marker rather than removing anything. A team reading only the return code will record a destroyed object where none exists, so the difference is worth seeing once with real output.
Four more attempts complete the picture. A bulk delete of several versions, a delete of the bucket, a request to suspend versioning, and a lifecycle rule with a short expiration. All four should be refused, since none is required to write and read backups. If any succeeds, the finding is not about the storage system but about the scope of that service account.
| Attempt | Expected result | What a different result means |
|---|---|---|
| Shorten retention on an existing job | Succeeds, locked versions unaffected | Retention is enforced by the software, not the storage |
| Set an earlier retain until date | Denied | Governance mode plus retention lifting rights on the account |
| Delete a locked object version | Access denied | Retention never applied to that write path |
| Suspend versioning or add a lifecycle rule | Denied | The account holds bucket administration rights |
| Open the storage port from a user subnet | Refused or timed out | The endpoint is as reachable as the user estate |
| Generate a denied delete and wait | A person is notified within minutes | The event is logged but nobody is watching |
This check has two halves and both are quick. The identity half is a list of every access key and console login on the storage system, with the date each was last used. Keys nobody recognizes and keys unused for months are the interesting entries, since a key issued for a migration two years ago is still a working credential.
The network half is a connection attempt from three places. An ordinary workstation subnet, the hypervisor management network, and the jump host administrators are supposed to use. A refused connection or a timeout from the first is the expected result. If a laptop on the user network can open the storage port, the storage system is defended by credentials alone, and every phishing email in the organization is a storage risk.
One question closes the section. If the storage system's administrative login authenticates against the directory production uses, a directory compromise is a storage compromise, and that belongs in the findings as a single point of failure.
The attempts above generate exactly the events a monitoring configuration is supposed to catch. Denied deletes, refused retention changes, failed authentication from an unusual source. Rather than reading the alerting rules, use the events already created and watch what happens.
Three outcomes are possible. A notification arrives on a channel someone reads, the event lands in a log nobody opens, or nothing is recorded at all. Only the first counts, and the test is whether a named person can say when the message reached them.
The delivery path deserves one more question. If the notification depends on production mail, and mail is part of what an attacker disables first, the alert works only in conditions where it is least needed. An out of band path is what makes the signal survive the scenario it was built for, and choosing which events justify that is separate from deciding which alerts matter day to day.
ARTESCA is object storage software used as a backup target, with immutable backup storage through S3 Object Lock and an S3 compatible API, deployed on infrastructure the customer runs. Every attempt described here is made against that API with ordinary client tooling, so the tests need no vendor specific utilities.
Because the deployment sits on the customer's own hardware and network, the boundary questions in this review stay under local control. Which subnets can open the endpoint, which directory the administrative login trusts, and where the keys live are decisions made on site rather than properties of a hosted service.
ARTESCA is commonly deployed alongside Veeam and sold through resellers, so account scoping and bucket configuration are often set once during installation and rarely revisited. That is why an attempt based review earns the day it takes, since the configuration that shipped with the deployment is usually the one still in force years later.
Write the attempts down as a short table with three columns, the action, the predicted result, and the observed result. The predicted column turns the exercise into a test, since filling it in beforehand forces the team to state what it believes. A gap between prediction and observation is the finding, more than the raw outcome is.
Repeat the sequence twice a year and after any change to the backup software, the storage configuration or the account structure. Those changes quietly reintroduce permissions, usually because a support case or an upgrade asked for a broader credential temporarily and nobody narrowed it afterward.
Record the credential used for each attempt, since a result is meaningless without one, along with the versions of the backup software and the storage platform. Pair the file with a written statement of what survives a compromised backup server, and the review stops being an annual document and becomes the thing that keeps that statement true.