Blog post

Best Practices in PCI DSS 3.1 are now required

By Jonathan Care | August 13, 2015 | 0 Comments

PCI DSS

PCI DSS 3.1 became effective April 15, 2015, and impacted organizations were given some “Best Practices”, with a clear indicator that on July 1st, 2015 these would become required. So what has changed, and what (or whom) are impacted? This is dependent on which SAQ you are completing, so let’s take a look at these requirements and see which SAQ they impact.

  • 6.5.10 – Requires specific coding practices to protect against broken authentication and session management. This affects the following SAQs:
    • SAQ A-EP
    • SAQ D-Merchant
    • SAQ D-Service Provider
  • 8.5.1 – Requires that service providers with remote access to customer premises use unique authentication credentials for each customer. This affects SAQ D-Service Provider.
  • 9.9.x – Requires that devices capturing payment card data via direct physical interaction with the card be protected from tampering and substitution. This affects the following SAQs:
    • SAQ C
    • SAQ B
    • SAQ B-IP
    • SAQ D-Merchant
    • SAQ D-Service Provider
  • 11.3 – Requires a methodology be implemented for penetration testing, which affects
    • SAQ A-EP
    • SAQ D-Merchant
    • SAQ D-Service Provider
  • 12.9 – Requires that service providers provide the written agreement/acknowledgment to their customers as specified at requirement 12.8. This affects SAQ D-Service Provider

What does this mean for me?

As a card acceptor, make sure that any entities storing, processing, or transmitting data on your behalf are up-to-date on these new requirements. Especially, make sure that they give you a written acknowledgment of their responsibilities for the security of cardholder data that you entrust to them. If you need to perform penetration testing as part of your PCI DSS compliance exercise, ensure that you have a methodology that covers infrastructure testing, application testing and even social engineering testing, both internally and externally. A lot of recent breaches have involved application security flaws, or exploitation of trust or process flaws to obtain access to cardholder data. And of course, once you have that methodology documented, ensure your penetration testers understand and follow it – whether its an internal team, or a professional service organisation. There are several exemplars available, including the Penetration Execution Testing Standard, guidance from SANS, OWASP, ISECOM, NIST and even the PCI Council has something to say on the matter.

As a service provider, the biggest change is that you are required to state in writing that you are responsible for the security of cardholder data you process on behalf of a card acceptor. This can have significant implications if (or when) a card acceptor is breached. If you’re a payment processor providing additional services to a card acceptor (for example, tokenization), then this may affect you, too.

What’s good about it?

These changes give PCI DSS entities a degree of clarity around what is required for compliance with PCI DSS. Like traffic warning signs placed at accident blackspots, PCI DSS changes usually come about from the card associations identifying key patterns in data breaches, and refining the guidance and requirements. So if you are using a service provider, they are now on notice that they have to accept responsibility for cardholder data, and software developers are getting direction around what they need to do to make their payment applications more resilient against attack. Finally of course, it removes some of the variance in penetration testing quality and execution, giving the opportunity for formal adoption of good security practices in this important area.

Remember, you don’t have a choice around whether your payment systems are tested for vulnerabilities – you only have a choice regarding whether it is done under your control, or not.

Leave a Comment