5 Steps to Better Credit Card Handling on Your Network

The requirements for PCI compliance are… high. Performing a risk assessment alone is a time-consuming process, to say nothing of an actual audit. Which is unfortunate for small and mid-sized businesses, since most of them don’t even need to store credit card numbers locally (and in fact it is much better if they don’t). Most of the time, a small payment processor / card & chip reader are sufficient, connected to an iPhone or iPad, for example. But guess what? PCI compliance doesn’t care. If this transaction takes place on your network, then everything on your network is subject to the audit.

Fortunately, there is an easy way for you to shrink the scope of this audit (and your attack surface, and your responsibilities). What we need to do is segment this type of transaction/traffic to a completely separate network, and not place anything else on it.

Let me be clear about this–having this setup doesn’t magically make you certified compliant, but it does take out a few risk factors from consideration, making your life a whole lot easier in the event of an audit. Here is how we accomplish this.

Step 1: Create a new VLAN interface on your firewall with a unique gateway address

If your internal network is 10.0.1.1/24, then create a new interface with some other IP scheme, maybe it’s 10.0.77.1/24 or something else–just ensure it is different. Make sure this network is not the same “type” as your internal network. Make a “Custom” zone or interface for it, so that it is not a “Trusted” or “LAN” network like your already existing internal network.

Next, if you find that communication (even ping) is still possible between these networks, then add an “Any” policy or rule that explicitly denies traffic between them (for any/all ports).

Last, you have to ensure that this network is allowed to communicate outbound. E.g to query an outside DNS service, such as OpenDNS–add this traffic rule to the firewall if necessary (port 53 TCP/UDP outbound from the new network). And of course, the payment provider is likely taking those SSL-encrypted payment transactions/requests over HTTPS / 443, so be sure to allow that port outbound as well for the new network.

Step 2: Bring the new VLAN to your switching infrastructure

If you tagged the interface on your firewall, then tag it on your switch infrastructure, and give it the same number or vlan id on both ends.  Otherwise if it was an untagged interface (no vlan id was specified at the firewall), then your switch connection would also be untagged, but it would be an untagged member of the credit card vlan (e.g. vlan id 77), and it should be removed from membership in vlan 1 (or whatever your default / data vlan is).

Or, if you don’t want to bother with VLAN’s, just have this be on a separate switch, and use separate physical connections entirely (see below).

Note that complete physical separation eliminates question marks even more quickly for auditors, as there seems to be no conclusive/consistent opinion in the industry on shared physical infrastructure, one way or another. That having been said, and for what it’s worth, I come down on the side of “VLAN’s are probably good enough”–provided you can easily demonstrate there is no inter-VLAN communication allowed on the network, or that it is explicitly denied by the firewall.

Step 3: Bring the new VLAN to your Wi-Fi infrastructure (if needed)

If you have Wi-Fi connected devices that process credit cards (such as iPads or iPhones), then you also need to tag this vlan on the ports that lead to the Wi-Fi access points (or use a different physical WAP). Add a new wireless network SSID (WPA2-AES) with a complex key that is changed on a regular cadence, especially if your organization sees a high rate of turnover. Specify the same vlan id in the settings for this network as you did for the switch, if applicable. Pro tip: I normally use a random password generator and make sure there is a minimum character length exceeding 12-16 characters for this network.

Step 4: Segment devices that process credit cards from the internal network

Any device that needs to access the Internet for the purposes of credit card processing (usually done via a third-party secure service provider), must use this new VLAN. If it is a computer, change the port on the switch to which it is connected, so that the untagged membership includes the new vlan id only. If a wireless device needs to access the payment provider, then make sure to remove/forget the passphrase on those devices for the internal network, and add the new Wi-Fi network instead.

This also means, any computers in this VLAN will be in a workgroup (not on the domain), and these and any other devices will have zero access to your internal network resources. Therefore, these devices have exactly one function. Which brings us to our last step.

Step 5: Lock down

We already disabled communications between the internal network and the new credit card VLAN. But we have just a bit further to go. What if someone decides to hop on the other network anyway, either by moving a cable or joining the staff WiFi?  Or, what if someone just takes the payment peripheral (card swipe/chip reader), and attaches it to an internal network device or PC? To prevent these kinds of things from being an attractive option, there are a number of solutions available, and we should implement all of them.

• Block the segmented devices from joining the internal network in DHCP by MAC address
• Set up a firewall rule that blocks communication from the internal network to your external payment provider
• On the credit card network, also consider blocking most if not all other protocols, and allow HTTPS oubound for only the most essential destinations:
  • The payment provider you need to reach on the web
  • Update providers (e.g. microsoft.com, apple.com, etc.)

Conclusion

There you have it, the result of this configuration is that you have segmented your devices that handle PCI data / credit card processing. At the same time, no devices on the internal network can process credit card payments at your provider, so that this will only be possible from the newly defined network.

The result? Audits should, in theory, go much quicker, because you can demonstrate that these two networks do not talk, and have nothing in common, except that they both utilize the same Internet connection via the firewall (which also prevents traffic from traversing between them). Is it a perfect solution? Well, no–but is anything?

If you were looking for weaknesses here, I think you’d be asking questions like, “How do you know whether these devices on the credit card network are properly updated/patched/protected?” And, “At any given point in time, how are you confident there are no other rogue devices joining that network?”  Well, those are legitimate questions that do require answers, and further thought & risk mitigation–but the above solution set is meant as a starting point. Keep making adjustments and improvements, by all means. But separation of duties on the network, so to speak, is a pretty solid starting place for most small businesses.