Resources

Insights, events, and proof from the field

Latest blogs, whitepapers, webinars, in-person events, podcast episodes, and customer case studies — all in one place.

Blog

Latest posts

Thought leadership, product updates, and technical deep dives from the Elastio team.

View all posts
Using CyberSense? Validate Recovery Data Before It Reaches the Vault

May 26, 2026

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. The Elastio Answer Elastio inspects recovery data at first write, the moment the primary backup copy is created, before the vault boundary, and across the cloud and hybrid environments CyberSense cannot reach. 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. Recovery Data Source CyberSense Elastio DDVE vault contents ✔ ✔ Production workloads, databases, filesystems ✘ ✔ First-write backups (Veeam, Commvault, Rubrik, Cohesity, Veritas) ✘ ✔ AWS Backup, EBS and RDS snapshots, S3 object versions ✘ ✔ Azure Backup, Azure managed snapshots ✘ ✔ Cross-region replicas, third-party SaaS backup ✘ ✔ A backup is only useful if you know whether it was already infected when it was written. 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 R-RPO Works Elastio uses Resilience RPO, or R-RPO, which measures the gap between now and the last proven clean recovery point . A company can have frequent backups and a poor clean-recovery position if ransomware went undetected for days. The backup schedule looks healthy. The usable restore point is much older than expected. R-RPO shifts the executive conversation from how often we back up to how recently we can prove a clean restore point exists. 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. The vault stays in place. The inspection layer expands to match the data estate. 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. Book a Recovery Assessment Find the recovery points you can actually trust. Request an Assessment 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

Read post

May 6, 2026

To What Extent Do Cybersecurity Breaches Impact the Stock Prices of Public Corporations?

Introduction Imagine waking up to headlines that your bank, retailer, or airline has suffered a major cyberattack—and within hours, billions vanish from its market value. A breach like this can tarnish years of carefully built reputation and undermine trust in an instant. Trust is the currency of the corporate world: it seals business alliances, sustains trade deals, and underpins every transaction between buyer and seller. In today's digital economy, a single breach can shake investors' confidence as much as a poor earnings report—or worse. During my EPQ research, I discovered that the real question is not if cyberattacks impact share prices—they do—but how much . Some companies see only a short-lived dip. Others spiral into prolonged decline. The difference lies not simply in the attack itself, but in the quality of the response. What Really Drives the Impact? The first casualty of a cyber breach is often trust . Investors immediately ask: Will customers still believe in this company's ability to deliver? Economist John Maynard Keynes described this as “animal spirits” —the instincts and emotions that drive economic behaviour. Fear spreads faster than facts, and share prices can fall sharply before the full scale of a breach is even understood. This is why corporate response matters. A rapid, transparent reaction shapes market sentiment and stabilises equity prices. Delays or silence, on the other hand, magnify uncertainty and deepen losses. From my project, three main factors stood out: Nature of the breach A ransomware lockout, a supply chain attack, or a large-scale data theft each carry different weight. Corporate response Did leaders act quickly, communicate openly, and prove they could prevent recurrence? Or did they leave space for rumours and speculation? Regulation and legal fallout Fines, lawsuits, and compliance costs can stretch the financial impact far beyond the initial panic. These elements explain why some breaches trigger only minor dips, while others unleash full-scale crashes. Breaches That Shook the Market Yahoo (2013 & 2014) 3 billion accounts compromised. Aftermath: $117.5M settlement, $35M in fines, and stock declines of 6.1% and 3.1% after disclosure. Capital One (2019) 106 million records exposed. Shares plunged nearly 14% in two weeks as investors questioned confidence in the brand. Maersk (2017) Supply-chain malware paralysed global shipping operations. Swift action limited losses to $300M, and shares rebounded 5% within a month—unlike Equifax, where sluggish disclosure drove a 30% six-month slide. Retail Breaches (2025) UK retail firms saw data compromises wipe out up to 3% of stock value in days. Heightened EU data protection scrutiny magnified investor anxiety, proving patterns identified years ago still persist. These cases underscore how response quality dictates the extent —from minor 3% dips to devastating 30% slides. Crises don't just test systems; they test leadership and accountability. In the long run, they test progress. The Future: Defence and Doubt Technology is reshaping the battleground. AI-driven cybersecurity now monitors behaviour patterns and detects anomalies in real time. This containment limits breaches before they spiral into market shocks. Far from replacing jobs, AI automates repetitive tasks so human specialists can tackle bigger threats. But AI is also a double-edged sword Criminals deploy it for targeted ransomware, data exfiltration, and reputational extortion schemes that go far beyond simple pay-to-decrypt attacks. Blockchain provides another defence line. By decentralising identity systems and creating tamper-proof records, it reduces fraud and unauthorised access. Early programmes show blockchain adoption can cut recovery costs by up to 30%—sometimes the difference between rebounding and prolonged decline. Together, these technologies could shrink the market impact of breaches from catastrophic 14% plunges to manageable 3–6% dips—if companies adopt them wisely. Conclusion Cybersecurity breaches are no longer side stories. They are front-page financial events . The scale of damage depends less on the attack itself and more on how companies handle the aftermath. Firms that respond well typically face share price drops of only 3–6%. Poor responses can trigger losses of 30% or more, eroding investor confidence for months. Companies with strong cyber insurance or proactive disclosures sometimes rebound within weeks—proof that preparation matters. The message is simple: cybersecurity is no longer just an IT issue—it's a shareholder issue. With global cybercrime costs projected to reach $10.5 trillion annually by 2025, no company can afford complacency. So the real question is: When—not if—the next breach comes, will your organisation's response reassure investors, or spark a sell-off?

