Thomas Haggath — AWS Security Writing

Leveraging Macie suppression rules to eliminate noise

2026-05-10T00:00:00Z

What is Amazon Macie?

Amazon Macie is a fully managed data security service that uses machine learning to automatically discover, classify, and protect sensitive data in Amazon S3 — covering PII, financial data, credentials, and custom data types you define.

Amazon Macie is a fully managed data security and data privacy service that uses machine learning and pattern matching to discover, monitor, and protect sensitive data stored in Amazon S3. Where GuardDuty focuses on threats to your infrastructure, Macie focuses on the data itself: what sensitive information exists in your S3 estate, where it lives, and whether it is adequately protected.

When you enable Macie, it automatically builds and maintains an inventory of your S3 general purpose buckets in the current region, evaluating each one for security and access control issues. Beyond bucket-level monitoring, Macie can inspect the contents of objects inside those buckets to detect sensitive data through two mechanisms:

Automated sensitive data discovery: Macie continuously and intelligently samples objects across your S3 estate, building a picture of where sensitive data lives without you needing to configure individual jobs
Sensitive data discovery jobs: targeted jobs you configure to scan specific buckets, prefixes, or object sets on a schedule or on demand

Macie can detect a broad range of sensitive data types out of the box, including personally identifiable information (PII), personal health information (PHI), financial data such as credit card and bank account numbers, and credentials such as AWS secret access keys. You can also define your own custom data identifiers using regex patterns and keyword lists to catch organisation-specific data formats.

When Macie detects a potential issue, it generates a finding: a detailed report describing the affected resource, the type of sensitive data or policy violation involved, and the severity.

Example Macie Finding Types

Macie generates two categories of findings: policy findings for bucket misconfigurations (public access, disabled encryption), and sensitive data findings for actual sensitive content detected inside S3 objects.

Macie generates two distinct categories of findings: policy findings and sensitive data findings. They serve different purposes and are generated by different parts of the service.

Policy Findings

Policy findings report potential security or privacy misconfigurations on your S3 buckets. Macie generates these continuously as part of its ongoing bucket monitoring, independent of any discovery jobs.

Policy:IAMUser/S3BlockPublicAccessDisabled: block public access settings have been disabled on a bucket, potentially exposing its contents to the internet
Policy:IAMUser/S3BucketEncryptionDisabled: default server-side encryption has been disabled on a bucket
Policy:IAMUser/S3BucketPublic: a bucket's ACL or policy grants public read or write access
Policy:IAMUser/S3BucketReplicatedExternally: bucket replication is configured to send data to a bucket in a different AWS account
Policy:IAMUser/S3BucketSharedExternally: a bucket policy grants access to a principal in a different AWS account or to anonymous users

Sensitive Data Findings

Sensitive data findings report the detection of sensitive content inside S3 objects. These are generated when Macie inspects object contents, either through automated discovery or a discovery job.

SensitiveData:S3Object/Credentials: the object contains sensitive credentials data, such as AWS secret access keys or private keys
SensitiveData:S3Object/Financial: the object contains financial information such as credit card numbers, bank account numbers, or similar data
SensitiveData:S3Object/Personal: the object contains personally identifiable information (PII) or personal health information (PHI), such as passport numbers, national insurance numbers, or medical record identifiers
SensitiveData:S3Object/CustomIdentifier: the object contains text matching the detection criteria of one or more custom data identifiers you have defined
SensitiveData:S3Object/Multiple: the object contains more than one category of sensitive data across any combination of the above types

Severity Scoring

Macie scores findings on a three-tier scale: Low, Medium, and High. The score is influenced by factors including the type of sensitive data detected, the number of occurrences, and the security posture of the bucket containing the object. A SensitiveData:S3Object/Credentials finding in a publicly accessible bucket will score higher than the same finding type in a private, encrypted bucket.

What are Suppression Rules?

A Macie suppression rule is a saved filter that automatically archives matching findings at generation time — removing them from your active queue without deleting them. Suppressed findings are not forwarded to Security Hub or EventBridge.

A suppression rule in Macie is a saved set of filter criteria that automatically archives any new finding matching those criteria. Like GuardDuty, Macie continues to generate the finding and stores it for 90 days, but it is immediately moved to the archived state and does not appear in your active findings queue.

How they work

Suppression rules are built on Macie's finding filter system. You define one or more conditions using finding attributes, and Macie evaluates every new finding against all active suppression rules at generation time. If a finding matches, it is archived immediately.

Filter conditions can be built using fields across two categories:

Field category	Examples
Common fields	Finding type, severity, region, account ID, resource ARN
Classification fields	Sensitive data category, sensitive data type, job ID, custom identifier name

You can combine multiple conditions with AND logic to build precise rules. For example, you could suppress all SensitiveData:S3Object/Personal findings only from a specific bucket used for anonymised test data, while keeping the finding active for all other buckets.

Why use them?

In environments with large S3 estates, Macie findings accumulate quickly. Common sources of recurring noise include:

Buckets containing known test or synthetic data that intentionally resembles PII
Internal tooling buckets that store credentials or keys as part of normal operations
Data science or analytics buckets where financial data is expected and already governed
Buckets scanned repeatedly by scheduled jobs where the sensitive data is known and accepted

Without suppression rules, your team spends time reviewing findings they have already triaged, which erodes confidence in the signal Macie produces.

Suppressed findings are not forwarded to AWS Security Hub or Amazon EventBridge, so your downstream alerting and ticketing systems stay clean.

Important consideration

Suppression rules archive findings after they are generated. If your automated sensitive data discovery or discovery jobs are generating high volumes of findings from known-good data, suppression rules reduce the noise in your queue but Macie still performs the inspection and counts the data. For data you know is safe and want Macie to ignore entirely at inspection time, allow lists are the more efficient tool.

Macie Allow Lists

