PCI DSS 4.0 Requirements – Restrict Access, Identify Users and Authenticate Access

Image

In the early days of computer networking, the idea of restricted permissions was shunned. Network administrators could access every system in the environment. In some extreme cases, a CEO would demand full administrative access to a network, thinking that this would protect against a rogue employee. As you can imagine, this set up a point of failure beyond logic. Fortunately, this ideology of unlimited access has waned, and many C-level executives now realize that they are high-level targets, so they appreciate that their access should be limited to only what they need to run the executive functions of the organization.

The new Payment Card Industry Data Security Standard (PCI DSS) clearly shows that unlimited access is a severe vulnerability. Requirement 7, titled, “Restrict Access to System Components and Cardholder Data by Business Need to Know”, presents detailed information about acceptable access control methods for organizations that process cardholder data.

Ben Rothke, a senior information security and risk management professional who has helped to secure the assets of many Fortune 1000 companies, and co-author of The Definitive Guide to PCI DSS Version 4: Documentation, Compliance, and Management translates this to a simple concept: “Protect the crown jewels.” Specifically, as it relates to PCI, this is the Cardholder Data (CHD). A Qualified Security Assessor (QSA) will typically ask to see how access to the Cardholder Data Environment (CDE) and CHD are restricted.

In its most basic sense, knowing the entire layout of the entire CDE is vital to understanding the extent of your scope. Ben states that “An analogous scenario that captures the importance of this requirement can be seen in the airline industry. A fully loaded 747 is ready for takeoff when they find out there is but a single piece of unidentified baggage that has been loaded. That single bag is enough to ground the entire flight.” Tyler Reguly and Funso Richard discuss some of the problems of the scoping requirements in our previous posts [LINKS] in this series.

It all comes down to the fundamental information security principles of least privileges, and need to know. As defined within the Standard, “Need to know’ refers to providing access to only the least amount of data required to perform a job, and “least privileges” refers to providing only the minimum level of privileges needed to perform a job. Following these principles improves security, lessens the chance of a data breach, and is essential to PCI compliance. Ben concludes that “firms need to use the approach of significant access restrictions. This can be a challenge over the long term, but is crucial to PCI compliance.”

As an extension to Requirement 7, Requirement 8 of the Standard focuses on knowing who is accessing the CDE. Requirement 8 directs that an organization must “Identify Users and Authenticate Access to System Components.” As an experienced information governance, cyber security, assurance, privacy, information risk and overall GRC professional, Dr. Andrea Simmons, PhD., offers the following advice for achieving compliance with this requirement:

“It is vital that we have fully documented who has access to what. Making sure that there are supporting processes for identifying and authenticating all those who are on those systems still appears to be challenging, even though system access precision has been a long-time focus in the computing industry. Liaison with your Human Resources/Personnel teams is an important element of this work to track them through the lifecycle from onboarding, to job transfers, through to termination – so that the access control lists (ACLs) as evident during assessments reflect accurate and up to date content in relation to users on the system(s). Next will be liaison with both Procurement and Project related teams – again, to ensure that those identified third parties are current and up to date and have an evident need for their noted level of access.”

Requirement 8 takes access management even further with new directives for multi-factor authentication (MFA). MFA is required for all access to the CDE. The Requirement hints that a loophole was discovered in its earlier version, where a subsequent connection to the CDE could be accomplished without MFA. The applicability notes make it clear by indicating: “If an individual first connects to the entity’s network via remote access, and then later initiates a connection into the CDE from within the network, per this requirement the individual would authenticate using MFA twice, once when connecting via remote access to the entity’s network and once when connecting via non-console administrative access from the entity’s network into the CDE.” Another addition to the new Standard also indicates that the MFA system itself must be securely configured to resist tampering or any bypass attempts.

As Dr. Simmons astutely observes, “If you consider the significant level of effort required to meet these requirements on a daily, weekly, and monthly basis, our Identity and Access Management (IAM) teams need to be more actively engaged in the end to end lifecycle management of users, with input from multiple teams. The people links in the security chain are as important as the technical ones.”

In the next part of this series, we will examine requirements 9 and 10 of the new PCI Standard. To learn even more about the new Standard, as told by other experts in the field, download our eBook.

Learn more about PCI DSS 4.0 Requirements:

PCI DSS 4.0 Requirements – Network Security Controls and Secure Configuration
PCI DSS 4.0 Requirements – Protect Stored Account Data and Protect Cardholder Data During Transmission
PCI DSS 4.0 Requirements – Protect from Malicious Software and Maintain Secure Systems and Software

PCI DSS 4.0 Requirements – Restrict Physical Access and Log and Monitor All Access

PCI DSS 4.0 Requirements –Test Security Regularly and Support Information Security with Organizational Policies and Programs