Cohesity Security Features Data Segmentation

Cohesity Security Features

This topic explains how Cohesity builds security into the Cohesity cluster and is intended
for:

l Administrators responsible for the configuration, maintenance and operation of the

Cohesity cluster.
l Security engineers reviewing Cohesity for compliance with their company's security
policies.

The Cohesity cluster provides the following security features.

Data Segmentation
The Cohesity cluster architecture provides virtual data isolation through Storage Domains.
Each Storage Domain encrypts the data stored in it using its own independent keys.
During initial cluster setup, encryption can be enabled for the entire cluster so that the data
in all Storage Domains will be encrypted. If encryption is not enabled during cluster
creation, it can be enabled at the Storage Domain level. Note that once encryption is set
during cluster or Storage Domain creation, it can not be disabled later.
Each Cohesity View is assigned a Quality of Service (QoS) Policy. A QoS Policy determines
the priority of I/O (when contention occurs).

Data at Rest Security

The Cohesity file system provides full at-rest encryption based on the strong AES-256 CBC
(Cipher Block Chaining) standard. Only 256 bit keys are used for encryption. The encryption
architecture provides high security while maintaining the flexibility to optimally leverage
the available hardware and software resources.
The built in software-based encryption is hardware-accelerated through the latest Intel
processors that support AES-NI instruction set. Due to hardware acceleration, the software-
based encryption route has minimal impact on performance.
Keys can be obtained in three ways:

l Internal Key Manager

l External Key Manager
l Cloud-based Key Manager

Keys can be rotated periodically. The default rotation is set to 90 days.

All user data is encrypted before it is stored on any storage media used. The data is
decrypted after it is read from the storage media in memory. The storage media can be
SSD, HDD, tape and cloud storage.

Cohesity Security 6.5.1 1

Cohesity Security Features Data in Flight Security

Data in Flight Security

The data being transmitted to a Cohesity cluster or being transmitted from a Cohesity
cluster to External Targets is encrypted for security. Examples of data movement are
ingesting data from a primary site, replicating between remote offices or transmitting data
to public cloud.

Primary Site to a Cohesity cluster

When the Cohesity backup software ingests data from the primary storage, it first
establishes a secure connection with the primary storage over HTTPS. Cohesity backup
software determines which data blocks have changed from the previous backup run by
communicating with the primary storage over the secure connection, and then transfers all
the changed blocks over the HTTPS connection.
Communication between the Cohesity cluster and Cohesity backup service (agent) is
secured using SSL/TLS integrated transport. They perform mutual authentication and all
data exchanged is encrypted.
The encryption is done using Advanced Encryption Standard-256 protocol. The cipher suites
used for backups through agent are:
1. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
2. TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA38
3. TLS_RSA_WITH_AES_256_GCM_SHA384

Replication from One Cohesity cluster to Another

A source Cluster starts a replication session by initiating a handshake with the target cluster
over an HTTPS connection. Upon receiving the handshake request, the target Cluster
obtains a session key from its local Key Management Server and sends it to the source
cluster over the HTTPS connection.
The source Cluster stores the received session key in its local Key Management Server and
completes the handshake. At this point, both the source and the target Clusters have the
session key.
The source Cluster uses the session key to encrypt the data and transfer it securely for that
replication session. The encryption uses Advanced Encryption Standard-128 protocol in
Cipher Block Chaining mode. The cipher suite used in replication is AES-128-CBC.

Data in Cloud Security

The cloud can be used:

Cohesity Security 6.5.1 2

Cohesity Security Features Data in Cloud Security

l As another tier of storage (Cloud Tier)

l To store long term retention copies (CloudArchive)
l Archive data directly to an external target without retaining a copy of the data on the
cluster (CloudArchive Direct).

Cohesity supports all the major cloud vendors, including Amazon, Microsoft Azure, Google
and Oracle, and any S3 compatible storage.

