IT providers may still be juggling the new requirements for PCI compliance after the council released PCI DSS version 3.1 back in April. Unfortunately, more change is coming.
Next week, five sections of PCI DSS that are “best practice guidelines” will become requirements. That means, after June 30, organizations covered by the regulations will have five new rules to juggle.
Below, we list and describe the five new rules. For more details, you can check each requirement in the full PCI DSS v3.1.
The following ‘best practice guidelines’ will become PCI requirements after June 30, 2015. Each requirement is shown in bold with a description underneath.
Requirement 6.5.10 – Broken authentication and session management
Merchants have to examine software development policies and procedures. They also have to interview associated personnel to verify that session management and broken authentication are addressed with coding techniques such as flagging session tokens as “secure” and not exposing session IDs in the URL.
Requirement 8.5.1 – Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer.
This requirement is only for service providers.
To limit the impact of credential compromise, vendors with remote access to customer environments should use a different set of credentials for each customer. That way if the credentials are compromised at one customer site, the other customers are not affected.
Requirement 9.9 – Protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution.
This requirement only applies to card-reading devices used in card-present transactions. It doesn’t apply to computer keyboards or POS keypads.
Merchants are encouraged to maintain a list of devices, periodically inspect the devices for tampering, and train personnel to spot and report suspicious behavior.
Requirement 11.3 – Implement a methodology for penetration testing.
This requirement includes a list of stipulations for penetration testing. For example, it should be based on industry-accepted approaches and it should include testing from both inside and outside the network.
Testing should also cover the entire cardholder data environment (CDE) and it should validate segmentation and scope-reduction controls.
Another stipulation is that the testing should include a review and consideration of threats and vulnerabilities experienced in the last 12 months.
Requirement 12.9 – Service providers acknowledge in writing to customers that they are responsible for the security of cardholder data the service provider possesses or otherwise stores, processes, or transmits on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.
This requirement is only for service providers.
As we mention in our PCI DSS for IT report, service providers must acknowledge in writing to customers that they are responsible for the security of the cardholder data they store, process, or transmit on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.
Data security is not static. The landscape of threats and security is constantly evolving. New vulnerabilities are discovered every year, and some have broad impact.
So expect PCI DSS to change and continue changing. New versions will be released, and new requirements will be added, the only question is when.
Changes in PCI DSS Version 3.1: What You Need to Know
PCI Compliance: 80% of merchants fail to maintain it