+1.800.357.1019

+1.800.357.1019

Feel free to call us toll free at +1.800.357.1019.

If you are in the area you can reach us at +1.360.359.4400.

Standard support
6:30am - 4:00pm PST, Monday - Friday, Free

Premium support
If you own Townsend Security 24x7 support and
have a production down issue outside normal
business hours, please call +1.800.349.0711
and the on-call person will be notified.

International customers, please dial +1.757.278.1926.

Townsend Security Data Privacy Blog

Patrick Townsend

Recent Posts

Scaling Encryption Key Management with MongoDB

Posted by Patrick Townsend on Dec 13, 2018 8:45:20 AM

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. 

Primary and secondary key manager

 

From the mongod.conf configuration file:

mongod.conf

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.

Primary and multiple secondary replication sets

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. 

Complex, geographically distributed nodes

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

Topics: MongoDB Encryption Key Management, MongoDB, MongoDB Encryption

PCI Cloud Computing Guidelines Bombshell - Where to Now?

Posted by Patrick Townsend on Dec 4, 2018 9:31:26 AM

PCI LogoIn 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.

Encryption Key Management Industry Perspectives and Trends eBookThere 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

New Call-to-action

Topics: PCI DSS, PCI Encryption, Encryption Key Management

Key Management System (KMS) Licensing - There Has to Be a Better Way

Posted by Patrick Townsend on Aug 20, 2018 10:27:50 AM

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.

eBook: Definitive Guide to Encryption Key ManagementYou 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

eBook: Definitive Guide to Encryption Key Management

Topics: Alliance Key Manager

Google Encryption Key Management

Posted by Patrick Townsend on Aug 6, 2018 8:21:37 AM

Like most cloud service providers, Google provides options for customers to encrypt data in the Google Cloud Platform (GCP) for Google application and storage services.  Of course, core to any encryption strategy is how the encryption keys are managed. Properly managing encryption keys is central to overall encryption security. In this blog let’s look at your options for managing encryption keys in GCE and the implications for security, key custody (ownership), and business flexibility. We will also look at some alternatives to Google-provided encryption and key management.

Google has three models for encryption key management:

  • Google managed encryption and encryption keys (you have no access to the keys)
  • Customer-Managed Encryption Keys, or CMEK (you and Google share key management and access)
  • Customer-Supplied Encryption Keys, or CSEK (you supply the key, Google does not store or manage)

It is important to understand key management in each of these areas.

Google Managed Encryption and Encryption Keys

Google automatically encrypts your data in storage for you. This is the default implementation of storage encryption. With this option Google creates and manages the encryption keys and you do not have access to the encryption keys nor to any key management functions. This basic level of encryption support ensures that your data is encrypted at rest, encrypted in Google-managed backups, and encrypted as it is replicated through the Google cloud infrastructure.

It is important to note that Google has full access to the encryption keys that protect your data and will not provide them to you. However, Google may provide these encryption keys and protected data to law enforcement or intelligence agencies as dictated by law in your country, and it may not notify you if encryption keys are disclosed under these circumstances.

Customer-Managed Encryption Keys (CMEK)

With the CMEK approach you and Google share in the administration and management of encryption keys. You have the ability to manage the creation and use of the encryption keys for protecting data in storage, and you have the ability to revoke or delete an encryption key. You do not have the ability to export an encryption key, so Google maintains exclusive custody of your encryption keys.

It is important to note that Google has full access to the encryption keys that protect your data and will not provide them to you. Google may provide these encryption keys and your protected data to law enforcement or intelligence agencies as dictated by law in your country, and it may not notify you if encryption keys are disclosed under these circumstances.

Customer-Supplied Encryption Keys (CSEK)

With the CSEK approach you provide the encryption keys to Google and Google does not create, store or manage the keys. You must generate the keys and manage them yourself outside of the Google Cloud Platform. This is normally accomplished using an Enterprise Key Management System. When you create a new virtual image you will have the option of specifying the encryption key in raw, Base64 encoded format, or you can specify the key using RSA key wrapping. Google does not store this encryption key. This means that you must supply the encryption key each time you start the GCP service. To some extent this can be automated using command line tools.

With CSEK Google does not store or manage your encryption keys in any way. Google cannot provide the key to law enforcement or intelligence agencies as it has no possession of the key.

Google Key Management Summary

