Townsend Security Data Privacy Blog

Over the last several years, encryption key management has attained “essential infrastructure” status. When done properly, key management can protect encrypted data - and in the event of a data breach, can even provide a company with an exemption for a breach notification.

I recently sat down with Patrick Townsend, Founder and CEO of Townsend Security to talk about encryption key management and the importance of standards, what to look for in a key manager, and fundamental features of an enterprise grade key manager. While Townsend Security isn’t alone in the key management game, there are a few telltale signs that differentiate a key manager that meets industry standards and one that will leave you with a breach notification on your hands. Let’s jump in.

Hi Patrick. Townsend Security has been in the key management game for close to 10 years now. Back when Alliance Key Manager was brought to market, people weren’t really sure what key management was. Now it is considered essential infrastructure.

Yes, it sure is. Things have changed so dramatically over the last few years. Encrypting sensitive data is now a requirement for businesses who need to meet data privacy compliance regulations. And it is also achieving visibility at the executive level as a part of a GRC (governance, risk, compliance) plan. The landscape really has changed a great deal, and I think organizations are stepping up and doing a better job.

We are also seeing databases implementing encryption directly into the database engine. MongoDB Enterprise is an excellent example of this by incorporating AES encryption into the WiredTiger storage engine and providing KMIP for good key management. Microsoft SQL Server Enterprise has also built the encryption engine right into the database with transparent data encryption (TDE) and provides extensible key management (EKM) for vendors like us to plug in to and allow users to properly manage encryption keys.

Let’s spend a minute on compliance. What regulations require key management?

It is true that there are a lot of compliance regulations and most of us fall under multiple. Certainly, GDPR and the new Australian law have come on board and are affecting the way companies all over the world, even outside of the EU, who are now taking steps to protect that data. Almost all regulations require the protection of data, which encryption can help with. Regarding encryption, from a best practices point of view, if you don’t have proper key management, you don’t have encryption.

PCI DSS and the payment industry has now been with us for a decade and that also drives the protection of a lot of sensitive data. While PCI DSS is a private regulation between merchants who accept credit cards and the industry, it is a strong regulation with strong penalties. Because of the longevity and focus on security, PCI DSS often informs other regulations and corporate governance boards.

While we live in a very complex set of compliance requirements, there are fortunately some similarities. When we set out to protect sensitive data, and do it right, which I am sure you know by now means based on standards and security best practices, we find business meeting a broad set of regulations.

As I mentioned earlier, key management is considered essential infrastructure. Back when Townsend Security first entered the market, there were just a few options for the enterprise to choose from. Today, options have dramatically increased. With that said, there are a few ways to distinguish a key manager that meets industry standards and one that will leave you with a breach notification on your hands.

There are a few key quality indicators when assessing key management systems. First off, a key management server must be validated to FIPS 140-2. That is the US and Canadian standard for cryptographic modules and it is just a fundamental indicator of the seriousness of a company and its ability to build good key management solutions. Unfortunately, there are claims of FIPS 140-2 compliance by vendors who have systems which have actually not completed a validation. It’s always a good idea to ask your key management vendor what their certificate number is so that you can look it up yourself on the NIST website. Additionally, key management vendors should be able meet KMIP requirements by demonstrating interoperability. These sorts of validations and certifications show that a key management vendor is stepping up to the technical requirements that customers expect.

Finally, there are individual specific validations to regulations. Our key manager, for example, has been through a PCI DSS validation with a QSA auditor and with VMware. You want to avoid solutions that are simply “key storage” which haven’t been validated and there has not been external review and validation of the cryptographic approach. It is incredibly easy to get encryption and key management wrong from a technical point of view.

Third-party attestations and validations are critically important. You are putting your digital assets, not to mention your company’s reputation, at risk when you use a poor quality key management server (KMS). Fortunately, today there are very affordable solutions available everywhere from a traditional hardware security module, to VMware, to the cloud. 10 years ago, key management servers where terribly expensive.

Yeah, I have been seeing key managers hitting the market that range from open source to cloud service provider (CSP) provided. Some key managers will even claim FIPS compliance when a simple check with NIST shows them nowhere to be found. You also get providers who claim FIPS compliance because they are using a module that has been through a validation, which as I am sure you can tell us more about, doesn’t make your solution compliant.

