PCI Compliance Every Day – Requirement 7

Restrict Access to Cardholder Data by Business Need to Know

As mentioned in our primer blog post for this series (PCI Compliance Every Day), with the release of PCI Data Security Standard (DSS) v3.2, the PCI Security Standards Council (SSC) introduced the concept of business as usual (BAU). BAU is meant to embed those relevant PCI DSS requirements into the business operations of organizations.

This post focuses on PCI DSS requirement seven; restricting access to cardholder data and in-scope system components based on the “need to know” and/or the principle of “least privilege.” “Need to know” as defined in the PCI DSS is “when access rights are granted to only the least amount of data and privileges needed to perform a job.”

While “need to know” is sometimes viewed as synonymous with “least privilege,” the exact terminology of each are still debated – to a degree. The intent of both, however, is to limit access rights (authentication and authorization) only to those which are absolutely necessary for a specific role – as defined by the organization. For the purposes of this post, users should only be able to access data, systems and execute functions absolutely necessary for their job role.

The sub-heading for requirement seven in the PCI DSS states: 

“To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities.” 

PCI DSS requirement seven focuses on defining job classifications and functions, assigning system roles based on those classifications and functions, approving and validating the access levels assigned, and ensuring any access outside of those parameters default to a “deny all” configuration.

It’s important to understand section seven requirements do not apply solely to individuals (reminder – that’s both internal staff and third parties), but also to applications and their related service accounts, which often possess broad or privileged access and use non-expiring credentials.

The BAU frequencies we’ll primarily focus on in this post are “as needed” and “annual,” although other frequencies and conditions may be referenced to provide additional context (e.g. significant changes). This post also illustrates the cross-over between these two frequencies as they pertain to procedures for creating and managing access rights, which organizations should define for themselves based on the size and/or complexity of the environment.

As-Needed BAU Activities for Requirement 7

The frequency of “as-needed” can be viewed a few different ways and can cover an array of activities (and crosses over to support the PCI DSS’ notorious “significant change” term). The “as needed” frequency should be defined by an organization’s risk assessment, but should occur at least annually since the controls must be assessed annually. Organizations should be prepared to account for the items in the list below when deploying new systems and applications, implementing changes in organizational structure (e.g. data owner shifts), or building new business processes interacting with PCI cardholder data (CHD) and sensitive authentication data (SAD) in new ways. Organizations also should ensure these activities include third-party relationships where access roles could be defined for on premise (e.g. remote connections in) and off-premise (e.g. cloud, private VPN). On an “as-needed” basis, organizations should perform the following access control tasks to support a BAU model:

• Define access needs and privilege assignments for each role to include both data and system components (7.1.1).
• Restrict access to privileged user IDs to specific roles and enforce least privileges necessary to perform job responsibilities (7.1.2).
  • Example 1 – A server administrator may not need administrative access to all servers/systems.
  • Example 2 – A network administrator may not need administrative access to firewall devices and/or a capability to modify rule sets/access control lists.
  • Example 3 – Database administrators (DBA) may not always need full administrator rights if they do not maintain the DBMS software and only deal with schemas, tables and DBMS related errors.
• Grant access rights to an account based on job classification and function (7.1.3).
• Document the approval (electronically or in writing) by someone authorized to do so and record a listing of the specific privileges approved (7.1.4).
• Publish any necessary changes to policies and standards governing access controls for system components and/or data (7.1, 7.3).

Annual BAU Activities for Requirement 7

During an organization’s annual PCI assessment, compliance with requirements in section seven will be validated by the assessor, but samples and evidence will reach back in time over the previous year to demonstrate compliance with these requirements were sustained and continue to be in place. Also remember that a designation of “annual” means that this is the minimum allowed and that your risk assessment may dictate that some or all of these controls may have to be tested/assessed more often. As mentioned earlier, performing these activities on a recurring basis and collecting the right evidence along the way will ease the assessment process.

• Ensure policies and standards for access controls incorporates enforcement of requirements 7.1.1 – 7.1.4 (7.1).
• Review user accounts to verify each accompanying role defines system components and data resources the job function should have access to as well as the level of privilege required (7.1.1).
• Verify user accounts with privileged access have been properly approved and are still required based on the users' job role/functions (7.1.2).
• Verify access rights assigned to user accounts have been properly approved and are still required based on the users' job role/functions (7.1.3).
• Ensure all in-scope system components have an access control system for controlling user accounts, roles and privileges (7.2.1).
  • Recommended: Maintain this information and include how access is granted (e.g. locally, AD, LDAP, TACACS, etc.) in a PCI inventory (2.4).
• Ensure access control mechanisms and supporting documentation illustrate how account privileges are aligned to job classification and function (7.2.2).
• Ensure all access control mechanisms include a default setting of "deny-all" that is applied, for example, when adding new accounts (7.2.3).
• Ensure all personnel involved with account management for in-scope system components are aware of, understand, and enforce the governing security policies and standards for account and rights management (7.3).

Increasing BAU Frequency for Requirement 7

How often organizations feel compliance with these requirements should be validated internally is largely dependent on the size and complexity of the environment as well as driven by the results of the organization’s risk assessment. As a reminder, that internal validation must coincide with the frequency and evidence expectations of the PCI DSS in order to be leveraged for annual assessments. Implementing a process to review access controls (authentication and authorization) for all in-scope system components and PCI data on a quarterly or even monthly basis may be more appropriate for some. The decision to adjust frequencies and perform internal validation checks should take both risk and cost into account and any internal BAU program should collect [proper] evidence along the way as it could be used in an annual assessment when assessors deliver their sample sets. Modeling and executing this the right way can reduce risks inherent with access control and ease the assessment process.

Permission/Entitlement Creep and Thinking beyond Requirement 7

The activities outlined in this post also will help organizations identify and correct, or altogether avoid, permission creep and inappropriately assigned access rights. Permission/entitlement creep can be defined as a condition where a user retains access rights assigned in a previous role, project or other activity where entitlements were changed or added and often takes place when personnel change roles within the same organization.

Implementing access review processes to focus on what the account can authenticate to, and what rights the account has after authentication, can help identify other challenges with access control. Some examples include identifying where default accounts may still exist and be active (PCI DSS requirement 2.1), where shared or generic accounts are being used (PCI DSS requirement 8.5) and if any unused or unneeded accounts still exist (PCI DSS requirements 8.1.4, 8.1.5). Watch for our future posts covering those PCI DSS requirement sections to learn more.