The Path to PCI Compliance – The PCI Requirements
Welcome back to the Path to PCI Compliance. In part one of this series we outlined the very high-level path for attaining and maintaining PCI compliance. With that in mind, let’s take a quick run through exactly what the Payment Card Industry Data Security Standards (PCI-DSS) expect of you in order to be compliant.
Scope. This is a word that gets included in nearly every conversation about PCI. If not, it should. What is Scope? Here is the official definition: 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.
The PCI-DSS gets pretty technical, so let’s define this a bit further. One of the keys to this definition is “cardholder data environment” or CDE. The CDE is where a credit card number can be found. If it is stored on a server (Think scanned Vault images. Think tape and disc backups. Think call recordings), that server is in scope. If it travels unencrypted across a network segment, that network segment is in scope – including the fireware that controls network access. If a keyboard is used to key in a card number, that keyboard and computer are in scope. All of these in-scope components need to be protected. We protect said in-scope components by way of network segmentation, encryption and restricting access. One early objective of the PCI-DSS is to narrow the scope of the CDE as much as reasonably possible. For NISC Members that use NISC solutions for taking credit card payments, that can mean several things:
- If you only accept credit card payments using NISC-hosted solutions (Smarthub and IVR), your scope is limited to the NISC Cooperative Cloud. This means you don’t need to worry about your corporate firewall, your local passwords or tracking and monitoring network traffic for PCI compliance. You really only need to make sure employees don’t actually take any payments via credit card by writing card numbers on a post-it or even using Member-owned equipment to help a consumer make a credit card payment through one of those solutions. Direct everyone to the NISC-hosted solutions using their own device to keep your office location out of scope.
- If you also take credit card payments through a Verifone paired with Cash Register or iVUE Connect, then the scope of the CDE widens to include the Verifone device. By design, the Verifone is used for capturing, encrypting and transmitting the card data – it handles all the parts of payment processing on your end. You should still physically protect the Verifone from tampering. Don’t let a card skimmer sneak in on you!
- If you use a PC on your network to allow Customer Service Representatives to log into Smarthub to setup Auto Draft, that computer and everything attached to it falls in scope and needs to be protected. That includes any accessories and peripherals, the network segment and any network device that is in or attached to that network segment including the firewall which controls access.
Requirements. Here are the 12 requirements from the PCI-DSS that you will use as the framework for controlling the size and scope of your CDE:
- Install and maintain a firewall configuration to protect cardholder data.
- Do not use vendor-supplied defaults for system passwords and other security parameters.
- Protect stored cardholder data.
- Encrypt transmission of cardholder data across open, public networks.
- Protect all systems against malware and regularly update anti-virus software or programs.
- Develop and maintain secure systems and applications.
- Restrict access to cardholder data by business need to know.
- Identify and authenticate access to system components.
- Restrict physical access to cardholder data.
- Track and monitor all access to network resources and cardholder data.
- Regularly test security systems and processes.
- Maintain a policy that addresses information security for all personnel.
Taken one at a time. Some of these don’t seem too terribly difficult, like requirement two – do not use vendor-supplied defaults for system passwords and other security parameters. Make your passwords more secure. Easy peasy.
Not soon after that, though, we meet requirement 10 – track and monitor all access to network resources and cardholder data. What? How far do we need to go to accomplish this?! Fortunately, the council provides guidance and testing procedures for each requirement and sub requirement in the PCI-DSS. Many of the requirements are built into the design of the credit card accepting solutions. This means that as long as they are implemented properly, you should be able to say YES to whether or not you are compliant with a particular requirement. Then again, many of the requirements are incumbent on you to be put in place.
The first nine or so requirements can generally be accomplished with proper implementation, and the last three or so requirements generally rely on robust daily ‘business as usual’ processes and awareness. There is overlap, but by looking at these in just a little more detail we can digest and understand the information a bit easier.
Some of the requirements do not really require action on your part due to the design of the payment application. For instance, the Verifone uses First Data’s TransArmor encryption on the card data, so you don’t have to figure out how to encrypt the data yourself. In addition, there are several questions about whether you have a policy in place to educate employees on how to recognize tampering of a device.
These are but a couple examples of what you need to do for PCI requirements using an NISC credit card payment solution. In the next installment, we will explore the Self-Assessment Questionnaire.