New software standards aim to resolve—or at least minimize—credit card theft. There’s cause for both optimism and caution.
Probably you’ve seen the headline, or a version of it, multiple times: “Another day, another data breach.” As in, cyber insecurity is rampant.
It is especially rampant when it comes to the theft of credit card data. At least one estimate, from threat-intelligence firm Gemini Advisory, puts it at 60 million stolen cards just from U.S. owners during a 12-month period ending last Nov. 1 (chart, page 33). Do the math. That’s an average of another day, another 164,384 card numbers stolen.
Which means anything that might reverse, or even slow, that trend would be revolutionary, in a very good way. And that is the aim of the Payment Card Industry Security Standards Council (PCI SSC). In mid-January, it published the first major, global overhaul of its software-security standards in more than a decade.
The titles of the new standards are a scramble of acronyms. The PCI Secure Software Standard (PCI SSS) and the PCI Secure Software Lifecycle (PCI Secure SLC) Standard are part of a new PCI Software Security Framework (PCI SSF) that will eventually replace the PCI Payment Application Data Security Standard (PA-DSS), created in 2008 but updated several times since then, most recently in 2016. You might need a reference card to keep track of all that.
And while the council clearly aspires to change things for the better, it acknowledges up front that they won’t change quickly—not next week, next month, perhaps not even until next year. The PA-DSS will not be “retired” until 2022.
Will Reality Match Intent?
Still, Matthew Getzelman, principal consultant at Synopsys Inc., calls the new standards “transformational—a whole new expectation for developing and maintaining secure software.”
“The PA-DSS is applicable to direct payment applications only—apps that directly process credit cards. The new standards apply to all application development in the PCI DSS space,” he says.
Or as Troy Leach, PCI SSC chief technology officer, put it, the new standards address the evolution of software development “with an alternative approach for assessing software security … designed to help ensure payment software adequately protects the integrity and confidentiality of payment transactions and data.”
The key principles are:
- Critical asset identification
- Secure default configuration
- Sensitive data protection
- Authentication and access control
- Attack detection
- Vendor security guidance
The intent is “to demonstrate the ongoing protection of payment data by the software that stores, processes, or transmits that information,” Leach said.
That is a lofty, and worthy, goal. How realistic is it?
Sammy Migues, chief scientist at Synopsys, served on a working group for several years that had a hand in developing the standards. The “intent and philosophy” of the new standards are transformational, he says, but it will take some time to see if the reality matches the intent.
Even so, he says he is encouraged that the language spelling out requirements for security testing is more precise and detailed.
‘Reasonable Code’
Instead of simply requiring penetration testing and static application security testing (SAST), the new framework calls for a variety of specific security-testing tools and techniques.
“At a minimum, assessors must use the appropriate combination of static and dynamic analyses to validate each control objective,” the framework says, citing tools for “automated static analysis security testing (SAST), dynamic analysis security testing (DAST), interactive application security testing (IAST), and software composition analysis (SCA) tools—as well as manual techniques such as manual code reviews and penetration testing.”
Migues said this is likely to ensure that “some vendors are not just luckily passing some pen tests, but are consistently writing reasonable code.”
Nontheless, he sees the changes as more incremental than revolutionary. “It took 10 years to make a small change in direction and intent, and it’ll take three-plus years to make it stick,” he said.
But whatever the magnitude of the changes, the long-term results will also depend in part on how much of the industry complies with them and whether online attackers figure out new ways around improved security, as they always do.
In the past, compliance has been spotty among smaller organizations. They argue they don’t have the resources and expertise to comply, even though failure to comply can put them on the hook for sanctions, fines, and liability if they are breached. But Leach said the new standards are intended not for merchants but for their software providers.
“This probably benefits [small-to-medium-size businesses] more than any other group,” he said. “It provides independent security testing of software to allow companies to make a more informed decision prior to purchase.
“Businesses that may not have the internal resources or capabilities to test the security of software they use to accept payments can use the standard as a metric to know their customers will be protected,” he said.
Still, while the intent and motive of the new framework are obviously laudable, Migues remains skeptical about the impact it will have.
“There is no objective evidence to indicate that the PCI standards have resulted in material improvements that wouldn’t have resulted through natural marketplace evolution and vendor attrition,” he says.
“Given that PCI compliance requires just a minimum level of application/system security, there was and still is no economic incentive to be better than that. I’m not aware of any data that suggest PCI-compliant systems are penetrated any less often than any other systems.”
Hope Or Reality?
Leach acknowledged that the PCI SSC doesn’t have such evidence, but said there are “several sources in the industry that have such evidence, but it is something we are not privy to.”
And he said the council has heard anecdotally “from several companies over the years that have benefited by using software that was independently tested by security experts that prevented potential exploits.”
There’s no debate that better software security will improve the security of the payment card industry overall. But will it cut the daily average of card data stolen to something less than 164,384? That is the hope, but it’s much too early to know if it will be the reality.
—Taylor Armerding is senior infosec writer at Synopsys Inc., Mountain View, Calif.