Catching Unauthorized Authorized Cloud Admins

At Snowflake’s security team, we’re creating new alerts that combine the three most important things in security analytics: context, context, and context.

Two detections activated this week were “IAM Administration by Unauthorized Person” and “S3 Change Action by Unauthorized Person”. At first glance, these rules don’t seem to make much sense. If an AWS user is not authorized to make a change then AWS is responsible for denying the user’s attempt, isn’t it?

Unfortunately for all of us, cloud administration is hard to get right and impossible to get perfect. In every environment, there are users that can do things that they’re not supposed to do. Security teams are one of the worst offenders in that they’re typically provided extensive privileges for incident response situations, privileges that can be abused to create user keys or modify permissions outside of change control.

We should all continue to strive for least privilege. But given that some users will inevitably be over-provisioned with cloud management rights, we’re applying security analytics to catch cases of unauthorized authorized administration.

The approach we’ve taken is to combine our ADP data (which we stream to our Snowflake) with our CloudTrail activity logs (which we also stream to our Snowflake). The ADP personnel records indicate the team association for each user that’s observed making sensitive changes in our AWS environment. For example, a user that’s not a member of the DevOps team should not be managing users or S3 buckets as far as we’re concerned. The following is a Jira ticket that SnowAlert opened for us this week:

This alert could not have been raised by looking at the AWS logs in a silo. Instead, we have an alert that is high fidelity and neatly complements our efforts at secure cloud configuration.