Hey folks — so I’ve been deep in the Secureframe setup for our AWS org this past week, and I hit a snag that I suspect others might run into. When connecting AWS Config and CloudTrail, I kept getting duplicate alerts for what seemed like the same compliance check. It was flooding our Slack channel and making it really hard to spot actual issues.
After some trial and error (and a fair bit of digging through AWS resource relationships), I think I’ve pieced together a workflow that avoids the duplication while still keeping all the necessary visibility. Here’s the step-by-step approach that finally worked for me.
First, the root cause: Secureframe, by default, will create separate findings from Config rules *and* CloudTrail events if they’re both enabled and pointing at the same resources. For example, an S3 bucket without encryption might trigger:
- A Config non-compliance alert (from the managed rule `s3-bucket-server-side-encryption-enabled`)
- A CloudTrail alert (from `PutBucketEncryption` events or lack thereof)
To avoid this, you need to be strategic about **which controls you assign to which service** in Secureframe’s integration settings.
Here’s my recommended mapping:
* Use **AWS Config** for:
* State-based compliance checks (like encryption status, logging enabled, configuration drift)
* Rules that evaluate resource properties at a point in time
* CIS benchmarks that are explicitly about configuration (e.g., “Ensure CloudTrail is enabled in all regions”)
* Use **CloudTrail** for:
* Event-based detection (like root user login, policy changes, unauthorized API calls)
* Controls that require monitoring sequence of events
* Actions that Config rules don’t cover natively
In the Secureframe UI, when you’re setting up the AWS integration, you can selectively enable/disable controls per service. I went through the control list and toggled off any CloudTrail-based alert that had a direct Config rule counterpart.
For a concrete example, here’s a snippet of the kind of logic I applied in my notes:
```yaml
# Controls to assign to AWS Config only (disable in CloudTrail settings):
- Ensure S3 bucket encryption is enabled
- Ensure EBS volume encryption is enabled
- Ensure RDS instance has encryption at rest
- Ensure CloudTrail log file validation is enabled
# Controls to assign to CloudTrail only (disable in AWS Config settings):
- Ensure MFA is enabled for the root user (via root login event)
- Ensure no security groups allow ingress from 0.0.0.0/0 (via AuthorizeSecurityGroupIngress events)
- Ensure IAM password policy is enforced (via UpdateAccountPasswordPolicy events)
```
A final tip: make sure your AWS Config setup is scoped correctly. If you have Config recording all resources in all regions, but your Secureframe scope is limited to certain accounts or regions, you might still get extra noise. Double-check that the Config aggregator and Secureframe’s target OU/account alignment match.
It took a bit of back-and-forth, but now we’re getting clean, actionable alerts without the duplicates. Curious if anyone else has tweaked this further — maybe with custom Config rules or Lambda-backed remediation steps?
editor is my home