l You register the cloud storage as an External Target on the cluster and provide the
cloud storage access keys. The access keys are encrypted and stored on the Cohesity
cluster using AES-256 encryption in CBC mode. You can update the access keys from
the Cohesity Dashboard or by using the Cohesity REST API. (DataPlatform does not
rotate the access keys.)
l Though the access keys are specific to the cloud storage provider, the DataPlatform
key storage security is the same regardless of the cloud provider. DataPlatform is
FIPS certified and has an internal software-based key management system (KMS)
that stores the key encryption key (KEK).
l DataPlatform establishes a connection to the External Target only when making REST
API calls to perform an archive or recovery operation.
l DataPlatform does not include the External Target access keys in the API request. The
request is signed using the External Target’s access key and the signature is sent
using the Authorization request header.
l DataPlatform uses TLS 1.2 to encrypt in-flight data. Currently, DataPlatform does not
use mTLS (2-way SSL) in communication with External Targets.

CloudArchive and CloudArchive Direct uses its own encryption, independent of data at rest
encryption. The cipher suite used for encryption is AES-256-CBC.

l Cloud Archive encryption is on by default but can be turned off. Cohesity recommends
keeping it on.
l Both the data encryption key (DEK) and KEK are encrypted, distributed for resiliency
across the cluster and stored in SSD.
l The cluster creates a new DEK for each External Target. DataPlatform provides two
options. You can:
l Store the data, metadata and encryption keys (DEK/KEK) in the External
Target.
l Store the data, metadata, and DEK only in the External Target. This requires the
KEK to be downloaded and stored outside of the cluster. Without the
downloaded keys, future CloudRetrieve operations will not be possible.

For Cloud Tier, encryption is always on and cannot be turned off.

Cohesity Security 6.5.1 3

Cohesity Security Features Key Management

Key Management
The Cohesity cluster has a built-in key manager that generates keys and stores them
internally on the SSDs in encrypted form. Data on the Cluster is encrypted using a Data
Encryption Key (DEK) and the DEK is in turn encrypted using a Key Encryption Key (KEK).
The encryption/decryption process is done within the Cohesity cluster and is transparent to
all inbound/outbound protocols and applications such as backup, archiving and file services.
Also, the keys are stored in a distributed fashion to be resilient to disk and Node failure.
The default key rotation policy for KEK is 90 days, but the administrator can configure a
different value. There is no other user intervention needed while using the internal Key
Management Server (KMS).
Cohesity supports the SafeNet external Key Management Server.

Ports Employed
For a list of firewall ports used by the Cohesity cluster, see Manage Firewall Ports.

Cluster Management Methods

The Cohesity cluster can be managed using the following methods:

l The Cohesity Dashboard web browser interface.

l The command line interface (CLI) available for Linux, Windows and iOS systems.
l The REST API endpoints on any platform using a REST client.

All access methods require an SSL connection that uses TLS 1.2 or above. The connection
uses strong ciphers for the established session. When the Cohesity cluster is created, a self-
signed X.509 certificate (PEM format only) is generated for this purpose. The certificate
must have the "Common Name" field set to the server’s hostname (for example, a VIP's
DNS name). Certificates are stored in the boot disk. They are replicated to other Nodes as
part of Cluster formation using RPC calls. When the key expires, the web browser marks the
session as invalid. Users can import new certificates to re-establish the session.
Users can overwrite this X.509 certificate according to their company policy.

Cohesity Security 6.5.1 4

Cohesity Security Features Authentication

Authentication
Authentication is required for all management methods (the Cohesity Dashboard, CLI and
API). Only a user with an account on the Cluster can authenticate to the Cluster. Cohesity
supports three types of accounts.

