PCI compliance requirement 7: Restrict accessDate: 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:
- 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 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
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.