PCI DSS Requirements With v4.0.1 Updates For 2024 – Source: securityboulevard.com

PCI DSS refers to the Payment Card Industry Data Security Standard created by the PCI Security Standards Council (PCI SSC), an independent entity founded by major payment card brands, including Visa, JCB International, MasterCard, American Express, and Discover. PCI DSS is designed to protect cardholder data and ensure security of payment infrastructure.

PCI DSS 4.0.1 is a new update built on the previous version, 4.0, and now businesses need to understand it and ensure compliance after December 31, 2024. PCI DSS compliance is necessary, although it is not a legal requirement, but crucial for entities that store, transmit, and process payment card data. Being PCI compliant shows that businesses have controls in place to combat security threats and are protecting cardholder data.

PCI Compliance Requirements

PCI DSS compliance is built on 12 requirements divided into six control objectives. PCI DSS compliance is validated on annual basis, regardless of company size. For instance, level 1 organisations must have an external PCI DSS audit performed by a PCI QSA (Qualified Security Assessor) to remain compliant. These compliant obligations increase significantly in the event of a data breach.

Build and maintain a secure network and systems

Requirement 1: Install and Maintain Network Security Controls

The PCI DSS’s first requirement is all about building and securing the payment network resources, which is only possible if you put well-defined and securely configured controls. Businesses need to maintain secure systems, change vendor-supplied default passwords and other security parameters, and install network security measures that not only restrict unauthorised network access but also protect against risks that arise from untrusted connections. All computing devices, including company and employee-owned devices, should be securely configured, have up-to-date software, and limited access to allowed changes.

This type of security can be achieved by managing network configurations through a structured process and documenting up-to-date network architecture and data flow diagrams. Firewalls, anti-virus software, anti-spoofing mechanisms, and other devices are also beneficial in keeping trusted and untrusted networks separated.

Requirement 2: Apply Secure Configurations to All System Components

To achieve PCI compliance, the organisation must define and maintain secure configurations for the overall infrastructure, including the wireless environment. All configurations should align with industry best practices and hardening guidelines.

Moreover, they should address known and new vulnerabilities and be regularly updated, especially whenever a new system component is introduced to the production environment. The overall system and its components should not have vendor-supplied defaults, as they are easy to exploit.

Thus, all the credentials should be either disabled if not used or immediately changed. All the components with varied security levels should be managed by isolating their functions or configuring them to meet the highest possible security benchmark.

At Cyphere, from all the annual PCI DSS assessments performed in the last few years, we have seen misconfigurations as one of the top risks affecting cardholder environments. The default passwords and other security parameters of the in-scope wireless network devices configuration should be changed. It’s critical that encryption keys are managed securely, as this is crucial for data protection and confidentiality. The keys must also be changed whenever personnel leaves or any compromise is suspected.

Businesses must make sure that all of the components only run necessary and secure services and protocols and must be disabled when no longer required to reduce the attack surface. Businesses using these insecure services must document and justify along with security countermeasures to mitigate the associated risks.

Protect Cardholder Data

Requirement 3: Protect stored account data

Organisations must have policies and controls to protect stored accounts and sensitive authentication data (SAD), such as PINs and card security codes. All such data should be deleted immediately after the payment authorisation process. PCI DSS compliance mandates not storing SAD after authorisation, and any retained data, like PAN, expiry date, service code, and cardholder name, should be masked and unrecoverable during the authorisation process.

Policies for data retention and secure disposal must be enforced to prevent unauthorised access. Besides this, the requirement focuses on using key management processes, including key distribution, rotation, storage, and destruction, to ensure the encryption of stored data. The key management policy must also address the key replacement and retirement process in case of compromise or at the end of their lifecycles.

A strong cryptography mechanism should be implemented for SAD that is electronically stored prior to authorisation completion. Appropriate technical controls must be considered to prevent unauthorised copying and relocation of PAN during remote access, except for the authorised processes with a legitimate business justification.

Most importantly, the policy should be reviewed quarterly, and all custodians must formally acknowledge their responsibilities.

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

PCI compliance requirement 4 requires a process to protect stored cardholder data during transmission over public networks with a strong encryption mechanism. It is also important to make sure only trusted keys are used and certificates are valid, unexpired, or revoked.

Along with it, the inventory of keys that are certificated must be maintained; network protocols should support the secure versions. Lastly, the PAM remains secured with strong cryptography whenever it is sent through end-user technologies.

