For the last two weeks it seems my mind and time has been consumed by PCI DSS, the Payment Card Industry Data Security Standards, a document written by the PCI Security Standards Council. The Council’s founding members are American Express, Discover Financial Services, JCB International, MasterCard, and Visa Inc. At the time of this writing the current version which I reference throughout this article is v3.2 published in April 2016. References are available at the bottom of this article.

I am going to recap some recent experiences I had with PCI compliance and small/medium-size businesses (SMBs) in the central Illinois area.

What is PCI DSS?

According to PCI DSS, it “[p]rovides a baseline of technical and operational requirements designed to protect account data”by publishing “a minimum set of requirements for protecting account data, [that] may be enhanced by additional controls and practices to further mitigate risks, as well as local, regional and sector laws and regulations.” 1 This “set of requirements”consists of 12 abstract “operational and technical requirements” that apply to all entities involved in payment card processing–including merchants, processors, acquirers, issuers, and service providers” and all other entites that store, process or transmit cardholder data (CHD) and/or sensitive authentication data (SAD).” 1

  1. Install and maintain a firewall configuration to protect CHD.
  2. Do not use vendor-supplied defaults for system passwords and other security parameters.
  3. Protect stored CHD.
  4. Encrypt transmission of CHD across open, public networks
  5. Protect all systems against malware and regularly update anti-virus software or programs.
  6. Develop and maintain secure systems and applications.
  7. Restrict access to CHD by business need to know.
  8. Identify and authenticate access to system components
  9. Restrict physical access to CHD.
  10. Track and monitor all access to network resources and CHD.
  11. Regularly test security systems and processes.
  12. Maintain a policy that addresses information security for all personnel.

That Seems Pretty Simple…

Despite being only 12 abstract control objectives version 3.2 of PCI DSS is 139 pages and published along with it are several supporting documents like one dedicated to a “Glossary of Terms, Abbreviations, and Acronyms” 2 which itself numbers 24 pages and there are multiple assessment documents each specific to different environments and merchant circumstances. Each of the 12 high-level objectives contain more specific requirements that must be followed under circumstances which are discovered by a merchant performing a self-assessment questionaire (SAQ) or by a qualified security assessor (QSA) while performing a formal audit or by a designated Internal Security Assessor (ISA) while performing a Report on Compliance, or RoC. There are also best practices guidelines, implementation guidelines for various environments, wireless-specific guidelines, etc. So although it may seem simple at first glance, PCI DSS is actually quite complex and nuanced in practice.

Should We Care?

Small business clients often ask me “Do we need to be PCI compliant?” or more informed clients will ask “What level of merchant are we with regards to PCI compliance?” Clients less informed (and perhaps most exposed to risk) might not even ask “What is PCI compliance?” and assume it is not a thing they need to worry about. This brings about a basic question of “Does this apply to me at all?”

A quick test I recently used for a small business client was asking if they accept Visa, MasterCard or Discover-branded credit or debit cards at any of their locations. Of course, they do, and so PCI DSS does apply to them. 3 The question then becomes, how much of it is applicable? The simple answer is anything in-scope with the cardholder data environment (CDE). The long answer is, it depends on your particular situation. The starting point is doing a self-assessment questionnaire of which there are multiple sub-types (SAQ-A, SAQ-A-EP, SAQ-B, SAQ-B-IP, etc.) 4

In the case of this client, they accept card transactions using an approved ‘swipe terminal’ which has both an internet connection and a backup dial-out connection to the phone network. They do not store cardholder data (SAQ D) and they do not use a P2PE terminal solution (SAQ P2PE). They do not perform e-commerce treansactions or use point-of-sale (POS) or a PC to take payments. By following the illustration in the footnote 4 this clearly puts the business in the SAQ B-IP environment, so from here on out that document is their primary guide to PCI DSS compliance which helps us answer our question of “how much of it is applicable?” 5

Now we know that PCI DSS applies to the client and that SAQ B-IP, which addresses “requirements applicable to merchants who process cardholder data only via standalone, PTS-approved point-of-interaction (POI) devices with an IP connection to the payment processor” is the specific assessment questionnaire I need to perform for the client to ensure they are compliant. 6

PCI DSS are Minimum Requirements