That’s right. Unfortunately, there is still a fair amount of snake oil in the industry. People claim FIPS 140-2 compliance, but haven’t fully been through the process. As you mentioned, claiming one component as being FIPS 140-2 compliant does not make your entire solution compliant. I like to say, “I drive a Toyota. If I put a Jaguar hood ornament on my car, it doesn't turn my car into a Jaguar. It is still a Toyota!” There is a lot of language used by some solution providers that just isn’t accurate and should be verified before choosing a solution.

You also talked about governance. Let’s take a look at the recent Marriott/Starwood breach. There was an interesting statement where they said “we can’t be absolutely sure that the encryption keys weren’t lost.” If you are using enterprise level key management systems, you have monitoring and audit trails that will show if keys have been retrieved. By them not knowing, it is easy to surmise that they weren’t adequately protecting our information. This was a failure of governance in regards to critical security infrastructure. We might not be talking about the breach right now had they had industry standard key management in place.

Changing gears a little, we have in the past seen cloud vendors offer key management systems in their shared environments. Multi tenant key management presents a concern for enterprises. Just last week I had a conversation with a security professional from a global enterprise who said, “for us, trust is paramount to our brand. We will never allow encryption keys to be stored and accessed by a cloud vendor.” I thought it was a very interesting statement and completely lines up with other enterprises that I speak with.

There is also a bit of confusion on the term KMS. For example, VMware defines KMS as a Key Management Server. Amazon, on the other hand, defines their KMS as a “Key Management Service.”

Well, there is a bit of confusion on this isn’t there? A true enterprise key management system (KMS), is responsible for the entire lifecycle of an encryption key - from generation where admins create provably strong keys, to storage, to provisioning applications and users who need the keys, all the way through to the archival and destruction of the keys. Key management systems manage all of those phases according to industry standards.  

A key management service can better be defined as storage service and offers a mix of capabilities. Some are services that are shared, multi-tenant environments. CSP key managers often work this way (think AWS KMS, Azure Key Vault). Many services don’t give you full access or control over a key’s complete lifecycle. Some services allow you to bring your own key, but then bring that into their own infrastructure, where you then share administrative access and control.

It is very important to know that if you are truly trying to do security the right way, you need a key management system that is built to industry standards and validated to industry standards. One last point, it is possible to do key management correctly in the cloud. There are third-party key management offerings that can be found in the marketplace that meet all the standards that we have been talking about, and are dedicated to you and only you. Our Alliance Key Manager is one, for example.

A feature that we are very proud of with our key manager is that it runs the same software in the Cloud, VMware, or as a traditional hardware security module (HSM). We have customers setting up hybrid cloud/on-prem deployments or even cross-cloud. The way we license our key managers works really well for the modern enterprise which needs a predictable, low TCO. With Alliance Key Manager, there are never added fees for additional databases or applications.

To hear this conversation in its entirety, download our podcast Don’t Forget About FIPS 140-2 and Other Fundamental Key Management Features and hear Patrick Townsend further what enterprises should look for in a key manager, the importance of standards, and other fundamental features of an enterprise grade key manager.

Townsend Security, today announced that its Alliance Key Manager for VMware has achieved VMware Ready status. This designation indicates that after a detailed validation process Alliance Key Manager for VMware has achieved VMware’s highest level of endorsement and is supported on VMware ESXi  (all supported versions, vSphere 6.5 and later, and vSAN 6.6 and later) for production environments.

“We are pleased that Townsend Security and Alliance Key Manager for VMware qualifies for the VMware Ready logo, signifying to customers that it has met specific VMware interoperability standards and works effectively with VMware cloud infrastructure. This signifies to customers that Alliance Key Manager for VMware can be deployed in production environments with confidence and can speed time to value within customer environments,” said Kristen Edwards, director, Technology Alliance Partner Program, VMware.

By using Alliance Key Manager for VMware with VMware ESXi (all supported versions, vSphere 6.5 and later, and vSAN 6.6 and later) organizations can centrally manage their encryption keys with an affordable FIPS 140-2 compliant encryption key manager. Further, they can use native vSphere and vSAN encryption to protect VMware images and digital assets at no additional cost. VMware customers can deploy multiple, redundant key servers as a part of the KMS Cluster configuration for maximum resilience and high availability.

