The Green Sheet Online Edition
October 27, 2014 • Issue 14:10:02
Top three changes in PCI DSS v3.0
On Jan. 1, 2015, version 3.0 of the Payment Card Industry (PCI) Data Security Standard (DSS) will reach year one of its three-year lifecycle. When the PCI Security Standards Council (PCI SSC) launched PCI DSS v3.0 in January 2014, businesses were given one year to implement the updated global standard. Now that the deadline is fast approaching, interest is picking up in what v3.0 entails.
Trustwave, a global data security firm, is on the frontlines of helping secure the networks of merchants and other businesses on the electronic payments value chain against data breaches. As an approved scanning vendor, Trustwave is used by businesses to achieve and validate PCI DSS compliance.
Greg Rosenberg, Engineer at Trustwave, said PCI DSS v3.0 is "business as usual" for the most part, except for a few changes from v2.0 that he considers "impactful" for large swaths of merchants. According to Rosenberg, the top three changes involve e-commerce businesses that "redirect" consumers to third-party payment providers; the expansion of penetration testing requirements; and the data security responsibilities of third-party service providers.
Rosenberg described the new redirect mandate as affecting some, but not all, e-commerce merchants that redirect customers – typically when they are ready to pay for online purchases – to a third party to collect payment details. "If you are a customer and you are going to a website and you add something to your shopping cart, when it comes time to enter in your credit card, this redirect says I'm going to send you off to this third party," Rosenberg said.
The redirect can come in several forms. Rosenberg said it can be a direct link from the e-commerce merchant's website to another website, such as in a PayPal Inc. scenario, or it can be done more "silently."
An example of the silent method is the use of an iframe, which is HTML code used to display one website within another website. Rosenberg said "real estate" on the merchant's website is used by the third party in such a way that consumers don't even know that the payment details they input are being collected and processed, not by the e-commerce site, but by the third party.
Another redirect strategy is accomplished via pop-up windows for the collection of payments in such environments as online or mobile games. In-game pop-up windows are typically used to get gamers to pay a little money to purchase an enhancement to their gaming avatars or advance to the next level of game activity.
Rosenberg said for merchants that employ these types of redirect strategies, PCI DSS v3.0 makes compliance much more complicated. In v2.0, such merchants that opted to take Self Assessment Questionnaires (SAQs), in lieu of undergoing on-site data security assessments, had to fill out the shortest of the eight SAQs, Rosenberg said. But in v3.0, such redirect merchants have to take the second longest SAQ, which entails over 100 security controls.
Rosenberg said the PCI SSC made this change because of the steady uptick in the number and severity of e-commerce breaches, with hackers zeroing in on exploiting weaknesses in redirect strategies to steal cardholder data. Also, redirecting merchants may be putting themselves into greater data breach jeopardy when they believe that third-party payment providers on the receiving end of redirects are reducing merchants' compliance responsibilities, when that may not, in fact, be the case, according to Rosenberg.
Rosenberg said penetration testing is the way in which merchants can assess the security of their networks by pretending to be hackers and probing networks for weaknesses. He said that v3.0 of the PCI DSS mandates that merchants follow a formal methodology in conducting penetration tests, and that the methodology goes well beyond what merchants can accomplish using off-the-shelf penetration testing software solutions.
Rosenberg said merchants that are self assessing and using such software are going to be surprised by the rigorous new methodology they are now expected to follow.
Additionally, penetration testing requirements in v3.0 raise the compliance bar for small merchants who self assess. Those merchants could lower the scope of their compliance responsibilities by segmenting their networks, which essentially walls off data-sensitive areas of networks from the larger network. In this way merchants could reduce their compliance burdens and not have to undergo penetration testing.
Not so in v3.0. "If you do something to try to reduce the scope of the PCI DSS to your systems, you now need to perform a penetration test to prove that those boundaries are in fact rigid," Rosenberg said.
Rosenberg said a service provider is any entity that stores, processes or transmits payment card data; examples include gateways, web hosting companies, back-up facilities and call centers. He said the update to the standard directs service providers to "clearly articulate in writing which PCI requirements they are addressing" and what areas of the PCI DSS is the responsibility of merchants.
For instance, a web hosting company may tell a merchant that the hosting company is PCI compliant. "The merchant thought, 'Oh I have nothing left to do,'" Rosenberg said. "The reality is there is still always something a merchant needs to do; they just didn't always recognize what that was."
In v3.0, service providers, specifically value-added resellers (VARs), also need to assign unique passwords, as well as employ two-factor authentication, to each of their merchants in order to remotely access the networks of those merchants. Rosenberg said VARs often employ weak passwords or use one password to access multiple networks, which makes it easier for fraudsters to breach multiple systems.
The PCI SSC is "trying to at least make it more difficult for the bad guys to break into one site and then move to the hub, so to speak, and then go to all the other different spokes with the same attack," Rosenberg noted.
Overall, Rosenberg believes v3.0 is more "granular" by more accurately matching appropriate security controls to specific types of merchants, even though the approach may add complexity to merchants' compliance obligations.
Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.