With all the security breaches that occurred on AWS in 2017, be they caused by poorly managed Amazon S3 permissions to inadequate security group configurations, we have seen that no company or government agency is above making simple mistakes. This post will explain three areas of security we’ve noticed many AWS accounts struggle with and mismanage, and, the tool Trek10 has chosen to remediate these areas (here’s a hint - it’s with monitoring).
3 Big Security Concerns
1. AWS IAM & User Security
The first area we see AWS users struggle with is their IAM setup, including users, roles and multi-account structures. At Trek10, we have an IAM account that’s sole purpose is for user authentication and nothing else. Once authenticated to the IAM account, our engineers use cross-account roles to do all their work in our internal and client accounts. While not every AWS product needs an IAM account associated with it, the following security principles we use in our IAM account can be beneficial to all AWS accounts.
- We set our password character minimum to 14
- We require letters, numbers, and symbols
- We prevent the reusing of passwords
- And most importantly, we enforce MFA on every user
2. Security Groups
The second area we see folks struggle is configuring their security groups. Security groups are AWS’s way of limiting traffic to your resources based off of an IP and port number. What makes this area such a pain for so many people when legacy systems have been moved to the cloud. The engineers who built this solution can easily be on a different team or even company, and no one is quite sure which security group to comb through first. We have clients fight through the questions of whether this or that IP should be allowed, or if this ec2 instance is really supposed to be publicly facing. It can be surprising how often you find companies unknowingly have their servers exposed publicly on a port they do not know about.
3. S3 Permissions
Last, but certainly not least, is S3 permissions. If you have been following security breaches over the last year you know a majority of breaches on AWS have come from misconfigured S3 buckets. To get an in depth look at S3 permissions check out our recent post, Understanding AWS S3 Permissions, Securing Your S3 Buckets and Objects. In short, S3 has multiple ways to control access and it can be tricky to make sure you have locked each one down.
Our Solution
Clearly no one wants to leave their infrastructure exposed, so how do we manage the biggest security concerns we see in today's environments? You guessed it (and we gave you a hint), with constant monitoring.
While this is a growing space, and there are a lot of great options like Evident.io, CloudPassage and even AWS themselves, we evaluated the market and found a great solution and partner in CloudSploit!
CloudSploit is an “Automated AWS Security and Configuration Monitoring” tool. What that really boils down to is that CloudSploit will scan your AWS account on an ad hoc or scheduled basis and let you know what “flaws” your account has based on sets of rules. You may think your account is crystal clear, but to date I have never seen an account pass every scan on the first scan. Oh, and for the best part the entire scanning engine is open source.
How We Use CloudSploit
When CloudSploit runs new scans, it can send SNS notifications. Trek10's CloudOps team monitors those with a lambda function to create tickets on what deemed mission critical plugins such as root-MFA, AWS CloudTrail enabled, open SSH ports, etc. We are pumping all new failures into our primary monitoring tool Datadog, from which we can create customizable compliance and security dashboards and tickets.
You may be thinking that, if the scanning code base is open source, and you can determine what you want to manage, why not maintain your own service? You could! But, now you are stuck managing your displays, alerting, API, user management etc. Not to mention, you would miss out where we really see value in CloudSploit; other really smart people managing and improving the tool... for us! The team at CloudSploit is iterating quickly with improvements to their front end, scans, etc. For example, when all the S3 security leaks were happening, they built and released a handy visualizer straight into the UI.
But, sometimes scheduled scans aren’t enough, and real-time notifications for things like disabled MFA or other high level security operations may be necessary. CloudSploit Events take all the power of Amazon CloudWatch, and make it real-time by consuming your CloudWatch Events, enabling hyper security focused teams to get alerts on certain API activity when seconds and minutes matter. And, possibly the coolest thing from CloudSploit is the API they give to premium customers. With it the possibilities are endless. In addition to scheduled scans (or in place of them), your developer team can leverage the API in hand with your CI pipeline to scan your environment after each deploy, and ensure that no new infrastructure security risks have been introduced.
Wrapping Up
We are really looking forward to continuing our mission to build a better, more secure experience for our clients, and CloudSploit helps us do this. If you have any questions about security in the cloud and how Trek10 can help, please feel free to reach us at info@trek10.com.