Maintain a Vulnerability Management Program

Requirement 5: Protect All Systems and Networks from Malicious Software

PCI DSS compliance can only be achieved if, among all other PCI DSS requirements, the business has implemented a clear process and mechanisms to protect the payment infrastructure from malware. Anti-malware and anti-virus software greatly help in evaluating systems that are at risk.

The businesses must deploy such solutions on network resources to detect, block, remove, and quarantine known malware at run-time. The periodic scans or behavioural analysis would greatly help in analysing as well as detecting potential threats, whereas keeping the solution up to date with the latest version will be beneficial in staying updated with trending malware or viruses.

Phishing is also a serious concern in maintaining defence that comes from employees or user negligence. Along with other security processes and solutions, an anti-phishing mechanism with an automated process is also important to fulfilling requirement 5 of PCI compliance.

Requirement 6: Develop and Maintain Secure Systems and Software

Businesses need to have a proper mechanism for maintaining system and software security, or else the PCI DSS requirement 6 cannot be fulfilled. Software should be developed securely, following secure software development lifecycle (Secure SDLC) best practices to ensure security is incorporated at every stage of development. This is only possible when the developers are fully trained and have strong knowledge of secure coding guidelines and secure architecture review to build the application or software.

Continuous tracking of vulnerability management is crucial, whether they are identified or reported in custom software, third-party software, or public-facing applications. All custom software should undergo essential security checks in pre-production, including vulnerability scans, code reviews, etc., through a third-party service provider.

There’s no sureshot single way to ensure security of systems and underlying services. An organisation must adopt a proactive approach to think of security strategy as a long term business enablement objective.

All software inventory must be kept updated; this will help with patch management. Vulnerability patches should be applied within a month of release, and public-facing applications need to be reviewed regularly or at least annually to ensure they are protected against emerging threats. WAF should be implemented to detect and block web-based attacks in real-time. At the same time, all security systems and solutions must remain up to date to generate logs and trigger alerts for immediate investigation whenever threats are detected.

All changes to pre-production and production environments should remain separated, and the production systems must be managed through a controlled process. This process should require approval wherever needed, with clear roles and responsibilities to ensure segregation. Most importantly, the live PAN must not be used in the testing environment and should be removed before going live to ensure full PCI compliance.

Last but not least, the authorities need to ensure that every change is properly reviewed and documented and that security controls are in place to protect stored cardholder data.

Implement Strong Access Control Measures

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

Organisations are obliged to restrict access and only follow the need-to-know principle to ensure only authorised personnel have access to cardholder data. Users are allowed to have minimum access to perform their duties, and all accounts, including third parties, contractors, etc., should be regularly reviewed or at least every six months.

By default, the access control system of all components needs to be built on “deny all” settings; access to cardholder data should be enforced on role-based access and the principle of least privilege to make sure only the designated administrator has access to specific repositories.

Requirement 8: Identify Users and Authenticate Access to System Components

It is necessary that users have their unique identifier (user ID) before they are allowed to access the system or cardholder data. When accessing the system, one or more appropriate identity verification methods, such as fingerprint, token, MFA, passwords, etc., should be used. Any changes to it need to be managed mindfully with pre-approval, and the authentication details must always be encrypted while in transit or at rest.

A password policy with at least 12 characters and restricted reuse of the last four passwords is required by the PCI Data Security Standard (PCI DSS) to maintain strong access control measures. Also, it is recommended to change the account and system passwords on each 90-day interval and be required to be monitored for account compromise or data breach. For inactive accounts or idle sessions, the account must be automatically disabled after 90 days of no use, for later, after 15 minutes, the user needs to re-authenticate.

For all non-console or cardholder data environment (CDE) access, especially for admin roles, multi-factor authentication must be in place to prevent replay attacks or unauthorised bypasses. Businesses must ensure that authentication details are always encrypted both at rest and in transit. The account security should have an access control mechanism to block the account for at least 30 minutes on 10 or more unsuccessful attempts.

Furthermore, accounts that need to be inactive for any business reason should be documented with proper approvals. It is necessary to ensure that those system passwords are not present in any scripts and are regularly changed.

Requirement 9: Restrict Physical Access to Cardholder Data

It is mandatory to regularly test security systems and restrict physical access to cardholder data. It is only possible when an organisation implements strong physical access controls such as monitoring via camera or CCTV, access cards, etc. The organisational facilities’ access should be restricted to authorised personnel only and allow visitors with appropriate checking.

