Security in the Cloud and the CCSK

Search for cloud computing and you will get approximately 190 million results, search for cloud computing security and you will get 120 million results. This is very rough data of course but it gives us an idea that when talking about Cloud, security is a big concern. Go to a conference and talk about Cloud, and you can be certain that one of the big questions you will get asked is "But what about Security ?"

Disclaimer and bias: This question always leaves me pondering, mostly because my personal background and bias always makes me wonder what people are afraid off in the Cloud and what do they see that Cloud brings to bear that is different from any existing distributed systems running over the internet. I am not an enterprise security expert, I used to teach an introductory course on network security, but I have spent my fair share thinking about Clouds especially at the IaaS layer. There, the new technology that could represent a new attack vector is virtualization and I only read about two non-traditional efforts that really challenged the security of virtualization: the controversial bluepill project in 2006 and the cross-VM side channel attack reported by a research group at MIT in 2009 (there are of course more...). Most problems publicly described with IaaS have been with spam and DDOS. Where on one hand cloud providers are being used to send spam and on the other hand cloud providers are victim of DDOS threatening the availability of services.

However, in the fall I had the chance to participate in the DELL in the Clouds Think Tank in London. It is there that I started to understand that what most people where worried about with the Cloud had more to do with legal issues, governance, compliance and contracts than hardcore attacks. Indeed when dealing with a cloud provider you are exposing your data to new risks for the simple fact that it is not under your total control and you need to manage those risks. Moving your data out of your secured premises and putting them in the hands of another party exposes you to new threats. This is the core of information assurance and risk management. Cloud security is therefore more about updating your security guidelines, making sure that you are compliant with the law and being confident that you can respond appropriately to any attack or business continuity issues. Cloud security is less about the fear of a new technology that exposes new attack vectors. The risks may be new to your enterprise but the attacks and vulnerabilities used are not new to the internet.

To learn more and come up with a plan I now point people to the Cloud Security Alliance (CSA) and their guidelines. It is a 176 pages document which coupled with the ENISA cloud security assessment (125 pages :)) forms the basis of the CSA Certificate of Cloud Security Knowledge (CCSK). I have finished reading the CSA guidelines and once I read the ENISA report I will take the CCSK exam.

The CSA guidelines are a set of reports covering fourteen domains of interest to Cloud security. From Governance and Legal Issues to Incident Response and Virtualization (to name a few). One sentence truly resonated with me due to my personal bias explained earlier. It is in the Application Security domain chapter which states: "Cloud-based software applications require a design rigor similar to an application connecting to the raw internet - the security must be provided by the application without any assumptions being made about the external environment" indeed doing the opposite would be one of the fallacies of distributed systems design enunciated by Peter Deutsch from SUN. There lies in my view the biggest risk, thinking that you can take an application that has been designed in-house assuming a secure local network and wanting to move it to the cloud as-is not managing the risks due to the fact that a) the network is not secure b) bandwidth is not infinite c) latency is not zero d) transport has a cost.

Any service, application, provider, data that is accessible over the public internet is being attacked and is subject to risk of being stolen, tempered with, disrupted and even shutdown. This is not fear mongering, it is just a fact and if you design an application or use a service thinking otherwise you will be exposing yourself and not managing risks properly. Similarly to the new cloud software being developed (e.g Hadoop, Cassandra, CloudStack), that are designed assuming failures of components, when moving to the Cloud one needs to assume attacks and unsecured networks. This is not saying that the Cloud is unsecure, this is saying that you need to adopt the proper security posture, a different one than if you have been operating under the -at least perceived- warmth and coziness of a secured local network.

Getting back to the CSA guidelines, the first domain Cloud Architecture is the perfect introduction to Cloud with reference to the NIST definition of cloud computing. It then follows with what I think is the most important section: Governing in the Cloud, it presents risk management as key to an enterprise governance and introduces legal issues and compliance management as it pertains to Cloud. The chapters help to define the proper security posture, defining or updating security policies that will make sense for Cloud use, understanding the assets that will be at risk and understanding if and how compliance will be enforced. As such it is not specific to Cloud computing, it is really best practices of risk management and understanding the contracts being signed with the cloud providers. Will those contracts expose you ? Do providers follow data protection standards ? Are the providers subject to any laws that may expose you (e.g Patriot Act) ? How can you remedy those risks ? Which providers can give you the compliance you need ? To help with these decisions, CSA created the Security Trust and Assurance Registry (STAR). Cloud providers who participate in the registry submit answers to a questionnaire that lists the standard they follow in 99 categories from audit and compliance to operations, business continuity, human resources, forensics. This registry is key to choose cloud providers that will match your security and governance needs.

The last section of the CSA guidelines is about Operating in the Cloud. From Disaster recovery, data center operations, incident response to encryption, authentication and virtualization. This section is not specific to cloud but comes into play in selecting providers to ensure for example, that the provider data center operations matches your requirements. Or to ensure that in case of incidents you will have access to the logs (defining which ones in a contract). I was pleased to see John Kinsella (@johnlkinsella) from Stratosec as one of the authors of the chapter on Application Security. John is a member of the CloudStack Project Management Committer (PMC). I was also happily surprised to see a chapter on Security as a Service something that Mice Xia from tcloudcomputing and a committer on CloudStack has been working on.

To summarize, knowledge is power (a bit cheezy I know). When moving to the Cloud, an enterprise should engage their security experts from the on-set making sure that risk is managed and that everything is in compliance, this is standard information assurance and part of good enterprise governance. When negotiating (or not negotiating) contracts with Cloud Providers the STAR registry can help choose the providers that will best match the requirements of the enterprise. I am not being paid by CSA or SANS, but I would recommend people to get the CCSK certification and probably also a SANS course on Cloud Security. In my opinion the cloud is not less secure than anything else. The Cloud (at least in its public form) is about accessing resources over the network and locating assets off-premises, this intrinsically presents risks but it is manageable risk that needs to be part of a design. You need to design for attacks, test your designs, monitor, counter-strike. Basic warfare. And remember, the network is secure...Oupss...sorry !