Read post

Project Glasswing: What Zero-Day Discovery at Scale Means for Your Data

April 13, 2026

Project Glasswing: What Zero-Day Discovery at Scale Means for Your Data

What Anthropic Announced On April 7, 2026, Anthropic announced Project Glasswing , a restricted cybersecurity initiative built around Claude Mythos Preview, their most advanced AI model. The model is not publicly available. Access is restricted to a coalition of launch partners and roughly 40 organizations that build or maintain critical infrastructure software. The launch partners include AWS, Apple, Microsoft, Google, CrowdStrike, Palo Alto Networks, Cisco, Broadcom, JPMorganChase, and the Linux Foundation. Anthropic committed $100M in usage credits and $4M in direct donations to open-source security organizations. 1000s Zero-day vulnerabilities found 52+ Organizations with access $100M Usage credits committed Mythos Preview has already identified thousands of previously unknown zero-day vulnerabilities across every major operating system and every major web browser. In one case, a researcher using the model found a bug in OpenBSD that had been present for 27 years. The model chains multiple vulnerabilities together into exploits that no single flaw would enable on its own. Anthropic warned senior U.S. government officials that the model makes large-scale cyberattacks significantly more likely this year. According to reporting by Fortune and CNBC , Anthropic has privately communicated to officials that this class of model capability will proliferate beyond actors committed to deploying it safely. Why This Changes the Threat Landscape Glasswing is a signal that AI has shifted the economics of attack. Cheap models, open weights, and commodity compute mean adversaries can now generate novel malware variants, automate lateral movement, and compress dwell times from months to weeks. No signature database stays current against this velocity of change. AI has collapsed the cost of discovering and exploiting vulnerabilities. The zero-day supply is about to expand dramatically. Every product in the current enterprise security stack relies on one of two things: behavioral signals from a running system, or a known indicator such as a file hash or malware signature. AI-generated, zero-day attacks defeat both. There is no hash to match. There is no behavior pattern in any database. The attacker's tooling has never been seen before. Key Distinction Zero-days are vulnerabilities, not malware. A zero-day is a flaw in software that the developer does not know about. What follows a zero-day exploit is malware, lateral movement, data staging, and ransomware. Those post-exploitation artifacts land in the data layer. That is where the damage is done, and that is where detection must happen. The Gap No Security Stack Covers Enterprise security stacks protect the perimeter, endpoints, identity, and network. None of them inspect the data itself. This is not a configuration problem. It is a structural gap in the architecture of enterprise security. Security Layer What It Inspects What It Misses Perimeter (Firewall, WAF) Inbound/outbound traffic Threats already inside Endpoint (EDR, XDR) Running processes on live servers Threats in snapshots and backups Identity (IAM, PAM) Access and privilege Malware in data at rest Network (NDR, SIEM) Traffic patterns and logs Ransomware in the data layer Backup (Rubrik, Veeam, Cohesity) Known malware hashes in own backups Zero-days. Data they do not manage. Data Layer (Elastio) Every file across live, replicated, and backup data -- The attacker exploits a zero-day to get in. Once inside, they deploy ransomware, stage data for exfiltration, and encrypt files. Every one of those post-exploitation actions writes artifacts into the data layer. EDR does not see them there. SIEM does not log them. Backup vendors copy the data without verifying whether it is clean. If your security stack does not inspect the data itself, how do you know whether your backups are already compromised? How Elastio Addresses This Gap Elastio performs Deep File Inspection across live data, replicated data, and backup data. It inspects the actual content of every file in the data layer to find ransomware and malware that has already landed. It does not rely on signatures, known hashes, or behavioral inference. Inspects the data, not the perimeter Elastio hunts inside the data layer where ransomware persists and where recovery is determined. No other security control reaches this surface. Finds zero-day ransomware Deep File Inspection does not need a known indicator. It examines file content directly. It finds threats that have never been cataloged. Works across any data surface Live data, replicated data, and backups. Any storage platform. Any backup vendor. One inspection engine across the full estate. Identifies the last clean recovery point When ransomware is found, Elastio traces backward to identify the last recovery point that is provably clean. No guessing. No manual inspection under incident pressure. How It Works Deep File Inspection examines the actual content of every file. It does not infer from entropy changes or statistical anomalies. One inspects. One infers. The detection accuracy profiles are fundamentally different. Why Glasswing Accelerates the Need for Data-Layer Inspection The Glasswing relevance is not about the vulnerabilities themselves. It is about volume. When AI compresses the cost of discovering and exploiting zero-days, more enterprises will be dealing with post-exploitation activity that their current stack does not inspect. Every security tool in the stack will continue to do its job at the perimeter, endpoint, and network layers. But the volume of novel threats reaching the data layer will increase. The question shifts from “Can we block the attack?” to “Can we find what it left behind and prove we can recover clean?” That is the question Elastio exists to answer. The Hunt Engine inspects the data layer today, across live data, replicated data, and backups. As the zero-day supply expands, every enterprise will need a security control that operates where the attacker's work ultimately lands: inside the data. The security stack protects the perimeter, endpoints, identity, and network. None of it inspects the data. That gap is about to be tested at a scale the industry has not dealt with before. Sources [1] Anthropic, Project Glasswing: Securing critical software for the AI era , April 7, 2026 [2] Fortune, Anthropic is giving some firms early access to Claude Mythos , April 7, 2026 [3] CNBC, Anthropic limits Mythos AI rollout over fears hackers could use model for cyberattacks , April 7, 2026 [4] CyberScoop, Tech giants launch AI-powered Project Glasswing , April 7, 2026 [5] Simon Willison, Anthropic's Project Glasswing , April 7, 2026 See How Elastio Detects This Find out whether your data layer is inspected and your recovery is provable. See the Hunt Engine

