An Overview of Cloud Security

Storm clouds pouring rain and hail over a French canal.

Cloud computing is a hot technology area and behind a large and growing business sector.

But cloud computing is not new. John McCarthy suggested that "computation may someday be organized as a public utility" in a speech at MIT's centennial in 1961.

And, what people refer to as "cloud computing" usually is not computing in the traditional sense.

So, what is it?

It's very much like the outsourcing and remote hosting that has been done for years and years. It's largely used for storage and network services, relatively little for high performance computation.

Some organizations are building their own cloud infrastructure, with smaller businesses looking into a platform such as the Dell cloud computing service for a cost-effective implementation. Most organizations, however, are going with the impressively powerful and reasonably priced major cloud services such as Amazon Web Services.

The difference between what came before and today's cloud offerings is that some current cloud providers have enormous network bandwidth and reserve virtualized hosts, to the point that you can (almost) always add more hosts and you (almost) never notice delays or bandwidth limitations. What's more, it's "pay as you go", you deploy as many cloud-based hosts, or "instances" as you would like, and use them for as long or for as little time as you would like. You deploy your own cloud resources and you pay only for what you use.

Users typically start by using a web-based dashboard type of interface. Once they become serious, they typically migrate to command-line tools and API calls from their programs.

The cloud environment is new and at least a little different to most people, and therefore it seems threatening. People worry: Just how risky is the cloud?

The answer in most situations comes as a surprise, to the extent that many people are hard to convince:

Used correctly, the cloud probably provides better information security than you have in house.

Really. Let's look at availability first:

Think about this: When was the last time that Amazon was down? Or Google? And how long were they down?

Yes, in the period of December 2010 through November 2011, Amazon had three well-publicized outages, or at least degradations. However, these events seem to have been well publicized but poorly understood by much of the cloud market.

The first of these was a brief degradation of service on the first of December, 2010. A mirror of the Wikileaks archive of U.S. State Department cables, the so-called "cablegate" collection, was running on a server in Amazon's US-East region. This became publicized, and the U.S. Government, Amazon's largest customer, told them to halt that server. Amazon did so, and became (along with MasterCard, Visa, and a few other perceived "enablers" of the U.S. Government) a target of a DDOS attack.

The second was in April 2011, which Amazon has described in detail as being a "mirroring storm" at its core. This also affected the US-East region, specifically the Virginia site.

The third was in the first week of August, 2011, when the electric utility provider in Dublin, Ireland suffered a failure of a 110 kV 10 MW transformer, resulting in a total loss of power to all its customers. This included both Amazon's and Microsoft's primary data centers. Amazon has said that their backup generators failed due to faulty programmable logic controllers, the UPS batteries quickly drained, and power was lost to almost all EC2 instances and 58 percent of the EBS volumes in that Availability Zone. Amazon has also provided a detailed description of this event.

Amazon very strongly suggests that customers deploy instances in and balance activity across multiple availability zones per region. Most customers who followed that recommendation noticed little to no service degradation in the first two events. The second did spread briefly to other Availability Zones due to resource depletion, something that Amazon says they have addressed in a partial redesign.

The third, the Dublin power loss, seems to have been the worst outage. It also degraded service in all EU-West Availability Zones because the EC2 management service is distributed across all zones.

Near-worst case: Some customers had EC2 servers running within one Availability Zone only, and they were unreachable for 24-48 hours.

Worst case: Some customers were using EBS storage within one Availability Zone only, and in the second event a small percentage of data was irretrievably lost. As Amazon reported, "Ultimately, 0.07% of the volumes in the affected Availability Zone could not be restored for customers in a consistent state."

Outcome for the cautious user: With servers in multiple Availability Zones, and S3 storage (which is automatically distributed across multiple Availability Zones), there was probably nothing noticeable in the first case, a minor degradation in the second event, and a more major service degratation in the third case.

Amazon's S3 or Simple Storage Service quotes 99.99% availability of data at any moment, and a long-term durability of 99.999999999%. This is done by redundant storage across multiple facilities within a geographic region, designed to withstand the concurrent loss of data in two facilities. That costs just US$ 0.14 per gigabyte per year. Actually that's the maximum cost, the price drops with increased volume.

