How do I set up alerts for specific IAM role changes in AWS?

Let's cut through the marketing fluff. If you're asking this question, you've probably realized that CloudTrail alone isn't a monitoring solution. You get the logs, but you're blind until you decide to go hunting through them. That's a reactionary posture, and for IAM role changes—especially ones involving trust policies or permissions boundaries—that's a dangerous way to operate. I've seen a simple `iam:UpdateAssumeRolePolicy` action on a critical role go unnoticed for weeks, leading to a compliance nightmare.

Sysdig Secure gives you the tooling to turn those CloudTrail events into actionable, real-time alerts. The key is understanding that you're building a Falco rule. Sysdig consumes CloudTrail via an SQS queue (you need to set that integration up first—that's a prerequisite, and their docs cover it), and then Falco evaluates the events against your rule set.

Here's the hard-won lesson: be specific. Alerting on all IAM changes will drown you in noise. You need to scope it down. Are you worried about roles used by your CI/CD pipeline? Roles attached to your production EC2 instances? The principle of least privilege applies to your alerts, too.

Let's build a rule. This example triggers a critical alert if the trust relationship (the `AssumeRolePolicyDocument`) of any role matching a name pattern (`prod-*`) is modified. This is a common attack path.

```yaml
- rule: AWS IAM Role Trust Policy Modified for Production Roles
desc: Detect modification to the trust policy of any IAM role with a name starting with 'prod-'. This could indicate a lateral movement attempt.
condition: >
aws.eventSource = "iam.amazonaws.com"
and aws.eventName in ("UpdateAssumeRolePolicy", "UpdateRoleTrustPolicy")
and aws.requestParameters.roleName startswith "prod-"
output: >
CRITICAL: Production IAM Role Trust Policy Modified (requesting user=%aws.user,
role=%aws.requestParameters.roleName, event=%aws.eventName, arn=%aws.userIdentity.arn)
priority: CRITICAL
source: aws_cloudtrail
tags: [aws, iam, compliance, production]
```

You'll place this custom rule in your Falco rules file (e.g., `custom_rules.yaml`). The real work is in the deployment and tuning.

Now, the pitfalls I've learned the hard way:

* **State Changes vs. Configuration Changes:** This rule catches *configuration* changes. If you also need to know when a role is *assumed*, that's a different rule. You'll want that for highly privileged roles. Use `eventName` "AssumeRole" and filter on `requestParameters.roleArn`.
* **Rule Ordering:** Your custom rules file is loaded. Ensure your rule IDs are unique and you understand the default Sysdig/Falco rule set to avoid conflicts.
* **Alert Fatigue:** The example uses a naming pattern (`prod-*`). If your naming isn't consistent, you'll need to maintain a list of specific role ARNs in the rule condition, which becomes a maintenance burden. Consider using tags on the IAM roles and filtering by `aws.requestParameters.tags` if Sysdig's CloudTrail ingestion includes them (test this).
* **Testing:** Don't deploy this and wait for a real event. You must generate a test event. Use the AWS CLI to perform a benign update on a test role and verify the alert fires in Sysdig. No test, no trust.

The final step is connecting the alert to a notification channel—Slack, PagerDuty, etc. Sysdig does this well. But remember, the alert is only as good as the response playbook behind it. Who gets paged? What's the immediate containment action? Have those answers before the first alert fires.

—BW