Townsend Security Data Privacy Blog

Many VMware customers know that they can encrypt their virtual machines that are managed with vSphere and other VMware tools. VMware vSAN encryption can also provide important protections for data-at-rest in vSAN virtual disks. I wanted to share some thoughts I’ve received from our VMware customers and partners on some of the benefits of using vSAN storage with encryption enabled.

A Simple Way to Encrypt

When you have a large database, it can be inefficient to store the data in a directory or folder directly in your virtual machine. vSAN can be much easier to manage from an administrative and recovery point of view and your VMware applications can easily connect to the vSAN volume. vSAN is configured using the VMware tools you already know how to use and managing vSAN storage is easy.

Did you know that you can enable vSAN encryption to protect that database with sensitive data? You can enable vSAN encryption on existing virtual disks or on new virtual disks that you create. The process is simple and does not require any downtime for your application - and vSAN encryption enables the use of a KMIP compatible key manager like our Alliance Key Manager so that you stay lined up with industry standards and security best practices. It is an easy way to improve your overall security posture.

A Simple Way to Meet Compliance

Many of our VMware customers are struggling to implement encryption on their databases to meet compliance regulations and to protect the organization’s digital assets. Although encryption and key management have become much easier over the years, it can still seem like a daunting task. VMware vSAN encryption to the rescue! It is easy to implement with the tools you already have, and you can deploy an affordable key management solution such as our Alliance Key Manager to fully meet compliance requirements and security best practices. You configure key management directly through the KMS Cluster facility in vSphere, and then activate vSAN encryption. Alliance Key Manager does not impose any limits on the number of virtual disks you protect, nor on the number of nodes that connect to the key manager.

A Simple Way to Save Money

Some databases, such as Oracle and Microsoft SQL Server, require expensive license upgrades to enable encryption capabilities. This cost can be out of reach for many small to medium size organizations. Using vSAN encryption is an affordable way to achieve a better security posture using the tools and the IT professionals you already have.

You might be wondering if VMware supports the deployment of these databases on vSAN volumes. The answer is absolutely YES! You will find substantial documentation from VMware on doing exactly this. The documentation includes reference architectures and analysis of performance impacts. You can confidently move forward with vSAN encryption knowing that VMware has invested time and effort to make sure you are successful.

Lastly, we know that some VMware users have deployed the free version of vSphere. There are some costs associated with upgrading to the paid tier of vSphere in order to get the ability to encrypt VMs and vSAN. If this is where you are today, talk to us about how we can help with the uplift to the next level of vSphere capability.

Resources:
vSAN Documentation
Oracle Database on VMware vSAN Solution Overview
Architecting Microsoft SQL Server on VMware vSphere
Pointers to our AKM for vSphere/vSAN Solution Brief 

Both encryption and proper key management are a crucial part of defending your sensitive data. Consider the massive Marriott/Starwood Resorts data breach that was announced at the end of November, 2018. Attackers were able to first gain access to their systems in 2014, almost a full four years before they were detected in September of 2018.

To date, it is estimated that over 500 million records were compromised. 327 million of which contain personally identifiable information (PII) like names, physical addresses, birthdays, etc. In a statement put out by their parent company, Marriott, they noted that, “for some, the information also includes payment card numbers and payment card expiration dates, but the payment card numbers were encrypted using Advanced Encryption Standard encryption (AES-128). There are two components needed to decrypt the payment card numbers, and at this point, Marriott has not been able to rule out the possibility that both were taken.” (italics and bolding mine)

So, while the information was encrypted, the company cannot rule out that “two components needed to decrypt” were not taken. One of these needed components would be the encryption keys. No one knows for sure why they they cannot rule this out, but if the encryption keys were properly managed, the potential for them being stolen along with the data would be highly unlikely. Encryption is crucial to securing sensitive information. Just as important: properly managing the encryption keys.

But encryption, and by extension key management, have a bad reputation for being difficult to deploy in the enterprise. Encryption projects used to be costly as well as time and personnel intensive. While many databases came with encryption as part of their native libraries, it was a largely manual process not for the faint-of-heart—and add on top of that finding ways to properly manage the encryption keys; most developers would put it off for another day.

The good news, much has changed in the last 10+ years. Deploying encryption and key management can take a fraction of the time it normally took. But that doesn’t mean to you don’t have to work smart. Coming at an encryption project in a haphazard way could cost you time, money, and sensitive data not getting the proper protection it needs.

