Which Encryption Option Should you Choose, vSphere VM or vSAN?

Data security is paramount for sensitive data-at-rest. Fortunately, protecting your data in VMware is relatively easy with the introduction of vSphere VM encryption in version 6.5 and vSAN encryption in version 6.6. Even better, for most folks, you won’t have to choose between each option, you will likely use both as needed. That said, there are some times when you might prefer one over the other. With that in mind, here are some of the features for each and how they are the same/different.

One of the most clear cut cases on preferring one encryption option or the other is in a multi-tenant situation. VMware gives these examples:

Engineering and Finance may have their own key managers and would require their VM's to be encrypted by their respective KMS. Or maybe your company has been merged with another company, each with their own KMS. Additionally, you may have a "Coke & Pepsi" scenario of two unrelated tenants. VM Encryption can handle this use case using the API or PowerCLI Modules for VM Encryption.

Since each VM is encrypted by a different key, vSphere VM encryption may be better suited for multi-tenant situations. In this way, not only will each tenant be assured that their sensitive data is not commingled with other tenants data (separate VMs), but their data is protected by separate keys.

Beyond that, VMware notes that “vSAN has unique capabilities for some workloads and may perform better in those situations.” So, if you are protecting larger datastores with a single tenant, vSAN would be your best option.

With these distinctions in mind, here is the best news: They are equally easy to set up! We have put together two videos to highlight the steps to get encryption enabled in each environment:

vSphere VM Encryption

For a more detailed look at vSphere VM encryption, please visit our post: vSphere Encryption—Creating a Unified Encryption Strategy. Here is a partial list of steps for enabling vSphere VM encryption:

• First, install and configure your KMIP compliant key management server, such as our Alliance Key Manager, and register it to the vSphere KMS Cluster.
• Next, you must set up the key management server (KMS) cluster.
• When you add a KMS cluster, vCenter will prompt you to make it the default. vCenter will provision the encryption keys from the cluster you designate as the default.
• Then, when encrypting, the ESXi host generates internal 256-bit (XTS-AES-256) DEKs to encrypt the VMs, files, and disks.
• The vCenter Server then requests a key from Alliance Key Manager. This key is used as the KEK.
• ESXi then uses the KEK to encrypt the DEK and only the encrypted DEK is stored locally on the disk along with the KEK ID.
• The KEK is safely stored in Alliance Key Manager. ESXi never stores the KEK on disk. Instead, vCenter Server stores the KEK ID for future reference. This way, your encrypted data stays safe even if you lose a backup or a hacker accesses your VMware environment.

vSAN Encryption

For a more detailed look at vSAN encryption, please visit our post: vSAN Encryption: Locking your vSAN Down. Here is a partial list of steps for enabling vSAN encryption:

• First, install and configure your key management server, or KMS, (such as our Alliance Key Manager) and add its network address and port information to the vCenter KMS Cluster.
• Then, you will need to set up a domain of trust between vCenter Server, your KMS, and your vSAN host.
• You will do this by exchanging administrative certificates between your KMS and vCenter Server to establish trust.
• Then, vCenter Server will pass the KMS connection data to the vSAN host.
• From there, the vSAN host will only request keys from that trusted KMS.
• The ESXi host generates internal keys to encrypt each disk, generating a new key for each disk. These are known as the data encryption keys, or DEKs.
• The vCenter Server then requests a key from the KMS. This key is used by the ESXi host as the key encryption key, or KEK.
• The ESXi host then uses the KEK to encrypt the DEK and only the encrypted DEK is stored locally on the disk.
• The KEK is safely stored separately from the data and DEK in the KMS.
• Additionally, the KMS also creates a host encryption key, or HEK, for encrypting core dumps. The HEK is managed within the KMS to ensure you can secure the core dump and manage who can access the data.

Final Thoughts

vSphere VM and vSAN encryption for data-at-rest is a powerful tool in protecting your sensitive data - for both companies and VMware Cloud Providers. It is standards-based, policy-based, and KMIP compliant. This makes it both powerful and easy to enable. While each has different strengths that make them a better choice in some situations; most of the time, it will just come down to needing to either secure data in a VM or vSAN datastore.

