What is PCI Requirement 7.1.2?

Within your organization, you will obviously have personnel who require an elevated level of privilege. You will have some personnel with more responsibility than others, but you still need to limit the ability for someone to impact the security of the cardholder data environment. PCI Requirement 7.1.2 requires you to limit access to privileged user IDs to personnel who truly require it for the function of their job. PCI Requirement 7.1.2 states, “Restrict access to privileged user IDs to least privileges necessary to perform job responsibilities.” The PCI DSS explains, “When assigning privileged IDs, it is important to assign individuals only the privileges they need to perform their job (the “least privileges”). For example, the database administrator or backup administrator should not be assigned the same privileges as the overall systems administrator.”

During the assessment, assessors will be looking for an explanation of why these roles or individuals have an elevated level of privilege. Assessors will also interview the personnel responsible for assigning access to determine if access to privileged user IDs is given only to those who specifically require such access and if access is restricted to least privileges necessary.

Within your organization, you’re going to have people, obviously, that are going to be responsible or have an elevated level of privilege. This might be everyone from the systems administration staff to your call center managers. For any of those accounts that would have the ability to impact somebody else’s experience or perhaps impact the security of the cardholder data environment in any way, or really all of those administrative accounts, we want to limit those accounts to only those individuals who truly require that.

From an assessment perspective, we’re going to talk to management staff and get a list of what those accounts are and look at any privileges that have been assigned to those roles. If those roles need that privilege, that’s fine. Basically, we’re looking for an accounting of why these roles or individuals would have access to those particular accounts.

How to Define Access Needs for Each Role

PCI Requirement 7.1.1 outlines the first step in the process of establishing role-based access controls. PCI Requirement 7.1.1 states, “Define access needs for each role, including: system components and data resources that each role needs to access for their job function, and level of privilege required for accessing resources.”

The PCI DSS states, “In order to limit access to cardholder data to only those individuals who need such access, first it is necessary to define access needs for each role (for example, system administrator, call center personnel, store clerk), the systems/devices/data each role needs access to, and the level of privilege each role needs to effectively perform assigned tasks. Once roles and corresponding access needs are defined, individuals can be granted access accordingly.” An assessor will expect that you define access needs for each role within your environment, then define the specific permissions that each individual needs. Then, an assessor will examine a sample of jobs/roles and their access control needs.

PCI Requirement 7 also talks about establishing role-based access controls. It’s expected that you define the roles within your environment and then define the specific permissions that each individual needs. Then, an assessor will find all places where individuals would have access and look at those systems to make sure that those systems have the capability of supporting the roles that you’ve defined within your organization.

Why Limit Access to System Components and Cardholder Data?

We’ve discussed least privileges before (See PCI Requirements 2.2.2 and 3.1) and the concept of, “If you don’t need it, get rid of it.” PCI Requirement 7.1 also follows this idea. PCI Requirement 7.1 states, “Limit access to system components and cardholder data to only those individuals whose job requires such access.” If someone’s job needs access to function, grant it. But if they can function without it? Deny access.

So, why should your organization limit access to system components and cardholder data?  The PCI DSS states, “The more people who have access to cardholder data, the more risk there is that a user’s account will be used maliciously. Limiting access to those with a legitimate business reason for the access helps an organization prevent mishandling of cardholder data through inexperience or malice.” Implementing PCI Requirement 7.1 within your organization further protects cardholder data.

During a PCI assessment, an assessor will ask for a list of all job roles within your organization and the responsibilities that fall under each job. An assessor will question which data each job has access to, and why this data is essential to their job. Your organization’s policies and procedures will also be examined to determine compliance with PCI Requirement 7.1. Policies and procedures for access control should incorporate the four sub-requirements of PCI Requirement 7.1, which include:

  • 7.1.1 – Define access needs for each role, including: system components and data resources that each role needs to access for their job function, and level of privilege required for accessing resources.
  • 7.1.2 – Restrict access to privileged user IDs to least privileges necessary to perform job responsibilities.
  • 7.1.3 – Assign access based on individual personnel’s job classification and function.
  • 7.1.4 – Require documented approval by authorized parties specifying required privileges.

