Securing Clouds from Service Providers

Secure multi-tenancy is not just about ensuring security and segregation between tenants. It is also about limiting, auditing, and tracking the activities of a cloud service provider within a tenancy or that touches upon more than one tenant, which of course includes any activity that occurs within the hypervisor, storage, or other layers of the cloud. In the past, I referred to this as the delegate user problem. We were joined by Skyfence (now Imperva) on the April 24 Virtualization Security Podcast to discuss its transparent gateway solution for cloud access, and I had another thought on usage. Perhaps now we can solve the delegate user problem. 

Securing Clouds: The Status Quo

The status quo for securing clouds today is to have the cloud provider provide all security—to depend on that provider to secure everything. When we perform ELT on storage clouds, we may encrypt our data before placing it into the storage cloud, but the vast majority of the time this just does not happen. We just pump data into the cloud, either praying for or having negotiated security via some SLA. However, when an audit comes around, our visibility into the cloud is limited at best, non-existent at worst.
Try getting Amazon or any of the other large cloud service providers to allow you the right to audit its environment, written into your contract. If it is not in your contract today, you have no ability to audit outside of your tenancy. The contract, however, is not the real reason for issues. For most, the real reason is a lack of understanding of what should happen within a cloud and blind faith that clouds do security better than anyone else. Perhaps they do, but there is no proof. To obtain proof that our tenancy is secure, we have to build more and more security into our clouds, duplicating, most likely, what has already been done under the covers. The duplication of effort by a tenant allows that tenant to gain control once more: we can add our own firewalls on a per-machine or per-port level, our own logging, and our own antivirus/anti-malware. We also can add our own auditing and trust that we are compliant and secure when we are outside our little tenancy. Clouds impose trust, but without the ability to verify. Specifically, you cannot verify what the cloud service provider administrators are doing within or to your tenancy.

Securing Clouds: The Next Step

The next step in securing clouds involves the concept of transparent gateways. These gateways—from Adallom, Elastica, Skyfence (now Imperva), and others—act by tying into single sign-on services within the cloud that allow you to use your own authentication store, as well as to redirect users to different entry points within the cloud. As they redirect you to a new entry point, they also log all activity within the cloud by the logged-in user. If such gateways are placed before cloud management, cloud applications, and cloud storage, you can literally know who, what, when, where, and how a service was accessed. This audit information can also be used to put in place finer-grain controls than a cloud service provider (CSP) has available. Moreover, it places the auditing burden for the tenants’ management, apps, and storage back into the hands of the tenants. We can now audit, log, and perform further security analysis on what is happening within a tenancy. Unfortunately, we still have to trust the cloud administrators, as they will not generally come into the cloud through our transparent proxy. We still have to trust with no way to truly verify.
Nevertheless, the use of transparent proxies has given us the ability to gain audit and role-based access controls over our tenancies. It allows us to pull log data we would not normally be able to obtain from services—specifically SaaS, PaaS, DaaS, and Storage-as-a-Service clouds. With IaaS, it may be possible to extract some log data without transparent gateways; however, with gateways we receive a whole lot more data. Useful data; analyzable data. This in turn allows tenants to perform analytics in real-time to determine if a breach is underway or something abnormal is happening. All the transparent gateways have some logic like this already with the ability to send the data to another log analysis engine via syslog.

Securing Clouds: The Future

The real future of cloud security is to surround the cloud with a transparent proxy such that even the cloud service providers have to go through the proxy to access the tenant, whether directly or indirectly, and the tenant controls such access. In a case in which a CSP is acting as a managed service provider (MSP), the tenant would allow all access, but in cases where the CSP has not been hired as an MSP, access would be granted on a per-use basis, and all logs would be sent to the tenant, not the provider.
There are still some issues related to clouds that tenants cannot control, such as hypervisors, storage, and other low-level data center constructs. However, if the transparent proxy is good enough, tenants can be informed when something that could impact them occurs. An example of such is the movement of all data off of one storage device and onto another. The transparent proxy would push fairly ambiguous data out to the tenants, indicating that a storage move was made and that it impacted such and such an app, virtual machine, or chunk of data. The tenant does not need to know internal cloud naming conventions; it just needs to know that some action took place on its data. This requires a special set of analytics that would tie everything a cloud service provider does within the physical and virtual infrastructure of a cloud back to a tenant, either by mapping which tenants are on which devices (already available from storage vendors); by mapping tenant IDs to a network, storage device, or the like; or even by using time-based correlation. In this manner, the CSP would have an automated means to send log data (preferably using syslog or something easily imported into an analytics engine such as Splunk, Log Insight, Loggly, etc.) that is applicable to a tenant.

Final Thoughts

Secure multi-tenancy has always been hard to achieve, because the tenant has had no control over the CSP. If we implement transparent gateways in this fashion, tenants can control access to their domains and obtain log data for those CSP admin actions that directly or indirectly impact their tenancies. This is really the holy grail of secure multi-tenancy; transparent gateways that log and control are a part of that solution. Tenants gain visibility, and CSPs offload much of the surrounding compliance, audit, and security analytics to the tenant. This could reduce overall legal requirements for CSPs, convey the right to audit through an existing means of procuring audit data, give control back to tenants that want it, and allow providers another managed service to provide.
I see using transparent gateways in this fashion to be the future of securing clouds, but this would require vendors to create cloud-specific versions that can generalize/sanitize logs for public consumption automatically. As a cloud tenant, would you like to regain control of what happens within your tenancy and at least audit level logs of what is happening surrounding your tenancy? I know I would.