Visa Europe revealed important stats about the usage of Contactless Cards.
Poland, Spain and the UK use this payment methd the most,
with UK usage growing by 300% year over year.
Analysis of PCI DSS v4.0 - Part 4: Requirements 5 & 6
David E. Acosta July 6, 2022
6 minutes read
The fourth article in the PCI DSS 4.0 Analysis series examines the changes to PCI DSS requirements 5 and 6 between versions 3.2.1 and 4.0. These two requirements are focused on software-level protection to prevent, detect and mitigate the exploitation of vulnerabilities in in-scope system components.
In PCI DSS version 4.0 these requirements were renamed to clarify and broaden their scope, addressing some of the restrictions identified in version 3.2.1.
Requirement 5: Protect All Systems and Networks from Malicious Software
In its first version, PCI DSS included controls for detecting, removing, blocking, and containing malicious code (malware). Until version 3.2.1, these controls were generically referred to as "anti-virus software", which was incorrect technically because they protect not just against viruses, but also against other known malware variants (worms, trojans, ransomware, spyware, rootkits, adware, backdoors, etc.).
As a result, the term "antimalware" is now used not only to refer to viruses, but also to all other types of malicious code, more in line with the requirement's objectives.
Other changes incorporated in this new version of the standard were:
To avoid the ambiguities seen in previous versions of the standard about which operating systems should have an anti-malware solution installed and which should not, a more operational approach has been chosen: the entity should perform a periodic assessment to determine which system components should require an anti-malware solution. All other assets that are determined not to be affected by malware should be included in a list (req. 5.2.3).
Updates of the anti-malware solution must be performed automatically (req. 5.3.1).
Finally, the term "real-time scanning" is explicitly included for the anti-malware solution (this is a type of persistent, continuous scanning where a scan for security risks is performed every time a file is received, opened, downloaded, copied or modified). Previously, there was a reference to the fact that anti-malware mechanisms should be actively running, which gave rise to different interpretations.
Continuous behavioral analysis of systems or processes is incorporated as an accepted anti-malware solution scanning method, as an alternative to traditional periodic (scheduled and on-demand) and real-time (on-access) scans (req. 5.3.2).
As for scheduled scans, their periodicity must be configured based on a risk analysis (req. 18.104.22.168).
The scanning of removable storage media is mandatory (req. 5.3.3).
The retention of the anti-malware solution logs is aligned to the general log management criteria (12 months with the availability of the last 3 months for immediate analysis - req. 5.3.4).
The use of mechanisms to detect and protect against phishing attacks is mandatory (req. 5.4.1). In this case, the controls to be implemented go beyond the installation of an antimalware agent, involving configurations at the level of email servers (without these servers having to be in scope)
This control will be effective as of March 31, 2025
Requirement 6: Develop and Maintain Secure Systems and Software
Like the vast majority of PCI DSS requirements, Requirement 6 was not immune to the name change, which on this occasion broadens its scope to include applications and software in general. It is clarified that the controls of this requirement apply to all system components, except for section 6.2, which applies only to custom or internally developed software.
The most relevant changes to the controls for custom or in-house developed software are:
The order of the controls in the requirement was changed, organizing in section 6.2 the controls for custom or internally developed software, section 6.3 for update and vulnerability management, section 6.4 for protection of publicly accessible web applications, and section 6.5 for change management.
Priority was given to the application of security controls on custom or internally developed software to prevent vulnerabilities throughout the development lifecycle phases.
Details about the content of developer training were incorporated (req. 6.2.2):
Must be performed annually
Must cover the programming languages used
It should incorporate information about the tools used for vulnerability detection.
As for code review, it must be performed in accordance with secure development guidelines, include reviews of existing and emerging vulnerabilities, and apply fixes before releasing to production (req. 6.3.2).
Some of the "traditional" vulnerabilities in software development (SQLi, XSS, CSRF, etc.) were grouped into a single requirement (req. 6.2.4).
On the other hand, the following controls were added/complemented for the management of security vulnerabilities:
Vulnerability identification should cover not only the "base" software (operating systems, databases, applications, network equipment) but also libraries, compilers, programming languages, etc.
The concept of "bug bounty" is mentioned for the first time as an additional tool for third parties to report vulnerabilities to the entity (req. 6.3.1).
The creation of an inventory of custom or internally developed software, including linked components such as libraries, services, frameworks, etc., is required (req. 6.3.2, effective 31 March 2025).
From 31 March 2025, the use of an automated technical tool to detect and prevent web attacks in real-time (such as a Web Application Firewall - WAF, for example) will be mandatory. The periodic execution of web application scanning tools, which was offered as an option for the protection of publicly accessible web applications, will no longer be valid.
Control 6.4.1 (protection of publicly accessible web applications) mentions Runtime Application Self-Protection (RASP) technology as a complementary tool to the Web Application Firewall (WAF).
Finally, many of the criteria that had been presented in the Information Supplement: Best Practices for Securing E-commerce were incorporated into the standard, including the implementation of technical methods for the protection of scripts on payment pages loaded and executed in the user's browser, including:
Controls to confirm that each script is authorized
Checks to verify the integrity of each script
An inventory of all scripts used with their related justification.
This control will be valid from March 31, 2025.
On the other hand, in terms of change management:
The use of live PAN numbers in pre-production environments will be allowed if these environments are included in the CDE and protected in accordance with PCI DSS.
Change management includes changes made to custom or internally developed software.
In the next article of this series, we will analyze the requirements 7, 8, and 9 of PCI DSS, focused on the management of physical and logical access control to the environment.
New to the Analysis of PCI DSS v4.0 series by Advantio? Follow the links below to catch up on the previous articles:
I am the Senior Security Consultant in Advantio. I have more than 15 years of experience, working both in South America and Europe. My information security background includes consultancy and audit, training, implementation of security technologies and design and policy development among others.