The latest Payment Card Industry Data Security Standard – PCI DSS 3.2 – continues what industry experts call “an evolution, not a revolution.”
That would make sense, since it is also “mature,” by Internet historical standards.
The first official iteration, PCI DSS 1.0, was released in December 2004 – several generations ago in the IT era. And its roots go back another five years, to October 1999, when Visa established the Cardholder Information Security Program (CISP).
It also remains controversial. Its supporters say while nothing can make credit card transactions “bulletproof,” its requirements have significantly lowered the risk of fraud and breaches.
Its critics have contended since the start that the standard, created by five major card brands – Visa, Mastercard, American Express, Discover and JCB – is mainly designed to shield the card issuers and banks from liability for loss, at the expense of merchants.
“We view PCI as the ultimate Catch 22 for most smaller businesses,” said Liz Garner, vice president of the Merchant Advisory Group (MAG), who adds that MAG calls the PCI requirements “specifications.” “We don’t say ‘standards’ because they aren’t accredited.
“You spend a ton of capital and resources to become ‘compliant,’ but if you’re breached you are no longer compliant, and become subject to thousands of dollars of fees and fines,” she said. “Until that aspect of PCI changes, and small businesses that invest in compliance are offered some protections for their investment, I don’t think PCI as an organization will be truly effective.”
Rich Mogull, CEO and analyst at Securosis, a longtime critic of PCI DSS, agreed. The requirement for essentially constant compliance – a nearly impossible task – “is more to help push the blame back on enterprises that are breached than anything else,” he said.
Of course, not everybody sees the merchants as overburdened. Alphonse Pascual, senior vice president, research director, head of fraud and security at Javelin Strategy and Research, argued that, “the burden for protecting cardholder data rests with every stakeholder, and merchants should rightfully be responsible for meeting the requirements of PCI DSS when it is their systems that are responsible for storing and transmitting that data.”
Julie Conroy, analyst with the Aite Group, said she thinks critics are, “viewing this through the lens of compliance obligation versus security best practices. The reality is that criminals are innovating their attacks faster than businesses are fortifying their security.
“The new reality in this age of digital commerce and digital data is that businesses need to spend money to protect that data,” she said.
And Jeremy King, international director at the PCI SSC, while not directly addressing the merchant complaints, said in a statement that protection against breaches, “comes down to having and maintaining the right people, process and policies, with the technology in place to support those. PCI DSS 3.2 emphasizes the importance of validating that security controls are in place and working.”
The PCI SSC also notes that it develops the updates based on feedback from all stakeholders – card companies, banks, payment processors, hardware and software developers, merchants and assessors.
However, amid the ongoing debate, both critics and supporters welcome some of the new requirements that they say are long overdue.
The one getting the most praise is the requirement for “multi-factor” authentication “for any personnel with administrative access into environments handling card data,” according to a summary by the PCI Security Standards Council (SSC), which develops and issues the PCI DSS updates. Previously, a two-factor authentication (2FA) requirement applied only to remote access from untrusted networks.
The change in language to “multi-factor” suggests that authentication should include at least three: “Something you know,” like a password; “something you have,” such as a token or certificate; and “something you are,” which would include biometrics like a fingerprint or eyeball scan.
Mike Morrato, research director at Gartner, said the change is aimed at both internal and external users. “While many organizations have already enforced this for years, it hasn’t been universal,” he said. “It’s a good security practice in general and strengthens part of the Identity and Access Management (IAM) component of PCI.”
Indeed, Conroy noted the irony that, “so many criminal underweb sites require two-factor authentication (2FA) for admission, but so many merchants still have not implemented it for their point-of-sale (POS) terminals.
“The Verizon Data Breach Investigations Report this year further substantiated the need for this, with the stat that 63% of breaches are the result of weak, default or stolen passwords. The password’s useful life as an authenticator is long past,” she said, “and 3.2 finally accounts for that.”
John Bambenek, threat systems manager of Fidelis Cybersecurity, agreed. Multi-factor authentication, “is something we’ve been advocating for almost 10 years,” he said. “The tools that can do this are reasonably priced, and this will force the issue of actually implementing it.”
Brett McDowell, executive director of the FIDO Alliance, is yet another fan of the change. “This is a trend we are seeing across industries and geographies,” he said, “as we collectively come to the painful realization that single-factor authentication is no longer adequate protection and that we need multi-factor authentication in all scenarios where sensitive data is being accessed.”
Other new mandates get more mixed reviews. The requirement for more pen testing, and to replace scanning with pen testing, “is a good practice on paper,” Morrato said, “because technology advances so quickly that something that was once thought as secure or had enough compensating controls in place could very well become obsolete overnight”
But, he also noted, “pen testing is neither cheap nor quick. Often fixes can take a long time to implement. Erring on the side of security is the correct mindset here, but there’s going to be some significant operating pain.”
Bambanek, by contrast, calls the requirement, “a great leap forward. Static vulnerability scanners can miss a great deal, and the move to penetration tests shifts the focus from retrospective testing to what an attacker can actually do.”
Other requirements that call for more frequent compliance audits for service providers and maintaining security throughout the year rather than making it an annual exercise also remain contentious.
Nobody argues that constant compliance would be a bad thing, but merchants have complained for years that it is simply unrealistic. And a number of security experts agree that it is possible to be compliant with the standard one day and out of compliance the next.
Mogull, in an October 2013 interview, rejected the PCI SSC’s assertion that no company that was in compliance had ever been successfully breached.
If a company with PCI certification is breached, he said, “the PCI SSC then retroactively revokes its compliance certification, often due to the victim not checking log files on a daily basis or something similar … you can always find something someone missed.”
Morrato agrees that more frequent audits and maintaining compliance will be a “pain point,” but he said, “once organizations get into a rhythm of doing this and adapt their practices to the new standard, it should become much smoother and treated like any other routine process regarding security evaluation and auditing.”
Overdue as the new requirements may be, they will only be considered “best practices” immediately. They will not be mandatory for another 19 months – Feb. 1, 2018 – “to allow organizations an opportunity to prepare to implement these changes,” according to Troy Leach, CTO of the PCI SSC.
That, according to Conroy, is not a major problem. “PCI is a set of minimum data security guidelines,” she said. “The merchants that I speak with that are keeping tabs on the threat landscape and responding to the evolving threats generally don’t find PCI too onerous, because they’re already meeting most of the requirements.”
This story, "PCI DSS 3.2: The evolution continues" was originally published by CSO.