Your Perfect Cybersecurity Partner

Stay Connected:

Image

The Next New Evolution of PCI DSS-What is New in v4.0

  • Published On: May 17, 2022 Updated On: January 24, 2023

About PCI DSS:

The Payment Card Industry Data Security Standard (PCI DSS) is a set of security standards formed in 2004 by Visa, MasterCard, Discover Financial Services, JCB International and American Express. Governed by the Payment Card Industry Security Standards Council (PCI SSC). It is a global standard that provides a baseline of technical and operational requirements designed to protect credit and debit card transactions against data theft and fraud.

Heads up to the Next New Evolution of PCI DSS:

The PCI DSS was unique when it was introduced because of its prescriptive nature and its focus on protecting cardholder data. Since Cybersecurity is a changing landscape, and prescriptive standards must be updated to address those changes. Hence The next evolution of the standard- PCI DSS v4.0- is now available.

The newest standards place significant emphasis on multi-factor authentication. Some changes don’t really seem like they’ll have an impact, but others have major change implications for call centres that are trying to stay PCI compliant.

However, PCI DSS vb4.0 doesn’t immediately come into effect for all organizations. The PCI Council sets full compliance out to 2025, labelling them as best practices until then.

PCI Council clearly stated that “In addition to an 18-month period when v3.2.1 and v4.0 will both be active, there will be an extra period of time defined for phasing in new requirements that are identified as “future-dated” in v4.0.”

image

Goals for PCI DSS v4.0

PCI DSS v4.0 evolved with four primary goals in accordance with the current technology.

  • Continue to meet the security needs of the Payment Industry.
  • Promote security as a continuous process.
  • Add flexibility for different Methodologies.
  • Enhance Validation Methods.

What Is New in PCI DSS v4.0?

The 12 core PCI DSS requirements did not fundamentally change with PCI DSS v4.0, and they remain the critical foundation for securing payment card data. However, the requirements have been redesigned to focus on security objectives to guide how security controls should be implemented.

Even though PCI DSS 4.0 keeps the existing prescriptive method for compliance, the new version introduces an alternate option for meeting compliance: customized implementation. Customized implementation considers the intent of the objective and allows entities to design their own security controls to meet it. This change will allow businesses to modify implementation procedures and meet requirement intent.

Below you can find a high-level summary and explanation of the changes made in the transition from PCI DSS v3.2.1 to PCI DSS v4.0, but not all revisions. The standard should be examined on its whole rather than focusing just on the summary below due to the scope of the changes.

image

Requirement #1 - Install and Maintain Network Security Controls:

  • Processes and mechanisms for installing and maintaining network security controls are defined and understood.
  • Network security controls (NSCs) are configured and maintained.
  • Network access to and from the cardholder data environment is restricted.
  • Network connections between trusted and untrusted networks are controlled.
  • Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.

Requirement #2 - Apply Secure Configurations to All System Components

  • Processes and mechanisms for applying secure configurations to all system components are defined and understood.
  • System components are configured and managed securely.
  • Wireless environments are configured and managed securely.

Requirement #3 - Protect Stored Account Data

  • Processes and mechanisms for protecting stored account data are defined and understood.
  • Storage of account data is kept to a minimum.
  • Sensitive authentication data (SAD) is not stored after authorization.
  • Access to displays of full PAN and ability to copy cardholder data are restricted.
  • Primary account number (PAN) is secured wherever it is stored.
  • Cryptographic keys used to protect stored account data are secured.
  • Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.

Requirement #4 - Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks

  • Processes and mechanisms for protecting cardholder data with strong cryptography during transmission over open, public networks are defined and documented.
  • PAN is protected with strong cryptography during transmission.

Requirement #5 - Protect All Systems and Networks from Malicious Software

  • Processes and mechanisms for protecting all systems and networks from malicious software are defined and understood.
  • Malicious software (malware) is prevented, or detected and addressed.
  • Anti-malware mechanisms and processes are active, maintained, and monitored.
  • Anti-phishing mechanisms protect users against phishing attacks.

Requirement #6 - Develop and Maintain Secure Systems and Software

  • Processes and mechanisms for developing and maintaining secure systems and software are defined and understood.
  • Tailored and custom software are developed securely.
  • Security vulnerabilities are identified and addressed.
  • Public-facing web applications are protected against attacks.
  • All changes to system components are managed securely.

Requirement #7 - Restrict Access to System Components and Cardholder Data by Business Need to Know

  • Processes and mechanisms for restricting access to system components and cardholder data by business need to know are defined and understood.
  • Access to system components and data is appropriately defined and assigned.
  • Access to system components and data is managed via an access control system(s).

Requirement #8 - Identify Users and Authenticate Access to System Components

  • Processes and mechanisms for identifying users and authenticating access to system components are defined and understood.
  • User identification and related accounts for users and administrators are strictly managed throughout an account’s lifecycle.
  • Strong authentication for users and administrators is established and managed.
  • Multi-factor authentication (MFA) is implemented to secure access into the CDE
  • Multi-factor authentication (MFA) systems are configured to prevent misuse.
  • Use of application and system accounts and associated authentication factors is strictly managed.

Requirement #9 - Restrict Physical Access to Cardholder Data

  • Processes and mechanisms for restricting physical access to cardholder data are defined and understood.
  • Physical access controls manage entry into facilities and systems containing cardholder data.
  • Physical access for personnel and visitors is authorized and managed.
  • Media with cardholder data is securely stored, accessed, distributed, and destroyed.
  • Point of interaction (POI) devices are protected from tampering and unauthorized substitution.

Requirement #10 - Log and Monitor All Access to System Components and Cardholder Data

  • Processes and mechanisms for logging and monitoring all access to system components and cardholder data are defined and documented.
  • Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
  • Audit logs are protected from destruction and unauthorized modifications.
  • Audit logs are reviewed to identify anomalies or suspicious activity.
  • Audit log history is retained and available for analysis.
  • Time-synchronization mechanisms support consistent time settings across all systems.
  • Failures of critical security control systems are detected, reported, and responded to promptly.

Requirement #11 - Test Security of Systems and Networks Regularly

  • Processes and mechanisms for regularly testing security of systems and networks are defined and understood.
  • Wireless access points are identified and monitored, and unauthorized wireless access points are addressed.
  • External and internal vulnerabilities are regularly identified, prioritized, and addressed.
  • External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected.
  • Network intrusions and unexpected file changes are detected and responded to.
  • Unauthorized changes on payment pages are detected and responded to.

Requirement #12 - Support Information Security with Organizational Policies and Programs

  • A comprehensive information security policy that governs and provides direction for protection of the entity’s information assets is known and current.
  • Acceptable use policies for end-user technologies are defined and implemented.
  • Risks to the cardholder data environment are formally identified, evaluated, and managed.
  • PCI DSS compliance is managed.
  • PCI DSS scope is documented and validated.
  • Security awareness education is an ongoing activity.
  • Personnel are screened to reduce risks from insider threats.
  • Risk to information assets associated with third-party service provider (TPSP) relationships is managed.
  • Third-party service providers (TPSPs) support their customers’ PCI DSS compliance.
  • Suspected and confirmed security incidents that could impact the CDE are responded to immediately.

How Briskinfosec can help

Like most of the security industry, the PCI Security Standards Council is following the approach that compliance is something that must be proven every day–this is an attainable goal. Expertise in Briskinfosec can help your organization to meet the PCI DSS v4.0 standard well before the deadline.

Make sure to bookmark the Briskinfosec website to stay up to date on all educational resources related to PCI DSS v4.0.