Multi-service remediation

In addition to AWS Security Hub CSPM control findings (identified by control IDs such as S3.1 or IAM.7), the solution can remediate findings from additional AWS security services. These findings are categorized by service name, finding type, and resource type rather than by a Security Hub control ID. The preprocessor maps each service and finding type to the appropriate remediation. Multi-service remediations use the same two-tier runbook architecture, ingestion, and orchestration flow as control-based remediations. Configure them the same way through the Remediation Configuration Amazon DynamoDB table.

This release supports one finding type per service:

Service	Control ID	Supported resource types	Remediation	Manual follow-up required
Amazon Inspector	Inspector.InstanceVulnerability	EC2 instances managed by AWS Systems Manager	Runs the AWS-RunPatchBaseline Systems Manager command to install the specific vulnerable packages identified in the finding. The Systems Manager Agent must be version 2.0.834.0 or later.	No
Amazon GuardDuty	GuardDuty.IAMUser	IAM access keys	Contains the potentially compromised IAM user by disabling its access keys, removing console access, and attaching a deny-all policy, using the AWS-managed AWSSupport-ContainIAMPrincipal runbook. The solution backs up the original configuration so you can roll back the containment from the Web UI.	Yes
Amazon Macie	Macie.SensitiveDataS3Object	S3 buckets containing objects with sensitive data	Enables S3 Block Public Access on the bucket to prevent public exposure of the sensitive data.	Yes

Manual follow-up required

The Amazon GuardDuty and Amazon Macie remediations are a first line of defense and do not resolve the underlying finding. They contain or limit exposure of the affected resource, but a security team must investigate and complete service-specific follow-up before resolving the finding. The finding remains visible in the solution for that follow-up.

For GuardDuty.IAMUser, the containment can be rolled back from the Web UI. If auto-remediation is enabled for the control, the Web UI warns you when you start a rollback that the solution might re-remediate the finding, because rolling back leaves the finding eligible for the solution to act on again. Disable auto-remediation for the control before rolling back if you want the rollback to persist.

Because a rollback restores the resource to its pre-remediation (non-compliant) state, the underlying finding remains unresolved. Re-enabling auto-remediation for the control while that finding is still unresolved makes it eligible again, so the solution re-applies the remediation the next time AWS Security Hub emits an event for the finding. Keep auto-remediation disabled for the control until you have investigated and resolved the underlying finding.

GuardDuty.IAMUser temporary credentials

The AWSSupport-ContainIAMPrincipal runbook contains a long-term IAM user (its access key ID begins with AKIA). A GuardDuty.IAMUser finding whose compromised principal is a temporary credential from an assumed-role or federated session — its access key ID begins with ASIA — has no IAM user to contain, so every remediation attempt would fail. The solution does not automatically remediate these findings; it records them for visibility but never triggers the remediation. Investigate the originating role or identity provider and revoke the active session directly.

GuardDuty.IAMUser rollback button in the Web UI Remediation History

GuardDuty.IAMUser rollback warning in the Web UI

Finding formats

Security Hub represents findings in two schema formats, and the solution processes both:

• ASFF (AWS Security Finding Format) – The format used by AWS Security Hub CSPM (Classic). The solution processes AWS Security Hub CSPM control findings in ASFF.

• OCSF (Open Cybersecurity Schema Framework) – The format used by AWS Security Hub v2. The solution processes Amazon Inspector, Amazon GuardDuty, and Amazon Macie findings in their native OCSF format.

Rather than forcing every finding into a single schema, the solution processes each finding in the format its source service emits. Existing remediations that use AWS Config continue to work unchanged in ASFF, while multi-service findings are processed in their native OCSF format.