Cohesity Security Specialist (COH350) Study Guide

A comprehensive study guide covering all seven exam domains of the Cohesity Certified Security Specialist certification, mapping to the COH350 exam objectives.

Table of Contents

• Chapter 1: Introduction to Cohesity Data Cloud & Security Architecture
• Chapter 2: Network Security
• Chapter 3: System Hardening — WORM Storage & Encryption
• Chapter 4: System Hardening — Attack Surface Reduction
• Chapter 5: Security Assessment & Compliance
• Chapter 6: Authentication — MFA, SSO & Active Directory
• Chapter 7: Access Control — RBAC, Multi-Tenancy & Quorum
• Chapter 8: Monitoring, Auditing & Threat Detection
• Chapter 9: Incident Response & Remediation
• Chapter 10: Secure Data Management & Data Isolation

Chapter 1: Introduction to Cohesity Data Cloud & Security Architecture

Learning Objectives

• Describe the Cohesity Data Cloud platform architecture and its core components
• Explain the Cohesity Threat Defense Architecture and its layered security model
• Identify the seven security domains tested in the COH350 certification exam
• Differentiate between Cohesity DataProtect, SmartFiles, CloudArchive, and Cloud Services

1.1 Cohesity Data Cloud Platform Overview

Imagine a city where every essential service — water, electricity, gas, internet, and waste management — is run by a different company, each with its own billing system, infrastructure, and support team. Now imagine one utility company that consolidates all of those services onto a single, modern grid. That is what Cohesity Data Cloud does for enterprise data management. It replaces the fragmented landscape of backup appliances, archival systems, file servers, and object stores with a single, software-defined platform. [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/solution-guides/the-essential-guide-to-modern-data-management-en.pdf]

