StorMagic. Copyright © 2020. All rights reserved.

WHITE PAPER

DATA ENCRYPTION:BEST PRACTICES FOR EDGE ENVIRONMENTS

INTRODUCTION

The news from the last few years is littered with stories about security breaches from electronic point-of-sale malware attacks on large US retailers, leaked online credit card payment details, sensitive defense documents being published, to celebrity private photos being stolen.

It seems that the number of breaches and data leaks is rising year over year, with each seeming to be bigger and more high-profile than the previous one, resulting in more data and customer information being exposed. The data is either sold on the black-market/”dark web” or published on the Internet to embarrass or discredit a person or company. In some cases, this has resulted in hefty fines and financial penalties for the companies involved.

The fact is that many of the breaches can be attributed to one or more of the following, unauthorized access (hacking), malware/viruses exploiting security holes from poor computer maintenance (patching), social engineering (email scamming), and in some cases hardware theft.

There are a number of techniques that can be used to protect the data, such as endpoint

security (virus scanning, firewalls), email spam filtering, role-based access controls, better user education and having a well-defined patch management strategy. However, the most effective way to protect and secure data is encryption. This will be the focus for the rest of this white paper.

WHAT IS ENCRYPTION?

Encryption is the process of translating data from one form (plaintext) to another (ciphertext) - see fig. 1. It ensures that if the data falls into an unauthorized party’s hands, the data cannot be accessed without having the correct encryption keys to decrypt the data.

Gartner defines encryption as, “the process of systematically encoding a bit stream before transmission so that an unauthorized party cannot decipher it.” Data-at-rest encryption

Fig. 1 The process of encryption, from plaintext to ciphertext.

StorMagic. Copyright © 2020. All rights reserved.

protects data when

it is stored on disk and

can be used to protect

data from unauthorized

access or equipment theft.

For example, in the event of a server theft

or disk failure, it would not be possible to access

the data as it is encrypted. Failed disks can now be

disposed of, or replaced easily, without the need for traditional

data destruction techniques such as “degaussing” of magnetic

disks, physical destruction or “disk scrubbing”.

WHO SHOULD ENCRYPT?

Some industries such as healthcare, financial services, government and defense

have strict regulatory, risk or compliance requirements that require data to be

encrypted. Common regulations include:

HIPAA Health Insurance Portability and Accountability Act (US healthcare)FIPS 140-2 Federal Information Processing Standard (US Defense, finance, healthcare)GDPR General Data Protection Regulation (EU)DPB Data Protection Bill (UK)SOX Sarbanes-Oxley (Finance)PCI DSS Payment Card Industry Data Security Standard (Finance)CCPA California Consumer Privacy Act

What becomes clear is that the number of regulations vary by geographic region and industry, some are very prescriptive while others less so. What unites all of them is, in the case of a breach, all of these regulations carry a financial penalty. Avoiding these penalties has been a major contributor in the increased interest and spending on data encryption solutions.

More industries will add encryption features for protection against penalties and litigation, and over time, encryption adoption will continue to become more mainstream and horizontal rather than by vertical industry or geography.

WHERE TO ENCRYPT?

There are numerous ways of solving most IT problems, and data encryption is no different. There are various points within an IT stack where the encryption can be performed, as shown in fig. 2. Each has its pros and cons with regards to cost, complexity, and capacity.

Fig. 2 Where should you encrypt? The software-defined layer is often the best option.

Performing encryption higher up in the stack enables greater control of what is being encrypted. For example, it is possible to encrypt a select number of virtual machines or specific tables in a database. This approach can add complexity, as each application, filesystem, or hypervisor will have different methods to perform the encryption, all of which need to be configured and managed differently.

Encrypting at the hardware layer radically simplifies the solution, as all the data will be encrypted, but this requires specialist hardware. This could mean self-encrypting drives (SEDs) or encryption-capable RAID controller cards while other solutions may rely on bespoke hardware

StorMagic. Copyright © 2020. All rights reserved.

acceleration cards to perform the encryption operations. All these can add significant cost to the solution and create lock-in to a specific hardware encryption solution.

StorMagic has seen that many end users want to just ‘blanket’ encrypt all their data rather than select which data needs securing. They want a simple solution that does not require individual encryption for each application, VM or filesystem. Furthermore, they want to do it with the equipment they already have and not incur any additional costs purchasing encryption-capable hardware. Therefore, the most effective place to perform encryption would be in the software-defined storage stack. This would allow the end users to select some or all volumes that require encryption using the same hardware-agnostic mechanism for all data, irrespective of application, filesystem or operating system.

KEY MANAGEMENT REQUIREMENTS