Read post

Elastio Delivers Zero-Day Ransomware Detection and Provable Recovery for IBM Cloud Object Storage

April 8, 2026

Elastio Delivers Zero-Day Ransomware Detection and Provable Recovery for IBM Cloud Object Storage

Which objects are compromised. Which are clean. Where recovery starts. Elastio answers all three. Summary Object storage is not built to inspect what is written to it. Ransomware and insider threats can exploit that gap deliberately, moving slowly over days or weeks to avoid detection thresholds. By the time an incident surfaces, the scope of compromise is often unknown and recovery cannot start. As enterprises face increasing threats, Elastio announced support for IBM Cloud Object Storage (IBM COS), designed to deliver ransomware detection and provable recovery for the object storage environments enterprises use for financial records, healthcare archives, and AI training data. What Elastio Delivers for IBM COS Elastio uses Deep Object Inspection to examine stored objects directly. When a threat is detected, four outcomes follow: Immediate threat context. Compromised objects are tagged with detection type, timestamp, and severity, surfaced in the Elastio portal and forwarded to your SIEM. Responders know the scope from the first alert. A provable recovery point. Elastio identifies the Last Known Clean (LNC) state by scanning backward through prior object versions. The recovery point is verified, timestamped, and auditable before the restore begins. Controlled recovery. Restores execute manually via console or automatically via policy, from the same platform that made the detection. Forensic isolation (upcoming). Compromised objects will be quarantined to a separate bucket outside the original permission boundary, enabling analysis without operational disruption. "IBM Cloud Object Storage holds the data enterprises rely on most. With Elastio, security teams can identify exactly which objects are clean, establish a verified recovery point, and restore with confidence." - Najaf Husain, CEO, Elastio Availability Elastio is available now as a tile in the IBM Cloud Catalog. No changes to storage architecture or application workflows are required. Contact ibm@elastio.com for a product briefing or proof-of-concept engagement. About Elastio Elastio delivers ransomware detection and provable recovery for cloud environments. Its platform inspects live data, replicated data, and backups for zero-day ransomware, insider threats, and malware, and identifies a verified recovery point before a restore begins. Elastio serves enterprise and regulated-industry customers who require security controls that extend into the data layer.