In many ways the Google Cloud Key Management Service (Cloud KMS) is primitive compared to other cloud service provide key management services, and especially when compared to Enterprise Key Manager Systems which provide dedicated, non-shared, control over the entire encryption key lifecycle.  The cloud services that are protected by Google Cloud KMS are also limited to the storage of data. Additionally Google Cloud KMS does not support open standards for key management such as the OASIS Key Management Interoperability Protocol (KMIP). If data protection, encryption key custody, and exclusive access to encryption keys are important to you, you may wish to explore other cloud service providers and independent key management vendors (Townsend Security can help).

Encryption and Key Management with MongoDB in Google Cloud Platform

One notable exception to the limitations of Google Cloud Key Management is the implementation of MongoDB Enterprise Advanced on the Google Cloud Platform. MongoDB Enterprise Advanced supports the KMIP interface to key management, so you have many choices for the deployment of encryption key management outside of GCP. These choices include the ability to deploy key management:

  • As hardware security module (HSM) in your own data center.
  • As a hardware security module in a hosted data center.
  • As a VMware virtual machine in your own data center or a hosting provider that supports VMware and vCloud.
  • As a dedicated cloud instance in another cloud platform.

At the present time in July of 2018, MongoDB Atlas does not support the KMIP interface, so Atlas users will not have the ability to use their own dedicated key management system.

Resources:

Google Customer Managed Encryption Keys (CMEK):

https://cloud.google.com/storage/docs/encryption/customer-managed-keys


Google Customer Supplied Encryption Keys (CSEK):

https://cloud.google.com/storage/docs/encryption/customer-supplied-keys

Topics: Encryption Key Management, Google Cloud Platform (GCP)

Encryption Key Management System vs Service: KMS Differences Explained

Posted by Patrick Townsend on Jul 23, 2018 2:41:19 PM

A rose is a rose is a rose - let's talk KMS.

eBook: Definitive Guide to Encryption Key ManagementIn IT technology and security, the language and three-letter acronyms we use can sometimes make things more confusing than they need to be. That’s true with encryption key management systems and services that are available today. So let’s sort out the language, TLAs, and try to reduce some of the confusion in this area.

HINT: In the following discussion, pay special attention to the words “system” and “service”. I’ve added emphasis below to help with clarity.

Enterprise Key Management System

An Enterprise Key Management System is a security appliance (hardware or software) that manages encryption keys through their entire lifecycle - key creation, key activation, key use, key expiration or retirement, key escrow, and key destruction. The “Enterprise” part of this descriptive phrase is often dropped, and these types of system are often referred to as Key Management Systems. The word “Enterprise” is often used to indicate that the key management system can be used for a wide variety of purposes within an organization.

Key Management Systems may be hardware devices (usually hardware security modules, or HSMs), software appliances (think VMware virtual machines), or cloud instances. Their use is dedicated to a single organization and usually managed by security professionals within that organization providing the organization exclusive custody of the encryption keys. Key Management Systems are usually validated to the FIPS 140-2 standard by the National Institute of Standards and Technology (NIST).

Category: “Key Management System”; or “Enterprise Key Management System”

Three-Letter Acronym: Usually “KMS”; less frequently “EKMS”

Here at Townsend Security we provide our Alliance Key Manager as a Key Management System available as a Hardware Security Module (HSM), VMware virtual appliance, and as a dedicated cloud instance (Azure, AWS) and is FIPS 140-2 compliant.

Cloud Service Provider - Key Management Service

A cloud service provider’s Key Management Service is generally a multi-tenant, encryption key storage service managed by the cloud service provider that provides a subset of encryption key lifecycle management. Administrative duties for encryption keys are a shared responsibility of the cloud service provider and the organization that uses the keys. This means that the organization is sharing custody (ownership and access) to encryption keys.

Cloud-based Key Management Services are not FIPS 140-2 validated, but may be partially backed by Key Management Systems which are. Examples of cloud service provider key management services include Amazon Web Services Key Management Service (AWS KMS), Microsoft Azure’s Key Vault (Azure KV), and Google Cloud Platform’s Customer-Managed Encryption keys (GCP CMEK, also known as GCP Cloud KMS).

The cloud service provider’s use of the “KMS” acronym adds substantially to the confusion. Just remember that cloud service providers implement a multi-tenant, shared “service” and not a dedicated key management “system”.

Category: “Key Management Service”; or “Cloud Key Management Service”

Three-Letter Acronym: Usually “KMS”, “KV” or “CMEK”; less frequently “Cloud KMS”

Townsend Security is not a cloud service provider and does not provide multi-tenant, shared custody key management services.