Follow along for three tips you need to get your encryption project off on the right direction.

Create a Unified Policy for Encrypting Data-at-Rest

The first step in any project is to get agreement between stakeholders as to what data-at-rest should be encrypted. Some of the obvious contenders would be any cardholder data (CHD) you have in you environment, personal health information (PHI) or personally identifiable information (PII) that needs to be kept safe. Many time this information falls under a compliance regulation like PCI DSS or HIPAA. The choice to encrypt this data is clear.

But less clear is data, that if exposed, would leave your company exposed to brand damage, lawsuits, or loss of competitive advantage. Whether it's the plans for a new product, proprietary schematics for an existing product, or information that exposes your business processes, business has a lot of information they want kept secret.

In fact, Deloitte estimates that Intellectual Property data can constitute more than 80 percent of a enterprise company’s value. Below is a short (and certainly not exhaustive) list of items that your company should be encrypting:

• Product/Solution Documents: If your product or service relies on proprietary information to give you a competitive advantage in the marketplace, you need to encrypt anything that would give your competition a window into how your products or solutions work.
• Research and Development (R&D) Data: In the same vein, any R&D you are conducting is your advantage in tomorrow's competitive landscape. Don't let it be stolen from you because you did not properly secure it.
• Financial Reports: If you don’t want your competitors spying on your financial information, encrypt it.
• Legal Documentation: There is a lot of documentation, that if made public, could tarnish a company's reputation. Harassment settlements, sexual misconduct accusations, financial misdealings, even benign partner agreements—all these need to be kept private and out of the public's eye.

Just as crucial as protecting PII and IP data is protecting any client data you are responsible for. Making sure that client data is safe is of utmost importance. Just one breach could cause major reputational damage and see a loss of current and future contract revenue.

Use Existing Encryption

Most databases now (like SQL Server and MongoDB), as part of their Enterprise editions, come with Transparent Data Encryption (TDE). This encryption encrypts the entire database while at-rest and normally uses either AES or 3DES encryption. This typically takes less time to deploy than column level encryption as there is less configuration to do.

If upgrading to an Enterprise edition is not in the budget, some third party encryption products may be an option. NetLib, for example, file level encryption for SQL Server. It supports all versions of SQL Server from 2000 to 2017 and can save you the upgrade costs from going from Standard or Dev editions to Enterprise.

Learn More: SQL Server Encryption Survey 2018

Use an Established Third Party Vendor for Encryption Key Management

The most important part of a data encryption strategy is the protection of the

encryption keys. Because encryption key management is crucial to data protection, the National Institute of Standards and Technology (NIST) provides guidelines on best practices for key management. NIST Special Publication SP-800-57 provides recommendations for encryption key management.

What this means to you is that managing your encryption keys is not a simple process. Why? Because you must create a defense-in-depth system for your encryption keys. Remember, hackers don’t break your encryption, they steal your keys. And the only way you keep your keys safe is to layer them in protection so that only authenticated and authorized personnel have access to them.

The good news is, there are vendors at the ready who already comply with the highest standards and have both virtual and hardware options. The real trick also is finding one that is both dedicated and affordable. Of course, there are some key manager options provided by public clouds, but they are not a dedicated key manager (i.e. you own the key manager) but rather your keys are housed are a multi-tenant environment as well as the public cloud provider having administrative access. This can get tricky as a public key manager may be compelled by the government to hand over your keys, without your knowledge, and unlock your data. Worse yet, if your data is stored in the same public cloud, the cloud provider would have access both to your keys and data. Unsafe! To learn more, check out our recent blog post on PCI SSC guidance around this issue.

Here at Townsend Security we do things differently. Not only is our Alliance Key Manager a dedicated key manager, you can purchase our key management platform of your choice and use it the way you want. It is that simple. From that point on:

• We never charge you fees for connecting a new end-point.
• We never limit the number of end-points based on the model of the KMS.
• We never limit the number of encryption keys generated or stored.
• We never force you to pay extra fees for software patches.
• We never force you to pay extra fees for routine software upgrades.

We do things a little differently here at Townsend Security and we think that makes encryption just a little easier.

As the date for the formal implementation of the EU General Data Protection Regulation draws near, many of our customers are struggling with the question of whether or not they have to encrypt sensitive data. Because the fines for violating the GDPR can be quite high, this question is taking on a growing urgency. So, let’s take a look at this question in more detail by looking at the actual GDPR source documents.

