Chapter 4: System Hardening — Attack Surface Reduction

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.

Linux-Based OS Hardening

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
• Multifactor authentication support

At the network level, all ports are disabled by default except for known required ports. Preconfigured IP tables allowlist only the services that need to communicate internally. The cluster is FIPS 140-2 certified, always operates in FIPS mode, and does not support TLS v1.1 or below.

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.

SSH and Console Access Restriction

SSH restriction is one of the most critical hardening measures. Since version 6.8, the Secure Shell feature restricts SSH access to a limited command environment rather than full OS-level shell access. Administrators can execute CLI commands and run diagnostics but cannot browse the filesystem or modify OS-level files directly.

For console access, Cohesity introduced the Split Key feature in version 7.0. This mandates a challenge-response system when a user attempts to access the console via IPMI. The response codes can only be generated by opening a support case with Cohesity SREs.

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.

Service Account Management

Cohesity's security architecture is built on least privilege and segregation of duties:

• The "support" user account has read-only privileges by default
• Only the cluster administrator can escalate the support user's privileges
• Sudo access is disabled by default for the support user
• MFA should be enabled for both admin and support user accounts

Role-Based Access Control (RBAC) supports three methods: default roles, individual user-based roles, and user groups-based roles. Best practice is to deploy SSO with user groups-based RBAC.

Quorum approval (dual control) requires that critical system changes be authorized by more than one person, preventing a rogue or compromised administrator from acting unilaterally.

Patch Management

Cohesity provides one-click, non-disruptive cluster upgrades that handle software, security, firmware, and OS upgrades through a single workflow. Each node upgrades sequentially while other nodes absorb its workload via VIP migration (Virtual IP migration), ensuring zero downtime.

Long-Term Support (LTS) releases are supported for a minimum of twelve months, with six months of overlapping coverage between two LTS releases to give organizations a comfortable migration window.

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

Identifying Exposed Services

Cohesity's platform consolidation approach inherently reduces the attack surface by unifying backup, DR, file services, object storage, dev/test, and analytics on a single platform. However, administrators must still actively audit what is exposed:

Disabling Unused Connectors

Every enabled but unused connector is an unnecessary door. Administrators should periodically audit for:

• Unused data protection policies retaining stale connections
• Integration endpoints (cloud tiering targets, external NAS mounts) no longer active
• Service accounts created for testing and never removed
• Marketplace applications installed but not actively used

Minimal Privilege Access

Data exposure reduction extends to who can see what data and when:

• Immutable snapshots: The original "gold copy" is never mounted or exposed. Access requires creating a zero-cost clone.
• DataLock WORM: Creates time-bound locks on backup snapshots that cannot be deleted even by administrators.
• RBAC and custom roles: Ensures backup operators, security officers, and auditors each have narrowly scoped permissions.

Security Advisor is a built-in, no-cost tool available via Cohesity Helios that assesses, scores, and helps improve cluster security posture. It launched in December 2021.

Dashboard and Scoring

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

1. Scan: Evaluates security configurations across clusters — access control, audit logs, encryption framework
2. Score: Generates a numerical score indicating performance against best practice recommendations
3. Remediate: Provides actionable recommendations on addressing potential risks with detailed guidance

Security Recommendations

Security Advisor evaluates four primary dimensions:

When prioritizing remediation, focus on: (1) authentication gaps, (2) encryption gaps, (3) access control gaps, (4) logging and monitoring gaps.

Automated Checks

Security Advisor provides centralized visibility across all clusters spanning geographies, sites, and regions through the Helios Dashboard. Key capabilities include executive-ready security scorecards, detailed configuration issue analysis, and native Helios integration requiring no additional licensing.

Security Advisor complements CyberScan, a Marketplace application that scans backup snapshots for indicators of compromise (IOCs) and known vulnerabilities. Security Advisor hardens the platform; CyberScan ensures the data being protected is not already compromised.

Tracking Improvements

Security posture requires ongoing measurement. Best practices:

1. Baseline: Run an initial scan after deployment or major configuration changes
2. Remediate in priority order: Critical findings first (authentication, encryption), then moderate
3. Re-scan regularly: Monthly or quarterly to detect configuration drift
4. Document and report: Use executive scorecards for leadership communication
5. Integrate with change management: Tie scans to change control processes

CIS Benchmark Alignment

The Center for Internet Security (CIS) Benchmarks are consensus-based configuration guidelines developed by security practitioners worldwide. Cohesity's SpanOS ships with many CIS-aligned configurations already applied at the factory level, covering:

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

CIS alignment is not something you build from scratch — it is something you verify and maintain after deployment, particularly after upgrades or configuration changes.

STIG Compliance

The Security Technical Implementation Guide (STIG) is published by the US DoD's DISA. Cohesity SpanOS implements many STIG controls across these categories:

STIG compliance is particularly important for government, defense, financial services, and healthcare organizations.

Hardening Checklist for New Deployments