Nov 8, 2017
More processes and applications are being migrated to the cloud than ever before. It’s been a number of years since we bought a server to host any of our apps. Even internal databases and developer machines are in the cloud. Like everyone else we see that there are significant savings not having a data center or a server closet or really any need for an old school network engineer. The pay as you go model from Amazon, Azure, Google etc. is very attractive. But it’s not just the machine costs where you save; cloud providers make it so easy that a complex task is now almost trivial. I can spin up a Saas application such as a Tableau Server in minutes by choosing an image on Amazon’s marketplace and entering my license keys. What used to take days is now instant.
But there are hidden costs and there are real challenges that are not safe for you to ignore. Firstly, hardly a day goes by when a new Amazon cloud service or update is announced. And of course everyone else is playing catchup. There is now such a dazzling array of options that it’s reached complexity overload, see figure 1.
Figure 1. EC2 Options
Cloud providers make it easy to spin up new machines. If nobody is paying attention and access is not tightly controlled the first you might notice extra cloud infrastructure is when you get the bill.
From a security perspective, complexity and security are not a good mix. A hacker is looking for the weakest link, an unlocked door. Increase the complexity and the chances increase that you or your developers will miss something.
There are often multiple security schemes to choose from with no simple explanation on how each choice could compromise your data. And if you do get hacked it’s often unclear who should take action and who is responsible – you or the cloud provider. It’s also not the most efficient time to figure out where the logs can be found and whether or not the backups are working. So planning is essential.
OWASP Cloud Top 10
A good place to start is the OWASP Top 10. Just like the mobile security we’ve looked at in the past, cloud security also has it’s own dedicated Top 10 Cloud risks. This will give you a big picture from a security perspective so you can drill down into the specifics.
R1 – Accountability and Data Ownership
R2 – User Identity Federation
R3 – Regulatory Compliance
R4 – Business Continuity and Resiliency
R5 – User Privacy and Secondary Usage of Data
R6 – Service and Data Integration
R7 – Multi Tenancy and Physical Security
R8 – Incidence Analysis and Forensic Support
R9 – Infrastructure Security
R10 – Non Production Environment Exposure
Some of these are obvious and some not so much so let’s talk just walk through them one at a time.
R1 – Accountability and Data Ownership
Amazon EC2, Azure and Google provide the hardware and software to run your servers. You are responsible for the security. But what is we’re using a platform as a service or PAAS. For example if someone sells the Tableau Server sitting on Amazon’s EC2 cloud. If something happens should you call the PAAS vendor, Amazon or even Tableau when there’s a security issue.
R2 – User Identity Federation
Most businesses will try to create a single sign on arrangement for their user’s as they log in to multiple business applications. This federated database of logins is primarily for better user experience. However from a security perspective it allows you to easily remove a user from all applications when they leave the company.
R3 – Regulatory Compliance
Data stored in the EU has different privacy regulations than data stored in the US. Healthcare data has much more strict HIPAA (US) or PIPEDA (CA) restrictions than other data. You may see them as so restrictive that you moving healthcare apps to the cloud is not for you. We also have to worry about SOX, PCI and other regulations based on your application.
R4 – Business Continuity and Resiliency
What happens if your data center is down due to bad weather or other issues. Does the data center have a disaster recovery plan so you can get back up and running as soon as possible. If the data center is swept away where are your backups are they up to date or not?
R5 – User Privacy and Secondary Usage of Data
When you put your data in the cloud you automatically give up control of that data. Is your provider using that with your knowledge – such as Google’s email scanners – or without your knowledge and selling it to third parties? Should you look at encrypting or anonymising the data before uploading it.
R6 – Service and Data Integration
Cloud services and APIs or microservices often go hand in hand. How secure is the REST API calls, how secure are the databases that hold the data. Should you encrypt the data and how do you manage all those keys?
R7 – Multi Tenancy and Physical Security
Space in the cloud is typically shared space, does the provider have enough protections in place to that no other tenant can see your data? Can you add extra protections to your apps so that another virtual machine can’t get at your data if it’s hijacked. Human nature being what it is someone can make an incorrect access control change that could open up your shared space to attack.
R8 – Incidence Analysis and Forensic Support
It’s 2am in the morning do you know where your logs are? Do you know where your logs are across all connected applications? Platform as a service and complex cloud architectures can make it a nightmare to find the logs to halt an attack and then analyze what happened later. In the cold light of day the necessary logs may just not be available unless you plan ahead.
R9 – Infrastructure Security
How secure is the infrastructure, what ports are open by default. What are the default passwords. For many of the larger providers this is probably known but what about the smaller providers. Should you or some other third party scan the site to verify what is and isn’t open.
R10 – Non Production Environment Exposure
If you have development, test and production environments and the test and production are up in the cloud. Make sure your other non-production environments are just as secure as your production environments. Test can often be the weakest link.
Resources
Here are a number of resources that you might want to check out for more information:
Amazon’s Identity and Access Management best practices.
Azure Security best practices.
Conclusion
To conclude I would like to offer a call to action for anyone using a cloud provider. First start an audit of your existing infrastructure so that you know who has what access level to what machines. Set guidelines and stick to them. Find out where the logs are and how you can access them. Report on the data so you can begin to see if there any exceptions. Automate the reporting.