A Macie allow list defines text or regex patterns that Macie should ignore during S3 inspection — preventing findings from being generated in the first place, rather than archiving them after the fact.

An allow list in Macie defines specific text or text patterns that you want Macie to ignore when it inspects S3 objects for sensitive data. Where suppression rules operate after a finding is generated, allow lists operate before: if Macie finds text that matches an entry in an allow list, it does not report that occurrence in findings, statistics, or discovery results at all.

Macie supports two types of allow list:

Predefined Text Lists

A predefined text list contains exact strings that Macie should ignore. This is useful for known values that are not actually sensitive in your context but would otherwise match a managed data identifier: sample account numbers used in documentation, anonymised test identifiers, or internal reference codes that follow a format Macie recognises as financial data.

Each entry in the list must be an exact match. Macie performs a case-sensitive comparison against the text it finds in the object.

Regular Expression (Regex) Lists

A regex list defines a pattern that Macie should ignore across all inspected objects. This is the more flexible option and suits cases where the exempted data follows a consistent format:

Your organisation's public phone numbers or email addresses
Patterned sample data used across test environments
Internal employee or customer ID formats that follow a proprietary schema

You store the regex or text list as a file in S3, and Macie reads it from there when performing inspections.

Usage

After creating an allow list you attach it to one or more sensitive data discovery jobs or to your automated sensitive data discovery settings. Macie then applies the list during every inspection covered by those jobs or that discovery configuration.

Limits

Up to 1,000 allow lists per Macie account per region
Predefined text lists: up to 100,000 entries per list
Regex lists: one pattern per list, stored as a plain-text file in S3
The Macie service role must have s3:GetObject permission on the bucket storing the list file

The Difference Between Allow Lists and Suppression Rules

Allow lists act at inspection time and prevent findings from being created; suppression rules act after generation and archive the finding immediately. Use allow lists for content you never want reported; use suppression rules for context-specific false positives where you still want the audit trail.

Both allow lists and suppression rules reduce noise in Macie, but they work at different points in the pipeline and have meaningfully different effects.

	Allow Lists	Suppression Rules
When it acts	At inspection time, before a finding is created	After finding generation, immediately archives it
Finding created?	No - the occurrence is excluded from results entirely	Yes - created and then archived, stored for 90 days
Scope	Specific text or patterns within object content	Any finding attribute (type, severity, bucket, account, job, etc.)
Applies to	Sensitive data findings only	Both policy findings and sensitive data findings
Forwarded downstream?	N/A - no finding exists to forward	Suppressed findings are not sent to Security Hub or EventBridge
Best used for	Known-safe data patterns you never want reported	Known false positives scoped by resource, finding type, or job

When to use each

Use an allow list when you have specific text or patterns that are genuinely not sensitive in your environment - test data, internal formats, or public contact details that happen to match a Macie managed identifier. Allow lists prevent Macie from ever flagging that content, which keeps your sensitive data statistics clean and avoids generating findings you will only suppress anyway.

Use a suppression rule when the finding itself is valid but irrelevant to your operations in a specific context: a known-good bucket that stores credentials as part of its design, a replication rule that intentionally sends data to an external account you own, or a policy finding type that your security posture accepts for a defined set of resources.

In practice, allow lists handle content-level exemptions and suppression rules handle context-level exemptions. Using both together gives you precise control over what Macie surfaces without losing the audit trail that archived findings provide.

Example Finding: Sensitive Credentials Detected in S3

SensitiveData:S3Object/Credentials fires when Macie detects AWS secret access keys, private keys, or authentication tokens inside an S3 object — one of Macie's highest-priority finding types given how commonly exposed credentials lead to account compromise.

The finding type SensitiveData:S3Object/Credentials fires when Macie detects content matching credentials patterns (such as AWS secret access keys, private keys, or authentication tokens) inside an S3 object. This is one of Macie's highest-priority finding types since exposed credentials in S3 are a common and high-impact misconfiguration.

{
  "schemaVersion": "1.0",
  "accountId": "123456789012",
  "region": "eu-west-1",
  "partition": "aws",
  "id": "b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5",
  "type": "SensitiveData:S3Object/Credentials",
  "title": "The S3 object contains AWS credentials",
  "description": "The S3 object contains text that matches detection criteria for AWS secret access keys.",
  "severity": {
    "score": 90,
    "description": "High"
  },
  "createdAt": "2026-05-10T11:22:10Z",
  "updatedAt": "2026-05-10T11:22:10Z",
  "resourcesAffected": {
    "s3Bucket": {
      "arn": "arn:aws:s3:::my-app-deployment-artifacts",
      "name": "my-app-deployment-artifacts",
      "publicAccess": {
        "effectivePermission": "NOT_PUBLIC"
      },
      "defaultServerSideEncryption": {
        "encryptionType": "AES256"
      }
    },
    "s3Object": {
      "bucketArn": "arn:aws:s3:::my-app-deployment-artifacts",
      "key": "configs/production/app-config.env",
      "size": 2048,
      "serverSideEncryption": {
        "encryptionType": "AES256"
      },
      "lastModified": "2026-05-09T08:14:00Z"
    }
  },
  "classificationDetails": {
    "jobArn": "arn:aws:macie2:eu-west-1:123456789012:classification-job/abc123def456",
    "result": {
      "status": {
        "code": "COMPLETE"
      },
      "sensitiveData": [
        {
          "category": "CREDENTIALS",
          "detections": [
            {
              "type": "AWS_CREDENTIALS",
              "count": 2,
              "occurrences": {
                "lineRanges": [
                  { "start": 14, "end": 14 },
                  { "start": 27, "end": 27 }
                ]
              }
            }
          ],
          "totalCount": 2
        }
      ],
      "sizeClassified": 2048
    }
  }
}

Key fields to note:

type: the finding identifier, your primary filter attribute when writing suppression rules
severity.score: Macie uses a numeric score (0-100) mapped to Low, Medium, or High; 90 indicates a high-confidence, high-impact detection
resourcesAffected.s3Object.key: the exact object path where the sensitive data was found, critical for triage
classificationDetails.result.sensitiveData: the breakdown of what was detected, including category, specific type (AWS_CREDENTIALS), and occurrence count
classificationDetails.result.sensitiveData.detections.occurrences.lineRanges: the line numbers within the object where matches were found, giving you a precise location to investigate
resourcesAffected.s3Bucket.publicAccess.effectivePermission: shows NOT_PUBLIC here, which reduces severity somewhat; the same finding in a public bucket would score higher

GuardDuty Suppression Rules: Reduce Alert Noise on AWS

2026-05-10T00:00:00Z

What is GuardDuty?

Amazon GuardDuty is a continuous threat detection service that monitors AWS accounts, workloads, and data by analysing CloudTrail events, VPC Flow Logs, and DNS query logs — with no agents or additional software to deploy.

Amazon GuardDuty is a continuous threat detection service that monitors, analyses, and processes data sources and logs across your AWS environment. It uses threat intelligence feeds (such as lists of malicious IP addresses, domains, and file hashes) combined with machine learning models to identify suspicious and potentially malicious activity without requiring you to deploy or manage any additional security software.

When enabled, GuardDuty automatically begins ingesting foundational data sources including AWS CloudTrail management events, VPC Flow Logs, and DNS query logs. Beyond these defaults, GuardDuty offers dedicated protection plans that extend coverage to additional services:

EKS Protection: audits Kubernetes API server logs for your EKS clusters
RDS Protection: monitors login activity for Amazon Aurora databases
S3 Protection: analyses CloudTrail data events for S3 object-level activity
Malware Protection: scans EBS volumes or S3 objects for malicious files
Lambda Protection: inspects network activity from Lambda function invocations
Runtime Monitoring: captures OS-level, network, and file events from EC2, ECS, and EKS workloads

When a potential threat is identified, GuardDuty generates a finding: a detailed security alert containing information about the affected resource, the threat actor, and the severity of the activity.

Example GuardDuty Finding Types

GuardDuty finding types follow the format ThreatPurpose:ResourceType/ThreatFamilyName, where the resource type identifies the targeted AWS service and the threat family describes the attack pattern.

Finding types follow the format ThreatPurpose:ResourceType/ThreatFamilyName. The resource type in the name tells you which AWS service was targeted. Below are representative examples across the main categories.

EC2

EC2 findings typically relate to network-level threats observed via VPC Flow Logs and DNS logs.

CryptoCurrency:EC2/BitcoinTool.B!DNS: an EC2 instance is querying a domain associated with cryptocurrency mining pools
Trojan:EC2/BlackholeTraffic: an instance is communicating with an IP address known to be a black-hole used by malware command-and-control infrastructure
UnauthorizedAccess:EC2/TorIPCaller: an EC2 instance is being accessed from a Tor exit node

IAM

IAM findings use GuardDuty's anomaly detection model to flag unusual API call patterns across CloudTrail management events.

UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B: a successful console login from an unusual geographic location
CredentialAccess:IAMUser/AnomalousBehavior: an IAM principal is making API calls in a pattern inconsistent with its historical baseline
Persistence:IAMUser/UserPermissions: an IAM entity is modifying policies or creating new users in a manner consistent with persistence techniques

S3

S3 findings surface data-access threats against your buckets.

Policy:S3/BucketPublicAccessGranted: an IAM principal has disabled block-public-access settings on a bucket
Exfiltration:S3/MaliciousIPCaller: S3 API calls are being made from a known malicious IP address
Discovery:S3/MaliciousIPCaller.Custom: a source IP on your custom threat list is enumerating S3 buckets

EKS

EKS Protection findings come from Kubernetes audit log analysis.

CredentialAccess:Kubernetes/MaliciousIPCaller: a Kubernetes API call to retrieve secrets was made from a known malicious IP
Execution:Kubernetes/ExecInKubernetes: a command was executed inside a running container via kubectl exec
PrivilegeEscalation:Kubernetes/PrivilegedContainer: a privileged container was launched, which could allow a breakout to the underlying host

RDS

RDS Protection findings are generated from login activity to Amazon Aurora clusters.

CredentialAccess:RDS/AnomalousBehavior.SuccessfulLogin: a successful database login from an unusual user or location
CredentialAccess:RDS/MaliciousIPCaller.FailedLogin: failed login attempts originating from a known malicious IP address

Attack Sequences (Extended Threat Detection)

GuardDuty's Extended Threat Detection correlates findings across multiple services and time windows to surface multi-stage attacks as a single high-severity finding.

AttackSequence:IAM/CompromisedCredentials: a sequence of IAM events indicating credential compromise and subsequent lateral movement
AttackSequence:S3/CompromisedData: a chain of events suggesting S3 data was discovered and then exfiltrated
AttackSequence:EKS/CompromisedCluster: correlated signals pointing to a compromised Kubernetes cluster

What are Suppression Rules?

A GuardDuty suppression rule is a filter that automatically archives matching findings — silencing known-good activity without deleting the record. Suppressed findings are stored for 90 days and excluded from Security Hub, EventBridge, and S3 exports.

A suppression rule is a filter you define in GuardDuty that automatically archives any new finding that matches its criteria. Suppressed findings are never deleted. GuardDuty still generates them and stores them for 90 days, but they are immediately moved to the archived state and do not appear in your active findings queue.

How they work

You define a suppression rule using one or more filter attributes (finding type, severity, resource tags, EC2 instance ID, S3 bucket name, etc.) combined with match operators:

Operator	Behaviour
`Equals` / `NotEquals`	Exact match or exclusion
`Matches` / `NotMatches`	Wildcard pattern match
`GreaterThan` / `LessThan`	Numeric comparison (e.g. severity score)