“By achieving VMware Ready status with Alliance Key Manager for VMware, Townsend Security has been able to work with VMware to bring affordable encryption key management to VMware customers and the many databases and applications they run in VMware,” said Patrick Townsend, CEO of Townsend Security. “Meeting data security compliance in VMware vSphere is now easier than ever.”

The VMware Ready program is a co-branding benefit of the Technology Alliance Partner (TAP) program that makes it easy for customers to identify partner products certified to work with VMware cloud infrastructure. Customers can use these products and solutions to lower project risks and realize cost savings over custom built solutions. With thousands of members worldwide, the VMware TAP program includes best-of-breed technology partners with the shared commitment to bring the best expertise and business solution for each unique customer need.

Townsend Security and Alliance Key Manager for VMware can be found within the online VMware Solution Exchange (VSX) at https://tsec.io/VMwareReadyPR. The VMware Solution Exchange is an online marketplace where VMware partners and developers can publish rich marketing content and downloadable software for our customers.

VMware, VSXi, vSphere, vSAN and VMware Ready are registered trademarks or trademarks of VMware, Inc. in the United States and other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies.

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.

MongoDB is revolutionizing the world of ‘Database’ with its scalable, secure, replicating database. With MongoDB Enterprise Advanced customers get the ability to protect sensitive data with built-in encryption, and a convenient, standards-based interface for encryption key management based on the industry standard Key Management Interoperability Protocol, or KMIP. Here at Townsend Security we fully support the MongoDB Enterprise Advanced key management architecture, and have certified our Alliance Key Manager with MongoDB for both Intel and IBM Power architectures. And, Alliance Key Manager supports real-time key mirroring between one or more failover key servers to ensure that you never have a service interruption because of a failed connection to a key server!

Customers often ask us how to design a resilient key management strategy with MongoDB. So let’s look at three common scenarios.

First, a note about the use of a load balancer

The key management interface for MongoDB Enterprise Advanced only allows for the definition of one key management server. In order to define one or more failover key servers, the following scenarios use a load balancer to allow connecting to the failover key server. As their name implies, load balancers are normally used to balance workload requests among multiple servers, and are available in all platforms where MongoDB is supported (VMware, cloud, etc.). In this case you use a load balancer to provide a failover mechanism. Future versions of MongoDB may support the definition of multiple key servers in the MongoDB configuration file - if that occurs the use of a load balancer would not be required.

Scenario 1: A primary and one local secondary replication set

Imagine a simple implementation of MongoDB that involves one primary node and one secondary node to provide for data recovery and high availability. In this scenario the secondary node is deployed locally, or in the cloud across regions or availability zones,  to the primary node. However, many MongoDB customers deploy the secondary node in a remote location to improve business recovery (see the next session).

Our goal in this scenario is to minimize or eliminate business interruption in the event the primary node fails or the key server for the primary node fails. To achieve this, we leverage the KMIP interface of MongoDB, a load balancer, and the key mirroring capabilities of Alliance Key Manager. 

From the mongod.conf configuration file:

It is important to note that we don’t have to worry about redundancy and failover of MongoDB itself. This is very nicely handled by MongoDB. What we are striving to achieve is to implement an equally resilient interface to key servers.

The primary MongoDB node has a KMIP configuration that points to the load balancer. The load balancer itself is configured to connect to the primary key server and a failover key server. Note that the failover key server is actually the key server for the secondary MongoDB node. In this scenario each key server functions as the primary key server for the local node, and as the failover key server for the other node. In the event the primary key server cannot be reached due to a network failure or a key server failure, the load balancer uses the secondary key server.

Alliance Key Manager supports real-time key mirroring between one or more failover key servers. In the above scenario if the primary key server fails, the secondary key server will have a copy of the necessary encryption key. Note that Alliance Key Manager can mirror keys to more than one failover key server if needed.

The result of this type of implementation is a fully redundant key server deployment to protect both the primary MongoDB node as well as a fully redundant key server deployment for the secondary MongoDB node.

Scenario 2: A primary and multiple secondary replication sets

MongoDB customers often deploy more complex implementations with multiple secondary replication sets. This might be done to provide high performance for data ingestion (writes) into the primary node, while secondary nodes provide high performance query support and data redundancy. This type of scenario involves multiple nodes each with its own availability and recovery requirements. There can be many key managers involved in supporting this environment.

