By Tim Cranny
Panoptic Security Inc.
In this installment of our multipart series, we drill down on the seventh of the 12 requirements of the Payment Card Industry (PCI) Data Security Standard (DSS). We will talk about what the issues are, what merchants need to do, and what their ISOs, banks or processors can do to help them.
Requirement 7 is "Restrict access to cardholder data by business need to know." It is the first part of the section "Implement strong access control measures."
Requirement 7 is one of the more "high-level" parts of the PCI. Rather than a listing of narrow, specific technical requirements, it is more about having the right general rules in place to control access to cardholder data. While the more specific details are laid out in Requirements 8 and 9, Requirement 7 is the foundation for those details.
The essence of Requirement 7 is that the best security is preventative, not reactive. The best way to ensure that cardholder data is not compromised is to simply make sure as few people as possible have access to it.
This basic idea is often called the "need to know" or "least privilege" principle. People should be able to access the tools and information they need to do their jobs but should have no access privileges beyond that.
For example, bank managers need access to bank vaults and so should have it. But cashiers or janitors don't need that same access privilege and so should not have it.
Another key point is that it does not say security should stop people from doing their jobs. The ideal is that the least privilege principle should be invisible to people doing the right thing; it should only become visible and active when they try to do something wrong.
For instance, bank cashiers should have access to cash drawers and terminals, but security should kick in when they try to enter the bank vault, since they don't need that level of access.
Think of security privilege controls like the safety barriers on the side of a mountain road - they're always there but only interfere with traffic when something goes wrong.
Unlike some other parts of the PCI, Requirement 7 is simple to understand: There is no mystery about the purpose of the requirement, nor is there a cloud of obscure technical issues to confuse the merchant.
Like Requirements 5 and 6 (discussed in "Digging into PCI - Parts 5 and 6: Maintain a vulnerability management program," The Green Sheet, Dec. 14, 2009, issue 09:12:01), the challenge is more about having the discipline to do unexciting but necessary things before disaster strikes, as opposed to the psychologically easier task of responding to a disaster that has already happened.
Political will is often needed because merchants may need to improve (that is, change) business processes and how their employees operate. This often triggers active or passive resistance, turning supposedly simple compliance issues into political and psychological ones.
This is a rare case in which smaller organizations have an advantage over larger, more sophisticated companies. The smaller the organization, the simpler these Requirement 7 issues usually are.
For example, in the ultimate case of a one-person operation, there are no internal politics to worry about, and all these "who does what" questions simply get answered with, "I pass all these questions because there's just me, and I'm supposed to do everything."
In larger organizations, the political and organizational costs are likely to be much greater, simply because the issues are more complicated, and procrastination is a bigger danger.
One thing merchants (and their advisors) need to remember is that when this requirement discusses "access privileges," it's not just talking about accessing computer files. Any unauthorized access to cardholder data is a problem, so merchants need to take a proactive approach. Find any problems that exist and fix them, rather than take a minimalist "they didn't specifically say I had to worry about that" approach.
For example, physical access to paper records or POS devices is an issue, and I will cover it in more detail when I consider Requirement 9.
As with Requirements 5 and 6, merchants need to focus more on confronting the issues raised by Requirement 7 and doing the right thing, rather than on attempting to avoid the issue. With two main aspects to Requirement 7, there are two main sets of actions called for:
Merchants must have a formal security policy that explicitly lays out a statement of least privilege. It need not contain fancy language or be complicated (simple and obvious is better). Something along the lines of:
The merchant also needs formal processes to grant access permissions, but they don't need to be elaborate. A small organization might establish a written rule, such as, "You don't have access privileges unless your name is on the following list maintained by the manager."
That rule can then be combined with a set of rules for the manager, such as, "Only add names to this list if the person needs the access to do his or her job and seems trustworthy after a reasonable background check. Keep the list up to date; remove names of those no longer authorized as soon as possible."
Merchants need an automated access control system, which is typically much simpler than it sounds. The biggest area of concern here is controlling access to computers. All modern computers already have built-in systems for user accounts and privilege controls.
In addition, all modern payment application or POS software must have these sorts of access controls built in, and they should be fairly easy to set up and use. If merchants' payment applications or POS software do not have these sorts of controls built in, they should upgrade their systems as an urgent priority.
Again, merchants don't particularly need rescuing from technical nightmares to comply with this part of the PCI, so it should not be a significant pain point in PCI conversations.
Merchants might need assistance in liaising with vendors of payment applications, POS terminals and other PCI devices. They might also require some general advice on security and access control. ISOs can do this themselves, if they choose, but for many, it is simpler and better to partner with a security specialist as part of a broader PCI program that also deals with the other, messier, parts of the PCI DSS.
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
