PCI DSS 3.0 preview highlights passwords, providers, payment data flow
15 Aug 2013 | SearchSecurity.com
Editor's update: See our coverage of the changes in the final version of PCI DSS 3.0.
The long-anticipated revision of PCI DSS won't be finalized until November, but the PCI SSC has provided the first glimpse at the proposed changes for enterprise information security's benchmark compliance mandate.
It's about making PCI compliance part of your business, not a once-a-year, study-for-the-test kind of thing.
general manager, PCI SSC
Today the PCI Security Standards Council (PCI SSC) released its proposed changes for the Payment Card Industry Data Security Standard (PCI DSS) version 3.0, which includes more than a dozen notable alterations, such as an increased emphasis on merchant-conducted vulnerability assessment, more detailed documentation of in-scope system components and card data flows, increased emphasis on malware detection and vulnerability management, added flexibility related to password requirements, and a revamped 12th requirement focused on service provider compliance management.
In an interview this week with SearchSecurity, Bob Russo, general manager of the PCI SSC, said the mission of the PCI DSS has not changed since its introduction in 2004 -- to help merchants protect payment card data wherever and however it's stored, processed or transmitted -- but the theme of PCI DSS 3.0 is to make PCI compliance "business as usual," or, more specifically, increase the importance for merchants to integrate PCI compliance with other important day-to-day business activities.
"It's about making PCI compliance part of your business, not a once-a-year, study-for-the-test kind of thing," Russo said. "But there are a lot of things that are new or have changed, so to that end, we want to center it around education and awareness, and make sure people understand what the focus is."
PCI DSS 3.0: Requirement 12 changes
The changes proposed for PCI DSS 3.0 include a number of additions and clarifications to current requirements, general guidance that affects several requirements or the overall PCI compliance process, and some significant changes to the last of the 12 requirements.
The new Requirement 12 would emphasize the need for merchants to maintain information about which PCI DSS requirements are managed by service providers and which are managed by merchants, and would require service providers to acknowledge responsibility for maintaining applicable PCI DSS requirements. Much of what was in covered in Requirement 12 concerning security policy issues has been broken up and incorporated into the other requirements.
"What we're planning for Requirement 12 is taking the operational procedure and security policy components (Requirements 12.1.1 and 12.2 in PCI DSS version 2.0) and moving them into each requirement separately," said Troy Leach, chief technology officer of the PCI SSC. "This is response to a lot of the things we were seeing and hearing."
The change is also intended to help make PCI compliance a realistic proposition for merchants that use cloud computing as an element of their payment-processing infrastructure. To date, PCI compliance in the cloud has been a struggle for many merchants, as interpretations regarding the sorts of cloud systems and configurations that may or may not be compliant have varied widely among qualified security assessors (QSAs), the select group of auditors charged with validating PCI compliance.
Leach said the move is also in response to what the SSC is seeing in terms of third-party security challenges when it comes to compromises, and also is based on the recommendations from its Third-Party Security Assurance Special Interest Group (SIG).
"Today we have not only new payment channels, such as mobile acceptance, but also ever-increasing use of new technologies, such as the cloud," Leach said, "so we want to provide flexibility in the requirements so that merchants can take a more risk-based approach to compliance.
"The focus here is really around helping merchants better understand their responsibilities when it comes to PCI DSS when working with any type of service provider, including cloud," Leach added.
Branden R. Williams, a PCI DSS expert and executive vice president of strategy for Dublin, Ireland-based Sysnet Global Solutions, said the changes to Requirement 12 are likely meant to clarify what service providers' responsibilities are, and to make it clear to them that they could be on the hook in the form of monetary penalties if an incident affects a customer's compliance status.
"If there's a breach, it's creating a vehicle for the merchant to pass liability onto a service provider," Williams said.
PCI DSS 3.0: In-house vulnerability assessment
One change that may create controversy is the change in Requirement 11 mandating not only a methodology for penetration testing, but also that penetration tests verify segmentation methods are operational and effective. Leach added that the intent is for merchants to conduct their own vulnerability assessments in addition to the existing mandated quarterly assessments by an approved scanning vendor.
Leach said the SSC hopes merchants will use their findings to reduce the scope of their own cardholder data environments.
"Our hope is that this will be a return on the security investment by enabling merchants to better understand and demonstrate that they've minimized the [in-scope] footprint and reduced the cardholder data environment," Leach said. "It's a similar but different activity" than what Requirement 11 currently covers.
"I do think that they will see some people objecting to this, because it does represent incremental work, but given how quickly the threat environment is moving, I don't think it's unreasonable to ask for this," said Julie Conroy, research director with Boston-based Aite Group. "The reality is that as agile development takes hold, we're starting to see updates to production environments get pushed out much more quickly on an annual basis," which consequently introduces more potentially flawed payment application code.
Williams also liked the change, noting that it could remove some of the interpretation issues involved with defining what types of vulnerability assessments are considered acceptable.
PCI DSS 3.0 password policy, management
Several proposed changes adjust mandates relating to password policy and management. Requirement 2 clarifies that changing default passwords is required for application and service accounts, as well as user accounts, and Requirement 8 offers increased flexibility in password strength and complexity and allows for variations that are equivalent.
"We always talked about the need for a seven-character alphanumeric password," Russo said, "but now passphrases are just as strong and easier to remember, so we decided to be a little more flexible."
The updated Requirement 8 language also emphasizes the importance of ensuring users choose strong passwords, protect their credentials and change passwords upon suspicion of compromise.
Conroy said the emphasis on password security is one of the most important changes proposed for PCI DSS 3.0 because weak passwords have been a primary cause of numerous card data breaches.
Conroy also lauded the introduction of the passphrase, noting studies that showed passphrases offer the same strength as shorter passwords that use a variety of uppercase and lowercase letters with numbers or special characters.
"I'm glad they recognize the fact that if you don't want people to use the same password across multiple platforms and you don't want people to put sticky notes on their desks, you need to make it so people can remember these passwords," Conroy said. "I think that bringing in some real-world common sense is a good thing."
PCI DSS 3.0: Defining in-scope systems
Certain parts of the proposed PCI DSS 3.0 standard are geared around helping merchants better understand and document normal, secure functioning of their in-scope systems.
Updated language in Requirement 1 clarifies the need for not only a network diagram with all connections to cardholder data, but also for an up-to-date diagram that shows how cardholder data flows through those systems.
Leach said even though this importance of understanding data flow has been emphasized in the introductory "executive summary" of the PCI DSS (commonly known as "Requirement Zero"), the added emphasis creates more accountability so merchants know exactly where the card data environment begins and ends.
"In a breach several years ago, the management of the company was presented with a data flow diagram that had been captured from the criminals that showed a color-coded scheme of how different data [flowed] through their organization," Leach said. "The management said, 'That's amazing. Why didn't we have that?'"
Along those lines, new language in Requirement 2 would require merchants to maintain an inventory of in-scope system components.
Williams said he is strongly in favor of that change. He said the added clarity beyond what exists today in the PCI DSS executive summary will not only put more emphasis on defining the in-scope environment on a regular basis, but will also place more emphasis on the application and data layers instead of the network and infrastructure layers.
PCI DSS 3.0: Evolving malware threats
New proposed language in Requirement 5 would compel merchants to evaluate evolving malware threats on systems not commonly affected by malware. Leach said one example would be the mainframe systems run by many big banks -- it's virtually impossible to install an off-the-shelf antimalware system on a mainframe, so the merchants that run those systems often opt not to put malware controls in place, and that's a tactic that may or may not be approved by QSAs during an assessment.
"I was just on a call with forensics experts last week, and malware is still their top priority because it's still the No. 1 way that criminals are able to gain access" to merchants' systems, Leach said.
Williams expressed concern that the updated language in Requirement 5 could cause some confusion, but supported the idea of increasing the emphasis on malware detection.
"Candidly, when you have a merchant forced to go through the compliance process, they're going to do the minimum required to get by," Williams said. "Still, I think it could cause interpretation biases because it's so broadly written. What does it actually mean? Subscribe to a service? Pay a consultant?"
Conroy said, "It seems that it may be a little bit confusing for banks and merchants alike, but the malware environment is evolving so rapidly that you do need to have some sort of technology that has the ability to detect emerging malware, or your infrastructure needs to be architected with the assumption that you have malware on your endpoints."
PCI DSS 3.0: Additional changes
Other proposed changes to note include the addition of supplemental guidance in Requirement 6, mandating merchants keep current with emerging threats by aligning their threat prevention programs with the guidance provided by select third parties, specifically OWASP, SANS and Carnegie Mellon CERT.
"Those groups' lists are updated on a regular, frequent basis," Leach said, "and the change just demonstrates that it's an ongoing process that has to be part of the culture of organizations responsible for processing cardholder data."
An addition to Requirement 9 mandates protection of point-of-sale (POS) terminals and other payment-related devices from tampering or substitution, an effort to emphasize the explosion in skimming and other physical attacks at the POS.
"Looking at the trends we've seen, there's been an explosion in attacks against the POS terminal, skimming right next to the terminal and other tampering," Leach said. "This change is about just going back to sound inventory management and understanding what the serial numbers are for those POS terminals, doing routine checks to make sure they are the same, and that the stickers are the same to demonstrate that there's been no tampering with those devices."
Separately, an update to Requirement 8 would boost security considerations for authentication mechanisms such as physical security tokens, smart cards and certificates, and a change to Requirement 10 seeks to clarify the intent and scope of daily log reviews.
Williams expressed concern about a change to the general language of the standard that could supplement guidance for implementing security into business-as-usual activities and best practices for maintaining on-going PCI DSS compliance. He said it may be an overreach on the part of the SSC.
"Technically you should be doing things as a business to keep [PCI compliance] top of mind, but PCI should be your baseline, it shouldn't be your security program; now we seem to be going the other way," Williams said. "I wouldn't want my business to keep PCI top of mind, but [rather] keep security top of mind. Let's focus on security principles that are far more beneficial and broadly applicable to the business than just keeping due care of where 16 digits appear in a row."
PCI DSS 3.0: Update, finalization cycle
PCI DSS 3.0 and its sister standard, the Payment Application Data Security Standard (PA-DSS) aimed at payment application providers and developers, will be finalized Nov. 7, 2013. The standards will take effect on Jan. 1, 2014, but the 2.0 versions will remain active until the end of 2014 to allow time for organizations to transition their compliance programs.
The proposed changes will be shared with the PCI SSC's more than 700 participating organizations in early September, and will be discussed at the North American Community Meeting taking place in Las Vegas in late September.
Updates to the PCI DSS and PA-DSS occur on a three-year cycle, an effort to allow time for merchants to learn about and comply with new versions of the standards, as well as to provide and discuss feedback with the PCI SSC. While critics believe the PCI SSC has not updated its standard often enough to address the changing information security threat landscape, the SSC has initiated several Special Interest Groups in recent years to provide guidance on the emergence of technologies like cloud computing, virtualization and tokenization, and other broadly applicable topics like risk assessment, maintaining PCI compliance and third-party security assurance.
The PCI SSC has scheduled a series of PCI DSS 3.0 webinars to further outline the proposed changes. Events for participating organizations will be held August 27 and 29, and online events for the general public will take place September 4 and 5.