Read post

DORA: What CISOs Must Prove About Recovery in 2026

April 1, 2026

DORA: What CISOs Must Prove About Recovery in 2026

Summary The EU's Digital Operational Resilience Act (DORA) became enforceable on January 17, 2025. It requires all in-scope financial entities to test backup and recovery procedures under cyberattack scenarios at least yearly, prove data integrity on recovery, and submit results to regulators. The ECB's 2024 cyber resilience stress test of 109 banks found gaps in recovery capabilities. Penalty regimes vary by member state, with some jurisdictions imposing fines up to 2% of global annual turnover and personal liability for senior management. DORA applies extraterritorially to EU subsidiaries of global banks and to critical ICT providers regardless of domicile. Your Regulator Will Ask for Proof of Clean Recovery The EU's Digital Operational Resilience Act ( Regulation (EU) 2022/2554 ) became enforceable on January 17, 2025. It applies to banks, insurers, investment firms, payment providers, crypto-asset service providers, and 15 other categories of financial entities operating in the EU. It also applies to their critical ICT third-party service providers, regardless of where those providers are headquartered. This is not a future obligation. Enforcement is active. The European Supervisory Authorities (ESAs) have designated critical third-party ICT providers and regulators across member states are conducting oversight. In March 2025, the European Commission opened infringement procedures against 13 member states for failing to fully transpose the accompanying directive. For CISOs at global financial institutions, DORA creates a specific, testable obligation: prove that your recovery works. Not in a slide deck. In a documented test, under a cyberattack scenario, with results submitted to your regulator. If your board asks whether the organization is DORA-compliant, the answer depends on one question: can you prove that your backups are clean and your recovery procedures work under a cyberattack scenario? Articles 11 and 12 require exactly that. Why DORA is Different Financial services is not short on regulation. CISOs in this sector already manage obligations under NYDFS Part 500, PCI-DSS, NIST CSF, and a patchwork of national supervisory frameworks. DORA is different for three reasons. First, DORA is a regulation, not a directive. It applies directly in all 27 EU member states without requiring national transposition of its core requirements. This means uniform rules, uniform enforcement, and no ability for individual countries to weaken the standard. (The accompanying Directive 2022/2556 amends existing sectoral legislation to align with DORA, which is why some member states received infringement notices for transposition delays.) Second, DORA explicitly mandates cyberattack scenarios in resilience testing. Article 11(6) requires financial entities to test ICT business continuity plans at least yearly. For all entities other than microenterprises, those tests must include scenarios of cyberattacks and switchovers between the primary ICT infrastructure and the redundant capacity, backups, and redundant facilities. This is not guidance. It is a statutory requirement. Third, DORA creates personal accountability. The regulation makes an entity's management body responsible for ICT risk management. Board members, executive leaders, and senior managers must define risk management strategies, actively participate in executing them, and maintain current knowledge of the ICT risk landscape. Leaders can be held personally liable for compliance failures, with individual penalty ceilings varying considerably by member state . What Articles 11 and 12 Actually Require The recovery obligations in DORA are concentrated in Article 11 (Response and Recovery) and Article 12 (Backup Policies and Procedures, Restoration and Recovery Procedures and Methods) . These two articles define what financial entities must build, test, and document. Article 11: Response and Recovery ICT Business Continuity Policy Financial entities must implement a comprehensive ICT business continuity policy through dedicated, documented plans, procedures, and mechanisms. These must ensure continuity of critical functions and enable rapid response, containment, and recovery from ICT-related incidents. Annual Testing Under Cyberattack Scenarios Testing must occur at least yearly for ICT systems supporting all functions. For entities beyond microenterprise scale, testing plans must include cyberattack scenarios and switchovers between primary infrastructure and backup systems. Independent Internal Audit ICT response and recovery plans must be subject to independent internal audit review. Crisis Management Function Entities must maintain a crisis management function with documented procedures for managing internal and external communications during an activation event. Records and Reporting Entities must keep readily accessible records of activities before and during disruption events. Upon request, they must report estimated aggregated annual costs and losses from major ICT incidents to competent authorities. Article 12: Backup Policies and Recovery Methods Documented Backup Policies Entities must develop and document backup policies specifying data scope and minimum backup frequency based on criticality and confidentiality levels. Backup System Activation Backup systems must be activatable without compromising network security or data availability, authenticity, integrity, or confidentiality. Backup procedures and recovery methods must be tested periodically. Physical and Logical Segregation When restoring from backups, entities must use ICT systems that are physically and logically segregated from the source system and protected from unauthorized access or ICT corruption. Redundant ICT Capacity Non-microenterprise entities must maintain redundant ICT capacities with adequate resources. Central securities depositories face additional requirements under Article 12(5), including maintaining a secondary processing site at a distinct geographic location. Recovery Time and Recovery Point Objectives Entities must define RTO and RPO for each function, accounting for criticality and potential market impact. In extreme scenarios, agreed service levels must still be met. Data Integrity on Recovery When recovering from an ICT-related incident, entities must perform multiple checks and reconciliations to ensure the highest level of data integrity. This applies to internal data and to data reconstructed from external stakeholders. The Compliance Gap Most CISOs Face Article 12(7) requires that when recovering from an incident, financial entities perform checks to ensure the highest level of data integrity. Most backup and recovery tools can restore data. Few can prove that the restored data is clean. The regulation does not ask whether you can recover. It asks whether you can prove that what you recovered is not already compromised. This is the gap between backup infrastructure and data-layer security controls . The ECB Enforcement Signal The European Central Bank is not waiting for DORA violations to surface. It is actively stress-testing cyber resilience and feeding results into its supervisory process. In 2024, the ECB conducted its first-ever cyber resilience stress test , involving 109 banks under direct supervision. The test scenario assumed all preventive measures had failed and a cyberattack had severely affected core system databases. Banks had to demonstrate their response and recovery procedures. A subset of 28 banks underwent extended testing with actual IT recovery tests and on-site quality assurance reviews. The ECB's conclusion: banks have response and recovery frameworks in place, but areas for improvement remain. Results fed directly into the 2024 Supervisory Review and Evaluation Process (SREP), which assesses each bank's individual risk profile. This was not a one-time exercise. The ECB's supervisory priorities for 2025-2027 explicitly name cyber resilience and operational resilience as core focus areas. The 2026-2028 priorities go further: full DORA implementation is a stated requirement, including ICT governance, incident reporting, resilience testing, and third-party risk management. Targeted on-site inspections for cyber risk and ICT third-party provider risk are planned for the 2026-2028 cycle. In 2026, the ECB is also conducting its first-ever reverse stress test on geopolitical risk , requiring banks to define the scenarios under which prescribed failure outcomes would materialize. The results will inform the SREP and the 2026 internal capital adequacy assessment process (ICAAP). The Supervisory Loop The ECB is building a continuous cycle: stress test, SREP findings, targeted on-site inspections, follow-up. If your bank was among the 109 tested in 2024 and received individual feedback, that feedback is now a supervisory expectation. The 2026-2028 OSI campaigns will check whether gaps identified in earlier reviews have been remediated. DORA's Reach Beyond the EU DORA is an EU regulation, but its impact extends beyond EU borders. Two mechanisms create global exposure. EU subsidiaries of global financial groups are directly subject to DORA. A US-headquartered bank with EU-licensed subsidiaries must ensure those subsidiaries comply with DORA's full requirements, including backup testing under cyberattack scenarios, incident reporting to competent authorities, and maintenance of ICT third-party provider registers. Critical ICT third-party service providers serving EU financial entities are subject to the DORA oversight framework regardless of their domicile. The ESAs have the authority to designate critical third-party providers, conduct off-site investigations, perform on-site inspections, and levy fines of up to 1% of average daily worldwide turnover per day of non-compliance, for up to six months. For global institutions operating across both EU and US regulatory frameworks, DORA creates a floor that often exceeds existing US requirements. The FFIEC CAT has been sunsetted. NIST CSF 2.0 is broad and principles-based. DORA is prescriptive and specific, particularly on backup testing, recovery verification, and incident reporting timelines. This extraterritorial reach is why global banks with EU operations are treating DORA compliance as a 2026 priority. When your EU operations are subject to a regulation that mandates documented recovery testing under cyberattack scenarios with results reportable to supervisors, the compliance program necessarily extends into global infrastructure. Threat-Led Penetration Testing (TLPT) DORA's testing requirements operate at two levels. The first is the annual resilience testing that all in-scope entities must perform under Article 11 . The second is the more advanced Threat-Led Penetration Testing (TLPT) mandated by Articles 26 and 27 for systemically important entities. TLPT is a full-scale, intelligence-driven attack simulation conducted on live production systems. It must cover critical or important functions and must be performed at least every three years. The ESAs' Regulatory Technical Standards specify mandatory purple-team phases, a dual-vendor rule (separate threat intelligence and red team providers), and reporting requirements to competent authorities. For credit institutions classified as significant under the ECB's Single Supervisory Mechanism, external testers are mandatory for every TLPT. The testing framework aligns with TIBER-EU , which was updated in February 2025 to align with DORA's RTS. The connection to recovery is direct. If a TLPT reveals that a simulated cyberattack can compromise backup systems and the entity cannot demonstrate clean recovery, that finding goes to the regulator. It creates a documented supervisory expectation for remediation. The Penalty Framework DORA's penalty framework delegates specific amounts to member states, resulting in considerable divergence across EU jurisdictions . Article 50 requires penalties to be "effective, proportionate and dissuasive." The following reflects ranges reported across member state implementations. Entity Type Penalty Range (varies by member state) Source Financial entities Up to 2% of total annual worldwide turnover in some jurisdictions DORA Art. 50, national implementations Individual managers EUR 100,000 (Finland) to EUR 5 million (Germany) DLA Piper analysis Critical ICT third-party providers 1% of average daily worldwide turnover per day of non-compliance, up to 6 months DORA Art. 35(8) Penalties vary by member state. DLA Piper's analysis of national penalty regimes shows considerable divergence across EU jurisdictions. Some member states have adopted higher ceilings than DORA's minimum requirements. Article 52 also allows member states to impose criminal penalties for severe violations. Beyond fines, competent authorities can order cessation of infringing conduct, require public disclosure of breaches (creating reputational exposure), and limit or suspend business activities until compliance is achieved. The Recovery Question DORA Forces You to Answer Strip away the regulatory language and DORA asks one question of every CISO at an in-scope financial entity: If a cyberattack compromises your production systems today, can you prove that your backup data is clean, that your recovery procedures work, and that restored data maintains integrity? Can you document this in a way that satisfies your regulator? Article 12(2) requires periodic testing of backup procedures and recovery methods. Article 12(7) requires data integrity checks on recovery. Article 11(6) requires all of this to be tested under cyberattack scenarios. The ECB's 2024 stress test simulated exactly this scenario and found gaps in banks' ability to execute. This is a provable-or-not-provable question. A CISO either has documented evidence that backup data has been verified as clean before recovery, or they do not. They either have test results showing successful recovery under an attack scenario with data integrity confirmed, or they do not. (For a deeper look at how provable recovery works as a security control, see the Elastio glossary.) The regulation does not care about the tools you selected. It does not care about your vendor relationships. It cares about outcomes: did recovery work, was data integrity maintained, and can you prove it to your supervisor? What to Do Now For CISOs at financial entities with EU exposure, the action items are concrete. Audit your current backup testing regime against Articles 11 and 12. Does your annual testing include cyberattack scenarios with switchovers to backup systems? Can you document the results in a format suitable for regulatory submission? Assess whether you can prove data integrity on recovery. Article 12(7) requires checks and reconciliations to ensure data integrity after an ICT incident. If your recovery process restores data without verifying it is clean, you have a gap. Map your ICT third-party provider register. DORA requires financial entities to maintain and submit registers of contractual arrangements with ICT third-party providers. The ESAs set April 30, 2025 as the deadline for national authorities to report these registers. Prepare for ECB on-site inspections. If you are an ECB-supervised institution, the 2026-2028 supervisory cycle includes targeted OSI campaigns for cyber risk and ICT third-party risk. Gaps identified in the 2024 stress test are now tracked supervisory expectations. Determine your TLPT obligations. If you are designated for TLPT under Article 26, your first test cycle is approaching. Competent authorities designate entities based on systemic importance, ICT maturity, and the impact of services on the financial sector. Frequently Asked Questions What is DORA? DORA is the EU's Digital Operational Resilience Act ( Regulation (EU) 2022/2554 ). It is a binding regulation that requires financial entities operating in the EU to manage ICT risk, report incidents, test resilience under cyberattack scenarios, and oversee third-party ICT providers. It became enforceable on January 17, 2025. What does DORA Article 12 require for backups? Article 12 requires financial entities to document backup policies specifying data scope and frequency, test backup procedures and recovery methods periodically, use physically and logically segregated systems when restoring from backups, maintain redundant ICT capacity, define recovery time and recovery point objectives for each function, and perform data integrity checks when recovering from an ICT incident. Does DORA apply to US banks? DORA applies directly to EU-licensed subsidiaries of US-headquartered banks. It also applies to ICT third-party service providers that support critical functions of EU financial entities, regardless of where the provider is domiciled. US banks with EU operations must ensure those operations comply with DORA's full requirements, including backup testing under cyberattack scenarios and incident reporting. What are the penalties for DORA non-compliance? DORA delegates penalty amounts to member states under Article 50, requiring penalties to be "effective, proportionate and dissuasive." Some jurisdictions have adopted ceilings of up to 2% of total annual worldwide turnover for financial entities. Individual manager penalties range from EUR 100,000 to EUR 5 million depending on the member state. For critical ICT third-party providers, Article 35(8) allows the Lead Overseer to impose periodic penalties of 1% of average daily worldwide turnover per day of non-compliance, for up to six months. Member states may also impose criminal penalties under Article 52. What is DORA TLPT? Threat-Led Penetration Testing (TLPT) is an advanced testing requirement under DORA Articles 26 and 27. Systemically important financial entities must conduct full-scale, intelligence-driven attack simulations on live production systems at least every three years. The tests must cover critical functions, include mandatory purple-team phases, use separate threat intelligence and red team providers, and report results to competent authorities. The framework aligns with TIBER-EU. What did the ECB cyber resilience stress test find? The ECB's 2024 cyber resilience stress test involved 109 banks under direct supervision. The test scenario assumed all preventive measures had failed and a cyberattack had compromised core system databases. The ECB concluded that banks have response and recovery frameworks in place, but areas for improvement remain. Results fed into the 2024 Supervisory Review and Evaluation Process (SREP). The ECB's 2026-2028 supervisory priorities include targeted on-site inspections for cyber risk and ICT third-party provider risk. How does DORA relate to NIS2? DORA is lex specialis to the NIS2 Directive, meaning it takes precedence over NIS2 for financial entities on matters of ICT risk management and incident reporting. Financial entities subject to DORA follow DORA's requirements rather than the corresponding NIS2 provisions. DORA's requirements are more prescriptive and sector-specific than NIS2. Reference Links DORA Full Text Regulation (EU) 2022/2554 (EUR-Lex) Article 11: Response and Recovery digital-operational-resilience-act.com Article 12: Backup Policies and Recovery Methods digital-operational-resilience-act.com Article 26: Threat-Led Penetration Testing digital-operational-resilience-act.com Article 27: Requirements for TLPT Testers digital-operational-resilience-act.com ECB Cyber Resilience Stress Test (2024) ECB Press Release, July 2024 ECB Supervisory Priorities 2025-2027 ECB Banking Supervision ECB Supervisory Priorities 2026-2028 ECB Banking Supervision ECB Stress Tests Overview ECB Banking Supervision ESAs TLPT Regulatory Technical Standards ESA Final Report, July 2024 TIBER-EU and Cyber Resilience ECB Macroprudential Bulletin, February 2025 EBA DORA Overview European Banking Authority EIOPA DORA Overview European Insurance and Occupational Pensions Authority DLA Piper: DORA Penalty Regime Divergence DLA Piper, October 2025 DLA Piper: DORA Application Key Considerations DLA Piper, February 2025 Mayer Brown: DORA Takes Effect Mayer Brown, January 2025 RECOVERY POSTURE Find out whether your recovery is provable. Assess Your Recovery Posture See the Platform

