As most realize by now, compliance with the PCI DSS is difficult. Unlike other security-focused regulations, such as HIPAA and SOX, much of the PCI DSS is highly prescriptive. Whereas many other regulations define high-level controls without much technical implementation guidance, the PCI DSS usually defines acceptable parameters for required controls with comparatively intricate technical detail.
This introduces a compliance challenge for merchants and service providers, because prescriptive controls leave relatively little interpretive latitude for scenarios that are outside the norm (i.e., scenarios that are not be envisioned by the standard). But, the opposite case -- less prescriptive requirements -- introduces its own set of challenges. In that case, rather than an organization being boxed in when dealing with outlier scenarios, organizations must determine for themselves how to address the requirement technically, bearing in mind that different assessors may interpret the requirements differently . While this latter situation is less common with PCI DSS compliance, it does occur.
PCI DSS requirement 7 ("Restrict access to cardholder data by business need-to-know") is one example of a situation where the standard is less technically prescriptive than in other areas. As such, requirement 7 can be one of the harder sections for organizations to address because they must decide for themselves how to technically implement the controls.
Requirement 7 in a nutshell
The intent of PCI requirement 7 is pretty straightforward: It's designed around the idea that the fewer people with access to resources, the fewer opportunities there are for those resources to be compromised. This includes access both to the data itself, as well as to the systems that store, process and transmit that data. The requirement specifies measures to ensure organizations manage and govern user access according to the principle of least privilege -- defining (and approving) which personnel need what levels of access to do their jobs, and limiting access within systems to only the minimum required.
As far as the specifics go, requirement 7 has two components: a policy component outlined in sub-requirement 7.1, and a technical one defined in 7.2. On the policy side, 7.1 requires an organization maintain a written data control policy that specifically limits access -- both to systems and data -- according to need-to-know. More specifically, 7.1 requires businesses address a few specific policy areas as mandated by its sub-requirements: privileged IDs (e.g. Administrators) [7.1.1], privileges that are based on job function/role [7.1.2], documentation of management approval [7.1.3], and automated access control [7.1.4]. From a technology perspective, the standard requires an automated access control system that addresses all system components [7.2.1], assigns privileges based on role [7.2.2], and defaults to "deny" (no access) [7.2.3].
The intent of this should be clear, but -- as many merchants have experienced firsthand -- there are a number of different ways that this can be implemented in practice.
Meeting the standard
So what do merchants and service providers do when seeking to address this requirement? The PCI compliance policy side of the requirement defined in 7.1 should be straightforward. You'll want to make sure you have a data control policy that's documented and addresses all the required points called out under 7.1. To that end, the policy should have clear, easy-to-locate, unambiguous statements for all access control procedures and concerns, including privileged IDs, least privilege, RBAC, approval flow and the automated access control systems in use. (Careful, there may be more than one . For example, if you use a Windows domain at corporate, and standalone UNIX servers at retail stores, your policy needs to be broad enough to address both areas, or you need to have two different policies to ensure both areas are touched upon.)
Moreover, it's advantageous to have one-to-one mapping between what's required by the standard and the actual policy statements. For organizations that need to go through an annual assessment, this is particularly important: Requiring a QSA to sit down and search for these statements in the entire body of your corporate policy is like asking him or her to look for a needle in a haystack. So, knowing that a QSA can only evaluate your policy statements to the extent that he or she can find them, having a map or index is helpful to make sure the assessor is looking in the right place.
From a technology standpoint, it's important that you meet the technical requirements outlined by the standard in section 7.2, namely, default deny and coverage across all components. During implementation, some firms don't fully appreciate the fact that "all system components" doesn't just mean the point-of-sale (PoS) terminal, OS or payment application alone. Instead, this means what it says: all system components, for all systems in scope. This implies a potential overlap between different access control systems at a technical level.
For example, an n-tier application may have different sets of users/roles/privileges at each tier. There may be access control at the operating system level (e.g., Windows authentication), at the database level (e.g., Oracle authentication), and for the application itself (e.g., controls implemented by the application vendor). The technical implementation of the requirement must address each of these levels, for each of the required areas: privileged ID's, default deny, role based permissions, etc. The plus side is that, for most of these system components, access control functionality will be natively built in to the technology in use; the downside is that you will need to account for each system component individually, as well as account for how all the components fit together at a technical level.
For merchants and service providers -- whether validating via annual assessment or submitting a self-assessment questionnaire -- it pays to address this requirement in an organized and thorough way; particularly because the technical implementation isn't spelled out as specifically as in some of the other PCI DSS requirements.
About the author:
Ed Moyle is currently a manager with CTG's Information Security Solutions practice, providing strategy, consulting, and solutions to clients worldwide as well as a founding partner of SecurityCurve.
This was first published in March 2011