In a recent document written by virtualization.info and Secure Network of Italy entitled Securing the Private Cloud several issues come to mind. While this is a good document on the availability front of virtualization security, integrity or confidentiality were fairly well ignored. You cannot be secure if you ignore 2 of the 3 tenants of security. Furthermore, this document states that two very important aspects of cloud and virtualization security are considered ‘Nice to Haves’ instead of requirements per the following figure.
Accountable to me implies audit, which may be related to charge back but from a security perspective should be able to tell me who did what when where how and hopefully why. Chargeback as Accountable is defined here is a business requirement, not necessarily a security requirement. This is the concept of integrity. How can I verify that my data has not been modified.
Multi-tenancy to me implies legal ownership of the data external to the cloud, the classification of the data within the Tenant including the applicable regulatory compliance and organizational audit controls. Assuming there are not Multiple Actors within a Private Cloud is short sighted. Multiple-Actors could be machines within a DMZ, machines holding PII, those that take place in PCI, etc. This is impart integrity but mostly confidentiality, how can I ensure my data is confidential?
Granted the document does require Elasticity, Reliable Service, Scalability, Resilence, and On Demand computing which are in essence all Availability concerns but do not address Integrity or Confidentiality.
The document further goes to detail that you need to some how send the security requirements to the cloud, or as I have been stating ‘dial’ the security levels to where the Tenant requires these security levels to be set. This implies that the Cloud provide must first make available those ‘settings’. Per the document all the inspected cloud providers do not have that capability. I was shocked when I read through the list that companies that employ vSphere were left out such as those that provide vCloud Express (Hosting.com, Rackspace, etc.) or full blown VMware vSphere private clouds such as Terremark, Rackspace, etc. The whitepaper does mention vCloud Express however as a way to provide multi-tenancy, but not that secure multi-tenancy. Which is actually true.
However, the requirements they stated at the beginning of the document do not discuss Integrity or Confidentiality. These are mentioned mid-way through the document and only sort of in passing. Yet the analysis was done on the ability to dial in security requirements but not what requirements they actually attempted to set, one has to imply it is availability requirements first mentioned.
There are actually a number of security tools currently available to cloud providers and in use by them to enable network fencing as stated in the document as well as regulatory compliance auditing and other aspects of cloud and virtualization security. These were conveniently overlooked by the research in this document.
Amazon can make use of Catbird Security for compliance auditing. While this costs extra, Catbird Security products can work within this environment.
Terremark public and private clouds have some of the most advanced security through the use of VMsafe, vShield Zones, and other technologies such as Netwitness and Zenoss to improve the availability, integrity, and auditing of their systems and networks.
I am also sure, but do not have proof, that the other virtualization security tools are also in use within many clouds today that use VMware vSphere and other hypervisors.
Private clouds hosted within a companies data center are one thing, those hosted by cloud providers are entirely different. The later is where Secure Multi-tenancy is extremely important. You need to protect your data from the cloud provider administrators that do not work for the organization.
This whitepaper implies that public clouds are single use without multiple-tenants. I do not think that will ever be the case. Multi-tenancy to me implies legal ownership of the data external to the cloud, the classification of the data within the Tenant including the applicable regulatory compliance and Tenant audit controls.
How can any research into the security of a Clouds ignore such basic fundamentals such as Integrity and Confidentiality?
Hi
I very much appreciate what you’re bringing to the discussion here.
All the conceptual elements are here: ownership, confidentiality, integrity and — yes — availability.
What I think we might need next is a crisp, axiomatic chart showing the term, what it means, some examples in the real world, and — ideally — what sort of approaches would yield the result.
Example?
Term: Confidentiality
Problem statement: clouds are used by multiple tenants, hence resources are shared and not physically dedicated or isolated: network, compute, storage.
Definition: mechanisms and assurances that no one other than the tenant’s authorized agent has access to the tenant’s information.
Common scenarios: cloud administrator has access to tenant’s information through administrative means, re-use of shared storage brings tenant data with it, proving to auditors confidentiality protections are in place, etc.
Suggested technologies: encryption w/key management by tenant, validation that encryption methods are working and enforced, validation that the tenant’s environment has not been internally subverted, etc.
I think we’re getting close to narrowing the discussion to a “single slide” or chart.
Thoughts?
This is a possibility, but instead of talking about resources, I think the real conversation is about the data whether at rest or in motion. I am not sure still if we should discuss it as separate entitities (rest vs motion) when I consider it all to be in motion and ‘scattered’ is the best term I can think about. Backups scatter data all over the place as do vMotions, SVMotion’s, snapshots, etc.
Thoughts?