The number of assessment testing procedures for anti-malware doubled – it went from 18 to 36, including a major new requirement!
Many of my clients, both merchants and service providers, are asking about the changes in the new version of the PCI DSS v4.0 which launched on March 31st, 2022. Most are concerned about how the changes are going to affect their compliance and what the new requirements are going to cost to implement.
While there are some general changes across the standard, such as the introduction of the customized approach and a requirement to define roles and responsibilities in each of the 12 requirements, in this blog I’m focusing on the most significant changes to Requirement 5: Protect all systems and networks from malicious software.
Along with the title change of PCI DSS Requirement 5 (it was previously Protect all systems against malware and regularly update anti-virus software or programs), the number of assessment testing procedures went from 18 to 36, including a major new requirement. Below I have identified four things you need to know about the new and updated requirements.
Note: In recognition of the significant effort required to implement some of these changes, and as was done on previous PCI DSS versions, some of the changes are listed initially as “best practices” and don’t need to be complied with until March 31, 2025.
In my opinion, the new requirements and options around malware detection are a bit of a mixed bag of good and bad news, but it’s mostly good.
Requirement 5.3.2 adds the option for using “next-gen” anti-malware solutions to perform continuous detection based on behavioural analysis of systems and processes.
These “next-gen” tools can run without any real-time or scheduled scanning; the term “blocks or contains” in Requirement 5.2.2 allows organizations to move beyond traditional malware protection methodologies. This change allows the use of alternative malware protection methods that do not involve virus definition files or the removal of malware. This is a big win for organizations with production systems that have resources impacted by traditional anti-malware scanning activity, as well as for those that want to use antimalware solutions such as Carbon Black, Crowd Strike, SentinelOne, or RSA NetWitness.
Conversely, for those running traditional (scanning) anti-malware tools, you will now need to do both periodic and real-time scanning, per Requirement 5.3.2, which could introduce additional load to in-scope systems. Most modern anti-malware platforms already include both, so in practice, this likely isn’t anything new.
|
|
“Behavior-based malware detection evaluates an object based on its intended actions before it can actually execute that behavior. An object’s behavior, or in some cases its potential behavior, is analyzed for suspicious activities. Attempts to perform actions that are clearly abnormal or unauthorized would indicate the object is malicious, or at least suspicious.” - John Cloonan, Director of Products, Lastline |
|
Throughout PCI DSS v4.0, the requirement for a “targeted risk analysis” has been added to many existing requirements, allowing the DSS to be better adapted to organizations with different threat landscapes and vulnerabilities.
Requirement 5 includes two requirements that specify a targeted risk analysis:
1. If you have systems “not at risk for malware” in scope, you must define the frequency of periodic evaluations of system components (Requirement 5.2.3.1) to ensure they are still not at risk for malware.
2. If you are performing periodic and real-time malware scans rather than continuous behavioral analysis, the frequency of the periodic malware scans (Requirement 5.3.2.1) must be supported by a targeted risk analysis. (Best practice until March 31, 2025.)
Unless you’re a risk management guru (and even if you are), you’re going to want to read another of our blogs, Targeted Risk Assessments; Know Thy Risks; this blog looks at risk using lions in the African savanna as a metaphor.
Another new requirement (best practice until March 31, 2025) is that removable electronic media must be automatically scanned when the media is inserted, connected, or logically mounted. The wording of the requirement, the testing procedures, and the guidance in Requirement 5.3.3 all indicate a requirement to scan the entire media/device upon connection, and not merely scan files on access.
Most anti-malware solutions can be configured to do this, though the functionality is usually disabled by default due to user experience implications; scanning a large USB drive with many files can take substantial time, and be quite inconvenient when it happens as soon as you plug in your USB thumb drive.
As with other anti-malware requirements in PCI DSS v4.0, continuous behavioural analysis is an alternative method to address the need to scan removable electronic media; as long as your anti-malware solution “Performs continuous behavioral analysis of systems or processes when the media is inserted, connected, or logically mounted,” you are not required to enable an automatic scan of media upon insertion, connection, or logical mounting.
As an organization, do you have technical controls in place to protect users from phishing attacks?
I suspect the vast majority of organizations do not, and therefore most will need to implement new tools to meet Requirement 5.4.1. These tools must be more than simple warnings about potential phishing (such as a visible warning when a message comes from an external sender); the requirement is for processes and automated mechanisms that cannot just detect phishing attempts but will actually protect end-users.
By adding this requirement, the PCI Security Standards Council has acknowledged that email is a major attack vector and the most successful attack is phishing. Thankfully, this new requirement does not need to be implemented immediately; it is considered best practice until March 31, 2025, so we have some time to figure out the most cost-effective way to meet it.
While attacks will keep coming, there are solutions out there today, and some cloud-based solutions like Gmail and Microsoft Defender for Office365 already have anti-phishing options included.
There are two key takeaways here that I would suggest you have on your radar:
All product names, trademarks, and registered trademarks are the property of their respective owners. No compensation related to the mention of these products was received by Online Business Systems or the author, and any mention of product names or solutions should not be considered an endorsement.