Demonstrating PCI DSS 4.0 Compliance with Veza's Identity Security Platform

Executive Summary

As organizations transition to PCI DSS 4.0, managing access control and demonstrating compliance has become increasingly complex. Veza’s identity security platform provides comprehensive capabilities to meet these challenges, particularly in addressing crucial access control requirements and periodic access reviews.

Introduction

PCI DSS 4.0 introduces enhanced requirements for access control, user identification, and monitoring. This whitepaper explores how Veza’s platform can help organizations meet these requirements effectively.

PCI Control Requirements

Veza’s platform, which focuses on identity security, access control, and resource-level permissions, can significantly aid in meeting several PCI DSS 4.0 requirements related to access control and least privilege. The specific PCI control requirements that are particularly relevant will be outlined below.

Access Control Requirements

Requirement 7: Restrict Access to System Components and Cardholder Data

Requirement 7.1: Define, document, and implement access control policies and procedures.
Requirement 7.2: Implement an access control system(s) for systems and components.
Requirement 7.2.1: Ensure access to system components and data is restricted to only those individuals whose job requires such access.
Requirement 7.2.4: Assign access based on individual personnel’s job classification and function. NOTE: Given the criticality and consistent audit scrutiny this control often receives, more details on this requirement will be further detailed in a later section.
Requirement 7.2.5: Implement least privileges for user IDs and other identifiers, allowing only the necessary privileges for their job responsibilities.

Requirement 8: Identify Users and Authenticate Access to System Components

Requirement 8.2: Implement multi-factor authentication for all user access into the cardholder data environment.
Requirement 8.6: Where other authentication mechanisms are used, these must be assigned to an individual account and not shared among multiple accounts.

Monitoring and Review Requirements

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data

Requirement 10.1: Implement audit trails to link all access to system components to each individual user.
Requirement 10.2: Implement automated audit trails for all system components.

Requirement 12: Support Information Security with Organizational Policies and Programs

Requirement 12.4: Ensure security policies and operational procedures for restricting access to cardholder data are documented, in use, and known to all affected parties.

Periodic Access Reviews

Requirement 7.2.4 in PCI DSS 4.0 specifically addresses the need for regular access reviews. This periodic review requirement is a critical component of the principle of least privilege, which is a cornerstone of effective access control. By regularly reviewing and adjusting access rights, organizations can:

Minimize the risk of unauthorized access to sensitive data
Reduce the potential impact of insider threats
Ensure compliance with the “need-to-know” principle
Adapt access controls to reflect organizational changes and staff turnover

Implementing robust processes for these periodic access reviews is essential for maintaining a strong security posture and complying with PCI DSS 4.0 requirements. The new standard defines clear expectations for access review programs:

This requirement is considered a best practice until March 31, 2025, after which it becomes mandatory.
Organizations must perform reviews of user accounts and access privileges at least once every six months.
These reviews should include all user accounts, including those of vendors and other third parties.
The purpose is to ensure that access remains appropriate based on the user’s job function and current role.
Any inappropriate access must be removed or adjusted to align with the user’s current responsibilities.
The review process must be formally documented and signed off by authorized parties.

Veza’s platform automates this critical process. Through its automated access review capabilities, organizations can efficiently conduct and document these mandatory six-month reviews, ensuring comprehensive coverage across all user accounts and access privileges. The platform streamlines the review workflow, from initial access discovery to final documentation and sign-off, significantly reducing the time and effort required for compliance.

Implementation Details

Follow these steps to build a sustainable access review process:

Establish a formal process for conducting these semi-annual reviews.
Create a comprehensive inventory of all user accounts and their associated access privileges.
Develop a matrix that maps job roles to appropriate access levels.
During each review, compare current access against the role-based access matrix.
Identify and rectify any discrepancies, such as excessive privileges or outdated access.
Maintain detailed records of each review, including findings and actions taken.
Obtain formal sign-off from appropriate management or security personnel.

Separation of Duties (SoD)

While Separation of Duties (SoD) is not explicitly called out as a standalone requirement in PCI DSS 4.0, it is an important principle that is embedded within several requirements. SoD relates to PCI DSS 4.0 in a number of areas, some of which have already been outlined above. This section specifically links the controls to the context of SoD:

Requirement 6.4.2 – Separation of Development and Production Environments

This requirement specifically addresses SoD in the context of development and production environments:

Production and test/development environments are separated, and the separation is enforced with access controls.

This separation helps ensure that development activities do not impact the security of the production environment.

Requirement 7.2.4 – Access Control

This requirement mandates that access to system components and data is restricted to only those individuals whose job requires such access. It states:

Access to system components and data is appropriately defined and assigned. Access is assigned based on:

– Job classification and function

– Least privileges necessary to perform job responsibilities

This inherently supports the concept of SoD by ensuring that individuals only have access to what they need for their specific job functions.

Requirement 7.2.5 – Least Privilege

Least privileges are implemented for user IDs and other identifiers (for example, service accounts), including for users, administrators, and all other types of accounts on all system components, as follows:

– Only the privileges necessary for the user’s job function are assigned.

– Access is restricted to only the data, commands, or resources necessary for the user’s job function.

This requirement supports SoD by ensuring that users only have the minimum access necessary to perform their job functions.

