Last updated at Wed, 30 Aug 2017 00:13:46 GMT
Strong Cryptography is referred to by PCI DSS through the following requirements:
2.3 - Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or SSL/TLS for web- based management and other non- console administrative access.
4.1 - Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks.
Cryptographic solutions are also suggested as a potential solution for: 3.4 - Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs)
What is meant by strong cryptography?
Cryptography is the art of transforming information so that it can not be understood by unauthorized parties. Of course, this transformation is meant to be resistant to attacks so that you can have fair assurance that your secrets are safe... at least for a specific period of time. This is what is meant by "Strong Cryptography". It consists of three parts:
- The use of industry-tested and accepted algorithms (transforming machines), along with strong key lengths
- The presence of resistant protection mechanisms limiting access to the keys
- The use of proper key management processes and procedures.
Organizations subjected to DSS must prove compliance with these three points.
What is meant by proper key management and key protection?
This is covered by:
3.5 Protect any keys used to secure cardholder data against disclosure and misuse)
3.6 Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data.
This last one further includes:
3.6.1 Generation of strong cryptographic keys according to best practices.
3.6.2 Secure cryptographic key distribution
3.6.3 Secure cryptographic key storage. PCI doesn't specifically require the use of hardware secured module for this purpose. However their use would greatly facilitate validation from your auditor.
3.6.4 Periodic cryptographic key changes.
3.6.5 Retirement or replacement of keys as deemed necessary when the integrity of the key has been weakened or keys are suspected of being compromised
3.6.6 Split knowledge and establishment of dual control of cryptographic keys.
3.6.7 Prevention of unauthorized substitution of cryptographic keys.
3.6.8 Requirement for cryptographic key custodians to sign a form stating that they understand and accept their key-custodian responsibilities.
What is a crypto-framework?
A crypto-framework is a set of rules, principles and tools designed to support the management and protection of cryptographic keys within an organization. Its purpose is to improve the efficiency, quality, robustness, and traceability of the processes involved in the management and protection of crypto keys. It provides a structure and a frame, while it draws the limits of the crypto playground. Every crypto service used within the organization would benefit from this.
Why is it needed?
PCI DSS does not explicitly mention it; however reading between the lines there is no doubt that a framework would greatly facilitate compliance with the keys protection and keys management requirements above.
What should be part of a crypto-framework?
A crypto-framework should at least include the following components:
Procedures: Set of procedures defining the high level processes and detailed technical procedures for the management of the keys. These should answer to the following questions: What must be done, by who, when and How must it be done and eventually how to record execution of the tasks. As mentioned above processes and procedures should exists for the following crypto activities: Key Generation, distribution, usage, replacement, archiving, Destruction,Incident response for key compromised.
Roles and responsibilities for whomever is assigned to the cryptographic operations, including key custodians.
Standards: Key Classification, approved cryptographic keys, protocols, and methods; Standards associated with various technology in use (i.e SSL/TLS, IPSEC, Bit Locker, SSH,…)
Key inventory. Depending on the number of keys a simple spreadsheet, or a more complex key management tool would be needed for the maintenance of the inventory.
Key metadata = Attributes that identifies a particular key and specifies the appropriate usage and management of that key. Example of attributes are: Key identifier; Key location, Key owner responsible for the use and management of the key; Set of algorithms that can be used with the key; Key usage; Key length; Key custodians who have access to the key; Key validity period also called crypto period;
State machines: The list of states that a key could take through is life: Generated, Distributed, Used, Retired/Replaced, Revoked, Archived, Destroyed. As well as the condition of transition between each of these sates.
Network Diagram showing the location and classes of keys within the infrastructure.
Key management logs (who did what and when)
Trainings: Introduction to Cryptography, Key management training
What are the minimum documents you should have ready for your PCI audit?
If you don't opt for the crypto-framework approach, here are the minimum documents you should have ready for your audit:
- Inventory of keys used within the PCI environment. (You may be interested to use the specific key inventory sheet from the PCI Compliance Dashboard V10)
- Keys attributes with a minimum of the key length, algorithms, crypto period, status, key custodians, and location (Same remark as above)
- List of Key Custodians having access to the keys (Same remark as above)
- Key custodians responsibility acknowledgement forms
- Functional processes and technical procedures for the generation, distribution, secure storage, protection, replacement and compromised keys
Questions
What's your field experience with these requirements?
Did you read our previous newsletter: PCI 30 seconds newsletter #30 - Trainings your organization must deliver to comply with PCI DSS?
