Using CyberSense? Validate Recovery Data Before It Reaches the Vault

CyberSense inspects content inside the vault. If you use Dell PowerProtect Cyber Recovery, this is the inspection control you have. By the time it runs, the data has already crossed the immutable boundary. If the data was already compromised at the moment of write, the vault preserves that compromise exactly. Immutable storage is faithful to whatever you give it, including ransomware.

Two limitations follow from that architecture. The first is timing: by the time the vault flags a problem, the corrupted copy is already inside the immutable boundary. The second is scope: CyberSense in the cloud is the on-prem appliance lifted into a virtual machine. Dell ships it as a CyberSense AMI co-located with the management host and the DDVE appliance. DDVE is Dell's Data Domain Virtual Edition, the virtual deduplication storage where supported backup vault data is written. Its inspection scope is the data inside that DDVE instance, which are backup images from Veritas NetBackup, Commvault, IBM Storage Protect, and the Dell backup products, Avamar, Networker, and PPDM, and nothing else. AWS Backup, EBS and RDS snapshots, S3 object versions, cross-region replicas, Azure managed snapshots, Azure Backup, and third-party cloud backup services all sit outside that scope.

The recovery path now starts long before data reaches the vault, and it extends into infrastructure CyberSense was not built to see.

Key Takeaways

• CyberSense inspects data after it is already inside the immutable vault. The compromised copy is across the boundary before anyone sees a verdict.
• CyberSense in the cloud is a Dell-provided virtual appliance (AMI co-located with DDVE and the Cyber Recovery management host). It inspects only data inside that DDVE instance, not cloud-native recovery data sources such as AWS Backup, EBS or RDS snapshots, S3 object versions, cross-region replicas, Azure managed snapshots, or Azure Backup.
• Elastio inspects at first write, produces a named ransomware verdict the SOC can act on without interpretation, and covers AWS and Azure natively plus on-prem data via Veeam, Commvault, Rubrik, Cohesity, and Veritas.
• Your CyberSense deployment stays in place. Elastio runs in front of the vault and across the cloud-native data sources CyberSense does not reach.

How CyberSense and Elastio Compare

Both products inspect content inside backup and recovery data, but they do not see the same surface. CyberSense's reach is bounded by what is inside DDVE and a small set of on-prem backup storage arrays, on-prem and in the cloud. It does not see inside S3, EBS, EC2, Azure storage, or cloud-native backup services. Elastio inspects across production, snapshots, replicas, object storage, and modern backup platforms in AWS, Azure, and on-prem. Where the surfaces do overlap, the products also differ on where in the pipeline inspection happens, what the output tells the SOC, and what it costs to operate.

Backup status answers a narrow question: did the copy complete?

Recovery integrity answers the question that matters during an incident: can we restore from this copy without reintroducing the attacker?

A recovery point can be present, immutable, replicated, and still unsafe. If ransomware or destructive encryption was already present when the copy was created, the recovery process brings the attacker back into production. Isolation preserves the compromised state. It does not undo the compromise.

Inspection Happens After the Immutable Boundary

CyberSense runs against the vault copy. The data has already crossed the immutable boundary before CyberSense touches it. Detection is late by architecture. The corrupted copy is already inside the vault when the verdict arrives.

Ransomware does not wait until data reaches a cyber recovery vault. It affects production workloads, file systems, databases, snapshots, replicas, cloud storage, and backup repositories before the protected copy is created or promoted. By the time the vault copy exists, the compromised state is preserved exactly as it was written.

Elastio runs on the primary backup copy at first write. Inspection happens earlier than CyberSense can run, and suspect copies are identified before they are promoted into the protected recovery set.

In the Cloud, CyberSense Sees Only DDVE

CyberSense runs on the on-prem Dell PowerProtect Cyber Recovery vault and, in the cloud, as a Dell-provided virtual appliance (AMI) deployed in the same private subnet as the Cyber Recovery management host and DDVE. It is not a managed cloud service. Customers operate the AMI, the DDVE instance, and the Cyber Recovery management host themselves, and the AMI itself runs on large EC2 shapes such as r5b.8xlarge or i3en.12xlarge.

The scope of that inspection is the data inside the DDVE instance. Everything else in the cloud half of the estate is out of scope: AWS Backup, EBS and RDS snapshots, S3 object versions, cross-region replicas, Azure managed snapshots, Azure Backup, and third-party cloud backup services. Backup data written by Rubrik, Cohesity, and Veeam is also not supported by CyberSense, on-prem or in the cloud.

