PCI-DSS is a mostly technical set of controls that are applicable to any organisation which stores, processes or transmits credit card data or anything that could affect the security of the card data. It is written by the PCI security standards council (PCI-SSC), mandated by the card brands (Visa, MasterCard, etc.) and enforced by the banks.
Due to the holistic approach to the security and the focus on defence in depth, PCI-DSS is not popular amongst many merchants. Some see these controls as onerous and expensive and it has even been referred to as a tax on retail.
This has led to the development of alternative options, designed to provide easier compliance and allow merchants to achieve PCI certification and meet the banks requirements without going to the extent of implementing expensive, resource heavy controls such as centralised logging, penetration testing or file integrity monitoring.
The alternative options are outsourcing the card data environment, reducing the scope of the card data environment or reducing the risk associated with the card data environment.
These ‘PCI Pills’ are designed to make compliance a much less painful experience and cover the three main payment flows for merchant transactions: mail order/telephone order (MOTO), eCommerce and face to face, and are described below:
Call centres
Problem
Call centre environments typically involve customers providing their card details to telephone agents. This data enters the call centre environment and is transmitted across a VoIP infrastructure (within the scope of PCI-DSS) before it is received by the agent. Then agent the types the card data into their workstation (in scope) and it is transmitted across the corporate LAN (in scope) to a local payment application or an internet-based payment service provider (PSP).
As the workstations are connected to the LAN and may have significant connectivity to LAN based servers and services (active directory, file shares, etc.), it is typical that the entire local infrastructure, and in many instances the wider area network of the corporation, is in scope.
Solution
In order to de-scope the call centre from a PCI compliance perspective, it is necessary to remove the card data from the environment entirely. One option for doing this would be for the merchant to engage a cloud-based DTMF (dual tone multi frequency – telephone touch tones) service provider. This cloud based service provider would sit upstream, in-between the customer and the merchant’s call centre. It intercepts the DTMF tones entered by the customer which represent the primary account number (PAN) and makes a payment with the PSP on behalf of the merchant, it will then send confirmation to the merchant that the payment was accepted.
As no card data is stored, processed or transmitted by the merchant there are no technical controls applicable to the merchant environment. The merchants’ only PCI obligation is to ensure the DTMF service provider is PCI compliant. Examples of these service providers include:
Everycloud - http://www.everycloud.eu/news/pci-compliance-lifting-your-contact-centre-out-of-scope.html
KeyIVR - http://www.keyivr.co.uk/
Semafone - https://www.semafone.com/
Face to face
Problem
Large retailers are increasingly dependent on smart Point of Sale (POS) solutions which interact with their PIN entry devices (PEDs). The interaction between the POS and the PED allows a smooth customer experience and the integration of additional functionality. This means the PED device must be connected to, or on the same LAN, as the POS.
Unfortunately, this connectivity also comes with implications. Only the PED device interacts with the customer credit card, but the connectivity between the PED and POS devices means the POS is also in scope. Larger merchants’ storage environments typically have a back office and limited segmentation across the LAN; this usually results in the entire LAN and any centrally managed POS solution also being in scope for PCI.
Solution
The card brands and PCI–SSC recognised that this was a problem for many merchants. The majority of PED devices encrypt the card data prior to passing it onto the POS or LAN but the quality of this encryption varied wildly between vendors and PSPs. With this in mind, the PCI-SSC defined a new data security standard entitled Point 2 Point Encryption (P2PE). This standardisation ensures that the card data is encrypted on the PED and can only be unencrypted by the PSP.
Vendors and service providers have been given the opportunity to align and assess their existing and upcoming PED device encryption and management solutions against the new P2PE standard. If certified, merchants will be able to use these new solutions to provide assurance that their POS and the LAN are out of scope. Then, the only applicable merchant requirements for PCI-DSS will be around the PED devices and their management.
A list of certified P2PE solutions can be found on the P2PE website:
https://www.pcisecuritystandards.org/approved_companies_providers/validated_p2pe_solutions.php
eCommerce
Problem
eCommerce is a high risk payment channel as websites act as a central repository where large volumes of customers enter their credit cards. This means hacking a payment website often results in data breaches yielding several thousand card details. In comparison, the volume of card data in a face to face environment is limited to the number of people who paid using that PED.
This risk is directly reflected in the number of applicable controls in an eCommerce environment. In some environments, these controls can exceed 300!
Solution
Like the MOTO environment, the best way of reducing your obligations is to outsource the payment channel. This can be done relatively easily by implementing an iFrame or full redirect to a PSP. Repeat payments can be managed simply with the integration of a tokenisation solution.
Visa Europe has provided detailed guidance to merchants around the controls that are applicable to their specific payment process:
http://www.visaeurope.com/media/images/processing%20e-commerce%20payments%20guide-73-17337.pdf
Please remember that simply implementing these solutions does not guarantee that your card data environment is secure. Please remember that PCI-DSS’s defines and mandates controls that are industry best practise from a security perspective. Even though many of these controls may not be required for a merchant to achieve PCI-DSS certification, it is always recommended that a holistic approach to security is taken to ensure the organisation protects its systems and data from malicious third parties or accidental disclosure.
Finally, it’s essential that any proposed solution or approach is always agreed with the merchants acquirer prior to implementation to ensure that they agree with the applicable controls and scope reduction!