Chapter 11: Security, Encryption, and Ransomware Resilience
Learning Objectives
Apply defense-in-depth across hardware, OS, software, and identity layers on a Cohesity cluster.
Configure FIPS-validated encryption at rest and in transit using software encryption, SEDs, and external KMIP/KMS providers.
Architect immutability with DataLock, WORM semantics, and legal hold workflows enforced by a Security Officer role.
Differentiate Cohesity FortKnox cyber vaulting from CloudArchive and explain when each is appropriate.
Design ransomware detection and clean-room recovery patterns using Cohesity DataHawk.
Layer DataLock + FortKnox + DataHawk into a coherent threat-defense architecture for a regulated workload.
Backups used to be the last thing an attacker thought about. Today they are the first. Modern ransomware operators routinely spend days or weeks inside an environment specifically hunting for backup admin credentials. For a Cohesity architect, security is the central design axis around which encryption, immutability, isolation, detection, and recovery are organized.
Defense-in-Depth Layers (Animated)
Defense in Depth: concentric layers build outward from hardware to data immutability
Section 1: Encryption at Rest and In Transit
Pre-Section Check - Encryption
1. A federal agency requires that pulling drives from a Cohesity chassis must yield ciphertext, with crypto-erase capability that wipes a drive instantly. Which encryption approach best fits?
Software AES at the SpanFS layer with internal KMS
Self-Encrypting Drives (SEDs) on FIPS-validated ReadyNodes
SMB3 encryption for all Views
TLS 1.3 with mutual authentication
2. What happens to encrypted data on a Cohesity cluster if the external KMIP/KMS revokes the KEK?
The cluster falls back to internal keys automatically
Data becomes inaccessible - acting as a global kill-switch
Replication continues but local reads fail
Only new writes are blocked; existing data is unaffected
3. Which is true about FIPS 140-2/140-3 mode on a Cohesity cluster?
It can be set per-View for tenant isolation
It is a cluster-wide setting and most easily enabled at deployment
It only affects in-transit traffic, not at-rest encryption
It permits MD5 and SHA-1 for backwards compatibility
Software Encryption vs. Self-Encrypting Drives
Cohesity supports two parallel at-rest encryption paths. Software encryption is performed by SpanFS itself: every chunk is encrypted with AES-256 using a Data Encryption Key (DEK) wrapped by a Key Encryption Key (KEK). The advantage is portability - it works on any node, physical, virtual, or cloud - with small CPU overhead absorbed by AES-NI. Self-Encrypting Drives push encryption into drive firmware; the drive holds the Media Encryption Key and refuses to release plaintext without an authentication key. Pulling a drive yields ciphertext.
Factor
Software Encryption
SED
Where it runs
SpanFS / Cohesity software
Drive firmware (FIPS 140-2/3)
Form factor
All (physical, VE, Cloud)
Physical appliances and ReadyNodes only
Performance impact
Small (AES-NI accelerated)
None on the host
Crypto-erase
Re-key wipes data logically
PSID revert wipes drive instantly
Customer-Managed Keys via KMIP
At enterprise scale, KEKs live in a customer-controlled KMS (Thales CipherTrust, Entrust KeyControl, HashiCorp Vault via KMIP, AWS KMS, Azure Key Vault). The cluster generates DEKs locally; KEKs wrap and unwrap them over KMIP/TLS. Revoking the KEK acts as a kill-switch.
sequenceDiagram
participant Cluster as Cohesity Cluster
participant KMS as KMIP / KMS Server
participant Disk as SpanFS Chunk File
Cluster->>Cluster: Generate local DEK
Cluster->>KMS: Request KEK wrap (KMIP/TLS)
KMS-->>Cluster: Wrapped DEK released
Cluster->>Disk: Encrypt chunk with DEK
Note over Cluster,KMS: On read: cluster requests unwrap
Cluster->>KMS: Unwrap DEK request
KMS-->>Cluster: Plaintext DEK (in-memory)
Cluster->>Disk: Decrypt chunk
Note over KMS: Revoke KEK = global kill-switch
TLS, SMB3, NFS Encryption, and FIPS Mode
Every interface that leaves a node is TLS-protected (1.2 or 1.3 with administrator-installed CA-signed certificates). Replication is encrypted, compressed, and deduplicated on the wire. SMB3 supports per-session encryption, and NFSv4.1 with Kerberos krb5p provides privacy - configured per View. FIPS mode is cluster-wide, restricts cipher suites to FIPS-approved algorithms, disables MD5/SHA-1 for signatures, forces SEDs to FIPS-validated configuration, and is most easily enabled at deployment time.
Key Points
Software encryption runs in SpanFS (any form factor); SEDs run in drive firmware (physical only) with instant PSID crypto-erase.
KMIP-attached external KMS (Thales, Entrust, HashiCorp, AWS KMS, Azure Key Vault) provides BYOK and a global kill-switch via KEK revocation.
TLS 1.2/1.3 protects management, REST API, and replication; SMB3 and NFSv4.1 krb5p add per-session client encryption for SmartFiles.
FIPS 140-2/140-3 mode is cluster-wide, restricts cipher suites, and is most easily enabled at deployment.
Post-Section Check - Encryption
1. A federal agency requires that pulling drives from a Cohesity chassis must yield ciphertext, with crypto-erase capability that wipes a drive instantly. Which encryption approach best fits?
Software AES at the SpanFS layer with internal KMS
Self-Encrypting Drives (SEDs) on FIPS-validated ReadyNodes
SMB3 encryption for all Views
TLS 1.3 with mutual authentication
2. What happens to encrypted data on a Cohesity cluster if the external KMIP/KMS revokes the KEK?
The cluster falls back to internal keys automatically
Data becomes inaccessible - acting as a global kill-switch
Replication continues but local reads fail
Only new writes are blocked; existing data is unaffected
3. Which is true about FIPS 140-2/140-3 mode on a Cohesity cluster?
It can be set per-View for tenant isolation
It is a cluster-wide setting and most easily enabled at deployment
It only affects in-transit traffic, not at-rest encryption
It permits MD5 and SHA-1 for backwards compatibility
Section 2: Immutability and DataLock
Pre-Section Check - Immutability
4. A regulator demands that no individual, regardless of role, can delete records before retention expires. Which DataLock mode applies?
Governance lock
Compliance lock
Legal hold
SpanFS baseline immutability only
5. Once a DataLock policy locks a snapshot, which of these is permitted during the lock window?
Cluster admin deletes the snapshot
Security Officer shortens retention
Extending retention further
In-place modification of the gold copy
SpanFS Baseline Immutability
By default every Cohesity backup snapshot is stored as a read-only, immutable object. The original gold copy cannot be mounted, modified, encrypted in place, or deleted by any external system. Read/write workflows (instant recovery, dev/test) get zero-cost, redirect-on-write clones; the gold copy stays intact, defeating the most common ransomware pattern of overwriting backup files in place.
DataLock Policies and WORM
DataLock adds a hardened, time-bound, role-bound enforcement layer applied by a Security Officer - a role distinct from the cluster admin. Once applied, a snapshot enters WORM state for the configured retention. It cannot be deleted or modified by any user, including the cluster admin, the Security Officer who applied the lock, or any account with full privileges. The lock can only be extended - never shortened or removed. DataLock applies equally to copies tiered or archived to CloudArchive and FortKnox.
DataLock Lifecycle Animation
DataLock states: Created -> Locked (countdown) -> Expired -> Released. Attempted delete fails during the locked window.
Compliance vs. Governance
Mode
Who can shorten retention
Use case
Mapping
Governance
Security Officer can shorten/remove
Internal policy, operational immutability
Best-practice hygiene
Compliance
Nobody - not even Security Officer
SEC 17a-4, FINRA, HIPAA retention floors
Strict regulatory immutability
Legal Hold and Quorum Approval
Legal hold is an indefinite freeze applied when litigation is anticipated; it extends retention until explicitly released, regardless of the DataLock timer. For sensitive operations outside the locked window - Protection Group deletion, retention shortening, target removal, legal hold release - Cohesity supports quorum approval (e.g., 2-of-3 or 3-of-5). A compromised account can request the destructive action; it cannot finish it without independent approvers.
Key Points
SpanFS makes every snapshot immutable by default; clones are redirect-on-write so the gold copy is never touched.
DataLock is applied by a separate Security Officer role and produces WORM that even the Security Officer cannot shorten or remove (only extend) during the lock.
Compliance mode forbids any shortening; Governance mode allows the Security Officer to override for operational exceptions.
Legal hold is indefinite and extends retention beyond the DataLock timer; quorum approval (e.g., 2-of-3) protects destructive actions from single-credential compromise.
Post-Section Check - Immutability
4. A regulator demands that no individual, regardless of role, can delete records before retention expires. Which DataLock mode applies?
Governance lock
Compliance lock
Legal hold
SpanFS baseline immutability only
5. Once a DataLock policy locks a snapshot, which of these is permitted during the lock window?
Cluster admin deletes the snapshot
Security Officer shortens retention
Extending retention further
In-place modification of the gold copy
Section 3: Cyber Vaulting with Cohesity FortKnox
Pre-Section Check - FortKnox
6. Which architectural feature most distinguishes FortKnox from CloudArchive?
Lower cost per TB
Persistent network connection to cloud
Virtual air gap with mandatory multi-person quorum
Customer-managed S3 buckets only
7. A customer needs a 7-year cost-optimized cold archive replacing tape. Which is appropriate?
FortKnox
CloudArchive
SmartFiles tier
CloudReplicate to Cloud Edition
FortKnox is a SaaS-delivered cyber vault - Data Isolation and Recovery as a Service (DIRaaS) - that stores an immutable, isolated tertiary copy of backup data in a Cohesity-managed cloud tenant on AWS, Azure, or Google Cloud. The customer subscribes; Cohesity operates the vault.
The Virtual Air Gap (Animated)
Virtual Air Gap cycle: gap closed -> opens for transfer window -> data flows -> closes -> ransomware attempt fails
Mandatory Multi-Person Quorum
FortKnox enforces multi-person quorum approval for sensitive operations - recoveries, retention changes, vault configuration - at the vault level. Two or more authorized users must approve before the operation proceeds. The control is purpose-built for insider-threat and stolen-credential scenarios.
DataHawk is the AI/ML-driven security service in the Cohesity Data Cloud, packaging three capabilities into a SaaS that answers the three incident questions: Is there an attack? Where is the malware? What sensitive data was exposed?
ML models trained on per-workload baselines inspect data entropy (encrypted-in-place data has near-uniform byte distribution), file/object change rates, write patterns, and file-extension patterns (e.g., .locked, .crypt). Anomaly scores drive the clean snapshot recommendation, pointing administrators to the last-known-good recovery point - critical because naive "most recent backup" restore often restores the encryption itself.
Threat Intelligence and YARA
Continuously updated feed of 100,000+ IOCs refreshed daily from 160,000+ sources, including curated YARA rules, CrowdStrike Falcon Intelligence, and Cohesity-curated default libraries. Customers do not author rules. DataHawk identifies malware hashes, the specific files containing them, and the variant/family.
BigID-Powered Classification
200+ predefined patterns and 50+ out-of-the-box compliance policies (PII, PHI/HIPAA, PCI, GDPR). Classification reports tell responders exactly which categories of sensitive data lived in affected files - essential for HIPAA's 60-day and GDPR's 72-hour notification clocks.
Clean-Room Recovery
Identify the clean recovery point via DataHawk's ML recommendation.
Provision an isolated environment (alternate cluster, alternate VLAN, recovery-only VPC).
Restore from FortKnox or DataLock-protected snapshot into the clean room.
Run threat intel scans, AV, and integrity validation.