Rules can be as broad as suppressing an entire finding type (e.g. all CryptoCurrency:EC2/* findings) or as granular as suppressing a specific finding type only when it fires against a resource tagged Environment: dev.

Why use them?

In a mature AWS environment, certain findings will reliably represent known-good activity: a penetration testing EC2 instance that legitimately communicates over unusual ports, a NAT gateway that generates high-volume DNS findings, or a deployment pipeline that makes bulk S3 API calls. Without suppression rules, these recurring false positives dilute your signal-to-noise ratio and increase alert fatigue.

Suppressed findings are also excluded from downstream integrations and are not forwarded to AWS Security Hub, Amazon EventBridge, Amazon Detective, or Amazon S3 exports. This means your SIEM, ticketing system, or on-call paging tool stays quiet for findings you have already triaged and accepted.

Important caveat

GuardDuty's Extended Threat Detection relies on individual findings as signals when building attack sequences. Broadly suppressing finding types can prevent attack sequence findings from being generated, because the archived signals are excluded from correlation. Suppress at the most specific level you can; prefer resource-scoped rules over type-wide ones.

GuardDuty IP Sets

GuardDuty IP sets and entity lists let you upload custom IP addresses or domains to either suppress findings from trusted sources or generate findings for known-malicious sources that AWS's built-in feeds may not yet include.

GuardDuty lets you upload custom lists of IP addresses (and domains) to fine-tune its detection behaviour. These lists come in two flavours: Trusted IP lists and Threat Intel lists (also called threat lists), described below.

Both are stored as plain-text files in S3 (one entry per line, supporting CIDR notation for IP ranges) and activated per GuardDuty detector. GuardDuty now recommends using entity lists, which can contain IP addresses, domain names, or both in the same list, over the legacy IP-only format.

Trusted IP Lists

A trusted IP list contains IP addresses or CIDR ranges that you consider safe sources of traffic, such as your corporate VPN egress IPs, an office network, or a known third-party security scanner you have authorised. GuardDuty does not generate findings for activity originating from entries on a trusted IP list.

Trusted lists are useful when you have infrastructure that legitimately behaves in ways that would otherwise trigger findings, and you want to suppress an entire source rather than write individual suppression rules per finding type.

Threat Intel Lists

A threat intel list contains IP addresses or domains you have identified as known malicious sources, such as IP ranges from your own incident response investigations or feeds from a commercial threat intelligence provider. When GuardDuty observes activity involving an entry on a threat list, it generates a finding even if that IP would not otherwise have triggered one.

Threat lists let you operationalise your own threat intelligence and ensure GuardDuty alerts on adversary infrastructure that AWS's built-in feeds may not yet include.

Limits

Up to 6 trusted IP lists and 6 threat intel lists per GuardDuty detector per region
Maximum 200,000 entries per list (IP addresses or CIDRs)
Lists must be stored in S3 and the GuardDuty service role must have s3:GetObject permission on the bucket

The Difference Between Trusted Lists and Suppression Rules

Trusted IP lists prevent findings from being generated at all; suppression rules generate the finding and then immediately archive it. The key practical difference is the audit trail — suppressed findings are stored and queryable for 90 days, while trusted-list activity leaves no finding record.

Both trusted lists and suppression rules can silence GuardDuty findings for known-good activity, but they operate at different layers and have meaningfully different behaviours.

	Trusted IP / Entity Lists	Suppression Rules
Scope	Source IP address or domain	Any finding attribute (type, severity, resource, tags, account, etc.)
Mechanism	Prevents the finding from being generated	Generates the finding, then immediately archives it
Finding stored?	No (the finding is never created)	Yes - archived for 90 days, fully queryable
Attack sequence impact	No signal created, so no correlation possible	Archived signals are excluded from correlation
Downstream forwarding	N/A (nothing to forward)	Suppressed findings are not sent to Security Hub, EventBridge, or S3 exports
Granularity	IP/domain only	Fine-grained: combine multiple attributes with AND logic
Best used for	Trusted infrastructure sources you always want to ignore	Known false positives scoped by resource, tag, region, or finding subtype

When to use each

Use a trusted IP list when the noise originates from a specific, stable set of IP addresses you fully control or trust: your VPN, a penetration testing host, or an authorised scanner. It is the bluntest instrument but requires no maintenance as new finding types emerge.

Use a suppression rule when you need more precision: for example, suppressing CryptoCurrency:EC2/BitcoinTool.B only for instances tagged Purpose: mining-research, while keeping the finding active for all other EC2 instances. Suppression rules also give you the audit trail of archived findings, which trusted lists do not.

In practice, most teams use both: trusted lists for known-good source infrastructure, and suppression rules for finding-type-specific or resource-scoped noise reduction.

Example Finding: IAM Credential Use Outside AWS

UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS is a high-fidelity finding with a low false-positive rate: EC2 instance credentials should never originate from outside AWS infrastructure, so this finding almost always indicates active credential theft.

The finding type UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS fires when instance profile credentials (issued via the EC2 metadata service) are used from an IP address that does not belong to AWS infrastructure. This is a high-fidelity indicator of credential theft, since legitimate use of instance credentials should never originate outside of AWS.

{
  "schemaVersion": "2.0",
  "accountId": "123456789012",
  "region": "eu-west-1",
  "partition": "aws",
  "id": "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4",
  "arn": "arn:aws:guardduty:eu-west-1:123456789012:detector/abc123def456/finding/a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4",
  "type": "UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS",
  "title": "Instance credential used from external IP address not associated with AWS",
  "description": "Credentials created exclusively for EC2 instance i-0abc123def456789a (via role WebAppInstanceRole) were used from external IP address 185.220.101.47, which is not associated with AWS infrastructure.",
  "severity": 8.0,
  "createdAt": "2026-05-10T09:14:32Z",
  "updatedAt": "2026-05-10T09:14:32Z",
  "service": {
    "serviceName": "guardduty",
    "detectorId": "abc123def456",
    "action": {
      "actionType": "AWS_API_CALL",
      "awsApiCallAction": {
        "api": "GetSecretValue",
        "serviceName": "secretsmanager.amazonaws.com",
        "callerType": "Remote IP",
        "remoteIpDetails": {
          "ipAddressV4": "185.220.101.47",
          "organization": {
            "asn": "4244",
            "asnOrg": "Tor Project Exit Node",
            "isp": "Quintex Alliance Consulting",
            "org": "Quintex Alliance Consulting"
          },
          "country": { "countryName": "United States" },
          "city": { "cityName": "Atlanta" },
          "geoLocation": { "lat": 33.749, "lon": -84.388 }
        },
        "affectedResources": {}
      }
    },
    "evidence": {
      "threatIntelligenceDetails": [
        {
          "threatListName": "ProofPoint ET Intelligence",
          "threatNames": ["TorExitNode"]
        }
      ]
    },
    "archived": false,
    "count": 1
  },
  "resource": {
    "resourceType": "AccessKey",
    "accessKeyDetails": {
      "accessKeyId": "ASIAQRSTUVWXYZ123456",
      "principalId": "AROABC123DEF456GHI789:i-0abc123def456789a",
      "userType": "AssumedRole",
      "userName": "WebAppInstanceRole"
    }
  }
}

Key fields to note:

type: the finding identifier, useful as the primary filter attribute in a suppression rule
severity: scored 8.0 (High) on GuardDuty's 1-10 scale; credentials used outside AWS are rarely false positives
service.action.awsApiCallAction.api: the specific API call made with the stolen credentials (GetSecretValue here indicates the attacker was targeting secrets)
service.action.awsApiCallAction.remoteIpDetails: the external IP and enriched geo/ASN data GuardDuty adds automatically
service.evidence.threatIntelligenceDetails: shows the credential was used from a known Tor exit node, corroborating the alert
resource.accessKeyDetails.principalId: the AROA... prefix confirms this is an assumed-role session tied to an EC2 instance, not a long-term IAM user key

AWS Security Hub: ASFF, Severity Normalisation and Cross-Account Aggregation

2026-05-16T00:00:00Z

If you've enabled GuardDuty and Macie in AWS, you already have two separate consoles generating findings in two different formats with two different severity scales. Add Inspector, Config, and a third-party SIEM integration and the problem compounds quickly. Security Hub exists to solve that.

AWS Security Hub is a managed service that pulls findings from 30+ integrations into a single place, translates them into a common format, and gives you one API and console to query across all of them. It doesn't detect threats itself. It aggregates and normalises what other services detect.

At the centre of that normalisation is the Amazon Security Finding Format (ASFF): a standardised JSON schema that every integrated service must map its findings to before Security Hub will accept them. Every finding, regardless of source, ends up with the same set of fields: severity, affected resource, finding type, workflow state.

Beyond aggregation, Security Hub provides two additional capabilities:

Security Hub Controls: managed compliance checks aligned to standards including CIS AWS Foundations Benchmark, PCI DSS, and AWS Foundational Security Best Practices. Each control is a continuously evaluated rule that generates its own ASFF finding when a resource is non-compliant.
Insights: pre-built and custom groupings of findings, useful for surfacing patterns such as "all HIGH findings by affected account" or "all findings for a specific EC2 instance".

Security Hub must be enabled per account and per region. Integrations with GuardDuty, Macie, Inspector, Config, and IAM Access Analyzer are enabled separately within Security Hub after the service is turned on.

Finding Categories

Security Hub classifies every finding using the ASFF Types field — a three-level Namespace/Category/Classifier taxonomy that maps findings from GuardDuty, Macie, Config, and other integrations to a consistent set of threat categories.

Security Hub classifies every finding using the ASFF Types field, which follows a three-level namespace taxonomy: Namespace/Category/Classifier. A finding can carry multiple Types values when it maps to more than one classification.

The five namespaces in use across Security Hub integrations:

Namespace	What it covers	Example sources
`Software and Configuration Checks`	Compliance controls, configuration drift, patch status	Security Hub Controls, AWS Config
`TTPs`	Threat behaviours aligned to MITRE ATT&CK	GuardDuty, third-party integrations
`Sensitive Data Identifications`	Sensitive data discovered in cloud resources	Amazon Macie
`Effects`	The impact of a finding: data exposure, resource consumption	GuardDuty, Macie
`Unusual Behaviors`	Anomalous activity relative to an established baseline	GuardDuty

A GuardDuty finding for a console login from an unusual location might carry both TTPs/Initial Access/Valid Accounts and Unusual Behaviors/User/ConsoleLogin. Two Types values reflecting different facets of the same event.

Security Hub Controls findings always fall under Software and Configuration Checks/Industry and Regulatory Standards or Software and Configuration Checks/AWS Security Best Practices, depending on which standard the control belongs to.

The Amazon Security Finding Format (ASFF)

The Amazon Security Finding Format (ASFF) is the standardised JSON schema that every Security Hub integration must map its findings to — giving every finding from every source the same set of fields, including severity, affected resource, finding type, and workflow state.

ASFF is the JSON schema that all Security Hub findings conform to. Every integrated service must translate its native finding format into ASFF before Security Hub will ingest it. This normalisation is what makes cross-service querying and filtering possible.

The key fields:

Field	Purpose
`SchemaVersion`	Always `2018-10-08`
`Id`	Unique finding ARN within Security Hub
`ProductArn`	ARN of the service that generated the finding: `product/aws/guardduty`, `product/aws/macie`, etc.
`GeneratorId`	Product-specific identifier: the GuardDuty detector ARN, the Config rule name, the Security Hub control ID
`AwsAccountId`	The account the finding relates to. In a multi-account setup, this is the member account, not the aggregator
`Types`	Array of `Namespace/Category/Classifier` strings classifying the finding
`CreatedAt` / `UpdatedAt`	ISO 8601 timestamps; `UpdatedAt` reflects when the originating service last updated the finding
`Severity.Label`	Normalised severity label: `INFORMATIONAL`, `LOW`, `MEDIUM`, `HIGH`, or `CRITICAL`
`Severity.Normalized`	Integer 0-100; the score Security Hub uses to derive `Severity.Label`
`FindingProviderFields.Severity`	The original severity from the source product, preserved alongside the normalised ASFF score
`Resources`	Array of affected AWS resources, each with `Type`, `Id`, `ARN`, `Region`, and optional `Details`
`Compliance`	Present on Security Hub control findings only (contains `Status`: `PASSED`, `FAILED`, `WARNING`, `NOT_AVAILABLE`)
`WorkflowState` / `Workflow.Status`	Triage state: `NEW`, `NOTIFIED`, `RESOLVED`, or `SUPPRESSED`
`RecordState`	`ACTIVE` or `ARCHIVED`; set by the originating service when a finding is no longer relevant

The distinction between RecordState and Workflow.Status trips people up. RecordState is controlled by the originating service. GuardDuty sets a finding to ARCHIVED when it stops observing the behaviour. Workflow.Status is controlled by your team. It reflects where the finding sits in your triage process and is set manually or via Security Hub automation rules. They are independent of each other.

Severity Normalisation

Security Hub maps every integrated service's native severity scale to a Severity.Normalized integer between 0 and 100, deriving a common Severity.Label — INFORMATIONAL, LOW, MEDIUM, HIGH, or CRITICAL — that can be compared across GuardDuty, Macie, Inspector, and other sources in a single query.

Every finding ingested by Security Hub is assigned a Severity.Normalized score between 0 and 100. This score determines the Severity.Label displayed in the console and returned by the API:

Normalized range	Severity.Label
0	`INFORMATIONAL`
1-39	`LOW`
40-69	`MEDIUM`
70-89	`HIGH`
90-100	`CRITICAL`

Each integrated service maps its own native severity scale to this range. For the three AWS services most commonly used together:

Service	Native severity	ASFF Normalized	Label
GuardDuty	Low (1.0-3.9)	1-39	`LOW`
GuardDuty	Medium (4.0-6.9)	40-69	`MEDIUM`
GuardDuty	High (7.0-8.9)	70-89	`HIGH`
GuardDuty	Critical (9.0+)	90-100	`CRITICAL`
Macie	LOW	1-39	`LOW`
Macie	MEDIUM	40-69	`MEDIUM`
Macie	HIGH	70-89	`HIGH`
Inspector	INFORMATIONAL	0	`INFORMATIONAL`
Inspector	LOW	1-39	`LOW`
Inspector	MEDIUM	40-69	`MEDIUM`
Inspector	HIGH	70-89	`HIGH`
Inspector	CRITICAL	90-100	`CRITICAL`

The normalised score gives you a common severity axis across services. What it doesn't give you is context.

A GuardDuty HIGH finding for UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS (Normalized: 80) and a Macie HIGH finding for SensitiveData:S3Object/Credentials (Normalized: 70) both show up as HIGH in Security Hub. The first means someone is actively exfiltrating EC2 instance credentials outside AWS. The second means Macie found AWS credentials embedded in an S3 object. Same label, very different urgency.

This is why ProductArn and Types matter when building filters, suppression rules, or automation. Filtering on Severity.Label = HIGH alone surfaces both. Filtering on ProductArn = product/aws/guardduty AND Severity.Label = HIGH narrows to active threat findings from GuardDuty only.

The original source severity is always available in FindingProviderFields.Severity.Original, which preserves the native score (e.g. "5.0" for a GuardDuty Medium) alongside the normalised value.

Cross-Account Aggregation

Security Hub cross-account aggregation centralises findings from all member accounts into a single administrator account view — one API, one console, one place to query across your entire AWS organisation.

In a multi-account AWS organisation, Security Hub findings are generated locally in each member account. Cross-account aggregation centralises them into a single view without requiring you to log into each account separately.

Delegated Administrator

One account is designated as the Security Hub delegated administrator via AWS Organizations. Typically this is the security tooling or audit account. Member accounts are enrolled automatically (if auto-enable is configured in Organizations) or manually. Once enrolled, each member account's findings are visible to the administrator account.

The AwsAccountId field on each finding identifies the originating member account. In the administrator account's console and API, findings from all members are queryable alongside findings from the administrator account itself.

Aggregation Region

Security Hub findings are regional by default. Cross-region aggregation must be explicitly configured: one region is designated as the aggregation region, and linked regions forward their findings into it. This gives you a single-region view across both accounts and regions.

The aggregation region must be the same region where your delegated administrator is configured. Regions are linked individually.

Filtering by Account

When querying aggregated findings, the AwsAccountId filter attribute scopes results to specific member accounts. This is useful when a known-noisy account, such as a development sandbox or penetration testing account, generates volume that would otherwise dilute signal from production. You can build Security Hub automation rules that apply Workflow.Status = SUPPRESSED to findings from specific accounts matching specific criteria, without affecting the same finding types in other accounts.

Example ASFF Finding

The following UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B finding shows how a GuardDuty alert looks after Security Hub normalises it into ASFF — with the original GuardDuty severity preserved in FindingProviderFields alongside the normalised score.

The following is a GuardDuty UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B finding as it appears in Security Hub after normalisation, in the format returned by the GetFindings API.

{
  "SchemaVersion": "2018-10-08",
  "Id": "arn:aws:securityhub:eu-west-1:123456789012:subscription/guardduty/v1/eu-west-1/123456789012/a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4",
  "ProductArn": "arn:aws:securityhub:eu-west-1::product/aws/guardduty",
  "GeneratorId": "arn:aws:guardduty:eu-west-1:123456789012:detector/abc123def456abc123def456abc123de",
  "AwsAccountId": "123456789012",
  "Types": [
    "TTPs/Initial Access/Valid Accounts",
    "Unusual Behaviors/User/ConsoleLogin"
  ],
  "CreatedAt": "2026-05-10T08:42:17Z",
  "UpdatedAt": "2026-05-10T08:42:17Z",
  "Severity": {
    "Label": "MEDIUM",
    "Normalized": 50,
    "Original": "MEDIUM"
  },
  "FindingProviderFields": {
    "Severity": {
      "Label": "MEDIUM",
      "Original": "5.0"
    },
    "Types": [
      "TTPs/Initial Access/Valid Accounts",
      "Unusual Behaviors/User/ConsoleLogin"
    ]
  },
  "Title": "Successful console login from anomalous location.",
  "Description": "AWS Management Console login was observed from an anomalous location. The principal john.doe successfully authenticated from Spain, which is inconsistent with the geographic baseline established for this user.",
  "Resources": [
    {
      "Type": "AwsIamUser",
      "Id": "arn:aws:iam::123456789012:user/john.doe",
      "Partition": "aws",
      "Region": "eu-west-1",
      "Details": {
        "AwsIamUser": {
          "UserName": "john.doe"
        }
      }
    }
  ],
  "WorkflowState": "NEW",
  "Workflow": {
    "Status": "NEW"
  },
  "RecordState": "ACTIVE"
}

Key fields to note:

ProductArn: product/aws/guardduty identifies the originating service. A Macie finding reads product/aws/macie; a Security Hub control finding reads product/aws/securityhub. This is the primary field for filtering by integration.
GeneratorId: the GuardDuty detector ARN. In multi-account environments with multiple detectors, this identifies which detector fired, which is useful when a specific detector is known to generate noise for a particular finding type.
Types: dual classification. TTPs/Initial Access/Valid Accounts maps to MITRE ATT&CK; Unusual Behaviors/User/ConsoleLogin reflects GuardDuty's anomaly detection model. Both are searchable filter attributes in Security Hub.
Severity.Normalized: 50, placing this in the MEDIUM band (40-69). GuardDuty's native severity of 5.0 maps directly to 50. FindingProviderFields.Severity.Original preserves the native "5.0" alongside the normalised value.
Compliance: absent on threat findings. The field is omitted entirely from the ASFF document, not set to null. Present only on Security Hub control findings, where it carries Status: PASSED | FAILED | WARNING | NOT_AVAILABLE.
Workflow.Status: NEW means the finding hasn't been triaged. Your team or automation rules change this to RESOLVED or SUPPRESSED. Unlike RecordState, this field is yours to manage.
RecordState: ACTIVE means the finding is current. GuardDuty sets this to ARCHIVED when it stops observing the behaviour, independent of your triage state.

Leveraging Amazon EventBridge to invoke Security Automation

2026-05-22T00:00:00Z

GuardDuty identifies threats. Macie surfaces sensitive data exposure. Security Hub aggregates findings across both. None of them act on what they find by default — that part is on you.

Amazon EventBridge is where detection meets response. It captures events emitted by AWS services and routes them to targets you define: Lambda functions, Step Functions workflows, Systems Manager Automation runbooks, SNS topics. It is the layer between a finding being generated and something actually happening because of it.

What is Amazon EventBridge?

Amazon EventBridge is a serverless event bus that receives structured JSON events from AWS services and routes them to targets you define — Lambda functions, Step Functions workflows, SNS topics, and more — based on rules you configure.

EventBridge is a serverless event bus. AWS services publish structured JSON events to it when things happen: a GuardDuty finding is generated, an EC2 instance changes state, an IAM policy is modified. EventBridge receives those events on the default event bus and evaluates them against rules you define. Matching events get delivered to your targets.

There are three ways to work with events in EventBridge:

Event buses: receive events from many sources and route them to many targets. Every AWS account has a default event bus that AWS services publish to automatically. You can create custom buses for cross-account routing or your own application events.
Pipes: point-to-point, single source to single target. Useful when you need filtering, enrichment, or transformation in between. Less relevant for security automation at scale.
Scheduler: time-based invocation using cron or rate expressions. Separate from event-driven rules.

For security automation, you'll mostly be working with event buses and rules.

Event-Driven Automation in AWS

Event-driven automation replaces the manual security operations loop — finding, review, ticket, action — with an immediate, rule-driven response triggered the moment a security service emits an event, collapsing detection-to-response time from hours to seconds.

The traditional security operations loop — finding appears, analyst reviews it, ticket gets raised, someone performs a manual action — doesn't hold up in environments with hundreds of accounts and thousands of resources. The volume is too high and the latency is too long.

Event-driven automation collapses that loop. When GuardDuty generates a HIGH severity finding, EventBridge can invoke a response in seconds, before an analyst has even opened the console. The security service emits an event, a rule matches it, a target runs. Each step is independent. The detecting service doesn't know or care what happens downstream.

One rule can have up to five targets. A single event simultaneously notifies an SNS topic, opens a ticket via Lambda, and starts a Step Functions workflow. Each target gets the same event; none of them know about the others.

The basic flow:

A security service detects something and emits an event
EventBridge receives it on the default event bus
A rule evaluates the event against a pattern
If it matches, EventBridge invokes one or more targets
The target does something

Automation does not have to mean remediation

Event-driven automation doesn't have to touch anything. It doesn't have to isolate an instance or revoke a credential. Those are valid responses, but they're not always the right first move, and in some environments they're politically difficult to get approved.

A finding is what the detecting service observed, not the full picture. Before taking an action that affects a running workload, it's worth thinking about what you don't know yet.

EventBridge targets can be used purely to gather that context and feed it back into your workflow:

A GuardDuty finding identifies an EC2 instance by ID. A Lambda function queries the EC2 API, pulls the instance tags, attached IAM role, VPC, and public IP status, then writes all of it back to the Security Hub finding via BatchUpdateFindings. The analyst sees a fully enriched finding instead of a raw alert.
A Macie finding identifies an S3 object containing credentials. Before anything is suppressed or escalated, a Lambda function checks whether the bucket is public, who last modified the object, and whether replication is configured to an external account.
An IAM Access Analyzer finding flags external access. A Lambda function checks whether the principal being granted access belongs to a known partner account in Parameter Store. If it matches, it's low priority. If it doesn't, it escalates.

In each case the automation runs immediately, nothing in production is touched, and the analyst gets a finding with actual context instead of a raw alert. It's a reasonable place to start if your team isn't ready to auto-remediate yet, and it stays useful after you are — better context means better triage regardless of what happens next.

How EventBridge Captures Security Events

EventBridge rules match incoming events using event patterns — JSON filters that specify which fields and values must be present — and route matching events to up to five targets simultaneously.

Event Patterns

Rules match events using event patterns: JSON filters that specify which fields must be present and what values they must hold. EventBridge evaluates every incoming event against every active rule. If the event matches, the rule fires.

You only need to include the fields you want to match on. Fields you omit are ignored.

A rule that captures all GuardDuty findings:

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"]
}

A rule scoped to a specific finding type at HIGH severity and above:

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "type": ["UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS"],
    "severity": [{ "numeric": [">=", 7] }]
  }
}

A rule that captures Security Hub findings with a FAILED compliance status that haven't been triaged yet:

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Compliance": {
        "Status": ["FAILED"]
      },
      "Workflow": {
        "Status": ["NEW"]
      }
    }
  }
}

Event Sources

Service	Event type	When it fires
GuardDuty	`GuardDuty Finding`	A new finding is generated or an existing finding is updated
Security Hub	`Security Hub Findings - Imported`	A finding is ingested or updated in Security Hub
Macie	`Macie Finding`	A new Macie finding is generated
CloudTrail	Via `aws.cloudtrail`	API calls matching a configured data event trail
IAM Access Analyzer	`Access Analyzer Finding`	A new external access finding is generated
Config	`Config Rules Compliance Change`	A resource transitions to NON_COMPLIANT

Targets

Target	What it's good for
Lambda	Arbitrary code: enrich findings, call external APIs, modify resources, make decisions
Step Functions	Multi-step workflows with branching, retries, and optional human approval
Systems Manager Automation	Runbook-based remediation for AWS resource configurations, good for Config compliance findings
SNS	Fan-out to email, SMS, HTTP endpoints, on-call paging tools
SQS	Queue events for downstream processing at controlled throughput, useful during finding bursts

Each rule supports up to five targets, all invoked in parallel with the same event.

Example: Automated Response to Credential Exfiltration

UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS fires when EC2 instance credentials are used from outside AWS infrastructure — a high-fidelity indicator with a low false-positive rate that warrants an immediate automated response.

UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS fires when EC2 instance credentials are used from outside AWS infrastructure. Instance credentials should never originate outside AWS, so the false positive rate on this one is low.

A response workflow for this finding:

EventBridge rule matches on source: aws.guardduty and detail.type: UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS
Rule triggers a Step Functions workflow
Step 1: Lambda extracts the affected role ARN from detail.resource.accessKeyDetails.principalId and queries the EC2 API for instance tags, environment, and owner
Step 2: Lambda writes the enriched context back to the Security Hub finding via BatchUpdateFindings
Step 3: SNS notifies the security team with the finding detail, enriched context, and a link to the finding in Security Hub
Step 4: Lambda attaches an explicit deny-all inline policy to the role via iam:PutRolePolicy, blocking further use of any active sessions
Step 5: Lambda updates Workflow.Status to NOTIFIED in Security Hub

Enrichment and notification happen first. Containment is a downstream step, after context has been gathered. The whole sequence runs in under 30 seconds from finding generation.

Thomas Haggath — AWS Security Writing

Leveraging Macie suppression rules to eliminate noise

What is Amazon Macie?

Example Macie Finding Types

Policy Findings

Sensitive Data Findings

Severity Scoring

What are Suppression Rules?

How they work

Why use them?

Important consideration

Macie Allow Lists

Predefined Text Lists

Regular Expression (Regex) Lists

Usage

Limits

The Difference Between Allow Lists and Suppression Rules

When to use each

Example Finding: Sensitive Credentials Detected in S3

Further Reading

GuardDuty Suppression Rules: Reduce Alert Noise on AWS

What is GuardDuty?

Example GuardDuty Finding Types

EC2

IAM

S3

EKS

RDS

Attack Sequences (Extended Threat Detection)

What are Suppression Rules?

How they work

Why use them?

Important caveat

GuardDuty IP Sets

Trusted IP Lists

Threat Intel Lists

Limits

The Difference Between Trusted Lists and Suppression Rules

When to use each

Example Finding: IAM Credential Use Outside AWS

Further Reading

AWS Security Hub: ASFF, Severity Normalisation and Cross-Account Aggregation

Finding Categories

The Amazon Security Finding Format (ASFF)

Severity Normalisation

Cross-Account Aggregation

Delegated Administrator

Aggregation Region

Filtering by Account

Example ASFF Finding

Further Reading

Leveraging Amazon EventBridge to invoke Security Automation

What is Amazon EventBridge?

Event-Driven Automation in AWS

Automation does not have to mean remediation

How EventBridge Captures Security Events

Event Patterns

Event Sources

Targets

Example: Automated Response to Credential Exfiltration

Further Reading