Most enterprise estates are no longer single-site. Workloads run in AWS and Azure. Recovery data lives in cloud snapshots, object storage, cloud backup services, and cross-region replicas. If a clean recovery decision has to span the whole environment, and one of the largest data surfaces in that environment is not inside a DDVE appliance, it is not in CyberSense's inspection scope.

Regulators have started writing recovery integrity into the rules. The EU Digital Operational Resilience Act requires financial entities to perform checks during recovery to ensure the highest level of data integrity is maintained, and to restore from systems that are physically and logically segregated from the source (DORA, Article 12). DORA is technology-neutral and applies to all ICT supporting critical or important functions, including cloud-resident systems. Inspection coverage that ends at the boundary of one virtual appliance leaves the cloud half of that obligation unanswered.

Elastio inspects data in AWS and Azure natively, and on-prem data through API integrations with Veeam, Commvault, Rubrik, Cohesity, and Veritas. The cloud half of the estate gets the same verdict the data center gets.

What CyberSense Leaves on the Table

Your CyberSense deployment stays in place. Elastio covers the data sources and pipeline stages CyberSense was not built to handle.

1. Cloud Parity

CyberSense only inspects a specific set of on-prem workloads, and that scope is mirrored to the cloud. Running it in AWS is the same on-prem appliance lifted into a Dell-provided AMI bolted to DDVE. It scans the same datasets it scans in the data center and adds no coverage for cloud-native workloads. AWS Backup, EBS and RDS snapshots, S3 object versions, cross-region replicas, Azure managed snapshots, Azure Backup, and third-party cloud backup services remain out of scope. Elastio inspects the same way in AWS, Azure, and on-prem. If a workload can be restored from the cloud, you should be able to prove that the recovery point is clean.

2. Inspection Before the Vault Boundary

CyberSense inspects after data is inside the immutable vault. Elastio inspects earlier, before promotion into the protected recovery set. The vault stops being the place where you first learn there is a problem.

3. A Named Ransomware Verdict the SOC Can Act On

CyberSense outputs alerts, a post-attack forensic assessment of impacted servers and files, and a last-known-good recovery point derived from machine-learning analytics. The output is a statistical confidence signal rather than a deterministic, family-named verdict, and it does not identify the encryption pattern at the file level. Translating that signal into a recovery decision still lands on the SOC. Elastio produces a deterministic verdict that names the family, shows the encryption pattern, and sets the clean boundary, so the SOC does not have to interpret a probability score under incident pressure.

Anomaly and entropy-based detection also misses modern evasion. Ransomware variants like LockFile encrypt alternate 16-byte blocks so files look statistically similar to the original, and research has shown that intermittent encryption and entropy-sharing techniques systematically bypass entropy-threshold detectors. A deterministic, family-named verdict is harder for those techniques to defeat than a statistical anomaly score.

4. Native Integration With the Backup Stack

CyberSense parses backup-image content directly from storage for Dell Avamar, NetWorker, Commvault, NetBackup, and PowerProtect Data Manager rather than calling the backup vendor's API to retrieve files. Coverage is bounded by the formats Index Engines has built parsers for. New backup vendors, new format versions, and cloud-native backup services (AWS Backup, Azure Backup, third-party SaaS backup) are not covered until parsers are added. Scans on enterprise-scale vault data can run long enough that Dell maintains a dedicated knowledge-base article for CyberSense analyze jobs running longer than 24 hours, naming large VMDKs and high-file-count datasets as common causes. The implication for operations is that a same-day verdict on what is in the vault right now is not always available.

Elastio integrates through the backup vendor's API and inspects with a model ensemble that adds behavioral and temporal analysis on top of deterministic detection. The coverage split tracks where the market is moving: CyberSense's parser list is anchored to the legacy on-prem stack (Avamar, NetWorker, NetBackup, Commvault, PPDM), while Elastio covers the modern backup platforms enterprises are standardizing on (Veeam, Rubrik, Cohesity) along with cloud-native data sources.

5. Light Operational Footprint

CyberSense ships as a dedicated Linux host (CentOS, SUSE, or RHEL) with CyberSense installed, or a Dell-supplied virtual appliance (OVA), deployed at the same location as the Cyber Recovery vault. Customers operate that host themselves: provisioning, OS patching, CyberSense upgrades, and license management all sit with the customer. Elastio runs as cloud-native software in the customer's AWS or Azure account, with no appliance host to provision.

