Hammerspace Security

This document is an informational security overview of the Hammerspace platform, not a configuration or administration guide. It summarizes the platform’s security architecture, key security features, and access controls.

Hammerspace software enables the following security features:

Hammerspace is based on a server installation of Linux with an upgraded kernel. Everything installed is provided by the Hammerspace software; it is not possible to add 3rd party packages before, during, or after the installation.

The configured services are minimal in order to reduce the potential vulnerability footprint. The platform is locked down with a firewall and a restricted administration shell. The firewall only allows for traffic on a certain set of ports. The open ports are specific to the network configuration applied (see network separation for further explanation).

See the Hammerspace Installation and Licensing Guide for a granular port listing with explanations per port.

Hammerspace includes three default management roles for Graphical User Interface (UI), Command Line (Admin CLI) and REST API access:

Custom roles can also be created to specify the exact permissions for the desired role.

Active Directory

Active Directory (AD) is the recommended method to manage administrative access to Hammerspace. This allows for management access to be controlled using the same security policies as configured with Active Directory.

Local Management Users

If AD is not in use, local management users can be created and managed within Hammerspace. Local management users do not have access to data. Local management account security behavior is controlled by the login policy. The system can be configured to automatically lock a local management account after a number of failures within a certain amount of time. This login policy only applies to local management users and not to management users managed by Active Directory.

The following options are available as part of the local user login policy.

+ .Admin CLI: Local-user login options

Management access can further be restricted by configuring which network(s) or host(s) are allowed to log in to the management address.

Hammerspace does not contain any default passwords for users. The password for the local admin user is set during installation by the customer. When deploying in the cloud, each deployment has a unique, auto-generated password. The password can also be changed after installation is completed.

The following rules apply to the creation of a management-user password:

Hammerspace has limited the command access for users when they log in using ssh. They are limited to a set of Hammerspace-only commands designed to offer all the required functionality to manage Hammerspace. No operating system access is granted.

The operating system that is running Hammerspace software is locked down and does not allow for generic logins. There is no sudo access to the underlying operating system for a Hammerspace management user.

The boot loader configuration is locked and cannot be modified by a console user to try to get to a pre-console state.

Management access is restricted to management network role and therefor separates, at the network layer, management traffic and data traffic. An SMB/NFS/S3 client computer cannot, assuming proper segregation of the networks, get access to the management shell/UI even if login credentials are known.

Hammerspace executes periodic security tests as part of the development and release process

[[3rd-party-external-security-scans]] = 3^rd-Party, External Security Scans

The following vendors have executed independent security scans of the Hammerspace product and Hammerspace have passed their testing

Hammerspace utilizes https connections into object storage to ensure the network transfers are safe.

In addition to a secure connection, customers can also configure Encryption of the data before it is sent over the wire. The encryption key(s) are provided either by utilizing the integrated Key Management capabilities of the product, Entrust nShield HSM or AWS Key Management Service.

After the KMS is configured, any new file instances placed in object, whether by objective or on demand, will be encrypted by default, in both existing and new object volumes. Encryption at rest can be disabled on a per object volume (bucket) basis.

Hammerspace software update mechanism is also protected. All updates (patches, software updates) are signed by Hammerspace, otherwise they cannot be applied. The software updates cannot be reverse-engineered and applied without being signed by Hammerspace.

Hammerspace support personnel do not have remote access to the installed system.

These Vulnerability Remediation SLAs define the maximum time allowed between the identification of a security vulnerability and the implementation of a remediation or approved mitigating control. Compliance with these SLAs is monitored and tracked as part of Hammerspace’s secure development and operations processes. For more information, see the Hammerspace Version 5.2 Vulnerability Remediation SLAs Document (HS3011-USEN-17).

Severity Remediation Table

By default, the product will send a health heartbeat every 24 hours to report back system health, status, and basic configuration. The health heartbeat is sent over a secure network transport to a US-based, Hammerspace-managed, resilient endpoint.

This functionality can be disabled if desired; however, by doing so, proactive support and the ability to detect potentially incorrect configurations will be limited.

The health heartbeat contains the following information:

Private data such as file data or file names, usernames, or any credentials are NOT included in the health heartbeat.

The following sections contain additional information that may be useful to Hammerspace administrators.