Once the encryption algorithm performs the conversion of plaintext data into an encrypted form using a key, there then arises the equally important topic of key management. In general, key management provides a secure, highly available place to store and manage the cryptographic keys.

Availability is the most important requirement of key management. Without access to the keys, the data will not be accessible. Therefore, it is highly recommended to have at least two or possibly more key management servers to ensure keys are always available. Ideally each key management system (KMS) would be installed in a different location or datacenter to ensure that a power outage, flooding, fire or other localized disaster does not interrupt availability.

KEY MANAGEMENT INTEROPERABILITY PROTOCOL (KMIP)

Today, all KMS solutions use the Key Management Interoperability Protocol (KMIP). This is a single, standard protocol for communication between KMS and encryption solutions, such as storage arrays, tape libraries, self-encrypting drives (SEDs) and networking equipment.

Prior to KMIP, each vendor would have their own methods of encryption leading to multiple key management solutions being used, increasing management overhead.

KEY CRITERIA FOR SELECTING YOUR ENCRYPTION SOLUTION

It should employ industry-standard, ultra-secure cryptographic algorithms to encrypt the data.It should use the CPU AES-NI encryption instructions to provide hardware acceleration that significantly improves encryption performance.It should be hardware-agnostic and should not require expensive special hardware, such as self-encrypting drives (SEDs), ASICs, FPGAs or cryptographic capable RAID controllers to perform the encryption operations.It should be KMIP-compliant, providing interoperability with industry-leading KMS solutions.It should encrypt data on a per volume granularity and provide the ability to select some or all of the data to encrypt.

HOW DOES GARTNER DEFINE ENTERPRISE KEY MANAGEMENT?

“Enterprise key management (EKM) provides a single, centralized software or network appliance for multiple symmetric encryption or tokenization cryptographic solutions. Critically, it enforces consistent data access policies through encryption and tokenization management. It also facilitates key distribution and secure key storage, and maintains consistent key life cycle management.”

StorMagic. Copyright © 2020. All rights reserved.

STORMAGIC SvSAN DATA ENCRYPTION

As a simple, cost-effective and flexible virtual SAN solution, StorMagic SvSAN also brings these fundamentals into the encryption space through its data encryption feature. When added to SvSAN, the solution provides lightweight, highly available encrypted storage on as few as two nodes per cluster.

SvSAN’s data encryption feature delivers ultra-secure encryption using a FIPS 140-2 compliant algorithm and meets HIPAA, PCI DSS and SOX requirements. It does not require special self-encrypting disk drives, RAID cards or FPGA/ASICs and has the flexibility to encrypt all mirrored data, or just selected volumes. The data is encrypted in-flight, before it is written to disk.

Available as an additional feature on top of the base SvSAN license, SvSAN’s data encryption feature enables organizations to securely protect data at edge locations where data and IT hardware are much more vulnerable. Data encryption can be added to new and existing SvSAN licenses. For more information on how to enable encryption on your SvSAN clusters, please contact sales@stormagic.com.

STORMAGIC SvKMS ENCRYPTION KEY MANAGEMENT

To enable secure and effective key management when using SvSAN’s data encryption feature, use StorMagic SvKMS encryption key management. SvKMS provides extremely flexible key management, enabling an organization to store keys locally, in the datacenter or cloud and integrate with any existing workflow.

SvKMS is a separately licensed product to SvSAN and the two can be used independently of each other. For more information on SvKMS, please refer to the SvKMS product data sheet.

Furthermore, if your organization is already using an existing KMS solution, providing it is KMIP-compliant, SvSAN’s data encryption feature is already fully compatible and can be integrated with it immediately.

KEY MANAGEMENT SERVER FAILURE SCENARIOS

Knowing that an encryption solution is secure, reliable and resilient is fundamental for data security. This section describes different failure scenarios that may impact SvSAN’s data encryption feature and explains the expected behavior during failure and subsequent recovery.

The scenarios are as follows:1. Normal running state2. Single KMS server becomes unavailable3A. All KMS servers in a cluster are unavailable - VSA online3B. All KMS servers in a cluster are unavailable - VSA offline or rebooted4. Key revoked/deactivated

SCENARIO 1: NORMAL RUNNING STATE

Fig. 3 shows a typical two node SvSAN cluster, connected to another cluster running KMS VMs. While the KMS could be located remotely, within a datacenter and/or cloud, this is the optimal configuration when the KMS is located locally to the encrypted cluster. It provides an adequate level of security by separating the keys from the encrypted data. In this instance:

All key servers in the KMS cluster are online.SvSAN hosts are online and healthy.All volumes are in a healthy state.

When the SvSAN VSAs are powered on they will obtain the encryption keys from the KMS cluster, and volumes will be brought online allowing normal read/write access.