l Local User Account—A user account is created locally on the Cluster. This user can
access only this Cluster. When the account is created, a password is assigned to the
user and required to authenticate to the Cluster. This password is stored on the
Cluster.
l Active Directory—A user account that exists on an Active Directory server. This
user can access all the Clusters that have joined the Active Directory. The user uses
the Active Directory password to authenticate to the Cluster. The Cluster
authenticates the user with Active Directory. The password is not stored on the
Cluster.
l Single Sign-On - A Single Sign-on (SSO) user account that uses the supported
Identity Provider (IdP) to authenticate to the Cohesity cluster. Cohesity DataPlatform
supports major IdP vendors such as Okta, Duo, Ping, and Azure AD.

Protocols and Authentication

The Cohesity cluster can authenticate users defined locally in the Cluster and users defined
in Active Directory. NFS uses whitelist-based access control. SMB uses Active Directory for
authentication and authorization. Anonymous access, which doesn’t require authentication,
is not allowed for SMB.

Kerberos Authentication Protocol

Kerberos can be enabled for stronger authentication for SMB by joining the Cohesity cluster
to Active Directory. Cohesity supports only Active Directory based Kerberos authentication.

Client Side Protocols

Cohesity supports the SMB, NFS and S3 protocols.

SMB Protocol Security

Cohesity supports two types of authorization data on a file: Windows-style access control
lists (ACLs) and POSIX mode bits (UNIX permissions). ACLs are used when a file is
accessed from SMB. POSIX mode bits are used when a file is accessed via NFS.

Access Description Supported Notes

Access-control lists (ACLs) Yes Windows-style ACLs

Cohesity Security 6.5.1 5

Cohesity Security Features Authorization

Access Description Supported Notes

Windows-style (NT) credentials for UNIX users No Not supported in NFS v3

SMB access of UNIX-created files Yes

NFS access of Windows-created files Yes (with root access)

Home directory permissions Yes Windows-style ACLs

NFS Protocol Security

l NFS access is controlled via whitelisted IP addresses. Client IP addresses that are
whitelisted are allowed to mount an NFS share.
l The whitelist is set at the Cluster level and View level override is available.
l Cohesity DataPlatform supports RPCSEC_GSS protocol for NFS.

Mixed SMB and NFS Environments

Beginning with version 6.0, support for mixed-permission environments is available. The
supported scenarios are:

l A UNIX client can store and access a file over NFS.

l A Windows client can store and access a file over SMB.
l A UNIX client can connect by NFS to a file that was stored on the Cluster by a
Windows client over SMB and access it based on the permissions.
l A Windows client can connect by SMB to a file that was stored on the Cluster by a
UNIX client over NFS and access it based on the permissions.
l Data can be written at the same time to a file via NFS or SMB.

Amazon S3

Cohesity supports:

l S3 server over HTTPs.

l Authentication with AWS Signature Version 2 and Version 4.
l AWS ACLs.
l Access controlled via allowed subnets.

Authorization
Authorization is implemented at two levels.

Cohesity Security 6.5.1 6

Cohesity Security Features Accounting

l The operation level, where operations are restricted to authorized users only.
l The object level, where objects are restricted to authorized users only.

The Cohesity cluster can also be added as an Active Directory domain.

Role Based Access Control (RBAC)

A role is a collection of operations, such as creating a View or deleting a Protection Group. A
role grants authorization to perform one or more operations. Cohesity provides default
roles such as Admin, Operator, Viewer, and Data Security. Customers can create custom
roles. A user can have multiple roles but must have at least one role to log in to the Cluster.
A user can be assigned a set of objects on the Cluster. The user is authorized to access only
those objects and perform operations on them allowed by the role assigned.

Accounting
Accounting is implemented at two levels.

l The operation level, where each operation is tracked.

l The file level, where each file access is tracked.

Audit Trail
Every user operation that changes the Cluster is audited and the audit log is saved. The log
contains the original value and the value after the operation. For a list of logged operations,
see Audit Logs. Cohesity stores audit logs on the Cohesity cluster. Users can read them
using the standard NFS, SMB and S3 protocols and can export the logs to a syslog server.

