AlgoBuzz Blog

Everything you ever wanted to know about security policy management, and much more.

Search
Generic filters
Exact matches only
Search in title
Search in content
Search in excerpt
Search in comments
Filter by Custom Post Type
Posts

Tips for auditing your AWS security policies, the right way

by

My colleagues and I  have previously blogged quite a bit about best practices for setting up and managing security in your AWS estate. Now its time to talk about auditing this environment. Because its critical to remember that if you process or store data that is subject to HIPAA, PCI or any other industry regulation in your AWS estate, it is within the scope of your audit and thus subject to the exact same requirements as it is on your on-premise networks.

So, what’s the best way to ensure that the policies enforced by AWS security groups are in line with the compliance regimes that your organization is subject to?

The starting point is to review your AWS estate. For example, you might have three security groups defined – one group for Linux-based servers, one group for database servers, and one group for Apache web servers.  In addition to these security groups, you will have all the separate instances that belong to the virtual private cloud (VPC) that are subject to the audit.

So, what should you audit?  There are two possible choices, each with their own advantages and disadvantages.

Option 1:  lead with security groups

AWS is clearly set up to enable you to look at each security group in turn and review it, so that you can look over the rules, compare them to your corporate policies and regulatory requirements to see if they match.  As such, this is an easy and resource-efficient option.

However, it comes with two caveats.  First, you don’t have any context if you look at an individual security group on its own.  You don’t even know if each security group has any instances associated with it – it might be ‘free floating’ – which is perfectly possible in AWS.

Second, AWS security groups can be mixed and matched, so you can have multiple security groups associated with individual instances or servers.  To truly understand your security posture, you need to look at all of the security groups that are associated with each instance, otherwise you will only have a partial view of what traffic is allowed into or out of instances that touch regulated data.

Option 2:  lead with instances

Conversely, you could start by looking at the individual instances, discovering which security groups are associated with those instances, and then reviewing the combined lists of rules, instance by instance.  With this option, you get a very accurate and comprehensive review of exactly what is protecting each instance.   However, the challenge here is a matter of scale.  You might have thousands of separate instances to look at, so this option doesn’t scale very easily.  It’s also extremely repetitive to manage, because many instances will have exactly the same combination of security groups associated with them.

So, which is the right method and how can you capture the advantages of both approaches?

Balancing accuracy and scalability

To take advantage of the resource-efficiency and scalability security groups, and the accuracy of examining each individual instance you can use an abstract concept that I refer to as a ‘security container’ (it’s not an Amazon container).  A security container is a collection of all the instances that have exactly the same combination of security groups associated with them.  Therefore, from the perspective of an audit review, all the instances within each security container are equivalent to each other.

Because all the servers and instances in a given security container have exactly the same combination of security groups, it’s sufficient to review a single instance within that container.

Once you, and your auditor, are satisfied that the combination of all the rules of all the security groups associated with a single instance, are in line with what you want to allow for the organization, then you will know that all of the instances in that security container are equally protected.  Therefore, it is not necessary to examine other instances in that specific container.

Carrying out an AWS security audit with this level of abstraction enables you to cover every combination of active security groups in your AWS estate without neglecting any of them.  It also ensures that you do not have to undertake unnecessary or repetitive work, because all the related servers and instances are clustered in the relevant security containers. AlgoSec Security Management solution can ’s can automatically organize all your AWS instances into security containers, giving you’re the ability to conduct a security audit of your AWS easily, accurately and quickly.

Watch me explain this in detail in my new whiteboard video lesson.

And don’t forget to watch the rest of the lessons in the Best Practices for Amazon Web Services (AWS) Security, whiteboard video course, which are packed with practical tips and tricks for managing security in AWS.

Subscribe to Blog

Receive notifications of new posts by email.