PCI DSS 5.3.2: The anti-malware solution(s)
PCI DSS v4.0.1 control 5.3.2: the requirement in full, the 3 testing procedures an assessor uses to verify it, and the related controls in section 5.3.
Requirement 5: Protect All Systems and Networks from Malicious Software › Section 5.3
The anti-malware solution(s):
- Performs periodic scans and active or real-time scans. OR
- Performs continuous behavioral analysis of systems or processes.
Summary
Either scan periodically and in real time, or run continuous behavioural analysis. One or the other, not neither.
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.3.2.a | Examine anti-malware solution(s) configurations, including any master installation of the software, to verify the solution(s) is configured to perform at least one of the elements specified in this requirement. |
| 5.3.2.b | Examine system components, including all operating system types identified as at risk for malware, to verify the solution(s) is enabled in accordance with at least one of the elements specified in this requirement. |
| 5.3.2.c | Examine logs and scan results to verify that the solution(s) is enabled in accordance with at least one of the elements specified in this requirement. |
An either/or, and choosing deliberately between the two branches has consequences beyond this control. Take periodic plus active or real-time scanning and you also acquire 5.3.2.1, which requires a targeted risk analysis justifying the scan frequency. Take continuous behavioural analysis and 5.3.2.1 does not apply at all, because there is no periodic frequency to justify. That is a real simplification and it is easy to miss when reading the controls in order. Note also how the three procedures divide: 5.3.2.a examines the configuration including any master installation, meaning the central policy, while 5.3.2.b examines system components and 5.3.2.c examines logs and scan results. A correct central policy with drifted endpoints passes the first and fails the other two.
What to prepare
- The central anti-malware policy, and which branch of the either/or it implements.
- Endpoint-level evidence for a sample across every at-risk operating system type.
- Logs and scan results, which are examined separately from configuration.
- The list of at-risk components, so coverage can be judged against it.
How to implement it
1. Choose the branch on purpose. If behavioural analysis covers your estate, saying so removes 5.3.2.1 and the risk analysis behind it.
2. Check the endpoints, not the console policy. 5.3.2.b examines system components including every at-risk operating system type, and policy drift is invisible from the centre.
3. Cover the less common platforms. The requirement names all operating system types identified as at risk, which usually means the estate's handful of unusual machines are exactly what gets sampled.
4. Keep the scan results. 5.3.2.c examines logs and results, so a solution operating correctly with no retained output is hard to evidence.
Where this commonly fails
- A correct central policy with endpoints that drifted out of it.
- Real-time protection on and periodic scanning never configured, where the chosen branch requires both.
- Minority platforms uncovered because the deployment tooling does not reach them.
- Choosing periodic scanning by default and inheriting 5.3.2.1 without noticing.
Related controls
Others in section 5.3:
| Control | What it requires |
|---|---|
| 5.3.1 | The anti-malware solution(s) is kept current via automatic updates |
| 5.3.2.1 | If periodic malware scans are performed to meet Requirement 5.3.2… |
| 5.3.3 | For removable electronic media, the anti-malware solution(s)… |
| 5.3.4 | Audit logs for the anti-malware solution(s) are enabled and retained in accordance… |
| 5.3.5 | Anti-malware mechanisms cannot be disabled or altered by users, unless specifically documented… |
← 5.3.1 · All controls · 5.3.2.1 →
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.