PCI Compliance Standards (PCI DSS): What You Should Know and Why They Matter
The Payment Card Industry Data Security Standards (PCI DSS) requires organizations to encrypt credit card account numbers stored in their databases and ensure that data remains secure when transferred outside the company.
In order to understand these PCI compliance requirements, we first should know the source of industry best practices for encryption key management. In the U.S. the National Institute of Standards and Technology (NIST) is the most common source for guidance on best practices. The NIST special publication SP-800-57 provides specific best practices for managing encryption keys and what to look for in key management systems. In these documents you will find the beginnings of most standards regarding encryption key management, including the following concepts in PCI DSS 3.2 Section 3.
3 Items You Must Protect to Meet PCI Compliance
In order to meet encyrption standards for PCI DSS, 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 U.S. 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 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 maintains its security when the data sent outside your organization.
For more about AES and PGP encryption, see our related blog post: AES vs PGP Encryption: What is the Difference?
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.
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.
3 Best Practices in Encryption Key Management
It is important to understand the security best practices concepts of Dual Control, Separation of Duties, and Split Knowledge. Here are their definitions, with a focus on how they relate to encryption key management:
- 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.
- Separation of Duties means that different people should control different aspects of your data protection strategy. This is the old adage “don’t put all your eggs in one basket.” The person who creates and manages the keys should not have access to the data they protect. Similarly, the person with access to the protected data, should not be able to manage its encryption keys.
- 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.
To learn more about accelerating PCI DSS compliance, watch our webcast: Accelerating Regulatory Compliance for IBM i Systems