New PCI DSS Rules Have Big Changes for Service Providers
The newly-released Payment Card Industry Data Security Standard Version 3.2 includes increased scrutiny for the security providers who help merchants process, store or transmit cardholder data.
PCI Council CTO Troy Leach said that service providers, specifically those that aggregate large amounts of card data, continue to be at risk.
“PCI DSS 3.2 includes a number of updates to help these entities demonstrate that good security practices are active and effective,” he told industry reporters.
Sword & Shield Vice President of Services Fred Cobb said one of the biggest changes is that service providers now will be required to have two penetration tests throughout the year in order to validate proper network segmentation of the cardholder data environment. This assumes that network segmentation is in use. In the past, service providers were only required to have one annual test.
Additionally, 8.3.1 of the PCI DSS 2.3 requires multi-factor authentication for non-console access to systems within the cardholder environment, including local access. Another requirement is to have an aggressive policy and process in place for detecting and reporting on failing critical security systems along with the technology in place to detect security events. PCI DSS requirement 10.8.1 mandates the ability to quickly detect, respond and report on security events that could affect the security of cardholder information.
“Many of the updated requirements will have an impact on the service providers’ bottom line,” Cobb said.
In his blog post on the revisions, Leach also mentioned that the council is considering “incorporating some of the Designated Entities Supplemental Validation (DESV) criteria for service providers.”
The DESV outlines a series of extra controls required for high-risk entities that have either experienced multiple breaches or are risky targets. Leach’s statement implies that some of the controls found in DESV, such as scouring systems for the presence of cardholder data, enacting formal compliance reviews and conducting semi-annual reviews, might end up in the PCI DSS baseline.
Here is the summary list of changes in the PCI DSS 3.2 as published by the PCI Council:
- PCI DSS 3.2 Requirement 10.8 and 10.8.1
- Service providers are required to detect and report on the failing of critical security control systems.
- This PCI DSS 3.2 change focuses on the importance of immediate notification of failure of security systems and protocols. The longer an organization goes without notice of a potential compromise, the longer a potential hacker has to compromise said systems.
- PCI DSS 3.2 Requirement 184.108.40.206
- Penetration Testing must occur every six months
- This PCI DSS 3.2 change is specific to 3rd party penetration testing, and changes the PCI DSS 3.1 requirement of annual penetration testing to the new PCI DSS 3.2 standard of semi-annual penetration testing.
- PCI DSS 3.2 Requirement 12.11 and 12.11.1
- Quarterly reviews of employees/personnel and their respective access to cardholder data/cardholder data environments (CDE)
- This PCI DSS 3.2 changes isn’t major, as most service providers likely have these controls in place for PCI DSS 3.1. That being said, service providers will be required to demonstrate that the specific controls that are in place quarterly.
- PCI DSS 3.2 Requirement 12.4.1
- Establishes individual as owner of PCI DSS compliance program
- This PCI DSS 3.2 change essentially puts into writing something that most service providers have been doing for years. That is, the PCI DSS 3.2, 12.4.1 Requirement makes an official individual within the organization accountable and responsible for the overall PCI DSS compliance program. This individual is also responsible for communicating directly with executive management regarding compliance with the internal PCI Compliance program.
- PCI DSS 3.2 Requirement 3.5.1
- Requirement 3.5.1 requires that service providers maintain a documented description of the types of encryption that are utilized within their environment.
- The purpose behind this new control is establishing internal process around the documentation of the organization’s encryption architecture. The new 3.5.1 requirement prevents a single employee, or small group of employees, to be the only individuals within an organization who understand the organization’s encryption architecture, should an employee leave the company.