PCI compliance requirement 7: Restrict access

PCI compliance requirement 7: Restrict access

Date: Jun 01, 2009

Diana Kelley and Ed Moyle of Security Curve review PCI compliance requirement 7: "Restrict access to cardholder data by business need-to-know." To meet PCI compliance requirement 7, you must:

  • Have a policy and dcoumented processes that limit who can have access to cardholder data
  • Have systems that enforce the policy

The compliance duo addresses common questions related to PCI compliance requirement 7, like "Do we need an automated access control system?"

Watch the rest of the PCI compliance videos, as Ed and Diana review each particular requirement.

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:

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 editor@searchsecurity.com.  

PCI compliance requirement 7: Restrict access

Ed Moyle: The next requirement, Requirement 7: Restrict access to

cardholder data. This is pretty intuitive. This just means that you have a

policy, documented processes, and some kind of system that enforces access

control, or restriction of access to those systems that store processes and

transmits to data. Most of the time, most likely you already had this. A

lot of folks ask, 'You mean like with the functionality that is provided by

logging into Windows and being on a domain?' Yes. Just make sure that it is

documented and that you do have the automated access control system, and

you document what that means, and so on. Most of the time, in an evaluation

context, we see that folks have this already, they just do not have the

policy around it that enforce it, that supports it.

 

Diana Kelley: Right. You can link back to your identity data stores, this

wall to help you with requirement, as well, to get policy and access

control. One 'gotcha' here that I would add is that you may have

applications that were not architected to be very granular in access

control.

 

Ed Moyle: Great point.

 

Diana Kelley: It could that all of the developers had the full blown

developer login and that they can still get to and use, even years after

that person has been deployed. Make sure that if you have applications that

are wide open, that you have taken some steps, either to re-architect the

internal access control or to put protection around, wrap them around the

application to make sure that you are really doing the access you need. The

quick hits are that you want to deal with the policy itself. There are a

lot of policies around what the rules are, who can get to what, and where,

and what you, and technical mechanisms you have in place to support that.

Another good thing is you want a default deny posture.

 

Ed Moyle: That is important, too.

 

Diana Kelley: Keep this, yes, it is traditional hardcore security, but

really, what you want is, that which is not allowed, is forbidden. Make

sure that you are opening up access as needed to users that need the pan

rather than that you got it wide open and now you are trying to firewall,

cutting people out; you want to go in a reverse direction here.

More on PCI Data Security Standard

Back to top