Where do PCI-DSS and PII intersect?
Learn the best practices for developing a security awareness training program that is engaging. Engaging awareness programs have been shown to change more users’ behavior and are seen as an asset for your organization instead of annoyance.
In this article we will learn about the how Personal Identifiable Information (PII) falls under PCI scope, what is new in PCI-DSS v3, what the various categories of PII are and what all PIIs comes under PCI-DSS.
Payment Card Industry Security Standards Council (PCI SSC) had developed a standard known as PCI Data Security Standard (PCI DSS), which comprises 12 core security areas to protect credit card holder data from theft, misuse, etc. These requirements apply to all entities involved in payment card processing, including merchants, processors, and 3rd party service providers that store, process and transmit cardholder data. PCI DSS originally began as five different programs:
- Visa’s Cardholder Information Security Program
- MasterCard’s Site Data Protection
- American Express’ Data Security Operating Policy
- Discover’s Information Security and Compliance
- JCB’s Data Security Program
The motive of the above listed companies was to protect the card holder by providing some guidelines to merchants or any other entity which is involved in storing, processing and transmitting cardholder data. From the above listed companies, a PCI Security Standards Council (SSC) was formed, and the first version of PCI DSS 1.0 was released in December 2004. Because of rapid changes in technology, new mode of payments, attack vectors, regulatory laws, etc., this version got back to back updates from 1.1 to 1.2. PCI subsequent versions 2.0 and 3.0 were released in October 2010 and November 2013 respectively.
PII is Personal Identifiable Information, which can be used to identify an individual’s identity; such as name, Social Security Numbers, and biometric records. PII scope is big and PCI-DSS covers only a part of it. We will see what PCi-DSS all covers. Below are examples of PIIs:
- Date of Birth
- Cell Phone Number
- Email Address
- Biometric records
- Social Security Number
- IP address
- Log in accounts.
- Vehicle Identification Number
- Credit Card Information
- Health Records
- Passport Number
- Bank Account Number
In the next section, we will see what PII lifecycle is and what specific requirements of PCI-DSS map with the PII lifecycle
As stated above, PCI-DSS standard was formed to prevent card related fraud/theft etc. So PCI-DSS covers only the PIIs that are related to payment card. However, the scope of PCI-DSS includes merchants, processors, service providers as well as all the entities that store, process and transmit payment card data. No when we say payment card data, it actually has 2 more classifiers namely:
Cardholder data: This includes:
- Permanent Account Number(PAN)
- Cardholder Name
- Card Expiration Date
- Service Code
As stated above, every entity that store transmits or process payment card data is under PCI-DSS scope.
Sensitive Authentication Data: This includes
- Full data in magnetic strip or chip
- Card PIN/Card PIN blocks
- CVC/CVC2 etc.
The first stage of PII lifecycle is collection. This involves collection of PII data from end-user. Since PCI-DSS deals with PII related to cardholder data, this involves the secure collection of PII data through Websites, Point of Sale, physical, Service provider etc.
- PCI-DSS clearly mentions to use secure channel between website and end-user using technologies like TLS, IPsec etc.
- For Point of Sale (POS) systems as well, PCI –DSS laid down guidelines around POS monitoring.
- Requirement 9 of PCI-DSS laid down requirement around physical access to cardholder data.
- PCI-DSS also established certain standards for third party service providers that have the business need to access cardholder data.
Some of the requirements that clearly define how Cardholder data (listed above) should be handled once it is inside the system:
Requirement 3.3: “Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see the full PAN.”
Requirement 3.4 “Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches:
- One-way hashes based on strong cryptography, (hash must be of the entire PAN)
- Truncation (hashing cannot be used to replace the truncated segment of PAN)
- Index tokens and pads (pads must be securely stored
- Strong cryptography with associated key-management processes and procedures”
What we can infer from both these requirements is that Cardholder data is allowed to store even if it contain PAN but PAN should not be readable.
Requirement 4.2: “Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat, etc.).”
This requirement is actually to create awareness among end-users not to share their PAN over emails, IMs, chat etc. as these channel if not properly protected can be sniffed very easily.
Requirement 3.2: “Do not store sensitive authentication data after authorization (even if encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process.”
Wat we can infer from this is that sensitive authentication data is not allowed to store even if it is encrypted/unreadable.
PCI-DSS also covers the aspect of securing the transmission of confidential data to other channels and providers.
Requirement 4.1: “4.1 Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC,SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks, including thefollowing:
- Only trusted keys and certificates are accepted.
- The protocol in use only supports secure versions or configurations.
- The encryption strength is appropriate for the encryption methodology in use”
In this guidance for this requirement PCI-DSS mentions to use TLS v 1.1 or later for use as other versions of SSL and TLS are susceptible to attacks.
PCI-DSS standard clearly specifies that whichever system that contains the cardholder data will be under PCI-DSS scope. For backup also, the cardholder data must be stored in secure form like encrypted, tokenized etc. In addition, the physical access to these backup systems must be monitored and these backup systems must have strict access controls build around them. In short, these Backup systems must have the same secure policies that are involved in usual cardholder data environment.
Instead of destroying the data, PCI-DSS clearly says to store only that data which has a business purpose. Moreover as we have seen above, it does not even permit to store sensitive card authentication data. The only requirement where PCI-DSS mentions to delete the data is when the data is moved to production and the samples used in testing must be deleted.
As we can see that PCI-DSS covers only one aspect of PII i.e. payment cards data and not all aspects of PII.
PII preventive practices
However, some of the best PII best preventive practices include:
- Know what type of PII is being used in the systems: This includes the need to identify the type of PII that are being collected, stored and processed.
- Ensure that the entities collecting, storing and processing PII are governed under regulations/compliances and are secure
- Create awareness programs among employees and restrict access to PII on need to know basis.
- Ensure that all the PII stored is in encrypted form.
- Deploy a monitoring solution around the PII environment.
- And the best of all, if you do not need the PII, do not store the PII.
So we have seen in this article that PII coverage is big and PCI-DSS do ensure PII coverage but only what is related to Cardholder data.