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:

 

  1. The framework needs to continue meeting the security needs defined by the payments industry. This includes new and emerging technologies.
  2. The framework should support flexibility and unique/customized methodologies used to achieve security.
  3. The framework should allow tailored validation procedures and methods for unique or customized security solutions.
  4. The framework should set an expectation that security is considered a continuous process.

 

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
PCI DSS 40_img1

 

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.

 

  • First, they need to fully understand the requirement. PCI DSS 4.0 standard provides the definition of the requirement and provides a separate customized approach objective. This outlines what the customized implementation must address to meet the intent of the requirement.
  • Second, the organization needs to determine if they’re already following the requirements as written. There’s no need to reinvent the wheel for a control that’s already being met.
  • Lastly, if the standard approach is not being met, the organization should consider whether the control processes they have implemented or plan to implement are suitable to meet the stated security objective of the requirement.

 

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?

 

  • Assign overall responsibility and accountability for PCI DSS compliance to an individual or team. This can include a charter defined by executive management for a specific PCI DSS compliance program and communication to executive management.
  • Develop performance metrics to measure the effectiveness of security initiatives and continuous monitoring of security controls. These include network security controls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), change-detection mechanisms, anti-malware solutions and access controls.
  • Create exception reporting of logged data and review more frequently to gain insights into trends or behaviors that may not be obvious with simple monitoring.
  • Detect and respond promptly to security control failures. The response should include:

    • Restoring the security control
    • Identifying the cause of failure
    • Identifying and addressing any security issues that arose during the failure of the security control
    • Implementing mitigation, such as process or technical controls, to prevent the cause of the failure from recurring
    • Resuming monitoring of the security control, perhaps with enhanced monitoring for a period of time, to verify the control is operating effectively

 

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.

Brett Perry
Senior Consultant II | Optiv
Brett Perry brings nearly 25 years of experience in consulting and systems engineering. He has provided critical IT security guidance to clients ranging from small businesses to Fortune 500 corporations across a multitude of industries. His extensive experience as a subject matter expert in the Payment Card Industry - Data Security Standard (PCI-DSS) has allowed him to work across a wide range of business types, including retail operations, service providers, ecommerce and card brands, helping them to secure and protect their cardholder data.

Prior to joining Optiv, Brett was a senior security consultant for a PCI qualified assessment company (QSAC), where he spent 15 years conducting both onsite assessments as a QSA and performing quality assurance reviews on peer Reports on Compliance. Brett also brings IT security experience as a former senior systems engineer and Microsoft solutions network implementer.

Optiv Security: Secure greatness.™

Optiv is the cyber advisory and solutions leader, delivering strategic and technical expertise to more than 7,000 companies across every major industry. We partner with organizations to advise, deploy and operate complete cybersecurity programs from strategy and managed security services to risk, integration and technology solutions. With clients at the center of our unmatched ecosystem of people, products, partners and programs, we accelerate business progress like no other company can. At Optiv, we manage cyber risk so you can secure your full potential. For more information, visit www.optiv.com.

Related Insights

Image
CPI_Risk_PCI_ServiceBrief_Images_List-Section-Thumbail-Image_476x210

 

Payment Card Industry (PCI) Advisory Services

 

Our PCI Advisory Services can build around your specific context, helping you to untangle competing requirements from multiple regulations.

Image
generic_list_476x210

 

PCI and PCI DSS -The Payment Card Industry Data Security Standard

 

PCI compliance, usually refers to the PCI Data Security Standard (DSS) which is an information security standard for organizations that handle branded credit cards from the major card companies.

Image
creative_image-set-pci-march-blog-list-image

 

PCI DSS 4.0 Is Here: When Does My Company Need To Be Ready?

 

Some companies should update to PCI DSS v4.0 now, while others should wait. This post features helpful details and advice on how to begin preparing.