As we work through the requirements of PCI DSS, we’ve run into several calls for securing data against “unauthorized users.” Operationally, this makes sense–cardholder data should be protected against use or viewing by people that don’t have a reason to do so. However, any effective IT security system must have a method to ensure that only authorized individuals access resources. This is what the seventh requirement of PCI DSS 4.0 addresses–restricting access to system components and cardholder data. 

What Is Access Control?

Access control is the practice of setting up rules, logic, and control mechanisms to ensure that only authorized users access system resources. In contrast, unauthorized users are provided limited or no access at all. 

Within that discipline are several different layers of controls that can be broadly classified into different categories–namely:

Authentication

Authentication is checking a user’s credentials against authorized identities to grant access to that system. Authentication emphasizes determining a user’s identity through different types of credentials:

• Knowledge: Credentials of knowledge refer to what we often think of when we think of authentication. That is usernames and passwords, or PINs.
  
• Ownership: Credentials of ownership refer to things we have (ideally) sole access to as proof of identity. These credentials include one-time passwords (OTPs) sent to SMS devices, email accounts, or OTPs generated through authentication apps.
  
• Inherence: Credentials of inherence are what we are. More precisely, inherence refers to the use of biometrics. This can include fingerprints, facial recognition scans, or iris scans. 

The use of two or more of these categories is called Multi-Factor Authentication (MFA).
 

Authorization

Authorization is the process of vetting users as they attempt to move through or access different system data, assets, or resources. Unlike authentication, which determines correct identity, authorization uses system-based access rules based on roles, responsibilities, system variables and other criteria to determine if a user is authorized to do whatever they are doing. 

Identity Management

Identity management involves creating, storing, and securing online identity information in databases for identity verification, authentication, and authorization purposes.

The combination of identity management, authentication, and authorization essentially powers what’s known as Identity and Access Management (IAM) and, more specifically, access control.

What Is the Principle of Least Privilege?

Outside methodological and technical aspects of access control, many security frameworks (including PCI DSS 4.0) call for specific philosophical approaches to proper authorization. One of these, and one referred to in the seventh requirement for PCI DSS, is the Principle of Least Privilege (PoLP). 

Simply put, the (PoLP) states that any user must have only the minimum access privileges necessary to accomplish their tasks and no more. This philosophy, in many ways, includes concepts like the need to know (only accessing data the user needs to know) or role-based separation of responsibilities. However, the principle of least privilege goes beyond even these approaches by addressing access based on given tasks–that is, even if a user with a role that expects access to certain types of data might have that privilege limited if they don’t need that access to do their job.

What Is the Seventh Requirement for PCI DSS 4.0?

The seventh requirement of PCI DSS 4.0 focuses on access control and the steps an organization must take to secure system resources against unauthorized access. This includes the technologies used to control access and the procedures and policies that define how those technologies are implemented.

7.1 – Processes and Mechanisms for Restricting Access

• Documentation: As with any other requirement, the seventh expects that your organization has clearly defined and documented access controls policies and procedures. This can include hierarchy charts, privileges for roles, and privileges based on tasks and responsibilities.
  
• Roles and Responsibilities: Speaking of roles and responsibilities. Perhaps in this requirement more than others, having a clear understanding of roles, responsibilities, data access, and system privileges are crucial for success.

7.2 – Defining Access Controls to System Components and Resources

• Access Control Models: Your organization should include an access control model that can support system access-based user interaction with business needs, specifics of job classifications and job functions, and within the consideration of the PoLP.
  
• Roles and Access Controls: Assignment of access controls should be assigned to the users based on the model, adhering to the Principle of Least Privilege and only granting access based on the requirements of your model.
  
• Approvals: Any users receiving access privileges must do so only with approval from authorized personnel. This includes access for internal users and those associated with third-party vendors or contractors.
  
• Reviews: All user access privileges should be reviewed at least once every six months to ensure that privileges align with roles and responsibilities, address inappropriate access, and sign off from management that the previous criteria are met. This should, ideally, automatically happen any time users are onboarded or terminated from the organization.
  
• Least Privilege: All access controls for application and system access should follow the PoLP necessary for operability and in no other way or location outside that condition. This can include ensuring that users and groups don’t have access to elevated privileges, restricting access from specific locations, restricting hours of use to business hours, or other approaches.
  
• Query Access: These access restrictions should also apply to any program-assisted access to database cardholder data (i.e., through queries in a program or controlled access via software). This also means restricting direct access to databases to administrators.

7.3 – Implementing and Managing Access Controls to System Components and Resources

• Implementation: Access controls should operate strictly on a need-to-know basis (for data access), based on roles within the organization (for resource and application access), and otherwise restrict access to anyone else by default.

Prepare for PCI DSS 4.0 with Lazarus Alliance

As we dig into the requirements of PCI DSS, you will see the increasing complexity and interoperability of the different technologies, policies, and practices you’ll need to deploy to receive PCI verification and maintain compliance. These practices aren’t just to complete a checklist. However–they are tried-and-true security practices that will help support your security efforts ten years from now. 

Are You Thinking Ahead for PCI DSS 4.0?

Call Lazarus Alliance at 1-888-896-7580 or fill in this form.