For companies that transmit payment card information from consumers, the Payment Card Industry Data Security Standard (PCI DSS) provides the most comprehensive information security standards.
That is because the PCI Security Standards Council is continually reviewing how the industry operates and looking for ways to improve it. Specifically, it is concerned with enhancing how businesses handle the development, storage, dissemination, and security of data. PCI DSS occasionally issues new updates for organizations to improve their practices in these areas and ensure they remain compliant.
The next version of the Payment Card Industry Data Security Standards is scheduled for release early next year. It might be too soon to know what will change when PCI DSS Version 4.0 is released, but we can look for clues in the PCI Council’s blogs and feedback reports from industry sources who have reviewed early drafts.
Goals for PCI DSS v4.0
Based on the feedback received, PCI SSC evaluates how to evolve the standard to accommodate changes in technology, risk mitigation techniques, and the threat landscape. PCI SSC is also looking to introduce greater flexibility to support organizations using a broad range of controls and methods to meet security objectives.
These are some of the high-level goals for PCI DSS v4.0:
- Ensure the standard continues to meet the security needs of the payments industry
- Add flexibility and support of additional methodologies to achieve security
- Promote security as a continuous process
- Enhance validation methods and procedures
Industry feedback is shaping the next major release of PCI DSS
An initial request for comment (RFC) went out to the industry between October and December 2019. The RFC generated over 3,000 responses. An additional RFC, which included an updated draft of PCI DSS Version 4.0, was sent in October 2020. PCI SSC is targeting a Q1 2022 publication date for PCI DSS v4.0.
Some of the specific areas that stakeholders asked PCI SSC to review include:
- Authentication, specifically consideration for the NIST MFA/password guidance
- Broader applicability for encrypting cardholder data on trusted networks
- Monitoring requirements to consider technology advancement
As part of the RFC process, all feedback received will be reviewed and considered in the development of the standard.
Key Changes to Anticipate with PCI DSS 4.0
1 Flexibility: Customized implementation to meet the intent of security controls
That is probably the most significant change that will come into place when PCI DSS 4.0 is released next year. The 12 requirements will shift to focus on the main security objectives reviewed in the RFCs.
The new, customized validation approach will sharply define the security outcomes linked to each requirement. With PCI DSS 4.0, organizations will have the ability to choose to perform the control as prescribed or opt for customized implementation. With customized implementation, organizations can comply by showing that they met the intent of the requirement without needing to provide an operational or technical justification.
That change will allow businesses more flexibility in modifying their implementation procedures and meeting the intent of the requirement. To verify the effectiveness, external evaluators must review the documentation and thoroughly test each control with a custom implementation.
2 Security: More stringent requirements
The ultimate goal of PCI DSS continues to be ensuring that all sellers safely and securely store, process, and transmit cardholder data. It is fair to assume that PCI DSS 4.0 will set the bar higher and build on the assurance of PCI-DSS v3.2.1. In addition to restructuring many of the requirements, the Summary of Changes will likely include strengthened security standards. Top management, including CISOs and CTOs, should prepare to adjust budgets to allocate capital and operational funds to implement the new requirements.
3 Authentication: A focus on NIST Password Guidance & MFA
National Institute of Standards and Technology (NIST) Password Guidance moves to the forefront in this new version. The PCI SSC places more focus on applying stronger authentication standards to payment and control process access log-ins. It has also partnered with the Europay, Mastercard, and Visa (EMVco) to implement the use of a 3DS Core Security Standard during transaction authorization.
4 Monitoring: Technology advancement requirements
There are likely to be more risk-based approaches in the new PCI DSS 4.0. Technology evolves rapidly, and companies are looking at pluggable options for their information systems, much like the PCI Software Security Framework. Adopting these solutions allows organizations to comply with standards while gaining faster deployment of processes without having the technology located in a specific control area.
How much time will organizations have to implement v4.0 once it is published?
Once PCI DSS v4.0 is released, an extended transition period will be provided for organizations to update from PCI DSS v3.2.1 to PCI DSS v4.0. To support this transition, PCI DSS v3.2.1 will remain active for 18 months. Once all PCI DSS v4.0 materials and supporting documents are released. The PCI DSS v4.0 standard will be available for two years before the retirement of PCI DSS v3.2.1.
This extended period allows organizations time to become familiar with the changes in v4.0, update their reporting templates and forms, and plan for and implement changes to meet updated requirements. Upon completion of the transition period, PCI DSS v3.2.1 will be retired, and v4.0 will become the only version in use. In addition to an 18-month period when v3.2.1 and v4.0 will both be active, there will be an extra period defined for phasing in new requirements identified as “future-dated” in v4.0.
What are “future-dated” requirements and when will they come into effect?
In PCI DSS, new requirements are sometimes designated with a future date to give organizations additional time to complete their implementations. Requirements that are future dated are considered as best practices until the future date arrives. During this time, PCI DSS does not require organizations to validate requirements that are future-dated. Once the designated future date arrives, all future-dated requirements come into effect and become applicable.
We anticipate that PCI DSS v4.0 will contain several new requirements that may be future-dated. However, we won’t know how many new requirements there will be until the standard is published. We will also not know the effective future date for these new requirements until PCI DSS v4.0 is ready for publication.
However, PCI DSS v4.0 will provide enough time for organizations to plan and implement new security controls and processes as needed to meet all the new requirements. The future date will be dependent on the overall impact that the new requirements will have on the standard. Based on the current draft, the future date will likely extend beyond the planned transition period, with a possible future date of 2 to 3 years after PCI DSS v4.0 is published.
Challenges to Consider before v4.0 is released
The core PCI DSS requirements are not expected to fundamentally change with PCI DSS v4.0, as these are still critical components of securing credit card data. However, organizations should consider the potential changes to PCI DSS requirements, as decisions that are being made now about IT infrastructure and policy could be affected by those changes.
The transition period could aggravate some challenges associated with obtaining and maintaining compliance with PCI DSS. First, there’s the threat of configuration drift. Organizations should have a goal in mind to ensure that systems in their cardholder environments remain compliant.
As always, organizations must demonstrate compliance to auditors. Time and resources must be allocated to complete the auditing process. These resources could be substantial, depending on the number of assets, tests, and controls that are in place. Organizations need to have historical data to prove compliance over time. Depending on their available resources and the size of their cardholder data environments, organizations might also find it impractical to audit all of their systems. Such a decision could prove costly if any threats remained unexposed, leaving their systems vulnerable to attacks.
Ransomware today is a billion-dollar industry. It’s crippled industries like healthcare, infrastructure, telecommunications, and finance. Hackers carry out cyberattacks at the private and public levels, and threat actors have no regard for the implications their actions have on our national and global financial security.
These attacks are possible by the ongoing presence of weak security controls and outdated operating systems. Looking ahead, it’s likely that malicious actors will continue to use ransomware to target a variety of industries. They’ll also probably go after individual organizations’ Point of Sale (POS) systems, as EMV chip cards have made data scraping nearly impossible.
One of the primary goals of PCI DSS v4.0 will be to promote security as a continuous process so that organizations can remain compliant over time.
Reduce Security Vulnerabilities with
Multi-Factor Authentication
Multi-factor authentication has become vital in ensuring secure access to systems and other valuable resources. It provides superior safety measures when attempting to access systems and financial applications, and is also an important requirement to comply with regulations such as PCI 8.3 and GDPR. MFA prevents access to phishing websites or spoofing applications, the added security layers provided by MFA help to keep you from falling for these types of traps.
Modern authentication methods represent a more robust security structure than simple passwords. They also provide a better user experience when logging into applications. MFA makes it easier for auditors to get answers to critical compliance questions. MFA provides valuable information, such as which users are granted access to which system and how the access policy is enforced. Additionally, some of the modern MFA applications available today also include reporting capabilities. That ensures that compliance standards, such as PCI-DSS, are met.
CSP Authenticator+® supports numerous authentication factors for NonStop. It provides a RESTful interface that supports multi-factor authenticated logins on NonStop systems. CSP Authenticator+ resides on the NonStop Platform and uses an OSS “bridge” to connect to the RESTful interface of the CSP Authenticator+ web server.
CSP Authenticator+ can provide authentication services via Safeguard Authentication SEEP, or Pathway and Non-Pathway servers. Almost any application, including TACL, can now easily support multi-factor authentication (MFA).
Primary authentication methods such as RADIUS, RSA Cloud, Active Directory, and Open LDAP are supported; User Rights Synchronization will also make it easier than ever before to integrate a NonStop system into the Enterprise ID management platforms.
Secondary authentication methods supported include RSA SecurID, Email, Text Message and Google Authenticator. You can now enable MFA logins for different applications, making them more secure.
CSP Authenticator+ Key Features:
- Support for various authentication methods
- Browser-based user-friendly interface
- Standardized authentication across platforms
- Configurable for all or selected users
- Support for virtual addressing
CSP – Compliance at your Fingertips®
For complimentary access to CSP-Wiki®, an extensive repository of NonStop security knowledge and best practices, please visit wiki.cspsecurity.com
We Built the Wiki for NonStop Security ®
+1(905) 568 –8900
Author
-
How much time will organizations have to implement v4.0 once it is published?
Once PCI DSS v4.0 is released, an extended transition period will be provided for organizations to update from PCI DSS v3.2.1 to PCI DSS v4.0. To support this transition, PCI DSS v3.2.1 will remain active for 18 months. Once all PCI DSS v4.0 materials and supporting documents are released. The PCI DSS v4.0 standard will be available for two years before the retirement of PCI DSS v3.2.1.
This extended period allows organizations time to become familiar with the changes in v4.0, update their reporting templates and forms, and plan for and implement changes to meet updated requirements. Upon completion of the transition period, PCI DSS v3.2.1 will be retired, and v4.0 will become the only version in use. In addition to an 18-month period when v3.2.1 and v4.0 will both be active, there will be an extra period defined for phasing in new requirements identified as “future-dated” in v4.0.
What are “future-dated” requirements and when will they come into effect?
In PCI DSS, new requirements are sometimes designated with a future date to give organizations additional time to complete their implementations. Requirements that are future dated are considered as best practices until the future date arrives. During this time, PCI DSS does not require organizations to validate requirements that are future-dated. Once the designated future date arrives, all future-dated requirements come into effect and become applicable.
We anticipate that PCI DSS v4.0 will contain several new requirements that may be future-dated. However, we won’t know how many new requirements there will be until the standard is published. We will also not know the effective future date for these new requirements until PCI DSS v4.0 is ready for publication.
However, PCI DSS v4.0 will provide enough time for organizations to plan and implement new security controls and processes as needed to meet all the new requirements. The future date will be dependent on the overall impact that the new requirements will have on the standard. Based on the current draft, the future date will likely extend beyond the planned transition period, with a possible future date of 2 to 3 years after PCI DSS v4.0 is published.
Challenges to Consider before v4.0 is released
The core PCI DSS requirements are not expected to fundamentally change with PCI DSS v4.0, as these are still critical components of securing credit card data. However, organizations should consider the potential changes to PCI DSS requirements, as decisions that are being made now about IT infrastructure and policy could be affected by those changes.
The transition period could aggravate some challenges associated with obtaining and maintaining compliance with PCI DSS. First, there’s the threat of configuration drift. Organizations should have a goal in mind to ensure that systems in their cardholder environments remain compliant.
As always, organizations must demonstrate compliance to auditors. Time and resources must be allocated to complete the auditing process. These resources could be substantial, depending on the number of assets, tests, and controls that are in place. Organizations need to have historical data to prove compliance over time. Depending on their available resources and the size of their cardholder data environments, organizations might also find it impractical to audit all of their systems. Such a decision could prove costly if any threats remained unexposed, leaving their systems vulnerable to attacks.
Ransomware today is a billion-dollar industry. It’s crippled industries like healthcare, infrastructure, telecommunications, and finance. Hackers carry out cyberattacks at the private and public levels, and threat actors have no regard for the implications their actions have on our national and global financial security.
These attacks are possible by the ongoing presence of weak security controls and outdated operating systems. Looking ahead, it’s likely that malicious actors will continue to use ransomware to target a variety of industries. They’ll also probably go after individual organizations’ Point of Sale (POS) systems, as EMV chip cards have made data scraping nearly impossible.
One of the primary goals of PCI DSS v4.0 will be to promote security as a continuous process so that organizations can remain compliant over time.
Reduce Security Vulnerabilities with
Multi-Factor Authentication
Multi-factor authentication has become vital in ensuring secure access to systems and other valuable resources. It provides superior safety measures when attempting to access systems and financial applications, and is also an important requirement to comply with regulations such as PCI 8.3 and GDPR. MFA prevents access to phishing websites or spoofing applications, the added security layers provided by MFA help to keep you from falling for these types of traps.
Modern authentication methods represent a more robust security structure than simple passwords. They also provide a better user experience when logging into applications. MFA makes it easier for auditors to get answers to critical compliance questions. MFA provides valuable information, such as which users are granted access to which system and how the access policy is enforced. Additionally, some of the modern MFA applications available today also include reporting capabilities. That ensures that compliance standards, such as PCI-DSS, are met.
CSP Authenticator+® supports numerous authentication factors for NonStop. It provides a RESTful interface that supports multi-factor authenticated logins on NonStop systems. CSP Authenticator+ resides on the NonStop Platform and uses an OSS “bridge” to connect to the RESTful interface of the CSP Authenticator+ web server.
CSP Authenticator+ can provide authentication services via Safeguard Authentication SEEP, or Pathway and Non-Pathway servers. Almost any application, including TACL, can now easily support multi-factor authentication (MFA).
Primary authentication methods such as RADIUS, RSA Cloud, Active Directory, and Open LDAP are supported; User Rights Synchronization will also make it easier than ever before to integrate a NonStop system into the Enterprise ID management platforms.
Secondary authentication methods supported include RSA SecurID, Email, Text Message and Google Authenticator. You can now enable MFA logins for different applications, making them more secure.
CSP Authenticator+ Key Features:
- Support for various authentication methods
- Browser-based user-friendly interface
- Standardized authentication across platforms
- Configurable for all or selected users
- Support for virtual addressing
CSP – Compliance at your Fingertips®
For complimentary access to CSP-Wiki®, an extensive repository of NonStop security knowledge and best practices, please visit wiki.cspsecurity.com
We Built the Wiki for NonStop Security ®
+1(905) 568 –8900
Be the first to comment