With some of the recent breaches of restaurant chains, I’ve got to think that many of them were related to poor remote access practices. I say this because in all of my years of consulting, I have found that very weak controls around the remote access is a lot more common than one would think. Even today you will commonly find things like POS Servers directly accessible on the Internet via VNC, RDP, or pcAnywhere. I have even seen SQL databases that contain credit card data made directly accessible over the Internet.

Sometimes the organization itself is to blame. Usually because they just don’t know any better. For many, this has been the standard way to connect with their restaurants or stores remotely. They may lack the skills needed to setup secure remote access.  Other times, and this is also very common, a vendor or service provider is responsible. I can’t tell you how many times I have found completely unsecure remote access setup and enabled by the POS vendor or service provider that the merchant didn’t even know about—or at least wasn’t told about as far as the risks and compliance issues this creates. In one case I even found that the service provider had opened up a port on the firewall so they could connect directly to the POS SQL database across the Internet. No matter who is to blame, this needs to be fixed right away.

First, these organizations need to stop allowing systems in their restaurants/stores to be directly accessible across the Internet. It’s actually quite easy fix if you have fairly recent firewall hardware. Set yourself up an IPSEC site-to-site VPN tunnel between each of your stores and the central office using some form of two-factor authentication. Certificate-based along with a pre-shared key for authentication isn’t that hard to set up and meets PCI DSS requirements. Now you can provide vendors and service providers with remote access into your central office where you can centrally log their activities and implement restrictions on what they will have access to at each of the stores. And remember that they also need to be using some form of two-factor authentication to access your environment.

If you are the type of business that doesn’t have full time connectivity from your stores back to your central office then remote access is a bit more complex to manage. Each of your locations needs to be configured to support client-to-site VPN connections from your own IT department as well as from your service providers and vendors. IPSEC or SSL VPNs can be set up on most of today’s small firewalls and UTM devices without much fuss. But remember that two-factor authentication is a requirement and some of these devices don’t support such strong authentication methods. For this type of connectivity, some form of hardware or software token or even SMS-based token code authentication is a good choice. Sometimes this involves the implementation of a separate two-factor authentication solution, but some firewall/UTM devices have two-factor authentication features built in. This is a big plus and makes setting up secure remote access less complex and less expensive. If you go with these types of remote access connections—direct  connections to the stores—it’s very important to get the logs from remote access activity (as well as all other logs of course) from the firewalls pulled back into a central logging server for analysis and audit purposes.

To get started, your first step should be to review your external PCI ASV scans to see if any remote console services are accessible from the Internet. Look for RDP (tcp port 3389), VNC (tcp port 5900), or PCAnywhere (tcp port 5631 and udp port 5632).  Also look for databases such as MS SQL (tcp port 1433), MySQL (tcp port 3306), or PostgreSQL (tcp port 5432). If any of these show up then you should get working on a plan to implement secure and compliant remote access.

If you’re looking for more information, I’ll be hosting a security webinar on July 18th to cover common security mistakes and how your organization can avoid many of them!