Taking Steps to Secure Your AWS Environment: Part 2

This post is part two of a continuing series on CloudCheckr CTO Aaron Newman’s white paper “Utilizing CloudCheckr for Security.” Part one can be seen here.
Last week we emphasized the importance of taking a look around your AWS usage. We learned how to make sure your environment is properly covered; this week we concentrate on how to keep it secure.

What’s Going On?

In 1971, legendary soul singer Marvin Gaye asked the world “talk to me, so you can see, what’s going on.” AWS web service CloudTrail knows what’s going on in your cloud deployment. CloudCheckr meanwhile, knows how to listen. Using CloudTrail monitoring, we translate API events into meaningful terms.

As Aaron Newman notes “the hardest part of monitoring is to understand what to monitor for.” This may be a cliché metaphor, but let’s try it anyways: picture a house.

Your house is secure because it has locks, and maybe even a home security system. Those who invade your company’s home in the cloud may first try picking the lock. CloudCheckr will monitor your AWS usage for “unauthorized access attempts” as dictated by CloudTrail. The hacker may then try the kitchen window, but we’ll catch him there with the “failed login to AWS Management Console” alert.

If somehow they already have your key, we have alerts to make sure you know it is being used where it shouldn’t, such as in the root account.

Outside of lock-picking, there’s also screwing with the alarms. You can set CloudCheckr’s alerts to notify you if security groups have been changed or if IAM or VPC events have been edited.

The invader may come from outside, or, worryingly, even from within the company. By disabling CloudTrail alerts, the invader is essentially shutting the lights off and trying to change the locks to make the house theirs. CloudCheckr notifies your security team if CloudTrail has been disabled before damage can be done.

Pro Tip: In “Using CloudCheckr for Security,” Aaron Newman points out how a hacker may cleverly “attempt to disable logging by pointing at an invalid S3 bucket or by disabling Global Service Events.” Sometimes these can be innocent uses of AWS’s UpdateTrail, but a crack security team should be wise to the possibility that they aren’t.

And Who Dunnit?

Over a span of three months, CloudTrail may report 200,000 modifications to the IAM policy. If something shifty has happened to your AWS account, 200,000 modifications is a lot of data to comb thru to find a guilty party. Who knows what damage can be done to your deployment in the meantime?

CloudCheckr maintains a history of IAM policy modifications. By searching under the Common Searches report or the Events report, your security team can narrow down who may what change and when. Then the culprit, whether nefarious evil-doer or a well-meaning but naïve employee, can be rooted out and corrections can be made.

See CloudCheckr in Action

The largest enterprises, service providers, resellers, and government agencies trust CloudCheckr’s cloud management platform. Schedule a 30-minute demo to learn what CloudCheckr can do for you.