8 Useful Assumptions About Cloud Security

The following article was originally written by Ming Lee over at the blog, A Cloudy Place.

In this article I’m going to highlight eight common-sense approaches to securing your applications and data in the cloud. I will use Amazon Web Services (AWS) as my main public cloud provider example but I’m sure these methods apply to a lot of the other providers out there.  As I discuss the various options, imagine if you will the layering up of a ‘sandwich’ of defensive security measures.

Security in the cloud for client data and applications is a paramount concern for a lot of my customers. Many are large central government departments used to having their own data, servers, and networks in their own silos; secure from everyone else. They have sensitive data about you and me and everything in between and they are obligated to make sure that these precious resources are only used for their intended purpose and are not leaked out to others. That’s not a bad thing now is it?

Another group of my users are defense and security agencies and once again, operational sensitive data cannot be leaked or compromised. Access to their servers and resources cannot be tampered with and, if there’s a real emergency, at least they can post guards around their physical servers!

It’s a challenge for Cloud specialists to advocate the movement of some (or all) of an organizations’ resources to the cloud. Certainly, despite initial reservations the UK government has started to look seriously into the cloud through their ‘G-Cloud Programme’ with quite ambitious and far-sighted goals. Clearly the much heralded advantages of cloud computing: it’s much lower TCO, elasticity of use, pay-as-you-go model, and lowering barriers to enable more rapid deployment of applications and services has the austerity-minded coalition-government looking into this area with great interest. The G-Cloud strategy document is available for download here.

Since a lot of my company’s business is in the public sector, the scene was therefore set. The last couple of years, a common perception started to entrench itself amongst some IT practitioners. The usual mantra that the cloud was insecure, servers were located in another country where physical security would be more lax and therefore prone to theft, and potential poor infrastructure meant cloud computing was only useful for photo sharing sites like Flickr and Picasso.

I have been challenging some of the more ingrained positions internally, and while security is a number one concern to me; I found that the perception of the cloud’s insecurity did not always match the reality. I’m going to take a look at some common misconceptions and solutions to securing your applications and data in the cloud using AWS.

Assumption 1: The servers are physically not in this country! How can we be sure that they are not being copied onto USB drives and sold on the black market?

Securing your data on the cloud machines

All your valuable data on any server should be securely encrypted, so even if someone runs off with a copy of the volume, they will need to know what the password is to decrypt the volume. You can use Windows on Encrypted File System  (EFS) for example if you have a Windows OS.

Here’s a useful video  on how to get started with EFS.

Figure 1 How to use Windows EFS

An alternative that you can use include the popular freeware TrueCrypt. I personally use TrueCrypt at home as it’s fast, easy to use, and free. It creates a virtual encrypted disk within a file. It then mounts it as a disk under windows, appearing as a volume. Of course, thinking securely, one should have disabled the ‘auto-mount-and-decrypt’ option for TrueCrypt as it rather defeats the point of securing the system! Best thing is, the file can be copied and stored on a portable drive.

Also, I have yet to hear of any rumor that it is possible to hack and copy an EBS volume that you don’t own.

Assumption 2: The public cloud is on the internet; anyone can get into the dashboard and then into your instances!

Make sure you are connecting to the Amazon Web Services Dashboard

An obvious one, but there are plenty of fake websites out there to trip you up. Avoid using short-cuts; make sure you know the entry point of the AWS dashboard. It should always be using the HTTPS protocol. Check the certificate to make sure it says amazon.com.

Figure 2 Make sure the dashboard is using HTTPS and that the certificate is valid

Assumption 3:  The AWS passwords are not part of our Active Directory domain and therefore are not governed by the same rigorous password policy!

Utilize an Access Control List (ACL)

Use AWS Identity and Access Management (IAM) to control who has access to the AWS Dashboard. For a while, my team was using the main AWS account (let’s call it the root account) to access the dashboard and the EC2 platform. Then, after a security audit we realized how exposed this was. At about the same time, AWS came out with IAM which allows you to create users and groups under the main root AWS account. These new users will have their own passwords and have a varying level of access to products and services. These users will NOT be able to access the Account profile information and (importantly) the billing and metering information. For this level of access, you still need to use the root AWS account.

Even better, we had users within the organization who were only interested in using a sub-set of AWS products (i.e. just EC2 and not S3 or RDS) and IAM was perfect to cater for them. There’s a whole host of stuff about IAM that I could talk about but that will be for another time (but if you can’t wait, check this out).

Finally, there is a password policy available – you should really be using it.

Figure 3 The AWS IAM password policy editor

Assumption 4: Username and password management can be notoriously lax, with important information being slapped onto post-it notes all over someone’s monitor. I might not be able to guess your password, but I doubt you will be able to remember it either. You’ve written it down somewhere obvious. I am going to find it.

Securing the user account

