PCI DSS Security Maturity Model·AWS v1.1.0

Drag to explore · pinch to zoom
Home / Matrix / Requirement 5 / c5.4
Optimized Incident ResponseSecurity 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.4 Automated response to malware detection

Automate isolation and response to malware detections to minimize exposure time and demonstrate timely handling of threats.

Quick Wins
Foundational
Efficient
Optimized
Effort: High Impact: Medium 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

Define playbooks that, on GuardDuty Malware Protection findings, isolate the instance (quarantine security group), take forensic snapshots, and notify. Orchestrate with EventBridge + Lambda or Step Functions. Log every action for evidence.

Practical implementation

How this control is implemented in each reference architecture:

Reach the optimized state: on a malware finding, automatically isolate, snapshot for forensics, and notify, so exposure time is minimal and the response is evidenced.

  1. Match GuardDuty Malware Protection findings with an EventBridge rule that invokes the response function.
    Account automation GuardDuty EventBridge
  2. In the Lambda (or Step Functions) playbook, move the instance to a quarantine security group (deny all), take an EBS snapshot for forensics, and notify the team.
    App tier (CDE) / Data tier (CDE) AWS Lambda Step Functions Amazon EC2
  3. Log every action taken so the response is auditable.
    Account logging CloudTrail Amazon S3

How to validate: A simulated malware finding triggers the playbook: the instance lands in the quarantine SG, a forensic snapshot exists, and the notification and action log are recorded.

Avoid: Deleting a suspected-compromised instance immediately. Snapshot first for forensics, then isolate; destroying it loses the evidence.

Single-account, 3-tier →

Run one central malware-response playbook driven by the org-wide GuardDuty stream, able to isolate a compromised instance in any CDE account.

  1. Drive the response playbook (EventBridge + Lambda/Step Functions) from the security tooling account off the org-wide GuardDuty findings stream.
    Security tooling account GuardDuty EventBridge Step Functions
  2. Use a scoped cross-account IAM role so the security account can quarantine and snapshot an instance in any CDE account.
    Security tooling account → CDE accounts AWS Lambda Amazon EC2
  3. Deliver the action log and forensic artifacts to the central log-archive account.
    Log archive account Amazon S3 CloudTrail

How to validate: A simulated finding in any CDE account triggers the central playbook, which isolates and snapshots the instance cross-account and records the action centrally.

Avoid: Duplicating the response automation in every account. Centralize the playbook with a cross-account role so behavior is consistent and maintained once.

Multi-account with a dedicated PCI OU →

PCI validation

Testing methods: examineobserve

Testing procedures

  • Examine anti-malware configurations and logs/scan results to verify the solution is active and detects/addresses malware, and that logs are retained per Requirement 10.5.1 (5.3.2.c, 5.3.4).

Evidence in AWS

  • Definition of malware response playbooks (EventBridge/Lambda/Step Functions).
  • Execution history of isolation and notification on findings.
  • Forensic snapshots and records of the actions taken.

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

Amazon GuardDuty Amazon EventBridge AWS Lambda AWS Step Functions

Learning resources

References

  • AWS Security Maturity Model: Automate response to findings