Read post

Bypass Techniques Are Mainstream - And That Should Concern Everyone

March 26, 2026

Bypass Techniques Are Mainstream - And That Should Concern Everyone

The Democratization of Endpoint Defense Bypass There was a time when bypassing endpoint defenses like Windows Defender was considered a niche capability, reserved for elite red teams, advanced threat actors, or highly specialized researchers. That time has passed. Today, bypass techniques are not only widely documented, they are being actively taught, operationalized, and scaled in ways that should give both security leaders and policymakers pause. How Modern Endpoint Protection Is Being Circumvented Modern endpoint protection platforms such as Microsoft Defender rely heavily on behavioral detection and interfaces like the Anti-Malware Scan Interface (AMSI) to identify malicious activity. In theory, these systems provide layered visibility into both known and unknown threats. In practice, however, attackers have adapted. Rather than attempting to defeat detection outright, many now focus on sidestepping it entirely. Techniques such as in-memory execution, obfuscation, and the abuse of legitimate system tools have become standard approaches for avoiding scrutiny. What was once considered advanced tradecraft is now widely understood and, more importantly, repeatable. From Underground Knowledge to Mainstream Curriculum The most significant shift is not purely technical, but structural. Bypass knowledge is no longer confined to underground forums or tightly controlled research communities. It is being democratized. Training platforms, professional courses, and widely accessible labs are now teaching the mechanics of evasion as part of mainstream cybersecurity education. A clear example is the LinkedIn Learning course “Defeating Windows Defender,” which walks through how Defender operates, how it detects threats, and how those mechanisms can be bypassed in practice. This reflects a broader reality: evasion is no longer treated as an edge case, but as a core competency. The Scaling Problem: When Bypass Becomes Repeatable This shift has profound implications. When bypass techniques become structured learning material, they become scalable. They can be taught, repeated, refined, and integrated into standard operating procedures. This fundamentally changes the balance between attackers and defenders. Security teams must account for an ever-expanding set of techniques, while adversaries can focus on identifying and executing a single successful bypass. The asymmetry has always existed, but the barrier to entry is now significantly lower. Studying Security Tools as Targets Equally important is the way attackers are approaching security tools themselves. Endpoint protection is no longer viewed as a black box, but as a system to be studied, tested, and ultimately manipulated. Detection logic is analyzed, blind spots are identified, and controls are treated much like software targets in their own right. This methodical approach, combined with the growing availability of training resources, is accelerating the pace at which bypass techniques evolve. Why Prevention Alone Is No Longer Enough None of this suggests that tools like Microsoft Defender are ineffective. They remain a critical component of any modern security architecture. However, it does underscore a necessary shift in mindset. Organizations can no longer assume that prevention alone will hold. They must operate under the assumption that controls can and will be bypassed, and that some level of adversary activity may go undetected for a period of time. The Shift Toward Resilience The implication is clear: resilience must extend beyond prevention. Detection, response, and containment capabilities are no longer secondary considerations, but central pillars of security strategy. Visibility across endpoints, identity systems, and networks becomes essential, as does the ability to respond quickly when something inevitably slips through. When Bypass Becomes the Norm The real concern is not that bypass techniques exist. They always have. The concern is that they are now accessible, repeatable, and teachable at scale. When bypass becomes curriculum, it stops being exceptional and becomes normal. And once that happens, the entire defensive posture must evolve accordingly. The Blurring Line Between Testing and Threat Activity A second-order effect of this shift is the normalization of adversary tradecraft within legitimate environments. Techniques that were once clear indicators of malicious behavior are increasingly indistinguishable from sanctioned testing or training activity. This creates challenges not only for detection systems, but also for governance and oversight, as organizations struggle to differentiate between benign and hostile use of the same methods. The line between offensive research and operational threat activity continues to blur. The Changing Talent Landscape There is also a growing talent dynamic that cannot be ignored. As more individuals are trained in evasion techniques early in their careers, expectations around what constitutes “baseline” knowledge in cybersecurity are changing. This raises the floor for defenders, but it also raises the ceiling for attackers entering the field. In effect, the industry is producing professionals who are equally capable of strengthening defenses and exploiting their weaknesses. The Reactive Cycle Facing Security Vendors At the same time, vendors face increasing pressure to respond in near real time to newly disclosed bypass techniques. This creates a reactive cycle where defensive updates follow public research and training content, rather than getting ahead of it. While this cycle has always existed to some degree, the speed and visibility of modern information sharing have accelerated it dramatically. The result is a more dynamic but also more volatile defensive landscape. Adapting to an Expected Reality Ultimately, the question is not whether bypass techniques will continue to evolve, but how organizations choose to adapt. Treating evasion as an anomaly is no longer viable. It must be treated as an expected condition within any environment. Organizations that embrace this reality and build for it will be better positioned to manage risk, while those that rely too heavily on prevention alone will find themselves increasingly exposed.

Read post

Podcast

Detonation Point

Conversations with investigators, CISOs, and researchers on the front lines of cybercrime.

All episodes

Webinars

Recent webinars

On-demand and upcoming sessions on ransomware resilience, AWS, and recovery assurance.

Webinars & events

Solution briefs

Architecture deep dives

Technical briefs on how Elastio integrates with AWS Backup, Veeam, and other platforms to deliver provable ransomware recovery.

All solution briefs