Compliance
The following sections explain how Cohesity addresses various guidelines and
specifications.

Federal Information Processing Standards (FIPS) Compliance

The Cohesity cluster is FIPS level 140-2 certified. The encryption module has been validated
on the Cohesity platform with NIST for FIPS certification. The encryption module always
operates in FIPS mode. You can find detailed information in the Cohesity FIPS 140-2 Non-
proprietary Security Policy on the NIST website.

Cohesity Security 6.5.1 7

Cohesity Security Features Compliance

Common Criteria (EAL2+ Certification)

Common Criteria is an internationally recognized set of guidelines for evaluating IT security
products.

l It is a catalog of criteria and a framework for organizing a subset of the criteria into
security specifications
l It is a methodology for evaluating security features
l It can be applied to hardware, software, firmware, or a combination thereof
l It allows vendors to describe a product's security functionality with proof to support
their claims

Cohesity realizes the value of being a Common Criteria participant. To view the CC
certificate, see MyCC.

WORM (Write Once Read Many SEC 17a-4(f) Certification)

Long-term records retention is mandated by regulations and compliance rules, for example:

l In the financial services industry, SEC Rule 17a-4(f) specifies that “electronic records
must be preserved exclusively in a non-rewriteable and non-erasable format.”
l Other industries must meet similar requirements when they store mission critical
information.

WORM technology addresses these requirements by providing immutable locking and

secure data retention capabilities.
Cohesity implements WORM as DataLock Views. DataLock Views are locked (read only) for
a user-specified time period. Any user who has access to the View can clone a copy of the
View as a DataLock View and set the lock retention time. During that time period, only
users with Cohesity Data Security privileges can delete the View, extend the lock period (it
cannot be reduced) , add whitelisted IPs, change the QoS and change the description of the
View. After the lock period expires, the View can be deleted by any user that has
permission to delete it.
A replicated or archived DataLock View retains its DataLock properties. A DataLock View
can be cloned to a regular or DataLock View. You can check the Assessment Report by
Cohasset Associates to learn more about how Cohesity DataLock feature is designed to
meet securities industry requirements for preserving records in a non-rewriteable and non-
erasable format.

General Data Protection Regulation (GDPR)

GDPR is an EU regulation designed to strengthen data protection for residents of the EU. It
became effective on May 25th, 2018, and applies to any company controlling or processing
Personally Identifiable Information (PII) of EU residents, regardless of the location of the
company.

Cohesity Security 6.5.1 8

Cohesity Security Features Compliance

GDPR imposes a broad set of legal, governance and technical requirements on companies
processing personal data. A subset of these requirements—those related to data protection
and data management—are particularly relevant for storage platforms used to store
personal data.
Cohesity has a strong vision to enable our customers to be at the top of their GDPR
compliance. The tools and product functionality that Cohesity provides as part of its vision
fall into the following categories:

Mandate Features Offered

Monitor l GDPR mandates companies to
monitor for and report security
breaches.
l Companies are obliged to
communicate breaches to relevant
supervisory authorities, and to
affected individual in certain cases.
l Demonstrating appropriate reporting
procedures post identification of a
breach can validate compliance.
l Prevent portability of PII using White Lists
l Receive notifications or warnings when data
is tiered, archived, or replicated to a non-
Cohesity target
l Receive notification when data leaves EU
while still on Cohesity
l Ability to export cluster and system level
audit logs for additional analytics and
breach detection

Search l GDPR mandates that any EU
resident can request visibility of PII
from a company.
l They can also request for the PII to
be deleted, modified / corrected, or
exported out.
l Search within unstructured data for multiple
categories of PII
l Input PII patterns and their variations, and
file types (txt, doc, pdf, xls, zip, jpeg) to scan
using templates
l Inject custom code to run data processing
jobs on stored data using in-place analytics
tool

l Report search results in txt file format or

integrate with 3rd party data visualization or
analytics tools

Cohesity Security 6.5.1 9

