Don’t Become a Statistic: 4 Rules For Creating Safer AWS Security Groups

Amazon Web Services is one of the safest publicly accessible places to compute that has ever existed. What was once seen as an eyebrow-raiser for security experts now offers more services, resources and oversight for the safe processing of data than all but the most sophisticated (and expensive) on-premises solutions.

There’s never been a safer time to use AWS but there is still one major security issue that Amazon has yet to figure out: humans.

Human-error is the biggest cause of breached and botched cloud security there is right now. Guarding against this kind of weakness is a constantly evolving practice but one way you can make a real difference TODAY is to start creating safer security groups.

Here are four ways to make that happen immediately:

1. Be Specific

Think of your security groups as the turnstile at a theme park. Guests should have to present a clear and specific ticket in order to gain admittance to the park and enjoy all of your wonderful data. However, some of our ticket booths are accepting movie stubs, gum wrappers and other miscellaneous garbage as proof for valid entry. You have to train each group to look only for one or two very specific credentials in order to allow access. Otherwise your dream park will quickly become a nightmare.

One great way to keep things specific is to reference other security groups when making your rules. Instead of just setting the allowable traffic to be from your whole VPC, be specific and only let traffic go to the places you want it to go and come from the groups you feel safe sourcing from.

In fact, it’s a good practice when making a new rule to have the source or the target be another security group. That kind of redundant protection is what really locks down an environment.  

For example, I could allow traffic to come from my friend Joe who lives in Mountain View, or I could allow all of Mountain View to access the group. Either way Joe does get access but it’s always better to go narrow rather than broad when it comes to security. Even if it creates more work for your team you’ll be grateful when the next hacker headline doesn’t feature your organization.

Additional tip: When taking traffic from the public internet still be specific and only open up just the ports you absolutely need to use.

There will be times when you do need to take in traffic from the entire internet, but when you do be sure to use a load balancer or something similar to ensure that traffic is flowing through the secure points you’ve put in place.

2. Jump Boxes and Bastion Hosts are Your Friend.

When it comes to public-facing data sets, some people actually have their database exposed to the entirety of the public internet. They do this so that they can log in easier and faster. If you do this and don’t get sweaty palms just thinking about it then that is a huge problem.

Instead of essentially putting a screen door on a submarine, what you can do instead is wire in a Jump Box or a bastion host to your account. According to TechRepublic:

“A jump box is simply a system, usually a single operating system, that is connected to two networks. The first of these networks is the common network and the second is the sensitive security zone.”

Setting up this extra step may seem like an inconvenience, but it’s a lot more inconvenient to have your submarine sunk under an ocean of unwanted traffic. The Jump Box functions like an airlock and essentially ensures that the only people accessing your sensitive database are those with the clearance to do so.

3. Set ELB Instances Up in Separate Security Groups

Another area where getting specific can avert disaster is when it comes to your Elastic Load Balancers. It’s important that you lock the rules for these down early and make sure the laws surrounding them make sense.

You should make sure that your ELBs are running in their own security groups. You need to set up a rule set that’s scoped down into the ports you need, not swinging wildly from place to place.

Some people will tell you that it’s fine and convenient for ELBs to pass traffic to a wide scope and without your oversight. But that convenience comes at the price of a poorly optimized ELB with terrible rules on it that is opening your system way up for intrusion.

4. Lock Down the Ability for People to Make Changes to Security Groups

Identity Access Management is not just something you need to do for your overall AWS system. You need to be using the same careful consideration when it comes to who can and cannot make changes to your security groups as well. A locked door becomes exponentially less secure whenever a new person is given a key. Keep your doors safe. Keep those keys specific and scarce.

Once you have more than a handful of security groups, third party tools like Dome9’s IAM Safety and Clarity help manage your account with greater visibility, security, and efficiency. You can try them out completely free.

At the absolute minimum, you should think about locking down IAM permissions, turning on flow logs and turning on AWS CloudTrail. This is Cloud Security 101 but you’d be surprised how many users miss these crucial first steps.

Try Dome9 for Free!

If these things sound basic and repetitive that’s because they are. However, it’s usually the simple things that get overlooked and lead to the human errors that create massive holes in your security posture.

So be specific, think proactively, and set up intelligent rules on all of your AWS Security Groups to avoid becoming the next Verizon or HBO-type story to explode onto people’s news feeds.