6. R-RPO for Clean Recovery Measurement

Traditional RPO measures how much data you might lose based on backup frequency. It does not tell you whether the latest backup is safe.

How This Works Alongside an Existing CyberSense Deployment

Elastio runs alongside the existing CyberSense deployment. It covers the data sources and stages CyberSense was not built for. In practice:

• Elastio inspects production, snapshot, replica, object-storage, and modern backup data in AWS, Azure, and on-prem. CyberSense stays on its own swim lane: backup images from the older backup products written into the Dell PowerProtect Cyber Recovery vault on-prem, or into DDVE when Dell's AWS deployment is in use.
• Elastio runs at first write, so suspect copies are flagged before they are promoted into the vault. CyberSense remains a last-line check on what is already inside the boundary.
• Elastio produces a named ransomware verdict the SOC can act on without interpretation. CyberSense anomaly output continues to feed the existing review workflow.
• Elastio identifies the Last Known Clean recovery point across the whole estate. The vault team gets a recovery target that is consistent with what the cloud team is seeing.

Questions to Ask if You Use CyberSense

These questions surface the gap using data already inside your environment:

• How long did the last full CyberSense scan take to complete on our largest vault dataset?
• How many CyberSense alerts in the past quarter turned out to be false positives, and how much SOC time went into tuning them down?
• In the last ransomware incident or red-team exercise, did CyberSense name the malware family and identify the clean boundary, or did the SOC have to reconstruct that itself?
• Which of our AWS, Azure, snapshot, replica, object-storage, or cloud-backup data have no CyberSense coverage today?
• Can we restore from the cloud half of our estate with the same level of clean-recovery evidence we have for the on-prem half?
• When the auditor asks about cyber-recovery coverage in the cloud, what is the answer?
• What is our R-RPO for the systems leadership cares about most, not our RPO?
• What is the all-in infrastructure cost of running CyberSense at our data volumes (high-core, high-memory hosts on-prem, the equivalent EC2 shapes in AWS, and additional servers as the dataset grows)?

If those answers are unsatisfying, the gap is real and the architecture needs to change.

When to Evaluate Elastio

Elastio is a strong fit when you are expanding beyond a vault-only recovery model.

Evaluate Elastio if you are:

• Moving workloads to AWS or Azure
• Adding cloud backup or cloud recovery workflows
• Using snapshots, replicas, or object storage as part of recovery
• Trying to validate recovery data before it reaches the vault
• Looking for a Last Known Clean signal across hybrid data surfaces
• Asked by leadership to prove recoverability, not just backup completion
• Trying to connect security findings to restore decisions

The most useful evaluation uses your own recovery data. Run Elastio against the data surfaces that feed, surround, or sit outside your CyberSense workflow. Identify where clean recovery evidence already exists, where it is assumed, and where it is missing.

That exercise gives recovery teams a clearer map of where trust is earned and where it is only inherited.

Clean Recovery Needs More Than One Checkpoint

Cyber recovery has moved beyond the question of whether backups exist. The more useful question is whether recovery data can be trusted at the moment the business needs it.

CyberSense helps answer that question inside the recovery workflow. Elastio extends the answer across the broader recovery path.

For hybrid and cloud-transition customers, that distinction matters. The data estate is no longer confined to one place. Recovery validation should not be confined to one checkpoint.

Use CyberSense where it already strengthens your vault-centered recovery process. Add Elastio where recovery risk starts earlier, moves through cloud and hybrid infrastructure, and needs clean-copy evidence before an incident forces the decision.

Sources

[1] Dell, PowerProtect Cyber Recovery 19.15 AWS Deployment Guide, Architecture overview

[2] Dell, PowerProtect Cyber Recovery 19.15 AWS Deployment Guide, Deploying CyberSense using the CyberSense AMI

[3] European Union, Regulation (EU) 2022/2554 (Digital Operational Resilience Act), Article 12

[4] Index Engines, CyberSense product page

[5] Elastio, Elastio Platform overview

[6] Bang J., Kim J. N., Lee S., Entropy Sharing in Ransomware: Bypassing Entropy-Based Detection of Cryptographic Operations, Sensors (MDPI) 24(5):1446, 2024

[7] Index Engines, CyberSense for Dell Technologies product details

[8] Dell, Knowledge Base 000185297, Cyber-Sense Analyze performance issues and jobs running longer than 24 hours

[9] Dell, PowerProtect Cyber Recovery 19.15 Installation Guide, Index Engines CyberSense