This scenario also leverages the use of load balancers to provide for automatic failover to a secondary key server. See the notes above about load balancers.

Primary and secondary MongoDB nodes have KMIP configurations that point to a load balancer. The load balancers are configured to connect to the defined failover key server when needed. Note that the failover key server is a different key server on another MongoDB node. In this scenario each key server functions as the primary key server for the local node, and as the failover key server for the other node. In the event the primary key server cannot be reached due to a network failure or a key server failure, the load balancer uses the secondary key server.

Alliance Key Manager supports real-time key mirroring between one or more failover key servers. In the above scenario if a key server fails, the secondary key server will have a copy of the necessary encryption key. Note that Alliance Key Manager can mirror keys to more than one failover key server if needed.

The result of this type of implementation is a fully redundant key server deployment to protect both of the MongoDB nodes.

Scenario 3: Complex, geographically distributed nodes

In complex MongoDB deployments that involve many geographically dispersed nodes, the same principles can be used to create highly redundant and resilient key management services. In this case the key managers are mirroring encryption keys and access policy across geographically dispersed locations. An encryption key management server and its backup mirrored server are available in all regions. 

This scenario uses multiple key management servers to provide a very high level of resilience and redundancy. The primary MongoDB node runs a primary and secondary server in order to ensure a high level of hot failover support. The remote MongoDB nodes also run a primary and secondary key server for the same reason - to provide the maximum availability of the secondary MongoDB databases. It is also important to note that this key server deployment leverages the ability of Alliance Key Manager to replicate keys to more than one additional key server.

In this example there may be many geographic regions that participate in the MongoDB replication group. Note that it is possible that multiple MongoDB nodes can share one set of key servers. There is no requirement that each MongoDB node needs to have its own key server.

This more complex MongoDB configuration demonstrates the scalability of Alliance Key Manager to serve even very complex deployments of MongoDB. And you can start with a simple deployment of MongoDB and scale up the key management deployment as you grow MongoDB.

Summary

Hopefully the above scenarios will help you understand and plan your MongoDB encryption key management needs, and provide a template for the growth of your MongoDB platforms. With Alliance Key Manager it is easy to start with a simple MongoDB deployment and then scale it as you invest more deeply in MongoDB technology. You won’t paint yourself in a corner with your early configurations!

Important note about MongoDB Atlas:

At the time this blog was written there is no support for key management using KMIP for MongoDB Atlas, the cloud-based solution. The MongoDB Atlas service only supports AWS Key Management Service (KMS) and Azure Key Vault.  Full encryption key management support is available by running MongoDB Enterprise Advanced as an AWS EC2 instance, Microsoft Azure virtual machine, or Google Cloud Platform virtual machine. We will update this blog if MongoDB Atlas implements the KMIP interface for key management.

Resources

Alliance Key Manager for MongoDB

MongoDB Security Guide

MongoDB technical guides

In April of this year the Payment Card Industry Security Standards Council (PCI SSC) released a new document on cloud guidance called “Information Supplement: PCI SSC Cloud Computing Guidelines”. It was an update of the first version of the guidance issued in 2013. While this is not a set of mandatory rules, it is a core guidance document and recommendations in PCI guidance documents often end up as requirements under the PCI Data Security Standard (PCI-DSS) and PCI Payment Application Data Security Standard (PCI PA-DSS). So it is worth understanding the guidance and it is wise to align your IT and business processes with the guidance. It is better to get things right at the beginning rather than have to rip-and-tear to fix things later.

There is another reason to pay attention to the PCI cloud guidance: The PCI standards often set the expectations for security best practices in other regulations, and reflect evolving industry standards such as those developed by the National Institute of Standards and Technology (NIST). Even if you are not processing credit card payments, you should be paying attention to this guidance.

When it comes to encryption key management in the cloud, there is a bombshell in this document (essentially describing services such as Amazon KMS and Microsoft Key Vault). What does the new PCI guidance say about encryption and key management? Let’s parse it out and see where it goes.

Take a look at appendix E.10 “Data Encryption and Cryptographic Key Management”.

Appendix E.10 starts by describing the shared, multi-tenant architecture of cloud services (pretty much states the obvious). And then makes this statement:

“If a Customer shares encryption keys with the Provider, or engages the Provider as a key custodian, details of Provider access permissions and processes will also need to be reviewed and verified.