If you have sensitive data in VMware and are not encrypting, enable encryption today! We are happy to help.

InnoDB, MySQL’s storage engine, offers transparent data encryption (TDE) for your sensitive data-at-rest. It secures the tablespaces via a “two tier encryption key architecture” that consists of:

• Tablespace encryption keys that encrypt the tablespaces.
• A master encryption key that encrypts the tablespace keys.

The only thing that you must add is a trusted, third-party encryption key manager. But more on that later.

With these items in hand, the system works like this:

• A tablespace is encrypted, generating a tablespace encryption key.
• The tablespace key is encrypted via the master key.
• The encrypted tablespace key is stored locally in the tablespace header.
• The master key is stored in a trusted, third-party encryption key manager.
• The master key’s full lifecycle is managed via the encryption key manager.

In this way, when a user or application needs to access the encrypted data, they just need to authenticate that they are authorized to access the data. From there, InnoDB uses the master key to decrypt the tablespace key and tablespace key is used to decrypt the data. The end user never sees this process, it is transparent to them.

Advantages of Using MySQL Encryption

Meets Compliance Regulations

Organizations are under increasing pressure to comply with a patchwork of compliance regulations. The good news, MySQL Enterprise edition uses standards based AES encryption for data-at-rest and is also KMIP compatible, so centralized key managers can plug-in to properly manage the master keys. Here are a few compliance regulations that MySQL Enterprise encryption helps you comply with:

Payment Card Industry Data Security Standard (PCI DSS)

Nick Trenc, IT Security Architect at Coalfire Labs, had this to say about encryption and PCI DSS compliance:

One of the key components to the protection of cardholder data at any merchant location is the use of strong cryptography along with just-as-strong cryptographic key management procedures. PCI DSS Requirement 3 outlines what the PCI council believes to be the baseline for strong cryptographic key management procedures and is a key element of any PCI DSS audit.

General Data Protection Regulation (GDPR)

According to GDPR, your security controls must be adequate to account for the risk of accidental, unlawful, or unauthorized disclosure or loss of personal data. If you are not adequately prepared to fend off attacks from hackers or unscrupulous employees and prevent a data breach, you could face stiff fines and lawsuits. Only proper encryption and centralized key management will ensure that should an attack occur, the data will be useless to the attacker.

California Consumer Privacy Act (CCPA)

Here is what Patrick Townsend said about encryption and CCPA:

If you want to avoid the risk of direct or class action litigation related to data loss you should encrypt the sensitive data. Individual and class action litigation only applies to unencrypted sensitive data that is disclosed or lost, for whatever reason. The CCPA is clear on the need for encryption. If you lose unencrypted sensitive data this is direct evidence that you violated your duty to provide reasonable security procedures and practices to protect the sensitive information.

The good news: enabling MySQL Enterprise encryption, coupled with encryption key management, will help keep you in compliance with these regulations. If you are protecting cardholder data, consumer data, or just internal HR records, encrypting that data with MySQL’s TDE will help you meet compliance and keep that sensitive data safe.

Easy to Deploy

MySQL encryption is easy to configure. Entire databases can be encrypted with just a few command line edits. Here are some selected examples from MySQL’s Reference Manual:

• To enable encryption for a new file-per-table tablespace:
• mysql> CREATE TABLE t1 (c1 INT) ENCRYPTION='Y';
• To enable encryption for an existing file-per-table tablespace:
• mysql> ALTER TABLE t1 ENCRYPTION='Y';
• To disable encryption for file-per-table tablespace:
• mysql> ALTER TABLE t1 ENCRYPTION='N';

Alliance Key Manager also makes this process easy. Since we are fully integrated with MySQL Enterprise, the configuration process is pretty straight forward. Many times, you can be up and running in a matter of minutes.

KMIP Compatible

As MySQL Enterprise encryption is KMIP 1.1 compatible, you can easily deploy your prefered key manager to manage your encryption keys. This means you are able to use a FIPS 140-2 compliant encryption key manager, like our Alliance Key Manager.