ISV Solutions for the Cloud - Key Management Systems

Independent Software Vendors (ISVs) provide Key Management Systems that are not managed or accessed by the cloud service provider or the ISV, and which are dedicated to the user organization. This means that the cloud user is not sharing custody (ownership and access) to encryption keys and has full and exclusive management, ownership, and access to encryption keys. ISV cloud Key Management Systems provide support for the entire key management lifecycle including key creation (key establishment), key activation, key distribution, key backup and escrow, and key destruction.

ISV Key Management Systems are not FIPS 140-2 validated, but may be based on software that is FIPS 140-2 compliant.  

An ISV’s use of the “KMS” acronym more closely reflects the Enterprise Key Management System described above. These are key management systems that are dedicated to a single organization and which support the entire lifecycle of key creation, key distribution, and key escrow.

Category: “Key Management System”; or “Cloud Key Management System”

Three-Letter Acronym: Usually “KMS” or “Cloud KMS”

Townsend Security provides its Alliance Key Manager solution as a dedicated, single tenant, Key Management System on the Amazon Web Services and Microsoft Azure cloud platforms. The solution can be located in the relevant Marketplace.

Cloud Service Provider - Bring Your Own Key

One small variation on the theme of cloud service provider Key Management Services involves the ability to import your own encryption key to the cloud service. In this case the cloud service is not creating the encryption key for you, but is allowing you to bring an encryption key that you have created, or which you manage outside of the cloud, to the cloud’s key management service. In this case the key you bring is imported into the multi-tenant, shared key management service and is then available through the cloud service provider key management service interface. Although you have exclusive control over the creation of the key and may store it outside of the cloud, it is important to remember that the storage and management of the imported encryption key is a shared responsibility between you and the cloud service provider. You do NOT have exclusive control of the key after it is imported to the cloud.

Category: “Key Management Service”; or “Cloud Key Management Service”; often “Bring Your Own Key” or “Customer-Supplied Encryption Key”

Three-Letter Acronym: “BYOK” or “CSEK” (Google Cloud Platform)

Townsend Security fully supports bringing your own key to its Alliance Key Manager Key Management System for the Azure and AWS cloud platforms. Key custody remains fully with the organization and is not shared with the cloud service provider nor with Townsend Security.

In summary: A rose is a rose is a rose.

However, a Key Management Service is NOT a Key Management System.

When discussing encryption key management care must be taken to understand the meaning of KMS. It can be quite different depending on the context. I hope this blog helps clarify the language and issues around key management.

Patrick

(with apologies to Gertrude Stein)

eBook: Definitive Guide to Encryption Key Management

Topics: Encryption Key Management

MongoDB Encryption Key Rotation

Posted by Patrick Townsend on Jul 9, 2018 11:11:00 AM

Every now and then you get something wrong and have to eat crow. Well, it’s my turn. Caw!

Encryption & Key Management for MongoDB eBookAt the MongoDB World 2018 conference I gave the security session on encryption key management for MongoDB. I love doing this session because MongoDB really makes getting encryption key management right by exposing a Key Management Interoperability Protocol (KMIP) interface available to plug in a key manager. I talked about the MongoDB interface, about the principles of good encryption and key management, and then demonstrated how easy it is to deploy our Alliance Key Manager with MongoDB. It takes just a few minutes for a complete implementation.

There were really good questions at the end of the session. One of those questions was:

“How do you rotate the encryption keys for MongoDB?” 

Key rotation is, of course, required under the PCI Data Security Standard (PCI DSS) and is a good security practice. The National Institute of Standards and Technology (NIST) addresses this in their Key Management Best Practices document Special Publication 800-57. See the section on crypto-periods for data encryption keys.

This is where I ran off the rails. It was my impression that you had to create a new MongoDB database, encrypt it with a new key, and then copy the data into the new database. And that was not right! That is the procedure for some databases, but not MongoDB.

Luckily Davi Ottenheimer, MongoDB’s head of security, and a MongoDB engineer were right there to set me straight.

Fortunately you do NOT have to create a new MongoDB database in order to roll the data encryption key. It is actually much simpler. Here are the steps you use to roll the data encryption key (extracted from the MongoDB documentation for KMIP key management):

1) Rotate the master key for the secondary members of the replica set one at a time.

a. Restart the secondary, including the --kmipRotateMasterKey option. Include any other options specific to your configuration, such as --bind_ip. If the member already includes the --kmipKeyIdentifier option, either update the --kmipKeyIdentifier option with the new key to use or omit to request a new key from the KMIP server:

