Is your remote access PCI compliant?
When the PCI standard talks about remote access, it is referring to connecting to a computer when you are on another network. A typical example would be if you were at home, and you connected to your back-office server to look at a report using remote software like PC Anywhere, LogMeIn or any of the other packages that offer remote connectivity. Some people think that there is a list of "allowed" remote access software, and that some software has been prohibited. This is simply not the case. PCI is rarely prescriptive, and the only software that the PCI Security Standards Council validates is payment application software. The PCI standard is general, and if you can set up a remote package to meet all the elements that PCI demands, then you can rest assured that it's compliant.
The trick is knowing what the standard says you need to do. There are several elements that need to be covered, and the goal of this post is to provide a simplified list of what they are, and what they mean.
Sometimes people have a hard time understanding the language used by PCI, so I will attempt to create a list that is easier to understand. That means that it might not cover every situation out there because the PCI language was crafted to handle all remote access scenarios from largest retailer with 100,000 locations to the mom-and-pop restaurant up the street.
PCI remote access checklist:
1. Do not share log-in credentials. Think of this as the user name and password. PCI wants you to be able to prove beyond a shadow of a doubt who accessed a system. If you share the remote access account, then you cannot be 100 percent sure who accessed your system remotely.
2. Use two-factor authentication. This is a computer term that is frequently misunderstood. It simply means that you have to use two different methods of validating who you are. A user name and password is a good factor to begin with. The second factor might be a one-time password that gets sent to your e-mail account or your phone. You might invest in a little security device that generates one-time passwords every minute. There are literally hundreds acceptable two-factor solutions available today. However, using two user names and two passwords is not two-factor authentication. That is using two single factors twice. The whole point of two-factor authentication is that it is almost impossible for someone to have both the knowledge of your password and the physical access to your second factor at the same time. Therefore, you can prove who logged in.
3. Have a log of who accessed your location remotely. Depending on which SAQ applies to your location, this might be an optional component (SAQ C does not have a logging component). On the other hand, if you have an issue, being able to gather the data of who accessed your system and when will be the first key to uncovering who might have been responsible for your problems. Logs will be the first thing that an investigator will ask for if they are called in after a credit card breach, so this step should not be skipped regardless of which SAQ applies to your location.
4. Make sure that remote access is only available when it is needed for third-party support.Leaving your remote access software running is a serious issue because hackers might find that you are running a utility that they can break into. While hacking techniques are complicated to understand, the end results are not. If a hacker is given enough time with a remote access package that is always available on the Internet, then chances are good he will find a way to exploit the system and break into the network. If you are connecting via the Internet, you must not leave your remote software running all the time. Someone at your location must activate it only when it is needed.
5. Do not allow remote software to upload or download files unless there is a business justification for it. If that justification exists, then all the data that was downloaded must have its own security plan surrounding it. If you absolutely must download data from a site remotely, then make sure that you can secure not only the communication but you have a process to protect the data received. It will not do you any good to have a secure restaurant if your personal computer has the same data without the same level of protection. The safest course of action is to not allow files to be downloaded remotely at all.
By looking at your remote software and comparing it to this list, you should be able to quickly tell if your remote communication meets the requirements of PCI.
Brad Cyprus Bradley K. Cyprus has more than 20 years experience in the security industry. He manages the development of in-house solutions to validate compliance, and he is a resource that Vendor Safe customers can rely upon to help interpret the PCI standard. www