While allowing visitors, the organisation must maintain a comprehensive record of their PII (Personal Identifiable Information), the organisation they represent, the date and time of the visit, and the name of personnel authorising the physical access.

All visitors allowed to access the cardholder data environment must be given a badge or any other identification that expires and distinguishes them from other personnel. They must also be escorted at all times. The visitors’ records shall also be stored securely, tracked when needed, and securely destroyed when no longer required.

Other than visitors, personnel access to sensitive areas within the cardholder data environment should also be controlled and only allowed for individuals with specific job responsibilities. Access must be revoked immediately upon termination, and all access cards, keys, etc., must be returned or disabled upon departure and termination.

There should an appropriate security controls to restrict the use of publicly accessible networks within the facility. All media that stores cardholder data needs to be protected in a secure location. Offline media backups should be maintained and reviewed at least annually.

Regularly Monitor and Test Networks

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

For Payment Card Industry Data Security compliance, it is important to establish a strong process for systems components and cardholder access such as logging and monitoring. The implemented log and monitoring system helps detect malicious activities, assists in forensic analysis, and protects against unauthorised changes. It should enable all system components to capture failed attempts, credential changes, and administration activities and must be functional to retain for at least a year with the most recent three-month accessibility.

The logs should also track activity such as the creation, deletion, modification of system-level objects. For each event, data such as userID, event type, date and time stamp, and successful or failed attempt must be recorded. Time-synchronisation is absolutely necessary to ensure logs have accurate time, and access to system clocks must be restricted to any changes and monitored.

The audit logs should only be accessible to authorised individuals, and that too for justified reasons or job duties. Logs related to security events or critical systems must be reviewed daily and for other components can be reviewed periodically based on their risk level.

Moreover, all security controls, such as IDS/IPS, firewall, and anti-virus software, must have a logging mechanism enabled, and in case of failure, it can be instantly investigated, remediated, and documented to prevent a recurrence.

Requirement 11: Test the security of systems and networks regularly

Businesses need to regularly test security systems to fulfill Requirement 11. Both internal and external vulnerability scans must be performed quarterly to address high-risk and critical security vulnerabilities. It is necessary to conduct external scans through a PCI Security Standards Council (PCI SSC) Approved Scanning Vendor (ASV). In case segmentation is done to isolate the cardholder data environment (CDE) network, testing of security systems must be done quarterly.

An authenticated scan should be used where applicable, and a testing methodology document must be maintained for internal and external scans covering both the application and network layers. It should be done annually or after significant changes are made. PCI DSS compliance has made it mandatory to maintain an authorised access point inventory with business justification, and it is necessary to test all authorised and unauthorised wireless access points quarterly.

An intrusion detection and prevention system and change detection mechanism must be implemented to monitor the Cardholder data environment to alert potential threats such as modifications to critical files, security settings, etc. All controls must align with the organisation’s risk analysis and be reviewed regularly.

Maintain an information security policy

Requirement 12: Support information security with organisational policies and programs

An information security policy should be documented, published and easily accessible that contains roles and responsibilities for employees, vendors, business partners. All personnel should be required to read and confirm their understanding of their duties towards securing data. Usually, organisations also prepare a set of associated policies aligned with the organisation’s function and usage of tech. These include access control policy, anti-virus policy, encryption policy, backup policy, business continuity, password policy and so on.

Similarly, an incident response plan covering disaster recovery and business continuity must be maintained.

The requirement does not end here. Along with all the policies and plans, businesses must document acceptable use policies for end-users, ensure regular security awareness training, and maintain an up-to-date inventory of PCI DSS system components.

Last, all policies and documents must be reviewed and updated annually to reflect changes in business objectives and environmental risks, and a programme must be in place to monitor PCI DSS compliance status each year.

Version 4.0.1 Updates (June 2024)

Allowing flexibility in implementing security controls​

The new PCI DSS version brings significant flexibility in terms of implementing security controls. Since every business operation demands different levels of security and faces different threats, this is why they require a customised approach to adopt security.

There is no one-size-fits-all model. The given flexibility empowers businesses to use their resources efficiently, prioritise security controls based on their risk levels, and address vulnerabilities and compliance needs.

