Answer these questions before studying the material. Do not worry about getting them wrong — this measures your starting point.
1. An attacker compromises a Cohesity cluster admin account. Which mechanism prevents them from deleting WORM-protected backups?
RBAC policies that restrict the admin role from deletion
DataLock retention locks that are enforced regardless of user role
Network segmentation that blocks deletion API calls
Encryption that makes the data unreadable to the attacker
2. A financial firm operating under SEC Rule 17a-4(f) enables Enterprise mode DataLock. Six months later, auditors require Compliance mode. What is the correct transition path?
Disable Enterprise mode first, then enable Compliance mode
Upgrade directly from Enterprise mode to Compliance mode (one-way)
Deploy a new cluster in Compliance mode and migrate data
Contact Cohesity support to perform a mode switch
3. A legal team requests that specific backup snapshots from last quarter be preserved indefinitely for ongoing litigation. Which feature should be used?
Extend the DataLock retention policy to 99 years
Place a legal hold on the specific snapshots
Disable garbage collection on the cluster
Replicate the snapshots to FortKnox
4. Why does Cohesity use a two-tier DEK/KEK architecture with external KMS rather than storing a single encryption key on-cluster?
To double the encryption strength from AES-128 to AES-256
To ensure the data encryption key is never stored in plaintext alongside encrypted data
To allow multiple users to decrypt data with different passwords
To reduce the computational cost of encryption operations
5. During a key rotation event on a Cohesity cluster, what happens to existing encrypted data?
All data is re-encrypted with the new key during a maintenance window
Data remains encrypted with its original key; only new writes use the new key
The old key is destroyed and a migration process converts all data
A background process gradually re-encrypts data over the next 90 days
WORM (Write Once Read Many) storage ensures that once data is committed, it becomes immutable for a defined retention period. Unlike access-control-based protection that can be bypassed with stolen credentials, WORM makes it so nobody can delete data until the retention clock expires.
SpanFS: Immutability at the Foundation
Cohesity's immutability starts at the filesystem layer. SpanFS stores all backup snapshots in a read-only state within internal Views that are inaccessible from outside the cluster. Every incremental backup is written to a zero-cost clone marked read-only upon completion. When a restore is requested, the system clones the internal view before exposing it, keeping the original untouched.
Cohesity Ransomware Defense: Three Phases
| Phase | Capability | How It Works |
|---|
| Prevent | Immutable filesystem with DataLock and WORM | Backup data cannot be modified or deleted during retention |
| Detect | Machine-learning anomaly detection | Continuously monitors backups for anomalies; recommends last known clean copy |
| Respond | Instant mass restore | Scalable restoration capabilities enable rapid recovery at scale |
flowchart LR
A["Prevent\nImmutable Filesystem\nDataLock & WORM"] --> B["Detect\nML Anomaly Detection\nIdentify Clean Copy"]
B --> C["Respond\nInstant Mass Restore\nRapid Recovery"]
style A fill:#2d6a4f,color:#fff,stroke:#1b4332
style B fill:#e9c46a,color:#000,stroke:#b08c2a
style C fill:#264653,color:#fff,stroke:#1a323d
DataLock: Policy-Driven Immutability
DataLock applies a role-based lock to backup snapshots, storing them in WORM format with a "Lock Until" expiration date. During retention, the snapshot cannot be deleted by anyone — including cluster administrators. Only a user with the Data Security RBAC role can manage DataLock policies, enforcing separation of duties.
sequenceDiagram
participant DS as Data Security User
participant PP as Protection Policy
participant PR as Protection Run
participant SN as Snapshot
DS->>PP: Enable DataLock (30-day retention)
PP->>PR: Policy applied to scheduled run
PR->>SN: Snapshot created
SN->>SN: Lock applied (Lock Until = now + 30 days)
Note over SN: Days 1-30: DELETE DENIED for all users
SN->>SN: Lock expires after 30 days
Note over SN: Day 31+: Normal retention policies resume
Compliance Mode vs. Enterprise Mode
| Feature | Compliance Mode | Enterprise Mode |
|---|
| Protection level | Disk-level WORM | File-level WORM |
| Regulatory compliance | SEC 17a-4(f), FINRA 4511(c), CFTC 1.31 | No regulatory designation |
| Deletion during retention | No user can delete or modify | Root user can delete |
| Who manages settings | Data Security role only | Admin or Data Security role |
| Mode switching | Cannot downgrade (one-way) | Can upgrade to Compliance (one-way) |
stateDiagram-v2
[*] --> Disabled: Initial state
Disabled --> EnterpriseMode: Enable Enterprise
Disabled --> ComplianceMode: Enable Compliance
EnterpriseMode --> ComplianceMode: One-way upgrade allowed
ComplianceMode --> ComplianceMode: Cannot downgrade or disable
DataLock vs. Legal Hold
| Characteristic | DataLock | Legal Hold |
|---|
| Trigger | Automatic (policy-based) | Manual (event-driven) |
| Duration | Time-bound (defined retention) | Indefinite (until removed) |
| Scope | All snapshots matching a policy | Specific selected snapshots |
| Primary use case | Regulatory compliance, ransomware protection | Litigation, investigations, audits |
| When configured | Before data is created (proactive) | After data exists (reactive) |
💾 Write
🔒 Lock
🔓 Expire
Animation: WORM Snapshot Lifecycle — Data is written, locked for the retention period, then the lock expires
While WORM protects data from deletion, encryption protects it from being read. Cohesity encrypts all data at rest using AES-256-GCM (Advanced Encryption Standard, 256-bit keys, Galois/Counter Mode).
AES-256-GCM: What Each Part Means
- AES-256: Symmetric encryption with 2256 possible keys — brute-force attacks are computationally infeasible
- GCM (Galois/Counter Mode): An authenticated encryption mode providing both confidentiality (data is unreadable) and integrity (tampering is detectable)
- FIPS 140-2 Level 2 certified: Validated by NIST to meet federal security requirements
Software vs. Hardware Encryption
| Approach | Mechanism | Advantage |
|---|
| Software-based (primary) | Runs on cluster nodes using Intel AES-NI hardware acceleration | No hardware dependency; drives can be replaced without affecting FIPS certification |
| Self-Encrypting Drives (SEDs) | Dedicated encryption hardware built into the physical drive | Defense-in-depth: protects data even if software encryption is bypassed |
PLAINTEXT DATA
→
AES-256-GCM + Key
→
CIPHERTEXT
Animation: Data-at-rest encryption flow — plaintext is encrypted with AES-256-GCM to produce ciphertext
Encryption Scope: Per-View-Box Keys
Cohesity manages encryption keys at the View Box (storage domain) level. Each View Box maintains independent encryption keys, providing workload isolation. If one View Box's keys were compromised, data in other View Boxes remains protected. This is especially valuable in multi-tenant environments where cryptographic isolation between tenants is required.
Encryption is only as strong as the protection of its keys. Cohesity supports both an internal KMS for simplicity and external KMS via KMIP for stronger separation of keys from data.
Internal KMS
The built-in Internal KMS automatically generates encryption keys and stores them as encrypted keys on the cluster's SSDs. It requires no additional infrastructure. However, since keys reside on the same system as encrypted data, it is analogous to locking your house and leaving the key under the doormat — adequate for basic needs but not for high-security requirements.
External KMS via KMIP
For stronger security, Cohesity integrates with external KMS systems through KMIP (Key Management Interoperability Protocol):
- On-premises: Thales CipherTrust, Fortanix DSM, Entrust KeyControl, HashiCorp Vault, IBM SGKLM
- Cloud-native: AWS KMS, Azure Key Vault, GCP KMS
- High availability: Up to 4 KMS servers in a cluster for redundancy
The DEK/KEK Architecture
With external KMS, Cohesity uses a two-tier key architecture:
| Component | What It Is | Where It Lives |
|---|
| DEK (Data Encryption Key) | Directly encrypts/decrypts data | Generated by cluster; cached in memory |
| EDEK (Encrypted DEK) | The DEK encrypted with the KEK | Stored on cluster (encrypted form) |
| KEK (Key Encryption Key) | Master key that encrypts/decrypts the DEK | External KMS only |
| KEK ID | Pointer to the KEK | Stored on cluster |
sequenceDiagram
participant Svc as Cluster Service
participant Cluster as Cohesity Cluster
participant KMS as External KMS
Svc->>Cluster: Request data access
Cluster->>Cluster: Retrieve EDEK and KEK ID
Cluster->>KMS: Send KEK ID via KMIP
KMS->>KMS: Look up KEK by ID
KMS->>Cluster: Return KEK
Cluster->>Cluster: Decrypt EDEK with KEK to obtain DEK
Cluster->>Cluster: Cache DEK in memory
Cluster->>Svc: Return decrypted data
Note over Cluster: DEK cached; subsequent reads skip KMS
Key Rotation
- Default rotation interval: 90 days (configurable)
- Existing data is not re-encrypted — only new writes use new keys
- AWS KMS deployments: DEKs rotate every 4 hours
Key Escrow and Disaster Recovery
- Internal KMS: Keys on cluster SSDs; protected by cluster replication. Risk: total cluster loss = key loss
- External KMS: Keys decoupled from data storage; own backup/replication/HA. Inherently more resilient
- KMS cluster: Up to 4 servers for no single point of failure
- Critical principle: Lost keys = permanently lost data. Plan DR for your KMS infrastructure
Layered Immutability Strategy
Best practice is defense-in-depth with immutability at multiple layers:
| Layer | Mechanism | Protection |
|---|
| Layer 1: Primary Cluster | On-cluster DataLock | Local snapshots locked; first line of defense |
| Layer 2: Replicated Cluster | Policy-based air gap + DataLock on target | Geographic separation; second admin domain |
| Layer 3: Cyber Vault | Cohesity FortKnox | Network-isolated, Cohesity-managed cloud vault |
flowchart LR
SRC["Production\nData Source"] --> L1
subgraph L1["Layer 1: Primary Cluster"]
L1A["Local Snapshots\nDataLock Protected"]
end
L1 -->|"Auto\nReplication"| L2
subgraph L2["Layer 2: Replicated Cluster"]
L2A["Remote Snapshots\nDataLock Protected"]
end
L2 -->|"Vault\nCopy"| L3
subgraph L3["Layer 3: FortKnox Vault"]
L3A["Network-Isolated\nCyber Vault Copy"]
end
style L1 fill:#d4edda,stroke:#28a745
style L2 fill:#cce5ff,stroke:#007bff
style L3 fill:#f8d7da,stroke:#dc3545
An attacker would need to simultaneously compromise three separate administrative domains with different access controls, network isolation, and geographic locations — an effectively impossible scenario.
Compliance Requirements: SEC, FINRA, CFTC
| Regulation | Requirement | Required Mode |
|---|
| SEC Rule 17a-4(f) | Records in non-rewriteable, non-erasable format | Compliance mode |
| FINRA Rule 4511(c) | Records preserved in WORM format | Compliance mode |
| CFTC Regulation 1.31(c)-(d) | Compliance-grade storage for trading records | Compliance mode |
Cohesity's Compliance mode has been independently assessed by Cohasset Associates. Key planning considerations:
- Compliance mode cannot be downgraded or disabled once enabled
- Only Data Security RBAC role users can manage settings (separation of duties)
- Document WORM configuration, retention periods, and roles as compliance evidence
Testing and Validating Immutability
Immutability is not "set and forget." Validate quarterly:
- Attempt to delete a DataLock-protected snapshot with admin credentials — confirm denial
- Verify only Data Security role users can modify DataLock policies
- Create a test snapshot with short retention; confirm it becomes deletable only after expiry
- Place a legal hold, let normal retention expire, verify snapshot is preserved
- Verify DataLock enforcement on replicated copies at the target cluster
- Confirm encryption status for all View Boxes in the cluster dashboard
- If using external KMS cluster, disable one server and verify continued data access
Now that you have studied the material, answer these questions again along with new ones. Compare your results with the pre-quiz.
1. An attacker compromises a Cohesity cluster admin account. Which mechanism prevents them from deleting WORM-protected backups?
RBAC policies that restrict the admin role from deletion
DataLock retention locks that are enforced regardless of user role
Network segmentation that blocks deletion API calls
Encryption that makes the data unreadable to the attacker
2. A financial firm operating under SEC Rule 17a-4(f) enables Enterprise mode DataLock. Six months later, auditors require Compliance mode. What is the correct transition path?
Disable Enterprise mode first, then enable Compliance mode
Upgrade directly from Enterprise mode to Compliance mode (one-way)
Deploy a new cluster in Compliance mode and migrate data
Contact Cohesity support to perform a mode switch
3. A legal team requests that specific backup snapshots from last quarter be preserved indefinitely for ongoing litigation. Which feature should be used?
Extend the DataLock retention policy to 99 years
Place a legal hold on the specific snapshots
Disable garbage collection on the cluster
Replicate the snapshots to FortKnox
4. What is the fundamental difference between how WORM and traditional access controls protect backup data?
WORM uses encryption while access controls use authentication
Access controls restrict who can delete; WORM prevents anyone from deleting until retention expires
WORM only protects against external threats while access controls protect against internal threats
WORM requires additional hardware while access controls are software-only
5. In Compliance mode, who can manage DataLock settings, and why is this restriction important?
Any cluster administrator, because they need full control for operations
Only users with the Data Security role, enforcing separation of duties so a compromised admin account alone cannot alter WORM policies
Only Cohesity support engineers, ensuring vendor oversight of compliance settings
Both admin and Data Security roles, with two-person approval required
6. Why does Cohesity use a two-tier DEK/KEK architecture with external KMS rather than storing a single encryption key on-cluster?
To double the encryption strength from AES-128 to AES-256
To ensure the data encryption key is never stored in plaintext alongside encrypted data
To allow multiple users to decrypt data with different passwords
To reduce the computational cost of encryption operations
7. During a key rotation event on a Cohesity cluster, what happens to existing encrypted data?
All data is re-encrypted with the new key during a maintenance window
Data remains encrypted with its original key; only new writes use the new key
The old key is destroyed and a migration process converts all data
A background process gradually re-encrypts data over the next 90 days
8. A managed service provider hosts backup data for multiple clients on a single Cohesity cluster. How does Cohesity's encryption architecture ensure client data isolation?
Each client gets a separate physical cluster with its own encryption
Each View Box maintains independent encryption keys, providing cryptographic isolation per tenant
All clients share a single encryption key but use separate RBAC policies
Client data is encrypted in transit but stored unencrypted at rest
9. An organization loses access to their external KMS and all KEK backups. What is the impact on their encrypted Cohesity data?
Data is temporarily inaccessible but can be recovered by resetting the cluster
Data is permanently unrecoverable because the DEKs cannot be decrypted without the KEK
Cohesity has a master recovery key that can decrypt all data
The cached DEKs in memory will continue working indefinitely
10. Why does Cohesity use software-based encryption with Intel AES-NI rather than relying solely on self-encrypting drives?
Software encryption is more secure than hardware encryption
It removes hardware dependency so drives can be replaced without affecting FIPS certification
Self-encrypting drives are not compatible with Cohesity's filesystem
Software encryption is faster than hardware encryption
11. Why does a layered immutability strategy (DataLock + replication + FortKnox) provide stronger protection than DataLock alone?
Because DataLock alone does not actually prevent deletion
Because each layer uses a different administrative domain and network boundary, requiring simultaneous compromise of all three
Because FortKnox uses a different encryption algorithm than the primary cluster
Because replication doubles the encryption key length
12. An organization enables Compliance mode DataLock but later realizes they do not actually need regulatory compliance. What are their options?
Downgrade to Enterprise mode since they do not need compliance features
They must continue operating in Compliance mode because it cannot be downgraded or disabled once enabled
Disable DataLock entirely and re-enable in Enterprise mode
Contact Cohasset Associates to remove the compliance designation