How It Works

MySQL Enterprise has made protecting your sensitive data easy. What’s more, setting up Alliance Key Manager for MySQL is easy as well. Here’s how it works:

• First, install and set up the primary and failover Alliance Key Manager servers.
• Download the admin authentication certificates from the Alliance Key Manager server to create a secure TLS connection and perform authentication.
• Then, create a directory to store your KMIP config file and store certificates needed for the Alliance Key Manager admin / client connection.
• Next, you will need to specify your primary key server and high availability failover key server.
• Finally, create a master key in Alliance Key Manager and use that to encrypt your tablespace keys in MySQL.

That's it, you have successfully encrypted your MySQL Enterprise database and properly managed the keys! To learn how Alliance Key Manager can help you easily protect your sensitive data in MySQL.

Final Thoughts

Encrypting your sensitive data in with MySQL’s Enterprise encryption has these advantages:

• It’s standards based AES-256 encryption. This means that your data is secured with the encryption algorithm that NIST recommends.
• It’s KMIP compliant. Your encryption is only strong if your keys are secure. With a trusted third-party key manager protecting your master keys, your encryption will remain strong.
• The encryption is transparent to users and applications. No manual processes are needed to access the databases. The data is there, on demand, for all authorized users and applications.

If you haven’t taken advantage of MySQL encryption, now is the time. MySQL encryption makes it simple. Alliance Key Manager makes it secure. Talk to us today.

This last November (Nov. 6-8, 2019) we had a chance to participate in the 21st annual PASS Summit in Seattle as an exhibitor. It was a great time as SQL Server professionals from around the world attended. We had an opportunity to ask them about their company's encryption and key management practices. Below are the results as well as some expert weigh-in on the findings. Enjoy!

The SQL Server Encryption Survey—2019

A special thanks to our contributors for their expertise and guidance. You all are clear-minded professionals that have a lot to offer those looking to better secure their data:

-Ed Leighton-Dick, Kingfisher Technologies
-Tim Roncevich, CyberGuard Compliance
-Justin Garren, LyntonWeb
-Sharon Kleinerman, Townsend Security
-Patrick Townsend, Townsend Security

If you are looking to protect your encryption keys for your sensitive data in SQL Server, you need a FIPS 140-2 compliant centralized key manager that:

• Never charges you additional fees for connecting a new end-point.
• Never limits the number of end-points based on the model of the KMS.
• Never limits the number of encryption keys generated or stored.
• Never forces you to pay extra fees for software patches.
• Never forces you to pay extra fees for routine software upgrades.
• Always gives you unmatched customer service.
• Always protects your keys, 24/7.

You need Alliance Key Manager for SQL Server.

(Part one of this series deals with VM encryption. This post will cover vSAN encryption)

The Rise of Storage Area Networks

Nowadays, VMware vSAN provides hyper-converged storage for the enterprise business. As VMware puts it, “in addition to being incredibly simple to deploy and provision, Virtual SAN allows you to scale storage and compute resources, eliminating costly forklift upgrades.”

But, as most know, vSAN, first released in 2014, did not grow in a vacuum. Physical SANs started to gain traction in the early 2000’s as our need for data storage exploded. The SANS Institute, in 2002, highlighted these trends and the advantages that a SAN provided:

• Higher availability of systems and applications
• Costly IT purchases reduced
• Higher scalability of storage architecture
• Increased IT staff efficiency
• Higher ability to utilize the full value of a company’s information assets

But even though a SAN brought these advantages to its user, it had one major limitation: Storage administrators were still tied to managing the data via where it physically lived, needing to pre-allocate storage on various servers.

vSAN, however, overcomes the limitations of a purely physical SAN. Since vSAN is a software layer that sits on-top of the server, it allows for greater flexibility of your storage capacity. According to MicroAge:

“vSAN is software-defined storage that enables organizations to pool storage capabilities and automatically provision virtual machine storage. They can dynamically scale performance and storage capacity as needed and render underlying physical storage accessible to virtual machines through a policy-driven control pane. [O]rganizations use SANs to interconnect shared pools of storage devices to different servers. vSAN extends this local storage to a shareable storage in each server, enabling other servers to access data over the LAN without a traditional shared storage device.”

