The latest version of the Payment Card Industry’s Data Security Standard (PCI DSS) does not go far enough on encryption, according to full-disk encryption software firm WinMagic.
“Version 3.0 is an improvement on previous versions because it includes more security intent rather than just prescriptive rules, which encourages a more holistic view,” said Garry McCracken, vice-president, technology, at WinMagic.
This is important, he said, because the intent of merchants should be to improve the security around customers’ payment data, not simply to achieve PCI compliance.
“Compliance does not necessarily mean data security, but a focus on security in terms of risk, confidentiality, integrity and availability is likely to cover a lot of compliance,” said McCracken.
A security-led approach is better than a compliance-led approach, he said, but while PCI DSS V3.0 takes a step in the right direction to support this, it does not go far enough.
While section 3.4.1 clarifies that merchants should not use the operating system authentication factors for giving access, for example, PCI DSS V3.0 is still light on details in other areas.
Section 3.4.1 states that if disk encryption is used, logical access must be managed separately and independently of native operating system authentication and access control mechanisms.
“In the past, merchants may have thought they could use a product that did the encryption but did not really provide a pre-boot authentication or any authentication until the machine had been unlocked, and then relied on the operating system for authentication,” said McCracken.
READ MORE ON PCI DSS
- Is meeting PCI DSS standards enough to protect customer data?
- Mainframe security best practices for compliance with PCI DSS
- Is PCI DSS compliance required?
- Choosing PCI DSS-compliant service providers
- Using metadata tagging tools for PCI DSS compliance
- Updating network diagrams for PCI DSS 3.0 compliance
- Is being PCI DSS-compliant enough to protect customer data?
- PCI DSS 3.0 compliance is mandatory in 2015. Are you ready?
- Is the PCI DSS a good guide for an application security program?
- Open source PCI DSS: A strategy for cheaper, easier PCI compliance
- How to meet PCI DSS requirement 6.6 and keep down costs
- PCI analysis: Marcus Ranum on why PCI DSS sets the bar too low
- Gartner on PCI DSS 3.0 changes: Bigger, harder and more expensive
- PCI DSS compliance still too low, says Verizon
- PCI 3.0 changes: A PCI compliance requirements checklist for 2015
- Target breach details: Was the retailer PCI DSS compliant?
This meant that a merchant which had encryption could achieve compliance, but if that encryption relied on the operating system for authentication, it was not really secure because encryption without proper authentication does not guarantee confidentiality,” he said.
Further PCI DSS improvements needed
Another improvement McCracken would like to see is more of a requirement for encryption to be implemented in accordance with international standards in general, and improvements in the area of encryption key management in particular.
“PCI DSS V3.0 is still a little light on things like where encryption keys are stored, who handles them and how they are protected. Our view is that the merchant should keep very tight control of their keys and their key management,” he said.
McCracken also believes it is important for data to be encrypted at source, or wherever is created, whether that is at the endpoint or in the cloud.
“This ensures that data is always encrypted, whether it is in transit or at rest, but at the same time the encryption keys must be held securely in the enterprise in a key manager and provided only on demand when necessary, which means it will be deleted from memory once the decryption process is complete, and access is more tightly controlled by policies that can be updated whenever necessary,” he said.
This means that if there is a breach, the impact can be reduced simply by updating a central policy in the key manager.
Overall, McCracken would like to see future versions of PCI DSS more aligned with basic principles in international standards, such as ISO27001 and the newly released ISO27040 on data storage security, and international assessment methods like the Common Criteria for IT security.
“In the next version of PCI DSS, there should be much more cross-referencing and building on these international standards,” he said.
This approach would mean that complying with basic international standards would take care of 95% of PCI DSS requirements and reduce the compliance load on merchants.
“Ultimately, a future PCI DSS could be a very thin document if it referenced the major and mature international standards on security and then had just a few sections on specific payment card data security requirements,” he said.
In line with global security standards
A spokesman for the Payment Card Industry Security Standards Council (PCI SSC), which administers the PCI DSS, told Computer Weekly the standard does cover encryption and key management.
“PCI addresses both key management and encryption, not only in the PCI DSS, but also with standards covering specific areas where key management and encryption controls are specifically used in the transaction process, such as point to point encryption, PIN security requirements, and PCI terminals security standards,” said Jeremy King, European director of the PCI SSC.
“PCI takes security extremely seriously and works with all relevant organisations to ensure we utilise or reference the most up-to-date security requirements for all aspects of protecting cardholder data throughout the transaction lifecycle.
“As part of this, PCI DSS references specific external documentation when it is appropriate. For example, the glossary definition for Secure Cryptography clearly points to the Nist [National Institute of Standards and Technology] standard which defines acceptable levels of cryptography.
“The PCI DSS also references other global industry standards,” he said.