Posted by Taylor Armerding on February 14, 2019
The original version of this post was published in Forbes.
Anything that could reverse, or even slow down, the rampant theft of credit card data would be a very big deal.
And that is the goal of the Payment Card Industry Security Standards Council (PCI SSC), which earlier this month published the first major overhaul of its software security standards in more than a decade.
The titles involved are a bit of an acronym alphabet soup. 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), which 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. Got all that?
They are also not expected to change things immediately—not next week, not next month, perhaps not until next year. The PA-DSS will not be fully “retired” until 2022.
But whatever the label and whatever the time frame, the need is obvious. Credit card data theft is so common that it rarely makes major headlines anymore. If there is a headline, it’s often framed as “Another day, another breach.”
Which is understating it. If it’s another day, there’s generally more than one breach. Threat intelligence firm Gemini Advisory reported last November that it had found 75.9 million stolen cards for sale on the Dark Web during the previous 12 months—60 million of them from U.S. owners.
That is at least in part because the “ecosystem” of credit card data is so much more varied and complex than a decade ago. It’s not just payment card terminals at gas stations or retailers that are involved, but mobile and “smart” devices, tablets, wearables and more.
According to Troy Leach, PCI SSC chief technology officer, the new PCI standards are aimed at addressing the evolution of software development to accommodate that expanding ecosystem “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 of that approach include:
The intention is “to demonstrate the ongoing protection of payment data by the software that stores, processes or transmits that information,” Leach said, adding in an interview that the PA-DSS standard was created in a time “when we had a much smaller payment ecosystem.”
“These new standards, over time, will address a much wider range of technology, and be done in a much more dynamic way. The goal is good application security—not just compliance,” he said.
If the new PCI standards really do work as intended, that would indeed be a very big deal. Of course, there is no way to know how effective they will be until they’re fully in place. But there is at least guarded optimism among some experts.
Matthew Getzelman, principal consultant at Synopsys, called 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 said.
Sammy Migues, chief scientist at Synopsys, who for several years served on a working group that had a hand in developing the standards, was a bit more cautious. The “intent and philosophy” are transformational, he said, but it will take some time to see if the reality matches the intent.
What is promising, he said, is that the language of requirements for security testing is more precise and detailed.
Instead of simply requiring pen testing and software application security testing (SAST), the new standard calls for a variety of 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 standard says, citing “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.”
According to Migues, this is likely to ensure that “some vendors are not just luckily passing some pen tests, but are consistently writing reasonable code.”
Are the two happy with what will eventually be the established framework for software security in the payment card industry?
Both Getzelman and Migues say it doesn’t include everything they wanted but moves in the right direction.
“It’s a huge improvement over the PA-DSS and the limited AppSec control requirements in the PCI DSS,” Getzelman said.
Migues was again more measured. “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. “It’s most correct to say that I’m happy that there are results.”
Of course, the long-term results will depend in part on how much of the industry complies with the standards and in part on whether online attackers figure out new ways around improved security—as they always do.
One unknown is whether smaller organizations will think they have the resources and expertise to comply. But Leach said the new PCI standards are not intended for merchants but for their software providers.
“This probably benefits SMB (small- to medium-sized businesses) companies 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.”
The new standards are not legal requirements—Leach said that how the industry uses them is “independent of the PCI SSC.”
But failure to comply with them can put organizations on the hook for sanctions, fines and liability if they are breached.
And history has shown that with numerous other standards out there, even if they are focused on other industries, they overlap enough to create “compliance fatigue” that can make adherence to any one group’s standards somewhat spotty.
Migues said he expects that history will repeat itself unless the rigor of assessments is equal across the board.
“At no point will these standards be followed any more rigorously than the previous two if organizations can shop around for the easiest grader,” he said.
“Also, there is no objective evidence that would indicate that the PCI standards have resulted in material improvements that wouldn’t have resulted through natural marketplace evolution and vendor attrition,” he added.
“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.”
Leach acknowledged that while the PCI SSC doesn’t have such evidence, 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 anecdotal evidence “from several companies over the years that have benefited by using software that was independently tested by security experts that prevented potential exploits.”
There is universal agreement that better software security will improve the security of the payment card industry overall. It’s just much too early to tell if it will be better enough.
Get the latest AppSec news and trends sent directly to you.