mongod --enableEncryption --kmipRotateMasterKey \

--kmipServerName <KMIP Server HostName> \

--kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem

If using a configuration file, include the security.kmip.rotateMasterKey.

b. Upon successful completion of the master key rotation and re-encryption of the database keystore, the mongod will exit.

c. Restart the secondary without the --kmipRotateMasterKey parameter. Include any other options specific to your configuration, such as --bind_ip.

mongod --enableEncryption --kmipServerName \

<KMIP Server HostName> \

--kmipServerCAFile ca.pem \

--kmipClientCertificateFileclient.pem

 If using a configuration file, remove the security.kmip.rotateMasterKey.

2) Step down the replica set primary.

Connect a mongo shell to the primary and use rs.stepDown() to step down the primary and force an election of a new primary:

 rs.stepDown()

When rs.status() shows that the primary has stepped down and another member has assumed PRIMARY state, rotate the master key for the stepped down member:

a. Restart the stepped-down member, including the --kmipRotateMasterKey option. Include any other options specific to your configuration, such as --bind_ip. If the member already includes the --kmipKeyIdentifier option, either update the --kmipKeyIdentifier option with the new key to use or omit.

mongod --enableEncryption --kmipRotateMasterKey \

--kmipServerName <KMIP Server HostName> \

--kmipServerCAFile ca.pem \

--kmipClientCertificateFileclient.pem 

If using a configuration file, include the security.kmip.rotateMasterKey.

b. Upon successful completion of the master key rotation and re-encryption of the database keystore, the mongod will exit.

c. Restart the stepped-down member without the --kmipRotateMasterKey option. Include any other options specific to your configuration, such as --bind_ip.

mongod --enableEncryption --kmipServerName \

<KMIP Server HostName> \

--kmipServerCAFile ca.pem \

--kmipClientCertificateFileclient.pem

If using a configuration file, remove the security.kmip.rotateMasterKey setting.

This is pretty easy. You can find the documentation online at the MongoDB documentation site.

If you attended my class in New York, or if you are implementing encryption and key management for MongoDB, I hope you find this helpful. As soon as the recording of the class is available I’ll send it to you in a new blog.

Thanks to all of the MongoDB team members who put on the MongoDB World in New York! It was an exciting two days and I always learn a lot at the conferences.

Patrick

Encryption & Key Management for MongoDB eBook

Topics: MongoDB, MongoDB Encryption Key Management

Customer Information: IBM i Security Products Acquired by Syncsort

Posted by Patrick Townsend on May 21, 2018 1:11:00 PM

We are pleased to announce that Syncsort has acquired Townsend Security's IBM i security offerings. Solutions in the sale include Townsend Security's encryption, tokenization, authentication, FTP, as well as SIEM integration products. Syncsort is the global leader in Big Iron to Big Data software. The acquisition helps Syncsort deliver on its ongoing commitment to strengthening the security of the IBM i platform and to businesses that rely on its performance and resilience to drive the business forward.  

Townsend Security will continue in business focusing on Alliance Key Manager, our FIPS 140-2 compliant encryption key management solution that is in use by over 3,000 customers worldwide. Alliance Key Manager provides encryption key management and encryption services to a wide set of relational database solutions, big data solutions, and blockchain platforms. We are pleased that we will have an on-going partnership with Syncsort around providing the Townsend Security Alliance Key Manager solution to Syncsort customers.

During the transition, Townsend Security will work closely with Syncsort to make sure that your IBM i product needs are met. As part of the acquisition, we will be sharing your account information with Syncsort and anticipate a full handover within 6 months.

To learn more about Syncsort’s IBM i products and content offers, you can sign up here to be added to their mailing list.

We thank you for your business and trust you will continue to experience the same high level of customer satisfaction and support with Syncsort.

Patrick Townsend
Founder/CEO
360.359.4400

Topics: Customer Information

SQL Server Always Encrypted vs Transparent Data Encryption (TDE)

Posted by Patrick Townsend on Apr 30, 2018 10:42:39 AM

Microsoft SQL Server customers ask us whether they should use Always Encrypted or Transparent Data Encryption (TDE) to protect sensitive data. It is a relevant question, especially given the concern for the GDPR, and it is relevant to many other compliance regulations and data protection needs. Let’s explore these technologies in more detail and I think the answer will emerge.

Always Encrypted

