October 8th, 2014 by Elma Jane

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. 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.

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.

PCI DSS v3.0 is business as usual for the most part, except for a few changes from v2.0 that considers impactful for large swaths of merchants. 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.

Penetration testing

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. 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.

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 raises 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.

Redirecting merchants

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.

The redirect can come in several forms. 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, HTML code used to display one website within another website. 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.

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. But in v3.0, such redirect merchants have to take the second longest SAQ, which entails over 100 security controls.

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.

Service providers

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. 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.

A web hosting company may tell a merchant that the hosting company is PCI compliant. The merchant thought, they have nothing left to do. 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. 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.

Overall, 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. On the whole a lot of these changes are very positive.

 

Posted in Best Practices for Merchants, Credit Card Security, Payment Card Industry PCI Security Tagged with: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,