PCI DSS 5.2.2: The deployed anti-malware solution(s)

PCI DSS v4.0.1 control 5.2.2: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 5.2.

Requirement 5: Protect All Systems and Networks from Malicious Software › Section 5.2

The deployed anti-malware solution(s):

  • Detects all known types of malware.
  • Removes, blocks, or contains all known types of malware.

Summary

The anti-malware you run has to be able to detect every known type of malware, and to remove, block or contain it.

What the assessor will examine

These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.

Procedure
5.2.2 Examine vendor documentation and configurations of the anti-malware solution(s) to verify that the solution: • Detects all known types of malware. • Removes, blocks, or contains all known types of malware.

This is about the capability and configuration of the solution, not about whether it has caught anything. 5.2.1 asks where anti-malware runs; 5.2.2 asks what it can do when it is there. The two bullets are tested separately, and the second one is where products fail: a tool that detects and alerts, but is deployed in monitor-only mode, satisfies the first bullet and fails the second. Note also that the procedure examines vendor documentation and configurations, so a capable product with the capability switched off does not pass on the datasheet alone.

What to prepare

  • Vendor documentation stating the malware types the product detects and what it does on detection.
  • The actual policy or configuration applied to each system class, showing the response action rather than the default.
  • A list of any systems where the product is deployed in a reduced or monitor-only mode, with the reason.

How to implement it

1. Check the response action, not just the deployment. Detect-only is a common state after a rollout, because it is how you avoid breaking things during a pilot, and it is a state pilots are frequently left in.

2. Cover the malware types the standard names, including the ones signature scanning misses. Ransomware, spyware, rootkits, scripts and cryptominers all appear in current definitions of "known types", and a product scoped to file viruses is a partial answer.

3. Keep the vendor documentation with the evidence. This is one of the few controls where the assessor is examining what the vendor says the product does, so having it to hand shortens the conversation.

4. Record any exclusions. Performance exclusions on directories or processes are ordinary and defensible, and undocumented ones look like gaps in coverage.

Where this commonly fails

  • An endpoint product left in detect-only or audit mode after deployment, so nothing is removed, blocked or contained.
  • Broad path exclusions added to fix a performance complaint and never reviewed, quietly removing coverage.
  • Relying on a signature-only product on servers while the standard expects all known types.
  • Assuming this control is satisfied by 5.2.1, when coverage and capability are assessed separately.

Others in section 5.2:

Control What it requires
5.2.1 An anti-malware solution(s) is deployed on all system components…
5.2.3 Any system components that are not at risk for malware are evaluated periodically…
5.2.3.1 The frequency of periodic evaluations of system components identified as not at risk…

5.2.1 · All controls · 5.2.3

Source

The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.

The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.