Encryption & Key Management for SQL Server - Definitive GuideAlways Encrypted is a relatively new, client-side implementation of encryption for SQL Server. That is, data is encrypted on the source system before you insert it into a SQL Server database. Implemented as a Windows driver, Always Encrypted intercepts your SQL statement before it leaves your client-side system (PC, web server, etc.), determines if there are any fields in the SQL statement that need to be encrypted, establishes or retrieves an encryption key, encrypts the field, and sends the modified SQL statement to SQL Server for processing.

One advantage of this approach is that the data is encrypted as it travels over the internal or external network, and as it resides in the database. A retrieval of the encrypted data reverses this process ensuring that the data is protected in transit.

One significant limitation of Always Encrypted is that it can only be applied to a small subset of SQL operations. Many SQL operations are complex and cannot be processed by Always Encrypted.

Transparent Data Encryption and Cell Level Encryption

SQL Server Transparent Data Encryption (TDE) and Cell Level Encryption (CLE) are server-side facilities that encrypt the entire SQL Server database at rest, or selected columns. The client-side application is completely unaware of the implementation of TDE or CLE and no software is installed on the client-side system. All of the encryption tasks are performed by the SQL Server database itself. It is easy to implement and performs very well for most SQL Server customers.

TDE and CLE are a part of the Microsoft SQL Server Extensible Key Management (EKM) strategy which has been a part of SQL Server since the 2008 edition. It is a mature technology and many organizations deploy TDE or CLE to protect their sensitive information.

Encryption Key Management

An encryption strategy is only as good as the encryption key management strategy. Creating, protecting, and using encryption keys is the hardest part of encryption, and for the sake of your overall security, it is important to get key management right.

With Transparent Data Encryption the key management strategy is well defined through the Microsoft Extensible Key Management (EKM) Provider interface. Key management systems such as our Alliance Key Manager for SQL Server provide software written to the EKM interface specification and SQL Server customers get full encryption key management integrated through the EKM Provider interface.

Always Encrypted does not provide a formal interface for key management. Instead, third party vendors must provide Always Encrypted drivers that implement an interface to a key management system. This means that the interface to the key management system is proprietary. Additionally, since the Always Encrypted implementation is a client-side deployment, each client-side application will have to have access to the key manager in order to properly protect and use encryption keys. This can be a challenge in distributed network topologies.

The bottom line: you can achieve proper key management with either approach, but expect to deal with more complexity with Always Encrypted when you have distributed clients.

When to Use Always Encrypted

Because Always Encrypted functions by modifying the SQL operation before it interfaces with the SQL Server database, and because many complex SQL operations will not work with Always Encrypted, I would only recommend using Always Encrypted when the application architecture is very simple. For example, you might want to use Always Encrypted to send data from an internal SQL Server database to a web-hosted SQL Server database and application. The data will be protected in transit and encrypted in the database. As long as your web application makes simple SQL queries to the database this approach can work well.

When to use TDE or CLE

Transparent Data Encryption and Cell Level Encryption are implemented directly in the SQL Server database itself. This means that complex SQL operations are fully supported and you will not find limitations imposed by your encryption or application strategy in the future. The SQL Server implementation of TDE and CLE also support a standardized interface for encryption key management. This means you will have choices in key management vendors and can readily find a solution.  TDE also has good performance metrics for the large majority of SQL Server customers, and is exceptionally easy to implement.

Summary

For the reasons outlined above I believe that Transparent Data Encryption or Cell Level Encryption implemented within SQL Server will almost always be the better choice for most SQL Server customers. You will not be locked into restrictions on the use of SQL operations, key management is well defined, and the encryption performance metrics are impressive.

I hope this overview of the two SQL Server encryption approaches has been helpful. Please feel free to reach out with any questions you have.

Patrick

Encryption

Topics: SQL Server, Transparent Data Encryption (TDE)

GDPR - Do I have to Use Encryption?

Posted by Patrick Townsend on Apr 24, 2018 8:44:17 AM

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

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

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

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

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

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

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

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

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

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

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

But there is more.

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

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

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

Where else does encryption come into play?

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

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

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

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

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

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

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

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

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

Patrick



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

EU Data Privacy Protections and Encryption

Topics: EU GDPR, Enryption

Migrating from Oracle to MongoDB with Data Security

Posted by Patrick Townsend on Mar 20, 2018 2:38:51 PM

With big cost savings in mind, many Oracle Database customers are migrating selected applications to MongoDB. Let’s take a look at some of the factors that are driving this migration, and how MongoDB helps protect and secure data after the migration.

