Diana Kelley and Ed Moyle of Security Curve review PCI compliance requirement 8: "Assign a unique ID to each person with computer access." To meet PCI compliance Requirement 8, you must:
- Give everyone with acess to cardholder data a unique ID
- Authenticate use of that ID using a strong password or two factors
Ed and Diana also review common questions that they hear when doing their QSA work, like "What about shared IDs?" or "Does a PIN and a password count as two-factor authentication?"
Watch the rest of the PCI compliance requirement videos.
Editor's note: This video is based on PCI DSS version 1.1. For updated information on the changes in PCI DSS version 1.2, see the following:
- Version 1.2 of PCI DSS answers questions, raises others
- PCI version 1.2 clarifications: How to get an early start on compliance audits
Read the full text transcript from this video below. Please note the full transcript is for reference only and may include limited inaccuracies. To suggest a transcript correction, contact email@example.com.
PCI compliance requirement 8: Unique IDs
Ed Moyle: Requirement 8: Unique IDs. Basically, in a nutshell, you give
everybody a unique ID and an identification string or value that
they have, that is unique to them. No shared IDs, no group
accounts, no 'the whole marketing department has one login that
they share or sticky tape to the monitor,' none of that stuff;
it has to be unique. One thing that we get a lot of questions
about is, 'What does it mean to be two-factor?' For
administrative, non-console access you need to have two-factor
authentication. We get a lot of questions about what does that
mean, and 'is entering two passwords, or one password twice, or
password and a pin, does that count a two-factor? Unfortunately,
no. It is what you have, what you are, what you know. Those are
the three factors for authentication. A strict reading of this
would say that that is not two-factor. You could build a case
and write some documentation about why you think that two
passwords, or a password and a pin, or whatever is, in fact, two-
factor, but your challenge would be to get your QSA to accept
that, and I personally do not. I want, when I am in an
assessment context, if it is two passwords, that is not two
Diana Kelley: In other words, you have no way to know what you are.
Ed Moyle: Right. That is what a factor is. If it was two authentication
vehicles, then it would say that.
Diana Kelley: One thing that may be a little confusing is that you may have a
token-based, one-time password, a card or a bingo card that
gives you a second number that you add in, so you may feel that
you are doing a password and a PIN with something like that, but
that gives you a 'what you have,' because now you have that
token or that bingo card that gives you that second number or
password. Those, you may feel like it is similar, but they
actually . . . Ed was talking about if you have them to use,
essentially, two things that are in their head, no.
Ed Moyle: This does not have to be expensive either. For administrative access,
if you consider something like SSH, guess what, built into SSH
is a two-factor mechanism for authentication; certificate plus
password. It is built in.
Diana Kelley: Some quick hints on the IDs. You want to have your processes,
document those, put them into place. You do need two-factor
authentication for remote access. Scope is going to help here a
lot, because it is OK to share your email address, potentially,
depending on your policy, with someone that works with you if
they need to do work for you, and this has nothing to do with
payment, like, somebody who does your scheduling, for example,
who needs control of your calendar. These are unique IDs for
accessing the payment information, so you want to Scope, again,
make sure you are talking about payment information. Having
those unique IDs there is very, very critical but do separate
it from the rest of your network because you may have businesses
requirements to share IDs for other business purposes.