PCI DSS Version 3.2 has been released, on April 28th 2016, bringing a host of changes and new requirements your ecommerce business will need to meet in order to ensure your PCI DSS compliance.
Stephen Orfei, the PCI Security Standards Council General Manager, has stated that the new update “advocates that organisations focus on people, process, and policy, with technology playing an important role in reducing the overall cardholder data footprint.”
But what exactly are the new requirements, and what will you need to do to ensure PCI DSS compliance within your ecommerce business?
Why is 3.2 being launched now?
Now that PCI DSS is recognised as a mature standard, new releases are being released more frequently to offer incremental modifications, in order to more efficiently address and combat threats.
The new requirements and updates take into account industry feedback from over 700 organisations and compiled by the PCI Council, including data breach reports and alterations to payment acceptance.
PCI Security Standards Council Chief Technology Officer, Troy Leach, has stated:
First, we must address the revised migration dates away from SSL/early TLS. Second, the industry recognizes PCI DSS as a mature standard now, which doesn’t require as significant updates as we have seen in the past. Moving forward, you can likely expect incremental modifications to address the threat landscape versus wholesale updates to the standard. Finally, we are sensitive to the drastic changes that are happening with payment acceptance – from advancements in mobile payments to EMV chip rollout in the United States, to adoption of other forms of dynamic data and authentication. By releasing the standard early, with long sunrise dates, organizations can evaluate the business case for their security investments.
It’s been confirmed there will be no additional releases throughout 2016 – as previous updates had been traditionally launched in the fourth quarter of the year. PCI DSS v3.1 is set to expire on October 31st 2016.
Major Changes for PCI DSS 3.2
Multi-factor authentication
One of the biggest changes is multi-factor authentication (MFA), which is now a requirement for personnel with administrative access into any environment which handles secure card data.
MFA requires multiple forms of credentials to authorise access to data and systems – which can include passwords, tokens, smartcards, or biometrics.
By requiring multi-factor authentication for sysadmins, it makes it much more difficult for attackers to use administrative credentials to access secure systems. This change must be implemented by February 1st 2018.
Prior to 3.2, multi-factor authentication was only necessary when it involved remote access from untrusted networks into the cardholder data environment. But now, even sysadmins with local access will need more than just a single password to log in. MFA can be performed at a network or system level.
MFA has been introduced due to an increase in attacks which circumvent a single point of failure – and deems a single password not secure enough to verify the administrator’s identity, which could access sensitive information.
New requirements for service providers
New requirements have also been introduced for service providers, incorporating some of the Designated Entities Supplemental Validation, or DESV, criteria.
This criterion has been added as an appendix to the standard, and also expands on a number of requirements to include DESV controls for service providers. DESV had previously been a separate document entirely. This includes:
- Demonstrating a detection mechanism is in place to respond to failures with critical security controls in a timely manner (Section 10.8, 10.8.1).
- Service providers must perform penetration testing on segmentation controls at least every six months, to show segmented environments are secure (Section 11.3.4.1). This was previously an annual requirement.
- Executives of service providers are now also required to demonstrate their understanding of PCI DSS compliance, and take overall responsibility for maintaining compliance. A charter for a PCI DSS compliance program must also be defined, and communicated to executive management (Section 12.4).
- New regulations now state that checks for personnel compliance with security policies must be undertaken on a quarterly basis (Section 12.11, 12.11.1).
As part of the personnel compliance reviews (Section 12.11), what must be covered includes:
- Daily log reviews
- Firewall rule-set reviews
- Application of configuration standards
- Security alert responses
- Change management processes
Revised Secure Sockets Layer (SSL) and Transport Layer Security (TLS) sunset dates
As part of PCI DSS v3.2, the migration date from SSL/early TLS has been revised.
Last year, the 3.1 release gave organisations 14 months to transition away from SLL and early TLS 1.0, which were previously in use for years, with a deadline of June 30th 2016. This meant all companies must have upgraded to at least TLS v1.1 or higher.
Once browser attacks including POODLE and BEAST took advantage of flaws found in SSL, these were no longer deemed secure.
PCI DSS 3.2 solidifies the migration away from SSL and early TLS – however, it has extended the migration deadline to July 1st 2018, to ease the transition for companies which depend heavily on other entities that utilise SSL.
Alongside this, PCI DSS 3.2 also includes a migration appendix in order to help companies make the switch.
Primary Account Number Masking
PCI DSS 3.2 updates the requirement for primary account number (PAN) masking, in order to ensure any display of PAN greater than the first six, or the last four, digits requires a legitimate business need (Section 3.3).
However, this requirement does not supersede any stricter requirements that may be in place for displays of secured cardholder data, such as brand requirements for point-of-sale receipts.
Change control processes
PCI DSS 3.2 has a new requirement for change control processes, in order to ensure when a significant change is completed, relevant PCI DSS requirements are implemented on any new systems or networks, including updating any affected documentation (Section 6.4.6)
Further Clarifications
Existing requirements have also been clarified – including changing the naming convention from “two-factor authentication” to “multi-factor authentication”, due to the fact that a minimum of two credentials are necessary to authorise access to card data.
Additional Guidance
PCI DSS 3.2 adds additional guidance on particular topics, such as the relationship between Payment Applications Data Security Standard (PA-DSS) and PCI DSS. As threats evolve, applications which are no longer supported by the vendor in question, may not offer the same security as supported versions.
What’s next for PCI Compliance?
PCI DSS 3.1 expires on October 31st 2016 – at which point, PCI DSS 3.2 must be used for all PCI DSS assessments.
After February 1st 2018, these new requirements will be deemed effective – as until then, they are deemed as best practice, in order for covered organisations to implement changes. Despite the fact this may seem a while away, many businesses will migrate quickly in order to remain secure, and to make the transition much simpler in time.
If you fail to implement these changes, you can be subject to fines, imposed by card brands, or lose the rights to process credit cards if your system is breached.
For a more in-depth look at the changes from PCI DSS 3.1 to 3.2, you can read more here. To read the full PCI SSC document on 3.2, then read it here.
If you need a helping hand in ensuring your ecommerce website remains safe and secure, or have any questions regarding PCI compliance, get in touch with the team here at Xanthos, who will be happy to help.
