AWS Security and Compliance Part 2: What If…


So time for the long delayed continuation of my investigation of security and compliance on AWS! And this time I thought I’d address a few of the “what if…” hypothetical scenarios that I’ve found people commonly ask about when this topic is raised.

While each of these scenarios is a legitimate security concern, and indeed I’d suggest a good basis for some security war games when planning an AWS deployment, I’ve found that the reality isn’t what you might expect. Even seasoned security professionals intuitively come up with are often wrong.

So, let’s dive in!

…An AWS employee logs in to my instance?

The first thing to look at here is how you login to the instances. When you first start an instance and until/unless you reconfigure it, you need to use an SSH key pair to login. On Linux you use your private key directly, on Windows you use your private key to decrypt the encrypted local administrator password.

So there’s no access without the private half of a key pair, so where do the key pairs come from?

There are two choices. Firstly you can have AWS generate the key pair for you, in which case you get one opportunity to download the private key at the time that it’s generated. AWS state that they don’t retain the private key, and there’s certainly no option for downloading it at a later date.

Alternatively, if you want to be really sure that AWS doesn’t have the private key you can generate your own key pair outside of AWS and upload just the public key. In this case AWS never see the private key, and so can’t possibly store it or use it.

Once you’ve logged in you have complete control of your instances. On Windows, this means you get local admin rights (SID 500) and on Linux root privileges (UID 0). So you have complete control over the operating system and its log files, configuration etc. This means you can check and control who’s logging in and from where using all the usual tools for your chosen OS, just as you would (or really, should!) for in-house servers.

For further reassurance, AWS explicitly state that they don’t have any access to the guest OS of an instance, for example in the “Overview of Security Processes” whitepaper;

Virtual instances are completely controlled by you, the customer. You have full root access or administrative control over accounts, services, and applications. AWS does not have any access rights to your instances or the guest OS.

When I’ve spoken to AWS front line, customer facing technical staff, they’ve told me that in fact they are like customers of AWS themselves. They get an account which has no more rights than a regular customer, and are given no live access to the AWS infrastructure outside of this. So even if you were to call AWS support and ask them to access your instances, they actually can’t!

…An AWS employee steels/clones/copies/etc. my disks?

So given that AWS staff can’t log in to your instances, how else might they gain access to your data? One way might be to physically access the media storing your data.

The first defence against this is something AWS talk a lot about including in the “Risk and Compliance” whitepaper, e.g.;

Internally, AWS aligns with ISO 27001 standard for managing segregation of duties. Refer to ISO 27001 standard, Annex A, domain 10.1 for additional details. AWS has been validated and certified by an independent auditor to confirm alignment with ISO 27001 certification standard.

After attending the AWS training and speaking to the AWS techs, my understanding of this is that;

  • Anyone with physical access to AWS infrastructure is never permitted logical access (i.e. they’re never given any credentials to log in to anything)
  • Anyone with logical access is never permitted to have physical access

So if the people who could, hypothetically, lay hands on the media storing your data can’t log on to see which media that data is stored on, the first obstacle would be for them to physically locate your data in the first place.

So that’s a bit of “security through obscurity”, but it’s not the only line of defence. Even if our theoretical rouge techy managed to find the disks containing your data, it’s not like they could just walk into an AWS data centre and start casually pulling drives. In the “Risk and Compliance” whitepaper AWS state that;

Physical access is strictly controlled both at the perimeter and at building ingress points by professional security staff utilizing video surveillance, intrusion detection systems, and other electronic means. Authorized staff must pass two-factor authentication a minimum of two times to access datacenter floors.

Additionally, all AWS data centre staff are required to degauss and physically destroy any and all data storage media before it leaves the data centre floor. Stephen E. Schmidt, AWS’ Chief Information Security Officer goes through this topic in this rather informative talk from about a year ago;

So even if our increasingly hypothetical rouge techy could get to the media with your data on it, he/she wouldn’t be able to get it out of the room intact!

Additionally, if you’re really taking “appropriate technical and organisational measures” to protect the data in your care, as required by EU law, then you should really be encrypting the data anyway.

So our now very hypothetical rouge techy has managed to run off the shredded, degaussed remains hard drive that once may or may not have contained an encrypted copy of your data… Yes, our rouge techy is a real evil genius indeed!

…AWS gets hacked?

An address this concern, I’m going refer again to the YouTube video of the Mr Schmidt’s talk above.

AWS segregate their internal network, such that all access to the actual AWS infrastructure is physically restricted to a special network they call the “management plane”. This is also reference repeatedly in both the “Risk and Compliance” and “Overview of Security Processes” whitepapers.

Accessing the management plane requires passing through bastion hosts, and this introduces one big security barrier that guards against hacking, either through technical means (e.g. brute force cracking of passwords) or social means (e.g. obtaining passwords through spear-phishing) – it doesn’t use passwords!

The bastion hosts use a completely separate authentication system to the AWS corporate network, the one their computers, email accounts, etc. sit on. So even the account of someone inside AWS, who had access logical access to the AWS infrastructure, got hacked, the hacker still wouldn’t gain enough access to manipulate the AWS services.

The authentication system utilised by the bastion host is based on key pairs. The absence of password makes any social engineering attack pretty much useless. Unlike passwords, which tend to be pretty short, private keys are very, very long and contain thousands of characters – pretty hard to recite over the phone to a mysterious “tech support” person I’d say!

This huge length also makes it pretty damn near impossible to “guess” the correct key through brute force cracking methods. As a quick and dirty demonstration of this, when feed a sample 2048 bit private key this what the popular “How Secure Is my Password?” site says;

An SSH private key takes "infinity years" to crack!

And even if you had a few Cray XK7s lying around to help speed things up, AWS review and renew access permissions every 90 days.

In would humbly suggest that an access control that would, theoretically, take longer to break than the universe is old probably qualifies as an “appropriate” protection against unauthorised access!

…Another AWS customer captures my network traffic?

This concern is one of many that stem from AWS’ nature as a multi-tenant environment. The basic idea being that some other, unknown tenant could nefariously eavesdrop on your AWS activity.

We can completely address this concern with one short sentence;

AWS blocks promiscuous mode.

In fact the hypervisors on which EC2 instances sit are configured to only deliver traffic to an instance which is directly addressed to it. And because the hypervisor knows which IP it assigned to which instance, this works even if you try to change the IP address of one of your instances to match someone else’s.

An interesting consequence of this is that instances running in EC2 are only permitted to transmit unicast traffic. Both broadcast and multicast are banded and blocked by the hypervisors.

So packet sniffing won’t work. Period.

What Next

For the next part(s) I plan to look at encryption options on AWS, both for data at rest and in transit, and later at how to control access to your resources and account.

But that’s it for now, and as always, thanks for reading :)


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s