The most relevant part of the GDPR regulation related to encryption is Article 32 - “Security of Processing”. The actual text of the article is very readable and you can find a link in the Resources section below. Here is an extract from Article 32 (emphasis added):

“Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate:

1. the pseudonymisation and encryption of personal data;
2. the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;
3. the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident;
4. a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.”

Well, it looks like we don’t really have to encrypt the sensitive data because we get to take into account the costs of the implementation and the nature, scope, context and purpose for processing. Along with some other potentially mitigating factors. If you read no further you might draw the conclusion that encryption is a recommendation, but it is not a requirements. Question answered, right?

Not so fast. Let’s dig deeper. The next point in Article 32 shines a brighter light on this question:

“2. In assessing the appropriate level of security account shall be taken in particular of the risks that are presented by processing, in particular from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data transmitted, stored or otherwise processed.”

In effect the GDPR is saying that your security controls must account for the risk of accidental, unlawful, or unauthorized disclosure or loss of personal data. That is a very broad category of potential violations of the protection of an individual’s data. Have you ever lost a backup cartridge? Do you really think your systems are secure enough to prevent access by sophisticated cyber criminals?

While on first look it seems that we have some leeway related to the deployment of encryption, GDPR quickly raises the bar on this question. Given the current state of security of data processing systems, no security professional should be absolutely comfortable with the security of their systems.

If you are still thinking you can avoid encrypting sensitive data, be sure to take a read of Recital 78, “Appropriate technical and organisational measures”.

It should be clear by now that if you decide NOT to encrypt sensitive data you should definitely document all of the reasons it is not feasible or practical to do so, and all of the measures you are actually taking to protect that data. Put this in writing and get senior management sign-off on your conclusions.

But there is more.

If you are wondering how serious GDPR is about encryption, be sure to read Recital 83 “Security of processing”. Here is an extract with emphasis added:

“In order to maintain security and to prevent processing in infringement of this Regulation, the controller or processor should evaluate the risks inherent in the processing and implement measures to mitigate those risks, such as encryption. Those measures should ensure an appropriate level of security, including confidentiality, taking into account the state of the art and the costs of implementation in relation to the risks and the nature of the personal data to be protected. In assessing data security risk, consideration should be given to the risks that are presented by personal data processing, such as accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed which may in particular lead to physical, material or non-material damage.”

If you are getting the notion that the authors of the GDPR really want you to encrypt sensitive data, you would be right.

Where else does encryption come into play?

There are safe-harbors in GDPR around data breach notification IF you are encrypting sensitive data. The avoidance of notification is not absolute, but here is one relevant section of Article 34, “Communication of a personal data breach to the data subject” (emphasis added):

The communication to the data subject referred to in paragraph 1 shall not be required if any of the following conditions are met:

1. the controller has implemented appropriate technical and organisational protection measures, and those measures were applied to the personal data affected by the personal data breach, in particular those that render the personal data unintelligible to any person who is not authorised to access it, such as encryption;

If the sensitive data of a data subject is lost and not encrypted, it will be difficult to argue that the information is inaccessible. The loss of unencrypted data will certainly require notification to the supervisory authority and the data subject.

There is one more aspect to the discussion of encryption and that relates to the management of encryption keys. Your encryption strategy is only as good as your ability to protect your encryption keys. This is reflected in Recital 85 “Notification obligation of breaches to the supervisory authority” (emphasis added):

“A personal data breach may, if not addressed in an appropriate and timely manner, result in physical, material or non-material damage to natural persons such as loss of control over their personal data or limitation of their rights, discrimination, identity theft or fraud, financial loss, unauthorised reversal of pseudonymisation, damage to reputation, loss of confidentiality of personal data protected by professional secrecy or any other significant economic or social disadvantage to the natural person concerned. Therefore, as soon as the controller becomes aware that a personal data breach has occurred, the controller should notify the personal data breach to the supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of it, unless the controller is able to demonstrate, in accordance with the accountability principle, that the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where such notification cannot be achieved within 72 hours, the reasons for the delay should accompany the notification and information may be provided in phases without undue further delay.”

If you are not properly protecting the encryption key used for encryption, it must be assumed that the encryption can be reversed. Don’t use weak encryption keys such as passwords, don’t store encryption keys in files or in application code. Instead, use a professional key management solution to protect the keys.

