Introduction
Following a weekend break, I was visiting a long-established award-winning English brasserie with plenty of its own history, characteristic of Stratford-upon-Avon and Shakespeare’s country when I happened to get into a conversation with a fellow patron, who asked me what I did for a living.
Now, if you happen to work in other industries, it may be much easier to answer this question, but for my current role, I find this difficult to explain just what my job involves.
The best summary that I have been able to think of is:
“Helping businesses to understand how they can mitigate their risks and to protect themselves from their ever-present threats!”
Following this, I started thinking about how unfair it was to expect someone that is managing such a business to understand what is needed for them to be truly compliant with PCI DSS and avoid those monthly “NON-COMPLIANCE” charges.
PCI DSS and the Restaurant Industry
Having thoroughly enjoyed my meal and a discussion with my fellow patron, along came that time to make the payment and, as many do, I chose to make the payment using my credit card.
Consequently, for this restauranteur to be able to take my credit card payment they would need to provide a declaration of the PCI DSS compliance. Now, given that they were a small establishment, it was reasonable to make the presumption that they would be a lower-risk merchant (Level 4, 3, or 2) and would be able to complete a Self-Assessment Questionnaire (SAQ).
For example, let’s estimate that they average 20 covers per night, for 5 nights of the week, over 50 weeks of the year, that would equate to around 5,000 payment card transactions per annum (Level 4):
However, how do they provide a declaration of their PCI DSS compliance?
Well, they only take ‘Face to Face’ card payments using a PIN Transaction Security (PTS) provided to them by an approved provider (Global Payments), to help them with the card payment life-cycle.
Surely, if the card payment devices have been leased and provided to them by an approved provider then that should be their PCI DSS compliance obligations sorted?
Unfortunately, this is not the case, and there is quite of understanding needed to ensure that they can meet their PCI DSS compliance obligations. However, where does such a retailer start to make sure they are compliant?
Breaking Down Brick ‘n’ Mortar PCI DSS
Where a Merchant only uses Brick ‘n’ Mortar payment card devices, it all starts with the type of devices involved and their connectivity.
For this restauranteur, they were using the Ingenico iWL250:
Such a payment card PTS device is an older device and, as a result, appears on the Payment Card Industry Security Standard Council’s (PCI SSC’s) devices with expired approvals:
Although the PCI SSC urges merchants to use approved PTS devices in their payment environments and some payment brands require the use of approved PTS devices; Merchants using expired PTS devices should contact their acquirer or the payment brands directly for information about these requirements.
Okay, now that we know that this Restauranteur only has the single Face to Face payment channel (assuming that they are authorized to keep using this PTS device), how do they now start to submit their compliance status?
As per the PCI SSC FAQ 1220, dated Jul 2015, PCI compliance submissions should be on the official reporting templates and forms that are approved and accepted by all payment brands, which are available on the PCI SSC’s website, e.g.,
- Report on Compliance (ROC) templates.
- Attestations of Compliance (AOC).
- Self-Assessment Questionnaires (SAQ).
- Attestations of Scan Compliance for ASV scans.
For Brick ‘n’ Mortar payment channels there are 2 main types of SAQ to consider:
- SAQ B: Merchants with Only Imprint Machines or Only Standalone, Dial-out Terminals – No Electronic Cardholder Data Storage.
- SAQ B-IP: Merchants with Standalone, IP-Connected PTS Point-of-Interaction (POI) Terminals – No Electronic Cardholder Data Storage.
The main differences between these are the connectivity of the devices, SAQ B being a portable machine that uses a SIM, the communication method is GPRS (Mobile / SIM) and SAQ B-IP being a fixed device, used in one location, and is it connected to your internet line, the communication method is Countertop (IP / Broadband).
The added connectivity of the B-IP more than doubles the PCI DSS compliance requirements from the circa 30 security controls to a substantial 64 security controls.
SAQ B | SAQ B-IP |
Your company uses only an imprint machine and/or uses only standalone, dial-out terminals (connected via a phone line to your processor) to take your customers’ payment card information; | Your company uses only standalone, PTS-approved point-of-interaction (POI) devices (excludes SCRs) connected via IP to your payment processor to take your customers’ payment card information; |
The standalone, dial-out terminals are not connected to any other systems within your environment; | The standalone IP-connected POI devices are validated to the PTS POI program as listed on the PCI SSC website (excludes SCRs); |
The standalone, dial-out terminals are not connected to the Internet; | The standalone IP-connected POI devices are not connected to any other systems within your environment (this can be achieved via network segmentation to isolate POI devices from other systems)[1]; [1] This criteria is not intended to prohibit more than one of the permitted system type (that is, IP-connected POI devices) being on the same network zone, as long as the permitted systems are isolated from other types of systems (e.g. by implementing network segmentation). Additionally, this criteria is not intended to prevent the defined system type from being able to transmit transaction information to a third party for processing, such as an acquirer or payment processor, over a network. |
Your company does not transmit cardholder data over a network (either an internal network or the Internet); | The only transmission of cardholder data is from the PTS-approved POI devices to the payment processor; |
Any cardholder data your company retains is on paper (for example, printed reports or receipts), and these documents are not received electronically; and | The only transmission of cardholder data is from the PTS-approved POI devices to the payment processor; |
Your company does not store cardholder data in electronic format. | Any cardholder data your company retains is on paper (for example, printed reports or receipts), and these documents are not received electronically; and |
| Your company does not store cardholder data in electronic format. |
The Payment Card Industry Data Security Standard states that:
“The PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment.
The cardholder data environment (CDE) is comprised of people, processes and technologies that store, process, or transmit cardholder data or sensitive authentication data. “System components” include network devices, servers, computing devices, and applications.”
Consequently, without network segmentation of the IP-connected PTS device from everything else on the corporate network the circa 330 controls of the SAQ D would need to be applied.
Let’s presume that there’s no need to connect your PTS devices to your corporate network and you only need to align with the SAQ B, what does this entail?
Breaking Down the SAQ B
PCI DSS applies to the processing, transmission and storage of cardholder data (CHD), whereas, the SAQ B only permits storage of paper (hardcopy) CHD and is focused on the processing and transmission of CHD through the PTS device. Consequently, the SAQ B requires that the following measures are implemented.
Protect Cardholder Data
Requirement 3: Protect stored cardholder data
- Safeguard the Sensitive Authentication Data (SAD).
- Magnetic stripe data.
- 3 or 4 digit security code (CVV).
- Primary Identification Number (PIN).
- Mask Primary Account Number (PAN) -long card number).
Requirement 4: Encrypt transmission of cardholder data across open, public networks
- Do not send unprotected PAN over end-user technologies.
Think of the CHD as being like the ‘Crown Jewels’ and should be protected at all times, across their data life-cycles.
- Check your printed receipts to confirm whether the receipts are only showing a maximum of the 1st 6 and last 4 digits of the PAN.
- If the PTS device is printing more CHD than is permitted, a single call to your Acquiring Bank (or PTS Device provider) can get this setting changed.
Remember that to be eligible for the SAQ B (or SAQ B-IP), it is prohibited to electronically store CHD:
- If you have CCTV, check your recorded footage to ensure that you haven’t inadvertently captured the CHD being entered into your PTS devices.
Implement Strong Access Control Measures
Requirement 7: Restrict access to cardholder data by business need to know
- Ensure that the principle of least privilege is applied:
- A security principle that restricts the access privileges of authorized personnel (e.g., program execution privileges, file modification privileges) to the minimum necessary to perform their jobs (NIST).
Requirement 9: Restrict physical access to cardholder data
- Physically secure all media.
- Maintain strict control of the internal and external distribution of any kind of media.
- Classify media.
- Send media by secure courier.
- Obtain management approval.
- Maintain strict control over the storage and accessibility of any media.
- Securely destroy any media at the end of the data life-cycle.
- Protect direct physical interaction payment car devices from tampering and substitution.
- Maintain device inventory.
- Periodically inspect devices.
- Train personnel to recognize and report signs of tampering and substitution.
E.g., For as little as $700, they can purchase a card skimmer to steal the cardholder of any customer using their credit card:
This stolen cardholder data can then be used to turn a significant return on investment, either by Bootlegging the stolen CHD or using the stolen CHD to purchase goods that can be resold on the Blackmarket.
Maintain an Information Security Policy
Requirement 12: Maintain a policy that addresses information security for all personnel
- Maintain Information Security & Acceptable Usage Policies.
- Ensure policies & procedures clearly define Information Security responsibilities.
- Incident response responsibilities are formally assigned.
- A formal Information Security awareness program is established.
- Management of 3rd-Party assurance is maintained.
- An incident response plan is established.
As well as producing and media produced by the PTS devices, it is also extremely important to ensure that the devices, themselves are always protected.
Summary
As you can see, ‘Face to Face’ Merchant card payment operations is an attractive target for opportunist criminals and PCI DSS compliance can greatly decrease these opportunities and the risks to the Merchants’ customers.
However, most Merchants do not understand the risks to their card payment operations or how to achieve and maintain the baseline of PCI DSS compliance, making it easy for the criminals.
Face to Face Merchants need to identify their PTS devices, check their approval, and (where appropriate) reduce the connectivity to these devices and familiarize themselves with the most appropriate SAQ.
Rather than being something to be feared, businesses should investigate how the standard can help them to protect their customers’ cardholder data, during their purchases of the ‘Face to Face’ Merchant’s goods or service.
- The Ultimate In Customer Service!