Understanding the Shared Security Model in Amazon Web Services

Security in the Amazon EC2 environment is a responsibility shared by both the end user and Amazon. This is because within this environment there are specific parts that Amazon has control of and specific parts that are controlled by the end user.

For the end user, they are responsible for securing the operating systems running on their instances, as well as the applications running on those operating systems. On the other hand, physical security and security of the hypervisor is Amazon’s responsibility.

When it comes to the network, security of that layer is a shared responsibility between the user and Amazon.

Huge operational efficiencies can be gained in a shared security model, however this comes at the cost of the flexibility to have total control over an environment.

In the past, significant security issues have occurred as organizations move to the shared model.

During this transition, it’s key that organizations understand the implications involved as they move to this new model.

The ability to utilize tried and true controls, like IDS and vulnerability scanners, becomes limited when there is a shared responsibility for the network layer. In EC2, Amazon holds the responsibly of network routing and segmentation between customers.

For instance, making sure that all traffic gets to the intended systems and preventing one customer from seeing another’s traffic.

The implementation of this restriction has prevented end users from easily gaining access to all the network traffic in their EC2 environment (traditionally captured by SPAN or TAP).

The implication of this is that the ability to deploy any security monitoring and controls that rely on network traffic becomes severely limited.

This includes network IDS, NetFlow analysis, etc. It’s possible to attempt to replicate this by capturing network traffic locally on hosts running in an environment and then analyzing in a central location, however this approach is error prone and has severe implications on the network load of the environment because all traffic is replicated as it is sent to the centralized location for analysis.

New Features in Amazon AWS

EC2 Security Groups is probably the most misunderstood security feature in Amazon AWS. This powerful feature provides the ability to control port-level network access to any running instance.

Confusion over this feature often arises due to its seemingly familiar nature. It’s very easy for a user to expose services to the public Internet. Traditionally, substantial effort would be required to put a database on the Internet – punching though one or two routers and a firewall.

However, with security groups this process becomes dangerously simple: a single configuration update. A recent analysis conducted by AlienVault found that in the US East region alone, more than 20,000 databases allowed anyone on the Internet to access them.

Dynamic Environment

Amazon EC2 is a very dynamic environment. Some users design their systems to adapt to this in order to elastically scale with demand, while other users find that their systems simply require restart, and redeployment to operate effectively in EC2.

This brings a substantial implication when conducting security monitoring and incident response in the EC2 environment. In traditional environments, identifiers such as IP addresses can be relied upon for forensic analysis and systems are relatively static.

This means that an incident that started weeks ago will likely have evidence resident on systems still operating. These assumptions are not valid in a dynamic environment. To follow security monitoring best practices, it’s important to provide a concrete relationship between captured security data and the instances running in the environment. Also, it’s key to dynamically collect data for use in incident response.

API

The final implication of security monitoring in AWS is a major one: the Amazon API controls all actions taken in the environment. While this provides much needed automation, it also means that a malicious user of this API could quickly cause substantial damage.

This was addressed in traditional environments by restricting physical access to machines and when using things like IPMI, access was (hopefully) restricted to a dedicated management network.

It’s best practice to use the same level of dedication to protect, monitor and control access to the Amazon API.

Summary

It’s important to understand the implications listed above for effective threat detection and incident response in environments such as AWS.

AlienVault has taken all of these implications and created an entirely new security monitoring offering that is native to AWS – Unified Security Management

(USM) for AWS. USM for AWS provides deep integration with the Amazon API to address shortcomings of more traditional technology ported from brick and mortar data-centers.

Additionally, it provides a completely new AWS Infrastructure Assessment engine for detecting insecure configurations and helps users audit their environments.

This provides a major step forward for those who need to gain visibility and detect malicious activity in these environments.


With USM for Amazon Web Services, you can answer questions like:

What users are accessing the API?

Where are they signing in from?

Who terminated the machine I was working on last night?

Did anyone mess with my security groups?

Did a developer open up a port to debug my production machines?

Has anyone compromised my API credentials?

Are my windows servers communicating with known command and control servers?

Are hackers scanning my infrastructure?

Do any of my machines have known vulnerabilities?