We have looked at the hidden dependencies around upgrades (Cloud Dependency: Automated Upgrades) as well as the hidden dependencies around networking (Cloud Dependency: Ubiquitous Networking). Now, we will look at the hidden dependencies on visibility. Or more to the point, the lack of visibility within the cloud. With regard to visibility, the question most often asked is, “Do we know what is happening behind the scenes within our tenancy?”
Visibility is another hidden cloud dependency. What you can see of what happens behind the scenes is dependent on the cloud in question. For example, you may be able to see exactly what is happening within a community cloud, such as the New York Stock Exchange community cloud, but within Amazon, that is not a possibility. You have to trust Amazon, but you have no way to verify the validity of that trust. Granted, Amazon’s claims that they do security better than many folks in the industry is a valid claim. Yet, still we need to verify that statement. Or do we?
When we start examining visibility, do we need to know much more than who accessed our tenancy, what they did there, and when, where, and how they did it? Do we need to know that the tenants’ VMs were moved between hosts within the same availability zone? Do we need to know anything about the shared infrastructure if we can determine that our tenancy was accessed (and that includes our data stored on disk)?
These are the questions we should be asking. I find this dovetails nicely with considerations about moving security closer to our data. I should not care about the underlying infrastructure, but I do care whether the integrity and confidentiality of my data was compromised. Can we use container technology to determine who did what, as well as when, where, and how they did it? Perhaps.
We have talked in the past about Adallom, Elastica, Skyfence, and Skyhigh Networks and their ability to track how our tenancy was accessed, as well as by whom, from where, and how, via the web APIs in use within SaaS and other cloud applications. These are huge wins for visibility. Yet sometimes, we are still missing the other side: the cloud side of the picture. Once more, we have two sides of the cloud to look at for this dependency:
The Cloud Provider
The cloud provider needs to plumb its infrastructure to provide proof that its security policy is adhered to while providing the same proof that a tenant’s security policy was followed. How we accomplish this is still up for debate, as the plumbing and per-tenant segregation of logs all the way down to the hardware just does not exist. This is the delegate user problem all over again.
If the tenant can detect network and other communications itself using various tools, should this also be provided by the cloud provider? Would it not just be a duplication of effort? In some cases yes, but it really depends on whether or not there are any efficiencies to be gained by having the cloud provider involved. In many cases, there are inefficiencies involved. To provide support, however, the cloud provider should never bypass any visibility tools a tenant has added to its tenancy.
The Tenant
The tenant needs to control access to its data, and there are a growing number of tools that provide control. These compensating controls remove the need for the cloud provider to log everything on a per-tenant basis. By moving security closer to the data and virtual machine, tools like CloudPassage and Illumio gain insight and control over data within or accessed by those VMs. Yet, we still have data that is not controlled or accessed by any VM. We also have to be concerned about the application; specifically, how do we secure an application that spans clouds? One solution is Illumio, which detects the communication between systems and maps out that communication as an application. However, its format is not shareable with other tools.
Visibility: The Future
The future of visibility within your software defined data center will be up to you as the tenant. The software defined data center owner can map out applications, determine what communicates with what, and layer on security and compliance measures. The policies and blueprints created and derived need to travel with the data as it moves through each system of the application in question. Ideally, the controls for access will be baked into the data container of the future so that system and application visibility are not necessary anymore, but visibility into the data container is. That container would be controlled by the tenant, not the cloud provider.
Visibility is a major cloud dependency. How deep do you need that visibility in politics and compliance? What does your organization require? Do you have data classifications based on visibility requirements?