Welcome back to our ongoing series on the Payment Card Industry Data Security Standard (PCI DSS) requirements. Having covered the first six requirements in detail, we now turn our attention to Requirement 7. This requirement is a critical component of the PCI DSS that has undergone significant changes from version 3.2.1 to the latest version 4.0.
Requirement 7 focuses on implementing strong access control measures. It specifically mandates the restriction of access to system components and cardholder data based on a business need-to-know basis. This is to ensure that critical data is only accessible by authorized personnel, thereby enhancing the security posture of organizations handling sensitive payment information.
In this blog post, we will explore the detailed sections and overviews extracted directly from PCI DSS v4.0. We aim to provide insights into processes and mechanisms for restricting access, defining and assigning access to system components and data, and managing this access via robust control systems. So, let’s get started! To learn more about the other requirements of PCI DSS, check out our comprehensive guide on the “12 requirements of PCI DSS.”
Note: These requirements do not apply to consumers (cardholders)
- 7.1: The procedures and methods for limiting access to system components and cardholder data, based on a business’s need-to-know basis, are clearly outlined and comprehended.
- 7.2: The allocation and definition of access to system components and data are carried out appropriately.
- 7.3: The management of access to system components and data is conducted through a designated access control system.
We will also delve into the potential risks associated with unauthorized individuals gaining access due to ineffective access control rules and definitions. Furthermore, we will clarify terms like “Access” or “access rights”, “Need-to-know”, and “Least privileges” to provide a clear understanding of their roles in securing sensitive information.
Please note that these requirements do not apply to consumers (cardholders). They are intended for businesses that handle cardholder data.
| Old Requirement (v3.2.1) - 7.1 | Updated Requirement (v4.0) - 7.2.1, 7.2.2, 7.2.3 |
|---|---|
| - In this version, access to system components and cardholder data was a privilege, not a right. It was only given to those individuals who needed it to do their jobs. - Each role had its own defined access needs. This included the system components and data resources that each role needed for their job function, and the level of privilege required for accessing these resources (7.1.1). -When it came to privileged user IDs, access was kept to a minimum. It was restricted to the least privileges necessary to perform job responsibilities (7.1.2). - Access wasn’t given out willy-nilly. It was assigned based on individual personnel’s job classification and function (7.1.3). -And lastly, required privileges weren’t just handed out. They were documented and had to be approved by authorized parties (7.1.4). | - This requirement is all about granting access based on what’s needed for the business, the job classification and functions of the users, and the least privileges required to perform a job function. - Access isn’t just given out to anyone. It’s assigned to users, including those with privileged access, based on their job classification and function, and the least privileges necessary to perform their responsibilities. - And it’s the same as before. Required privileges must be approved by authorized personnel. It’s all about making sure that the right people have the right access. |
The updated requirements seem to provide more detailed guidelines on how to implement and verify the access control models and privileges.
| Old Requirement (v3.2.1) - 8.7 | Updated Requirement (v4.0) - 7.2.6 |
|---|---|
| - It wasn’t a free-for-all. In fact, all access, whether by applications, administrators, or any other users, was strictly restricted. - But how did users interact with the databases? Well, all user access, queries, and actions on databases were done through programmatic methods. No manual meddling allowed. - And who could directly access or query databases? Only database administrators had that privilege. - What about application IDs for database applications? They could only be used by the applications themselves, not by individual users or other non-application processes. It’s all about keeping things secure and orderly. | - Now, all user access to query these repositories is restricted. It’s only possible via applications or other programmatic methods, and the access and actions allowed are based on user roles and the principle of least privilege. - But who can directly access or query these repositories? Only the responsible administrators have that privilege. The updated requirement also introduces two sub-requirements: - 7.2.6.a: This one’s all about verification. Policies and procedures need to be examined, and personnel interviewed, to make sure that processes are defined for granting user access to query repositories of stored CHD. And this must be in accordance with all elements specified in this requirement. - 7.2.6.b: This sub-requirement is about checking the configuration settings for querying repositories of stored CHD. These settings need to be examined to verify that they’re in accordance with all elements specified in this requirement. |
The changes seem to provide more detailed guidelines on how to implement and verify the restrictions on access to stored CHD. The move from Requirement 8 to Requirement 7 appears to be done for better alignment with the content in Requirement 7.
New Requirements:
Requirement 7.1.2:
Staff handling sensitive access need to know their exact job and what’s expected of them. (This requirement is effective immediately for all v4.0 assessments.)
- Formally document access control task assignments for sensitive data.
- Delegate these tasks to appropriate staff members.
- Verify staff members’ understanding of their responsibilities through interviews.
Requirement 7.2.4:
Regularly check that user accounts and permissions are appropriate to prevent unauthorized access. (This requirement is a best practice until 31 March 2025.)
- Perform bi-annual reviews of user accounts (including vendors).
- Ensure access aligns with roles, adjusting it if needed.
- Obtain official sign-off for appropriate access. Implement clear policies and maintain records of review outcomes.
Requirement 7.2.5:
Limit access for application and system accounts to reduce security risks. (This requirement is a best practice until 31 March 2025.)
- Restrict programs and systems to minimal required access.
- Limit account interactions to necessary system parts.
- Establish clear guidelines for account creation and access management.
- Regularly review access rights and communicate with staff to ensure compliance.
Requirement 7.2.5.1:
Regularly review access rights for system and application accounts to make sure they remain appropriate and secure. (This requirement is a best practice until 31 March 2025.)
- Frequency of access reviews depends on risk analysis findings.
- Confirm minimal access during reviews, addressing excessive access promptly.
- Obtain official approval for correct access rights.
- Document policies, risk analysis, and review results.
Conclusion:
The transition from PCI DSS v3.2.1 to v4.0 has significantly enhanced data security by providing more specific and detailed guidelines for access control. The new version emphasizes restricting access to stored cardholder data (CHD) based on user roles, least privileges, and programmatic methods.
It also underscores the role of responsible administrators in directly accessing or querying CHD repositories. This shift reduces ambiguity and aids organizations in implementing more effective security measures. Consequently, PCI DSS v4.0 represents a substantial improvement over v3.2.1 in terms of clarity, specificity, and overall security.
For more insights and detailed discussions on PCI DSS and other data security topics, please visit our website at VISTA InfoSec and explore our range of informative blogs and we help organizations to comply with regulations. Your understanding of compliance with these standards is crucial in today’s digital age. Stay informed, stay secure!
Lets us help you
Need help navigating PCI DSS v4.0? We have been active in the PCI DSS space since 2008 and even certify payment brand. Our PCI DSS services provide assurance on card security controls, with offerings for both product platform and backend services attestation.
We have a dedicated team of auditors and a separate team for consulting/advisory assignments to even help our esteemed clients to define processes and achieve compliance.
We have completed multiple PCI DSS 4.0 certifications too right from scoping to Readiness Assessment, Advisory and Final Certification.
We are vendor neutral and have a strict no-outsourcing policy. We can also assist you with the technical assessments needed for PCI DSS Compliance – Vulnerability Assessment, Penetration Testing, Network Segmentation Testing, Network Architecture Review, Firewall Assessment, Secure Configuration Assessment, Web and Mobile Application Security Assessment, and Secure Code Review.