First, how do customers protect data that is stored in an Oracle Database?

Encryption & Key Management for MongoDB eBookOracle Database supports Transparent Data Encryption (TDE) through a special interface implemented in Oracle Advanced Security. Once you’ve made the costly upgrade to Oracle Advanced Security, you can configure and activate encryption of the Oracle Database through the Advanced Security Wallet application. The encryption support can be either whole database encryption through Transparent Data Encryption or column level encryption. If you are using the Oracle Key Manager (OKM) solution, or a third-party key manager, the interface in Oracle Wallet is usually through a PKCS#11 interface library. This is simply a software library that uses the key manager to protect the local key used for database encryption.

The increase in cost to deploy Oracle Advanced Security can be substantial. It varies depending on your licensing agreement with Oracle or one of their distributors, but it affects the cost basis for each database user.

Faced with the increased cost of deploying Oracle Advanced Security, or wishing to achieve cost savings with existing Oracle Database implementations, Oracle customers are moving to MongoDB Enterprise which has a different security strategy.

So,  how do MongoDB customers protect data in an equivalent fashion?

MongoDB Enterprise edition also supports Transparent Data Encryption of the database. But this is a native part of the Enterprise edition of MongoDB and does not involve additional license costs. Additionally, MongoDB Enterprise overall pricing is substantially lower that Oracle Database [Organizations are saving 70%+ by switching from Oracle to MongoDB]. Without the need for increased costs to get the encryption option, MongoDB customers are able to achieve Transparent Data Encryption in an affordable way.

Additionally, encryption key management is based on the industry standard Key Management Interoperability Protocol (KMIP) as defined by the OASIS standards group. Most enterprise key management systems, including our Alliance Key Manager for MongoDB solution, support KMIP. This means that customers can easily deploy Transparent Data Encryption with an affordable key management solution that plugs into MongoDB through the KMIP interface. This will make security-conscious Oracle Database customers happy in achieving an equivalent level of security after the migration.

MongoDB has been doing a lot lately to woo Oracle Database customers to its platform. While MongoDB is a NoSQL big data database, it supports SQL-like interfaces to the database. This means that migrations from Oracle to MongoDB are pretty straight-forward [A Step-by-Step Guide on How to Migrate from RDBMS to MongoDB].

MongoDB also just announced a key feature that will make Oracle Database customers happy. That announcement is that MongoDB version 4 will fully support Atomicity, Consistency, Isolation and Durability (ACID) as a core feature of MongoDB. This is database geek-speak that means that MongoDB database applications will work with the same reliability as big commercial SQL databases - something that Oracle Database customers expect. I think this will help accelerate the migration from Oracle Database to MongoDB Enterprise database.

Oracle Database customers typically run a wide range of packaged and custom-built applications. I believe that early migrations from Oracle to MongoDB mostly involve those custom-built applications that are relatively simple in their architecture. Migrating from an Oracle ERP or CRM application might involve a great deal of planning and re-engineering. But I think almost every Oracle customer has some custom-built applications that are easy targets for a migration to MongoDB.

The cost savings combined with the ease of migration, the equivalent level of database encryption and key management security, and the new support for ACID database reliability in MongoDB version 4 is a winning combination for MongoDB as a company. I suspect that migrations from Oracle to MongoDB will pick up dramatically this year as MongoDB version 4 roles out.

Here at Townsend Security we’ve done a lot to align with the MongoDB Enterprise strategy. We’ve formally certified our Alliance Key Manager solution with the MongoDB security team, we support both Intel and Power platforms for our key management interface, we deploy in cloud, VMware and on-premise environments, and we’ve aligned our pricing and licensing strategy with the MongoDB strategy. Entry level MongoDB customers can deploy compliant (PCI DSS, FIPS 140-2) key management in an affordable manner, and key management licensing follows the MongoDB model. Even very large MongoDB Enterprise customers will be happy with our key management licensing, scalability, and pricing strategy.

I am impressed with MongoDB’s goal of bringing enterprise level database technology to a wide variety of small, medium, and large Enterprise customers. It’s just the right time for a new, disruptive approach to databases.

If you'd like to learn more about how we are helping secure MongoDB Enterprise with encryption and key management, visit our Alliance Key Manager solution for MongoDB page.

Patrick

Encryption & Key Management for MongoDB eBook

Topics: MongoDB

Definitive Guide to VMware Encryption & Key Management
 

 

Subscribe to Email Updates

Recent Posts

Posts by Topic

see all