This consideration is particularly critical if cryptographic keys are stored or hosted by a third-party Provider that also hosts the encrypted data. If Provider personnel have access to a Customer’s keys and the Customer’s encrypted data, the Customer may have unintentionally granted the Provider ability to decrypt its sensitive data.”

In fact, all cloud service providers such as Amazon (AWS), Microsoft (Azure), and Google (GCP) have access to both your data and your encryption keys if you are using their key management services. This includes AWS Key Management Service (KMS), Azure’s Key Vault, and Google’s Customer Customer-Managed Encryption Keys (CMEK). Perhaps unknowingly, you HAVE granted your cloud provider the ability to decrypt your sensitive data.

Here is how the PCI SSC sees the risk:

“Any data that is decrypted in the cloud may be inadvertently captured in clear text in process memory or VMs via cloud maintenance functions (such as snapshots, backups, monitoring tools, etc.). To avoid this risk, Customers may choose to keep all encryption/decryption operations and key management on their own premises, and use a public cloud only for storage of the encrypted data.

Applicable controls must be applied to the encryption, decryption, and key management processes to ensure that data can only be retrieved (decrypted) by those who are authorized with a defined business need.”

Wow, that’s a pretty strong statement about not allowing your cloud provider have access to your encryption keys and sensitive data. It is hard to imagine a scenario where the cloud service provider has a “defined business need” to access your sensitive data.

Pointing back to the perceived risks of the cloud provider, here is the key point in the PCI cloud guidance:

Because compromise of a Provider could result in unauthorized access to multiple data stores, it is recommended that cryptographic keys used to encrypt/decrypt sensitive data be stored and managed independently from the cloud service where the data is located.

Wow, there you have it. Don’t use the cloud service providers key management service because there is too much risk. This recommendation affects a very large number of users in the cloud.

Where do we go from here?

Fortunately, there are solutions available now to solve this problem (we have one). Let’s outline some options. There will be pluses and minuses for each one. But the good news is that there are multiple solutions to this issue.

1. Deploy your own dedicated key manager in your own on-premise data center

It is fairly easy to deploy an encryption key manager in your own data center and enable its use by cloud applications. Most enterprise key managers use a secure TLS-encrypted session to interoperate with the key manager. Once you enable an outbound TCP port to your key manager, you can easily use the on-premise key manager. Note that this could be a hardware security module (HSM) or a virtual key management appliance running in VMware.

Remember that you probably do not have to retrieve the encryption key from the key server to your cloud application - most key managers support on-board encryption and decryption services. This alleviates the risk of an exposure of the encryption key in cloud memory. Performance will be the important factor to weigh in this regard. While the key manager may be quite efficient in the encryption or decryption operation, the communications lag times may mitigate against this approach.

2. Deploy your own dedicated key manager in a hosted platform

If your organization does not have on-premise infrastructure for a key manager, don’t despair. It is really straightforward to deploy a key manager in a hosted environment. A hosting provider can provide a home for a hardware security module, or for a software appliance. Establishing the firewall rules may take a bit more work, but this is an approach that has worked well for our customers.

3. Deploy your own dedicated key manager in a different cloud

One creative option to separate the encryption keys from the protected data is to deploy the key manager in a different cloud platform. You could, for example, deploy your application data in Amazon Web Services, and deploy the key manager in Microsoft Azure. This helps mitigate the risk of one cloud service provider having access to both your encryption keys and your protected data - one of the key concerns expressed in the PCI guidance.

Note that this solution will probably require that you work with the firewall rules in both cloud provider platforms. The good news is that this is not complicated - we have customers doing this today.

4. Deploy your own dedicated key manager in a separate cloud instance

Lastly, it is possible to deploy a dedicated key management solution in the same cloud as your protected data, but completely avoid the use of the cloud provider’s encryption key management infrastructure. The key server runs in its own virtual machine or EC2 instance and encryption key management is exclusively dedicated to you. If you take this approach, but sure that your key management vendor is not using the cloud providers encryption key management infrastructure! Encryption keys and key management should only be accessible to you and not to your vendor or cloud provider.

I know that some cloud customers are reluctant to take this approach due to concerns about the ability of the cloud provider to access all of the customer applications and data on their platform, including a key management system running in the cloud. Personally I think the risk is minimal, but if you have that concern see the previous alternatives.