Another advantage of vSAN: greater (and much easier to implement) data security. With version 6.6 of vSAN, VMware introduced native encryption for your data-at-rest. vSAN encryption is baked right into vSAN and, as Jase McCarty of VMware puts it, “with a couple of clicks, it can be enabled or disabled for all items on the vSAN datastore, with no additional steps.”

This gives the enterprise business much greater control in how and when they secure their data. That said, let’s take a look at some additional advantages of using vSAN encryption.

The Advantages of vSAN Encryption

Minimizes Impact on Performance

With encryption there will always be a performance impact. It is just the nature of the beast. But with vSAN encryption, VMware reports:

• Minimal impact to CPU cycles while data is being encrypted.
• A 5-15% CPU penalty and no performance overhead. This overhead is representative of running vSAN with dedupe and compression turned on.

This is great news for those needing to encrypt large amounts of stored data. You can now protect your data and, in large part, maintain the integrity of your performance.

Streamlines Operations

As mentioned earlier, vSAN encryption is easy to configure and entire clusters can be encrypted with just a few clicks. There is zero guess-work with:

• No third-party encryption to install, configure, and maintain.
• No encryption at the hardware layer. Encryption at the hypervisor layer (vSAN encryption) has considerably less overhead than deploying encryption at the hardware layer.

Bring Your Own Key Manager

You can bring your preferred key manager to manage your encryption keys. Since vSAN encryption is KMIP 1.1 compatible, you are free to use a FIPS 140-2 compliant encryption key manager, like our Alliance Key Manager.

How Do I Enable vSAN Encryption?

The last and biggest advantage: vSAN encryption is easy to enable and use. This means that securing your sensitive data with AES encryption is not a time-intensive task. To prove the point, here is a quick guide to getting encryption up and running for your vSAN clusters:

• First, install and configure your key management server, or KMS, (such as our Alliance Key Manager) and add its network address and port information to the vCenter KMS Cluster.
• Then, you will need to set up a domain of trust between vCenter Server, your KMS, and your vSAN host.
• You will do this by exchanging administrative certificates between your KMS and vCenter Server to establish trust.
• Then, vCenter Server will pass the KMS connection data to the vSAN host.
• From there, the vSAN host will only request keys from that trusted KMS.
• The ESXi host generates internal keys to encrypt each disk, generating a new key for each disk. These are known as the data encryption keys, or DEKs.
• The vCenter Server then requests a key from the KMS. This key is used by the ESXi host as the key encryption key, or KEK.
• The ESXi host then uses the KEK to encrypt the DEK and only the encrypted DEK is stored locally on the disk.
• The KEK is safely stored separately from the data and DEK in the KMS.
• Additionally, the KMS also creates a host encryption key, or HEK, for encrypting core dumps. The HEK is managed within the KMS to ensure you can secure the core dump and manage who can access the data.

That’s it! VMware has made encrypting your data in vSAN both simple and secure.

Final Thoughts

Let’s face it, storage area networks are a target-rich environment for malicious actors. Whether it’s:

• Customer data
• Intellectual property
• Financial transactions
• Legal records
• Patient information
• And much, much more….

It all needs to be protected. Network administrators, though, face these challenges:

• They have little control over what gets put into storage.
• Sensitive data, many times, is stored by end users with little thought to encrypting it.
• There is a dizzying array of compliance regulations, internal security standards, and best practices that must be complied with.

vSAN encryption can help. With a few clicks in vSAN entire virtual disks can be encrypted. And with a FIPS 140-2 compliant encryption key manager, like Alliance Key Manager, the keys for your AES-NI encryption will be properly protected and full lifecycle managed.

If you are not protecting your data in vSAN, get started today! It’s not a matter of if your data will be hacked, but when.

(Part one of this series deals with VM encryption. Part two will cover vSAN encryption)

A Unified Way to Encrypt VMs

“Dance like nobody’s watching. Encrypt like everyone is.”
~Werner Vogels, CTO at Amazon.com

