PCI DSS 4.0: A Primer

April 12, 2022

• The Payment Card Industry is releasing the newest version of the PCI DSS – version 4.0.
• The framework supports flexibility and unique/customized methodologies used to achieve security.
• It allows tailored validation procedures and methods for unique or customized security solutions.
• This post discusses how v4.0 keeps PCI DSS current, relevant and effective to combat emerging threats and technologies.

What Is PCI DSS 4.0?

The Payment Card Industry Data Security Standard (PCI DSS) is an information security framework that applies to any organization that processes, stores and transmits cardholder data. These organizations include merchants, service providers, payment processors, cloud providers (PaaS, Iaas, SaaS), banks, credit unions and the payment brands. PCI DSS evolved from each card brand’s independent cardholder security framework. A governing body, the PCI Security Standards Council (PCI SSC), was created and is responsible for the maintenance and update of the PCI DSS. In March 2022, the PCI SSC released the newest version of the PCI DSS – version 4.0.

The PCI SSC set four objectives for the 4.0 standard:

Let’s look at each of these objectives and how they make version 4.0 current, relevant and effective in today’s challenging information security environments.

Meeting Security Needs

To say technology is always changing is an understatement. Securing that technology and data is more vital than ever, especially in the payments industry. The PCI DSS framework was created for the implementation of security controls on PCI-scoped systems – that is, the servers, network devices, databases and applications that store, process or transmit cardholder data. The security controls also apply to supporting systems, such as backup, user access, virus control and audit logging. The PCI DSS framework is designed with six security objectives, and within those, 12 separate requirement areas. While the objectives outline the security goal (e.g., building and maintaining secure networks and systems), the requirements drill down into those firewalls, routers and servers, and define how they are to be hardened, restrict unauthorized traffic and keep their operating systems current. Requirements are also directed at how these systems should not be operating – with insecure protocols, multiple roles per server or vendor default passwords.

Image

The requirements as written are based on information security best practices that have been standard for years. The challenge for any security framework is maintaining a static set of security controls in an ever-changing technology world. The PCI SSC has updated the PCI DSS framework in multiple versions, each reflecting changes to technologies and their incorporation into cardholder payments and merchant environments.

PCI DSS 4.0 adds new requirements to address emerging technologies. Previous versions were not designed for the current IT landscape, which includes cloud computing, virtual and containerized computing and passwordless authentication. Version 4.0’s new requirements and enhancements bring some of these new technologies into the PCI framework, and is structured to address evolving risks and threats to payment systems and cardholder data.

While the 12 core PCI DSS requirements remain fundamentally the same, all requirements are redesigned to focus on security objectives, and there is a new validation option that gives more flexibility to organizations using different methodologies to meet the intent of PCI DSS requirements.

Customizing the Security Solution or Procedures

All previous versions of the PCI DSS included the six security objectives (e.g., protect cardholder data), but maintained specifically worded requirements that direct how companies were to achieve those goals. In other words, the standard is extremely prescriptive. Business entities must meet the requirement as written or address the requirement through the alternate means of a compensating control – a set of additional procedures that requires the organization to go above and beyond the intent of the primary control itself. For many companies, defining an alternate set of security controls and constantly maintaining them is both burdensome and time-consuming. Previously, if the entity did not meet the requirement as written, or meet it through a compensating control, the requirement was found noncompliant, resulting in failure of a company’s PCI compliancy posture.

PCI DSS 4.0 does keep the existing prescriptive method for compliance and allows the use of compensating controls. However, PCI DSS 4.0 requirements have been expanded with an alternate option: the customized implementation.

Customized implementation considers the intent of the objective and allows entities to design their own security controls to meet it. Once an organization determines the security control for a given objective, it must provide full documentation to enable their qualified security assessor (QSA) to make a final decision on the effectiveness of a control.

But, doesn’t this sound similar to a compensating control?

It is similar, in that both the compensating control and customized implementation use alternate means to meet the intent of the requirement, but don’t perform the control as written. The major difference is that a customized implementation does not require a business or technical justification. An organization can implement a customized implementation for most requirements, and for any reason. A compensating control generally arises from a deficiency and is defined by a technical or business constraint.

Most organizations will use the standard approach of meeting the PCI DSS requirements as written. But the customized implementation provides the flexibility to address individual requirements and security controls that lie outside of the written definition. Nonstandard or proprietary technologies or methods may be defined through the customized implementation, with a detailed test plan documented by the organization and validated by their QSA.

Customizing Testing and Validation

For organizations wishing to use customized implementation, there are some considerations that need to be addressed.

If the customized implementation approach is selected for a particular requirement, the organization will need to develop a detailed test plan that outlines how the alternate approach meets the security objective of the requirement. The plan should be detailed to include the technologies used and any customized configurations of the systems or applications. They should also document the expected output or resolution of the control. The test plan will need to be repeatable, as the QSA will conduct each step, receive the expected output or resolution and then measure that result against the stated security objective of the requirement. Organizations will need to work with their QSA to determine the best approach for any proposed customized implementations.

Business-As-Usual Security

Organizations that implement business-as-usual (BAU) processes as part of their overall security strategy are taking measures to ensure that the security controls used to secure their cardholder data environment continue to be implemented correctly and functioning properly as normal course of business. The PCI DSS has always maintained certain requirements that act as BAU processes through monitoring security controls, periodic review and follow-through on anomalies. However, for many companies, the BAU processes were conducted at the scheduled interval and only at the scheduled interval. The control was being met; however, the entire focus was meeting the point-in-time compliance of the PCI assessment. Compliance is not something that happens once per year. Compliance should be year-round, 24 hours per day, which derives from making security posture a constant part of daily business operations.

PCI DSS 4.0 has restructured many of the requirements to change the focus to security as a continuous process. The requirements that mandate controls be conducted at scheduled intervals still exist, but the guidance in the PCI DSS 4.0 standard extends to the purpose (intent) of the requirement, along with good practices, security definitions and examples on how the control can be met. It encourages organizations to look beyond the minimum frequency to meet the control and to expand their security understanding and response, so that whether automated or manual, the controls are performing as expected. Regardless of whether a PCI DSS requirement is automated or manual, it is important for BAU processes to detect anomalies, alert and report so that responsible individuals address the situation in a timely manner.

How can organizations begin incorporating PCI DSS into their BAU activities?

One key to both implementing PCI DSS into BAU processes and conducting the customized integration is to perform a risk assessment to determine the potential impact to PCI DSS scope. For organizations that select customized integration, PCI DSS 4.0 requires a targeted risk assessment for each requirement using the approach. The targeted risk analysis must focus on the specific PCI DSS requirement(s) and explain how the organization assessed the risk and determined that the customized control meets the objective of the PCI DSS requirement. The organization’s QSA will also review the targeted risk assessment as part of their review of the customized implementation test plan.

Outlook

The 4.0 update is a major improvement for payment processors, merchants and service providers that handle cardholder data. By framing the standard to meet emerging security needs, promoting flexibility for emerging technologies, allowing a customized approach for organizations to meet PCI DSS requirements and by promoting security as a continuous process, PCI DSS 4.0 is well positioned to meet both the current and future technology and security challenges in a strong, efficient manner.