We attended the Netherlands AWS summit near Utrecht this week. It was a good opportunity to meet people who were using Cloud services in the field and talk about the problems they were facing securing them. A phrase that was repeated during the day (including by the Amazon CTO Werner Vogels) that was a really interesting jumping off point for discussions: “Cloud is more secure”.
Full disclosure: I’m a former Amazon employee and I have a lot of experience using AWS services and I like them. I am strong supporter of Cloud and at Cadency we are building our services inside various Clouds, as well as on our own infrastructure. One of our core values is using the best technology for the job and we aim to keep provider agnostic so we can move our services around depending on the requirements we have and who is providing the best service.
As someone who works to help our customers build and secure cloud environments, I can’t help but feel that the missing caveat to this message is: “if you do it right”. The Information Security industry has a long history of promising that a particular technology will make you secure. If you have had the misfortune of attending a vendor sponsored infosec conference then you would have been bombarded with these guarantees. Unfortunately, this is not the reality we live in and these boxes have not ushered in the age of security. Instead of evolving towards stable and secure services we are faced with a weary acceptance of instability and data loss. This makes it vitally important not to make the same mistakes when building in the Cloud.
A Cloud provider’s platform is arguably more secure than the average company data center. Cloud companies have the resources to maintain their infrastructure to a high standard and it is their core business. But, their Cloud is a platform that you build your service on and you need to take the building blocks they give you and turn them into a secure service.
To give an example Identity and Access management (IAM) is a core security primitive. AWS has great IAM, all of it’s services can be authenticated and authorised and it can be federated from within your environment (for example by connecting an in-house LDAP server). This is exciting for developers as it comes for free, you don’t need to build your own access control service. It’s also good news for security engineers as we are able to offer robust security services without adding friction to the development roadmap. But, you still need the engineering expertise to understand how to implement it correctly and a commitment to following these principles. AWS doesn’t enforce the use of IAM it is your choice. It equally allows you to deploy unauthenticated and open services without proper hardening to get you up and running quickly. Whether this is an EC2 instance with open security groups and a shared SSH key or a RDS instance open to the internet with a weak password.
The way that infrastructure change is being accelerated by Cloud providers is exciting for security engineering as it offers the chance to implement services using the design patterns we have always wanted. You want to apply patches as soon as they are released and tested? There should now be nothing limiting a roll out as your services should be designed to both withstand the loss of any one component and be continuously deployed to. A recently discovered vulnerability should pose less of a risk as you can always be running the latest version of the OS. If you don’t ever want your infrastructure in production to be changed then it can be immutable. Micro-service architectures, while fragmenting your attack surface, can allow for the kind of fine-grained access control at every data exchange we have always wanted.
The Cloud is enabling us to build and iterate at an incredible pace but it is also enabling people to build terrible, terrible things at an incredible pace. This is why the phrase: “Cloud is more secure” is interesting; as it certainly isn’t all of the time but it definitely can be.
Originally published on the Cadency blog