Data is a bedrock asset for today’s enterprise business. Its value is too great to ignore. Data security, then, is mission critical for those looking to maintain brand integrity, intellectual property confidentiality, and customer trust.

VMware vSphere 6.5 gave its users powerful data security tools; among them AES-NI encryption. The reason this is great news: instead of an ad-hoc approach to encrypting sensitive data where individual sources of encryption are found for each type of database or application, you can now encrypt directly in VMware’s hypervisor creating a unified source for encrypting and managing that encryption. And through their KMIP interface, managing your encryption keys is pretty painless. But more on that later.

vSphere encryption, then, allows the enterprise business to uniformly manage their encryption for both VMs and vSAN and ensure that all sensitive data within VMware is secured. This enables companies to create an encryption strategy for their sensitive data. Let’s look at some of the main advantages, specifically VM encryption, that vSphere encryption provides.

The Advantages of Using VM Encryption

With VMware vSphere 6.5 and up, you are able to encrypt individual VMs. The main difference between VMware encryption and other encryption methods is ease

of management. As VMware puts it, because “VMs are treated as objects that can have a policy applied to them, there is no need to manage them individually.”

Here are some of the advantages that this brings:

• Encryption is configured and managed at the hypervisor level, not within an individual VM.
  • vSphere encryption is agnostic in regards to what is stored within the VM.
  • There are not multiple encryption products for each guest OS, database, or application.
• Encryption is policy based. Applying it, then, can be done to as many or few VMs that you want.
• You can bring your prefered key manager to manage your encryption keys. Since vSphere encryption is KMIP 1.1 compatible, you are free to use a FIPS 140-2 compliant encryption key manager, like Alliance Key Manager.

Now that we know some of the advantages of using VM encryption, let’s looks what is (and is not) encrypted. Why? VMware did a great job making sure all sensitive information can be secured. The list below will go to illustrate that.

What Is/Is Not Encrypted

According to VMware, here are the items that can be encrypted (and those that can’t) with vSphere’s VM encryption:

What can be encrypted:

• VM files
• Note: Most VM files can be encrypted. This set of files can include the NVRAM, VSWP, and VMSN files. If you use the vSphere Web Client to create an encrypted VM, all virtual disks will be encrypted as well.
• Virtual disk files
• Note: Data in an encrypted VMDK file is never written in plaintext to storage or a physical disk, and is never transmitted in plaintext. The VMDK descriptor file, however, is not encrypted and contains a key ID for the key encryption key (KEK) as well as the encrypted data encryption keys (DEKs).
• Host core dump files
• Note: When you enable encryption mode on an ESXi host the core dump is always encrypted.

What is not encrypted (and why):

• Log files
• Why: these are not encrypted because they contain no sensitive data.
• VM configuration files
• Why: the VM configuration information, stored in the VMX and VMSD files, contains no sensitive data.
• Virtual disk descriptor files
• Why: the descriptor file is omitted from encryption/decryption functions to support disk management without a need for an encryption key.

How it Works

Now that we know some of the advantages of VM encryption and what can and cannot be encrypted; here is the last reason to use vSphere to create a unified encryption strategy—it is easy to set up. Here is a quick video showing how easy it is.

Here are those steps for those that would like to just read it:

• First, install and configure your KMIP compliant key management server, such as our Alliance Key Manager, and register it to the vSphere KMS Cluster.
• Next, you must set up the key management server (KMS) cluster.
• When you add a KMS cluster, vCenter will prompt you to make it the default. vCenter will provision the encryption keys from the cluster you designate as the default.
• Then, when encrypting, the ESXi host generates internal 256-bit (XTS-AES-256) DEKs to encrypt the VMs, files, and disks.
• The vCenter Server then requests a key from Alliance Key Manager. This key is used as the KEK.
• ESXi then uses the KEK to encrypt the DEK and only the encrypted DEK is stored locally on the disk along with the KEK ID.
• The KEK is safely stored in Alliance Key Manager. ESXi never stores the KEK on disk. Instead, vCenter Server stores the KEK ID for future reference. This way, your encrypted data stays safe even if you lose a backup or a hacker accesses your VMware environment.

