3

I am attempting to ascertain the boundaries of personally identifiable information.

For example does the combination of John and Doe equate to personally identifiable information since there could be several thousand John Does?

My understanding of Personally Identifiable Information (PII) is when an individual (not deceased) can be sufficiently identified. So if I had the name John Doe plus a social security number or email address, it would be deemed as Personally Identifiable Information.

In the context of PCI-DSS, are there specific requirements in the storage, transmission, destruction, utilization of such data?

Motivated
  • 1,493
  • 1
  • 14
  • 25

3 Answers3

5

I am attempting to ascertain the boundaries of personally identifiable information.

That is a legal question, and varies by jurisdiction. Perhaps the best known is California:

(a) The term “personally identifiable information” means individually identifiable information about an individual consumer collected online by the operator from that individual and maintained by the operator in an accessible form, including any of the following:

(1) A first and last name.

(2) A home or other physical address, including street name and name of a city or town.

(3) An e-mail address.

(4) A telephone number.

(5) A social security number.

(6) Any other identifier that permits the physical or online contacting of a specific individual.

(7) Information concerning a user that the Web site or online service collects online from the user and maintains in personally identifiable form in combination with an identifier described in this subdivision.

Later case law has added zip code to the list.

In the context of PCI-DSS, are there specific requirements in the storage, transmission, destruction, utilization of such data?

The only overlap between PCI-DSS and PII is the cardholder name. The PCI DSS does not concern itself with PII; it concerns itself with "Account Data", which consists of the following elements:

PCI DSS 3.1 "Applicability Information"

Certain PII elements that may be included in credit card processing, such as billing address and zip code (you may have had to enter your billing zip at a gas station?) are not even mentioned by the PCI DSS. And even for the one clear overlap, the cardholder name, it's fair to say that one's management of the data may be fully PCI compliant but egregiously lacking compliance with applicable PII regulations. You should not consider PCI controls when determining if you are protecting PII correctly.

Following up to comment:

Are there defined controls in protecting PII that also overlap with PCI-DSS controls?

The problem is that PII laws are punitive rather than prescriptive. They define what PII is and state who is responsible for handling it correctly. They don't define how to handle it correctly; they indicate what sorts of results a correct handler provides and state that failing to provide those results indicates a violation of the law.

The PCI-DSS, on the other hand, is much more prescriptive. It goes into some detail as to the protections expected. It doesn't say what encryption you need to use, but it says you need to use encryption for this and that and correct encryption has to meet reasonable standards.

Could PCI-DSS controls be used to apply to PII data? Sure... you could treat PII as if it was PAN (Primary Account Number) data; make sure it's encrypted whenever stored, etc. etc. However, you'll probably have more trouble because the use cases for PII are different than for PAN; with PAN, you pretty much need to send it to the processor and that's about it. With PII, you may have lots of employees needing to reach in and look at it for one reason or another (customer support? snail mail campaigns? data analytics?) and those people will either be inconvenienced by the encryption, or the protection around the encryption will be weakened by the increased number and variety of access.

There are many criticisms of the PCI-DSS, but perhaps its best defense is, "It's better than nothing." It's a standard, it's imposed by the card brands, and it lays down an acceptable minimum of security controls. There's no equivalent document for PII - all the more so because PII is so jurisdiction-dependent.

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
3

I will take a different approach to this answer. Gowenfawr, and SilverlightFox provided excellent answers from the textbook/guideline perspective, so I will tackle answering your "John and Doe equate to personally identifiable information since there could be several thousand John Does" portion. Many portions of current PII laws, come from inference attacks. Decades ago, there was a lot of military discussion about the security of its soldiers data. Consider the following:

FNAME   GENDER  AGE CURRENT_LOCATION    TITLE
JAMIE   F       22  NYC                 NUCLEAR_OPERATOR
JAMIE   M       27  NYC                 CHEF

If you came across this data, as an attacker, you would know which is a more important target. You'd search for a woman named Jamie, who appears to be 18-25. You may further refine your search to someone who seems "structured" (hair in a bun, serious demeanor). You had information to build on. Government/military sought out to build systems to protect against these kinds of searches. (It makes sense). They have built, and deployed videos training many military personnel about PII which can be viewed here, and is explained in detail. (slide 3 explains inference to an extent).

So when you state: "There could be several thousand John Does" imagine if we lived in Smalltown USA, where population is 30, how many John Does do you think we could possibly find there? Same applies to most places nowadays. Because of the influx of data everywhere (Spokeo, Facebook, LinkedIn, etc) it is much simpler to pull off inference attacks using simple data (Jamie example above). "John Doe Smalltown USA" is enough to identify an individual. (Re-identification). Now as far as requirements are concerned, this all depends on your state/country/business. For example, if you operate an online business, your rules will differ from someone in Smalltown USA running a coffee shop. Many organizations have moved to tokenizing names, telephone numbers, zip codes, etc.

munkeyoto
  • 8,682
  • 16
  • 31
1

From Wikipedia:

[PII] is information that can be used on its own or with other information to identify, contact, or locate a single person, or to identify an individual in context.

Therefore I'd agree with your premise of PII being defined as having enough information in order to uniquely identify someone.

Under PCI-DSS everything is looked at in the context of cardholder data. If such data is held about a credit or debit card then it is in scope for PCI. Other information about individuals that are not associated with card details, PCI doesn't really care about.

If such data is associated with cards then should your system transmit, process or store this data then it must be PCI compliant. The current version of PCI DSS is v3.1. Account data that must be kept secure under PCI is as follows:

Cardholder Data:

  • Primary Account Number (PAN)
  • Cardholder Name
  • Expiration Date
  • Service Code

Sensitive Authentication Data:

  • Full track data (magnetic-stripe data or equivalent on a chip)
  • CAV2/CVC2/CVV2/CID
  • PINs/PIN blocks

And according to Comodo:

Cardholder data is any personally identifiable data associated with a cardholder. This could be an account number, expiration date, name, address, social security number, etc. All personally identifiable information associated with the cardholder that is stored, processed, or transmitted is also considered cardholder data.

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
  • Thanks SilverlightFox. When you say if such data is held in the context of credit or debit cards, to what extent especially if the credit card information is masked and what does it mean in terms of scope in the storage, transmission, utilization and destruction? – Motivated Apr 12 '16 at 09:02
  • Answer updated. – SilverlightFox Apr 12 '16 at 10:26