Once again, the PCI DSS calls out least privileges. If you don’t need it, get rid of it. The other side of that is where you do need access, it’s absolutely appropriate to give individuals access. PCI Requirement 7.1 says that we limit the access into the environment to that which is necessary for a job to function. As part of this requirement, we’re going to be asking for a list of all of your roles and their responsibilities. We’re then going to ask, “What is the data that they’re going to be viewing as part of their roles?” We’re going to speak to management staff and ask management, “Why does Johnny, Betty, Suzie, or Tommy actually need to view this data?” If it’s part of their job and they absolutely need it, there’s nothing wrong with that. Let’s give them the access, but we need to make sure it’s secure. However, where there are individuals within your organization that don’t truly need to view cardholder data or have access to it, we expect that cardholder data access has been removed.

Protecting Cardholder Data

PCI Requirement 7 focuses on establishing access into your organization’s cardholder data environment through the lens of business need to know. PCI Requirement 7 states, “Restrict access to cardholder data by business need to know.” Complying with PCI Requirement 7 is critical to ensuring that cardholder data is accessed only by authorized personnel. There’s nothing wrong with granting someone access to the CDE and the PCI DSS does not define which personnel should receive access. If access is required for a job, grant it. The PCI DSS, though, does define “need to know” as, “…when access rights are granted to only the least amount of data and privileges needed to perform a job.”

In this set of PCI Requirement 7 videos, we will discuss the systems and processes that must be in place to limit access based on business need to know. We will cover the following PCI Requirement 7 sub-requirements:

  • 7.1 – Limit access to system components and cardholder data to only those individuals whose job requires such access.
  • 7.1.1 – Define access needs for each role, including system components, data resources, and level of privilege.
  • 7.1.2 – Restrict access to privileged user IDs to least privileges necessary to perform job responsibilities.
  • 7.1.3 – Assign access based on individual personnel’s job classification and function.
  • 7.1.4 – Require documented approval by authorized parties specifying required privileges.
  • 7.2 – Establish access control that covers all system components.
  • 7.2.1 – Establish access control that covers all system components.
  • 7.2.2 – Establish access control to assignment of privileges to individuals based on job classification and function.
  • 7.2.3 – Employ default “deny-all” setting.
  • 7.3 – Ensure that security policies and operational procedures for restricting access to cardholder data are documented, in use, and known to all affected parties.

When we look at PCI Requirement 7, it is focused on establishing access into your environment based on a business need to know. If somebody needs access to data, there’s no problem with giving that. There’s nothing that prohibits you from defining who gets what access. What’s required of this particular requirement is that you define role-based access controls and you establish the access into your environment based purely on business need to know.

Documentation Requirements

PCI Requirement 6 pairs with PCI Requirement 5 to satisfy vulnerability management program expectations. PCI Requirement 6 states, “Develop and maintain secure systems and applications.” The purpose of this requirement is to build a process for securely managing the software within your environment. For this requirement, we’ve discussed the 18 sub-requirements and topics such as how to securely develop applications, common coding vulnerabilities, and how to ensure your applications are protected. Complying with PCI Requirement 6 will protect your organization’s applications from being susceptible to threats and vulnerabilities. But, as we’ve learned, it’s not enough just to learn and talk about these things. All policies, procedures, and standards must be implemented in order to comply with PCI Requirement 6.7.

PCI Requirement 6.7 states, “Ensure that security policies and operational procedures for developing and maintaining secure systems and applications are documented, in use, and known to all affected parties.” This is not only saying that your organization needs to maintain documented security policies and operational procedures; the policies and procedures need to be known and in use by all relevant parties. Your personnel must be implementing what the policies, procedures, and standards require of them. It is a requirement of this framework that the affected parties use the policies and procedures. It is not sufficient that you generate documentation just for the sake of the audit. Your assessor should be reading these documents, familiar with the policies and procedures, and interviewing staff to make sure that anybody who is subject to the policies and procedures understands what they are. If PCI Requirement 6.7 is not met, your systems and applications will be left vulnerable.

Once again, we come to the capstone for Requirement 6. You need to maintain a documentation program. The documentation must be fully documented, in use, and known to all affected parties. From an assessment perspective, we’re going to be looking at your paperwork, reviewing your SDLC and policies, and interviewing your staff to make sure that they understand and have applied the policies as you’ve defined them for your organization.