Management Approval

PCI Requirement 7.1.4 states, “Require documented approval by authorized parties by specifying required privileges.” The PCI DSS explains that the purpose of documented approval, in writing or electronic, is to assure that those with access and privileges are known and authorized by management, and that their access is necessary for their job function.

PCI Requirement 7.1.4 requires that your organization retain some type of artifact that states who asked for access, if it is necessary for their job function, and if management approved this access. Before your PCI assessment, we recommend that you examine anyone with elevated privilege or access into the cardholder data environment and ensure there is management approval for that access. During the assessment, an assessor will take a sample of user IDs and the documentation which should verify that access was approved by management and the access matches their job responsibility requirements.

From a security perspective, we have this principle of data security owner and data security custodian. Typically, the owner is the management of the organization and the custodian is the IT department. We expect somebody to approve the request for access into an environment. If Betty, Tommy, or Suzie needs access to a particular asset within your organization, somebody needs to be approving that and we expect that there’s some type of artifact that you’re going to retain that says that access was asked for Tommy to be given privileges to this particular environment, and that somebody from management has approved that.

One of the things that we find from time to time is we encounter a particular staff member who pre-dates PCI DSS. What I would ask you to do is go through all of your privileged staff or those who’ve been given escalated privileges or access into the cardholder data environment, and make sure that there’s some type of management approval for those individuals to have access. From an assessment perspective, we’re going to ask for a copy of those particular request forms. Typically, we get a sample of new hire request forms, and then take that back and we look at the access privileges that actually have been assigned. Whatever has been assigned and approved based on management’s request should only be the permissions that have actually been assigned in the production environment.

Make sure you have some type of artifact where management has approved everybody’s access into the cardholder data environment or where those individuals might have privileged access.

What is PCI Requirement 7.1.3?

PCI Requirement 7.1.3 states, “Assign access based on individual personnel’s job classification and function.” Because access needs have been defined for user roles in PCI Requirement 7.1.1, it is easy to take the next step in PCI Requirement 7.1.3 and grant individuals access according to their job classification and function by using the already-created roles.

During the assessment, an assessor will, once again, get a list of all the roles, a list which individuals are in those roles, find out what permissions these particular roles need, and ensure that you are only assigning the necessary privileges to each role.

When you hire somebody within your organization, you’ve obviously hired them to perform a specific task or to fill a specific role. Requirement 7.1.3 requires that you only assign those necessary privileges based on their individual role. Once again, from an assessment perspective, we’re going to be working with your HR, get a list of all the roles, get a list of who those individuals are, talk to the management staff and find out what permissions these particular roles need, and make sure that for a role, you’re only assigning the necessary privileges to that role.

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.