The PCI Security Standards Council Thursday released updated requirements for organizations that handle data on holders of credit cards and thus must comply with the council’s data security standard, known as PCI DSS.
The changes, first introduced in draft form in August, were then discussed during public PCI community meetings, before becoming formalized in PCI DSS version 3, which details information security policies and procedures for businesses that collect or process cardholder data. Also Thursday, the council released the Payment Application Data Security Standard (PA-DSS) version 3, which covers vendors of payment industry software.
Both standards will take effect January 1, although businesses will have until the end of 2014 to comply. “The older version, 2.0 will be ‘sunsetted’ for one year, so … you have some time to see what the changes are,” said Bob Russo, general manager of the PCI Council, speaking by phone. “But please don’t wait until the end of next year.”
What’s new? “The 3.0 version of this standard is probably more of a natural evolution than a revolution,” said Rodolphe Simonetti, managing director of Verizon’s Payment Card Industry Services, in a phone interview.
From a security standpoint, here’s an overview of some of the most important ways in which the standards have evolved:
1. Expanded Penetration Testing Requirements
In the words of the revised PCI DSS standard, businesses that have segmented their networks to isolate cardholder data must now “perform penetration tests to verify that the segmentation methods are operational and effective.” While there were previously some “pentesting” requirements, those didn’t extend to segmented networks. “It makes sense, because it’s really important to make sure that … the network segment is segregated from the rest of IT,” said Verizon’s Simonetti. “It doesn’t make sense to secure a room, if you still leave the door open.”
2. Unique Authentication Credentials Required
The revised PCI guidelines call on any service provider — including cloud service vendors — that has remote access to a customer’s systems to “use unique authentication credentials for each customer.” That particular requirement is part of a handful that won’t take effect for another 18 months, to give businesses more time to comply.
This change was made in response to real-world breaches. “We were seeing attacks over the last two to three years where one password or set of credentials was being used for a series of merchants” — in the PCI world, that refers to any organization that accepts credit card payments — “and it lead to a series of compromises where the systems were fairly secure, but because there was a known password for all of these systems, it lead to a chain of compromises,” said Troy Leach, CTO of the PCI Council, speaking by phone.
3. Watch POS Security
The security of point-of-sale (POS) terminals is now covered by the standard. “We’ve had a document around skimming and doing some basic checks to make sure they’re not compromised,” said Leach, but the latest standard now includes “checkpoints for merchants to validate that the systems haven’t been tampered with.”
In the past, some PCI members had resisted this proposal, citing cost concerns, he said. Now, however, the standard will require merchants and service providers to perform basic checks on devices to ensure that they haven’t been tampered with. Likewise, the standard demands certain levels of tamper resistance, so that for example if a POS terminal gets opened, it will stop working.
One overriding goal, said Leach, is to ensure that merchants receive better education about the ways in which criminals might target them. For example, he cited a recent incident in Britain in which an organized crime ring shipped replacement POS terminals to merchants, together with instructions to ship the old terminals back using included mailers. As a result, the criminals behind the social engineering attack obtained old POS terminals that still stored customer data, but also tricked merchants into installing the new POS terminals, which had been infected with malware.
“It was a very successful attack, because those merchants were not educated and aware of some of the basic checks” that they should have done in that situation, Leach said.
4. Malware Checks Expand
All systems that touch cardholder data must now be analyzed as part of a malware risk assessment, to assess the potential risk they pose. In some ways, this revised requirement is meant to correct earlier auditing errors. “Historically, we said that systems that aren’t commonly affected by malware wouldn’t have to validate that they’re running malware,” said Leach, referring to such systems as mainframes and midrange AS/400 systems. “They don’t have the ability to incorporate malware, [but] assessors would sometimes go into a mainframe environment that’s highly secure, and mark them as non-compliant” — because, technically speaking, they weren’t running anti-malware software.
“That was never the intent of the requirement,” said Leach. Hence the PCI standard has been revised to lead businesses to ask: “Does this particular distribution of Linux, or Solaris or Unix or whatever it might be need to be evaluated?”
5. Cloud Providers: Prove Your Compliance
Service providers under PCI-DSS version 3 must provide written acknowledgement of how they use cardholder data. “Especially when we start talking about cloud computing, the majority of merchants are starting to leverage some part of cloud,” said Leach. But to date, there haven’t been any guarantees from cloud providers about how they might handle or protect cardholder data.
This particular new PCI requirement is meant to take effect starting now, and hopefully shift that balance of responsibility for all contracts signed in the future. The PCI Council’s Russo said the intent is to get more businesses to add this language to their RFPs and contracts, to thus hold their vendors legally accountable.
6. Vendors: Educate Customers
Another PCI change concerns the PA-DSS standard that governs vendors. In particular, the PCI Council wants vendors to put secure coding practices in place during the development cycle, as well as to help customers implement products in a secure manner. That includes helping customers change any default passwords built into hardware and software products. “If we could get rid of default passwords, we’d probably stop — for the breaches we’ve seen — the vast majority of compromises,” said Leach.