It really is that easy. Not only can govern your encryption at the hypervisor layer, deploy standards based AES encryption on a per VM basis (allowing you to secure only those workloads that require it), but you can do so quickly. It is a great encryption option for any business.

Final Thoughts

VMware vSphere VM encryption creates a unified strategy for protecting your sensitive data within vSphere by using the hypervisor to perform the encryption. This means that you do not need to first consider what is in the VM (guest OS, specific databases, etc.) in order to encrypt it. According to VMware, this yields the following benefits:

• No modification to OSs within VMs
• No changes needed to existing applications
• No specialized hardware or infrastructure required
• Policy-based enforcement that is supported by vSphere

All this and more means that it is easier than ever to secure your company’s sensitive data. Once you have configured your vSphere vCenter Server to enable encryption, simply choose which VMs you want to encrypt and your data is secured. It’s that easy.

According to RiskBased Security, for the first half of 2019, over 3,800 breaches were reported, breaching over 4.1 billion records. When you compare that to the first half of 2018, “the number of reported breaches was up 54% and the number of exposed records was up 52%.” With the pace of breaches only accelerating, the time to create a unified encryption strategy for your sensitive data is now.

Recently, we here at Townsend Security had the opportunity to poll the fans of our Newsletter to see how folks are doing with encryption and key management for their data-at-rest. We conduct this survey, and surveys like it, so that the larger InfoSec community can get a snapshot of how businesses, in general, are doing in securing their sensitive data. Below are a few key findings, hope you enjoy!

Overall Results

First, the good news: 73% of respondents report that they encrypt their sensitive data while at-rest. This makes sense as all the respondents are fans of our Newsletter; the group is a little self-selecting in that they have already expressed an interest in data security. Of course, we would like to see the number at 100%, but that would mean our work is already done—and we know we still have a long way to go.

To give a bit of perspective, we conducted two additional surveys that represent a more general audience that we published, here and here. In those two surveys the adoption rate for encryption is closer to 50%. So, hats off to our fans for being above the curve!

Now, the bad news: Only 50% of respondents say that they use proper key management to secure their encrypted data-at-rest (again, a little self-selecting in that, as part of the reason they like our Newsletter is that they are learning more about key management). Interestingly, even if you adjust the data to only look at those who replied that they do use encryption, the number only jumps to 66%.

As a comparison with the wider community, only about 30% of respondents in our other two polls (referenced above) said that they use encryption key management to securely manage their keys.

Expert Weigh-In: Patrick Townsend, CEO of Townsend Security
"Encryption is not enough. In order for encryption to be secure, the keys must be properly managed—100% of the time. If you don’t properly manage your encryption keys, it is like placing your house keys under your welcome mat. Every good thief knows to look in the obvious places for easy entry. Hackers do as well."

Encryption and Key Management Use, per Database/Blob Storage

It is no surprise to see that, overall, if a database/blob storage reports a rise/fall in the use of encryption, there is also a corresponding rise/fall in the use of proper key management. What is interesting, however, is the databases/blob storage where the respondents reported the widest gap in adoption of key management in comparison to the adoption of encryption. Here are the top five databases and their corresponding adoption gaps:

What may or may not be surprising is that SharePoint leads the pack in lack of key management adoption (compared to encryption adoption) and SQL Server Enterprise Edition comes in third. SharePoint is built on top of Microsoft SQL Server as its datastore (for structured data, at least). For SQL Server 2008 Enterprise edition and up, you now have the ability to not only take advantage of SQL Server’s Transparent Data Encryption (in SharePoint and SQL Server), but you also can leverage the power of a third-party encryption key manager using Extensible Key Management (EKM). This means it is incredibly easy to not only deploy encryption but also proper manage the encryption keys.

What is less surprising is the other three that made the top of the list. All these come with free editions that do not come with encryption libraries, let alone the ability to properly manage the keys. So anyone spinning up a free version of these databases will, by their very nature, not be able to secure their data.