Cohesity Security Features
Mandate
Locate l GDPR mandates getting a 360-
degree view of what PII is stored by
an organization. In addition, the
organization should be aware of:
l What PII they store and why
l Where does it come from
l Where the data is stored,
and the retention policy on
the personal data
l Who has access to the data
l And, monitor the movement
of the data
Minimize l GDPR mandates data minimization
as one of the main tenets to ensure
that companies maintain reduced
amounts of stored personal data.
l Here, PII needs to be kept only for
the time period relating directly to
the original intent of capturing the
data.
Protect l GDPR mandates data protection by
design and by default, making
privacy by design an express legal
requirement.
l Organizations should also be able to
demonstrate transparency when
validating compliance.
Payment Card Industry Data Security Standard (PCI DSS)
Cohesity adheres to the security benchmarks and requirements that are mandated by the
PCI-DSS, including the following:
Cohesity Security 6.5.1
Compliance
Features Offered
l Scheduled update to data maps that
delineate the following:
l Location and Movement Tracking
(source & destination) of PII
l Categories of PII stored
l File containing PII
l Retention policies of PII
l Access rights to PII
l Leverage Cohesity reports to complete Data
Protection Impact Assessments (DPIAs), if
needed.
l Cohesity architecture inherently minimizes
data copies, reduces attack footprint, and
tracks copies through centralized data
management
l Granular control over and automation of
retention policies enables customers to keep
PII only for intended periods
l Effectively relocate files to on demand to
minimize spread of PII data
l Encryption architecture, based on strong
AES-256 Cipher Block Chaining standard
and has a FIPS-Certified mode, provides
high end-to-end security while allowing
optimal use of available resources.
l Granular control through Role Based Access
Control and strong Active Directory
integration
l File or view level WORM provides
immutable locking and secure data retention
capabilities
10
Cohesity Security Features Compliance

l Authentication and access

l Logging and auditing
l Browser, plug-in and /or third party software requirements
l Management systems and software
l Releases, patching and updates
l Granular service controls
l Exposed protocols
l Monitoring, alerting and call home

Cohesity can provide details on demand.

Secure Government Clouds

Cohesity supports AWS GovCloud, Azure Government Cloud, and is working towards C2S
support.

Trade Agreements Act (TAA)

All Cohesity appliances are compliant with the Trade Agreements Act (19 U.S.C. & 2501-
2581) and ship from San Jose, CA.

Authorization to Operate (ATO)

Cohesity has the following:

l ATO for highly classified US Department of Defense (DoD) agency networks.

l DoD customers have created STIGs for Cohesity on DoD top secret networks.
l ATO for highly classified Department of Energy networks.
l ATO for US Air Force networks that support mission critical programs including the Air
Force GPS ground systems.
l Support US Intelligence Community on many programs.

Cohesity Security 6.5.1 11

Copyright Compliance

Copyright
Copyright © 2021 Cohesity, Inc. All rights reserved. Product specifications, release dates,
prices, and all other documentation are subject to change without notice. Cohesity, Inc.
makes no warranties, express or implied, with regards to this documentation, all of which is
provided “AS IS”. No part of this documentation or any related software may be
reproduced, stored, transmitted, or otherwise distributed in any form or by any means
(electronic or otherwise) for any purpose other than the purchaser's personal use without
the prior written consent of Cohesity, Inc. You may not use, modify, perform or display this
documentation or any related software for any purpose except as expressly set forth in a
separate written agreement executed by Cohesity, Inc., and any other use (including
without limitation for the reverse engineering of such software or creating compatible
software or derivative works) is prohibited, except to the extent such restrictions are
prohibited by applicable law.
Trademarks
Cohesity, SpanFS, SnapTree and ActiveRx are registered trademarks of Cohesity and/or its
affiliates. Other names may be trademarks of their respective owners.
Published on February 24, 2022 01:19 AM

Cohesity Security 6.5.1 12