In summary, it would be prudent to avoid the use of cloud service provider key management services such as AWS KMS, Azure Key Vault, and Google Customer-Managed Encryption Keys (CMEK). These services will put you at odds with the PCI cloud security recommendations, and likely put you in variance with future regulations. Not a good place to be.

My advice? Get encryption key management right from the beginning. If you are using a cloud provider’s KMS, start your migration now. You have readily-available choices that are affordable. Get started now!

Our Alliance Key Manager is validated to PCI-DSS and available in cloud, VMware, and HSM platforms. You can do this! Get started here.

Patrick

This week Amazon Web Services sent an email to our AWS customers informing them that Alliance Key Manager was no longer available in the AWS Marketplace. This email message was inaccurate and misleading. Townsend Security is committed to providing dedicated, compliant key management solutions to AWS customers, as well as to other cloud platform customers, and continues to make our solution available on the AWS Marketplace.

This is from the email message sent by Amazon:

We are writing to inform you that, as of 10 October 2018, Townsend Security will no longer offer "Alliance Key Manager for AWS" to new subscribers on AWS Marketplace.”

In fact, Townsend Security posted a new version of Alliance Key Manager on AWS this week, and withdrew the older version. The withdrawn version is Alliance Key Manager version 4.5. The new version is Alliance Key Manager version 4.6, which adds new support for VMware vSphere and vSAN encryption key management. You can find the current version of Alliance Key Manager in the AWS Marketplace here:

• Fee-based
• Bring Your Own License

Both versions of Alliance Key Manager remain under full software support and maintenance. You can upgrade to the new version if and when you wish to.

Please be aware that Amazon prevents us from knowing your customer details when you use the fee-based offering on AWS. Unless you register with us we won't be able to inform you if we have important updates and security patches. If you are an Alliance Key Manager customer on AWS, please register with us here.

Our goal is to provide you with the best key management and encryption solutions on the AWS platform. You always have exclusive control of your encryption keys and – neither Amazon nor Townsend Security can manage or access your keys.

If you have any questions please contact us here.

Townsend Security

VMware allows customers to use native vSphere and vSAN encryption to protect VMware images and digital assets.  But as we know, to truly protect private data, encryption keys must also be properly stored and managed. I recently sat down with Patrick Townsend, Founder and CEO of Townsend Security, to talk about vSphere and vSAN encryption, deploying multiple, redundant key servers as a part of the KMS Cluster configuration for maximum resilience and high availability, as well as meeting compliance regulations and security best practices for your organization.  Additionally, we talked about Alliance Key Manager for VMware and how it is helping businesses protect their sensitive data.

VMware virtualization has been a game-changing technology for IT, providing efficiencies and capabilities that have previously been impossible for organizations constrained within a traditional IT data center world.

It is really great to see VMware, as a company, stepping up to embrace encryption for vSphere and vSAN.  Introduced in vSphere 6.5 and vSAN version 6.6, encryption allows users to protect data at rest. Additionally, there is a really great key management interface, which provides an excellent path to store and manage keys.  While these versions have been out for a while, many customers are just now getting around to upgrading and can take advantage of VMware's native encryption. With VMware, organizations are able to reduce hardware costs, lower operational cost, and provides a clear a path to move to the cloud. With the addition of encryption, you can deploy secure environments where there is less risk of data loss in the event of a breach.

Let’s dive in a little more and talk about vSphere and vSAN encryption.  Can you walk me through how an organization might deploy encryption and key management?

Sure. I think in a typical VMware environment, organizations are already doing some encryption in their applications.  For example, they may be running Microsoft SQL Server in a VM and using Transparent Data Encryption (TDE) to protect the data.  With the new facilities, you now get the ability to encrypt right in the VMware infrastructure itself. There is one thing that I think VMware did really well, and they have proven this over and over again, is that they have laid out a certification process for key management vendors, which gives VMware customers confidence that they are purchasing and deploying a solution that has been vetted by VMware themselves.  Our Alliance Key Manager, for example, has been certified for:

• vSphere encryption
• vSAN encryption

In terms of deploying key management, it is easy. We recommend using both a production key server and a failover key server. vSphere supports KMS cluster configurations which allow you to have a resilient encryption and key management architecture.  Aside from just being a security best practice, we are seeing our customers deploy two servers because they never want to lose access to their encrypted data. The servers synchronize in real-time and have automatic failover capabilities.

