The PCI DSS is a set of data security standards that anyone who handles payment card information must abide by to protect sensitive cardholder data in the event of a breach.
Though the principles of PCI DSS and the total set of PCI DSS requirements are somewhat complex, an important subset of the requirements pertain to data encryption and tokenization. Since these two data security techniques are widely used, all companies that handle large quantities of cardholder data should be aware of them. Failure to abide by them can not only put cardholder data at risk but also subject merchants to fines.
Learn the differences between tokenization and encryption and the PCI DSS requirements for them here.
Encryption and Tokenization
Tokenization and encryption are two methods of keeping sensitive customer data safe by preventing unauthorized access to it. Global Payments Integrated maintains that the answer to keeping sensitive payment data safe is a multi-pronged approach incorporating EMV, QIR, encryption, tokenization and more.
Encryption involves passing bits of data through a function called an encryption key, which then turns the data into ciphertext. Ideally, the only way to convert the ciphertext back into the original text is with a decryption key which only authorized parties will have access to. Ultimately, encryption is designed to devalue sensitive data so that it is unreadable or unusable if compromised. Tokenization replaces cardholder data with digital “tokens.” Sensitive data is stored in the secure Global Payments Integrated token vault rather than in the merchant environment.
Tokenization vs. Encryption: Compliance Concerns
With proprietary encryption services from Global Payments Integrated, cardholder data is rendered unreadable, encrypted at the device. Merchants are unable to view card numbers after the swipe, dip or hand-key. In addition, payment applications are rendered out-of-scope with EdgeShield, eliminating cumbersome PCI validation requirements.
Merchants looking to store sensitive data for card-on-file or recurring billing solutions can also utilize tokenization to reduce the security and PCI burden on the organization. With tokenization, all sensitive data is stored in an off-site medium, platform or cloud vault. The token data that is present is without value to attackers for they would be required to pass additional security checks before they could exchange the tokenized data for the true data.
PCI DSS for Tokenization
The following list of PCI DSS requirements and guidelines for tokenization systems is taken directly from the official statement of the PCI DSS Tokenization Guidelines:
- Tokenization systems must not provide primary account numbers (PANs) in response to any application, system, network or user outside of your strictly defined cardholder data environment (CDE). Your customers’ PANs must be kept utterly secret at all costs, with no one but those who absolutely need to see them (such as those working in a call center who may need the number for verification purposes) allowed any access to them. If any aspect of your system is able to provide a PAN to any other part upon request, this enormously increases the chances that the PAN will leak out and that unauthorized parties will get it. This must not be allowed to happen.
- All parts of your tokenization system must be located on secure internal networks that are sealed off from any other networks that are either not set up to meet PCI DSS requirements or are generally untrusted. They must be set to reject all suspicious and unverified traffic. There are a number of ways to do this, including segmenting your network to wall off in-scope from out-of-scope subnets, installing VPNs or implementing zero-trust network security strategies.
- Only trusted communications are permitted to move from inside to outside the CDE, and vice versa. All untrusted traffic is to be rejected, and security protocols must exist to deal with such traffic when it is detected.
- If you plan to store cardholder data locally, you must encrypt all of it with a strong, industry-tested cryptographic algorithm like the AES-256. If you must transmit the information over open or public networks, it must also be encrypted with some such algorithm.
- As demanded by PCI DSS Requirements 7 and 8, all tokenization systems must have strong and reliable authentication and access control measures in place. Specifically, all access to cardholder data is to be doled out on a strictly need-to-know basis (Requirement 7), and each of those who are given access to cardholder data must have unique identifiers (Requirement 8). This will make it easier to detect anyone who is not meant to access the data.
- The tokenization system must meet general network configuration and security standards to make it safe from cyberattacks.
- As dictated by PCI Requirement 3.1, all unnecessary cardholder data must be deleted from your systems at least quarterly. Your tokenization system must include a data retention policy that specifies a procedure for doing this.
- The tokenization system must log and monitor all traffic passing through the network. This will make it easier to detect suspicious traffic. When suspicious traffic is detected, there must be a procedure in place to alert network security professionals to deal with it.
Payment security is paramount for any ISV that processes payments within their software as well as for their merchants. There are important PCI DSS requirements that every ISV must meet. Failure to meet them can mean not only harmful data breaches that damage your relationship with your customers but also accumulating fines for both the ISV and merchant.
Meeting these requirements can be a tricky and demanding business. Thankfully, Global Payments Integrated is here to help you meet them all with ease.
Contact us today to learn more about our security solutions that combine encryption, tokenization, EMV, QIR, and more.