Townsend Security Data Privacy Blog

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 eBook 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

New Call-to-action

Topics: PCI Encryption, PCI DSS, Encryption Key Management

PCI Encryption - Three Things to Know & Three Things to Protect

Posted by Michelle Larson on Jun 28, 2013 1:47:00 PM

What Standards for PCI Encryption You Need To Know and Why They Matter

Payment Card Industry - Data Security Standards (PCI-DSS) require you to encrypt credit card account numbers stored in your database and ensure data stays secure when transferred outside your company. Download Whitepaper on PCI Data Security

In order to understand these PCI encryption requirements, we first should know the source of industry best practices for encryption key management. Here in the US, the National Institute for Standards and Technology (NIST) is the most common source for guidance on best practices. The NIST special publication SP-800-57 provides specific pointers on how best practices for both procedurally managing encryption keys, and what to look for in key management systems. In these documents you will find the genesis of most standards regarding encryption key management, including the following concepts in PCI DSS 2.0 Section 3.  Next, it is important to understand the security best practices concepts of Dual Control, Separation of Duties, and Split Knowledge. I’ll simplify them here from the point of view of encryption key management:

  1. Dual Control means that no one person alone should be able to manage your encryption keys. Creating, distributing, and defining access controls should require at least two individuals working together to accomplish the task.
     
  2. Separation of Duties means that different people should control different aspects of your data protection strategy. This is the old adage “don’t put your eggs in one basket”. The person who creates and manages the keys should not have access to the data they protect. And, the person with access to protected data, should not be able to manage encryption keys.
     
  3. Split Knowledge applies to the manual generation of encryption keys, or at any point where encryption keys are available in the clear. More than one person should be required to constitute or re-constitute a key in this situation.

In order to meet standards for PCI encryption, you need to make sure you protect these three things properly:

  1. Protect your data at rest with AES Encryption
    Advanced Encryption Standard (AES) has been adopted as a format standard (FIPS -197) by the US government and many state and local agencies when it comes to encrypting data in a database. AES is the recommended encryption method for PCI-DSS, HIPAA/HITECH, GLBA/FFIEC and individual state privacy regulations. Encryption methods approved and certified by the National Institute of Standards and Technology (NIST) provide assurance that your data is secured to the highest standards.  
     
  2. Protect your data in motion with PGP Encryption
    PGP encryption is the standard when it comes to encrypting files that need to be transferred.  Pretty Good Privacy (PGP) is the standard for encrypted file exchange among the world’s largest retail, finance, medical, industrial, and services companies.  Also know that when encrypting a file with PGP, you may be using AES encryption.  Transmit sensitive files over the internet using trusted encryption technologies. (AES, SSH, SSL, and PGP). Encryption solutions work together to ensure that all your sensitive data is secure even after the transmission is complete.  AES will protect data at rest within your organization and PGP keeps it secure when it is sent outside your company.
     
  3. Protect your encryption keys and your data by keeping them apart!
    Leaving your encrypted data and keys in the same place is like leaving the key to your house under your welcome mat.  Security best practices require that you store encryption keys separately from your encrypted data and managed with an encryption key manager. It is also important to note that. In regards to the cloud, PCI SSC recently offered this guidance:
    In a public cloud environment, one Customer’s data is typically stored with data belonging to multiple other Customers. This makes a public cloud an attractive target for attackers, as the potential gain may be greater than that to be attained from attacking a number of organizations individually. Strong data-level encryption should be enforced on all sensitive or potentially sensitive data stored in a public cloud. 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.
The most important part of a data encryption strategy is the protection of the encryption keys you use. Encryption keys safeguard your encrypted data and represent the keys to the kingdom. If someone has access to your keys, they have access to your encrypted data.
 

Download the whitepaper Meet the Challenges of PCI Compliance and learn more about protecting sensitive data to meet PCI compliance requirements.

          DOWNLOAD WHITEPAPER

 

At Townsend Security, we ensure our customers data is secured to the highest level for compliance. Our AES encryption solutions are NIST validated and our encryption key management solutions are FIPS 140-2 certified.  Our HSM appliances integrate seamlessly with Windows, Linux, UNIX, IBM Power Systems and Microsoft SQL Server 2008/2012 (enterprise edition) and can also work with earlier/non-enterprise editions of SQL Server.

As always, if you have comments or questions about PCI encryption, please list them here

Topics: Encryption, Separation of Duties, PCI Encryption, Split Knowledge, PCI DSS, PCI, Dual Control