On many a Virtualization Security Podcast I tend to mention that we need greater visibility into the cloud to judge whether Cloud Service Provider security measures are good enough. But why should we bother? I am not saying we should not be concerned about a cloud’s security but that we should as tenants be concerned with clouds meeting our security, compliance, and data protection policies and requirements. Will a cloud service provider ever be able to meet a specific organizations requirements as well as the cloud service providers policies and compliance?
When we consider the cloud, we are considering all the baggage that comes with the cloud such as a specific cloud service providers security posture, but I think we need to step back for a moment. We need to consider first and foremost our own security posture with respect to the data, ask yourself the following questions:
- What data is being placed in the cloud
- Why is the data being placed in the cloud
- How will this data be accessed within the cloud
- What is the Security requirements of this data (is it confidential, eyes only, public information, etc.)
- What is the Compliance requirements for this data (is it Personal Identifiable Information, etc.)
- What does our Security Policy say about the data to be placed in the cloud
In essence, when we look at the cloud, we should be looking at our data. How do we PROTECT our data, not how does the cloud’s security posture measure up to our own. As the later answer is, it will never measure up to our own, it is the cloud service providers security policy, not our own. Given this, we need to reconsider the security measures we take when we enter the cloud.
Gaining Visibility in the Cloud
Our entire goal is to provide not only a defense in depth, but visibility into the cloud. To that end we should be willing to create our own additional security within a cloud instance. Let us take on a few different clouds with respect to adding our own security so that we can gain more visibility. Our real goal is to know when our data is touched, by whom our data is touched, how our data is touched, and where our data was touched. In essence, not only security but a full audit log to prove our security policies around our data in the cloud was met. So how do we do this?
Software as a Service
With Software as a Service (SaaS) clouds we have very little control over how the data is handled internally to the cloud, but we have control over how our data enters the cloud. For SalesForce style SaaS clouds we can use format preserving encrypting gateways to enter our data into the cloud encrypted as well as choose a level of service from SalesForce that allows us to get an audit log of who (user or device), what (records), when (timestamp), how (query types), that our data has changed. This report can come once a week or as often as you want to login and look at the audit log of the data within SalesForce. In essence, we have augmented SalesForce’s own security to provide integrity and confidentiality, with our organization owning the keys, while making use of SalesForce’s native audit capabilities.
However, on the flip side of this is a SaaS cloud like DropBox which initially do not seem to have audit capabilities, but it does, there is a way to determine when files change and by whom and where, known as Previous Versions. A previous version will tell you who changed the file (user), where it was changed (device), as well as when (time) it was changed. However, we may need to add some form of integrity (digital signatures) or confidentiality (encryption where we own the keys) into drop box. Some say to use a True Crypt image into which we could drop the files as needed, but then we would only see the true crypt image has changed in an audit log, not which specific file inside the true crypt image has changed. So we are also looking at per file encryption or digital signatures. This is best handled by an encrypting gateway to dropbox but could be handled individually as well.
For every SaaS cloud out there, there is a way to augment the security posture of the cloud to gain better overall security for the data within the SaaS cloud. What we use, how we use such additional security depends on the type of cloud and whether they provide some basic requirements. So in this case we need to know what the SaaS provider has available to us.
Infrastructure as a Service (pay as you go, or full infrastructures)
For Infrastructure as a Service (IaaS) of any form (pay as you go ala Amazon through full infrastructures ala Terremark) there are many additional security measures that can be put into place and that depends entirely on the underlying technology to build the cloud. Below, is a Possible IaaS Security Augmentation Architecture that takes into account all types of possible hypervisors.
Does this duplicate what a cloud may already have? Absolutely, but it provides the ability to perform your own security assessments to determine if your data is protected per your security policies. Cloud service providers in effect provide us a new layer of hardware, we need to build our security on top of it to maintain our visibility into the cloud.
Ending Thoughts
While it is important for cloud service providers to provide to their tenants visibility all the way down the stack, when push comes to shove and the breach happens, companies fall back onto their security policy and without visibility there is no method to determine if you have met your security policy requirements. To this end cloud providers must become our partners with respect to security and compliance. They need to embrace some mechanism that allows us as tenants to verify a cloud service providers security posture against the tenants own security policies. But we as tenants, until this changes, need to consider the cloud the wild west and protect our data appropriately. We need to move security closer to our data and expect bastions to no longer exist. At the end of the day, we need to augment a cloud with our security policy requirements.