The multiple PCI compliance requirements encourage businesses to align security controls with their operational environment and risk management strategies and promote proactive security practices, which, in the long term, will shape a culture of continuous improvements.

Introduction of advanced MFA factors like FIDO2

Updated version contains guidelines on advanced security protocols, specifically in multi-factor authentication mechanisms. MFA, such as FIDO2 or another passwordless method, secures user accounts by incorporating stronger phishing-resistance features.

The need to have more than one authentication factor reduces the probability of an attacker gaining access to the system as a legitimate user because, in order to do so, he would need to compromise multiple authentication factors.

The FIDO2 mechanism boosts the account security lifecycle because it does not rely on traditional SMS or email-based codes. Instead, it focuses on hardware and biometric credentials, which are quite difficult to bypass. The MFA must be implemented for all remote access coming from outside the business network and for all non-console access to the cardholder data environment.

APIs and Client-side security

Today’s technology architecture heavily relies on APIs, and the same has been focused on in the latest update. Along with all security controls and MFA to block authorised access, it has been made essential to protect all the APIs that are connected to the payment systems.

Organisations now need to ensure their client-side security is well-tested and has no open security vulnerabilities. The API must be thoroughly tested and protected with secure authentication and strong encryption. All client-side applications that directly interact with payment card data should be able to prevent common attack vectors like SQL, XSS, etc.

When Does PCI DSS 4.0 Retire?

PCI DSS 4.0 will retire on December 31, 2024, after which only 4.0.1 will be the active version supported by the PCI Security Standards Council (PCI SSC) with deadline set as March 31, 2025.

Staying up to date with industry releases is essential for maintaining a smaller attack surface and demonstrate a proactive approach towards data security. This PCI DSS update serves as a reminder that the data security landscape will evolve alongside emerging threats and risks. While the new PCI DSS version does not bring any new additions or changes, the previous only adds some guidance and fixes typographical mistakes, so it will be easier for businesses to ensure a smooth transition.

How Cyphere Can Help You with PCI DSS Standard Requirements?

Cyphere carries extensive experience and contextual awareness of several sectors, that adds edge to our capabilities. When it comes to regulatory and compliance requirements, your team needs to have a combined skill-set to help customers achieve business objectives while maintaining a balance with cyber security.

Through our annual PCI DSS penetration testing and network segmentation pen testing and web application pen tests, we also offer penetration testing, vulnerability assessment, and secure configuration reviews to strengthen the cardholder environments.

Book a call with us today to elevate your business compliance to the next level!

Summary

PCI compliance is important to businesses in building customer trust, protecting sensitive data, and reducing attack surface and data breaches. Some banks suggest that only Level 4 merchants need to comply with PCI DSS, which often needs clarification. PCI DSS compliances vary for merchants at different levels. Regardless of size or transaction frequency, it is recommended to implement all its requirements and comply with them.

Through careful planning and execution, all levels of merchants can seamlessly transition from PCI 4.0 to 4.0.1. In case of non-compliance, can lead the merchant to reputational damage, financial penalties, and loss of business opportunities.

Thus, businesses must carefully understand the requirements and map them to their business objectives, assess their current status, develop a transition plan, implement the necessary controls, train employees, and perform regular assessments to effectively comply with Payment Card Industry Data Security Standard (PCI DSS) 4.0.1.

While it may require a lot of effort, the proactive approach is essential for achieving long-term success and maintaining customer confidence.

Answering Your Questions About PCI Requirements

What are the requirements for PCI Merchant Level 4?

Level 4 merchants are those who handle less than 20,000 credit card transactions annually. Such merchants are required to complete the PCI Self-Assessment Questionnaire, perform quarterly security scans by a PCI Security Standards Council Approved Scanning Vendor (ASV), and complete the Attestation of Compliance form.

How many PCI DSS requirements are there in v4.01?

In the new update, requirements are 12, the same as the previous version, 4.0.

Is PCI DSS a legal requirement?

Payment Card Industry Data Security Standard (PCI DSS) compliance is not a legal requirement or a law. It is a security standard created by the PCI Security Standards Council and major credit card companies for businesses handling payment card processing.

Who should comply with PCI DSS?

PCI DSS compliance is mandatory for businesses processing, storing, or transmitting credit card information, including merchants, service providers, and any business handling payment data. While the Payment Card Industry Data Security Standard (PCI DSS) is not a legal requirement, non-compliance can lead to penalties, business losses, or fines.