Related to the ACL, each of our user accounts is subject to our password policy procedures that include length of password, limitation of re-use (come on, you’re not using the SAME password for AWS as for your work domain are you?) and the use of a multi-factor authentication device*. The latter is important. If someone DOES manage to phish your username and password; they still can’t access the dashboard since they’d also need access to the MFA device. You need all three to login:

Figure 4 The AWS login using IAM

Figure 5 The MFA login right after

Assumption 5: Data transferred from your internal network to the cloud can be intercepted!

Transferring data to the cloud securely

There are a number of ways to transfer data to the cloud. For small files, one can use the built-in remote desktop options of ‘copy and paste’ or have it remotely mount a drive. You can even email files to yourself and access the same email from the AWS instance. You can also use Dropbox or some other cloud enabled storage provider. For large files and to securely transport them, it is recommended that a secure file transfer system is used. Examples include WinSCP, WinSSHD and OpenSSH.

AWS also offers their import/export service where one can copy data to a portable USB drive and ship it to one of AWS data centers. Depending where you are, the data can be copied over to either your S3 bucket or onto an EBS volume. The latter service currently is only available in the US regions. Sending any media, even by courier does require that the drive and its contents are secured. At the minimum, consider using TrueCrypt to encrypt your data. Avoid any USB drive that requires fingerprint decryption: unless you want to send your thumb with the drive!

Assumption 6: With no physical firewall, you are open on all ports!

Utilize the security groups in AWS

Despite the name, an AWS Security group (SG) isn’t related to users and groups of users. It is an AWS term for a firewall, controlling all traffic to and from any AWS instance that is associated with the security group. By default, all ports and inbound traffic is blocked – including remote desktop. So it is a good idea to enable RDP via the dashboard before you start logging into the machine. However, security groups can restrict the access of these ports to a bunch of IP addresses. This is extremely useful and at my company we’ve restricted all incoming RDP to any of the instances to the address of our external firewall. Thus, only those who are physically at the office, with the right username, password, and multi-factor authentication device will be able to access any instance.

Assumption 7: All code has bugs in it.

How secure is your application?

This is a tricky one, as the security of any application is down to how security conscious your developers are and what type of QA/QC one has on unreleased software. Providing basic security principles are adhered to when the application is put together and an established program of review and release is followed; then it should be okay. Having an established procedure for testing, stage, and release should be sufficient to tease out the obvious security flaws in an application before it goes live.

Assumption 8: The safest computer is one switched off!

Your operating system is vulnerable!

This is an easy one: keep on top of patches and updates, apply them as soon as possible and keep your eyes and ears on the various blogs, webinars, and news items on security. It is vitally important that everyone takes security seriously. We have a patch day that occurs when Microsoft releases its own patches, we dedicate time to keep up to date on this. Security audits should be carried out on a regular basis covering password renewal and log analysis. The latter is important: how do you know that someone has been trying to hack into your system and if they’ve been unsuccessful? We have a process where the logs are skimmed for any errors and if any are found, the entire log is analyzed in detail.

Let people attack it – within reason

An important part of securing the application in the cloud, we’ve engaged a number of security companies that can perform penetration tests (‘Pen test’) and attempt to ‘ethically’ hack into one of our applications. Most of these companies are sensible and will try the more subtle approach and not a brute force, denial-of-service attack. The latter will cause your ISP to react with some alarm and pull up the drawbridge. Once the pen-test has completed; a detailed report is made available of any vulnerabilities detected. We tried our own pen-test by inviting a different team from the company to try and hack into our new application, with an Amazon Kindle as a prize for the most impressive and successful attempt. It’s interesting to note that phishing attempts were the most successful, illustrating that social engineering attempts attacks the weakest part of any security apparatus: the people.

Finally – disaster recovery

Data centers sometimes fail look at my favorite public cloud provider: AWS.  They experienced a couple  of outages that have affected a number of clients. Now, rather than securing your service against malicious attacks, it is equally important to secure against a force majeure – but this ambles the conversation towards business continuity planning and disaster recovery. There are so many things that can affect the security and therefore viability of the your cloud-based services, but good business practices, adherence to standards and known processes, and everyone in the organization taking security seriously should lessen the impact of when there is a breach and ensure fast recovery and safe-guarding of sensitive business data.

The cloud isn’t the magic bullet for application uptime or cost savings but it is going to be the environment for computing now and in the future. Its much heralded advantages, and the need to squeeze efficiencies out of current systems, ensure that all organizations need to embrace the elastic computing model sooner or later. The fear that many people feel about the cloud is probably magnified by the physical absence of the hardware, previously tucked away safely in an on-premise server room. However, many of us now access our money digitally through online banking,  and despite some recent hi-profile episodes of banking hardware experiencing ‘technical’ issues; many of us access our money electronically and we trust it, so why not the same with your data?

*This is a device that continually generates a random six-digit number that you need to enter alongside your username and password. So even if your username and password has been compromised, the physical device needs to be acquired before anyone else can use it.