GS Logo
The Green Sheet, Inc

Please Log in

A Thing
View Archives

View PDF of this issue

Care to Share?


Table of Contents

Lead Story

Do banking silos hinder fraud prevention?

Patti Murphy
The Takoma Group

News

Industry Update

Is online PIN debit more secure?

Social networking meets the POS

Illuminating the compliance highway

Features

Research Rundown

Selling Prepaid

Prepaid in brief

Prepaid expo showcases speakers, regs

How prepaid cards assist in disaster relief

Making the case for disaster relief cards

Views

A PIN for all reasons

Scott Henry
VeriFone

Merchant training:
Competitive advantage, potential game-changer

Biff Matthews
CardWare International

Education

Street SmartsSM:
Gain traction on the red carpet

Jon Perry and Vanessa Lang
888QuikRate.com

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

Tim Cranny
Panoptic Security Inc.

Clarify your brand and use it

Peggy Bekavac Olson
Strategic Marketing

Selling and giving to specialized markets

Jeffrey Shavitz
Charge Card Systems Inc.

Going alternative

Caroline Hometh
Payvision

Company Profile

Vesdia Corp.

New Products

Separation of powers

iPA280
Ingenico

Going out made easy

TabbedOut
ATX Innovation Inc.

Inspiration

Make everyone your valentine

Departments

Forum

Resource Guide

Datebook

A Bigger Thing

The Green Sheet Online Edition

February 08, 2010  •  Issue 10:02:01

previous next

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

By Tim Cranny

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.

    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.

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

    previous next

Spotlight Innovators:

North American Bancard | USAePay | Super G Capital LLC | Humboldt Merchant Services | Impact Paysystems | Electronic Merchant Systems