You can’t talk about key management without talking about compliance.  Whether it is PCI DSS, GDPR, or state and federal privacy laws, who doesn’t fall under compliance these days?

Yes, good question.  That is probably a very short list these days.  When you look at all the existing compliance regulations around the world, including the new GDPR, you realize that everyone falls under some compliance regulation, and most of us fall under multiple regulations.  Enterprises, big and small, public and private, fall under the same compliance regulations. Additionally, I have heard more from privately held companies that they think they are exempt - which is not true.

So you are correct.  Compliance regulations are driving a lot of uptake in encryption and I would say that lately GDPR is driving the most interest.  If you look at Article 32 and related recitals, the requirement to protect a data subjects information, there is a clear call for encryption. GDPR has put a new focus on the need to protect private data, as well as to take a broad view at what should be considered sensitive data.  It is not just a credit card number or social security number. Information like a phone number or email address can be considered sensitive data.

How is your Alliance Key Manager helping VMware users protect their private data?

Well, we have been helping VMware customers for a number of years  who are encrypting at the application level. Our Alliance Key Manager for VMware runs as a virtual software appliance and is binarily the same as our hardware security module (HSM). What is new, is that VMware opened the vSphere and vSAN and products to support encryption key management. Now VMware users can leverage the same key management solution for both application and VMware infrastructure encryption.

People often ask us, “How is your key manager different than your competitors”?  One thing that makes us stand out is that we are very diligent about meeting compliance requirements (PCI DSS, GDPR, HIPAA, etc.) and industry standards (FIPS 140-2, KMIP, etc.). Years ago, when we partnered with VMware, one of the first things we did was work with VMware and a QSA auditor to achieve a PCI compliance statement.  Customers can now be assured that when they deploy our Alliance Key Manager in VMware that they are meeting PCI compliance.

What else do VMware customers need to know about Alliance Key Manager for VMware?

Alliance Key Manager is a mature product that has been on the market for more than 10 years. It uses the same software that runs inside our Hardware Security Module (HSM), so customers can be confident that they are running exactly the same key management software that is FIPS 140-2 compliant and in use by over 3,000 customers worldwide.  Additionally, the security posture that the key manager allows, as well as the reference architecture that VMware provides, really gives VMware customers a road map to doing a secure installation.

The other thing that I think a lot of people might not realize is, that when they deploy Alliance Key Manager, they have our entire library of client side applications, SDKs, and sample code available to them.  For example, we have a Microsoft SQL Server TDE encryption component, support for MongoDB via KMIP, and sample SDKs for languages like Java, PHP, Python, etc. All of that comes along with the key manager and makes it easy to address security requirements.

Finally, I’d like to mention our partnership with VMware.  We are diligent about maintaining our certifications with Alliance Key Manager.  Doing this brings a level of confidence to the product for our customers. Prior to starting an encryption project they may be a little leery of key management because they have heard that it may be complicated.  That was true in the past. In fact, today it is actually extremely simple to deploy. Another barrier that we have knocked down is the scalability issue. Our solution works across multiple platforms - AWS, Azure, VMware or as an HSM.  They all talk to each other, and if one goes down, another will automatically fail over. That gives VMware customers the ability to be extremely flexible about how they deploy key management. It is not uncommon that our customers will deploy an application in the cloud, deploy a key manager in AWS, and then mirror those keys back to their on-premise VMware infrastructure. All of this is really straightforward and simple to deploy.

To hear this conversation in its entirety, download our podcast Protecting Data with vSphere & vSAN Encryption and hear Patrick Townsend further discuss protecting data in vSphere and vSAN with encryption and key management.

VMware users can now protect VM Images and vSAN with Alliance Key Manager, Townsend Security’s FIPS 140-2 compliant encryption key manager.

Townsend Security is excited to announce that its new version of Alliance Key Manager fully supports VMware vSphere encryption for both VMware virtual machines (VMs) and for VMware Virtual Disk (vDisk). VMware users have been using Alliance Key Manager to protect data in application databases and applications to meet PCI DSS, GDPR, HIPAA compliance as well as other data privacy regulations. Now VMware users can use the same Alliance Key Manager solution with vSphere to protect virtual machines and virtual disks. Townsend Security is a VMware Technology Alliance Partner (TAP) and Alliance Key Manager for VMware has achieved VMware Ready status.  