The Cohesity Data Cloud is “a unified cloud data management platform for securing, managing, and extracting value from your data, available as self-managed software and SaaS.” [Source: https://docs.cohesity.com/disaster-recovery/pillars/data-cloud.htm] It consolidates backup and recovery, disaster recovery, long-term archival, file and object storage, test/dev data management, and analytics into one environment that can run on-premises, in the public cloud, or at the edge.

Cohesity Cluster Architecture and Node Types

At the physical level, Cohesity runs on clusters — groups of interconnected servers called nodes. Each node is a commodity x86 server, available directly from Cohesity or from hardware partners such as Cisco, HPE, and Dell. A minimum deployment starts at three nodes, and the architecture scales linearly: you add capacity by adding nodes, not by replacing equipment. [Source: https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/UCS_CVDs/ucs_xseries_cohesity.html]

Think of each node as a brick in a wall. You can add bricks to make the wall longer or taller without tearing down what already exists. This hyperconverged design bundles compute, storage, and networking into each node, so there is no separate storage array to manage. The result is that organizations can expand backup capacity at any time without disruptive forklift upgrades. [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/white-paper/Cohesity_Data_Protection_White_Paper.pdf]

A critical design principle is that there is no master node. Every node in the cluster participates equally, which eliminates single points of failure and allows the system to dynamically rebalance data as nodes are added or removed. [Source: https://www.cohesity.com/platform/spanfs/]

Figure 1.1: Cohesity Cluster Architecture — Hyperconverged Node Design

flowchart LR
    subgraph Cluster["Cohesity Cluster (No Master Node)"]
        direction LR
        N1["Node 1\nCompute + Storage + Network"]
        N2["Node 2\nCompute + Storage + Network"]
        N3["Node 3\nCompute + Storage + Network"]
        N4["Node N\n(Scale Linearly)"]
    end
    N1 <--> N2
    N2 <--> N3
    N3 <--> N4
    N1 <--> N3
    N2 <--> N4
    subgraph SpanFS["SpanFS Distributed File System"]
        direction LR
        D1["Global Deduplication"]
        D2["Unlimited Snapshots"]
        D3["Multi-Protocol Access\nNFS / SMB / S3"]
    end
    Cluster --> SpanFS

SpanFS: The Foundation

Underneath every Cohesity cluster runs SpanFS, a third-generation, web-scale distributed file system. SpanFS is the engine that makes the unified platform possible. Its key characteristics include:

[Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/white-paper/Cohesity-SpanFS-and-SnapTree-WP.pdf]

SpanFS is the only file system in the industry that simultaneously provides NFS, SMB, and S3 interfaces, global deduplication, and unlimited snapshots and clones on a web-scale platform. [Source: https://www.cohesity.com/blogs/cohesity-spanfs-snaptree/]

Worked Example — Why Multi-Protocol Matters: Consider a hospital that stores medical images (DICOM files) on an NFS share, serves them to clinicians via an SMB-connected workstation, and archives them to an S3-compatible cloud tier for compliance. With traditional infrastructure, this requires three separate storage systems, three sets of permissions, and three management consoles. On Cohesity, all three protocols access the same underlying data on SpanFS, managed from a single pane of glass.

Data Cloud Components: DataProtect, SmartFiles, CloudArchive

The Cohesity Data Cloud is not a single product but a family of services built on the SpanFS foundation. The three core components you will encounter most frequently are:

DataProtect is the platform’s software-defined backup and recovery engine. It provides unified, policy-based protection for virtual machines (VMware, Hyper-V), physical servers, databases (SQL, Oracle), cloud workloads, and Kubernetes containers. DataProtect offers centralized cluster management across on-premises, cloud, and virtual environments with remote access capabilities through the Helios management plane. [Source: https://futurumgroup.com/wp-content/uploads/documents/FGPR_Cohesity_DataProtect-5.pdf]

SmartFiles is a multiprotocol file and object services platform for hybrid cloud environments. It natively supports NFS, SMB, and S3 protocols and provides multi-tier data management, allowing organizations to move data between hot and cold storage tiers based on access patterns and policies. Think of SmartFiles as a smart filing cabinet that automatically moves rarely accessed folders to cheaper long-term storage while keeping frequently used ones at arm’s reach. [Source: https://www.cohesity.com/platform/smartfiles/]

CloudArchive handles long-term, off-site archival storage. It supports policy-driven archival to major cloud providers including Google Cloud Storage Nearline, Microsoft Azure Cool storage, and Amazon S3/Glacier. CloudArchive is designed for compliance and long-term retention requirements where data must be kept for years but is rarely accessed. [Source: https://cloud.google.com/architecture/partners/using-cohesity-with-cloud-storage-for-enterprise-hybrid-data-protection]

Figure 1.2: Data Cloud Component Architecture Built on SpanFS

flowchart TD
    subgraph Services["Cohesity Data Cloud Services"]
        DP["DataProtect\nBackup & Recovery"]
        SF["SmartFiles\nFile & Object Services"]
        CA["CloudArchive\nLong-Term Archival"]
    end
    subgraph Cloud["Cloud Services"]
        CT["CloudTier"]
        CR["CloudReplicate"]
        FK["FortKnox\nCyber Vault"]
        SC["SiteContinuity"]
    end
    subgraph Foundation["SpanFS Foundation"]
        FS["SpanFS Distributed File System\nSnapTree | NoSQL Store | Global Dedup"]
    end
    DP --> FS
    SF --> FS
    CA --> FS
    CT --> FS
    CR --> FS
    FK --> FS
    SC --> FS

Cohesity Cloud Services and Hybrid Deployment Models

Beyond the core trio, Cohesity offers several cloud-native services that extend the platform into hybrid and multi-cloud environments:

• CloudTier: Automatically tiers cold data to cloud object storage (Google Cloud Storage, Azure, Amazon S3) while keeping metadata on-premises for fast lookups. [Source: https://cloud.google.com/architecture/partners/using-cohesity-with-cloud-storage-for-enterprise-hybrid-data-protection]
• CloudReplicate: Replicates data to cloud vendors for disaster recovery and cloud migration scenarios.
• SiteContinuity: Provides automated failover and failback orchestration for business continuity of mission-critical workloads.
• FortKnox: A SaaS-based cyber-vaulting solution that stores immutable data copies in Cohesity-managed cloud vaults, creating a virtual air-gap between production data and backup copies. [Source: https://www.cohesity.com/why-cohesity/threat-defense/]

Modern backup-as-a-service offerings like Cohesity DataProtect delivered as a Service use a cloud-native architecture and microservices in the backend to simplify and scale operations. [Source: https://www.cohesity.com/blogs/architecture-matters-blueprints-for-backup-as-a-service-offerings/]

The result is a deployment model where organizations can choose to run Cohesity entirely on-premises, entirely in the cloud, or in a hybrid configuration — all managed through a single control plane.

Key Takeaway: The Cohesity Data Cloud consolidates backup, file/object storage, archival, and cloud services onto a single platform built on SpanFS, a masterless distributed file system. This eliminates the infrastructure silos that plague traditional data management and enables linear scaling by simply adding commodity nodes.

1.2 Cohesity Threat Defense Architecture

If the Cohesity Data Cloud is the city, then the Threat Defense Architecture is its security system — not just a single lock on the front door, but a layered network of guards, cameras, alarms, and vaults working together. The Cohesity Threat Defense Architecture keeps organizations ahead of cybercriminals and threats by incorporating multiple security pillars, and it follows and goes beyond Zero Trust to help organizations achieve cyber resilience. [Source: https://www.cohesity.com/blogs/what-is-cohesity-threat-defense/]

Layered Security Model and Defense-in-Depth Approach

Defense-in-depth is a security strategy that deploys multiple independent layers of protection so that the failure of any single layer does not compromise the entire system. Cohesity identifies seven defensive layers, each addressing a different attack surface:

[Source: https://www.cohesity.com/glossary/defense-in-depth/]

Real-World Analogy: Think of a bank vault. The bank has security guards (Human layer), a locked building (Physical), fences and surveillance cameras on the perimeter (Perimeter), interior motion sensors and locked doors between rooms (Internal Network), hardened vault doors (Host), combination locks requiring specific codes (Applications), and finally the vault itself with individually locked safety deposit boxes (Data). An attacker would need to defeat all seven layers to reach the valuables.

Figure 1.3: Defense-in-Depth — Seven Security Layers

flowchart TD
    L1["Layer 1: Human\nTraining, RBAC, SSO, MFA"]
    L2["Layer 2: Physical\nGuards, Biometrics, Fire Suppression"]
    L3["Layer 3: Perimeter\nFirewalls, Vulnerability Testing, DDoS Prevention"]
    L4["Layer 4: Internal Network\nEncryption in Transit, Micro-Segmentation"]
    L5["Layer 5: Host\nOS Hardening, Patching, Endpoint AV"]
    L6["Layer 6: Applications\nAI/ML Anomaly Detection, Least Privilege"]
    L7["Layer 7: Data\nEncryption at Rest, Access Controls, Immutability"]
    L1 --> L2 --> L3 --> L4 --> L5 --> L6 --> L7

Cohesity’s approach aligns with the NIST Cyber Security Framework and specifically addresses the three stages of ransomware evolution: encryption attacks, backup deletion, and data exfiltration. [Source: https://www.cohesity.com/blogs/countering-the-evolving-threat-of-ransomware/]

Four Pillars of Threat Defense

Within this defense-in-depth framework, Cohesity organizes its security capabilities into four pillars:

Pillar 1: Data Resiliency protects data against hardware failures, corruption, human error, natural disasters, and ransomware. This pillar includes:

• Immutability: Data stored in internal Views on SpanFS is never directly exposed to external applications. The DataLock feature provides time-bound WORM (Write Once, Read Many) capability, preventing anyone — including administrators — from modifying or deleting protected data before the lock expires.
• Encryption: FIPS-validated AES-256 encryption protects data both in transit and at rest. Organizations can integrate third-party key management systems for additional control.
• Fault Tolerance: The distributed architecture ensures backup resilience through node and cluster failure recovery with strict consistency protocols.

[Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/white-paper/threat-defense-architecture-white-paper-en.pdf]

Pillar 2: Access Control addresses credential theft — the preferred method attackers use to deploy ransomware:

• Multifactor Authentication (MFA): Requires multiple authentication factors such as device tokens, smart cards, and passwords.
• Granular Role-Based Access Control (RBAC): Restricts access by assigning privileges appropriate to each user’s role.
• Quorum Authorization: Requires two-person approval for critical operations (such as deleting a backup policy), preventing a single compromised credential from causing damage.
• Continuous Monitoring and Auditing: Integrations with SIEM/SOAR platforms provide real-time visibility into security events.

[Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/white-paper/threat-defense-architecture-white-paper-en.pdf]

Pillar 3: AI-Driven Detection and Analytics addresses data exfiltration and stealthy threats:

• Data Classification: Proactive scanning identifies where sensitive data resides and how exposed it is.
• Adaptive Behavioral Analytics: AI-powered analysis detects anomalous access patterns that may indicate insider threats or ransomware activity.
• Near Real-Time Threat Detection: Native antivirus engines and threat intelligence (powered by Google) scan data within the platform.
• Custom YARA Rules: Administrators can create custom rules for identifying advanced or organization-specific threats.

[Source: https://www.cohesity.com/platform/threat-protection/]

Pillar 4: Data Security Integrations (Extensibility) connects Cohesity to the broader security ecosystem through integrations with tools such as Cisco SecureX, Tenable, and various cloud, endpoint, identity, and SIEM/SOAR partners. [Source: https://www.cohesity.com/blogs/what-is-cohesity-threat-defense/]

          Cohesity Threat Defense Architecture

    +--------------------------------------------------+
    |              Extensibility (Pillar 4)             |
    |   SIEM/SOAR  |  Cisco SecureX  |  Tenable  | ... |
    +--------------------------------------------------+
    |         AI-Driven Detection (Pillar 3)            |
    |  Classification | Behavioral Analytics | YARA     |
    +--------------------------------------------------+
    |           Access Control (Pillar 2)               |
    |     MFA  |  RBAC  |  Quorum  |  Audit Logging    |
    +--------------------------------------------------+
    |          Data Resiliency (Pillar 1)               |
    |  Immutability | AES-256 Encryption | Fault Tol.   |
    +--------------------------------------------------+
    |              SpanFS / Data Cloud                  |
    +--------------------------------------------------+

Data Resilience vs. Data Security Distinction

It is important to distinguish between data resilience and data security, as they address different risks:

• Data resilience ensures data survives — that it can be recovered after hardware failure, corruption, natural disaster, or ransomware encryption. It answers the question: “Can we get our data back?”
• Data security ensures data is not compromised — that unauthorized parties cannot read, modify, or exfiltrate it. It answers the question: “Is our data safe from unauthorized access?”

A backup system with strong resilience but weak security is like a bank vault with an indestructible door but no lock. The data will survive a fire, but anyone can walk in. Cohesity’s Threat Defense Architecture addresses both dimensions: Pillar 1 (Data Resiliency) ensures recoverability, while Pillars 2 through 4 ensure security.

Cohesity Security Advisor and Security Posture Scoring

Security Advisor is a built-in tool that scans the Cohesity environment and provides a quantitative security posture score. It evaluates an array of security configurations including access control settings, audit logs, and the encryption framework. The workflow is straightforward: scan, score, remediate. [Source: https://www.cohesity.com/newsroom/press/cohesity-launches-security-advisor-making-it-as-easy-as-scan-score-remediate-to-improve-security-posture-and-reduce-cyber-risks-in-an-era-of-sophisticated-ransomware-attacks/]

If a scan reveals a score indicating an issue, administrators can drill into the details and receive specific recommendations on how to address configuration gaps. Security Advisor provides a centralized view of all Cohesity cluster security settings across geographies, sites, and regions through the Helios Dashboard, and it is available to all customers globally at no additional cost. [Source: https://www.helpnetsecurity.com/2021/12/15/cohesity-security-advisor/]

Figure 1.4: Security Advisor Workflow — Scan, Score, Remediate

flowchart LR
    A["Run Security\nAdvisor Scan"] --> B["Receive Security\nPosture Score"]
    B --> C{"Score\nAcceptable?"}
    C -->|Yes| D["Monitor &\nMaintain"]
    C -->|No| E["Review Detailed\nRecommendations"]
    E --> F["Remediate\nConfiguration Gaps"]
    F --> A
    D -.->|"Periodic Rescan"| A

Worked Example — Security Advisor in Action: An organization deploys a new Cohesity cluster at a branch office. After initial configuration, the administrator runs Security Advisor and receives a score of 62 out of 100. The report highlights that MFA is not enabled, audit logging is not forwarded to the SIEM, and several backup policies lack DataLock. The administrator enables MFA, configures syslog forwarding, and adds DataLock to the relevant policies. A follow-up scan shows the score has improved to 91.

Key Takeaway: The Cohesity Threat Defense Architecture implements defense-in-depth through four pillars — Data Resiliency, Access Control, AI-Driven Detection, and Extensibility — layered across seven security domains from human to data. Security Advisor provides a continuous, quantitative feedback loop for measuring and improving security posture.

1.3 COH350 Exam Domain Overview

The Cohesity Certified Security Specialist exam, designated COH350, validates that a candidate possesses the knowledge and skills to secure a Cohesity Data Cloud environment. Understanding the exam structure early in your study process will help you allocate preparation time effectively.

Seven Exam Domains and Their Weight Distribution

The COH350 exam tests knowledge across seven security domains, each weighted according to its importance to the security specialist role:

[Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/academy/security-specialist-exam-prep-en.pdf]

Exam Logistics:

[Source: https://www.cohesity.com/resource-assets/academy/data-security-professional-exam-details-en.pdf]

Products covered by the exam include Cohesity Data Cloud, DataProtect, CloudArchive, Replication, SmartFiles, and related threat defense and cloud services. [Source: https://www.cohesity.com/academy/certification/cohesity-data-security-professional/]

Target Roles and Recommended Experience

The COH350 certification is designed for practitioners who work directly with data protection and security infrastructure. Target roles include:

• Professional Services Engineers
• Security Administrators
• Data Protection Administrators
• Data Architects
• Sales Engineers
• Storage Administrators
• Network Administrators

[Source: https://www.cohesity.com/academy/certification/cohesity-data-security-professional/]

Candidates are expected to have hands-on experience with Cohesity administration and a working understanding of enterprise security concepts including encryption, access control, and network security.

Study Strategy and Exam Preparation Tips

Given the domain weights, here is a practical allocation strategy for your study time:

1. Start with System Hardening (22%) — This is the heaviest domain and covers foundational topics like WORM, encryption, and attack surface reduction. A solid grasp here pays dividends across other domains.
2. Follow with User & Access Management (17%) and Network Security (15%) — Together with System Hardening, these three domains account for 54% of the exam. Mastering them gives you a strong foundation.
3. Study Security Assessment (13%) and Incident Response (13%) together — Both domains require understanding how security policies translate into operational procedures.
4. Finish with Monitoring & Reporting (10%) and Secure Data Management (10%) — These domains are important but narrower in scope.

Throughout this textbook, each chapter maps to one or more exam domains, and domain-specific content is flagged so you can track your coverage.

Key Takeaway: The COH350 exam spans seven domains, with System Hardening (22%), User & Access Management (17%), and Network Security (15%) comprising the majority of the test. Allocate study time proportionally to domain weight, and focus first on the three domains that together represent 54% of the exam.

1.4 Security Fundamentals for Data Management

Before diving into Cohesity-specific security configurations in later chapters, it is essential to establish the foundational security concepts that underpin every decision in data protection.

CIA Triad Applied to Backup and Recovery

The CIA triad — Confidentiality, Integrity, and Availability — is the cornerstone of information security. Each element has specific implications for backup and recovery environments:

Real-World Analogy: Consider a hospital’s patient records. Confidentiality means only authorized medical staff can view a patient’s chart. Integrity means no one can silently alter a diagnosis or prescription in the record. Availability means the records are accessible when a doctor needs them during an emergency, even if a server has failed.

In a ransomware scenario, all three principles are under simultaneous attack: the attacker encrypts data (destroying availability), threatens to leak it (violating confidentiality), and may alter records to undermine trust (compromising integrity). Cohesity’s Threat Defense Architecture addresses all three through its four pillars.

Figure 1.5: CIA Triad Under Ransomware Attack and Cohesity Defenses

flowchart TD
    subgraph Attack["Ransomware Attack Vectors"]
        A1["Encrypt Data\n(Destroy Availability)"]
        A2["Threaten to Leak\n(Violate Confidentiality)"]
        A3["Alter Records\n(Compromise Integrity)"]
    end
    subgraph Defense["Cohesity Threat Defense Response"]
        D1["Immutable Backups\n+ Fault Tolerance"]
        D2["AES-256 Encryption\n+ RBAC + MFA"]
        D3["DataLock WORM\n+ Checksums"]
    end
    A1 -->|"Countered by"| D1
    A2 -->|"Countered by"| D2
    A3 -->|"Countered by"| D3

Zero Trust Principles in Data Protection

Zero Trust is a security model built on the principle “never trust, always verify.” Rather than assuming that users and devices inside the network perimeter are trustworthy, Zero Trust requires continuous authentication and authorization for every access request, regardless of origin.

Cohesity’s approach follows and extends Zero Trust principles through several mechanisms:

• No implicit trust: Every API call and user action is authenticated and authorized, even for internal cluster operations.
• Least privilege access: RBAC ensures users can only perform actions required by their role — a backup operator cannot modify security policies.
• Quorum authorization: Critical operations require approval from multiple administrators, so no single compromised account can cause catastrophic damage. [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/white-paper/threat-defense-architecture-white-paper-en.pdf]
• Microsegmentation: Network traffic within the cluster is segmented so that compromise of one component does not grant access to others.
• Continuous verification: Security Advisor continuously evaluates the security posture, and AI-driven analytics monitor for anomalous behavior in real time.

Worked Example — Zero Trust in Practice: A storage administrator logs in to the Cohesity dashboard using their Active Directory credentials and a time-based one-time password (MFA). They attempt to delete an old backup policy. Because the policy is protected by Quorum, the system requires a second administrator to approve the deletion. Even though the first administrator has legitimate credentials and appropriate RBAC permissions, the system does not trust a single point of authorization for destructive operations.

Regulatory Landscape Affecting Data Security

Data protection does not exist in a vacuum. Regulatory and compliance requirements shape how organizations configure their backup and security infrastructure. Key frameworks that influence Cohesity deployments include:

Cohesity’s platform capabilities — encryption at rest and in transit, WORM/DataLock for immutability, granular RBAC, comprehensive audit logging, and policy-driven retention — map directly to the controls required by these frameworks. Security Advisor can help validate that a deployment meets the configuration baselines these regulations demand.

The NIST alignment is particularly significant for the COH350 exam. Cohesity explicitly maps its Threat Defense Architecture to the five NIST functions (Identify, Protect, Detect, Respond, Recover), and understanding this mapping will help you answer questions about how Cohesity features address specific compliance requirements. [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/white-paper/threat-defense-architecture-white-paper-en.pdf]

Key Takeaway: The CIA triad, Zero Trust, and regulatory compliance are not abstract concepts — they directly determine how a Cohesity environment is configured. Every security feature in the platform (encryption, RBAC, DataLock, Quorum, Security Advisor) exists to satisfy one or more of these foundational requirements.

Chapter Summary

The Cohesity Data Cloud represents a fundamental shift from fragmented, siloed data management to a unified, software-defined platform. Built on SpanFS — a masterless, distributed file system that provides multi-protocol access, global deduplication, and unlimited snapshots — the platform consolidates backup (DataProtect), file and object services (SmartFiles), and long-term archival (CloudArchive) into a single architecture that scales linearly by adding commodity nodes. Cloud services including FortKnox, CloudTier, CloudReplicate, and SiteContinuity extend this architecture into hybrid and multi-cloud environments.

Security on this platform is not an afterthought but a foundational design principle. The Threat Defense Architecture implements defense-in-depth across seven layers (from Human to Data) and organizes its capabilities into four pillars: Data Resiliency, Access Control, AI-Driven Detection and Analytics, and Extensibility. Security Advisor provides a continuous, quantitative feedback loop for measuring and improving security posture, available at no additional cost to all customers.

For COH350 exam preparation, understanding the platform architecture and Threat Defense model is prerequisite knowledge that every subsequent domain builds upon. System Hardening (22%), User & Access Management (17%), and Network Security (15%) collectively account for more than half the exam, and all three rely on the architectural concepts introduced in this chapter. The security fundamentals covered here — the CIA triad, Zero Trust, and the regulatory landscape — provide the conceptual vocabulary you will use throughout the rest of this textbook.

Key Terms

Chapter 2: Network Security

Learning Objectives

By the end of this chapter, you will be able to:

• Configure network protocol access controls on a Cohesity cluster
• Implement encryption for in-flight backup data using industry best practices
• Design network segmentation strategies for Cohesity deployments
• Apply firewall rules and network policies to secure Cohesity cluster communication

Introduction

If data protection is the vault, network security is every wall, door, and checkpoint between the outside world and that vault. A Cohesity cluster does not exist in isolation — it communicates with hypervisors, agents, cloud services, and administrators across dozens of network pathways. Each pathway is a potential attack surface. This chapter teaches you how to lock down those pathways using the controls Cohesity provides: firewall profiles, protocol restrictions, encryption, VLAN segmentation, and access policies.

Think of your Cohesity cluster as a hospital. Patients (backup data) need to move between rooms (source systems and the cluster), but you would never leave every door in the building unlocked. You restrict which hallways are open, require ID badges at checkpoints, and ensure that sensitive records are transported in sealed containers. Network security for Cohesity follows the same logic — control who can connect, encrypt what travels across the wire, and segment traffic so that a breach in one area cannot cascade into another.

Section 1: Controlling Network Protocol Access

Supported Network Protocols and Their Security Implications

A Cohesity cluster exposes several network protocols — standardized rules that govern how systems communicate over a network. Each protocol serves a specific data-access purpose and carries its own security profile:

Cohesity supports SMB, NFS, S3, and RPCSEC_GSS protocols for data access. [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/white-paper/cohesity-platform-security-white-paper-en.pdf] The key principle is simple: every enabled protocol is an open door. Your job is to ensure only the doors you need are open, and that each one has a lock.

Figure 2.1: Deny-by-Default Protocol Access Model

flowchart TD
    A[Fresh Cohesity Cluster] --> B[All Ports Disabled by Default]
    B --> C{Identify Required Protocols}
    C --> D[SMB Needed?]
    C --> E[NFS Needed?]
    C --> F[S3 Needed?]
    D -->|Yes| G[Enable SMB on specific interface group]
    D -->|No| H[Leave Disabled]
    E -->|Yes| I[Enable NFS on specific interface group]
    E -->|No| H
    F -->|Yes| J[Enable S3 with HTTPS enforcement]
    F -->|No| H
    G --> K[Apply IP Allowlist to permitted sources]
    I --> K
    J --> K
    K --> L[Hardened Cluster with Least-Privilege Access]

Disabling Unnecessary Protocols and Services

By default, all ports on a Cohesity cluster are disabled except for some known ports. Protocols like SNMP are not enabled by default and must be explicitly enabled by an administrator. [Source: https://docs.cohesity.com/baas/Setup/ManageRules.htm] This “deny-by-default” posture is a significant security advantage — it means a fresh Cohesity deployment starts in a hardened state rather than an open one.

Real-World Analogy: Imagine moving into a new office building where every window and door starts locked. You only unlock the front entrance and the loading dock because those are the only two entry points your business needs. A Cohesity cluster works the same way — you start locked down and selectively open only what is required.

Worked Example: Reviewing and Disabling Protocols

Suppose your organization uses only VMware for virtualization and Windows file servers. Your Cohesity cluster does not need NFS access enabled for end users. To review and adjust protocols:

1. Navigate to Settings > Networking in the Cohesity Dashboard
2. Click the Firewall tab to view all supported firewall profiles
3. Identify profiles related to NFS access
4. Set the profile rule to Deny for NFS on interface groups that face end-user networks
5. Leave NFS enabled only on interface groups used for internal backup traffic if required

This ensures that even if an attacker gains access to the user-facing network segment, they cannot attempt NFS-based exploits against the cluster.

Network Interface Configuration and VLAN Segmentation

VLAN segmentation — the practice of dividing a physical network into multiple isolated virtual local area networks — is fundamental to Cohesity deployment security. Cohesity supports VLAN tagging on its network interfaces, allowing administrators to separate different types of traffic.

In Cohesity’s architecture, the management (MGMT) IP addresses and virtual IP (VIP) addresses can reside in the same VLAN or different VLANs. However, all MGMT IPs must be in the same VLAN, and all VIPs must be in the same VLAN. All nodes of a Cohesity cluster need to be part of a single, layer-2 network. [Source: https://www.cohesity.com/resource-assets/reference-architecture/Optimal-Network-Designs-with-Cohesity-RA.pdf]

In multi-tenant environments, Views, VLANs, and Sources are isolated per tenant, ensuring that one tenant’s backup traffic cannot be observed or intercepted by another. [Source: https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/UCS_CVDs/ucs_xseries_cohesity.html]

Table: Recommended VLAN Separation Strategy

IP Allowlisting and Deny-Listing for Cluster Access

IP allowlisting is the practice of explicitly specifying which IP addresses or subnets are permitted to access a resource — everything not on the list is denied. Cohesity provides IP allowlisting at two levels:

1. Global allowlist: Applies to all Views in the cluster that do not have their own individual allowlist
2. Per-View allowlist: Applies only to a specific View, and supersedes the global allowlist when the “Override Global IP Allowlist” toggle is enabled

[Source: https://docs.cohesity.com/baas/Dashboard/Platform/ViewsSpecifyWhitelistedSubnets.htm]

Only systems with IP addresses in the subnets listed in a View’s allowlist have privileges to access and mount that View. Subnets are specified in CIDR format — for example, 10.0.0.0/24 for IPv4 or FE80:CD00::211E:729C/60 for IPv6. [Source: https://docs.cohesity.com/baas/Dashboard/Platform/view-options.htm]

Figure 2.2: IP Allowlist Hierarchy — Global vs Per-View

flowchart TD
    A[Incoming Access Request to a View] --> B{View has Override Global Allowlist enabled?}
    B -->|Yes| C[Check Per-View Allowlist]
    B -->|No| D[Check Global Allowlist]
    C --> E{Source IP in Per-View Allowlist?}
    D --> F{Source IP in Global Allowlist?}
    E -->|Yes| G[Access Granted]
    E -->|No| H[Access Denied]
    F -->|Yes| G
    F -->|No| H

Worked Example: Configuring a View-Level Allowlist

Your finance team stores sensitive backup data in a Cohesity View called “Finance-Backups.” Only two subnets should have access: the finance application servers (10.20.30.0/24) and the backup admin workstations (10.20.40.0/28).

1. Navigate to Data Protection > Views and select “Finance-Backups”
2. Open the View’s settings and locate the IP Allowlist section
3. Toggle Override Global IP Allowlist to On
4. Click Add Allowlist and enter 10.20.30.0/24
5. Add a second entry for 10.20.40.0/28
6. Save the configuration

Now, even if a compromised machine on the 10.20.50.0/24 engineering subnet attempts to mount this View, the request will be denied. The View-level allowlist acts as a network-layer gatekeeper independent of user authentication.

As a complementary measure, configure firewall profiles to allow only the IP addresses of systems that need to access the Cohesity cluster web UI for HTTP/HTTPS traffic. [Source: https://www.scribd.com/document/794868665/Cohesity-Best-Practice-Security-Hardening-Guide]

Key Takeaway: Cohesity follows a deny-by-default posture where all ports start disabled. Secure your cluster by enabling only the protocols you need, segmenting traffic across VLANs, and applying IP allowlists at both the global and per-View levels to enforce least-privilege network access.

Section 2: Securing In-Flight Backup Data

TLS Encryption for Data-in-Transit

TLS encryption (Transport Layer Security) is the cryptographic protocol that secures data as it moves across a network — referred to as data-in-transit encryption. Without it, backup data traveling between a source server and the Cohesity cluster could be intercepted and read by anyone with access to the network path.

All access methods to the Cohesity cluster require an SSL connection that uses TLS 1.2 or above, with strong ciphers for the established session. Cohesity utilizes TLS 1.2 and mTLS (mutual TLS) protocols for transport layer security with only FIPS-approved cipher suites with Perfect Forward Secrecy (PFS) protection. [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/white-paper/cohesity-platform-security-white-paper-en.pdf]

What is Perfect Forward Secrecy? PFS ensures that even if a server’s private key is compromised in the future, previously recorded encrypted sessions cannot be decrypted. Each session generates a unique ephemeral key. Think of it like using a different combination on a lock each time you open the vault — stealing today’s combination gives you nothing from yesterday’s session.

What is mutual TLS (mTLS)? Standard TLS verifies only the server’s identity to the client. mTLS goes further — both the client and server present certificates and verify each other’s identity. Cohesity uses mTLS for communication between Hybrid Extender VMs and the cluster, securing the gRPC communication channel. [Source: https://www.cohesity.com/blogs/enhancing-data-security-in-the-cloud/]

Figure 2.3: TLS vs mTLS Authentication Flow

sequenceDiagram
    participant Client
    participant Server

    Note over Client,Server: Standard TLS (one-way verification)
    Client->>Server: ClientHello (supported ciphers, TLS version)
    Server->>Client: ServerHello + Server Certificate
    Client->>Client: Verify Server Certificate against CA
    Client->>Server: Encrypted session key (PFS ephemeral key)
    Server->>Client: Session established

    Note over Client,Server: mTLS (mutual verification)
    Client->>Server: ClientHello
    Server->>Client: ServerHello + Server Certificate + Request Client Certificate
    Client->>Client: Verify Server Certificate
    Client->>Server: Client Certificate + Encrypted session key
    Server->>Server: Verify Client Certificate against CA
    Server->>Client: Mutual trust established, session active

Table: TLS Configuration at a Glance

Certificate Management and Rotation

Certificate management refers to the lifecycle of digital certificates used to establish encrypted connections — from creation through renewal and replacement.

When a Cohesity cluster is created, a self-signed X.509 certificate in PEM format is automatically generated. The certificate’s “Common Name” field is set to the server’s hostname (for example, a VIP’s DNS name). Certificates are stored on the boot disk and replicated to other nodes as part of cluster formation using RPC calls. [Source: https://helios.cohesity.com/docs/UserGuide/Content/Concepts/SecurityFeatures.htm]

Users can import new certificates to replace the auto-generated self-signed certificate according to their company policy. This is an important step for production environments because:

• Self-signed certificates trigger browser warnings and cannot be verified by external certificate authorities
• Enterprise PKI (Public Key Infrastructure) policies typically require certificates signed by an internal or public CA
• Automated certificate rotation reduces the risk of expired certificates causing service disruptions

Real-World Analogy: A self-signed certificate is like printing your own employee ID badge. It works for getting through your own building’s doors, but no other organization will trust it. A CA-signed certificate is like a government-issued passport — it is universally trusted because a recognized authority vouches for your identity.

Worked Example: Replacing the Default Certificate

1. Generate a Certificate Signing Request (CSR) with the Cohesity cluster’s VIP DNS name as the Common Name
2. Submit the CSR to your organization’s Certificate Authority
3. Receive the signed certificate and any intermediate CA certificates
4. In the Cohesity Dashboard, navigate to Settings > Security > Certificates
5. Upload the signed certificate (PEM format), the private key, and any intermediate certificates
6. The cluster will apply the new certificate and re-establish all SSL sessions

Plan to rotate certificates before expiration — most organizations enforce a 1-year or 2-year maximum certificate lifetime.

Encryption Between Source and Cohesity Cluster

Data moving between source systems (VMware hosts, physical servers, NAS devices) and the Cohesity cluster must be encrypted to prevent interception. The specific encryption mechanism depends on the connection type:

The Cohesity cluster is FIPS 140-2 certified — not merely compliant. The distinction matters: “FIPS-compliant” has no formal meaning, while FIPS certification requires the encryption module to be validated by a third-party federal laboratory through NIST. The encryption module on Cohesity always operates in FIPS mode. [Source: https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp4922.pdf]

Key Takeaway: Cohesity enforces TLS 1.2 or above with FIPS-approved cipher suites and Perfect Forward Secrecy on all connections. Replace the default self-signed certificate with a CA-signed certificate for production environments, and leverage mTLS for cloud and hybrid connectivity.

Section 3: Network Architecture Best Practices

Network Segmentation for Management, Data, and Replication Traffic

Effective network segmentation separates traffic types so that a compromise or congestion event in one zone does not affect others. For Cohesity deployments, three primary traffic categories should be segmented:

1. Management traffic — Administrative access to the Cohesity UI, API calls, and cluster configuration
2. Data traffic — Backup and restore data flows between source systems and the cluster
3. Replication traffic — Data replication between clusters for disaster recovery

Real-World Analogy: Consider a modern airport. Passengers (data traffic) move through terminals, staff (management traffic) use restricted corridors, and cargo (replication traffic) travels through a completely separate logistics network. A security incident in the passenger terminal does not shut down cargo operations because the paths are physically and logically separated.

All MGMT IPs must reside in the same VLAN, and all VIPs must reside in the same VLAN, though MGMT and VIP VLANs can differ. All cluster nodes require layer-2 connectivity between them. [Source: https://www.cohesity.com/resource-assets/reference-architecture/Optimal-Network-Designs-with-Cohesity-RA.pdf]

Figure 2.4: Cohesity Network Segmentation Architecture

flowchart TD
    subgraph MgmtVLAN["Management VLAN 100"]
        A1[Admin Workstations]
        A2[API Clients]
        A3[Monitoring Tools]
    end

    subgraph DataVLAN["Data VLAN 200"]
        B1[VMware Hosts]
        B2[Physical Agents]
        B3[NAS Devices]
    end

    subgraph ReplVLAN["Replication VLAN 300"]
        C1[DR Cluster]
        C2[Remote Sites]
    end

    subgraph ClientVLAN["Client Access VLAN 400"]
        D1[NFS/SMB Clients]
        D2[S3 Applications]
    end

    subgraph Cluster["Cohesity Cluster (Layer-2)"]
        N1[Node 1]
        N2[Node 2]
        N3[Node 3]
    end

    A1 -->|HTTPS 443| Cluster
    A2 -->|REST API 443| Cluster
    B1 -->|VADP 902| Cluster
    B2 -->|Agent 50051| Cluster
    B3 -->|NFS 2049 / SMB 445| Cluster
    Cluster -->|TLS 443, 11111, 11114| C1
    D1 -->|NFS/SMB| Cluster
    D2 -->|S3 HTTPS| Cluster

+--------------------------------------------------+
|              Network Segmentation                 |
|                                                   |
|  [Management VLAN 100]    [Data VLAN 200]         |
|   - Admin workstations     - VMware hosts         |
|   - API clients            - Physical agents      |
|   - Monitoring tools       - NAS devices          |
|        |                        |                 |
|        +-------+  +-------------+                 |
|                |  |                                |
|          +-----v--v------+                        |
|          | Cohesity      |                        |
|          | Cluster       |                        |
|          | (All nodes    |                        |
|          |  Layer-2)     |                        |
|          +------+--------+                        |
|                 |                                  |
|        [Replication VLAN 300]                     |
|         - DR cluster                              |
|         - Remote sites                            |
+--------------------------------------------------+

Firewall Port Requirements and Security Zones

Firewall rules define which network traffic is permitted or denied based on source, destination, port, and protocol. Cohesity uses application-based firewall profiles that define whether data from specific applications, ports, protocols, and IP sets are allowed or denied through one or more interface groups. [Source: https://docs.cohesity.com/baas/Setup/ManageRules.htm]

The following tables detail the critical ports required for Cohesity cluster communication:

Core Cluster and Replication Ports

[Source: https://docs.cohesity.com/disaster-recovery/site-continuity/vmware-vms/initial-setup/firewall-ports.htm]

Workload-Specific Ports

[Source: https://docs.cohesity.com/baas/data-protect/dataprotect-firewall-ports.htm]

Infrastructure Services Ports

[Source: https://docs.cohesity.com/baas/Setup/OpenPorts.htm]

Worked Example: Building a Firewall Rule Set

Your security team requires explicit firewall rules for a new Cohesity deployment. Start by mapping traffic flows:

1. Management zone to cluster: Allow TCP 443 inbound from admin subnets only
2. Source systems to cluster: Allow TCP 443 (vCenter), TCP 902 (ESXi), and TCP 50051 (agents) from source subnets
3. Cluster to DR cluster: Allow TCP 443, 11111, 11114, and 24444 bidirectionally between cluster subnets
4. Cluster to infrastructure: Allow UDP 53 to DNS servers, UDP 123 to NTP servers
5. Deny all other traffic: Default deny rule at the bottom of each firewall policy

On the Cohesity side, navigate to Settings > Networking > Firewall and configure profiles to mirror these rules, specifying the appropriate interface groups and custom IP/subnet entries. [Source: https://docs.cohesity.com/baas/Setup/ManageRules.htm]

DNS and NTP Security Considerations

DNS and NTP may seem like mundane infrastructure services, but their compromise can undermine the entire security posture of a Cohesity deployment:

• DNS poisoning could redirect the cluster’s replication traffic to a malicious endpoint or prevent the cluster from reaching Cohesity cloud services (helios.cohesity.com)
• NTP manipulation could cause certificate validation failures (expired or not-yet-valid certificates) or corrupt backup scheduling logic

Best practices:

• Use internal, hardened DNS servers and restrict DNS queries (port 53) to those servers only
• Configure at least two NTP sources for redundancy, and restrict NTP traffic (ports 123/323) to trusted time servers
• Monitor for DNS and NTP anomalies as part of your SIEM integration

Key Takeaway: Segment Cohesity network traffic into management, data, and replication zones. Open only the specific ports each traffic flow requires, apply firewall profiles on the cluster itself, and do not overlook DNS and NTP as critical security dependencies.

Section 4: Secure Remote Access

VPN and SSH Access to Cohesity Clusters

Remote access to a Cohesity cluster should always traverse encrypted channels. Two primary methods exist:

1. VPN (Virtual Private Network): Administrators connect to the corporate network via VPN before accessing the Cohesity management interface over HTTPS (port 443). This ensures the management traffic never traverses the public internet unencrypted.

2. SSH (Secure Shell): Direct SSH access to Cohesity cluster nodes is available for advanced CLI operations. The Cohesity CLI can be used to configure firewall rules, manage cluster settings, and troubleshoot issues that cannot be resolved through the web UI. [Source: https://docs.cohesity.com/baas/Setup/ManageRules.htm]

Best practices for SSH access:

• Restrict SSH access to a dedicated management VLAN or jump host
• Use key-based authentication instead of passwords where possible
• Log all SSH sessions for audit purposes
• Disable SSH access when not actively needed for troubleshooting

Real-World Analogy: SSH access is like having a master key to the building. It gives you access to rooms (cluster nodes) that the regular entrance (web UI) does not reach. Because of this power, you keep the master key in a locked safe (jump host behind VPN) and log every time it is used.

Cohesity Support Channel Security

Cohesity provides a support channel that allows Cohesity support engineers to remotely access your cluster for troubleshooting. This channel connects via SSH or HTTPS (port 22 or 443) to rt.cohesity.com. [Source: https://docs.cohesity.com/baas/data-protect/dataprotect-firewall-ports.htm]

Key security controls for the support channel:

Organizations with strict security requirements should establish a policy that requires change-management approval before enabling the support channel, and that mandates disabling it within a defined time window after the support case is resolved.

API Access Security and Token Management

The Cohesity REST API provides programmatic access to all cluster functions — backup configuration, restore operations, reporting, and cluster management. Securing API access is critical because automated scripts and integrations often operate with elevated privileges.

An API token is a credential that authenticates an API request without requiring a username and password for each call. Cohesity API access occurs over HTTPS (port 443), inheriting the TLS 1.2+ encryption that protects all cluster communication. [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/white-paper/cohesity-platform-security-white-paper-en.pdf]

Best practices for API token management:

1. Least privilege: Create dedicated API service accounts with only the RBAC permissions required for the integration’s purpose
2. Token rotation: Rotate API tokens on a regular schedule; do not use long-lived tokens
3. IP restriction: Combine API access with IP allowlisting so that tokens can only be used from authorized source systems
4. Secure storage: Store API tokens in a secrets manager (e.g., HashiCorp Vault, AWS Secrets Manager) rather than in plaintext configuration files
5. Audit API calls: Monitor API usage logs for anomalous patterns — unexpected source IPs, unusual hours, or bulk data-access requests

Worked Example: Securing an Automation Integration

Your team has a Python script that runs nightly to pull backup status reports from the Cohesity API. To secure this integration:

1. Create a dedicated Cohesity user account named svc-backup-reporter with a read-only RBAC role
2. Generate an API token for this account
3. Store the token in your organization’s secrets manager
4. Configure the Cohesity firewall profile to allow HTTPS access from the automation server’s IP only
5. Add the automation server’s subnet to the cluster’s IP allowlist
6. Set a calendar reminder to rotate the token quarterly
7. Forward API audit logs to your SIEM for monitoring

This layered approach ensures that even if the token is leaked, the attacker must also originate from the correct IP address, and the read-only permissions limit the blast radius.

Figure 2.5: Secure Remote Access Paths to Cohesity Cluster

flowchart LR
    subgraph External["External Network"]
        Admin[Administrator]
        Script[Automation Server]
        Support[Cohesity Support]
    end

    subgraph SecurityLayer["Security Controls"]
        VPN[VPN Gateway]
        JumpHost[Jump Host]
        FW[Firewall / IP Allowlist]
    end

    subgraph Cluster["Cohesity Cluster"]
        WebUI[Web UI - HTTPS 443]
        CLI[CLI - SSH 22]
        API[REST API - HTTPS 443]
        SupportCh[Support Channel - 22/443]
    end

    Admin -->|Encrypted tunnel| VPN
    VPN -->|Mgmt VLAN| WebUI
    Admin -->|SSH via| JumpHost
    JumpHost -->|Restricted access| CLI
    Script -->|Token + IP allowlist| FW
    FW -->|HTTPS| API
    Support -->|Time-limited, admin-enabled| SupportCh

Key Takeaway: Secure all remote access paths — VPN for administrators, controlled SSH via jump hosts, time-limited support channels, and API tokens with least-privilege RBAC, IP restrictions, and regular rotation.

Chapter Summary

Network security for Cohesity deployments is built on four pillars:

1. Protocol access control — Start from Cohesity’s deny-by-default posture and enable only the protocols and ports your environment requires. Apply IP allowlists at both the global and per-View levels.

2. In-flight encryption — All Cohesity communication is protected by TLS 1.2+ with FIPS-approved cipher suites and Perfect Forward Secrecy. Replace self-signed certificates with CA-signed certificates and use mTLS for cloud and hybrid connections.

3. Network architecture — Segment management, data, and replication traffic into separate VLANs. Define explicit firewall rules for each traffic flow and harden DNS/NTP infrastructure.

4. Secure remote access — Protect administrative access through VPNs and controlled SSH, govern the Cohesity support channel with time-limited policies, and secure API integrations with token management and least-privilege service accounts.

Together, these controls implement a defense-in-depth strategy aligned with Cohesity’s Zero Trust security model, which encompasses in-flight and at-rest encryption, WORM immutability, RBAC, and MFA. [Source: https://www.cohesity.com/blogs/keeping-data-secure-with-cohesity/]

Key Terms

Chapter 3: System Hardening — WORM Storage & Encryption

Learning Objectives

By the end of this chapter, you will be able to:

• Configure WORM (Write Once Read Many) storage policies on Cohesity for immutable backups
• Implement data-at-rest encryption using Cohesity’s built-in and external KMS options
• Differentiate between DataLock and legal hold mechanisms
• Design encryption key management strategies using internal KMS and external KMIP servers

3.1 WORM Storage Technology

Imagine writing something in permanent ink on a page that has been laminated — you can read it as many times as you like, but nobody can erase or overwrite what was written. That is the core idea behind WORM (Write Once Read Many) storage: once data is committed, it becomes immutable for a defined retention period. In the context of backup infrastructure, WORM is the single most important technology for defending against ransomware, because even an attacker who gains administrative access to your environment cannot delete or encrypt backup copies that are WORM-protected.

3.1.1 WORM Concepts and Immutability for Ransomware Protection

Traditional backup systems rely on access controls to prevent unauthorized deletion. The problem is that access controls can be compromised — a stolen administrator credential gives an attacker the power to delete every backup in the environment. WORM flips this model: instead of relying solely on who can delete data, WORM makes it so nobody can delete data until a retention clock expires.

Cohesity’s immutability story begins at the filesystem layer. The platform is built on SpanFS, an immutable file system that stores all backup snapshots in a read-only state within internal Views that are inaccessible from outside the Cohesity cluster. Every incremental backup and clone is written to a zero-cost clone that is marked read-only upon completion of each Protection Run. When a mount-based restore is requested, the system clones the internal view before exposing it externally, keeping the original snapshot untouched. [Source: https://www.cohesity.com/blogs/how-backup-immutability-defends-against-ransomware-attacks/]

This architectural foundation means that even before you enable any WORM policy, Cohesity snapshots already have a baseline level of protection. Writes to internal views are permitted only through trusted internal services and authenticated APIs, and granular Role-Based Access Control (RBAC) prevents unauthorized access. [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/white-paper/threat-defense-architecture-white-paper-en.pdf]

Cohesity frames ransomware defense as a three-part strategy:

[Source: https://www.cohesity.com/solutions/ransomware/]

WORM is the cornerstone of the “Prevent” phase. Without it, the Detect and Respond phases have nothing to work with if an attacker has already destroyed backup data.

Figure 3.1: Cohesity ransomware defense phases

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

3.1.2 Cohesity DataLock for Backup Immutability

DataLock is Cohesity’s implementation of WORM for backup snapshots. When enabled, DataLock applies a role-based lock to selected backup snapshots, storing them in WORM format with a “Lock Until” retention expiration date. During the retention period, the backup snapshot cannot be deleted by anyone — including cluster administrators. [Source: https://docs.cohesity.com/baas/Dashboard/Protection/datalock.htm]

Think of DataLock like a time-locked safe in a bank vault. The bank manager (cluster administrator) can manage many aspects of the vault, but even they cannot open the safe until the timer expires. Only a specially designated officer — in Cohesity’s case, a user with the Data Security RBAC role — can add, modify, or remove DataLock policies. This separation of duties is a critical security control: it means that compromising the cluster administrator account alone is not sufficient to destroy WORM-protected backups. [Source: https://www.cohesity.com/blogs/how-backup-immutability-defends-against-ransomware-attacks/]

Worked Example: Enabling DataLock on a Protection Policy

Consider a healthcare organization that must retain daily backups for 30 days in an immutable state. The workflow would be:

1. A user with the Data Security role navigates to the Protection Policy settings.
2. They enable DataLock on the policy and set the retention period to 30 days.
3. Each time a Protection Run completes, the resulting snapshot is automatically locked with a “Lock Until” date 30 days in the future.
4. During those 30 days, no user — regardless of role — can delete or modify the snapshot.
5. After 30 days, the lock expires and normal retention policies take effect.

Figure 3.2: DataLock protection workflow

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

3.1.3 Configuring WORM Retention Policies: Compliance Mode vs. Enterprise Mode

Cohesity DataLock offers two distinct modes, each designed for different organizational requirements:

[Source: https://docs.cohesity.com/baas/NAS/NASFileDataLock.htm]

Compliance mode is the most restrictive option. It protects WORM files at the disk level, and Cohesity’s implementation has been assessed as compliant with SEC Rule 17a-4(f), FINRA Rule 4511(c), and CFTC Regulation 1.31(c)-(d) by Cohasset Associates, an independent assessor specializing in records management compliance. [Source: https://www.cohesity.com/resource-assets/third-party-reports/Cohesity-Cohasset-Assoc-Assessment-Report2017.pdf]

Enterprise mode provides a more flexible approach. While files still cannot be modified by any user, a root user retains the ability to delete files during or after the retention period. This makes Enterprise mode suitable for organizations that need immutability as a security control but do not have strict regulatory requirements mandating absolute non-deletion.

A critical detail to remember: switching from Enterprise mode to Compliance mode is supported, but switching from Compliance mode back to Enterprise mode is not supported. This is intentional — if regulators require Compliance mode, it would be a violation to allow downgrading to a less restrictive mode. Plan your mode selection carefully before deployment. [Source: https://www.penguinpunk.net/blog/cohesity-is-datalocked-in/]

Figure 3.3: DataLock mode transition rules

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

    state EnterpriseMode {
        direction LR
        e1: File-level WORM
        e2: Root can delete
        e3: Admin or Data Security role manages
    }

    state ComplianceMode {
        direction LR
        c1: Disk-level WORM
        c2: No user can delete
        c3: Data Security role only
    }

3.1.4 DataLock vs. Legal Hold: Use Cases and Differences

Both DataLock and legal hold prevent the deletion of backup snapshots, but they serve fundamentally different purposes and operate through different mechanisms.

DataLock is policy-driven and time-bound. When a DataLock policy is applied, every snapshot that matches the policy automatically receives a retention lock with a defined expiration date. Once the lock expires, normal retention and garbage collection resume. DataLock is proactive — it is configured before data is created.

Legal hold is event-driven and indefinite. A user with the Data Security role manually places a legal hold on specific existing snapshots (Protection Runs) to preserve them for legal or investigative purposes. A legal hold prevents the snapshot from being deleted even after its normal retention period expires. The hold remains in effect indefinitely until it is explicitly removed by an authorized user. [Source: https://docs.cohesity.com/baas/Dashboard/Protection/datalock.htm]

Real-world analogy: DataLock is like a lease on an apartment — the terms are set when you sign, and the lock-in period is predetermined. Legal hold is like a court injunction — it is imposed after the fact, applies to specific items, and remains until the court lifts it.

Figure 3.4: DataLock vs. Legal Hold lifecycle comparison

flowchart TD
    subgraph DataLock["DataLock (Policy-Driven)"]
        direction TB
        DL1["Policy configured\n(proactive)"] --> DL2["Protection Run\ncreates snapshot"]
        DL2 --> DL3["Lock auto-applied\nwith expiration date"]
        DL3 --> DL4["Retention period\n(DELETE DENIED)"]
        DL4 --> DL5["Lock expires\nNormal cleanup resumes"]
    end

    subgraph LegalHold["Legal Hold (Event-Driven)"]
        direction TB
        LH1["Snapshot already exists"] --> LH2["Litigation or\ninvestigation event"]
        LH2 --> LH3["Data Security user\nplaces legal hold"]
        LH3 --> LH4["Indefinite hold\n(DELETE DENIED)"]
        LH4 --> LH5["Authorized user\nexplicitly removes hold"]
    end

    style DataLock fill:#f0f4f8,stroke:#264653
    style LegalHold fill:#fdf6ec,stroke:#b08c2a

Key Takeaway: WORM storage with DataLock ensures that backup data cannot be deleted or modified by anyone — including administrators — for a defined retention period. Compliance mode meets SEC/FINRA/CFTC regulatory requirements, while Enterprise mode offers more administrative flexibility. Legal hold complements DataLock by providing indefinite preservation of specific snapshots for legal purposes.

3.2 Data-at-Rest Encryption

If WORM storage protects backup data from being deleted, encryption protects it from being read. Even if an attacker physically steals a hard drive from a data center, encrypted data is unreadable without the correct decryption keys. Cohesity provides comprehensive data-at-rest encryption as a standard feature of its platform.

3.2.1 Cohesity Encryption Architecture and AES-256 Implementation

Cohesity encrypts all data at rest using AES-256-GCM (Advanced Encryption Standard, 256-bit keys, Galois/Counter Mode). AES-256 is the gold standard for symmetric encryption — it is the same algorithm used by governments and financial institutions worldwide to protect classified information. The “256” refers to the key length in bits, which provides 2^256 possible keys — a number so large that brute-force attacks are computationally infeasible with any current or foreseeable technology. [Source: https://www.cohesity.com/blogs/keeping-data-secure-with-cohesity/]

The GCM (Galois/Counter Mode) component is equally important. GCM is an authenticated encryption mode, meaning it simultaneously provides confidentiality (the data is unreadable without the key) and integrity (any tampering with the encrypted data is detectable). This is a stronger guarantee than encryption modes that provide only confidentiality.

Cohesity’s encryption implementation is FIPS 140-2 Level 2 certified, which means it has been validated by the National Institute of Standards and Technology (NIST) to meet federal security requirements. This certification is often a prerequisite for government agencies and regulated industries. [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/white-paper/cohesity-platform-security-white-paper-en.pdf]

Enabling encryption on a Cohesity cluster is straightforward — it requires selecting a single checkbox during cluster setup. Once enabled, all data written to the cluster is automatically encrypted.

3.2.2 Software-Based vs. Hardware-Based Encryption

Cohesity takes a hybrid approach to encryption that combines software-based encryption with hardware acceleration:

Software-based encryption is the primary mechanism. The encryption and decryption operations run in software on the cluster nodes, using Intel processor hardware acceleration (AES-NI instructions) to achieve encryption speeds of several GB/s with minimal performance impact. A key advantage of software-only encryption is that it removes hardware component dependency — customers can upgrade or replace storage drives without affecting their FIPS certification status. [Source: https://www.cohesity.com/blogs/keeping-data-secure-with-cohesity/]

Self-encrypting drives (SEDs) provide an additional hardware encryption layer. SEDs encrypt data as it is written to the physical disk using dedicated encryption hardware built into the drive. This creates a defense-in-depth approach: even if the software encryption layer were somehow bypassed, the SED layer would still protect data on the physical media.

Think of this like a double-envelope system for mailing sensitive documents: the document is sealed in an inner encrypted envelope (software encryption), which is then placed inside an outer encrypted envelope (SED). An attacker would need to defeat both layers to access the data.

3.2.3 Encryption Scope: Cluster-Level and Storage Domain-Level

Cohesity manages encryption keys at the View Box (storage domain) level. A View Box is a logical storage division within a Cohesity cluster, and each View Box maintains its own independent set of encryption keys. This design provides workload isolation — if one View Box’s keys were somehow compromised, data in other View Boxes would remain protected. [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/white-paper/cohesity-platform-security-white-paper-en.pdf]

This per-View-Box key management is particularly valuable in multi-tenant environments or organizations with strict data segregation requirements. For example, a managed service provider hosting backup data for multiple clients can ensure that each client’s data is encrypted with separate keys, providing cryptographic isolation between tenants.

Key Takeaway: Cohesity encrypts all data at rest using AES-256-GCM with FIPS 140-2 Level 2 certification. The hybrid software-plus-hardware approach delivers high-speed encryption with minimal performance impact. Encryption keys are managed independently per View Box, providing workload isolation across storage domains.

3.3 Key Management

Encryption is only as strong as the protection of the keys used to encrypt and decrypt data. If an attacker obtains the encryption keys, the encryption itself becomes meaningless. Key management — the processes and infrastructure for generating, storing, rotating, and recovering encryption keys — is therefore one of the most critical aspects of any encryption strategy.

3.3.1 Internal Key Management Service (KMS)

By default, the Cohesity cluster includes a built-in Internal Key Management Service (KMS) that automatically generates encryption keys and stores them as encrypted keys on the cluster’s SSDs. This is the simplest option and requires no additional infrastructure or configuration beyond enabling encryption. [Source: https://www.cohesity.com/blogs/keeping-data-secure-with-cohesity/]

The internal KMS is appropriate for organizations that:

• Are getting started with Cohesity encryption and want a zero-overhead solution
• Do not have regulatory requirements mandating external key management
• Have a single-cluster deployment where key distribution across systems is not a concern

However, the internal KMS has an inherent limitation: the encryption keys reside on the same system as the encrypted data. This is analogous to locking your house and leaving the key under the doormat — it provides protection against casual access but not against a determined attacker who gains full access to the system. For higher security requirements, external KMS is recommended.

3.3.2 External KMS Integration via KMIP Protocol

For organizations requiring stronger separation between encrypted data and encryption keys, Cohesity supports integration with external key management systems through the KMIP (Key Management Interoperability Protocol) standard. KMIP is an industry-standard protocol that enables communication between encryption systems and key management servers, regardless of vendor. [Source: https://docs.cohesity.com/baas/KMS/External_KMS.htm]

Cohesity supports the following KMIP-compliant external KMS vendors:

• Thales (CipherTrust Manager)
• Fortanix (Data Security Manager)
• Entrust (KeyControl)
• HashiCorp (Vault)
• IBM (SGKLM — Security Guardium Key Lifecycle Manager)

[Source: https://support.fortanix.com/docs/using-fortanix-data-security-manager-for-cohesity-encryption-keys]

For cloud deployments, Cohesity also integrates with cloud-native KMS services:

• AWS KMS (Key Management Service)
• Azure Key Vault
• GCP KMS (Google Cloud Key Management Service)

[Source: https://docs.cohesity.com/baas/data-protect/self-managedKMS-AWS.htm]

For high availability, you can configure a KMS cluster of up to four key management services, ensuring that encryption key access is not a single point of failure. [Source: https://docs.cohesity.com/baas/KMS/External_KMS.htm]

The DEK/KEK Architecture

When an external KMS is configured, Cohesity uses a two-tier key architecture that separates concerns between the cluster and the external KMS:

+---------------------+         +-------------------+
|   Cohesity Cluster  |         |   External KMS    |
|                     |         |                   |
|  EDEK (encrypted)   | <-----> |  KEK (master key) |
|  KEK ID (pointer)   |  KMIP   |                   |
+---------------------+         +-------------------+

Decryption Flow:
1. Service requests data access
2. Cluster sends KEK ID to External KMS
3. External KMS returns KEK
4. Cluster uses KEK to decrypt EDEK -> DEK
5. DEK decrypts the actual data

• DEK (Data Encryption Key): The key that directly encrypts and decrypts data. It is generated by the cluster.
• EDEK (Encrypted Data Encryption Key): The DEK encrypted with the KEK. Stored locally on the cluster.
• KEK (Key Encryption Key): The master key that encrypts/decrypts the DEK. Managed by the external KMS.
• KEK ID: A pointer stored on the cluster that identifies which KEK to request from the external KMS.

[Source: https://www.fortanix.com/resources/solution-briefs/securing-cohesity-data-at-rest-encryption-with-fortanix-data-security-manager]

Figure 3.5: DEK/KEK decryption flow with external KMS

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 from local storage
    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 for limited period
    Note over Cluster: Subsequent reads use cached DEK

To minimize latency, Cohesity implements key caching within cluster services. The DEK is cached in-memory on the cluster node for a limited period, reducing the frequency of calls to the external KMS. After the cache expires, a fresh request to the external KMS is required. This balance between security and performance ensures that the external KMS does not become a throughput bottleneck. [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/white-paper/cohesity-platform-security-white-paper-en.pdf]

Worked Example: Configuring External KMS with Fortanix

An enterprise security team wants to centralize key management using Fortanix Data Security Manager:

1. Deploy and configure the Fortanix DSM appliance (or SaaS instance).
2. In the Cohesity UI, navigate to the KMS configuration page and select “Add External KMS.”
3. Enter the Fortanix KMIP endpoint address, port, and TLS certificates for mutual authentication.
4. Test the connection to verify KMIP communication.
5. Assign the external KMS to the desired View Boxes (storage domains).
6. The Cohesity cluster generates DEKs locally, encrypts them with the KEK from Fortanix, and stores the resulting EDEKs on-cluster.
7. All subsequent data encryption/decryption operations follow the DEK/KEK flow described above.

3.3.3 Key Rotation Policies and Procedures

Key rotation is the practice of periodically replacing encryption keys with new ones. This limits the exposure if a key is compromised — an attacker who obtains an old key can only access data encrypted with that specific key, not data encrypted with subsequent keys.

Cohesity’s default key rotation interval is 90 days, though this is configurable to meet organizational security policies. When key rotation occurs: [Source: https://www.cohesity.com/blogs/keeping-data-secure-with-cohesity/]

• All old encryption keys used by the cluster are replaced by a new set of keys
• Data is not re-encrypted — existing data on the cluster remains encrypted with the keys that were active when the data was originally written
• Only new writes use the new keys

This approach is important for performance: re-encrypting potentially petabytes of existing data every 90 days would be operationally prohibitive. The trade-off is that older data remains protected by older keys. If an older key is compromised, only the data encrypted with that key is at risk.

For cloud deployments using AWS KMS, DEKs are rotated every 4 hours, providing a more aggressive rotation cadence suited to cloud environments. [Source: https://docs.cohesity.com/baas/data-protect/self-managedKMS-AWS.htm]

3.3.4 Key Escrow and Disaster Recovery for Encryption Keys

A worst-case scenario for any encrypted system is losing access to the encryption keys. If the keys are lost, the encrypted data becomes permanently unrecoverable — no amount of technical effort can recover data encrypted with AES-256 without the correct key.

Key disaster recovery strategies include:

• Internal KMS: Keys are stored on cluster SSDs. Cluster replication and backup of cluster configuration provide key redundancy. However, if the entire cluster is destroyed without replication, keys may be lost.
• External KMS: Keys are stored on a separate, dedicated key management infrastructure with its own backup, replication, and high availability mechanisms. This is inherently more resilient because key storage is decoupled from data storage.
• KMS cluster configuration: Deploying up to four KMS servers ensures key availability even if one or more KMS servers fail. [Source: https://docs.cohesity.com/baas/KMS/External_KMS.htm]

For organizations using external KMS, the key management server itself should be treated as critical infrastructure with its own disaster recovery plan, including geographic redundancy and documented recovery procedures.

Key Takeaway: Cohesity offers internal KMS for simplicity and external KMS via KMIP for stronger security separation. The DEK/KEK architecture ensures that encryption keys are never stored in plaintext alongside encrypted data when using external KMS. Key rotation defaults to 90 days, and data is not re-encrypted during rotation. Plan your key disaster recovery strategy carefully — lost keys mean permanently lost data.

3.4 Immutability Best Practices

Understanding WORM technology and encryption is necessary but not sufficient. Effective system hardening requires a strategic approach to how these technologies are deployed together. This section provides practical guidance for designing a layered immutability strategy.

3.4.1 Layered Immutability Strategy Across Backup Copies

Best practice is to apply immutability at multiple layers, creating defense-in-depth:

Layer 1 — Primary Backup (On-Cluster DataLock): Enable DataLock on local backup snapshots to prevent deletion during the retention period. This is your first line of defense.

Layer 2 — Replicated Copy (Policy-Based Air Gap): Use Cohesity’s policy-based air gap feature to automatically replicate data to another immutable cluster, either on-premises or in the cloud. The replicated copy is also protected by DataLock on the target cluster, creating geographic separation. [Source: https://www.cohesity.com/blogs/how-backup-immutability-defends-against-ransomware-attacks/]

Layer 3 — Cyber Vault (Cohesity FortKnox): For the highest level of isolation, Cohesity FortKnox provides cyber vaulting and recovery as a service. FortKnox stores a copy of backup data in a Cohesity-managed cloud environment that is network-isolated from the customer’s production infrastructure. [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/datasheets/cisco-cohesity-fortknox-datasheet-en.pdf]

Layered Immutability Strategy:

Layer 1: Primary Cluster        Layer 2: Replicated Cluster     Layer 3: FortKnox Vault
+---------------------+        +---------------------+         +---------------------+
| DataLock-protected  | -----> | DataLock-protected  | ------> | Network-isolated    |
| local snapshots     |  auto  | remote snapshots    |  vault  | cyber vault copy    |
| (on-premises)       |  repl  | (on-prem or cloud)  |         | (Cohesity-managed)  |
+---------------------+        +---------------------+         +---------------------+

Each layer adds isolation and protection against different threat scenarios.

Figure 3.6: Layered immutability strategy

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

This layered approach means that an attacker would need to simultaneously compromise the primary cluster, the replicated cluster, and the FortKnox vault — a scenario that is effectively impossible given the different access controls, network isolation, and administrative domains involved.

3.4.2 Compliance Requirements for WORM Storage (SEC, FINRA)

Organizations in regulated industries must choose their DataLock mode carefully. The following table maps regulatory requirements to Cohesity configuration:

[Source: https://www.cohesity.com/resource-assets/third-party-reports/Cohesity-Cohasset-Assoc-Assessment-Report2017.pdf]

Cohesity’s Compliance mode has been assessed by Cohasset Associates, an independent records management compliance firm, confirming that it meets these regulatory requirements. When preparing for an audit, organizations should retain the Cohasset assessment report as evidence of third-party validation. [Source: https://docs.cohesity.com/baas/NAS/NASFileDataLock.htm]

Important planning considerations:

• Once Compliance mode is enabled, it cannot be downgraded to Enterprise mode or disabled. Ensure your organization truly needs Compliance mode before enabling it.
• Only users with the Data Security RBAC role can manage DataLock settings in Compliance mode, which provides the separation of duties that regulators expect.
• Document your WORM configuration, retention periods, and administrative roles as part of your compliance evidence package.

3.4.3 Testing and Validating Immutability Configurations

Configuring immutability is not a “set and forget” activity. Organizations should regularly validate that their immutability controls are working as expected:

Validation checklist:

1. Test deletion prevention: Attempt to delete a DataLock-protected snapshot using an administrator account. Confirm the operation is denied.
2. Test role separation: Verify that only users with the Data Security role can modify DataLock policies. Attempt to modify settings with a standard administrator account and confirm denial.
3. Test retention expiry: Create a test snapshot with a short DataLock retention period. Verify it becomes deletable only after the retention period expires.
4. Test legal hold: Place a legal hold on a snapshot, allow its normal retention to expire, and verify the snapshot is preserved.
5. Test replication: Verify that DataLock policies are enforced on replicated copies at the target cluster.
6. Test encryption validation: Verify encryption status in the cluster dashboard and confirm that all View Boxes show encryption as enabled.
7. Test key management failover: If using an external KMS cluster, temporarily disable one KMS server and verify that data access continues through the remaining servers.

Perform these validations after initial deployment and periodically thereafter (quarterly is a common cadence) to ensure that configuration drift or software updates have not altered your immutability posture.

Key Takeaway: A layered immutability strategy combining on-cluster DataLock, replicated copies, and cyber vaulting (FortKnox) provides defense-in-depth against ransomware and data destruction. For regulated industries, Compliance mode is mandatory and cannot be downgraded. Regularly test and validate your immutability configurations to ensure they function as expected.

Chapter Summary

This chapter covered the two pillars of system hardening for Cohesity environments: immutability through WORM storage and confidentiality through encryption.

WORM and DataLock provide the foundation for ransomware resilience. Built on the SpanFS immutable file system, Cohesity snapshots are inherently read-only. DataLock adds policy-driven retention locks that prevent anyone — including administrators — from deleting backup data. Compliance mode meets the strictest regulatory requirements (SEC, FINRA, CFTC), while Enterprise mode offers flexibility for organizations that need immutability without regulatory mandates. Legal hold extends this protection to specific snapshots that must be preserved for litigation or investigation.

Data-at-rest encryption using AES-256-GCM ensures that backup data is unreadable without proper authorization, even if physical media is compromised. FIPS 140-2 Level 2 certification validates that the encryption implementation meets federal standards.

Key management ties it all together. The internal KMS provides a zero-overhead starting point, while external KMS via KMIP and cloud-native KMS services offer the separation of keys from data that security best practices demand. The DEK/KEK architecture, key rotation, and key caching mechanisms balance security with operational performance.

Layered immutability — combining DataLock, replication, and cyber vaulting — creates a defense-in-depth posture that no single point of compromise can defeat.

Key Terms

Chapter 4: System Hardening — Attack Surface Reduction

Learning Objectives

By the end of this chapter, you will be able to:

• Identify and reduce the attack surface of a Cohesity cluster deployment
• Implement hardening measures for the underlying Cohesity OS and system access
• Configure Security Advisor recommendations to improve cluster security posture
• Apply CIS benchmark and STIG-aligned hardening practices to Cohesity environments

Every door you leave unlocked is a door an attacker can walk through. In cybersecurity, system hardening is the practice of locking those doors — disabling unnecessary services, restricting access, and configuring systems according to security best practices. The closely related concept of attack surface reduction means shrinking the total number of doors that exist in the first place.

Think of a medieval castle. A castle with one well-guarded gate and thick walls is far harder to breach than a sprawling estate with dozens of entrances, open windows, and unguarded corridors. Cohesity Data Cloud takes this castle approach: the platform is designed to be secure by default, with ports closed, access restricted, and encryption active from the outset. Your job as a security specialist is to verify those defaults are in place, tighten them further where needed, and monitor the security posture over time.

This chapter walks through the four pillars of Cohesity system hardening: OS and access security, attack surface analysis, Security Advisor posture scoring, and alignment with industry hardening frameworks.

Figure 4.1: Four Pillars of Cohesity System Hardening

graph LR
    A[System Hardening] --> B[OS & Access Security]
    A --> C[Attack Surface Analysis]
    A --> D[Security Advisor & Posture Scoring]
    A --> E[Hardening Frameworks & Compliance]
    B --> B1[SpanOS Hardening]
    B --> B2[SSH & Console Restriction]
    B --> B3[Privilege Reduction]
    B --> B4[Patch Management]
    C --> C1[Identify Exposed Services]
    C --> C2[Disable Unused Connectors]
    C --> C3[Minimal Privilege Access]
    D --> D1[Scan]
    D --> D2[Score]
    D --> D3[Remediate]
    E --> E1[CIS Benchmarks]
    E --> E2[STIG Controls]

4.1 Cohesity OS and System Access Security

The foundation of any hardened system begins at the operating system layer. Cohesity runs a purpose-built Linux-based OS called SpanOS, and its security controls start there.

4.1.1 Cohesity Linux-Based OS Hardening Measures

Cohesity Data Cloud follows a secure-by-default design philosophy. Out of the box, the platform includes zero trust architecture, AES-256 encryption for data at rest, TLS v1.3 with strong ciphers for data in transit, immutable backup snapshots, and multifactor authentication support. [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/white-paper/cohesity-platform-security-white-paper-en.pdf]

At the network level, the OS enforces strict port discipline:

• All ports on a Cohesity cluster are disabled by default except for known required ports.
• Preconfigured IP tables in the underlying OS allowlist only the services that need to communicate internally.
• Unused open ports and services remain closed. [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/white-paper/cohesity-platform-security-white-paper-en.pdf]

The encryption subsystem is equally locked down. The Cohesity cluster is FIPS 140-2 certified, with the encryption module validated with NIST, and the cluster always operates in FIPS mode. Cohesity leverages FIPS-approved AES-256 encryption at rest and does not support TLS v1.1 or below. Node-to-node data transfer uses TLS 1.2, and Cohesity recommends enabling node-to-node encryption as an additional security measure. Encryption keys can be managed through an internal KMS, a KMIP-compliant external KMS, or AWS KMS. [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/white-paper/cohesity-platform-security-white-paper-en.pdf]

Real-World Analogy: Think of FIPS 140-2 certification as a government stamp of approval on a bank vault’s lock mechanism. It does not just mean the lock works — it means the lock has been independently tested, validated, and certified to meet a rigorous federal standard.

4.1.2 Restricting SSH and Console Access

SSH restriction is one of the most critical hardening measures on any server. On Cohesity clusters, the Secure Shell feature has been enabled by default since version 6.8, which restricts SSH access to the host operating system shell. [Source: https://docs.cohesity.com/baas/CLI/secureshell.htm]

Key SSH hardening behaviors include:

Users interact through a restricted command environment rather than having full OS-level shell access. This means administrators can still execute CLI commands, run diagnostic tools, and access logs — but they cannot browse the filesystem or modify OS-level files directly. [Source: https://docs.cohesity.com/baas/CLI/secureshell.htm]

For console access, Cohesity introduced the Split Key feature in version 7.0. This delivers an additional safeguard against malicious access to the Host OS by mandating a challenge-response system when a user attempts to access the console via IPMI (Intelligent Platform Management Interface). The Split Key adds a second authentication layer on top of the existing username-password combination. Critically, the response codes can only be generated by opening a support case with Cohesity SREs, who are available 24x7. [Source: https://www.csoonline.com/article/574493/cohesity-data-cloud-70-enhances-privileged-access-authentication-ransomware-recovery.html]

The Split Key feature is configurable from the cluster UI under Access Management > SecureLogin > Split Key. On upgrade from 6.8 or below to 7.2, Split Key for IPMI console access can be enabled. [Source: https://www.scribd.com/document/794868665/Cohesity-Best-Practice-Security-Hardening-Guide]

Real-World Analogy: Split Key works like a safe deposit box at a bank — you need your key and the bank manager’s key to open it. No single person can gain access alone, which eliminates the risk of a rogue or compromised administrator acting unilaterally.

Figure 4.2: Split Key Challenge-Response Flow for IPMI Console Access

sequenceDiagram
    participant Admin as Administrator
    participant Cluster as Cohesity Cluster
    participant Support as Cohesity SRE (24x7)

    Admin->>Cluster: Request console access via IPMI
    Cluster->>Admin: Generate challenge code
    Admin->>Support: Open support case with challenge code
    Support->>Support: Verify identity & authorize
    Support->>Admin: Provide response code
    Admin->>Cluster: Enter response code
    Cluster->>Admin: Grant console access

4.1.3 Service Account Management and Privilege Reduction

Cohesity’s security architecture is built on the principles of least privilege and segregation of duties, both for managing data and administering the platform. [Source: https://www.scribd.com/document/794868665/Cohesity-Best-Practice-Security-Hardening-Guide]

Support user account controls:

• The “support” user account has read-only privileges by default when a Cohesity support engineer is allowed to access the cluster.
• Only the cluster administrator user can escalate the support user’s privileges.
• Sudo access is disabled by default for the support user for security reasons.
• Cohesity recommends enabling MFA for the support user account in addition to the admin account. [Source: https://docs.cohesity.com/baas/Dashboard/Admin/support-user.htm]

Role-Based Access Control (RBAC) provides centralized user management with the ability to map users to Cohesity Roles and create custom roles. Cohesity’s SSO integration supports three RBAC methods:

Best practice is to deploy SSO with user groups-based RBAC and assign custom roles to different user groups. [Source: https://www.cohesity.com/blogs/role-based-access-control-rbac-cohesity-dataprotect-4-0/]

Quorum approval (also called dual control) adds another layer of protection. This feature requires that any root-level or critical system change be authorized by more than one person. Quorum approvals help eliminate risks associated with unilateral admin tasks from highly-privileged administrators — preventing a rogue, poorly trained, or compromised administrator from performing sensitive operations without oversight. [Source: https://futurumgroup.com/wp-content/uploads/documents/FGPR_Cohesity_DataProtect-5.pdf]

As a security best practice, the default password of Cohesity clusters must be changed before starting operations, which helps minimize the likelihood or impact of an attack. [Source: https://www.scribd.com/document/794868665/Cohesity-Best-Practice-Security-Hardening-Guide]

4.1.4 Patch Management and Software Update Procedures

Keeping systems patched is one of the most effective — and most neglected — security practices. Cohesity simplifies this with one-click, non-disruptive cluster upgrades that handle software upgrades, security updates, firmware upgrades, and OS upgrades through a single workflow. [Source: https://www.cohesity.com/blogs/cohesity-delivers-one-click-non-disruptive-upgrades/]

How rolling upgrades work:

When a cluster upgrade is initiated, each node upgrades one after another. A distributed lock manager coordinates the process. When a node starts upgrading, its services are temporarily brought down while other nodes automatically pick up its workload via VIP migration (Virtual IP migration). This ensures zero downtime during the upgrade window. [Source: https://www.cohesity.com/blogs/cohesity-cluster-upgrades/]

Figure 4.3: Rolling Upgrade Process with VIP Migration

graph TD
    Start[Initiate Cluster Upgrade] --> Lock[Distributed Lock Manager Coordinates]
    Lock --> N1[Node 1 Begins Upgrade]
    N1 --> VIP1[VIP Migration: Nodes 2-4 Absorb Workload]
    VIP1 --> N1Done[Node 1 Complete]
    N1Done --> N2[Node 2 Begins Upgrade]
    N2 --> VIP2[VIP Migration: Nodes 1,3,4 Absorb Workload]
    VIP2 --> N2Done[Node 2 Complete]
    N2Done --> N3[Node 3 Begins Upgrade]
    N3 --> VIP3[VIP Migration: Nodes 1,2,4 Absorb Workload]
    VIP3 --> N3Done[Node 3 Complete]
    N3Done --> N4[Node 4 Begins Upgrade]
    N4 --> VIP4[VIP Migration: Nodes 1-3 Absorb Workload]
    VIP4 --> N4Done[Node 4 Complete]
    N4Done --> Done[All Nodes Upgraded - Zero Downtime]

In the 7.2.2 release, Cohesity completely redesigned the software upgrade and patch framework process, further streamlining the experience. [Source: https://www.cohesity.com/blogs/cohesity-data-cloud-7-2-2-features-support-for-red-hat-openshift-and-more/]

Long-Term Support (LTS) releases are supported for a minimum of twelve months with security updates and bug fixes, with a minimum of six months of overlapping coverage between two LTS releases. This overlap gives organizations a comfortable migration window. Cohesity recommends that agents be maintained on the same, latest major version as the cluster to receive the latest security fixes. [Source: https://www.cohesity.com/blogs/long-term-support-lts-for-cohesity-data-cloud-6-8-1-now-available/]

Worked Example: Planning a Cluster Upgrade

Suppose your organization runs Cohesity Data Cloud 7.0 across a 4-node cluster. A new 7.2.2 LTS release is available with critical security patches. Here is the process:

1. Pre-check: Verify current cluster health and confirm all nodes are operational.
2. Download: Obtain the upgrade package from the Cohesity support portal.
3. Initiate: Start the one-click upgrade from the cluster UI.
4. Rolling update: Node 1 goes offline for upgrade while Nodes 2-4 absorb its workload via VIP migration. Once Node 1 completes, Node 2 begins, and so on.
5. Post-check: Verify all nodes are running the new version. Update agents on protected sources to match the cluster version.

The entire process requires no application downtime, no manual intervention between nodes, and no separate workflows for OS versus software patches.

Key Takeaway: Cohesity’s OS-level hardening starts with secure defaults — closed ports, restricted SSH, disabled sudo for support accounts, and FIPS-certified encryption. Administrators should verify these defaults, enable Split Key for IPMI access, enforce quorum for privileged operations, and maintain a disciplined patching cadence using the non-disruptive rolling upgrade mechanism.

4.2 Attack Surface Analysis

Attack surface refers to the sum of all points where an unauthorized user could attempt to enter or extract data from a system. Reducing the attack surface is not a one-time event — it is an ongoing discipline.

4.2.1 Identifying Exposed Services and Unnecessary Features

Cohesity’s platform consolidation approach inherently reduces the attack surface. By consolidating backup, disaster recovery, file services, object storage, dev/test, and analytics on a unified platform, Cohesity eliminates the need for multiple point products, each of which would present its own set of vulnerabilities and management overhead. [Source: https://www.cohesity.com/blogs/protecting-a-growing-attack-surface-from-ransomware/]

However, even on a consolidated platform, administrators must actively identify what is exposed. The following table outlines common exposure points and their mitigations:

IPMI traffic deserves special attention. It is sent over the network for administrators to access nodes for pre-boot BIOS access and post-boot console access. This traffic should be restricted to management networks only — never exposed to general user or production networks. [Source: https://www.scribd.com/document/794868665/Cohesity-Best-Practice-Security-Hardening-Guide]

4.2.2 Disabling Unused Connectors and Integration Points

Every connector, integration, or feature that is enabled but not used is an unnecessary door in the castle wall. Administrators should periodically audit the cluster for:

• Unused data protection policies that may retain stale connections to decommissioned sources
• Integration endpoints (such as cloud tiering targets or external NAS mounts) that are no longer active
• Service accounts that were created for testing or temporary purposes and never removed
• Marketplace applications that were installed but are not actively used

The principle is straightforward: if a feature or connection is not actively required, disable or remove it. This practice directly aligns with the zero trust philosophy that Cohesity’s Threat Defense architecture embodies. [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/white-paper/threat-defense-architecture-white-paper-en.pdf]

4.2.3 Reducing Data Exposure Through Minimal Privilege Access

Data exposure reduction goes beyond network hardening — it extends to who can see what data and when. Cohesity addresses this through several mechanisms:

Immutable snapshots: All backup snapshots are stored in an immutable state by default. The original snapshot (the “gold copy”) is never mounted or exposed to any external system or application. The only way to access backup data in read-write mode is to create a zero-cost clone, which the system handles automatically. [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/white-paper/cohesity-platform-security-white-paper-en.pdf]

Figure 4.4: Immutable Snapshot and Clone Access Model

graph LR
    Backup[Backup Job] --> Gold[Gold Copy Snapshot]
    Gold -->|Immutable - Never Exposed| Storage[(Protected Storage)]
    Gold -->|Zero-Cost Clone| Clone[Read-Write Clone]
    Clone --> App[Application / User Access]
    Admin[Administrator] -.->|Cannot Delete| Gold
    Attacker[Attacker] -.->|Cannot Modify| Gold
    DataLock[DataLock WORM Policy] -->|Time-Bound Lock| Gold

DataLock WORM: DataLock provides Write-Once-Read-Many (WORM) capability for backups. A DataLock policy creates a time-bound lock on selected backup snapshots that cannot be deleted even by the administrator or security officer role, providing an extra layer of protection against ransomware and insider threats. [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/white-paper/counter-ransomware-attacks-with-cohesity-solution-brief-en.pdf]

RBAC and custom roles: By mapping users to specific roles with narrowly scoped permissions, organizations ensure that a backup operator cannot modify security settings, a security officer cannot delete backups outside of policy, and an auditor can view logs without modifying configurations.

Key Takeaway: Attack surface reduction on Cohesity requires both leveraging the platform’s secure-by-default posture and actively auditing for unnecessary services, stale integrations, and overly broad access. Immutable snapshots and DataLock WORM provide data-level protection that even compromised administrator accounts cannot override.

4.3 Security Advisor and Posture Scoring

Knowing what to harden is half the battle. Security Advisor, launched in December 2021 as part of the Cohesity Helios data platform, gives administrators a built-in tool to assess, score, and improve their cluster’s security posture — at no additional cost. [Source: https://www.businesswire.com/news/home/20211214005820/en/Cohesity-Launches-Security-Advisor-Making-It-as-Easy-as-Scan-Score-Remediate-to-Improve-Security-Posture-and-Reduce-Cyber-Risks-in-an-Era-of-Sophisticated-Ransomware-Attacks]

4.3.1 Cohesity Security Advisor Dashboard and Scoring

Security Advisor operates through a straightforward three-step approach: Scan, Score, Remediate.

+------------------+     +------------------+     +------------------+
|                  |     |                  |     |                  |
|      SCAN        | --> |      SCORE       | --> |    REMEDIATE     |
|                  |     |                  |     |                  |
|  Scans security  |     |  Generates a     |     |  Provides        |
|  configurations  |     |  numerical score  |     |  actionable      |
|  across clusters |     |  against best     |     |  recommendations |
|                  |     |  practices        |     |  to fix gaps     |
+------------------+     +------------------+     +------------------+

1. Scan: Security Advisor scans the Cohesity environment, evaluating an array of security configurations and considering factors such as access control, audit logs, and encryption framework that are critical to protecting the data cluster’s security posture.

2. Score: Customers receive a numerical score indicating how they are performing against Cohesity’s best practice recommendations. This scorecard-based approach helps IT teams understand their standing relative to recommended security standards.

3. Remediate: Customers receive actionable recommendations on how to address potential risks. When a scan reveals issues, teams can drill down for detailed information and specific guidance on resolving configuration gaps. [Source: https://www.cohesity.com/newsroom/press/cohesity-launches-security-advisor-making-it-as-easy-as-scan-score-remediate-to-improve-security-posture-and-reduce-cyber-risks-in-an-era-of-sophisticated-ransomware-attacks/]

4.3.2 Interpreting and Acting on Security Recommendations

Security Advisor evaluates four primary security dimensions:

When interpreting your score, focus on the highest-impact recommendations first. A finding like “MFA not enabled for admin accounts” represents a far greater risk than a suboptimal log retention period. Prioritize:

1. Authentication gaps (MFA, default passwords, SSO configuration)
2. Encryption gaps (node-to-node encryption, KMS configuration)
3. Access control gaps (RBAC misconfigurations, excessive privileges)
4. Logging and monitoring gaps (retention, syslog integration)

Worked Example: Responding to a Security Advisor Scan

After running a Security Advisor scan, your organization receives a score of 72/100 with the following findings:

• MFA not enabled for the support user account
• Audit log retention set to 90 days (below recommended 180)
• Node-to-node encryption not enabled
• Two inactive service accounts with elevated privileges

Your remediation plan:

1. Enable MFA for the support account via Access Management > MFA settings. [Source: https://se-baas1.aas.netnordic.net/docs/UserGuide/Content/Dashboard/Admin/mfa-support-user.htm]
2. Increase audit log retention to 180 days under System > Audit Logs > Log Settings. [Source: https://docs.cohesity.com/baas/data-protect/audit-logs-dataprotect.htm]
3. Enable node-to-node encryption (note: this may require a maintenance window for initial configuration).
4. Remove or disable the two inactive service accounts.
5. Re-scan with Security Advisor to confirm the score improvement.

4.3.3 Automated Security Checks and Remediation Guidance

Security Advisor provides centralized visibility across all Cohesity cluster security settings, spanning geographies, sites, and regions through the Helios Dashboard. This is particularly valuable for organizations with distributed deployments where configuration drift is a real risk. [Source: https://www.techzine.eu/news/data-management/69676/cohesity-security-advisor-helps-organizations-improve-their-security/]

Key capabilities include:

• Executive-ready security scorecards suitable for reporting to management and security teams
• Detailed configuration issue analysis with granular recommendations for each specific gap
• Native Helios integration — no additional deployment or licensing required

Security Advisor also works alongside CyberScan, a Cohesity Marketplace application that runs on-demand and automated scans against known vulnerabilities within backup snapshots. While Security Advisor focuses on platform configuration and security posture, CyberScan specifically uncovers cyber exposures by scanning backup data for indicators of compromise (IOCs). Together, they provide a complementary view: Security Advisor hardens the platform itself, while CyberScan ensures the data being protected is not already compromised. [Source: https://blocksandfiles.com/2021/12/15/cohesity-threat-scanning-security-advisor-looks-for-malware/]

Figure 4.5: Security Advisor vs CyberScan Complementary Coverage

graph TB
    subgraph "Security Advisor"
        SA[Platform Configuration Scanning]
        SA --> AC[Access Control]
        SA --> AL[Audit Logs]
        SA --> EF[Encryption Framework]
        SA --> CC[Cluster Configuration]
    end
    subgraph "CyberScan"
        CS[Backup Data Scanning]
        CS --> IOC[Indicators of Compromise]
        CS --> Vuln[Known Vulnerabilities]
        CS --> Malware[Malware Detection]
    end
    SA -->|Score & Remediate| Posture[Improved Security Posture]
    CS -->|Alert & Quarantine| Posture

4.3.4 Tracking Security Posture Improvements Over Time

Security posture — the overall strength of an organization’s security controls and readiness — is not a fixed state. It requires ongoing measurement and improvement. Security Advisor enables this by providing a repeatable, quantifiable assessment process.

Best practices for tracking improvements:

1. Baseline: Run an initial Security Advisor scan immediately after deployment or after any major configuration change. Record the score and all findings.
2. Remediate in priority order: Address critical findings first (authentication, encryption), then moderate findings (logging, access control tuning).
3. Re-scan regularly: Schedule periodic scans (monthly or quarterly at minimum) to detect configuration drift or new findings introduced by upgrades or environment changes.
4. Document and report: Use the executive-ready scorecards to communicate security posture to leadership, demonstrating measurable progress over time.
5. Integrate with change management: Tie Security Advisor scans to change control processes so that any cluster modification triggers a re-assessment.

Key Takeaway: Security Advisor provides a no-cost, built-in tool for continuous security posture assessment using a scan-score-remediate workflow. Combined with CyberScan for data-level vulnerability detection, it gives administrators centralized visibility and actionable guidance to maintain and improve cluster security across distributed environments.

4.4 Hardening Frameworks and Compliance

Industry hardening frameworks provide prescriptive, externally validated security configurations. Cohesity aligns with two of the most widely adopted frameworks: CIS Benchmarks and STIG standards.

4.4.1 CIS Benchmark Alignment for Cohesity Clusters

The Center for Internet Security (CIS) Benchmarks are consensus-based configuration guidelines developed by security practitioners and subject matter experts worldwide. They provide specific, actionable recommendations for hardening operating systems, applications, and network devices.

Cohesity’s OS and components are specifically configured to meet CIS benchmark security hardening requirements. This means that SpanOS ships with many CIS-aligned configurations already applied at the factory level, covering areas such as: [Source: https://www.scribd.com/document/794868665/Cohesity-Best-Practice-Security-Hardening-Guide]

• Filesystem permissions and mount options
• User account and authentication policies
• Network configuration and firewall rules
• Logging and auditing settings
• Service and process restrictions

For a Cohesity security specialist, the key point is that CIS alignment is not something you build from scratch — it is something you verify and maintain. After deployment, use Security Advisor and manual checks to confirm that CIS-aligned settings remain in place, particularly after upgrades or configuration changes.

4.4.2 STIG Compliance Considerations

The Security Technical Implementation Guide (STIG) is published by the US Department of Defense’s Defense Information Systems Agency (DISA). STIGs provide configuration standards that are mandatory for DoD systems and widely adopted across government and regulated industries.

Cohesity SpanOS has implemented many STIG controls as detailed in the following categories:

[Source: https://www.collegesidekick.com/study-docs/22327185]

STIG compliance is particularly important for organizations in government, defense, financial services, and healthcare sectors where regulatory requirements mandate adherence to DoD security standards. Cohesity’s pre-built STIG alignment significantly reduces the compliance burden for these organizations compared to general-purpose infrastructure that would require extensive manual hardening.

4.4.3 Security Hardening Checklist for New Deployments

The following checklist consolidates the hardening measures discussed throughout this chapter into an actionable deployment guide:

This checklist is not exhaustive but covers the primary hardening actions that align with CIS benchmarks, STIG controls, and Cohesity’s own security best practice recommendations. [Source: https://www.scribd.com/document/794868665/Cohesity-Best-Practice-Security-Hardening-Guide]

Key Takeaway: Cohesity SpanOS ships with CIS benchmark and STIG controls pre-applied, significantly reducing the hardening burden for new deployments. Administrators should use the deployment checklist to verify and extend these defaults, particularly in regulated environments where compliance documentation is required.

Chapter Summary

System hardening and attack surface reduction on Cohesity Data Cloud is a layered discipline that spans the OS, network, application, and data tiers:

1. OS and access security begins with SpanOS’s secure-by-default design — closed ports, restricted SSH, FIPS 140-2 certified encryption, and disabled sudo for support accounts. Split Key and Quorum add dual-control safeguards against privileged access misuse.

2. Attack surface analysis requires both leveraging platform consolidation (which inherently reduces the number of vulnerable components) and actively auditing for unnecessary services, stale connectors, and overly broad permissions. Immutable snapshots and DataLock WORM protect data even if administrative accounts are compromised.

3. Security Advisor provides a no-cost, built-in scan-score-remediate workflow that evaluates access control, audit logs, encryption, and cluster configuration against best practices. Combined with CyberScan for data-level vulnerability detection, it delivers centralized visibility and actionable remediation guidance.

4. Hardening frameworks including CIS Benchmarks and STIG controls are pre-integrated into SpanOS, providing a strong compliance foundation. The deployment hardening checklist consolidates these practices into a prioritized, actionable plan.

The overarching principle is defense in depth: no single control is sufficient on its own, but together they create a hardened environment where the attack surface is minimized and the security posture is continuously measured and improved.

Key Terms

Chapter 5: Security Assessment & Compliance

Learning Objectives

By the end of this chapter, you will be able to:

• Evaluate Cohesity cluster security posture against compliance frameworks
• Configure data retention policies aligned with regulatory requirements
• Implement legal hold procedures for e-discovery and compliance
• Integrate Cohesity with third-party security solutions for Zero Trust architecture

5.1 Compliance and Regulatory Frameworks

Organizations that manage sensitive data — whether patient records, financial transactions, or personal information — must comply with a growing web of regulations. Think of a compliance framework as a blueprint for a building’s safety systems: it specifies what protections are required, how they must be tested, and what evidence proves they are in place. Cohesity addresses this challenge by holding a broad set of certifications and by building compliance-enabling features directly into the platform.

5.1.1 GDPR, HIPAA, SOX, and PCI-DSS Requirements for Data Protection

Each regulatory framework emphasizes different aspects of data protection, but they share common themes: encryption, access control, auditability, and data minimization. The table below summarizes the key requirements and how Cohesity maps to each.

Figure 5.1: Compliance framework common themes mapped to Cohesity capabilities

graph LR
    subgraph Frameworks
        GDPR["GDPR"]
        HIPAA["HIPAA"]
        SOX["SOX"]
        PCI["PCI-DSS"]
    end

    subgraph Common Requirements
        ENC["Encryption"]
        AC["Access Control"]
        AUD["Auditability"]
        DM["Data Minimization"]
    end

    subgraph Cohesity Capabilities
        AES["AES-256 Encryption\n(FIPS-validated)"]
        RBAC["Granular RBAC\n+ MFA"]
        TRAIL["User Audit Trails\n+ Security Advisor"]
        RET["Automated Retention\nPolicies"]
        CLASS["ML-Based Data\nClassification"]
        WORM["DataLock WORM\nImmutable Snapshots"]
    end

    GDPR --> ENC & AC & AUD & DM
    HIPAA --> ENC & AC & AUD
    SOX --> AUD & DM
    PCI --> ENC & AC & AUD

    ENC --> AES
    AC --> RBAC
    AUD --> TRAIL
    DM --> RET
    AUD --> CLASS
    DM --> WORM

GDPR (General Data Protection Regulation) governs how organizations collect, store, and process personal data of EU residents. Cohesity offers a Data Processing Addendum (DPA) so that when a customer shares personal data with Cohesity, the customer acts as the data controller and Cohesity acts as the data processor under applicable data protection laws. Automated retention policies help enforce the principle of data minimization — keeping data only as long as necessary. [Source: https://www.cohesity.com/blogs/data-protection-gdpr-compliance-positive-pitfall/]

HIPAA (Health Insurance Portability and Accountability Act) establishes standards for protecting sensitive patient health information. Cohesity products adhere to security benchmarks aligned with HIPAA guidelines. Platform data is encrypted at rest using AES-256 encryption, meeting HIPAA’s encryption requirements. Granular role-based access control (RBAC) and user audit trails provide the access management and accountability that HIPAA mandates. [Source: https://www.cohesity.com/glossary/data-protection/]

SOX (Sarbanes-Oxley Act) requires publicly traded companies to maintain accurate financial records with verifiable internal controls. Cohesity’s immutable snapshots and DataLock WORM functionality ensure that financial data cannot be altered after the fact, directly supporting SOX audit requirements.

PCI-DSS (Payment Card Industry Data Security Standard) protects cardholder data through encryption, access controls, and continuous monitoring. Cohesity’s ML-based data classification can identify and map PCI-relevant data across backup environments, helping organizations know exactly where sensitive payment information resides. [Source: https://www.cohesity.com/platform/data-classification/]

5.1.2 Mapping Cohesity Features to Compliance Requirements

Cohesity maintains an extensive set of security certifications that serve as independent validation of the platform’s security posture:

[Source: https://www.cohesity.com/trust/]

For financial services organizations, Cohesity supports write-once, read-many (WORM) functionality compliant with SEC 17a-4(f), FINRA Rule 4511(c), and CFTC regulations, as assessed by Cohasset Associates. [Source: https://www.cohesity.com/trust/]

Real-World Analogy: Think of these certifications like a restaurant’s health inspection grades posted in the window. Each certification represents an independent auditor verifying that specific security controls are in place and functioning correctly. A SOC 2 Type II audit, for example, does not just check that controls exist on a single day — it evaluates whether they operated effectively over a sustained period, much like a health inspector returning multiple times throughout the year.

5.1.3 Compliance Reporting and Audit Evidence Generation

Passing an audit requires more than having controls in place — you must prove it. Cohesity supports compliance reporting through several mechanisms:

• User Audit Trails: The platform maintains a comprehensive audit trail for all actions performed on the Cohesity cluster, providing proof of compliance and operational integrity. Every login, configuration change, data access, and administrative action is logged. [Source: https://www.cohesity.com/solutions/data-security/]
• ML-Based Data Classification: Cohesity’s data classification engine uses machine learning to identify and categorize sensitive information — including personally identifiable information (PII), protected health information (PHI), and payment card data — across backup environments. Classification categories include regulatory classification, confidentiality levels, criticality assessment, accessibility controls, lifecycle management, format-based organization, location-based categorization, and value-based prioritization. [Source: https://www.cohesity.com/platform/data-classification/]
• Security Advisor: Provides continuous security posture assessment and recommendations, giving administrators a dashboard view of how their cluster configuration aligns with security best practices. [Source: https://www.cohesity.com/why-cohesity/threat-defense/]

Worked Example: Preparing for a HIPAA Audit

A healthcare organization using Cohesity needs to demonstrate HIPAA compliance to an auditor. Here is how they would gather evidence:

1. Encryption verification: Navigate to cluster settings and document that AES-256 encryption is enabled for data at rest and in transit. Export the encryption configuration report.
2. Access control documentation: Export the RBAC configuration showing that only authorized roles (e.g., Backup Admin, Security Officer) have access to PHI workloads. Show that MFA is enforced for all administrative accounts.
3. Data classification report: Run the data classification scan to produce a report showing where PHI resides across the backup environment, confirming that sensitive data is identified and properly protected.
4. Audit trail export: Pull the user audit trail for the review period, demonstrating who accessed what data and when. This log serves as evidence of the “minimum necessary” access principle.
5. Retention policy documentation: Export the retention policies showing that PHI backups are retained for the required period (typically six years under HIPAA) and that automated expiration prevents indefinite data accumulation.

Figure 5.2: HIPAA audit evidence gathering workflow

flowchart TD
    START["HIPAA Audit\nPreparation"] --> S1["1. Encryption\nVerification"]
    S1 --> S1D["Export AES-256\nconfig report"]
    S1D --> S2["2. Access Control\nDocumentation"]
    S2 --> S2D["Export RBAC roles\n+ MFA enforcement"]
    S2D --> S3["3. Data Classification\nReport"]
    S3 --> S3D["Run ML scan to\nlocate all PHI"]
    S3D --> S4["4. Audit Trail\nExport"]
    S4 --> S4D["Pull user access logs\nfor review period"]
    S4D --> S5["5. Retention Policy\nDocumentation"]
    S5 --> S5D["Export 6-year PHI\nretention policies"]
    S5D --> AUDIT["Complete Evidence\nPackage for Auditor"]

    style START fill:#1a73e8,color:#fff
    style AUDIT fill:#34a853,color:#fff

Key Takeaway: Cohesity maps to major compliance frameworks — GDPR, HIPAA, SOX, and PCI-DSS — through a combination of platform certifications (SOC 2 Type II, ISO 27001, FIPS 140-2, FedRAMP), built-in security features (AES-256 encryption, RBAC, audit trails), and ML-based data classification that automatically identifies regulated data across backup environments.

5.2 Data Retention and Legal Holds

Data retention is the practice of keeping data for a defined period to meet business, legal, or regulatory requirements. Getting retention wrong creates risk in both directions: delete data too early and you violate regulations; keep it too long and you increase storage costs and attack surface. Cohesity provides policy-driven retention management combined with legal hold capabilities for litigation scenarios.

5.2.1 Configuring Data Retention Policies and Schedules

Cohesity’s predefined policies help organizations meet global and regional requirements for GDPR, CCPA, HIPAA, and other regulations. Data retention periods are specified through automated policies that define how long backup snapshots are kept before they expire. [Source: https://www.cohesity.com/resource-assets/solution-brief/Cohesity-GDPR-Solution-Brief.pdf]

Real-World Analogy: A retention policy is like an expiration date on food packaging. Just as a grocery store systematically removes expired products from shelves, Cohesity automatically expires backup snapshots once they pass their retention period — ensuring data does not linger beyond its useful or legally required lifespan.

A typical retention policy configuration includes:

Organizations typically create multiple retention policies tailored to different data classifications. For example, a financial services firm might maintain a 7-year archival policy for SEC-regulated records while using a 30-day policy for development environment backups.

5.2.2 Implementing Legal Holds for E-Discovery

A legal hold (also called a litigation hold) is a directive to preserve all data that may be relevant to pending or anticipated litigation. When a legal hold is in place, normal retention expiration is suspended — the data must not be deleted regardless of what the retention policy says.

In the context of e-discovery — the process by which electronically stored information is identified, collected, and produced for legal proceedings — Cohesity’s legal hold capability ensures that relevant backup data remains available and unaltered throughout the litigation process.

Worked Example: Implementing a Legal Hold

A company receives notice of pending litigation related to a former employee’s activities. The legal department issues a preservation notice. Here is how the Cohesity administrator responds:

1. Identify relevant data: Work with the legal team to determine which protection groups, sources, or time ranges are relevant to the case.
2. Apply legal hold: Place a legal hold on the identified backup snapshots. This overrides the normal retention policy, preventing automatic expiration.
3. Document the hold: Record the hold’s scope, the date it was applied, who authorized it, and the legal matter it relates to. This documentation is essential for demonstrating compliance with preservation obligations.
4. Monitor the hold: Periodically verify that held snapshots remain intact and accessible. The audit trail confirms that no data under hold has been modified or deleted.
5. Release the hold: Once the legal matter concludes, the legal team authorizes removal of the hold. Snapshots then resume their normal retention lifecycle and will expire according to policy.

5.2.3 Retention Lock and Policy Enforcement Mechanisms

DataLock is Cohesity’s implementation of time-bound WORM (Write Once Read Many) protection. Cohesity was the first modern data management solution to introduce DataLock, which prevents backup snapshots from being deleted or modified before their lock period expires — even by administrators. [Source: https://www.cohesity.com/blogs/what-is-cohesity-threat-defense/]

DataLock serves as a critical defense against both insider threats and ransomware. Unlike a standard retention policy (which an administrator could modify), a DataLock-protected snapshot cannot be shortened or removed by any single individual. Combined with the Quorum feature — which requires multiple authorized individuals to approve critical changes — DataLock creates a robust chain of custody that satisfies the strictest regulatory requirements. [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/white-paper/threat-defense-architecture-white-paper-en.pdf]

For financial services, DataLock’s WORM functionality has been assessed by Cohasset Associates as compliant with SEC 17a-4(f), FINRA Rule 4511(c), and CFTC regulations. [Source: https://www.cohesity.com/trust/]

Real-World Analogy: DataLock is like a time-locked safe at a bank. Once something is placed inside and the timer is set, nobody — not even the bank manager — can open it until the timer expires. This guarantees that the contents remain untouched for the required period.

5.2.4 Data Lifecycle Management and Automated Expiration

Effective data lifecycle management automates the journey of data from creation through archival to eventual deletion. Cohesity’s policy engine handles this lifecycle by:

1. Creation: Protection policies define when snapshots are taken and how many copies are created (local, replicated, archived).
2. Tiering: As data ages, policies can automatically move snapshots from high-performance local storage to cost-effective archival targets such as cloud storage or tape.
3. Expiration: When a snapshot reaches the end of its retention period (and no legal hold is active), it is automatically deleted to reclaim storage and reduce the attack surface.
4. Compliance verification: Audit trails record every retention event, providing evidence that data was retained for the required period and deleted on schedule.

Figure 5.3: Data lifecycle management with legal hold override

flowchart LR
    CREATE["1. Creation\nSnapshot taken\nper policy"] --> TIER["2. Tiering\nAge-based move to\narchival storage"]
    TIER --> CHECK{"Legal Hold\nActive?"}
    CHECK -- No --> EXPIRE["3. Expiration\nAuto-delete at\nretention end"]
    CHECK -- Yes --> HOLD["Hold: Expiration\nSuspended"]
    HOLD --> RELEASE["Hold Released\nby Legal Team"]
    RELEASE --> EXPIRE
    EXPIRE --> VERIFY["4. Compliance\nVerification\nAudit trail logged"]

    subgraph Protection Layer
        DATALOCK["DataLock WORM\nPrevents early deletion\neven by admins"]
        QUORUM["Quorum\nMulti-person approval\nfor critical changes"]
    end

    DATALOCK -.->|enforces| CHECK
    QUORUM -.->|governs| RELEASE

    style HOLD fill:#e8710a,color:#fff
    style DATALOCK fill:#d93025,color:#fff
    style QUORUM fill:#d93025,color:#fff

Key Takeaway: Cohesity’s data retention framework combines automated policies, legal holds for e-discovery preservation, and DataLock WORM protection to ensure data is kept exactly as long as required — no more, no less. DataLock and Quorum together prevent any single individual from circumventing retention controls.

5.3 Zero Trust Design Principles

Zero Trust is a security model based on the principle “never trust, always verify.” Unlike traditional perimeter-based security that assumes everything inside the network is safe, Zero Trust treats every access request as potentially hostile — regardless of where it originates. Cohesity’s Threat Defense architecture implements and extends Zero Trust principles, recognizing that Zero Trust alone is insufficient against sophisticated threats like “double extortion” ransomware that combines encryption with data theft. [Source: https://www.cohesity.com/blogs/what-is-cohesity-threat-defense/]

Real-World Analogy: Traditional security is like a castle with a moat — once you cross the drawbridge, you are trusted everywhere inside. Zero Trust is like a modern high-security building where every door requires a badge scan, every floor requires separate authorization, and security cameras monitor all activity continuously. Even employees who are already inside must prove their identity at every checkpoint.

5.3.1 Zero Trust Architecture Applied to Data Protection

Cohesity’s Threat Defense architecture is built on four pillars that align with the NIST Cyber Security Framework’s multi-layered defense approach: [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/white-paper/threat-defense-architecture-white-paper-en.pdf]

Figure 5.4: Cohesity Threat Defense four-pillar Zero Trust architecture

graph TB
    ZT["Zero Trust Principle\nNever Trust, Always Verify"]

    ZT --> P1["Data Resiliency"]
    ZT --> P2["Access Control"]
    ZT --> P3["Detection &\nAnalytics"]
    ZT --> P4["Extensibility"]

    P1 --> P1A["Immutable Snapshots\n(SpanFS)"]
    P1 --> P1B["AES-256 Encryption\n(FIPS-validated)"]
    P1 --> P1C["FortKnox\nVirtual Air Gap"]

    P2 --> P2A["MFA"]
    P2 --> P2B["Granular RBAC"]
    P2 --> P2C["Quorum\nMulti-Person Auth"]

    P3 --> P3A["AI Anomaly\nDetection"]
    P3 --> P3B["ML Data\nClassification"]
    P3 --> P3C["YARA Rules\nThreat Hunting"]

    P4 --> P4A["SIEM\nSentinel / Splunk"]
    P4 --> P4B["SOAR\nXSOAR / ServiceNow"]
    P4 --> P4C["Endpoint / Network\nCrowdStrike / Cisco"]

    style ZT fill:#1a73e8,color:#fff
    style P1 fill:#34a853,color:#fff
    style P2 fill:#ea4335,color:#fff
    style P3 fill:#fbbc04,color:#000
    style P4 fill:#9334e6,color:#fff

Data Resiliency forms the foundation. Cohesity’s SpanFS — a third-generation distributed file system — stores data in internal Views that are never exposed to external applications. Immutable snapshots create read-only clones if any modification is attempted. FIPS-validated AES-256 encryption protects data both in transit and at rest. [Source: https://www.cohesity.com/blogs/what-is-cohesity-threat-defense/]

FortKnox adds an additional layer by providing SaaS-based data isolation that functions as a “virtual air gap” against ransomware. Even if an attacker compromises the primary cluster, FortKnox-isolated copies remain safe in a separate, Cohesity-managed environment. [Source: https://www.cohesity.com/why-cohesity/threat-defense/]

5.3.2 Microsegmentation and Least-Privilege Access

Microsegmentation in the Cohesity context means that access is compartmentalized so that compromising one credential does not grant access to all data. This is achieved through:

• Granular RBAC: Privileges are assigned based on specific roles, ensuring users can only access the data and operations relevant to their job function. A backup operator, for example, can run and monitor backup jobs but cannot modify security settings or access data from other departments.
• Quorum Authorization: Critical operations require approval from two or more authorized individuals. This feature works like a safety deposit box at a bank — no single person, not even a root administrator, can perform quorum-controlled actions alone. The platform contains no service back-doors. [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/white-paper/threat-defense-architecture-white-paper-en.pdf]
• Multifactor Authentication (MFA): Requires multiple authentication factors — such as a device, one-time password, or smart card in addition to a password — reducing the risk of credential theft.

Worked Example: Least-Privilege RBAC Configuration

An organization configures the following roles for their Cohesity environment:

By segmenting responsibilities this way, even if an attacker compromises the Backup Operator credentials, they cannot modify security settings, delete backups, or access data classification reports.

Figure 5.5: Least-privilege RBAC microsegmentation model

graph TB
    ATTACKER["Attacker Compromises\nBackup Operator Credentials"]

    subgraph Accessible ["Accessible (Backup Operator Scope)"]
        A1["Run/Monitor\nBackup Jobs"]
        A2["View Job\nStatus"]
    end

    subgraph Blocked ["Blocked by RBAC Segmentation"]
        B1["Modify Security\nSettings"]
        B2["Delete Backups\nor Snapshots"]
        B3["Access Classification\nReports"]
        B4["Manage Legal\nHolds"]
        B5["Cluster Admin\nOperations"]
    end

    ATTACKER -->|"granted"| A1
    ATTACKER -->|"granted"| A2
    ATTACKER -.->|"DENIED"| B1
    ATTACKER -.->|"DENIED"| B2
    ATTACKER -.->|"DENIED"| B3
    ATTACKER -.->|"DENIED"| B4
    ATTACKER -.->|"DENIED"| B5

    B5 -->|"additionally requires"| QUORUM["Quorum:\nMulti-Person\nApproval"]

    style ATTACKER fill:#d93025,color:#fff
    style Accessible fill:#e8f5e9
    style Blocked fill:#fce4ec
    style QUORUM fill:#e8710a,color:#fff

5.3.3 Continuous Verification and Trust Scoring

Zero Trust requires ongoing verification rather than one-time authentication. Cohesity implements continuous verification through:

• Security Advisor: Continuously assesses the cluster’s security posture and provides actionable recommendations. It functions as an automated security auditor, flagging configuration drift and compliance gaps. [Source: https://www.cohesity.com/why-cohesity/threat-defense/]
• Adaptive Behavioral Analytics: AI-powered analysis detects unusual access patterns that may indicate ransomware activity or malicious insider behavior. Rather than relying on static rules, the system learns normal patterns and flags deviations. [Source: https://www.cohesity.com/blogs/what-is-cohesity-threat-defense/]
• Source-Side Anomaly Detection: Cohesity detects anomalies at the source rather than waiting for the next backup cycle. This is significant because backups typically run on daily schedules — source-side detection provides earlier identification of threats. [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/white-paper/threat-defense-architecture-white-paper-en.pdf]
• Near Real-Time Threat Detection: Native next-generation antivirus engines identify ransomware and malware within platform data. Administrators can create custom YARA rules for advanced threat hunting targeting specific indicators of compromise. [Source: https://www.cohesity.com/blogs/what-is-cohesity-threat-defense/]

Key Takeaway: Cohesity implements Zero Trust through its four-pillar Threat Defense architecture: immutable data resiliency, least-privilege access control with Quorum multi-person authorization, AI-driven continuous detection, and extensible security integrations. The Quorum feature is particularly distinctive — it eliminates single points of compromise by requiring multiple individuals to authorize critical operations, with no service back-doors in the platform.

5.4 Third-Party Security Integration

No security tool operates in isolation. Modern organizations run security operations centers (SOCs) that aggregate alerts from dozens of sources into centralized platforms. Cohesity’s Extensibility pillar — the fourth pillar of the Threat Defense architecture — ensures that backup intelligence flows seamlessly into the broader security ecosystem. [Source: https://www.cohesity.com/blogs/what-is-cohesity-threat-defense/]

5.4.1 SIEM Integration for Centralized Security Monitoring

A SIEM (Security Information and Event Management) platform collects, correlates, and analyzes security events from across an organization’s infrastructure. Integrating Cohesity with a SIEM means that backup anomalies, ransomware alerts, and policy violations appear alongside firewall logs, endpoint alerts, and identity events — giving security analysts a unified view.

Cohesity sends rich, contextual backup intelligence — including anomalies, scan results, and timeline data — into leading SIEM platforms. [Source: https://www.cohesity.com/blogs/cohesity-7-0-data-management-and-security-for-cyber-resilience/]

Microsoft Sentinel Integration (Detailed Example)

Microsoft Sentinel is a cloud-native SIEM that integrates with Cohesity Data Cloud through the Cohesity Security Integration solution available on the Cohesity Marketplace. [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/solution-guides/integrate-microsoft-sentinel-with-cohesity-data-cloud-solution-guide-en.pdf]

The integration architecture works as follows:

Cohesity Clusters --> Cohesity Helios --> Azure Function App --> Microsoft Sentinel
                                          (Data Connector)     (Log Analytics Workspace)

• Data Connector: An Azure Function App (Cohesity Data Connector) establishes a secure connection between Cohesity Helios and Microsoft Sentinel, processing security events and telemetry.
• Alert Categories: The integration surfaces ransomware detection events, unauthorized access attempts, policy violation notifications, anomalous user behavior patterns, and data exfiltration indicators.
• Data Flow: Data flows from Cohesity clusters through the connector to Sentinel’s Log Analytics workspace, enabling both real-time threat visualization and historical analysis.

Configuration Steps:

1. Deploy the Cohesity Data Connector from the Azure Marketplace
2. Configure Cohesity cluster credentials in the Function App
3. Set Function App authentication parameters
4. Establish Log Analytics workspace connectivity
5. Customize alert routing rules to match your organization’s incident response workflow

The integration enables centralized log aggregation across hybrid environments, anomaly detection using machine learning baselines, custom query creation for threat hunting, automated incident response workflows, and compliance reporting with audit trails. [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/solution-guides/integrate-microsoft-sentinel-with-cohesity-data-cloud-solution-guide-en.pdf]

5.4.2 SOAR Platform Integration for Automated Response

While SIEM platforms focus on detection and analysis, SOAR (Security Orchestration, Automation, and Response) platforms take the next step by automating the response to security incidents. When Cohesity detects a threat, SOAR integration can trigger automated playbooks that triage the incident, notify stakeholders, and initiate recovery — all without waiting for a human analyst.

Palo Alto Networks Cortex XSOAR Integration

Cohesity Helios integrates with Palo Alto Networks Cortex XSOAR for AI-powered ransomware detection and recovery: [Source: https://www.cohesity.com/newsroom/press/cohesity-helios-integrates-with-palo-alto-networks-cortex-xsoar-to-help-ai-powered-ransomware-detection-and-recovery/]

1. Detection: Cohesity Helios continuously monitors backup data using AI-powered analysis. When it detects anomalies — such as a sudden spike in data change rates or encryption patterns consistent with ransomware — it sends detailed alerts to Cortex XSOAR.
2. Automated Triage: Cortex XSOAR receives the alert and initiates automated playbooks designed to assess the scope and severity of the potential attack.
3. Response Orchestration: The playbook can automatically isolate affected systems, notify incident response teams, and begin forensic evidence collection.
4. Recovery: If an attack is confirmed, Cohesity helps the organization locate and recover a clean copy of data from immutable backups, reducing downtime and minimizing data loss.

The integration is available through both the Cortex XSOAR Marketplace and the Cohesity Marketplace.

Figure 5.6: SOAR automated incident response pipeline (Cohesity + Cortex XSOAR)

sequenceDiagram
    participant C as Cohesity Helios
    participant X as Cortex XSOAR
    participant T as Security Team
    participant R as Recovery

    C->>C: AI monitors backup data continuously
    C->>C: Detects anomaly (encryption spike,<br/>unusual change rate)
    C->>X: Sends detailed alert with context
    X->>X: Initiates automated triage playbook
    X->>X: Assesses scope and severity
    X->>T: Notifies incident response team
    X->>X: Isolates affected systems
    X->>X: Begins forensic evidence collection
    T->>R: Confirms attack, authorizes recovery
    R->>C: Locates clean immutable backup
    C->>R: Restores data from pre-attack snapshot
    R->>T: Recovery complete, minimal data loss

Real-World Analogy: Think of SIEM as a building’s security camera system — it records everything and alerts security guards to suspicious activity. SOAR is the automated response system that, upon detecting a fire, automatically triggers the sprinklers, sounds the alarm, unlocks emergency exits, and calls the fire department — all within seconds, without waiting for someone to notice the camera feed.

5.4.3 Antivirus and Malware Scanning Integrations

Cohesity provides native threat detection capabilities and extends them through partnerships:

• Native Next-Gen Antivirus: Built-in antivirus engines scan backup data for known ransomware and malware signatures. [Source: https://www.cohesity.com/resources/solution-brief/cohesity-advanced-threat-protection-en/]
• Custom YARA Rules: Security teams can create custom detection rules using YARA, a pattern-matching language widely used in malware research, to hunt for specific indicators of compromise (IOCs) within backup data. [Source: https://www.cohesity.com/blogs/what-is-cohesity-threat-defense/]
• Sophos Integration: Cohesity has partnered with Sophos for next-generation malware scanning, further expanding the threat protection partner ecosystem. [Source: https://www.businesswire.com/news/home/20260319037008/en/Cohesity-Enhances-Cyber-Resilience-with-Next-Generation-Malware-Scanning-Powered-by-Sophos]

Cohesity streams IOC hits and alerts to existing security stacks, enabling consolidated, end-to-end incident management across the organization’s security tools. [Source: https://www.cohesity.com/blogs/cohesity-7-0-data-management-and-security-for-cyber-resilience/]

5.4.4 Cohesity Marketplace Security Apps and Extensions

The Cohesity Marketplace serves as the central hub for security integrations. The broader partner ecosystem spans multiple security domains:

[Source: https://www.cohesity.com/blogs/what-is-cohesity-threat-defense/]

These integrations create a feedback loop: Cohesity detects anomalies in backup data and shares that intelligence with security tools, while those tools can feed threat intelligence back to Cohesity to improve detection accuracy.

Key Takeaway: Cohesity integrates with the broader security ecosystem through SIEM platforms (Microsoft Sentinel, Splunk) for centralized monitoring, SOAR platforms (Cortex XSOAR, ServiceNow) for automated incident response, and antivirus partners (Sophos) for enhanced malware scanning. These integrations ensure that backup intelligence — anomalies, IOC hits, and classification data — flows into the organization’s security operations for end-to-end threat management.

Chapter Summary

Security assessment and compliance in Cohesity is not a single feature but a comprehensive framework spanning regulatory alignment, data governance, trust architecture, and ecosystem integration.

Compliance and Regulatory Frameworks: Cohesity holds certifications including SOC 2 Type II, ISO 27001, FIPS 140-2, Common Criteria, FedRAMP, and DoD Authorization to Operate. The platform maps to GDPR, HIPAA, SOX, and PCI-DSS requirements through encryption, RBAC, audit trails, and ML-based data classification that automatically identifies regulated data.

Data Retention and Legal Holds: Automated retention policies enforce regulatory timelines while legal holds override normal expiration for e-discovery preservation. DataLock provides time-bound WORM protection assessed as compliant with SEC 17a-4(f) and FINRA requirements, and the Quorum feature ensures no single individual can circumvent retention controls.

Zero Trust Design Principles: The four-pillar Threat Defense architecture implements Zero Trust through immutable data resiliency (SpanFS, encryption, fault tolerance), least-privilege access control (MFA, RBAC, Quorum), AI-driven detection and analytics (behavioral analysis, YARA rules, source-side anomaly detection), and extensible security integrations.

Third-Party Security Integration: Cohesity feeds backup intelligence into SIEM platforms like Microsoft Sentinel for centralized monitoring and SOAR platforms like Cortex XSOAR for automated response. Native antivirus capabilities are extended through partnerships with Sophos, and the Cohesity Marketplace provides a growing catalog of security integrations across endpoint, network, identity, and vulnerability management domains.

Key Terms

Chapter 6: Authentication — MFA, SSO & Active Directory

Learning Objectives

By the end of this chapter, you will be able to:

• Configure multi-factor authentication (MFA) for Cohesity cluster access
• Implement single sign-on (SSO) using SAML and OIDC identity providers
• Integrate Cohesity with Active Directory and LDAP for centralized authentication
• Design authentication policies that enforce organizational security standards

Authentication is the gatekeeper of every security architecture. Before a user can protect data, restore backups, or manage policies on a Cohesity cluster, the system must first answer a fundamental question: Who are you, and can you prove it?

Think of authentication like airport security. A boarding pass (your username and password) gets you through the first checkpoint, but modern airports also require government-issued ID (a second factor), and frequent travelers may use trusted-traveler programs that let them pass through a single expedited lane (single sign-on). Cohesity provides all three layers — multi-factor authentication, SSO integration, and centralized directory services — so that organizations can build a defense-in-depth approach to identity verification.

Figure 6.1: Cohesity authentication defense-in-depth layers

graph LR
    User["User"] --> Layer1["Layer 1\nUsername & Password"]
    Layer1 --> Layer2["Layer 2\nMulti-Factor Authentication\n(TOTP / Email)"]
    Layer2 --> Layer3["Layer 3\nSSO via Identity Provider\n(SAML / OIDC)"]
    Layer3 --> Layer4["Layer 4\nDirectory Services\n(Active Directory / LDAP)"]
    Layer4 --> Cluster["Cohesity\nCluster Access"]

    style Layer1 fill:#4a90d9,color:#fff
    style Layer2 fill:#e8a838,color:#fff
    style Layer3 fill:#7b68ee,color:#fff
    style Layer4 fill:#2ecc71,color:#fff
    style Cluster fill:#34495e,color:#fff

6.1 Multi-Factor Authentication

Multi-factor authentication (MFA) requires users to present two or more independent pieces of evidence before gaining access. Even if an attacker steals a password, they cannot authenticate without the additional factor. Cohesity supports MFA natively, requiring no additional hardware or internet connectivity for its primary method. [Source: https://docs.cohesity.com/baas/Dashboard/Admin/mfa-local-user.htm]

6.1.1 MFA Configuration on Cohesity Clusters

Enabling MFA on a Cohesity cluster is a straightforward process performed through the management UI:

1. Navigate to Settings > Access Management and select the MFA tab.
2. Turn on the MFA toggle.
3. Select one or both authentication methods (Authenticator App and/or Email).
4. Click Enable.

Cohesity recommends selecting both authentication methods to prevent user lockouts in case one method becomes unavailable. [Source: https://docs.cohesity.com/baas/Dashboard/Admin/mfa-local-user.htm]

After MFA is enabled at the cluster level, individual users complete setup during their next login by either scanning a QR code or manually entering a security key into their authenticator app. [Source: https://se-baas1.aas.netnordic.net/docs/UserGuide/Content/Dashboard/Admin/mfa.htm]

6.1.2 Supported MFA Methods

Cohesity supports two MFA verification methods:

TOTP (Time-based One-Time Password) is a standard algorithm that generates a new numeric code every 30 seconds based on a shared secret and the current time. The code is valid for a limited window, typically five minutes on Cohesity. Critically, the cluster does not need internet connectivity when using TOTP — the algorithm runs entirely on the user’s device and the cluster. [Source: https://docs.cohesity.com/baas/Dashboard/Admin/mfa-local-user.htm]

Figure 6.2: TOTP-based MFA authentication flow

sequenceDiagram
    participant U as User
    participant App as Authenticator App
    participant C as Cohesity Cluster

    U->>C: Enter username & password
    C->>C: Validate credentials
    C-->>U: Prompt for MFA code
    U->>App: Open authenticator app
    App->>App: Generate 6-digit TOTP code<br/>(shared secret + current time)
    App-->>U: Display code (valid 30s)
    U->>C: Enter TOTP code
    C->>C: Generate expected TOTP code<br/>(same shared secret + current time)
    C->>C: Compare codes (5-min window)
    C-->>U: Access granted

Cohesity strongly recommends against using email as the primary MFA method because email messages can be intercepted by intermediary parties. The authenticator app approach is both more secure and more reliable. [Source: https://cohesity.my.salesforce-sites.com/KnowledgeBase/?id=ka02J000000N7goQAC]

Real-World Analogy: TOTP works like a combination lock where the combination changes every 30 seconds. Both you and the lock know the pattern for generating combinations, so even without communicating, you always arrive at the same code at the same time. An attacker who intercepts one code finds it useless seconds later.

6.1.3 Enforcing MFA: All Users vs. Privileged Accounts

Cohesity provides granular control over which accounts require MFA:

Local and Active Directory Users: Administrators can enable MFA for all users or for specific local users. Notably, MFA is enabled by default for Active Directory users who have accounts created in Cohesity, and disabling MFA for AD users is not supported for security reasons. [Source: https://docs.cohesity.com/baas/Dashboard/Admin/mfa-local-user.htm]

Support User Accounts: MFA for support users is configured separately via Settings > Access Management > Support. The administrator must click Unlock and enter the support user password before making changes. Cohesity recommends enabling MFA for both the built-in admin and support accounts. [Source: https://docs.cohesity.com/baas/Dashboard/Admin/mfa-support-user.htm]

Multi-Tenant Organizations: In environments using Cohesity’s multi-tenancy features, MFA can be enabled at the organization level, allowing each tenant to enforce their own MFA policies. [Source: https://docs.cohesity.com/baas/Dashboard/Admin/mfa-organizations.htm]

Flex Appliance Enforcement: On Flex Appliances, MFA extends across multiple interfaces including the Web UI, shell command-line access, NetBackup WORM storage server shell, and NetBackup Primary and Media Server environments. Administrators can enforce MFA with a grace period of up to 90 days for user compliance. Once enforcement is activated, it becomes permanent — it cannot be reversed. [Source: https://www.cohesity.com/blogs/multifactor-authentication-made-easy-with-flex-appliances/]

6.1.4 MFA Recovery and Emergency Access

When users lose access to their authenticator device, administrators holding super administrator or security administrator privileges can reset that user’s MFA credentials. The user then re-enrolls their authenticator app on next login. [Source: https://www.cohesity.com/blogs/multifactor-authentication-made-easy-with-flex-appliances/]

Best practices for MFA recovery planning:

• Enable both MFA methods (TOTP and email) so users have a fallback if one method is unavailable.
• Document the recovery procedure and ensure at least two administrators have super administrator or security administrator privileges.
• Secure the built-in admin account with a strong password and store its credentials in a sealed envelope or vault, as this account can serve as a break-glass access path.

Key Takeaway: Cohesity’s MFA implementation uses open-standard TOTP and email verification, requires no additional hardware or internet connectivity, and should be enabled for all users — especially the built-in admin and support accounts. Always enable both methods to prevent lockouts, and use TOTP as the primary factor.

6.2 Single Sign-On Configuration

Single sign-on (SSO) allows users to authenticate once with a central identity provider (IdP) and then access multiple applications — including Cohesity — without re-entering credentials. SSO reduces password fatigue, centralizes authentication policy enforcement, and simplifies user provisioning and deprovisioning. [Source: https://docs.cohesity.com/baas/Helios/SingleSignOn.htm]

6.2.1 SAML 2.0 Integration with Identity Providers

SAML 2.0 (Security Assertion Markup Language) is an XML-based open standard for exchanging authentication and authorization data between an identity provider and a service provider. In Cohesity’s SSO architecture, the IdP (such as Okta or Azure AD) authenticates the user and sends a signed SAML assertion to Cohesity, which validates the assertion and grants access.

SAML is Cohesity’s primary SSO protocol, supporting both UI and API-based authentication. [Source: https://docs.cohesity.com/baas/Helios/SingleSignOn.htm]

Figure 6.3: SAML 2.0 SSO authentication flow

sequenceDiagram
    participant U as User Browser
    participant C as Cohesity Cluster<br/>(Service Provider)
    participant IdP as Identity Provider<br/>(Okta / Azure AD / AD FS)

    U->>C: Access Cohesity login page
    C->>C: Detect SSO domain
    C-->>U: Redirect to IdP with SAML request
    U->>IdP: Follow redirect
    IdP->>IdP: Authenticate user<br/>(credentials + MFA)
    IdP-->>U: Return signed SAML assertion
    U->>C: POST SAML assertion
    C->>C: Validate signature &<br/>extract user attributes
    C->>C: Map groups to RBAC roles
    C-->>U: Grant access with assigned role

To configure SAML SSO, navigate to Settings > Access Management > Single Sign-On > Configure SSO and provide the following:

Additional security options: Cohesity supports signed authentication requests, where the cluster signs its SAML request to the IdP using RSA-SHA256 and SHA256 digest algorithms. This requires uploading Cohesity’s public certificate to the IdP. SAML assertions can also be both signed and encrypted for maximum security. [Source: https://docs.cohesity.com/baas/Helios/SingleSignOn.htm]

6.2.2 OIDC Configuration for Modern SSO Workflows

OpenID Connect (OIDC) is a modern authentication layer built on top of the OAuth 2.0 framework. Unlike SAML’s XML-based approach, OIDC uses lightweight JSON Web Tokens (JWTs), making it popular for API-driven and cloud-native architectures.

However, an important limitation applies: Cohesity supports OIDC only for API-based authentication, not for UI login. If your users need to sign in through the Cohesity web interface, SAML is the required protocol. [Source: https://docs.cohesity.com/baas/Helios/SingleSignOn.htm]

Figure 6.4: SAML vs OIDC protocol support in Cohesity

graph TD
    SSO["Single Sign-On Protocols"]
    SSO --> SAML["SAML 2.0"]
    SSO --> OIDC["OIDC (OpenID Connect)"]

    SAML --> SAML_FMT["XML-based assertions"]
    SAML --> SAML_UI["Web UI login ✓"]
    SAML --> SAML_API["API authentication ✓"]
    SAML --> SAML_SEC["Signed & encrypted assertions"]

    OIDC --> OIDC_FMT["JSON Web Tokens (JWT)"]
    OIDC --> OIDC_UI["Web UI login ✗"]
    OIDC --> OIDC_API["API authentication ✓"]
    OIDC --> OIDC_SEC["OAuth 2.0 token-based"]

    style SAML fill:#2ecc71,color:#fff
    style OIDC fill:#e67e22,color:#fff
    style SAML_UI fill:#27ae60,color:#fff
    style OIDC_UI fill:#e74c3c,color:#fff
    style SAML_API fill:#27ae60,color:#fff
    style OIDC_API fill:#27ae60,color:#fff

OIDC configuration fields:

6.2.3 IdP Configuration Examples

Cohesity supports 11+ identity providers. Below are detailed configuration walkthroughs for the three most common.

Okta (SAML 2.0)

1. In Okta, navigate to Applications > Applications and click Create App Integration. Select SAML 2.0 as the sign-on method.
2. Configure the App Name and optional logo.
3. Set the Single Sign-On URL to https://<cluster_fqdn>/idps/authenticate (or https://helios.cohesity.com/v2/mcm/idp/authenticate for Helios). Set the Audience URI to the same URL. Enable “Use this for Recipient URL and Destination URL.”
4. Map SAML attributes: Email to user.email, Login to user.login.
5. (Optional) For group-based RBAC, enter “groups” in the group attribute name field and apply filters such as “Starts with cohesity_”.
6. From the Sign-On tab, retrieve the Identity Provider Single Sign-On URL, Identity Provider Issuer, and download the certificate (convert to .pem format).
7. Assign users and groups via the Assignments tab.

[Source: https://docs.cohesity.com/baas/Helios/okta.htm]

Microsoft Entra ID (Azure AD) — SAML

1. In the Azure portal, navigate to Azure Active Directory > Enterprise applications. Select New Application > Create your own application > Non-gallery.
2. Under Set up Single Sign-On with SAML, set both the Identifier (Entity ID) and Reply URL to https://helios.cohesity.com/v2/mcm/idp/authenticate.
3. Add custom claims under User Attributes & Claims.
4. For group-based RBAC, add a group claim, select “Groups assigned to the application”, and configure the source attribute (sAMAccountName or Group ID). Name the claim “groups”. Note: nested groups are not supported, and sAMAccountName requires Azure AD Connect Sync 1.2.70.0 or later.
5. Extract the Login URL (SSO URL), Azure AD Identifier (Provider Issuer ID), and download the SAML Signing Certificate in PEM format.

[Source: https://docs.cohesity.com/baas/Helios/azure.htm]

Active Directory Federation Services (AD FS)

Prerequisites: AD FS installed, Active Directory with email attributes for all users, Microsoft Server 2016/2012/2008, SSL certificates for AD FS login pages and signing.

1. Open AD FS, right-click Relying Party Trusts, and add a new trust. Select Claims aware, enter data manually, and set the service URL to https://helios.cohesity.com/v2/mcm/idp/authenticate.
2. Create three claim rules:
   • Rule 1 — LDAP to Claims Mapping: Map User-Principal-Name to E-Mail Address
   • Rule 2 — Email Claim Transformation: Transform E-Mail Address to outgoing claim type “email”
   • Rule 3 — Custom Group Rule: Extract and transmit group names
3. Retrieve the Federation Service Name, Federation Service Identifier, and export the Token-Signing Certificate as Base-64 encoded X.509 (convert to .pem).

Note: Cohesity does not support Sign Auth Requests for signing SAML requests to AD FS. [Source: https://docs.cohesity.com/baas/Helios/adfs.htm]

RBAC with SSO

Cohesity’s SSO integration supports three methods for role-based access control:

Users must have explicit IdP entries — missing entries result in authentication rejection. Cluster access can be scoped to all clusters or limited to specific ones. [Source: https://docs.cohesity.com/baas/Helios/SingleSignOn.htm]

Key Takeaway: Cohesity supports SSO via SAML 2.0 (for both UI and API access) and OIDC (API only). When configuring SSO with providers like Okta, Azure AD, or AD FS, the critical steps involve registering the Cohesity authentication endpoint, mapping user and group attributes, and downloading the IdP certificate in .pem format. Group-based RBAC mapping through SAML attributes enables automated, policy-driven role assignment.

6.3 Active Directory & LDAP Integration

While SSO handles web-based authentication flows, many organizations need Cohesity to participate directly in their Active Directory (AD) domain — particularly for SMB file services, delegated administration, and environments where AD is the authoritative identity source.

Real-World Analogy: Joining a Cohesity cluster to Active Directory is like adding a new employee to the company directory. Once registered, the cluster can verify anyone’s badge (Kerberos ticket) against the central registry, and the company’s existing group memberships automatically determine what each person can access.

6.3.1 Joining Cohesity Clusters to Active Directory Domains

Prerequisites

Before joining a Cohesity cluster to AD, verify the following:

[Source: https://docs.cohesity.com/baas/ActiveDirectory/ADRequirements.htm]

Configuration Steps

1. Navigate to Settings > Access Management and click the Active Directory tab.
2. Enter the AD domain name.
3. Provide at least one machine account to identify the Cohesity cluster on the domain.
4. (Optional) Select a mapped provider — LDAP or NIS — for UID/GID mapping.
5. (Optional) Specify the organizational unit (format: OUName or OUName/SubOUName).
6. (Optional) Enable trusted domain discovery to detect and manage trust relationships.
7. Supply domain join credentials and complete the join process.

The entire process typically takes approximately five minutes. After joining, the login interface displays a dropdown menu for domain selection. [Source: https://docs.cohesity.com/baas/Dashboard/Admin/ActiveDirectory.htm]

Figure 6.5: Active Directory join and authentication flow

flowchart TD
    subgraph Prerequisites
        DNS["DNS A Record\nfor machine account"]
        NTP["Clock Sync\n(< 5 min skew)"]
        DC["Preferred Domain\nControllers (2+)"]
        Creds["Domain Admin\nCredentials"]
    end

    Prerequisites --> Join["Join Cohesity Cluster\nto AD Domain"]
    Join --> Machine["Machine Account\nCreated in AD"]
    Machine --> Ready["Cluster Ready for\nAD Authentication"]

    subgraph Login["AD User Login Flow"]
        direction LR
        UserLogin["User selects\nAD domain"] --> Kerberos["Kerberos ticket\nvalidated against DC"]
        Kerberos --> GroupLookup["Group membership\nresolved"]
        GroupLookup --> RBAC["RBAC role\nassigned"]
    end

    Ready --> Login

    style Join fill:#3498db,color:#fff
    style Ready fill:#2ecc71,color:#fff
    style Machine fill:#9b59b6,color:#fff

Machine Account Permissions

After the cluster joins AD, the machine account must have Read membership permissions across all users and groups in the domain. Without these permissions, the cluster cannot resolve group memberships for RBAC. [Source: https://docs.cohesity.com/baas/Dashboard/Admin/ActiveDirectory.htm]

6.3.2 LDAP Authentication Configuration and Group Mapping

LDAP (Lightweight Directory Access Protocol) is a vendor-neutral protocol for accessing directory services. Cohesity supports LDAP providers as either standalone directory sources or as mapped providers alongside Active Directory.

To configure LDAP, navigate to Settings > Access Management > LDAP tab and click Add LDAP Provider. [Source: https://se-baas1.aas.netnordic.net/docs/UserGuide/Content/Dashboard/Admin/ManageLDAP.htm]

Important limitations to understand:

• Cohesity does not support LDAP authentication for users logging in to the Cohesity Dashboard (web UI).
• LDAP providers are primarily used to provide access to NFS exports for Unix users belonging to more than 16 groups.
• Only administrators or users with the “Manage AD and LDAP” role can add or modify LDAP providers.

[Source: https://se-baas1.aas.netnordic.net/docs/UserGuide/Content/Dashboard/Admin/ManageLDAP.htm]

6.3.3 Trusted Domain Support and Cross-Domain Authentication

When enabling trusted domain discovery during the AD join process, Cohesity detects trust relationships with other domains. Administrators can then selectively exclude certain trusted domains after the cluster has joined.

For SMB shares, only Kerberos authentication is supported when multiple AD domains are joined to the cluster — NTLM authentication is disabled. Any client machine accessing SMB shares must be joined to the same domain as the cluster and must be able to communicate with a domain controller in that domain. [Source: https://docs.cohesity.com/baas/Dashboard/Admin/ActiveDirectory.htm]

Cohesity also supports Azure Active Directory Domain Services (Azure AD DS) with Cohesity Cloud Edition deployments, enabling cloud-native AD authentication for clusters running in Azure environments. [Source: https://www.cohesity.com/blogs/leveraging-azure-active-directory-domain-services-cohesity-cloud-edition/]

6.3.4 Service Account Requirements for AD Integration

AD integration involves several service-level account considerations:

• Domain Join Account: Requires permissions to create Computer Objects in the target OU. Domain Administrator credentials are the simplest approach, though least-privilege delegated accounts can also be used.
• Machine Account: Created during the join process to represent the Cohesity cluster in AD. Must retain Read membership permissions across users and groups.
• Built-in Admin Account: The local admin account persists after AD integration — “configuring AD authentication supplements built-in authentication, so the local accounts still exist.” Cohesity recommends establishing a complex password and documenting it securely as a break-glass access path. [Source: https://demitasse.co.nz/2018/10/active-directory-authentication-for-my-cohesity-cluster/]

Role-Based Access Control with AD

After joining AD, Cohesity supports delegating privileges to AD groups with the following built-in roles:

Roles default to global scope but can be restricted to specific objects. For example, one AD group can receive administrator-level access while another receives operator-level permissions. [Source: https://demitasse.co.nz/2018/10/active-directory-authentication-for-my-cohesity-cluster/]

Key Takeaway: Joining Cohesity to Active Directory enables centralized authentication using Kerberos, with support for trusted domains and group-based RBAC. Critical prerequisites include DNS A records, preferred domain controllers (at least two recommended), and clock synchronization within 5 minutes. LDAP integration supplements AD for NFS/Unix use cases but does not support Dashboard login. Always secure the built-in admin account after AD integration.

6.4 Authentication Policy Design

Configuring authentication mechanisms is only half the battle. Effective security requires well-designed policies that govern how those mechanisms behave — from password strength requirements to session management and audit logging.

6.4.1 Password Policies and Complexity Requirements

Organizations should enforce password policies that align with current industry standards (such as NIST SP 800-63B). While Cohesity’s AD-integrated users inherit the domain’s password policies, local Cohesity accounts require separate attention:

For AD-integrated environments, the domain’s Group Policy Objects (GPOs) enforce password policies centrally. This is one of the key advantages of AD integration — a single policy applies across all domain-joined systems, including Cohesity.

6.4.2 Session Timeout and Lockout Configurations

Session management controls help limit the window of exposure if a session is left unattended or if an attacker attempts brute-force authentication:

• Session Timeouts: Configure idle session timeouts appropriate to the security classification of the environment. Shorter timeouts (15-30 minutes) are appropriate for clusters managing sensitive data.
• Account Lockout: Implement lockout thresholds after a defined number of failed login attempts to mitigate brute-force attacks. For AD-integrated accounts, the domain’s lockout policy applies.
• MFA Grace Periods: On Flex Appliances, administrators can set an MFA enforcement grace period of up to 90 days, giving users time to enroll. Once activated, enforcement becomes permanent and cannot be reversed. [Source: https://www.cohesity.com/blogs/multifactor-authentication-made-easy-with-flex-appliances/]

6.4.3 Authentication Audit Trails and Login Monitoring

A robust authentication architecture is incomplete without visibility into who is logging in, when, and from where. Cohesity provides audit capabilities that administrators should configure and monitor:

• Login event logging: Track successful and failed authentication attempts across all methods (local, AD, SSO).
• MFA enrollment tracking: Monitor which users have completed MFA enrollment, especially during grace periods.
• SSO assertion monitoring: Review SAML/OIDC authentication events to detect anomalies such as assertions from unexpected IP ranges or unusual login times.
• Privileged account monitoring: Pay special attention to authentication events for the built-in admin account, support account, and any accounts with cluster administrator privileges.

The following table summarizes a recommended authentication policy baseline for Cohesity environments:

Key Takeaway: Authentication policy design ties together MFA, SSO, and directory integration into a coherent security posture. Enforce MFA universally, use signed SAML assertions, configure preferred domain controllers, apply strong password policies for local accounts, set appropriate session timeouts, and maintain continuous audit logging of all authentication events.

Chapter Summary

This chapter examined the four pillars of Cohesity authentication: multi-factor authentication, single sign-on, Active Directory and LDAP integration, and authentication policy design.

Multi-Factor Authentication adds a critical second verification layer. Cohesity supports TOTP authenticator apps (recommended as the primary method) and email-based codes (recommended as a backup only). MFA is mandatory for AD users by default and should be explicitly enabled for the built-in admin and support accounts. On Flex Appliances, enforcement can include a grace period but becomes permanent once activated.

Single Sign-On centralizes authentication through SAML 2.0 (supporting both UI and API access) or OIDC (API only). Cohesity integrates with 11+ identity providers including Okta, Azure AD, and AD FS. Group-based RBAC mapping through SAML attributes enables automated role assignment aligned with organizational structure.

Active Directory and LDAP Integration brings Cohesity into the enterprise identity fabric. AD integration requires careful attention to DNS records, preferred domain controllers, clock synchronization, and machine account permissions. LDAP supplements AD for NFS/Unix access scenarios but does not support Dashboard login. The built-in admin account persists after AD integration and must be secured as a break-glass access path.

Authentication Policy Design unifies these mechanisms through consistent password policies, session management, and audit logging. The strongest authentication architecture combines all three layers: MFA on every account, SSO for centralized policy enforcement, and AD integration for Kerberos-based access control.

Key Terms

Chapter 7: Access Control — RBAC, Multi-Tenancy & Quorum

Learning Objectives

By the end of this chapter, you will be able to:

• Configure role-based access control (RBAC) with built-in and custom roles on Cohesity
• Implement multi-tenancy security to isolate tenant data and operations
• Set up Quorum groups to require multi-person approval for privileged actions
• Design least-privilege access strategies for Cohesity administration

Introduction

Imagine a large hospital where every staff member — from surgeons to janitors — carries the same master key that opens every door. That scenario would be reckless: surgeons need access to operating rooms, janitors need access to supply closets, and neither needs the other’s access. The same principle applies to data infrastructure. A backup platform holding an organization’s most critical data must enforce strict boundaries around who can see what, who can change what, and who can approve irreversible actions.

Cohesity Data Cloud addresses these requirements through three complementary mechanisms: Role-Based Access Control (RBAC) to assign precise permissions, Multi-Tenancy via Organizations to isolate entire tenant environments, and Quorum Groups to require multi-person approval before critical operations execute. Together, these features implement the security principles of least privilege, separation of duties, and defense in depth.

7.1 Role-Based Access Control

Role-Based Access Control (RBAC) is a security model in which permissions are assigned to roles, and roles are assigned to users — rather than granting permissions directly to individual users. Cohesity’s RBAC implementation provides centralized user management and the ability to map users to Cohesity roles, enforcing segregation of duty across the platform’s UI and API. [Source: https://www.cohesity.com/blogs/role-based-access-control-rbac-cohesity-dataprotect-4-0/]

Think of RBAC like a corporate badge system: rather than programming each badge individually, you create badge tiers (Executive, Employee, Visitor), define what each tier can access, and then assign the appropriate tier to each person.

Figure 7.1: RBAC model — users are assigned to roles, roles hold permissions

flowchart LR
    subgraph Users
        U1["Local User"]
        U2["AD Group Member"]
        U3["SSO User"]
    end
    subgraph Roles
        R1["Super Admin"]
        R2["Operator"]
        R3["Custom Role"]
    end
    subgraph Permissions
        P1["Manage Clusters"]
        P2["Run Protection Groups"]
        P3["Manage VMware Sources"]
        P4["View Dashboards"]
    end
    U1 --> R1
    U2 --> R2
    U3 --> R3
    R1 --> P1
    R1 --> P2
    R1 --> P3
    R1 --> P4
    R2 --> P2
    R2 --> P4
    R3 --> P3
    R3 --> P4

7.1.1 Built-in Roles and Their Permissions

Cohesity ships with over a dozen predefined roles that serve as ready-made templates for common job functions. The following table summarizes the most important built-in roles: [Source: https://docs.cohesity.com/disaster-recovery/site-continuity/vmware-vms/initial-setup/access-management.htm]

[Source: https://docs.cohesity.com/baas/data-protect/access-managment/manage-users-and-groups.htm]

An important constraint to understand: you cannot combine a default role such as Viewer with the Admin or Super Admin role. However, custom roles can be combined with Admin or Super Admin, providing additional flexibility when needed. [Source: https://docs.cohesity.com/baas/data-protect/access-managment/manage-users-and-groups.htm]

7.1.2 Creating Custom Roles with Granular Permissions

When built-in roles do not match your organization’s needs precisely, Cohesity allows you to create custom roles with hand-picked privileges. Custom roles let you implement the principle of least privilege by granting only the specific permissions a job function requires.

Steps to create a custom role:

1. Navigate to Settings > Access Management > Roles
2. Click Add Custom Role
3. Choose between a DataProtect Role or a custom NetBackup role
4. Define the role name and description (note: role names cannot be edited after creation)
5. Set the role’s privileges using toggles and checkboxes across privilege categories

[Source: https://docs.cohesity.com/baas/data-protect/access-managment/manage-users-and-groups.htm]

Privileges span multiple categories, allowing fine-grained control:

[Source: https://docs.cohesity.com/baas/data-protect/access-managment/manage-users-and-groups.htm]

Worked Example: Creating a “VMware Backup Operator” Custom Role

Suppose your organization has a team responsible solely for VMware backup operations. They should not manage storage, modify access controls, or perform restores. Here is how you would configure this:

1. Create a new custom role named VMware-Backup-Operator
2. Enable privileges under DataProtect Services for Protection Group management
3. Enable Source Access Control for VMware only
4. Leave all other categories (Access Management, Recovery Management, Storage Management) disabled
5. Assign this role to the VMware backup team’s AD group

The result: team members can create and run VMware protection groups but cannot restore data, manage storage, or modify user accounts.

7.1.3 Role Assignment to Local Users, AD Groups, and SSO Claims

Cohesity supports multiple identity sources for role assignment:

• Local users: Created directly in the Cohesity UI and assigned roles individually
• Active Directory (AD) groups: AD users and groups are mapped to Cohesity roles, enabling centralized identity management [Source: https://www.cohesity.com/blogs/role-based-access-control-rbac-cohesity-dataprotect-4-0/]
• SSO claims: Single sign-on integration with identity providers including Azure AD, Okta, Ping Identity, Duo, and Active Directory Federation Services [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/white-paper/integrate-azure-ad-with-cohesity-sso-white-paper-en.pdf]

When a user is assigned a custom role individually and also inherits a role from an AD group membership, that user holds both roles, and the effective permissions are the union of all assigned roles. [Source: https://docs.cohesity.com/baas/data-protect/access-managment/manage-users-and-groups.htm]

Figure 7.2: Identity sources converge into Cohesity role assignments

flowchart TD
    AD["Active Directory\nGroups & Users"] --> MAP["Cohesity Role\nMapping Engine"]
    SSO["SSO / IdP\n(Azure AD, Okta, Ping)"] --> MAP
    LOCAL["Local Cohesity\nAccounts"] --> MAP
    MAP --> ROLE_A["Role A\n(e.g., Admin)"]
    MAP --> ROLE_B["Role B\n(e.g., Custom Backup-Ops)"]
    ROLE_A --> EFF["Effective Permissions\n= Union of All Roles"]
    ROLE_B --> EFF
    EFF --> ACCESS["Access Granted\nto Cohesity Resources"]

Best practice: Deploy SSO with group-based RBAC. Map AD or IdP groups to custom Cohesity roles so that when an employee changes teams, updating their group membership in the identity provider automatically adjusts their Cohesity permissions. [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/white-paper/integrate-azure-ad-with-cohesity-sso-white-paper-en.pdf]

7.1.4 Principle of Least Privilege Applied to Cohesity RBAC

The principle of least privilege states that every user should have only the minimum permissions necessary to perform their job function. Cohesity enforces this principle through several mechanisms:

• Object-level access restrictions: Users can be limited to specific resources such as individual Virtual Machines, Physical Servers, or Storage arrays [Source: https://www.linkedin.com/pulse/mastering-cohesity-dataplatform-deep-dive-granular-access-riegel]
• Privilege escalation control: The system prevents users from granting themselves or others access to resources beyond their authorization [Source: https://www.linkedin.com/pulse/mastering-cohesity-dataplatform-deep-dive-granular-access-riegel]
• Granular privilege categories: Rather than broad “read” or “write” toggles, privileges are broken into dozens of specific operations

Think of it this way: rather than giving someone a key to the entire building, you give them a key that opens only their office, the conference room, and the break room — nothing more.

Key Takeaway: Cohesity RBAC provides over a dozen built-in roles and the ability to create custom roles with granular privileges. Roles can be assigned through local accounts, AD groups, or SSO claims. Always start with the most restrictive role that satisfies a user’s job requirements and use object-level restrictions to further limit scope.

7.2 Multi-Tenancy Security

Multi-tenancy is an architecture in which a single instance of software serves multiple independent customers (tenants), with each tenant’s data logically isolated from the others. Cohesity implements multi-tenancy through a feature called Organizations, where each tenant is represented as a separate Organization on the cluster. [Source: https://www.cohesity.com/blogs/multi-tenancy-meets-simplicity/]

The analogy here is an apartment building: all residents share the same physical structure, but each apartment has its own lock, its own utility meters, and its own lease agreement. No resident can enter another’s apartment, even though they share hallways and elevators.

7.2.1 Cohesity Organizations Architecture

An Organization in Cohesity logically groups a set of users and enforces data boundaries around their resources. Service providers create one Organization per tenant customer on their Cohesity cluster. [Source: https://www.cohesity.com/blogs/multi-tenancy-meets-simplicity/]

Key architectural properties of Organizations:

• Each Organization can be defined with its own Active Directory domains or groups
• Users within an Organization can only see resources assigned to that Organization
• Organizations can have their own password policies, MFA configurations, and RBAC role assignments
• Each Organization can be associated with a dedicated VLAN for network-level isolation

[Source: https://se-baas1.aas.netnordic.net/docs/UserGuide/Content/Dashboard/Admin/ManageOrganizations.htm]

The following diagram illustrates the logical architecture:

+--------------------------------------------------+
|              Cohesity Cluster                     |
|                                                   |
|  +-------------+  +-------------+  +----------+  |
|  | Org: Acme   |  | Org: Globex |  | Org: ... |  |
|  |             |  |             |  |          |  |
|  | - Users     |  | - Users     |  |          |  |
|  | - AD Domain |  | - AD Domain |  |          |  |
|  | - Policies  |  | - Policies  |  |          |  |
|  | - Views     |  | - Views     |  |          |  |
|  | - Sources   |  | - Sources   |  |          |  |
|  | - VLAN 100  |  | - VLAN 200  |  |          |  |
|  | - Encrypt.  |  | - Encrypt.  |  |          |  |
|  +-------------+  +-------------+  +----------+  |
+--------------------------------------------------+

7.2.2 Tenant Isolation: Data, Views, Policies, and Resources

Cohesity provides multiple layers of isolation to ensure tenant security: [Source: https://www.cohesity.com/blogs/per-tenant-data-security-service-at-provider-scale/]

A particularly strong security guarantee: service providers cannot decrypt tenant data even though they have physical access to the hard drives. This is enforced through per-tenant encryption keys that are not accessible to the service provider. [Source: https://www.cohesity.com/blogs/per-tenant-data-security-service-at-provider-scale/]

Figure 7.3: Multi-tenancy isolation layers stacked on shared infrastructure

block-beta
    columns 1
    block:MGMT["Management-Level Isolation"]
        columns 3
        A["Tenant A\nAdmin Portal"] B["Tenant B\nAdmin Portal"] C["Tenant C\nAdmin Portal"]
    end
    block:POLICY["Policy Isolation"]
        columns 3
        PA["Tenant A\nPolicies & SLAs"] PB["Tenant B\nPolicies & SLAs"] PC["Tenant C\nPolicies & SLAs"]
    end
    block:NET["Network Isolation (VLANs)"]
        columns 3
        VA["VLAN 100"] VB["VLAN 200"] VC["VLAN 300"]
    end
    block:ENC["Per-Tenant Encryption"]
        columns 3
        EA["Key A"] EB["Key B"] EC["Key C"]
    end
    block:NS["Namespace Isolation"]
        columns 3
        NA["Namespace A"] NB["Namespace B"] NC["Namespace C"]
    end
    block:HW["Shared Cohesity Cluster Hardware"]
        columns 1
        DISK["Storage Pool / Nodes"]
    end

For cost optimization, service providers can optionally enable cross-tenant deduplication, which provides 5-10% additional storage efficiency. However, this shares a single encryption key across tenants while maintaining management-level isolation. Organizations with strict compliance requirements may choose to forgo this optimization in favor of fully independent encryption. [Source: https://www.cohesity.com/blogs/per-tenant-data-security-service-at-provider-scale/]

7.2.3 Tenant Administrator Delegation and Scope Limitations

Within each Organization, an admin user manages other users in that Organization. This delegation model enables each tenant to apply its own authentication controls: [Source: https://www.cohesity.com/blogs/multi-tenancy-meets-simplicity/]

• Configure tenant-specific password policies
• Enable and configure multi-factor authentication (MFA) with third-party identity providers (Okta, Ping, Cisco Duo)
• Assign RBAC roles within the Organization’s scope
• Create and manage Protection Groups for the tenant’s assigned resources

Tenant administrators operate within strict boundaries — they can only see and manage resources that have been assigned to their Organization. They cannot view other Organizations, access cluster-level settings, or modify the infrastructure shared across tenants.

Self-service capabilities extend tenant administrator delegation through pre-built integrations with:

• VMware vCloud Director (tenant portal for backup/recovery)
• ServiceNow (IT service management workflows)
• VMware vRealize Suite (cloud management)
• Cohesity REST APIs (custom portal development)

[Source: https://www.cohesity.com/blogs/multi-tenancy-meets-simplicity/]

7.2.4 Cross-Tenant Security Boundaries and Enforcement

Cohesity’s multi-tenancy security boundaries are enforced through a combination of technical controls aligned with Zero Trust principles: [Source: https://www.cohesity.com/blogs/per-tenant-data-security-service-at-provider-scale/]

• Data boundaries restrict user access to specific VMs, vCenters, NAS shares, or resource pools
• Fine-grain RBAC controls enable custom roles scoped per data source within an Organization
• Machine-learning anomaly detection monitors each tenant’s backup data ingestion rate and data entropy to detect potential ransomware attacks, triggering alerts for rapid recovery from healthy snapshots [Source: https://www.cohesity.com/blogs/per-tenant-data-security-service-at-provider-scale/]

Worked Example: Onboarding a New Tenant

A managed service provider (MSP) wants to onboard “Acme Corp” as a new backup-as-a-service customer:

1. Create a new Organization named “Acme-Corp” on the Cohesity cluster
2. Assign VLAN 150 to the Acme-Corp Organization for network isolation
3. Register Acme Corp’s Active Directory domain within the Organization
4. Create a tenant admin account and assign the Admin role scoped to Acme-Corp
5. Assign VMware vCenter resources (Acme’s VMs and resource pools) to the Organization
6. The tenant admin logs in and sees only Acme-Corp resources, creates protection policies, and manages backups independently

The MSP retains cluster-level administration but cannot access Acme Corp’s backup data or encryption keys.

Key Takeaway: Cohesity Organizations provide multi-tenancy through namespace isolation, per-tenant encryption, VLAN segmentation, and management-level access controls. Tenant administrators operate within strict boundaries and cannot access resources outside their Organization. Service providers cannot decrypt tenant data even with physical hardware access.

7.3 Quorum Groups for Privileged Actions

A Quorum is a multi-person authorization mechanism that requires a predefined number of approvers to sign off on a sensitive operation before it executes. Cohesity’s Quorum Groups feature ensures that no single administrator — even one with Super Admin privileges — can unilaterally perform critical operations such as deleting backups, modifying security settings, or disabling protection policies. [Source: https://se-baas1.aas.netnordic.net/docs/UserGuide/Content/Helios/quorum-approvals.htm]

The real-world analogy is a bank vault that requires two keys turned simultaneously: no single person, no matter how trusted, can open it alone.

7.3.1 The Quorum Concept: Multi-Person Authorization

Quorum Groups address a fundamental security risk: the single-point-of-compromise scenario. If a highly privileged administrator account is compromised by an attacker, or if an insider acts maliciously, quorum protection prevents that single identity from executing destructive operations. [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/white-paper/cohesity-platform-security-white-paper-en.pdf]

The approval workflow operates as follows:

User initiates        Quorum members         Threshold met?        Operation
protected       -->   receive request   -->  Yes --> Execute  
operation              for approval           No  --> Denied/Pending
                           |
                    Auto-approved if
                    requester is a
                    quorum member

1. A user initiates a quorum-protected operation
2. If the requester is a quorum member, their request counts as one automatic approval
3. Other quorum group members review the request in the Quorum Dashboard (pending request tab)
4. Each approver can approve or decline the request
5. When the minimum approval threshold is reached within the configured time limit, the operation executes immediately

[Source: https://se-baas1.aas.netnordic.net/docs/UserGuide/Content/Helios/quorum-approvals.htm]

Figure 7.4: Quorum approval workflow for a protected operation

flowchart TD
    START["User initiates\nprotected operation"] --> CHECK{"Is user a\nquorum member?"}
    CHECK -- Yes --> AUTO["Auto-approve\n(count = 1)"]
    CHECK -- No --> PENDING["Request pending\n(count = 0)"]
    AUTO --> DASH["Request appears in\nQuorum Dashboard"]
    PENDING --> DASH
    DASH --> REVIEW["Quorum members\nreview request"]
    REVIEW --> APPROVE["Member clicks\nApprove"]
    REVIEW --> DECLINE["Member clicks\nDecline"]
    APPROVE --> THRESH{"Approval count\n>= threshold\n(n/2 + 1)?"}
    THRESH -- Yes --> EXEC["Operation\nexecutes immediately"]
    THRESH -- No --> DASH
    DECLINE --> DENIED["Request denied\nor remains pending"]

7.3.2 Configuring Quorum Groups and Approval Workflows

Cohesity provides predefined templates that identify which sensitive or privileged operations should be included in a quorum group. These templates are the recommended starting point — Cohesity advises against manually selecting individual operations unless instructed by Cohesity Support. [Source: https://se-baas1.aas.netnordic.net/docs/UserGuide/Content/Dashboard/Admin/quorum-protected-operations.htm]

Approval Thresholds

The approval threshold defines how many members must approve before an operation proceeds. This can range from a single approval to unanimous approval (every member of the quorum group). [Source: https://se-baas1.aas.netnordic.net/docs/UserGuide/Content/Helios/quorum-approvals.htm]

Cohesity recommends using the formula:

Minimum approvals = n/2 + 1

Where n is the total number of members in the quorum group. [Source: https://se-baas1.aas.netnordic.net/docs/UserGuide/Content/Dashboard/Admin/quorum-protected-operations.htm]

Worked Example: Quorum Approval in Action

Consider a quorum group with 3 members (Alice, Bob, and Carol), with the approval threshold set to 2:

1. Alice initiates a request to delete an expired protection policy
2. Because Alice is a quorum member, her request is auto-approved (count: 1 of 2)
3. Bob reviews the request in the Quorum Dashboard and clicks Approve (count: 2 of 2)
4. The threshold is met — the deletion executes immediately
5. Carol’s approval is not needed since the threshold was already reached

If Alice were not a quorum member, she would initiate the request but it would start at 0 approvals, requiring two quorum members (e.g., Bob and Carol) to approve.

7.3.3 Operations Requiring Quorum Approval

Quorum protection is designed for operations that, if performed maliciously or accidentally, could cause significant damage. While the exact operations depend on the predefined template selected, typical quorum-protected operations include:

• Deleting or modifying protection policies
• Disabling or deleting Protection Groups
• Modifying security configurations
• Deleting Views or storage domains
• Changing cluster-level settings
• Vault operations (e.g., FortKnox cloud vault changes) [Source: https://aws.amazon.com/blogs/apn/defending-against-ransomware-with-aws-and-cohesity-fortknox/]

[Source: https://se-baas1.aas.netnordic.net/docs/UserGuide/Content/Dashboard/Admin/quorum-protected-operations.htm]

7.3.4 Quorum as a Defense Against Insider Threats and Compromised Accounts

A critical design principle of Cohesity’s Quorum implementation is the separation between operational authority and approval authority: quorum approvers who approve an operation request do not need an RBAC role with permission to initiate that operation. RBAC controls who can initiate; Quorum controls who can approve. [Source: https://se-baas1.aas.netnordic.net/docs/UserGuide/Content/Helios/quorum-approvals.htm]

This separation provides defense in depth against multiple threat scenarios:

Quorum Groups integrate with Cohesity’s broader security architecture through audit logging of all quorum-protected operations and approval decisions, providing a complete trail for compliance and forensic review. [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/white-paper/cohesity-platform-security-white-paper-en.pdf]

Key Takeaway: Quorum Groups require multiple people to approve sensitive operations before they execute, preventing any single compromised or malicious administrator from causing damage. Use the n/2+1 formula for approval thresholds and start with Cohesity’s predefined templates to identify which operations to protect.

7.4 Access Control Best Practices

The three mechanisms covered in this chapter — RBAC, multi-tenancy, and Quorum — are most effective when combined with disciplined operational practices.

7.4.1 Separation of Duties in Cohesity Administration

Separation of duties is the principle that no single person should control all aspects of a critical process. In Cohesity administration, this translates to:

• Separate operational and approval authority: Use Quorum Groups so that the person who initiates an action is not the sole approver. As noted earlier, quorum approvers do not need the RBAC permission to initiate the operation they approve. [Source: https://se-baas1.aas.netnordic.net/docs/UserGuide/Content/Helios/quorum-approvals.htm]
• Separate backup administration from security administration: Use different custom roles for teams managing protection policies versus teams managing access controls and encryption settings
• Separate tenant administration from platform administration: In multi-tenant environments, tenant admins manage their own users and policies while platform admins manage infrastructure

A practical separation model:

7.4.2 Regular Access Reviews and Permission Auditing

Access controls degrade over time as people change roles, leave the organization, or accumulate permissions. Maintain hygiene through:

• Periodic access reviews: Quarterly review of all user-to-role mappings to identify stale accounts and excessive permissions
• Quorum group maintenance: Periodically review the lists of quorum approvers and remove users no longer responsible for approving operations [Source: https://se-baas1.aas.netnordic.net/docs/UserGuide/Content/Dashboard/Admin/quorum-protected-operations.htm]
• SSO/AD integration audit: Verify that AD group memberships still reflect current job functions, since group membership drives Cohesity role assignment
• Privilege escalation monitoring: Leverage Cohesity’s built-in privilege escalation controls that prevent users from granting themselves unauthorized access [Source: https://www.linkedin.com/pulse/mastering-cohesity-dataplatform-deep-dive-granular-access-riegel]
• Audit log review: Examine quorum approval decisions and administrative actions for anomalies

7.4.3 Break-Glass Procedures for Emergency Access

Even with strict access controls, organizations need a way to perform emergency operations when normal approval workflows are unavailable (e.g., quorum members unreachable during an outage). A break-glass procedure provides emergency access under controlled conditions:

1. Document the procedure: Define exactly which emergency scenarios warrant break-glass access and who is authorized to invoke it
2. Use the Cohesity Support Admin role: This built-in role exists specifically for scenarios where customers lose access — it allows Cohesity support to create a Super Admin user [Source: https://docs.cohesity.com/disaster-recovery/site-continuity/vmware-vms/initial-setup/access-management.htm]
3. Seal and audit: After the emergency, immediately review all actions taken during the break-glass period, reset any temporary credentials, and document the incident
4. Test periodically: Run break-glass drills to ensure the procedure works when needed

Key Takeaway: Effective access control requires ongoing operational discipline: enforce separation of duties through role and quorum design, conduct regular access reviews, and maintain documented break-glass procedures for emergencies.

Chapter Summary

This chapter covered the three pillars of access control on the Cohesity Data Cloud:

1. RBAC provides the foundation, with over a dozen built-in roles and the ability to create custom roles with granular privileges across categories like DataProtect Services, Recovery Management, and Source Access Control. Roles are assigned through local accounts, Active Directory groups, or SSO claims from identity providers like Azure AD and Okta.

2. Multi-Tenancy through Organizations enables service providers and large enterprises to host multiple tenants on shared infrastructure while maintaining strict isolation through namespace separation, per-tenant encryption, VLAN segmentation, and management-level access controls. Tenant administrators manage their own environments independently.

3. Quorum Groups add a critical layer of protection for sensitive operations by requiring multi-person approval before execution. The separation of operational authority (RBAC) from approval authority (Quorum) implements true separation of duties and defends against insider threats and compromised credentials.

These three mechanisms work together: RBAC controls what actions a user can initiate, Organizations scope those actions to a specific tenant boundary, and Quorum ensures that the most critical actions require consensus before proceeding.

Figure 7.5: How RBAC, Organizations, and Quorum work together as layered access control

flowchart LR
    USER["User attempts\nan action"] --> RBAC{"RBAC Check:\nDoes the user's role\ngrant this permission?"}
    RBAC -- No --> DENY1["Access Denied"]
    RBAC -- Yes --> ORG{"Organization Check:\nIs the target resource\nwithin the user's\nOrganization scope?"}
    ORG -- No --> DENY2["Access Denied"]
    ORG -- Yes --> QUORUM{"Quorum Check:\nIs this a\nprotected operation?"}
    QUORUM -- No --> ALLOW["Action Executes"]
    QUORUM -- Yes --> APPROVAL["Quorum Approval\nWorkflow Triggered"]
    APPROVAL --> APPROVED{"Threshold\nmet?"}
    APPROVED -- Yes --> ALLOW
    APPROVED -- No --> DENY3["Action Blocked"]

Key Terms

Chapter 8: Monitoring, Auditing & Threat Detection

A backup platform is only as secure as your ability to see what is happening inside it. Firewalls, encryption, and access controls are preventive measures — they try to stop bad things from happening. Monitoring, auditing, and threat detection are detective measures — they tell you when something bad is happening or has already happened. Think of it this way: locks on a building keep intruders out, but security cameras and alarm systems tell you when someone has breached those locks. In the Cohesity ecosystem, audit logs are your cameras, syslog forwarding is your centralized security operations center, DataHawk is your threat intelligence team, and alerting is your alarm system.

This chapter covers the full monitoring and detection stack available to Cohesity administrators, from configuring audit trails that satisfy compliance auditors to deploying AI-driven ransomware detection that can catch attacks in progress.

Learning Objectives

By the end of this chapter, you will be able to:

• Configure comprehensive audit logging on Cohesity clusters
• Set up remote syslog forwarding to centralized log management systems
• Implement ransomware and data breach monitoring using Cohesity DataHawk
• Design alerting strategies for security events and cluster health

8.1 Audit Logging

Every action taken on a Cohesity cluster — whether a user modifies a protection policy, restores a virtual machine, or simply logs in — can be recorded in an audit log. An audit log is a chronological record of system events that captures who did what, when, and from where. These logs are the foundation of security investigations, compliance reporting, and operational troubleshooting.

8.1.1 Cohesity Audit Log Architecture and Log Types

Cohesity DataPlatform’s audit capabilities allow administrators to monitor clusters for access events, changes to files and folders, modifications to shares and permissions, and configuration changes to the clusters themselves. [Source: https://www.cohesity.com/forms/white-paper/leverage-the-configuration-and-protocol-audit-capabilities-of-cohesity-dataplatform/]

To view and configure audit logs, navigate to System > Audit Logs > Log Settings in the Cohesity management interface. [Source: https://docs.cohesity.com/baas/data-protect/audit-logs-dataprotect.htm]

Audit logs record two primary event types:

• Write actions — changes to configuration, data, or system state (displayed by default)
• Read actions — viewing or accessing data and settings (must be manually enabled via the Actions filter)

Each audit entry captures:

The system organizes logs into 18 predefined categories including API Key, Access Token, Alert, Protection Group, Protection Policy, Recovery Task, Region, Snapshot, User, and Tenant. Over 50 write action types are tracked, spanning the full operational lifecycle: Accept, Activate, Add, Create, Delete, Login, Logout, Modify, Recover, Update, Upgrade, and more. [Source: https://docs.cohesity.com/baas/data-protect/audit-logs-dataprotect.htm]

When forwarded via syslog, audit entries are tagged for easy identification and routing:

[Source: https://developers.cohesity.com/reference/addsyslogserver]

Real-world analogy: Think of audit log categories like departments in a company. Just as an accounting department tracks financial transactions and HR tracks personnel changes, cluster_audit tracks administrative actions while filesystem_audit tracks file-level access. Each department keeps its own ledger, but together they form a complete picture of everything that happens in the organization.

Figure 8.1: Audit log flow from cluster actions to syslog tags

flowchart LR
    A[Admin Action] --> B[Audit Engine]
    C[File Access] --> B
    D[Alert Event] --> B
    E[Backup/Recovery Job] --> B
    B --> F["cluster_audit"]
    B --> G["filesystem_audit"]
    B --> H["cohesity_alerts"]
    B --> I["dataprotection_events"]
    F --> J[Syslog Server / SIEM]
    G --> J
    H --> J
    I --> J

8.1.2 Configuring Audit Log Retention and Storage

Audit log retention determines how long historical records are preserved. Cohesity provides the following defaults and options:

[Source: https://docs.cohesity.com/baas/data-protect/audit-logs-dataprotect.htm]

Organizations subject to regulatory requirements should align retention periods with their compliance framework. For example, PCI DSS requires at least one year of audit log retention, while HIPAA mandates six years for certain records. Since Cohesity’s on-cluster maximum is 365 days, organizations requiring longer retention should use remote syslog forwarding (covered in Section 8.2) to archive logs in an external system with extended retention capabilities.

Audit logs can also be exported as CSV files, which provide more detail than what the Helios Dashboard displays, including IP addresses, tenant information, and impersonation data. This export capability is valuable for offline analysis and for providing evidence to auditors. [Source: https://docs.cohesity.com/baas/data-protect/audit-logs-dataprotect.htm]

8.1.3 Interpreting Audit Log Entries for Security Investigations

When investigating a security incident, audit logs are your primary forensic tool. Cohesity provides several filtering options to narrow down relevant events:

• Date Range — isolate events within a specific time window
• System — filter by Cloud Protection Service region
• Users — focus on activity from a specific user account
• Category — narrow to a specific functional area (e.g., Protection Policy, Recovery Task)
• Action — filter by read or write operations

[Source: https://docs.cohesity.com/baas/data-protect/audit-logs-dataprotect.htm]

Worked Example: Investigating an Unauthorized Policy Change

Suppose your organization discovers that a protection policy was modified to reduce snapshot retention from 30 days to 7 days — potentially leaving data unprotected. Here is how you would investigate:

1. Navigate to System > Audit Logs
2. Set the Date Range to the past two weeks (or the suspected time frame)
3. Set Category to “Protection Policy”
4. Set Action to write actions only
5. Review the results for “Modify” actions on the specific policy
6. Note the User, timestamp, and IP address (available in the CSV export)
7. Cross-reference the user account with your identity provider to determine if the action was authorized

If the user account was compromised, the IP address field in the CSV export can help trace the origin of the attack.

8.1.4 Compliance-Grade Audit Trails

For organizations in regulated industries, audit logs must meet specific standards to be considered “compliance-grade.” Key requirements typically include:

• Tamper-evidence — Logs must be protected from modification. Forwarding logs to an external syslog server (Section 8.2) creates a second copy outside the control of cluster administrators.
• Completeness — All security-relevant events must be captured. Enabling both read and write action logging ensures comprehensive coverage.
• Retention — Logs must be retained for the period required by the applicable regulation.
• Accessibility — Auditors must be able to review logs efficiently. CSV export and SIEM integration support this requirement.

Cohesity’s audit framework has undergone Common Criteria evaluation, which validates that the platform’s security logging meets internationally recognized standards. [Source: https://www.commoncriteriaportal.org/files/epfiles/Cohesity_ST_061519_v1.0.pdf]

Key Takeaway: Cohesity audit logs capture 50+ action types across 18 categories with configurable retention from 90 to 365 days. For security investigations, use the filtering tools to isolate events by time, user, category, and action type. For compliance, enable both read and write logging, configure appropriate retention, and forward logs to an external system for tamper-resistant archival.

8.2 Remote Syslog and Log Management

On-cluster audit logs are useful, but they have limitations: they are stored on the same system they are monitoring, their retention maxes out at 365 days, and they cannot easily be correlated with events from other infrastructure. Remote syslog forwarding solves these problems by shipping log data to a centralized log management platform in real time.

Syslog (System Logging Protocol) is a standard protocol for transmitting log messages across a network. It allows devices and applications from different vendors to send their logs to a single collection point, enabling centralized analysis and correlation.

8.2.1 Configuring Remote Syslog Server Integration

Cohesity supports forwarding audit logs to one or more external syslog servers. Configuration is performed through the web interface. [Source: https://developers.cohesity.com/reference/addsyslogserver]

Configuration Steps:

1. Navigate to Settings > Summary and select the Syslog tab
2. Click +Add at the top-right of the page
3. Configure the following parameters:

[Source: https://developers.cohesity.com/reference/addsyslogserver]

Real-world analogy: Configuring syslog forwarding is like setting up a mail forwarding service. Instead of keeping all your mail at your local post office (on-cluster logs), you tell the post office to forward copies of everything to your home address (centralized SIEM). This way, even if the local post office burns down, you still have all your records.

Figure 8.2: Remote syslog forwarding architecture with protocol options

flowchart TD
    subgraph Cohesity Cluster
        A[Audit Logs] --> B[Syslog Forwarder]
    end
    B -->|UDP Port 514| C[Syslog Server]
    B -->|TCP Port 601| C
    B -->|TCP+TLS Port 6514| C
    C --> D[Splunk]
    C --> E[Google Chronicle]
    C --> F[ELK Stack]
    C --> G[Other SIEM]

Protocol Selection Guidance:

TLS encryption is supported independently and as part of HTTPS for trusted communications. You can enable encryption between the Cohesity cluster and the syslog server and configure mutual authentication. [Source: https://www.commoncriteriaportal.org/files/epfiles/Cohesity_ST_061519_v1.0.pdf]

The Cohesity Security Hardening Guide recommends enabling remote syslog forwarding to assure log availability and integrity — if an attacker compromises the cluster, off-cluster log copies remain intact. [Source: https://www.scribd.com/document/794868665/Cohesity-Best-Practice-Security-Hardening-Guide]

8.2.2 Syslog Format and Field Mapping

When Cohesity forwards logs via syslog, each message is tagged with one of the four log type identifiers (cluster_audit, filesystem_audit, cohesity_alerts, dataprotection_events). These tags allow the receiving SIEM or log management platform to parse, categorize, and route messages appropriately.

A typical syslog message from Cohesity includes:

• Facility and severity — Standard syslog priority values
• Timestamp — When the event occurred
• Hostname — The Cohesity cluster node that generated the event
• Tag — One of the four Cohesity-specific log tags
• Message body — Structured data including the user, action, target object, and result

Understanding this field mapping is critical when building dashboards, alerts, and correlation rules in your SIEM platform.

8.2.3 Integration with Splunk, ELK, and Other SIEM Platforms

A SIEM (Security Information and Event Management) platform collects, normalizes, and analyzes log data from across the enterprise to detect threats and support compliance reporting. Cohesity Data Cloud can fully integrate with external SIEM and log monitoring solutions by exporting platform logs in open format or through syslog to third-party applications. [Source: https://www.scribd.com/document/794868665/Cohesity-Best-Practice-Security-Hardening-Guide]

Splunk Integration

Splunk Connect for Syslog provides a pre-built integration for Cohesity cluster logs. Once syslog forwarding is configured on the Cohesity side, Splunk can ingest, index, and analyze the log data using its standard syslog input. This enables security teams to correlate Cohesity backup events with other infrastructure logs (firewall, endpoint, identity) in a single pane of glass. [Source: https://splunk.github.io/splunk-connect-for-syslog/main/sources/vendor/Cohesity/cluster/]

Google Chronicle (Security Operations)

Google Security Operations (Chronicle) supports Cohesity log ingestion via its default parser, enabling automated normalization and threat detection against Cohesity audit data. [Source: https://cloud.google.com/chronicle/docs/ingestion/default-parsers/cohesity]

ELK Stack (Elasticsearch, Logstash, Kibana)

For organizations using the ELK stack, Cohesity syslog output can be received by Logstash, parsed using the syslog tags, stored in Elasticsearch, and visualized in Kibana dashboards. While there is no Cohesity-specific ELK plugin, the standard syslog format makes integration straightforward.

Cohesity Marketplace Apps

Organizations can also integrate Cohesity with SIEM tools via apps available on the Cohesity Marketplace, providing pre-built connectors and dashboards for common platforms. [Source: https://www.cohesity.com/blogs/introducing-cohesity-datahawk/]

Key Takeaway: Remote syslog forwarding is a security best practice that provides tamper-resistant log archival, extended retention, and cross-platform correlation. Configure it via Settings > Summary > Syslog using TCP with TLS for production environments. Cohesity integrates with Splunk, Google Chronicle, and ELK through standard syslog protocols and marketplace apps.

8.3 Ransomware and Breach Monitoring

Audit logs and syslog forwarding tell you what administrators and users are doing. But what about threats that target the data itself — ransomware encrypting files, malware hiding in backups, or sensitive data being exfiltrated? This is where Cohesity DataHawk enters the picture.

DataHawk is a SaaS-based security solution that combines three critical capabilities into a single offering: threat protection, ML-based data classification, and cyber vaulting via Cohesity FortKnox. [Source: https://www.cohesity.com/platform/datahawk/]

Real-world analogy: If your backup infrastructure is a warehouse storing valuable goods, DataHawk is the combination of a K-9 unit (sniffing out threats), an inventory specialist (classifying what you have), and an armored vault (protecting the most critical items). Each capability reinforces the others.

Figure 8.3: DataHawk three-pillar architecture

flowchart TD
    A[Cohesity DataHawk] --> B[Threat Protection]
    A --> C[Data Classification]
    A --> D[Cyber Vaulting - FortKnox]
    B --> B1[Deep Learning Ransomware Detection]
    B --> B2[IOC Scanning - 100K+ Indicators]
    B --> B3[Custom YARA Rules]
    C --> C1[200+ ML Classifiers]
    C --> C2[50+ Compliance Policies]
    D --> D1[Immutable Backup Copies]
    D --> D2[Air-Gapped Storage]

8.3.1 Cohesity DataHawk Threat Detection Capabilities

DataHawk uses a deep learning-based ransomware detection engine that scans backup data for anomalous behavior, potential threats, and indicators of possible ransomware attacks. Critically, this scanning occurs on backup data without impacting production systems — your primary workloads continue running at full performance while DataHawk inspects their backup copies. [Source: https://www.cohesity.com/blogs/introducing-cohesity-datahawk/]

The platform features automated and extensible threat feeds that eliminate the need for manual threat signature updates. These curated IOC threat feeds are updated daily, ensuring detection capabilities keep pace with the evolving threat landscape. [Source: https://www.cohesity.com/platform/datahawk/]

DataHawk integrates with existing security tools including CrowdStrike, Microsoft Sentinel, Palo Alto, Cisco SecureX, and others. This means threat feeds or alerting from other security products can be ingested directly into Cohesity, and DataHawk alerts can be embedded into incident response playbooks for streamlined SOC operations. [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/solution-brief/cisco-cohesity-datahawk-solution-brief-en.pdf]

DataHawk supports threat protection scanning for physical servers, Hyper-V environments, Acropolis (AHV) Objects, and Cohesity Helios-managed clusters. [Source: https://www.cohesity.com/blogs/cohesity-datahawk-updates-what-you-need-to-know/]

8.3.2 Anomaly Detection for Backup Data Patterns

DataHawk’s anomaly detection engine constantly scans indexed backups, utilizing an AI/ML engine to apply an anomaly strength score to each backup. When this score exceeds a threshold defined by the organization, it can trigger targeted automations — such as alerts, additional scans, or protective actions. [Source: https://www.cohesity.com/blogs/cohesity-datahawk-continuing-the-ai-ml-transformation-of-data-security-and-management/]

The system specifically monitors for:

• Encryption activity — sudden, widespread file encryption is a hallmark of ransomware
• Abnormal data volume fluctuations — unexpected increases or decreases in backup size
• Password change patterns — mass password resets could indicate account takeover
• User behavior anomalies — unusual access patterns that could indicate insider threats or compromised accounts

[Source: https://www.cohesity.com/blogs/cohesity-datahawk-updates-what-you-need-to-know/]

One specific alert to know is the DataIngestAnomalyAlert (CE01516011), which fires at Warning severity when an anomalous change in the data ingest rate for a protected source is detected. This alert has an interval of 3600 seconds (1 hour) and may indicate a ransomware attack on the primary environment. When triggered, the recommended response is to restore the source from a snapshot using Instant Recovery with the most recent clean snapshot. [Source: https://docs.cohesity.com/baas/data-protect/alerts/security-alerts.htm]

Worked Example: Anomaly Detection in Action

Consider a file server that normally produces 50 GB of changed data per daily backup. One day, DataHawk’s ML engine detects that the change rate has jumped to 400 GB — an 8x increase. The anomaly strength score exceeds the configured threshold, triggering the following sequence:

1. DataHawk fires a DataIngestAnomalyAlert
2. The alert is forwarded via syslog to the organization’s SIEM
3. A SIEM correlation rule matches the anomaly with a recent failed login attempt on the file server
4. An automated playbook creates a ServiceNow incident and pages the on-call security analyst
5. The analyst reviews the backup and confirms ransomware encryption
6. The team initiates Instant Recovery from the last clean snapshot

This sequence illustrates how monitoring, syslog forwarding, SIEM integration, and alerting work together as a detection and response pipeline.

Figure 8.4: Anomaly detection and incident response sequence

sequenceDiagram
    participant FS as File Server
    participant DH as DataHawk ML Engine
    participant Alert as Alert System
    participant SIEM as SIEM Platform
    participant SOC as Security Analyst
    FS->>DH: Backup data (8x change rate spike)
    DH->>DH: Anomaly score exceeds threshold
    DH->>Alert: DataIngestAnomalyAlert fired
    Alert->>SIEM: Syslog forward
    SIEM->>SIEM: Correlate with failed logins
    SIEM->>SOC: PagerDuty/ServiceNow incident
    SOC->>SOC: Confirm ransomware encryption
    SOC->>FS: Initiate Instant Recovery from clean snapshot

8.3.3 IOC (Indicators of Compromise) Scanning

IOC scanning is the process of comparing files and data against known signatures of malicious software. An Indicator of Compromise (IOC) is a piece of forensic evidence — such as a file hash, filename pattern, or network behavior — that indicates a system has been compromised.

DataHawk’s threat scans analyze files and data using 100,000+ Indicators of Compromise and custom YARA rules to hunt for malware in backup data. [Source: https://www.cohesity.com/platform/datahawk/]

YARA rules are a pattern-matching language used by security researchers to identify and classify malware. They allow analysts to create descriptions of malware families based on textual or binary patterns. DataHawk supports custom YARA rule creation for advanced threat identification targeting specific environments.

IOC detection covers three categories:

[Source: https://www.cohesity.com/platform/datahawk/]

Users can schedule both threat and data classification scans with flexible options: single execution or recurring intervals at specified frequencies. This allows organizations to balance thoroughness with resource consumption. [Source: https://www.cohesity.com/blogs/cohesity-datahawk-updates-what-you-need-to-know/]

8.3.4 Data Classification and Sensitive Data Discovery

Data classification is the process of identifying, categorizing, and labeling data based on its sensitivity and regulatory significance. Knowing what data you have — and where it lives — is essential for understanding the impact of a breach.

DataHawk leverages classification technology from BigID to accurately discover and classify large data sets at scale. [Source: https://www.businesswire.com/news/home/20221115005648/en/Cohesity-Announces-DataHawk---Providing-Protection-Detection-and-Recovery-Against-Cyberattacks-All-From-a-Single-SaaS-Security-Offering]

The solution provides:

[Source: https://www.cohesity.com/blogs/cohesity-datahawk-continuing-the-ai-ml-transformation-of-data-security-and-management/]

Data classification adds critical context during an incident. When ransomware strikes, the first question executives ask is: “What data was affected?” Without classification, answering that question requires manual analysis of potentially millions of files. With DataHawk’s classification labels already in place, the security team can immediately report which sensitive data sets were in the blast radius — whether PII subject to breach notification laws, financial records under PCI scope, or health records governed by HIPAA.

Key Takeaway: DataHawk combines deep learning-based ransomware detection, 100K+ IOC scanning with custom YARA rules, AI/ML anomaly detection with configurable thresholds, and BigID-powered data classification with 200+ classifiers. Together, these capabilities let organizations detect threats in backup data, understand the sensitivity of affected data, and respond with confidence — all without impacting production workloads.

8.4 Alerting and Notification

Detection is only valuable if the right people are notified at the right time. Cohesity provides a flexible alerting framework that routes notifications through multiple channels based on severity, category, and organizational escalation procedures.

8.4.1 Cluster Alert Configuration and Severity Levels

Cohesity Cloud Protection Service creates alerts for a wide range of conditions, each assigned a severity rating. [Source: https://docs.cohesity.com/baas/data-protect/alerts/alerts.htm]

Alert notification rules are configured from the Health > Notification tab, where administrators can create rules that match specific alert categories, severities, and names to specific notification channels. [Source: https://docs.cohesity.com/baas/data-protect/alerts/configure-alert-notification-rule.htm]

8.4.2 Email, SNMP, and Webhook Notification Channels

Cohesity supports four notification delivery methods, each suited to different operational workflows:

Email Notifications

The most straightforward channel. Configure recipient email addresses and Cohesity sends alert details directly to individual inboxes or distribution lists. Best for small teams or as a backup notification method.

SNMP Trap Notifications

SNMP (Simple Network Management Protocol) is a standard protocol for monitoring and managing network devices. Cohesity can send SNMP trap notifications to network management systems (such as Nagios or SolarWinds) when alerts are triggered. Configuration is found at Settings > Cluster > SNMP. [Source: https://helios.cohesity.com/docs/UserGuide/Content/Dashboard/Admin/SNMP.htm]

SNMP is ideal for organizations that already have a centralized network operations center (NOC) monitoring infrastructure health via SNMP.

Syslog Forwarding

Alerts can also be forwarded to syslog servers using the cohesity_alerts tag, integrating directly with the SIEM pipeline described in Section 8.2.

Webhook Notifications

Webhooks are HTTP callbacks — when an event occurs, Cohesity sends an HTTP POST request to a configured URL, triggering an action on another system. [Source: https://www.cohesity.com/blogs/custom-payload-template-webhooks-integration-with-cohesity-made-easy/]

To create a webhook notification rule:

1. Navigate to Health > Notification
2. Click Create > New Alert Notification Rule
3. Select Webhook in the Notification Method section
4. Provide the target URL and cURL options

Cohesity supports sending webhook payloads in any customized format using a template with placeholders. These placeholders are keywords that get resolved to the actual values of the generated alert at delivery time. This flexibility allows integration with virtually any system that accepts HTTP requests. [Source: https://www.cohesity.com/blogs/custom-payload-template-webhooks-integration-with-cohesity-made-easy/]

The following table summarizes when to use each channel:

8.4.3 Alert Escalation and Response Procedures

A well-designed alerting strategy goes beyond simply sending notifications. It defines who gets notified, when, and what they should do about it. Here is a recommended escalation framework for Cohesity security alerts:

Tier 1 — Automated Response

• Trigger: Informational alerts, routine operational events
• Action: Log to SIEM, no human notification required
• Channel: Syslog only

Tier 2 — Operational Notification

• Trigger: Warning alerts, non-critical anomalies
• Action: Notify the operations team for investigation within business hours
• Channel: Email + SIEM logging

Tier 3 — Security Escalation

• Trigger: DataIngestAnomalyAlert, IOC scan matches, critical severity alerts
• Action: Immediate notification to the security team; create incident ticket
• Channel: Webhook to ServiceNow/PagerDuty + email to security on-call + SIEM

Figure 8.5: Tiered alert escalation framework

flowchart TD
    A[Cohesity Alert Generated] --> B{Severity?}
    B -->|Informational| C[Tier 1: Automated]
    B -->|Warning| D[Tier 2: Operational]
    B -->|Critical| E[Tier 3: Security Escalation]
    C --> C1[Log to SIEM only]
    D --> D1[Email to Ops Team]
    D --> D2[Log to SIEM]
    E --> E1[Webhook to PagerDuty/ServiceNow]
    E --> E2[Email to Security On-Call]
    E --> E3[Log to SIEM]
    E1 --> F[Incident Created]

Third-Party Integration Options

Cohesity’s alerting framework integrates with several incident management platforms:

[Source: https://www.cohesity.com/blogs/use-webhooks-to-manage-cohesity-alerts-in-servicenow/] [Source: https://www.cohesity.com/blogs/manage-your-cohesity-alerts-using-pagerduty/] [Source: https://www.cohesity.com/blogs/backup-and-recovery-infrastructure-monitoring-with-nagios/] [Source: https://www.logicmonitor.com/support/monitoring/storage-systems/cohesity-dataprotect-and-dataplatform-monitoring]

Cohesity also offers System Health Insights, a SaaS-based platform that uses artificial intelligence and machine learning to analyze Call Home data, monitor the health and operational state of appliances, and proactively alert administrators to potential problems before they become incidents. [Source: https://www.scribd.com/document/794868665/Cohesity-Best-Practice-Security-Hardening-Guide]

Key Takeaway: Cohesity supports four notification channels — email, SNMP, syslog, and webhooks — each configurable with rules based on alert category, severity, and name. Design a tiered escalation strategy that matches alert severity to response urgency, and integrate with platforms like ServiceNow and PagerDuty to automate incident management workflows.

Chapter Summary

This chapter covered the four pillars of Cohesity’s monitoring and detection framework:

1. Audit Logging provides a detailed record of every action on the cluster, with 18 categories, 50+ action types, and configurable retention from 90 to 365 days. Enable both read and write logging for comprehensive coverage, and export to CSV for forensic investigations.

2. Remote Syslog and Log Management extends audit logging by forwarding events to centralized SIEM platforms. Use TCP with TLS for secure, reliable delivery. Pre-built integrations exist for Splunk, Google Chronicle, and other platforms.

3. Ransomware and Breach Monitoring through DataHawk brings AI/ML-powered threat detection to backup data. The combination of deep learning ransomware detection, 100K+ IOC scanning, anomaly strength scoring, and BigID-powered data classification enables organizations to detect, assess, and respond to threats without impacting production.

4. Alerting and Notification closes the loop by ensuring the right people learn about threats at the right time. Four delivery channels (email, SNMP, syslog, webhooks) support a tiered escalation strategy, with integrations into ServiceNow, PagerDuty, and other incident management platforms.

Together, these capabilities form a detection and response pipeline: audit logs capture events, syslog forwards them to a central platform, DataHawk scans for threats in backup data, and alerting notifies the appropriate teams to take action.

Key Terms

Chapter 9: Incident Response & Remediation

Learning Objectives

After completing this chapter, you will be able to:

• Execute incident recovery procedures using Cohesity’s recovery capabilities
• Perform clean room recovery and isolated recovery environment (IRE) operations
• Implement rapid mass restore procedures for ransomware recovery scenarios
• Design and test incident response plans that leverage Cohesity backup infrastructure

9.1 Incident Response Framework

When a cyberattack strikes, the difference between a contained incident and a full-blown catastrophe often comes down to how well-prepared the response team is. Think of incident response like a fire department: you do not wait until a building is ablaze to figure out where the hydrants are, who drives the truck, and how the hoses connect. Everything is planned, practiced, and ready to execute under pressure. In this section, we examine how the NIST incident response lifecycle applies to data protection and how Cohesity integrates into an organization’s broader incident response strategy.

NIST Incident Response Lifecycle Applied to Data Protection

The National Institute of Standards and Technology (NIST) defines a four-phase incident response lifecycle that serves as the industry standard framework:

Figure 9.1: NIST Incident Response Lifecycle with Cohesity Integration

flowchart LR
    A["1. Preparation\n- Backup policies\n- FortKnox vaulting\n- Anomaly detection\n- IR simulations"] --> B["2. Detection &\nAnalysis\n- ML anomaly detection\n- CyberScan indexing\n- IoC feeds\n- MITRE ATT&CK mapping"]
    B --> C["3. Containment,\nEradication &\nRecovery\n- Clean room provisioning\n- Instant mass restore\n- Point-in-time recovery"]
    C --> D["4. Post-Incident\nActivity\n- Audit log analysis\n- Policy adjustments\n- Lessons learned"]
    D -->|"Continuous\nImprovement"| A

    style A fill:#2d6a4f,color:#fff
    style B fill:#e76f51,color:#fff
    style C fill:#264653,color:#fff
    style D fill:#6a4c93,color:#fff

Cohesity’s platform touches every phase of this lifecycle. During preparation, organizations configure immutable backup policies and establish isolated recovery environments. During detection and analysis, Cohesity’s agent-free threat detection scans backup data using curated Indicators of Compromise (IoCs) — specific artifacts such as file hashes, IP addresses, or behavioral signatures that indicate malicious activity — mapped to the MITRE ATT&CK Framework. [Source: https://www.cohesity.com/blogs/data-clean-rooms-done-right-in-a-world-of-destructive-cyberattacks/] This detection operates passively, meaning adversaries cannot detect the monitoring activity, and it resists the evasion techniques that commonly disable traditional EDR/XDR tools. [Source: https://www.cohesity.com/solutions/clean-room/]

Cohesity also provides a Cyber Incident Response Simulator — a gamified training tool that allows teams to practice their response procedures in realistic scenarios before a real attack occurs. [Source: https://www.cohesity.com/incident-response-simulator/]

Roles and Responsibilities in Backup-Centric Incident Response

Effective incident response requires clearly defined roles that bridge the gap between security operations and IT operations. Cohesity stresses the integration of IT Operations and Security Operations teams on a single platform to improve both response speed and recovery efficiency. [Source: https://www.cohesity.com/solutions/clean-room/]

Communication and Escalation Procedures

During an incident, communication must follow predefined channels. A critical principle in Cohesity-based incident response is that compromised systems’ communication tools cannot be trusted. Organizations need secured backup copies containing collaboration and authentication tools — including Active Directory — stored in the cyber vault so that responders can establish trustworthy communication channels even when production systems are compromised. [Source: https://www.cohesity.com/blogs/data-clean-rooms-done-right-in-a-world-of-destructive-cyberattacks/]

Integrating Cohesity into Organizational IR Plans

Cohesity integrates into IR plans through three primary mechanisms:

1. CERT Partnerships: Cohesity maintains Cyber Event Response Team (CERT) partnerships with leading incident response firms, providing organizations with access to expert responders who understand the platform. [Source: https://www.cohesity.com/solutions/clean-room/]
2. Third-Party Tool Interoperability: The platform provides seamless integration with third-party security tools and services, allowing it to fit into existing security toolchains. [Source: https://www.cohesity.com/solutions/clean-room/]
3. Managed Recovery Services: Cohesity has partnered with 11:11 Systems to combine core clean room capabilities with cyber incident recovery and managed services expertise, offering a fully isolated clean room environment to identify clean, uncompromised data replicas and restore operations swiftly. [Source: https://www.cohesity.com/newsroom/press/cohesity-1111-systems-launch-clean-room-recovery-service/]

Key Takeaway: A well-integrated incident response plan positions Cohesity not just as a backup tool but as a core component of the security response lifecycle — from preparation through post-incident analysis. The integration of IT Ops and SecOps on a single platform is essential for rapid, coordinated recovery.

9.2 Recovery Procedures

If incident response is the fire department, then recovery procedures are the actual firefighting techniques. Knowing you have water is not enough — you need to know which hose to use, where to aim it, and in what order. Cohesity provides multiple recovery approaches, each suited to different scenarios ranging from a single corrupted file to a full-scale ransomware event affecting hundreds of virtual machines.

Point-in-Time Recovery and Snapshot Selection

Point-in-time recovery allows administrators to roll back data to a specific moment before a disruption occurred. Cohesity’s patented SnapTree technology uses a B+ tree metadata structure to create fully hydrated snapshots — meaning each snapshot is a complete, self-contained representation of the data at that point in time rather than a chain of incremental changes that must be reconstructed. [Source: https://www.cohesity.com/solutions/instant-mass-restore/]

To understand why this matters, consider a traditional backup approach as a series of handwritten recipe cards where each card only records changes from the previous one. To prepare Tuesday’s recipe, you need Monday’s card, plus Tuesday’s changes. To get to Friday, you must process every card in sequence. Cohesity’s fully hydrated snapshots are like having a complete, updated recipe book for every day — you simply open Friday’s book and start cooking.

Selecting the right recovery point is critical during a ransomware incident. Cohesity provides two key tools for this decision:

• CyberScan displays each snapshot’s vulnerability index and provides actionable recommendations, enabling operators to identify clean restore points and avoid re-injecting software vulnerabilities into production. [Source: https://www.cohesity.com/blogs/defend-against-ransomware-attacks-a-security-first-approach/]
• Helios anomaly detection uses machine learning to monitor daily logical/stored change rates, historical ingest patterns, and entropy levels, alerting administrators when patterns deviate significantly from normal baselines. [Source: https://www.cohesity.com/blogs/cohesity-protecting-backup-data-ransomware-customers-approve/]

Instant Mass Restore for Rapid Recovery at Scale

Instant mass restore is Cohesity’s capability for recovering hundreds of files, objects, VMs, and large databases simultaneously, reducing recovery time objectives (RTO) to minutes rather than hours or days. [Source: https://www.cohesity.com/solutions/instant-mass-restore/]

The five-step instant mass restore workflow proceeds as follows:

Figure 9.2: Instant Mass Restore Five-Step Workflow

flowchart TD
    S1["Step 1: Identify Clean Backup Data\n(CyberScan vulnerability index)"]
    S2["Step 2: Present NFS Datastore to ESX\n(QoS policies applied)"]
    S3["Step 3: Instantiate & Power On VMs\n(Fully hydrated snapshots)"]
    S4["Step 4: Storage vMotion Migration\n(Automated, non-disruptive)"]
    S5["Step 5: Cleanup Temporary Datastore"]

    S1 --> S2 --> S3 --> S4 --> S5

    style S1 fill:#e76f51,color:#fff
    style S2 fill:#264653,color:#fff
    style S3 fill:#2a9d8f,color:#fff
    style S4 fill:#e9c46a,color:#000
    style S5 fill:#6a4c93,color:#fff

Step 1 — Identify Clean Backup Data. Using CyberScan analysis and third-party tools, operators identify the most recent backup copy that was not infected. CyberScan’s vulnerability index provides a per-snapshot assessment of data cleanliness. [Source: https://www.cohesity.com/blogs/defend-against-ransomware-attacks-a-security-first-approach/]

Step 2 — Present Storage to ESX. An NFS datastore is presented from the Cohesity cluster directly to the ESX infrastructure. Because the storage runs on the Cohesity cluster itself, Quality of Service (QoS) policies can be applied to the presented storage — a significant advantage over competitors that rely on separate appliances. [Source: https://www.cohesity.com/blogs/cohesity-instant-mass-restore-better-solution-to-an-old-problem/]

Step 3 — Instantiate and Power On VMs. New virtual machines are created from the selected backup point and powered on from the temporary datastore. Because snapshots are fully hydrated, they can be instantly mounted and read by applications such as Oracle databases for immediate data access. [Source: https://www.cohesity.com/blogs/instant-and-non-disruptive-recovery-for-your-mission-critical-oracle-database/]

Step 4 — Storage vMotion Migration. Cohesity automates the complete storage vMotion process to move data from the Cohesity cluster to production storage non-disruptively, without requiring manual scripts. [Source: https://www.cohesity.com/blogs/cohesity-instant-mass-restore-better-solution-to-an-old-problem/]

Step 5 — Cleanup. The temporary datastore is removed after migration completes.

Worked Example: Ransomware Recovery of 50 VMs

An organization detects ransomware at 2:00 AM affecting 50 production VMs. The backup administrator opens CyberScan and identifies that yesterday’s 10:00 PM snapshot has a clean vulnerability index. Within minutes, the NFS datastore is presented to ESX, and all 50 VMs are instantiated from the clean snapshot. Applications come online immediately while storage vMotion runs in the background, transparently migrating data to production storage. By the time users arrive at 8:00 AM, the environment is fully restored. [Source: https://www.cohesity.com/blogs/validation-of-cohesity-accelerated-recovery-from-ransomware/]

Two additional technologies underpin this performance:

• MegaFile Technology distributes large files across cluster nodes for parallel operations, achieving 3x performance improvements demonstrated in real-world healthcare deployments. [Source: https://www.cohesity.com/solutions/instant-mass-restore/]
• SpanFS Distributed File System immediately surfaces data via NFS/SMB during background recovery, allowing applications to come online while restoration continues behind the scenes. [Source: https://www.cohesity.com/solutions/instant-mass-restore/]

Granular File and Object Recovery

Not every incident requires mass recovery. For targeted attacks or accidental deletions, Cohesity supports granular recovery of individual files and objects through Enterprise Search — a simple file name search that lets administrators select the most recent clean copy and click “Restore Now.” [Source: https://www.cohesity.com/solutions/instant-mass-restore/]

VM Recovery and Live Mount Operations

Live mount is a Cohesity capability that allows a VM to be booted directly from a backup snapshot without copying data to production storage first. This is particularly useful for:

• Rapid validation of backup integrity before committing to a full restore
• Running forensic analysis on a snapshot without affecting production
• Providing temporary access to applications while production recovery proceeds

Live mount operations leverage the fully hydrated snapshot architecture, meaning there is no performance penalty from incremental stitching during the mount. [Source: https://www.cohesity.com/solutions/instant-mass-restore/]

Key Takeaway: Cohesity’s SnapTree technology and fully hydrated snapshots eliminate the traditional bottleneck of incremental reconstruction, enabling instant mass restore of hundreds of VMs in minutes. The five-step workflow — identify, present, instantiate, migrate, cleanup — provides a structured, repeatable recovery process.

9.3 Clean Room and Isolated Recovery

Imagine investigating a crime scene while the criminal is still in the building, watching your every move. That is essentially what happens when security teams try to investigate a breach using the compromised production environment. The attacker may still have access, can observe the investigation, and might escalate their attack in response. Clean room recovery solves this problem by providing a completely isolated environment where investigators can work safely, hidden from the attacker’s view.

Isolated Recovery Environment (IRE) Concepts and Setup

An isolated recovery environment (IRE) is a trusted, segregated infrastructure where security teams can examine and analyze digital evidence related to cyber incidents without risk of contamination or detection by adversaries. Cohesity implements this through its clean room architecture, which creates a Minimum Viable Recovery Environment (MVRE) — an environment sized based on guidance from the incident response team rather than matching production scale. Oversizing the MVRE wastes resources; the goal is to provide just enough infrastructure to support investigation and initial recovery. [Source: https://www.cohesity.com/blogs/data-clean-rooms-done-right-in-a-world-of-destructive-cyberattacks/]

Essential components of a Cohesity clean room include:

A critical design principle: since the compromised systems’ security tools cannot be trusted, all forensic tools and critical software must be pre-staged in the isolated vault. [Source: https://www.cohesity.com/blogs/data-clean-rooms-done-right-in-a-world-of-destructive-cyberattacks/]

Cohesity Fort Knox for Cloud-Based Data Vaulting

Cohesity FortKnox is a SaaS-based cyber vaulting and recovery solution that provides an immutable copy of data in a Cohesity-managed cloud vault through a virtual air gap — a logical and physical isolation mechanism that prevents ransomware from reaching vaulted data even when production systems are fully compromised. [Source: https://www.cohesity.com/platform/fortknox/]

A cyber vault is an offsite copy of data that is isolated physically and logically from primary and backup copies, acting as an added layer of protection against ransomware and other cyber threats. [Source: https://www.cohesity.com/platform/fortknox/]

FortKnox operates through four core stages:

Figure 9.3: FortKnox Cyber Vaulting Four-Stage Process

flowchart LR
    R["Replicate\nSecure copy to\nvaulted environment"] --> S["Scan\nAnomaly detection &\nthreat scanning"]
    S --> L["Lock\nImmutable snapshots\nprevent modification"]
    L --> RC["Recover\nRestore with confidence\nin minutes"]

    subgraph "Virtual Air Gap"
        R
        S
        L
        RC
    end

    P["Production\nEnvironment"] -.->|"Isolated\nReplication"| R

    style P fill:#e76f51,color:#fff
    style R fill:#264653,color:#fff
    style S fill:#2a9d8f,color:#fff
    style L fill:#e9c46a,color:#000
    style RC fill:#2d6a4f,color:#fff

1. Replicate: Data is securely copied into a vaulted environment isolated from production networks.
2. Scan: Integrated anomaly detection and threat scanning verify data cleanliness before restoration.
3. Lock: Immutable snapshots prevent modification or deletion, protecting data integrity.
4. Recover: Users restore with confidence in minutes, minimizing downtime.

[Source: https://www.cohesity.com/resources/solution-brief/cohesity-fortknox-modern-cyber-vaulting-for-confident-recovery-en/]

FortKnox is available as a fully managed SaaS service on AWS, Azure, and GCP, as well as an on-premises/self-managed deployment for organizations requiring complete control. [Source: https://www.cohesity.com/blogs/cohesity-fortknox-is-now-available-on-google-cloud/] [Source: https://www.cohesity.com/blogs/multicloud-cyber-vaulting-with-cohesity-fortknox-and-microsoft-azure/]

Security controls protecting the vault include:

[Source: https://www.cohesity.com/platform/fortknox/]

The underlying SpanFS immutable file system maintains backup jobs in time-based snapshots that cannot be accessed externally or modified by ransomware. The original backup job is kept in an immutable state and is never made accessible through read-write mounting. [Source: https://www.cohesity.com/platform/fortknox/]

FortKnox modernizes the classic 3-2-1 backup strategy — three copies of data on two different media types, with one off-site — by serving as the critical offsite, isolated copy. [Source: https://www.cohesity.com/resources/datasheet/cohesity-fortknox/]

Clean Room Recovery Procedures for Forensic-Safe Restoration

Figure 9.4: Clean Room Recovery Three-Phase Process

flowchart TD
    DET["Anomaly Detected\n(Recovery Agent)"] --> P1

    subgraph P1["Phase 1: Isolate the Threats"]
        ISO1["Spin up isolated\nclean room"] --> ISO2["Move suspect asset\ninto clean room"]
    end

    P1 --> P2

    subgraph P2["Phase 2: Secure Forensic Investigation"]
        F1["AI/ML threat hunting"] --> F2["IoC feed analysis\n& YARA rules"]
        F2 --> F3["Timeline analysis\nacross snapshots"]
    end

    P2 --> P3

    subgraph P3["Phase 3: Structured Recovery"]
        R1["Eliminate threats"] --> R2["Implement enhanced\ncontrols"]
        R2 --> R3["Restore validated data\nto production"]
    end

    style DET fill:#e76f51,color:#fff
    style P1 fill:#264653,color:#fff
    style P2 fill:#2a9d8f,color:#fff
    style P3 fill:#2d6a4f,color:#fff

Cohesity implements a three-phase response process within the clean room environment:

Phase 1 — Isolate the Threats. The platform provides isolation capabilities for malware analysis and detailed threat examination. When the platform’s Recovery Agent detects an anomaly, it can automatically spin up an isolated clean room and move the suspect asset into it for forensic analysis — without waiting for human initiation. [Source: https://www.truthinit.com/index.php/video/3843/incident-response-automation-with-recovery-agent/]

Phase 2 — Secure Forensic Investigation. Security teams investigate the nature and impact of the attack, determining what data has been compromised. The clean room provides native AI/ML threat-hunting tools, a curated IoC feed covering hundreds of thousands of indicators used by ransomware operators, and support for custom YARA rules to identify advanced threats. Timeline analysis capabilities allow investigators to compare filesystem states across the incident progression, leveraging backup retention that extends far beyond typical security log retention. [Source: https://www.cohesity.com/blogs/data-clean-rooms-done-right-in-a-world-of-destructive-cyberattacks/]

Phase 3 — Structured Recovery. Teams eliminate threats and implement enhanced controls based on the investigation findings before restoring to production. [Source: https://www.cohesity.com/solutions/clean-room/]

Worked Example: Automated Clean Room Provisioning

At 3:15 AM, Cohesity’s anomaly detection identifies unusual entropy patterns in a backup job for a critical database server. The Recovery Agent automatically provisions a clean room environment, instantiates the suspect VM from its most recent snapshot via live mount, and alerts the on-call security analyst. By the time the analyst logs in, the isolated environment is ready with forensic tools loaded, the suspect system mounted for investigation, and a timeline view showing filesystem changes over the past 72 hours. The analyst confirms ransomware infection, identifies the initial compromise point at 11:42 PM the previous evening, and the recovery team restores from the 11:00 PM snapshot — all without the attacker ever knowing the investigation was underway. [Source: https://www.truthinit.com/index.php/video/3843/incident-response-automation-with-recovery-agent/] [Source: https://www.cohesity.com/solutions/clean-room/]

Validating Backup Integrity Before Production Restore

Before any data returns to production, it must be validated as clean. Cohesity provides multiple validation mechanisms:

• CyberScan vulnerability indexing assesses each snapshot for known vulnerabilities and provides a cleanliness score. [Source: https://www.cohesity.com/blogs/defend-against-ransomware-attacks-a-security-first-approach/]
• Integrated anomaly detection during the “Scan” phase of FortKnox operations verifies data cleanliness before any restoration proceeds. [Source: https://www.cohesity.com/resources/solution-brief/cohesity-fortknox-modern-cyber-vaulting-for-confident-recovery-en/]
• Live mount testing allows teams to boot a recovered VM in isolation to verify application functionality before committing to production deployment.
• Custom YARA rule scanning enables targeted searches for specific threat indicators identified during the forensic investigation. [Source: https://www.cohesity.com/blogs/data-clean-rooms-done-right-in-a-world-of-destructive-cyberattacks/]

Key Takeaway: Clean room recovery and FortKnox cyber vaulting provide the isolated, trustworthy environments essential for safe forensic investigation and validated recovery. The automated Recovery Agent can provision clean rooms without human intervention, dramatically reducing response time. Always validate backup integrity through CyberScan and anomaly detection before restoring data to production.

9.4 Post-Incident Remediation

Recovering from an incident is not the end of the process — it is the beginning of the next preparation cycle. Post-incident remediation ensures that the same attack vector cannot be exploited again and that the organization’s defenses are stronger than before. Think of it like a hospital conducting a post-surgery review: the operation may have been successful, but the medical team still reviews what happened, what could be improved, and whether the treatment plan needs updating.

Root Cause Analysis Using Cohesity Audit and Detection Data

Cohesity provides several data sources that support root cause analysis:

• Timeline Analysis: By comparing filesystem states across multiple snapshots, investigators can trace the progression of an attack backward from detection to initial compromise. Because backup retention typically extends far beyond security log retention, Cohesity’s historical data can reveal attack activity that occurred weeks or months before detection. [Source: https://www.cohesity.com/blogs/data-clean-rooms-done-right-in-a-world-of-destructive-cyberattacks/]

• Anomaly Detection History: Helios records historical anomaly data including change rates, ingest patterns, and entropy levels. Reviewing this data retrospectively can reveal early indicators that were not flagged as critical at the time. [Source: https://www.cohesity.com/blogs/cohesity-protecting-backup-data-ransomware-customers-approve/]

• CyberScan Vulnerability Reports: Snapshot-level vulnerability assessments can reveal when specific vulnerabilities were introduced into the environment, helping identify the entry point. [Source: https://www.cohesity.com/blogs/defend-against-ransomware-attacks-a-security-first-approach/]

• Audit Logs: Platform audit logs document all administrative actions, access attempts, and configuration changes, providing an evidentiary trail for the investigation.

Re-Securing the Environment After a Breach

After recovery, the environment must be hardened against the specific attack that occurred and similar attack patterns. Key re-securing steps include:

1. Credential Rotation: All credentials that may have been exposed must be rotated, including service accounts used for backup operations.
2. Access Control Review: Review and tighten RBAC policies, enable quorum-based access for critical operations if not already active, and verify MFA enforcement across all administrative interfaces. [Source: https://www.cohesity.com/platform/fortknox/]
3. Network Segmentation Validation: Verify that network isolation controls identified as gaps during the investigation are remediated — including VLAN configurations and firewall rules protecting backup infrastructure. [Source: https://www.cohesity.com/blogs/data-clean-rooms-done-right-in-a-world-of-destructive-cyberattacks/]
4. Patch Management: Address all vulnerabilities identified by CyberScan before the recovered environment is placed back into full production.
5. Enhanced Monitoring: Update anomaly detection baselines and thresholds based on patterns observed during the incident.

Lessons Learned and IR Plan Updates

Every incident should produce a formal lessons-learned document that feeds back into the IR plan. Key areas to review:

Cohesity’s Cyber Incident Response Simulator can be used after an incident to rehearse improved procedures, allowing teams to validate that the updated IR plan addresses the gaps identified during the real event. [Source: https://www.cohesity.com/incident-response-simulator/]

Backup Policy Adjustments Post-Incident

Figure 9.5: Post-Incident Remediation Feedback Loop

flowchart TD
    INC["Incident Resolved"] --> RCA["Root Cause Analysis\n- Timeline analysis\n- Anomaly detection history\n- CyberScan reports\n- Audit logs"]
    RCA --> SEC["Re-Secure Environment\n- Credential rotation\n- Access control review\n- Network segmentation\n- Patch management"]
    SEC --> LL["Lessons Learned\n- Detection effectiveness\n- Response time review\n- Recovery completeness"]
    LL --> POL["Backup Policy\nAdjustments"]
    POL --> PREP["Updated Preparation\n(NIST Phase 1)"]
    PREP -.->|"Next Incident\nCycle"| INC

    style INC fill:#e76f51,color:#fff
    style RCA fill:#264653,color:#fff
    style SEC fill:#2a9d8f,color:#fff
    style LL fill:#e9c46a,color:#000
    style POL fill:#6a4c93,color:#fff
    style PREP fill:#2d6a4f,color:#fff

Incidents frequently reveal that backup policies need adjustment. Common post-incident policy changes include:

• Increased snapshot frequency for critical systems, reducing the maximum data loss window (RPO)
• Extended retention periods to ensure that investigation data remains available for regulatory and legal requirements
• Additional FortKnox vault copies for systems that were previously only protected by local snapshots
• Updated DataLock/WORM policies to extend immutability windows based on the observed attack dwell time
• New YARA rules reflecting the specific threat indicators discovered during the investigation, added to ongoing scanning [Source: https://www.cohesity.com/blogs/data-clean-rooms-done-right-in-a-world-of-destructive-cyberattacks/]
• Compliance alignment with frameworks such as NIST, ISO 27040, and DORA, which FortKnox’s immutable logs and retention locks help satisfy [Source: https://www.cohesity.com/platform/fortknox/]

Key Takeaway: Post-incident remediation closes the loop on the NIST incident response lifecycle. Cohesity’s extended data retention, timeline analysis, and CyberScan reports provide the forensic depth needed for thorough root cause analysis, while backup policy adjustments ensure the organization is better prepared for the next potential incident.

Chapter Summary

This chapter examined how Cohesity integrates into every phase of the incident response lifecycle — from preparation and detection through recovery and post-incident remediation. The NIST framework provides the structural backbone, while Cohesity’s platform provides the operational capabilities.

Recovery procedures center on Cohesity’s SnapTree technology and fully hydrated snapshots, which enable instant mass restore of hundreds of VMs through a structured five-step workflow. Point-in-time recovery, guided by CyberScan vulnerability indexing, ensures organizations restore from clean data points.

Clean room and isolated recovery capabilities provide forensic-safe investigation environments through the Minimum Viable Recovery Environment (MVRE) concept. FortKnox cyber vaulting delivers air-gapped, immutable data protection through a four-stage process (Replicate, Scan, Lock, Recover) available on AWS, Azure, and GCP. The automated Recovery Agent can provision clean rooms without human intervention when anomalies are detected.

Post-incident remediation leverages Cohesity’s extended data retention and detection history for root cause analysis, followed by environment re-hardening and backup policy adjustments that strengthen the organization’s posture for future threats.

Together, these capabilities position Cohesity as more than a backup platform — it is a central component of an organization’s cyber resilience strategy.

Key Terms

Chapter 10: Secure Data Management & Data Isolation

As the final chapter in this study guide, Chapter 10 brings together two critical topics: the technical mechanisms for isolating backup data from attackers, and a comprehensive review of exam preparation strategies across all seven COH350 domains. Data isolation represents the last line of defense in a ransomware attack — when every other control has failed, an isolated, immutable copy of your data is what stands between your organization and catastrophic data loss.

Learning Objectives

After completing this chapter, you will be able to:

• Implement data isolation methods including air-gapped and network-isolated backup copies
• Configure Cohesity replication and CloudArchive for secure offsite data protection
• Design a comprehensive 3-2-1-1 backup strategy with isolation tiers
• Apply exam preparation strategies across all seven COH350 domains

10.1 Data Isolation Methods

Data isolation is the practice of separating backup copies from production systems and networks so that a threat actor who compromises the primary environment cannot reach, modify, or destroy backup data. Think of data isolation like a bank vault: even if a thief breaks into the bank lobby, the vault is a separate, hardened compartment that requires entirely different credentials and physical access to breach.

Cohesity provides multiple data isolation methods designed to protect backup data from ransomware, insider threats, and unauthorized access. The primary approaches include physical air gaps, virtual air gaps, and logical air gaps. [Source: https://www.cohesity.com/glossary/air-gap/]

Physical Air-Gap vs. Logical Isolation Approaches

Physical Air Gap — A complete physical air gap means zero network connections between the backup environment and production systems. Data is physically isolated from production systems, stored miles away behind security boundaries. While this approach offers maximum isolation, recovery is slow and requires manual intervention such as physically transporting tapes or storage media. [Source: https://www.cohesity.com/glossary/air-gap/]

Real-world analogy: A physical air gap is like storing gold bars in a vault at the bottom of the ocean. It is extraordinarily secure, but retrieving the gold when you need it is expensive and time-consuming.

Figure 10.1: Physical Air Gap vs. Logical Air Gap

flowchart LR
    subgraph Physical["Physical Air Gap"]
        direction TB
        P1["Production Systems"]
        P2["No Network Connection"]
        P3["Isolated Backup Media\n(Tape / Portable Storage)"]
        P1 -.->|"Manual Transport\n(Sneakernet)"| P2
        P2 -.-> P3
    end

    subgraph Logical["Logical Air Gap"]
        direction TB
        L1["Production Systems"]
        L2["Encryption + RBAC +\nQuorum Approval"]
        L3["Backup Storage\n(Network-Accessible)"]
        L1 -->|"Secured Network\nConnection"| L2
        L2 --> L3
    end

    style Physical fill:#f9e2e2,stroke:#c0392b,color:#000
    style Logical fill:#e2f0f9,stroke:#2980b9,color:#000

Logical Air Gap — Logical air gaps keep systems within the same network but use encryption, role-based access control (RBAC), and multi-person authorization (also called four-eyes or quorum approval) to isolate data logically. The data remains accessible over the network, but layered security controls prevent unauthorized access or modification. [Source: https://www.cohesity.com/glossary/air-gap/]

The following table compares the two primary air gap approaches:

[Source: https://www.cohesity.com/deep-dives/how-does-virtual-air-gap-work/]

Network-Isolated Backup Copies and Virtual Air Gaps

A virtual air gap simulates the protection of a physical air gap while maintaining the ability to recover data quickly over a network. Virtual air gaps use several technical layers to achieve isolation:

• Network Segmentation: Virtual local area networks (VLANs) and software-defined networks (SDNs) segment network traffic. Data diodes — one-way communication gateways — ensure that data can flow in only one direction, preventing an attacker from reaching back into the isolated environment. [Source: https://www.cohesity.com/deep-dives/how-does-virtual-air-gap-work/]
• Access Control: Firewalls enforce default-deny rules, blocking all communication unless explicitly permitted. Multi-factor authentication (MFA) protects access points between network segments. RBAC and attribute-based access control (ABAC) limit user permissions to the minimum required. [Source: https://www.cohesity.com/deep-dives/how-does-virtual-air-gap-work/]
• Data Protection: Data remains encrypted and immutable — it cannot be altered, copied, or deleted. Continuous AI/ML-powered monitoring with extensive logging detects anomalies in real time. [Source: https://www.cohesity.com/deep-dives/how-does-virtual-air-gap-work/]
• Operational Isolation: Separate key management systems for Cohesity-managed and customer-managed encryption keys ensure that compromise of one key hierarchy does not expose all data. [Source: https://www.cohesity.com/deep-dives/how-does-virtual-air-gap-work/]

Figure 10.2: Virtual Air Gap Defense Layers

flowchart TB
    Attacker["Threat Actor"] -->|"Blocked"| Layer1

    subgraph VirtualAirGap["Virtual Air Gap - Layered Defenses"]
        direction TB
        Layer1["Network Segmentation\nVLANs / SDN / Data Diodes"]
        Layer2["Access Controls\nFirewalls / MFA / RBAC / ABAC"]
        Layer3["Data Protection\nEncryption / Immutability /\nAI-ML Anomaly Detection"]
        Layer4["Operational Isolation\nSeparate Key Management Systems"]
        Layer1 --> Layer2
        Layer2 --> Layer3
        Layer3 --> Layer4
    end

    Layer4 --> ProtectedData["Protected Backup Data"]

    style Attacker fill:#e74c3c,stroke:#c0392b,color:#fff
    style ProtectedData fill:#27ae60,stroke:#1e8449,color:#fff
    style VirtualAirGap fill:#eaf2f8,stroke:#2c3e50,color:#000

Cohesity FortKnox as a Managed Isolation Service

Cohesity FortKnox is a SaaS-based data isolation and recovery service that represents a modern approach to cyber vaulting. FortKnox improves cyber resiliency by maintaining an immutable copy of data in a Cohesity-managed cloud vault behind a virtual air gap. This data can be quickly and easily recovered back to the source or an alternate location in case of a data disaster. [Source: https://www.cohesity.com/platform/fortknox/]

FortKnox delivers isolation through multiple reinforcing layers:

[Source: https://www.cohesity.com/platform/fortknox/] [Source: https://aws.amazon.com/blogs/apn/defending-against-ransomware-with-aws-and-cohesity-fortknox/]

The temporary connection model is a defining feature of FortKnox: a secure network connection is established for vaulting, then cut off once data has been transferred, creating a virtual air gap. This means the vault is unreachable from the network during the vast majority of its operational life. [Source: https://www.cohesity.com/blogs/going-beyond-the-air-gap-data-isolation-and-recovery-for-the-modern-era/]

Figure 10.3: FortKnox Temporary Connection Model

sequenceDiagram
    participant Source as Cohesity Cluster<br/>(Source)
    participant Net as Secure Network<br/>Connection
    participant Vault as FortKnox<br/>Cyber Vault

    Note over Source,Vault: Normal State: Connection CLOSED (Air Gap Active)

    Source->>Net: 1. Initiate vault session
    Net->>Vault: 2. Establish secure TLS tunnel
    Note over Net: Connection OPEN

    Source->>Vault: 3. Transfer encrypted<br/>immutable snapshot
    Vault->>Vault: 4. Apply WORM +<br/>AWS Object Lock

    Vault->>Net: 5. Confirm receipt
    Net--xSource: 6. Disconnect tunnel

    Note over Source,Vault: Connection CLOSED (Air Gap Restored)

    rect rgb(255, 235, 235)
        Note over Source,Vault: Vault unreachable from network<br/>until next scheduled transfer
    end

FortKnox cyber vault is available on both AWS and Google Cloud, providing organizations with choice in where their isolated vault copies reside and enabling geographic diversity for data sovereignty compliance. [Source: https://www.cohesity.com/blogs/cohesity-fortknox-is-now-available-on-google-cloud/]

Isolation Tiers: Local, Remote, Cloud-Vaulted

A mature data protection strategy uses multiple isolation tiers to balance recovery speed against attack resistance:

Each tier adds distance — both logical and physical — between production systems and backup data. The exam may test your ability to recommend the appropriate tier for a given scenario based on RPO, RTO, and threat model.

Figure 10.4: Data Isolation Tiers — Distance from Production

flowchart LR
    Prod["Production\nSystems"] --> T1
    T1 --> T2
    T2 --> T3
    T3 --> T4

    T1["Tier 1: Local\nOn-Cluster Snapshots\n(Logical Isolation)\nRTO: Minutes"]
    T2["Tier 2: Remote\nReplicated Cluster\n(Network Segmentation)\nRTO: Min-Hours"]
    T3["Tier 3: Cloud-Vaulted\nCloudArchive\n(Encrypted + Air-Gapped)\nRTO: Hours"]
    T4["Tier 4: Cyber Vault\nFortKnox\n(Virtual Air Gap + Quorum)\nRTO: Hours-Days"]

    style Prod fill:#e74c3c,stroke:#c0392b,color:#fff
    style T1 fill:#f39c12,stroke:#e67e22,color:#000
    style T2 fill:#f1c40f,stroke:#d4ac0f,color:#000
    style T3 fill:#2ecc71,stroke:#27ae60,color:#000
    style T4 fill:#27ae60,stroke:#1e8449,color:#fff

    linkStyle 0 stroke:#e74c3c,stroke-width:3px
    linkStyle 1 stroke:#f39c12,stroke-width:2px
    linkStyle 2 stroke:#2ecc71,stroke-width:2px
    linkStyle 3 stroke:#27ae60,stroke-width:2px

Key Takeaway: Data isolation ranges from logical controls on local clusters to fully air-gapped cyber vaults. Cohesity FortKnox provides managed, SaaS-based isolation with temporary connections, immutability, quorum approval, and anomaly detection. A tiered approach ensures both rapid operational recovery and resilient last-resort protection against sophisticated attacks.

10.2 Replication and CloudArchive Security

Moving backup data offsite is fundamental to any disaster recovery strategy, but the mechanisms used to transfer and store that data must themselves be secured. Cohesity provides two primary approaches: cluster-to-cluster replication and CloudArchive to public cloud storage.

Secure Replication Between Cohesity Clusters

Replication copies backup snapshots from a source Cohesity cluster to a target Cohesity cluster, typically at a remote site. This provides site-level protection — if the primary data center is destroyed or compromised, the secondary cluster holds recent copies ready for recovery.

Key security considerations for replication include:

• Encryption in transit: All replication traffic is encrypted using TLS, ensuring data cannot be intercepted during transfer between clusters.
• Separate administrative domains: The source and target clusters should be managed by different administrator accounts so that compromise of one cluster’s credentials does not automatically grant access to the other.
• Network segmentation: Replication traffic should traverse a dedicated network segment or use encrypted tunnels (VPN) rather than sharing bandwidth and exposure with general-purpose traffic.
• RBAC on target clusters: The target cluster should enforce its own RBAC policies, limiting who can access, modify, or delete replicated data independently of the source cluster.

Real-world analogy: Replication is like making a photocopy of an important document and storing it in a safe at a different office. The copy is independent — shredding the original does not affect the copy — but you still need a locked filing cabinet and restricted access at both locations.

CloudArchive to AWS, Azure, and GCP with Encryption

CloudArchive simplifies long-term data retention and archival by enabling organizations to archive older local snapshots from their Cohesity clusters to cloud storage for long-term retention. The platform supports archival to leading public clouds as well as S3-compatible object stores. [Source: https://www.cohesity.com/blogs/leverage-cloud-long-term-archival-with-cohesity/]

How CloudArchive Works:

1. Data is first backed up onto a Cohesity cluster.
2. The cluster then copies selected backup snapshots to an External Target — an abstraction of the cloud storage service registered within the Cohesity cluster.
3. Archival workflows operate through data protection policies that specify retention periods, RPO schedules (e.g., weekly or monthly snapshots), and target cloud vault destinations.

[Source: https://www.cohesity.com/blogs/leverage-cloud-long-term-archival-with-cohesity/]

The External Target abstraction layer enables flexible multi-cloud deployments where organizations can use multiple cloud storage providers with different RPO and retention objectives for each vault. [Source: https://www.cohesity.com/blogs/leverage-cloud-long-term-archival-with-cohesity/]

Figure 10.5: CloudArchive Workflow

flowchart LR
    Sources["Data Sources\n(VMs, DBs, Files)"]
    Cluster["Cohesity Cluster\n(Local Snapshots)"]
    Policy["Data Protection\nPolicy\n(RPO / Retention)"]
    ET["External Target\n(Abstraction Layer)"]

    Sources --> Cluster
    Cluster --> Policy
    Policy --> ET

    ET --> AWS["AWS S3 /\nS3-IA / Glacier"]
    ET --> Azure["Azure Standard\nStorage"]
    ET --> GCP["GCP Nearline\nStorage"]
    ET --> S3C["S3-Compatible\nObject Store"]

    subgraph Cloud["Cloud Storage Targets"]
        AWS
        Azure
        GCP
        S3C
    end

    style Cluster fill:#3498db,stroke:#2980b9,color:#fff
    style Policy fill:#9b59b6,stroke:#8e44ad,color:#fff
    style ET fill:#e67e22,stroke:#d35400,color:#fff
    style Cloud fill:#eaf2f8,stroke:#2c3e50,color:#000

Supported Cloud Storage Tiers:

[Source: https://www.cohesity.com/resources/solution-brief/simplify-long-term-data-retention-and-archival/]

Replication Encryption and Access Controls

All CloudArchive data is protected with robust security measures:

• AES 256-bit encryption for both data-at-rest and data-in-flight, compliant with FIPS 140-2 Level-1 standards. [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/white-paper/cohesity-platform-security-white-paper-en.pdf]
• HTTPS transport for all data-in-motion to cloud targets. [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/white-paper/cohesity-platform-security-white-paper-en.pdf]
• Different encryption keys across different cloud vaults, with internal key management enabling key rotation without requiring full re-encryption of archived data. [Source: https://www.cohesity.com/content/dam/cohesity/resource-assets/white-paper/archive-your-data-directly-with-cohesity-cloudarchive-direct-white-paper.pdf]
• Index metadata stored alongside archived datasets, enabling full cluster recovery scenarios where even the source cluster is lost. File-level search and restoration capabilities remain available from archived snapshots. [Source: https://www.cohesity.com/blogs/leverage-cloud-long-term-archival-with-cohesity/]

RPO and RTO Considerations for Isolated Copies

Recovery Point Objective (RPO) defines the maximum acceptable data loss measured in time. A 4-hour RPO means you can tolerate losing up to 4 hours of data, which dictates a backup frequency of at least every 4 hours.

Recovery Time Objective (RTO) defines the maximum acceptable time to restore operations after an incident. An RTO of 2 hours means your recovery infrastructure must be capable of bringing systems back online within that window.

These two metrics directly influence your isolation tier selection:

[Source: https://www.cohesity.com/glossary/321-backup-rule/]

Worked Example: Choosing Isolation Tiers for a Healthcare Organization

A hospital must protect its electronic health records (EHR) system. Regulatory requirements (HIPAA) mandate that patient data is recoverable and that backup copies are protected from unauthorized access.

1. Tier 1 (Local): Hourly immutable snapshots on the primary Cohesity cluster. RPO: 1 hour. RTO: 15 minutes via instant recovery.
2. Tier 2 (Remote): Replication every 4 hours to a secondary Cohesity cluster at a disaster recovery site. RPO: 4 hours. RTO: 1 hour.
3. Tier 3 (Cloud): Daily CloudArchive to AWS S3 with 7-year retention for compliance. RPO: 24 hours. RTO: 4-8 hours.
4. Tier 4 (Cyber Vault): Weekly FortKnox vault with quorum-protected access. RPO: 7 days. RTO: 8-24 hours. This tier exists solely for catastrophic ransomware recovery.

Key Takeaway: Cohesity replication and CloudArchive provide secure offsite data protection with AES-256 encryption, FIPS 140-2 compliance, and policy-driven archival to multiple cloud providers. RPO and RTO requirements determine the appropriate mix of isolation tiers, from rapid local snapshots to deeply isolated cyber vault copies.

10.3 Comprehensive Data Protection Strategy

3-2-1-1 Backup Rule with Immutable and Isolated Copies

The classic 3-2-1 backup rule mandates maintaining at least three copies of data, stored on two different media types, with one copy kept off-site. This foundational strategy protects against single points of failure. [Source: https://www.cohesity.com/glossary/321-backup-rule/]

The 3-2-1-1 rule extends this model by adding a critical fourth element for modern ransomware defense:

• 3 — At least three copies of data
• 2 — Stored on two different media types
• 1 — One copy kept off-site or in the cloud
• 1 — One copy that is air-gapped or immutable (cannot be accessed via network or modified)

Some organizations adopt the further-enhanced 3-2-1-1-0 approach, where the 0 represents zero errors achieved through continuous monitoring and regular testing of backup-restore processes. [Source: https://www.cohesity.com/glossary/321-backup-rule/]

Figure 10.6: The 3-2-1-1 Backup Rule

flowchart TB
    Rule["3-2-1-1 Backup Rule"]

    Rule --> Three["3 Copies of Data"]
    Rule --> Two["2 Different Media Types"]
    Rule --> OneOff["1 Copy Offsite"]
    Rule --> OneAir["1 Copy Air-Gapped\nor Immutable"]

    Three --> C1["Copy 1:\nProduction Data\n(Primary Storage)"]
    Three --> C2["Copy 2:\nLocal Backup\n(Cohesity Cluster)"]
    Three --> C3["Copy 3:\nOffsite Copy\n(Replicated / Archived)"]

    Two --> M1["Media A:\nDisk-Based\nStorage"]
    Two --> M2["Media B:\nCloud Object\nStorage"]

    OneOff --> Off["CloudArchive to\nAWS / Azure / GCP"]
    OneAir --> Air["FortKnox Cyber Vault\n(Immutable + Quorum)"]

    style Rule fill:#2c3e50,stroke:#1a252f,color:#fff
    style OneAir fill:#27ae60,stroke:#1e8449,color:#fff
    style Air fill:#27ae60,stroke:#1e8449,color:#fff

Real-world analogy: Think of the 3-2-1-1 rule like protecting a family heirloom. You keep one copy of the photo at home (local), one in a safe deposit box at the bank (offsite), and one in a fireproof safe that only opens with two keys held by different family members (air-gapped and immutable). Even if your house burns down and the bank is robbed on the same day, the fireproof safe copy survives.

Cohesity’s implementation of the 3-2-1-1 strategy rests on three pillars: [Source: https://www.cohesity.com/blogs/how-backup-immutability-defends-against-ransomware-attacks/]

1. Immutability: Backup data must be immutable so it cannot be modified or deleted. Cohesity provides immutable snapshots — a “gold copy” that is never exposed externally.
2. Platform Hardening: The backup platform itself must be hardened so administrative settings such as backup schedules cannot be altered by unauthorized actors.
3. Multi-Person Approval (Quorum): Any changes to critical settings must require multi-person approval so no single rogue insider can unilaterally change settings.

Tiered Protection Policies Based on Data Criticality

Not all data requires the same level of protection. A tiered approach allocates resources proportionally to the business value and sensitivity of the data:

Protection policies in Cohesity are configured at the cluster level and specify backup frequency, retention duration, replication targets, and archival destinations. Users can configure policies to archive specific snapshots (e.g., the first snapshot of every month) to multiple cloud vaults simultaneously. [Source: https://www.cohesity.com/blogs/leverage-cloud-long-term-archival-with-cohesity/]

Testing and Validating Isolated Recovery Capabilities

A backup that cannot be restored is not a backup — it is a false sense of security. Organizations must regularly test their isolated recovery capabilities:

1. Scheduled recovery drills: Perform quarterly or semi-annual restore tests from each isolation tier, verifying that data is intact and recovery meets RTO targets.
2. FortKnox recovery validation: Test the full FortKnox recovery workflow, including quorum approval, to ensure the process works under time pressure and that all required approvers are available.
3. CloudArchive retrieval testing: Verify that archived data can be retrieved from cloud storage tiers (especially cold tiers like Glacier) within acceptable timeframes.
4. Runbook documentation: Maintain detailed, step-by-step recovery procedures for each isolation tier so that operations staff can execute recovery under stress without guesswork.
5. Zero-error validation: Implement continuous monitoring to detect backup failures, incomplete snapshots, or replication lag before a disaster strikes.

With ransomware attacks increasing 29% year-over-year, having isolated copies prevents total data loss even when production systems are compromised. [Source: https://www.cohesity.com/blogs/how-backup-immutability-defends-against-ransomware-attacks/]

Key Takeaway: The 3-2-1-1 rule is the foundation of modern ransomware-resistant data protection. Cohesity implements this through immutable snapshots, platform hardening, and quorum approval. Tiered protection policies match data criticality to the appropriate level of isolation, and regular testing ensures that recovery capabilities work when needed most.

10.4 Exam Preparation and Domain Review

This section provides a structured review of all seven COH350 exam domains, study prioritization guidance, and practical recommendations for hands-on preparation.

Cross-Domain Security Integration and Exam Scenarios

The COH350 exam tests your ability to connect concepts across domains. Real exam questions rarely test a single topic in isolation — instead, they present scenarios requiring you to integrate knowledge from multiple domains. Consider these example integration patterns:

Scenario 1: Ransomware Response A question might describe a ransomware attack and ask you to identify the correct response. This requires knowledge from:

• Monitoring and threat detection (Chapter 8) — recognizing the attack via DataHawk anomaly detection
• Incident response (Chapter 9) — executing clean room recovery procedures
• Data isolation (Chapter 10) — recovering from a FortKnox cyber vault copy
• Access control (Chapter 7) — quorum approval for vault access

Scenario 2: Compliance Audit An auditor asks you to demonstrate data protection controls. This spans:

• System hardening (Chapters 3-4) — WORM storage, encryption, attack surface reduction
• Compliance (Chapter 5) — mapping Cohesity features to HIPAA/GDPR requirements
• Authentication (Chapter 6) — MFA and SSO configuration evidence
• Audit logging (Chapter 8) — providing compliance-grade audit trails

Scenario 3: Secure Architecture Design You are asked to design a multi-site Cohesity deployment. This involves:

• Network security (Chapter 2) — VLAN segmentation, TLS encryption, firewall rules
• Data isolation (Chapter 10) — tiered isolation with replication and CloudArchive
• Access control (Chapter 7) — multi-tenancy and RBAC across sites

Hands-On Lab Recommendations and Practice Exercises

The COH350 exam emphasizes practical knowledge. The following lab exercises reinforce the key skills tested across all domains:

Key Takeaways Per Exam Domain with Weight-Based Study Priorities

The following table summarizes the critical concepts for each COH350 domain. Allocate your study time proportionally to each domain’s exam weight:

Study Strategy Tips:

1. Start with high-weight domains: System hardening, access control, and incident response/data management collectively represent the largest portion of the exam.
2. Practice scenario-based thinking: For each concept, ask yourself “In what scenario would I use this?” and “What other controls complement this?”
3. Know the defaults: The exam often tests whether you know what Cohesity enables or disables by default and what requires explicit configuration.
4. Understand the “why”: Memorizing configuration steps is less important than understanding why a control exists and what threat it mitigates.

Certification Maintenance and Continuing Education

After passing the COH350 exam:

• Stay current with Cohesity platform updates, as new security features are regularly added (e.g., FortKnox expanding to Google Cloud).
• Monitor threat landscape changes that may affect data protection strategies, particularly evolving ransomware techniques.
• Participate in Cohesity community forums and partner training to maintain practical skills.
• Review Cohesity security white papers and best practice guides as they are updated for new platform versions.
• Consider complementary certifications in cloud security (AWS Security Specialty, Azure Security Engineer) to broaden your data protection expertise across the hybrid environments where Cohesity operates.

Key Takeaway: COH350 exam success requires integrated knowledge across all seven domains. Focus your study time on high-weight domains, practice with hands-on labs, and develop scenario-based thinking that connects concepts across chapters. After certification, continue learning to stay current with the evolving threat landscape and platform capabilities.

Chapter Summary

This chapter covered the final two pillars of the Cohesity Security Specialist body of knowledge: secure data management through isolation techniques, and a comprehensive review for exam preparation.

Data isolation is your organization’s insurance policy against catastrophic attacks. Cohesity provides a spectrum of isolation methods — from logical controls like RBAC and immutability on local clusters, to virtual air gaps via network segmentation and FortKnox’s temporary-connection model, to physical air gaps for maximum-security environments. The tiered approach (local, remote, cloud-vaulted, cyber vault) ensures that every organization can match its isolation strategy to its risk profile and recovery requirements.

CloudArchive extends data protection to the public cloud with AES-256 encryption, FIPS 140-2 compliance, and policy-driven archival to AWS, Azure, GCP, and S3-compatible stores. Combined with cluster-to-cluster replication, it provides the offsite copies required by the 3-2-1-1 rule.

The 3-2-1-1 backup strategy modernizes the classic 3-2-1 rule for the ransomware era by mandating an air-gapped or immutable copy. Cohesity’s three pillars — immutability, platform hardening, and quorum approval — make this strategy operationally achievable.

Finally, exam preparation requires integrated thinking across all seven COH350 domains. The exam tests scenario-based reasoning, not isolated facts, so your study approach should emphasize understanding the connections between network security, hardening, compliance, authentication, access control, monitoring, and data isolation.

Key Terms