Next, what about user authentication, which can lead to inappropriate access if you don't do it right?

Let's consider a standalone system at your facility. Let's say it runs Linux, for meaningful comparison to Amazon's most popular EC2 (or Elastic Compute Cloud) server platform.

User accounts and their authentication can be defined in a local database, with the sensitive bits in /etc/shadow and the non-sensitive bits in /etc/passwd. The shadow file should be readable only by root and the operating system, so we should be OK there.

User accounts can also be stored in a remote database communicated over NIS/NIS+, LDAP or LDAP/S, and even SMB/CIFS from an Active Directory server. But unless you're using LDAP/S or encrypting all traffic with IPsec, anyone with a network connection can capture the network traffic and save the password hashes. Hash functions are not reversable, but with some awareness of what tiny subset of the possible password space is actually used by users, an off-line attack can find the corresponding passwords.

Then there are risks of physical access. Someone can boot a machine from media, at which point they completely own it. Or even steal the hardware. Yes, your servers are locked in a room. And your physical security is perfect? Congratulations!

Then there are all the network authentication methods using cleartext logins and passwords. Get the dsniff tool for easy capture and collection of logins and passwords from at least this list of application layer protocols listed on its manual page: FTP, Telnet, SMTP, HTTP, POP, poppass, NNTP, IMAP, SNMP, LDAP, Rlogin, RIP, OSPF, PPTP MS-CHAP, NFS, VRRP, YP/NIS, SOCKS, X11, CVS, IRC, AIM, ICQ, Napster, PostgreSQL, Meeting Maker, Citrix ICA, Symantec pcAnywhere, NAI Sniffer, Microsoft SMB, Oracle SQL*Net, Sybase and Microsoft SQL protocols.

All of these remote and local authentication protocols can use multiple methods of authentication thanks to PAM, or Pluggable Authentication Modules. So local authentication could involve some combination of the keyboard, a smart card reader, and a fingerprint scanner.

But here's the thing about PAM: It can make things more secure if you manage to get it exactly right. But you can make things far worse if you get it wrong, possibly far worse in a way you never notice until you're trying to figure out how you got hacked.

Summary so far: In-house systems require a lot of work to harden user authentication.

Let's compare that complicated mess to authentication into a cloud based server. I'll use Amazon EC2 as a good example of how to do this correctly. You can:

• Authenticate into SSH, using the SSH-2 protocol only, authenticating only via cryptographic key based authentication.

And... that's it! There is no other way to get into the AWS EC2 server. Sure, once you deploy it you can get in and open it up, turning on Telnet and setting the administrator's password to the literal word password and other nonsense, but what they give you is relatively easy to secure and maintain because there are very few opportunities for an attacker.

As far as you can tell, your server is on its own VLAN behind a router with packet filtering rules. Yes, really there's virtualization and multitenancy, but you have to look fairly hard to notice it.

Finally, information security in the cloud is exactly like information security anywhere else. Data confidentiality can be protected with encryption, data integrity violations can be detected with hash functions, and we have no cryptographic tools (and therefore no math, and therefore no numbers) for data availability and so we cannot formally compare availability levels.

Encryption is still encryption: select good ciphers and good protocols using them, and be very careful with your key management. Hash functions are still the tool to verify integrity; collisions are possible with any hash but the probability of two different files colliding under two hash functions is so unlikely that I haven't noticed anyone even trying to figure out just how unlikely it is.

There is no magic security dust, for the cloud or otherwise.

Remember that the cloud computing service model of SaaS, PaaS, and IaaS defines who has responsibility for the hardware and software at the cloud provider or service end. The customer is always responsible for everything at the client end.

A Survey of Cloud Technology Users' Security Concerns

Secure Distributed Logging with Syslog, TLS, and Amazon EC2 Cloud Servers

How To Set Up Encrypted Storage On Amazon EC2

Back to the Security Page

Home Unix/Linux Networking Cybersecurity Travel Technical Radio Site Map Contact

Tweet