PCI DSS Security Maturity Model·AWS v1.1.0

Drag to explore · pinch to zoom
Home / Matrix / Requirement 5 / c5.2
Foundational Infrastructure ProtectionSecurity domain from the AWS Cloud Adoption Framework (CAF) Security Perspective, used to organize the controls. 🤝 SharedAWS Shared Responsibility Model: who implements and operates this control. Customer = you own it; AWS = AWS operates it and you inherit it; Shared = both have obligations.

c5.2 Deploy maintained and monitored anti-malware/EDR on instances

Install and maintain anti-malware/EDR solutions on at-risk system components, with automatic updates, active execution, and audit-log generation, without allowing users to disable them.

Quick Wins
Foundational
Efficient
Optimized
Effort: Medium Impact: High Applies to CDE: Yes

Requirement 5

Protect All Systems and Networks from Malicious Software

PCI sub-requirements coveredCoverage shown per PCI DSS v4.0.1 sub-control. “Covered” = addressed by this AWS recommendation. “Roadmap” = technical, planned. “Your responsibility” = organizational/process control. “Out of scope” = physical or third-party control not implemented in AWS.

5.2 Malicious software is prevented, or detected and addressed
  • 5.2.1 Anti-malware deployed on all system components at risk Covered
  • 5.2.2 Anti-malware detects/removes/blocks all known malware types Covered
  • 5.2.3 System components not at risk are evaluated periodically Your responsibility
  • 5.2.3.1 Frequency of periodic evaluations defined by targeted risk analysis Your responsibility
5.3 Anti-malware mechanisms and processes are active, maintained, and monitored
  • 5.3.1 Anti-malware kept current via automatic updates Covered
  • 5.3.2 Anti-malware performs periodic scans and active/real-time scanning Covered
  • 5.3.2.1 Scan frequency defined by targeted risk analysis (if applicable) Your responsibility
  • 5.3.3 Anti-malware for removable media scans/behavioral analysis Covered
  • 5.3.4 Audit logs for anti-malware enabled and retained Covered
  • 5.3.5 Anti-malware cannot be disabled/altered by users unless authorized Covered

How to implement on AWS

Deploy the EDR/anti-malware agent through SSM Distributor and State Manager to ensure presence and an up-to-date version on all instances. Prevent deactivation by end users. Centralize agent logs and health status. Keep signatures/mechanisms updated automatically.

Practical implementation

How this control is implemented in each reference architecture:

Put a maintained anti-malware/EDR agent on every at-risk instance, keep it updated and running, and stop users from turning it off.

  1. Deploy the EDR/anti-malware agent to the app- and data-tier instances with SSM Distributor, and keep it present and current with a State Manager association.
    App tier (CDE) / Data tier (CDE) Systems Manager
  2. Harden the instance so end users cannot disable or alter the agent (locked service, IAM/OS controls).
    App tier (CDE) / Data tier (CDE) Amazon EC2
  3. Centralize the agent's logs and health status in CloudWatch for monitoring and evidence.
    Account logging CloudWatch

How to validate: SSM State Manager reports the agent installed, running, and current on every in-scope instance, and its logs are flowing to CloudWatch.

Avoid: Installing the agent once in the AMI and never checking it runs. Enforce presence/version continuously with State Manager so it cannot silently drift or be disabled.

Single-account, 3-tier →

Manage one EDR deployment and version baseline centrally so every CDE account runs the same maintained agent, with health rolled up.

  1. Manage the EDR install and version baseline with shared SSM documents / State Manager associations distributed to all CDE accounts.
    Security tooling account → PCI OU Systems Manager AWS Organizations
  2. Enforce the same no-disable hardening across accounts.
    Each CDE workload account Amazon EC2
  3. Roll agent health and compliance status up to the security tooling account.
    Security tooling account Security Hub

How to validate: Every CDE account's State Manager shows the same agent version compliant, and health status is visible centrally.

Avoid: Each team choosing its own EDR and version. Divergent agents create coverage gaps; standardize and distribute one maintained baseline.

Multi-account with a dedicated PCI OU →

PCI validation

Testing methods: examineobserve

Testing procedures

  • Examine anti-malware configurations, including the master installation, to verify automatic updates are enabled and definitions are current (5.3.1.a, 5.3.1.b).
  • Examine configurations and scan results to verify the solution performs periodic scans or continuous behavioral analysis (5.3.2.a, 5.3.2.c).
  • Examine configurations and interview personnel to verify anti-malware mechanisms cannot be disabled/altered by users unless documented and authorized by management for a limited time (5.3.5.a, 5.3.5.b).

Evidence in AWS

  • SSM State Manager compliance report showing the agent installed and updated on all instances.
  • Configuration that prevents end users from deactivating the agent.
  • Anti-malware agent logs centralized in CloudWatch.

Customized approach

Requires a targeted risk analysis (Req 12.3.2).

Customized Approach Objective

  • 5.2 — Automated mechanisms are implemented to prevent systems from becoming an attack vector for malware.
  • 5.3 — Anti-malware mechanisms can detect and address the latest malware threats.

AWS services

AWS Systems Manager Amazon EC2 Amazon CloudWatch

Learning resources

References

  • AWS Security Maturity Model: EDR / anti-malware