Yesterday RSA announced new controls for virtual infrastructure security in cloud environments. Concerns regarding security and compliance have been primary factors preventing large enterprises from placing production workloads on shared virtual infrastructure in the cloud. Yesterday’s announcement and proof-of-concept didn’t solve all of public cloud’s security woes, but it brought us closer to a practical solution. In case you missed it, you can read a detailed overview of the solution in the RSA security brief “Infrastructure Security: Getting to the Bottom of Compliance in the Cloud.” Even if you’re not ready for public cloud, many of our clients have expressed concerns over mixing security zones or subzones on internal private cloud infrastructure. Instead of supporting multi-tenancy (i.e. multiple departments traversing multiple security boundaries), the conservative IT organization isolates security zones using dedicated physical infrastructure (e.g., separate physical clusters, network ports, and storage). Even if you build in security controls in the virtual infrastructure, how do you expose them to the auditor? To date, that has been a problem.

In the past, I have talked about this security dilemma in a couple of couple of key areas. First, we need a standardized set of cloud isolation levels. We also need standard metadata (either de facto or industry standard) so that third party audit tools can properly query an application’s relationship to cloud security policy in relation to virtual and physical controls that are in place. I covered those issues in more depth in the post “The Cloud Mystery Machine: Metadata Standards.” In addition, virtual resources need to be able to answer the question “Where are you?” That applies to both the runtime location and data location. It’s important to ensure that data privacy and governance concerns are met, and regulatory compliance issues such as data export restrictions are satisfied. Ideally, the answer to the question will provide details on the hardware root of trust (the hypervisor and physical infrastructure is secure), relationship to defined pre-defined security tiers (the RSA POC uses “platinum,” “gold,” and “silver",” and “bronze,” for example), and provides the detail needed to prove that both data and application runtime security requirements are satisfied.

Rather than summarize all of the goodness in the RSA announcement, I’ll focus on the areas where it still falls short. For starters, neither EMC nor Cisco were part of the POC. So the existing model does not detail concerns such as data location and the privacy of data at rest. Naturally, there is quite a bit that you would expect Cisco to offer too. The Nexus 1000V has plenty to offer when it comes to security inspection and enforcement on shared virtual infrastructure: L2-4 ACLs, SPAN, ERSPAN, AAA, and more. Naturally, any de facto tiered security models offered by RSA and its partners should go as far as to include advanced network and storage requirements, and I expect them to do so over time.

Now that RSA, VMware, and Intel have taken this big step toward satisfying the security concerns associated with shared infrastructure-as-a-service (IaaS) architectures, it’s time to be transparent on metadata structure. If each service provider builds its own proprietary metadata schema, we’re in trouble. Instead, vendors such as VMware need to define a more robust metadata schema within the .vmx configuration file. In a perfect world, VMware would toss .vmx to the side and work with the DMTF to take the XML-based .ovf standard from a standard for VM importing to a standard for runtime metadata. If we had that, RSA, VMware, and Intel can continue on their current path, and third party vendors could add their own custom controls as well. In addition, the standard could be applied to all hypervisors, such as Hyper-V and XenServer.

While I expect this announcement and forthcoming innovations to be a boost to public cloud providers, the work of RSA, VMware, and Intel will pay immediate dividends for each organization’s internal cloud plans. The more compute resources that can be shared, the lower the capital and operational expenses to run the data center. Solutions that enhance visibility, improve security, and create opportunities to share more physical infrastructure are no-brainers, in my opinion. I could spend much more time discussing the details of the RSA POC, but I’ll leave that for the RSA white paper. Also, if you would like to hear more about where this solution is going, I encourage you to attend Catalyst Europe next month. RSA CTO Bret Hartman will detail RSA’s vision for cloud security at the conference, and will be on-hand to answer your questions as well.