“Our customers have been using Alliance Key Manager to protect data in Microsoft SQL Server, MongoDB and other environments for many years. Now VMware users can have confidence that Alliance Key Manager can also protect VMware virtual machines and virtual disk to achieve the highest level of data-at-rest protection,” said Patrick Townsend, CEO of Townsend Security. “VMware users are looking for certified solutions that support their complex Windows and Linux environments without the need to deploy additional hardware-based HSMs. We are happy to announce this extension of our key management solution to help VMware vSphere users achieve a high level of data protection.”

VMware users are looking for affordable solutions that provably meet compliance regulations and which fit their budget and deployment goals. Alliance Key Manager meets this goal by providing NIST FIPS 140-2 compliance, PCI-DSS certification, and Key Management Interoperability Protocol (KMIP) compliance out of the box. Existing Alliance Key Manager customers can upgrade at no cost to extend their data protection compliance requirements to vSphere. New customers can deploy Alliance Key Manager without the fear of increased, unplanned licensing costs in the future.

In addition to PCI DSS, compliance regulations such as the European Union General Data Protection Regulation (GDPR), the HIPAA data security regulation, and many other data protection regulations, require the encryption of data at rest. Alliance Key Manager combined with vSphere encryption are the protection methods  to help you meet these regulatory requirements. “Don’t be fooled by vague language in the GDPR regulation. You must act to protect sensitive information of individuals in order to meet this regulatory requirement. You should act now to protect your organization,” said Townsend.

Alliance Key Manager for VMware is available for a free 30-day evaluation.

Take a little imaginary trip with me.

You want to buy a new car and you are dreaming of all of the great places you can go and hikes you can take. You’ve done your research, you’ve identified a favorite model, you know the mileage and quality ratings, and you’ve made up you mind! That dream car is going to be yours.

You spend the obligatory two hours at the dealer and drive away with your dream vehicle. You drive it home and park it in the driveway.

Time to head out to your first destination! You pile your hiking gear into the car and head for the Appalachians for your first hike.

Suddenly, your car stops dead in the road and says “Sorry, you need to pay for this destination. It is not a part of your original car purchase plan. That will be an extra $5,000 please. Credit cards accepted!”

WTF?

You didn’t read the fine print. This car purchase plan only includes 5 destinations and the Appalachians aren’t in the plan. Each new destination is going to cost you a bundle.

Welcome to Key Management System licensing.

Most Enterprise Key Management Systems (KMS) work with this licensing model. You will usually find that you need to license each end-point that connects to the key manager. One end-point may be included in the KMS pricing, but you need to purchase additional “license packs” to attach additional systems. Or, you find that your KMS only supports a limited number of encryption keys. As soon as you roll your keys to meet compliance requirements, it is suddenly time to purchase capacity for more keys! Or, for that new encryption project, you may find that you need to purchase new software to enable encryption for that environment.

And it can get really bad when you discover that the KMS system comes in different hardware models and you suddenly need to purchase an entirely different hardware model and do full replacements. That’s painful.

This typical KMS licensing model works really well for the companies that sell them. For companies who need to deploy encryption?

Not so much …

It means going to management for new budget approval every time you want to extend your security through better encryption. Over time this can add up to hundreds of thousands or even millions of dollars in new license and maintenance fees.

There has to be a better way, right?

There is. Here at Townsend Security we do things differently with our Alliance Key Manager licensing. You purchase the KMS 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 that needs a KMS.
• 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 on the KMS.
• We never force you to pay extra fees for software patches.
• We never force you to pay extra fees for routine software upgrades.
• If you have a hardware HSM, we do not force you to re-purchase the KMS at end of life. Just replace the hardware and keep on keepin’ on!

Fortunately, the story about purchasing a car was completely made up. But the nightmare of KMS licensing is real. Just know that it doesn’t have to be that way. Take a look at our KMS offerings and see a new path forward.

Pinch yourself. And get ready for that dream trip.

We provide Alliance Key Manager as a hardware security module (HSM), as a VMware software appliance, and as a cloud instance (Azure, AWS) - All running the same key management software with the same interfaces and applications.

Patrick