Requirement 8.6.1 – Shared Accounts

If shared or generic accounts or other shared authentication credentials are used, their use is managed as follows:

– Use is prohibited unless necessary to the business.

– Use is limited to the extent necessary for business needs.

– Use is managed in accordance with the entity’s policies and procedures.

– Accountability for use is maintained.

This requirement helps enforce SoD by limiting the use of shared accounts, which can blur the lines of individual accountability.

Requirement 10.2.1 – Audit Logs

Audit logs are enabled and active for all system components and cardholder data.

While not directly about SoD, robust logging and monitoring support the principle by ensuring that all actions are traceable to specific individuals, which is crucial for maintaining effective separation of duties.

By implementing these requirements effectively, organizations can establish and maintain proper Separation of Duties within their cardholder data environment. Veza’s platform can significantly aid in implementing and maintaining these SoD-related controls by providing visibility into access patterns, automating access reviews, and helping to enforce least privilege principles across various systems and applications.

How Veza Enables Compliance

Veza’s platform streamlines PCI DSS compliance while providing deeper visibility into access relationships across your environment through a number of core capabilities.

Providing visibility into “who can take what action on what data,” which is crucial for implementing least privilege access.
Offering the Veza Access Graph, which captures access metadata from all enterprise systems, enabling real-time answers to access-related questions.
Supporting privileged access monitoring, allowing organizations to visualize and control data access across all systems.
Enabling non-human identity management, which helps in untangling the complex web of cloud IAM and understanding true permissions of all identities, including service accounts.
Facilitating SaaS access security, which is important for monitoring all apps, seeing the reality of permissions, fixing risky posture, and staying compliant.
Providing capabilities for cloud access management, helping organizations know exactly who can do what across various cloud environments.

Organizations can more effectively implement, monitor, and maintain the access controls required by PCI DSS 4.0, thereby enhancing their overall security posture and compliance efforts.

Compliance Assurance Example Queries and Reports

Based on Veza’s Access Graph capabilities and the PCI DSS 4.0 requirements, below are some practical examples of queries that can help demonstrate compliance with specific control requirements. Veza’s platform includes out-of-the-box PCI dashboards that provide continuous visibility into access patterns and compliance status across in scope PCI systems. The platform’s query capabilities extend beyond basic reporting to enable proactive compliance monitoring, such as detecting unauthorized access paths to sensitive data environments, identifying outdated access privileges, and validating separation of duties requirements.

Requirement 7.2.1 – Restrict access to system components and data

Query: Show all users with access to cardholder data tables in our Snowflake database

This query would leverage Veza’s granular visibility into database permissions, helping identify any users with unnecessary access to sensitive data.

Requirement 7.2.4 – Assign access based on job classification and function

Query: List all marketing department employees who have delete permissions on production S3 buckets

This query combines identity information (department) with access data (S3 permissions) to identify potential misalignments between job roles and access rights.

Also related to this control, the following query can help with periodic access reviews:

Query: Show all access possessed by Okta user Gary Ward

This type of query provides a comprehensive view of a user’s access across multiple systems, facilitating thorough access reviews.

Requirement 7.2.5 – Implement least privileges

Query: Recommend least privilege role for user Amber to access the customer table in DataBricks with read-only permissions

This example demonstrates Veza’s ability to suggest roles that provide necessary access with minimal additional permissions, supporting least privilege implementation.

Requirement 8.2 – Implement multi-factor authentication

Query: Show me all Entra AD users without MFA enabled who can delete Salesforce objects

This query combines identity provider configuration data (MFA status) with cloud infrastructure permissions, highlighting high-risk accounts that lack proper authentication controls.

Requirement 10.1 – Implement audit trails

Query: Display all AWS IAM roles connected to AWS service principals

This query helps in tracking non-human identity access, which is crucial for maintaining comprehensive audit trails.

Separation of Duties (SoD)

Query: Identify users with both ‘approver’ role in Zendesk and ‘submitter’ role in Coupa

This query helps detect potential SoD violations across different applications, supporting compliance with SoD principles.

Dormant account detection

Query: List all AWS IAM users who haven’t accessed any resources in the last 90 days

This query combines access data with activity monitoring to identify potentially unnecessary accounts, supporting overall access hygiene.

These queries demonstrate how the Access Graph can provide the detailed visibility and analysis capabilities needed to meet various PCI DSS 4.0 requirements, particularly those related to access control, least privilege, and periodic reviews. By leveraging this granular access data, organizations can more effectively manage their compliance efforts and improve their overall security posture.

Conclusion

The transition to PCI DSS 4.0 represents a significant evolution in access control and identity security requirements. Organizations face increasing complexity in managing access across hybrid environments while maintaining compliance with these enhanced standards. Veza’s identity security platform provides the comprehensive visibility, control, and automation needed to meet these challenges effectively.

As the deadline approaches for mandatory implementation of these new requirements, organizations should begin planning their compliance strategy now. Veza’s platform offers a foundation for not only meeting current PCI DSS 4.0 requirements but also establishing sustainable access governance practices that will serve organizations well into the future.

Demonstrating PCI DSS 4.0 Compliance with Veza’s Identity Security Platform

Executive Summary

Introduction