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.

Click here to read the Analysis of DSS DSS v4.0
Part 3: Requiements 3 & 4

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.

Analysis of PCI DSS v4.0 - Part 4: Requirements 5 & 6Requirement 5: Protect All Systems and Networks from Malicious Software

 

Analysis of PCI DSS v4.0 - Part 4: Requirements 5 & 6

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.

Analysis of PCI DSS v4.0 - Part 4: Requirements 5 & 6

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. 5.3.2.1).
  • 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

 

Analysis of PCI DSS v4.0 - Part 4: Requirements 5 & 6

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:

 

 

Analysis of PCI DSS v4.0 - Part 4: Requirements 5 & 6

References

  1. Information Supplement - Best Practices for Securing E-commerce
  2. Defending Against Phishing & Social Engineering Attacks - A Resource Guide from the PCI Security Standards Council

 

Column Header Text Column Header Text Column Header Text

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Performing a review of the media inventories at least annually

Performing a review of the media inventories at least annually

Performing a review of the media inventories at least annually

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Discover More

Advantio_Blog_DNS_Diagram_V1 Image caption goes here. This is HTML text.

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.

Certifications: CISSP, CISM, CISA, CRISC, CEH, CHFI, PCI QSA, QSA (P2PE), 3DS Assessor

Schedule a call with an expert