Expert Weigh-In: Tim Roncevich, Partner at CyberGuard Compliance
"Many Enterprise editions of databases come with robust AES encryption and a way for a third-party vendor to manage the encryption keys. If you are storing sensitive data in an open-source, or free, version of a database, upgrade today. Hacks similar to the Cathay Pacific breach of 2018 were due to the company not upgrading to the Enterprise edition to take advantage of the encryption and key management that were available to them."

What Virtualization Do You Use?

About three-quarters of respondents said that they use VMware in their environment. The other quarter reported using Hyper-V, Red Hat Virtualization, Citrix Hypervisor, or KVM. Less than 10% said they used multiple virtualization platforms.

This is great news for the majority of businesses, then, in terms of encryption and key management. VMware’s vSphere 6.5 and up come with encryption ready to use. Not only that, but using a third-party encryption key manager is easy to set up and deploy.

Expert Weigh-In: Sharon Kleinerman, Director of Sales at Townsend Security
"For those organizations struggling to secure their data-at-rest with encryption and key management, doing so has never been easier. If you have VMware 6.5 and above, you simply set up your third-party key manager through vSphere’s KMS Cluster KMIP interface, tell vSphere which VMs you want encrypted, and your data is encrypted. Same with vSAN. It really is easy to encrypt with VMware as your virtual environment."

Backup & Recovery Solutions

Backup and recovery solutions are an integral part of business continuity. In fact, Allied Market Research estimates that the market will grow by almost 25% year over year through 2023. In the next few years, however, Gartner estimates that 50% of companies will augment or replace their current backup solution with another.

Our findings fall roughly in line with Gartner’s research. According to our survey, about 40% of respondents say they will, or don’t know if they will, replace their current backup and recovery solution.

Expert Weigh-In: Steve Brown, Partner at Rutter Networking Technologies
"For those thinking of switching your B&R solution, it is important to make sure that the solution you are switching to provides encryption and a way to manage your encryption keys. Encryption should not be an afterthought. Instead, it should be one of the main drivers as to why you would either stay with your current solution or look farther afield."

Conclusion

The rate at which data breaches are happening is not slowing down. We all know this. But the adoption rate of best practices is still lagging. While it is heartening to see our blog’s fanbase beating the overall average for using encryption and key management to secure sensitive data-at-rest, We still have a long way to go.

The good news, it is easier than ever to adopt best practices. If you are thinking about truly defending yourself with a defense-in-depth strategy, talk to us today.

This June we had a chance to participate in MongoDB World 2019 in New York City as an exhibitor. It was a great time as MongoDB professionals from around the world attended. We had an opportunity to ask them about their company's encryption and key management practices. Below are the results as well as some expert weigh-in on the findings. Enjoy!

If you are looking to protect your encryption keys for your sensitive data in MongoDB, you need a FIPS 140-2 compliant centralized key manager that:

• Never charges you additional fees for connecting a new end-point.
• Never limits the number of end-points based on the model of the KMS.
• Never limits the number of encryption keys generated or stored.
• Never forces you to pay extra fees for software patches.
• Never forces you to pay extra fees for routine software upgrades.
• Always gives you unmatched customer service.
• Always protects your keys, 24/7.

You need Alliance Key Manager for MongoDB.

This last November (Nov. 6-9, 2018) we had a chance to participate in the 20th annual PASS Summit in Seattle as an exhibitor. It was a great time as SQL Server professionals from around the world attended. We had an opportunity to ask them about their company's encryption and key management practices. Below are the results as well as some expert weigh-in on the findings. Enjoy!

A special thanks to our contributors for their expertise and guidance. You all are clear-minded professionals that have a lot to offer those looking to better secure their data:

-Sebastian Meine, Ph.D., sqlity.net
-Steve Brown, Rutter Networking Technologies
-Tim Roncevich, CyberGuard Compliance
-Sharon Kleinerman, Townsend Security
-Patrick Townsend, Townsend Security

If you are looking to protect your encryption keys for your sensitive data in SQL Server, you need a FIPS 140-2 compliant centralized key manager that:

• Never charges you additional fees for connecting a new end-point.
• Never limits the number of end-points based on the model of the KMS.
• Never limits the number of encryption keys generated or stored.
• Never forces you to pay extra fees for software patches.
• Never forces you to pay extra fees for routine software upgrades.
• Always gives you unmatched customer service.
• Always protects your keys, 24/7.

You need Alliance Key Manager for SQL Server.

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.

Updated: 3/13/2020 - to reflect current status of TDE in SQL Server editions.

In 2008, Microsoft introduced Transparent Data Encryption (TDE) to its Enterprise and Datacenter Editions of SQL Server. Billed as a way to seamlessly deploy SQL Server encryption, users now had the choice of full database-level encryption, instead of just the previous choices of cell-level encryption (CLE), Encrypting File System (EFS), or Bitlocker. With its rapid deployment, ease-of-use, and enhanced security TDE has been a staple for every version of SQL Server Enterprise Edition (and Developer Edition) ever since.

Versions of SQL Server Enterprise with TDE:
2008 and up

Versions of SQL Server Standard with TDE:
2019 and up

SQL Server TDE has become a favorite for bulk encryption in meeting regulatory compliance (like PCI DSS) or internal corporate data security initiatives. But while TDE has it’s advantages, it is not a cure-all. Sung Hsueh did a great job explaining the advantages and disadvantages of TDE as compared to CLE. The following is a curated look at that whitepaper. Let’s take a quick look:

What is Transparent Data Encryption?

TDE fundamentally is full database-level encryption. It functions at the Input/Output (I/O) level. Any data written into the database is automatically encrypted. Backups are also automatically encrypted. Data in use is decrypted by TDE as they are read by a user or application and stored, in clear text, in memory. Since the data-in-flight is decrypted; TLS or SSH (or now, “Always Encrypted”) should be enabled to protect the data while in motion.

What is Cell-Level Encryption?

Introduced in 2005, CLE is implemented as a series of built-ins. It is a manual process “that requires a re-architecture of the application to call the encryption and decryption functions.” Hsueh also notes that “the traditional limitations of encryption are inherent in this method as none of the automatic query optimization techniques [of TDE] can be used.” 

CLE vs. TDE

• Since it is column level encryption, it encrypts only the sensitive information in a table.
• With CLE, the data is still encrypted even when it is loaded into memory.
  CLE allows for “explicit key management” giving you greater control over the keys and who has access to them.
• CLE is highly configurable, giving you a high degree of customization (especially when your applications require it).
• Queries may be faster with CLE if the encrypted column(s) is not referenced in the query. TDE will always decrypt the entire row in the table. CLE will decrypt the column value only IF it is a part of the data that is returned. So in some cases CLE implementations provide much better overall performance.

The disadvantages of CLE:

• One of the main disadvantages of CLE is the high degree of fully manual application changes needed to use it. TDE, on the other hand, can be very simple to deploy with no changes to the database, tables or columns required.
• CLE can also have high performance penalties if search queries cannot be optimized to avoid encrypted data. “As a rough comparison, performance for a very basic query (that selects and decrypts a single encrypted column) when using cell-level encryption tends to be around 20% worse [than TDE].”

The whitepaper goes on to note that with CLE performance impacts “are several magnitudes worse when attempting to encrypt an entire database. One sample application with 10,000 rows was four times worse with one column encrypted, and 20 times worse with nine columns encrypted.” TDE, on the other hand, only had a 3-5% average performance impact compared to a non-encrypted database.

Final Thoughts

A case could be made for using CLE in conjunction with TDE as a defense-in-depth strategy. By selectively encrypting columns with CLE, encrypting the full database with TDE, and then managing the separate keys with a centralized key manager; it would ensure that crucial data was protected, even while loaded into memory.

But, in general, TDE and CLE are used for different purposes. If you are looking to encrypt a small amount of data, if your application “has custom design requirements,” or if performance is not a much of a concern, CLE may have advantages over TDE. But, if performance is a concern or you would like to avoid manually implementing encryption (normally a time-consuming process) then TDE is the way to go.

For more information on both types of encryption and how they relate to Extensible Key Management, visit our Definitive Guide to SQL Server Encryption & Key Management.