A Thing
The Green SheetGreen Sheet

The Green Sheet Online Edition

February 08, 2010 • Issue 10:02:01

Digging into PCI - Part 8:
Assign a unique ID to each person with computer access

By Tim Cranny
Panoptic Security Inc.

This installment of our multipart series drills down on the eighth of the 12 requirements of the Payment Card Industry (PCI) Data Security Standard (DSS). The article discusses what the issues are, what merchants need to do and what their ISOs, banks or processors can do to help them.

Requirement 8 is "Assign a unique ID to each person with computer access." It is the second part of the section called "Implement Strong Access Control Measures." The first part of that section (Requirement 7) laid out the high-level principles for controlling who gets access to sensitive cardholder data and systems. But Requirement 7 is deliberately short on details about what merchants should actually do and how to do it.

Requirement 8 plugs that gap when it comes to computers; it contains a long list of specific technical requirements on how to implement access control. The other main area of access control issues, physical security, is covered in Requirement 9.

What Requirement 8 is all about

The core idea behind Requirement 8 is that before you can control access, you first need to be certain who is trying to gain access. To use an analogy, there's not much value in having 10 bouncers at the front door of a nightclub with a detailed list of invited guests if a 60-year-old man can walk up and say, "I'm Paris Hilton. Let me in," and then be admitted.

Recognizing and "authenticating" people is not the same as access control, but it is the foundation of access control. And since modern computer systems can do access control naturally and easily once the authentication piece is taken care of, authentication has become the primary issue in most peoples' minds.

Requirement 8 is all about making sure that when someone tries to get access to a computer resource (a file or a program, for example) that relates to cardholder data, the system knows specifically who the person is claiming to be and can be reasonably confident that the individual is actually the person he or she purports to be.

The challenges of Requirement 8

This requirement is fairly technical. Despite that, it is usually not as problematic as other sections of the PCI DSS, mainly because most merchants are aware of the issues and the solutions, and also because many of the requirements are in the "Do it once, properly" vein rather than the more painful "Be sure to do this every day." Not all parts of Requirement 8 are like that though; important parts of it need regular attention and updating. Requirement 8 is also simpler than Requirement 7 in that it is less likely to trigger staff complaints or resistance; the issues are almost purely technical, rather than social, political or cultural.

What merchants need to do

To comply with Requirement 8, merchants need to ensure that they use passwords (or a suitable replacement like fingerprint scanning) carefully and completely. None of the individual requirements are particularly difficult or obscure. They include such steps as the following:

  1. Make sure each user has a unique identifier. (Typically this means that all users have their own accounts on computers, and/or individual accounts for accessing applications). The idea is that you must avoid things like having an account called "cashier" that all cashiers share; you need to be able to monitor and control access at an individual rather than group level.

  2. Make sure passwords are required for all access to sensitive systems or data.

  3. Ensure that passwords are long enough to be reasonably strong and changed often enough to prevent problems. (The rationale for changing passwords is that they become "stale" if kept too long, giving attackers time to find or guess them. Not all security experts agree, but it is part of the PCI DSS that passwords be changed every 90 days.)

  4. Carefully manage passwords and accounts to make sure they are only created for authorized users; that they are promptly disabled when no longer needed (for example, when staff are reassigned or terminated); and that passwords are themselves protected like the sensitive information they are, since there isn't much use in having a password if it can be reset by an attacker or read by strangers off a piece of paper or e-mail.

    One requirement that will be less familiar to most merchants is the requirement that "two-factor authentication" be used for remote access (that is, logging on to computers or applications off-site). Two-factor authentication basically means using passwords plus something else to prove who you are; the "something else" could be a fingerprint, retinal scan, or a physical device like a smart card or dongle.

    Using something else in addition to a password makes the authentication much stronger, which is a reasonable goal because allowing remote access is riskier than allowing on-site access only. The right approach to this issue is to prohibit remote access unless there is a clear and unavoidable need for it. As with all security concerns, avoiding the problem in the first place is the best route.

    Some Requirement 8 particulars, like setting a minimum password length or enforcing automatic screensavers, are generally "Do it once, properly" issues. Others, like ensuring that old accounts are disabled, are necessarily an ongoing process and should be built into the company's standard operating procedures.

    Because meeting these requirements depends in part on the behavior of payment applications used by merchants, it is just one of many reasons why merchants should make sure they are using certified systems.

    What you need to do for your merchants

    Most of the issues raised by Requirement 8 are fairly familiar to merchants. As such, this requirement will typically be a low-pain part of a general PCI awareness and compliance program. ISOs and others should spend most of their effort and time on making sure that their programs can deal with the technical demands and support burdens of other, more challenging and painful, parts of PCI. end of article

    Dr. Tim Cranny is an internationally recognized security and compliance expert and is Chief Executive Officer of Panoptic Security Inc. ( www.panopticsecurity.com). He speaks and writes frequently for the national and international press on compliance and technology issues. Contact him at tim.cranny@panopticsecurity.com or 801-599-3454.

    The Green Sheet Inc. is now a proud affiliate of Bankcard Life, a premier community that provides industry-leading training and resources for payment professionals. Click here for more information.

    Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.

    Prev Next
A Thing