Returning to our original question about the need for encryption of sensitive data, I hope you have arrived at Yes as the most responsible answer. The loss of unencrypted sensitive data will definitely trigger the need for data breach notification. And the improper protection of encryption keys will also trigger the need for breach notification. You are at more risk of financial penalties if you are not properly protecting that sensitive information with encryption.

The GDPR is complex and some parts are subject to interpretation. But if you control or process sensitive data you should not underestimate the serious intent of the GDPR to enforce protections for individuals. GDPR is revolutionary and disruptive - it is dangerous to ignore it.

Patrick

Resources
The General Data Protection Regulation (GDPR)
The GDPR Recitals
GDPR Article 32 “Security of Processing"
Recital 78, “Appropriate technical and organisational measures”
Recital 83, “Security of processing”
GDPR Article 34, “Communication of a personal data breach to the data subject”
Recital 85 “Notification obligation of breaches to the supervisory authority”

If you are a Java developer you probably know that the Java language has full native support for AES encryption. You don’t need any third-party SDKs or add-ins to Java to use industry-standard, strong encryption. The standard Java APIs are based on industry standards and are very efficient. Don’t hesitate to use that built-in facility. You include it in your Java application like this:

import javax.crypto.Cipher;
import javax.crypto.spec.IvParameterSpec;
import javax.crypto.spec.SecretKeySpec;

Encryption key management is another story. To implement good encryption key management you will need to turn to an enterprise key management solution and their Java library to make this happen. Our Alliance Key Manager for AWS solution provides a Java SDK to help you with encryption key use. The Alliance Key Manager Java SDK lets you easily retrieve an encryption key for use in your application, or alternatively to send data to Alliance Key Manager on a secure connection where the encryption or decryption task can be performed directly on the key server. This encryption service is helpful in situations where you don’t want to expose the encryption key in your application or server environment.

Many developers use the Java Keystore (JKS/JCEKS) facility for storing encryption keys. The Java key store is more a key storage facility rather than a key management facility and rarely meets compliance regulations for separating keys from the data they protect, providing for separation of duties, and dual control. If you are currently storing encryption keys in a JKS repository you may want to consider moving them to true key management solution like Alliance Key Manager.

One of the advantages of the Alliance Key Manager SDK is the built-in high availability failover facility. By using the Alliance Key Manager SDK in the event of a network or other failure you automatically fail over to a secondary HA key server in real-time. This means your application keeps running even though a network or system error prevents access to the primary key server.

The Java SDK for Alliance Key Manager includes all of the support needed to make a secure connection to the key server, retrieve an encryption key, access the encryption and decryption services on Alliance Key Manager, and perform other common functions. By using the SDK the Java developer can avoid writing all of the code needed to perform these tasks – the work needed to retrieve an encryption key is reduced to a few lines of code.  We think this is a big bonus for the Java developer and helps make their lives easier. And sample source code will really speed along the process.

Here is an extract of the sample source code showing the retrieval of an encryption key from Alliance Key Manager, an encryption of some plaintext, and the decryption of that ciphertext:

// Note: Full sample source available (this is just an extract)

import javax.crypto.Cipher;

import javax.crypto.spec.IvParameterSpec;

import javax.crypto.spec.SecretKeySpec;

import com.townsendsecurity.akmcore.AkmException;

import com.townsendsecurity.akmcore.AkmUtil;

import com.townsendsecurity.akmcore.AkmRequest;

import com.townsendsecurity.akmkeys.AkmKeyRequest;

import com.townsendsecurity.akmkeys.AkmSymKey;

// The AKM configuration file

String sCfgFile = "/path/jakmcfg.xml"

// Create a key request object initialized from the configuration file

AkmKeyRequest keyRQ = null;

keyRQ = AkmKeyRequest.getInstance(sCfgFile);

// Define the key instance (version) name

String sInstance = "some-name"

// Retrieve the encryption key from Alliance Key Manager

AkmSymKey symkey = null;

symkey = keyRQ.retrieveSymKey(sKey, sInstance);

// Create a context

EncryptDecryptCBC cryptor = new EncryptDecryptCBC(symkey.getKeyBytes());

// Let’s encrypt some plaintext

byte[] ciphertext = null;

ciphertext = cryptor.encryptSymmetric(plaintext.getBytes());

// Let’s decrypt the ciphertext

byte[] plainbuf = null;

plainbuf = cryptor.decryptSymmetric(ciphertext);

There is no charge for the Java SDK and all Alliance Key Manager customers have access to the Java SDK and sample code. AWS customers must register on the Townsend Security web site to get access to the Java code. You can do that here.