Another consideration when asking oneself if one cares about PCI compliance would be to consider that even the PCI says their requirements are, in large part, already considered industry standard security practices that most companies should be doing already as part of their basic security protections. If you are able to say with confidence that your IT security game is so good that PCI DSS would be a security downgrade, then by all means ignore it after you read it all. If you are like most people and you really have no idea, then PCI DSS is a good starting point to build from to start learning how to integrate IT and data security into your daily business operations and processes and allows you to start putting your risk exposure into something more measurable than “Well we have a firewall installed…”

Whether you think you are compliant or not, it does not change the fact you are required to perform quarterly vulnerability assessments for wireless at each location and that you are required to perform annual SAQs and remediate any issues discovered. This is not a thing you want to find out the day financial auditors show up at your business.

Scope it Out First

The next issue is determining the scope of the cardholder data environment (CDE). Scoping and network segmentation is often the most cost-effective way to minimize the footprint of what devices and subnets on your network are considered in-scope of the PCI DSS rules. To better illustrate what scoping is or why it’s important consider the following example:

Example 1, ISP default setup

You have a modem/router/WAP gateway device with a single DHCP server broadcasting DHCP on the network 192.168.1.0/24 and it contains four switch ports for connecting your devices. You connect a Windows workstation for an employee to use for work-related activities and you connect the card swipe terminal your payment processor provided your company. The workstation gets an IP of 192.168.1.2 and the card terminal gets an IP of 192.168.1.3. Barring other restrictions, the workstation is ‘in-scope’ with the card terminal because it can communicate directly over the network to the card terminal by IP. Since the gateway is also broadcasting a wireless network, the wireless network is also in-scope of the card terminal.

The implications of this example are that in order to be PCI compliant, we would need create firewall rules or change our router configuration so that traffic between the wireless network and the workstation PC is always denied. If we are, for some reason, unable to block the wireless traffic from reaching the card terminal, then we would have to implement wireless security standards outlined in PCI DSS which include things like 802.11i (WPA2) and 802.1x port-based authentication, maintaining wireless access logs, and operating a local wireless intrusion prevention system (WIPS). We also still have an issue that anyone can plug a device into the two remaining open ports on the gateway device since virtually all of those devices are incapable of administratively disabling switch ports.

Network Engineering 101 for SMBs on a Budget

A simple solution would be to use a managed switch with VLAN support and the ability to administratively disable unused ports. Such a switch with 8 ports can be purchased for less than $200 from Ubiquiti Networks and a router containing support for rich/complex firewall and routing rules with support for VLANs can be purchased from the same vendor for $50-$110 depending on the device. Scoping and network segmentation are covered in-depth by PCI at the following footnote. 7

Example 2, VLANs, Subnets, and Rules

In this scenario, we now have a modem running in bridge mode which hands the internet connection to our new gateway/router which, in-turn, is plugged into our managed switch. From inside the switch, we can disable all unused ports so anyone plugging into them will have no connection (or will be placed into an isolated ‘guest’ VLAN and subnet) until an authorized person configures the port.

We can also assign VLANs to individual or groups of ports on our switch and give them their own subnets and DHCP pools in the router. Now, we plug the card terminal into a port configured for VLAN 80, our CDE VLAN in which only PCI authorized terminals are allowed, using a network of 192.168.80.0/28. We plug the workstation into a port configured for VLAN 60, our internal office VLAN in which only company approved devices will communicate and we assign this network to 192.168.60.0/24.

Then in our router or firewall, we create rules which effectively say “block all traffic from VLAN 80 to VLAN 60 and block all traffic from VLAN 60 to VLAN 80, block devices in VLAN 80 from talking to other devices in VLAN 80, and block any unsolicited incoming connection to VLAN 80 from the internet.”

Now our card terminal gets an IP of 192.168.80.2 in VLAN 80 and our workstation gets an IP of 192.168.60.2 in VLAN 60 and our wireless access point can also exist in VLAN 60 with an IP of 192.168.60.3 along with other authorized wireless clients getting IPs in that same 192.168.60.0/24 DHCP pool.

Working Smarter, Not Harder