While the connection state to the KMS cluster is good, SvSAN will recheck the connection to the KMS cluster every 5 minutes.If there is an issue with this connection and the VSA can no longer contact the KMS cluster it will recheck the connection to the KMS every minute.If unable to establish connectivity to the KMSthe VSAs will trigger an event.

StorMagic. Copyright © 2020. All rights reserved.

SCENARIO 2: SINGLE KMS SERVER BECOMES UNAVAILABLE

Fig. 4 shows the same two clusters - one for SvSAN and one for the KMS. In this scenario, one of the KMS servers has failed. As the remaining KMS is still online and available to the SvSAN cluster:

The VSAs continue to operate without impact to data availability.Storage will remain accessible and the encryption keys can still be obtained from the surviving KMS, in the event of a VSA reboot.

SCENARIO 3A: ALL KMS SERVERS IN A CLUSTER ARE UNAVAILABLE - VSAs ONLINE

In this scenario, shown in fig. 5, all the KMS servers have failed, but the SvSAN cluster is operational.

While the VSAs remain online the volumes will be available and online. See Scenario 3B for when the VSAs are rebooted/powered down.SvSAN will check the connection state to the KMS every minute.On a successful connection to the KMS, an event is logged and System Status returns to normal.

SCENARIO 3B: ALL KMS SERVERS IN A CLUSTER ARE UNAVAILABLE - VSAS OFFLINE OR REBOOTED

In this scenario, all the KMS servers have failed (as in fig. 5) and the VSA has been rebooted or was powered down.

When a VSA is rebooted or powered on, the VSA will attempt to retrieve the encryption keys at startup.As there are no key management servers available, the VSA will be unable to obtain the encryption key for the volumes.An event will be generated and displayed in the SvSAN WebGUI, shown in fig. 6. It should be noted that events can also be propagated to vCenter, and via remote syslog, SNMP and email using SMTP.

Fig. 3 A separate KMS cluster communicating using KMIP to an encrypted SvSAN cluster.

Fig. 4 A single KMS server is unavailable.

StorMagic. Copyright © 2020. All rights reserved.

The volume will enter an “Offline (Locked)” state and events will be triggered from the VSA to alert the administrator, shown in fig. 7.

Recovery:

The VSA will continue to check the connection to the KMS server every minuteWhen the connection to the KMS has been re-established, an event is logged as shown in fig. 8.The volume will return to the “Online” state, and the system status returns to normal.No administrative intervention is required to bring the storage back online.

SCENARIO 4: KEY REVOKED/DEACTIVATED

When the encryption keys are revoked on the KMS server, the VSA will keep its storage online and accessible until it is rebooted.

On reboot of the VSA, SvSAN will try to retrieve the encryption keys from the KMS server. The VSA will fail to obtain the encryption key, as it has been revoked.An event will be generated and the volume will be held in the “Offline (Locked)” state. The VSA system status will change to “Error”.

When the encryption keys have been revoked or deactivated for a target, it is still possible to perform rekey and decrypt operations.

Fig. 5 All KMS servers have failed.

Fig. 8 Events logged in the WebGUI.

Fig. 7 Volume in “Offline (Locked)” state.

Fig. 6 Error displayed in the WebGUI.

StorMagic. Copyright © 2020. All rights reserved.

CONCLUSIONS

SvSAN’s data encryption feature has been developed to provide ultra-secure FIPS 140-2 compliant encryption and the flexibility to work with any KMIP-compliant key manager, including StorMagic SvKMS. SvSAN is resilient and flexible enough to be deployed at remote and edge sites, enabling safe, secure data encryption alongside highly available storage. The process of installing and deploying SvSAN is straightforward enough to ensure data can begin to be encrypted within 15 minutes. As shown through the scenarios in this white paper, SvSAN handles many common failures of a remote KMS cluster, and endeavors to keep the volumes online and protected, providing peace of mind.

FURTHER READING

Visit the StorMagic website to read more about StorMagic’s virtual SAN solution SvSAN and encryption key management software SvKMS. Why not explore some of the others, such as Predictive Storage Caching, or the witness? These features and more can be accessed through the extensive collection of white papers on the StorMagic website.

Additional details on SvSAN are available in the Technical Overview which details SvSAN’s capabilities and deployment options.

If you’re ready to test SvSAN or SvKMS in your environment, you can do so totally free of charge, with no obligations. Simply download a fully-functioning free trial of both products from the website.

If you still have questions, or you’d like a demo of SvSAN or SvKMS, you can contact the StorMagic team directly by sending an email to sales@stormagic.com

StorMagicUnit 4, Eastgate

Office CentreEastgate Road

BristolBS5 6XX

United Kingdom

+44 (0) 117 952 7396sales@stormagic.com

www.stormagic.com