Cloud Security: Segmentation, Isolation and Accreditation… oh my!

There was a time, not too long ago, where simple perimeter firewalls were the state of the art. It was too complex and costly to implement proper segmentation for servers.

All that’s changed with the advent of software-defined networking and advances in virtualization and host-based software. Toto, I’ve got a feeling we’re not in Kansas anymore! We can now affordably apply segmentation and isolation best practices for security as discussed in this Gartner paper.

Where do I start?

Amazon Web Services provides a powerful and user-friendly means of applying basic network ACLs (Access Control Lists). ACLs are just a fancy name for controlling which network ports instances can speak to each other and the Internet on.

By default AWS operates in deny all, meaning no ports are open unless you specifically request them. Ideally you want to open the minimum of ports needed, and only to the resources that need them. For instance you could open a Web Server to port 80/443 for all of the Internet, but you shouldn’t open its RDP port to the Internet…or at all if you can help it.

Like the wizard, AWS has a clever trick up its sleeve to make this easier. Say I wanted to protect a 3-tier application with web servers, application servers and back end data services:

AWS allows you to define Security Groups, which are like templates for multiple instances of the same type. To make it easier to keep the rule set small, you can link Security Groups together. For example, allowing only traffic over 443 to the App tier from instances in the Web Server tier. Sounds simple—and it is—but it’s also incredibly powerful.

If you combine that with VPC (Virtual Private Clouds), you can apply rich segmentation and isolation policies for a wide variety of architectures. There are plenty of samples in the architectures section on the AWS site to help you get to the Emerald City.

That’s enough, right?

Not quite. As we discussed in our last post, it often isn’t enough to simply segment and open only the required ports. Threats like Shellshock, Heartbleed and others occur over these legitimate ports. To keep these winged monkeys out of your instances, you have to look deep into the packets of data from the network. A software based intrusion prevention system ensures that the traffic to and from your instances is free from malicious intent.

Using an IPS running on your EC2 instances—like Deep Security—means that your security will scale automatically with your workload. This consistency reduces your operational burden with a nice clean scaling model.

In addition to the protection of an IPS, many compliance frameworks require detailed logs of all network activity. While VPC’s have flow logs, they do not provide sufficient detail for passing compliance audits like PCI-DSS. You may want to consider a 3^rd party firewall if you need detailed logging and accreditation. While providing excellent security, AWS Security Groups have not yet been certified by ICSA Labs.

Tying it together…

Before you go far down the segmentation and isolation red-bricked road, make sure you have a plan for how your network security will be monitored and audited.

In an earlier post, another best practice highlighted the importance of ongoing monitoring . You also need to watch for intentional or unintentional configuration changes and constantly reassess your security architecture.

Interested in learning more? Read the Gartner paper on best practices for securing AWS workloads.

If you have questions or comments, please post them below or follow me on Twitter: @justin_foster.

 

from Trend Micro Simply Security http://ift.tt/1Nr1RU0
via IFTTT