We can then remotely, or on-site, perform security assessments to verify a lack of connectivity from an out-of-scope VLAN to an in-scope VLAN and vice versa. We can mirror the CDE port and sniff traffic to confirm things are operating securely as expected. The local configuration on the router and switch are protected by a unique and strong password and the configurations are backed up and deployed remotely. Changes made on-site that would affect the compliance situation are remotely monitored so that logs are made and alerts and remediation can be performed when unauthorized or unexpected changes that break compliance occur.

This configuration also makes setting up additional branch offices trivial, as the configuration of each site is essentially the same as the others, is centrally managed, and remotely deployable and can be automatically monitored for changes.

How Not to Handle Issues

Interestingly enough, I have ran into situations where businesses will do all sorts of over or under-engineering to address PCI compliance issues. One such company addressed the isolation problem by literally buying a dedicated internet connection at each branch location and only hooking up their swipe terminal to that modem, connecting the rest of their devices to a different modem. However, this was only the beginning of their compliance and general IT issues.

Any customer or employee has unfettered access to the server room to do anything they please and at the time of my visit their gateway combo device was using factory-default login credentials. I responsibly disclosed both the overspending, under-engineering, and vulnerabilities I stumbled upon while handling a situation for a neighboring client. I addressed the message to the two most senior people involved in day-to-day IT decision making and never received a reply.

Instead of taking the opportunity to get ahead of the risks they took perhaps the least professional approach: they ignored my warnings, later questioned my character, motives, and expertise, then even later, begrudgingly fixed the lowest hanging fruit (the modem credentials). They clearly are not handling compliance as a continuous IT process, but as a point-in-time certification that is immutable once created. Since these are issues their quarterly vulnerability scan or annual SAQ would have uncovered, I have to guess they probably do not even do them. I am not confident they have an IT person in their employ that could explain ARP, VLANs or subnetting in a coherent fashion. There is no CIO, CTO, security chief, or any C-level responsible for IT.

Get Breached.

These circumstances may come to a head when they are breached and Visa or MasterCard show up wanting to see their annual SAQs and quarterly vulnerability reports and start combing through their unmanaged firewall rules site-by-site. That is a really poor time to learn that you were exposed to risks at 20 branch locations that you could have cheaply and easily fixed in advance if people would remove their egos and collaborate in good faith when someone responsibly discloses vulnerabilities/compliance issues free of charge and even provides direction on how to fix them.

At least say thank you…

References and Footnotes

          [1] Page 5. Payment Card Industry (PCI) Data Security Standard, v3.2. PCI Security Standards Council, LLC. April 2016. https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2.pdf

          [2] Payment Card Industry (PCI) Data Security Standard (DSS) and Payment Application Data Security Standard (PA-DSS). Glossary of Terms, Abbreviations, and Acronyms, v3.2. PCI Security Standards Council, LLC. April 2016. https://www.pcisecuritystandards.org/documents/PCI_DSS_Glossary_v3-2.pdf

          [3] Page 2. Myth 7 – We don’t take enough credit cards to be compliant. Ten Common Myths of PCI DSS. PCI Security Standards Council, LLC. October 2010. https://www.pcisecuritystandards.org/documents/PCI%20SSC%20-%20Ten%20Common%20Myths.pdf

          [4] Page 18, illustration. Which SAQ Best Applies to My Environment? PCI DSS Self-Assessment Questionnaire Instructions and Guidelines, v3.2. PCI Security Standards Council, LLC. May 2016. https://www.pcisecuritystandards.org/documents/SAQ-InstrGuidelines-v3_2.pdf

          [5] Page 13. SAQ B-IP — Merchants with Standalone, IP-Connected PTS Point of Interaction (POI) terminals, No Electronic Cardholder Data Storage. PCI DSS Self-Assessment Questionnaire Instructions and Guidelines, v3.2. PCI Security Standards Council, LLC. https://www.pcisecuritystandards.org/documents/SAQ-InstrGuidelines-v3_2.pdf

          [6] PCI DSS SQ B-IP, v3.0 – Section 2: Self-Assessment Questionnaire PCI Security Council, LLC. February 2014. https://www.pcisecuritystandards.org/documents/SAQ_B-IP_v3.pdf

          [7] Information Supplement – Guidance for PCI DSS Scoping and Network Segmentation, v1.1. PCI Security Standards Council, LLC. May 2017. https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1_1.pdf