On the January 2, 2014, the Virtualization Security Podcast was joined on the spur of the moment by @Josh_Atwell, who works for VCE, to discuss the security of converged infrastructures. This was of particular interest to me due to my current research on the security of a VCE Vblock. The research got me thinking about converged infrastructures in general. Before the podcast, I posed two questions on Twitter:
- Are converged infrastructures more secure than traditional implementations?
- Can converged infrastructures be more secure than traditional implementations?
There is quite a bit of hype around converged infrastructures, but none of it goes into security. The important question to pose to the architects of a converged infrastructure is whether security is even considered, as the security of virtual and cloud environments starts with architecture. Though security here is key, the security goals and policies to which organizations must adhere differ wildly from organization to organization, which implies that no single architecture can meet everyone’s security requirements. Other items are necessary. Even so, there is a base list of elements within the control of a converged infrastructure vendor that are more fundamental, and which the vendor can implement.
Here are some thoughts from the podcast:
- The architecture for a converged infrastructure goes beyond a simple logical diagram. There are reasons certain elements are chosen over others within a vendor portfolio. This architecture and reasoning needs to be shared. Sharing a logical diagram is not enough to determine how everything fits together, what makes up the converged infrastructure, how is it updated, what requirements were being met, etc.
- When a converged infrastructure is ordered, there is time as it is being built for organizations to create their own architectures that are based on the ones from the vendor. There is a need to expand the architecture to include all of the required security controls. Relying on a converged infrastructure to provide all the necessary controls is, in effect, securing neither the device nor the environment running on top of the device.
- A converged infrastructure should provide an easy button to harden all components within it to a given profile. However, this would require all hardening guides for all elements of the converged infrastructure to share the same profile definitions and to be codified so that tools can be run automatically. Hardening, however, is just a small subset of security.
- A converged infrastructure vendor should be able to verify the supply chain of firmware, drivers, etc. that are required to make the hardware work with a chosen hypervisor. Supply-chain security is a big question, as hacks appear not only against code but now also embedded within firmware.
The most important thing we need from converged infrastructure vendors is better documentation. A diagram is not an architecture; we need more. We need to know how everything fits together. Why? Because most converged infrastructures are not black boxes, but instead leave layer 3 routing, as in the case of a Vblock, up to your core switching. This implies that when you are looking to secure a converged infrastructure, the security of elements of your existing data center also come into scope. This in turn implies that your own architectures, security policies, and other documentation must now consider the converged infrastructure and perhaps its individual components. Most importantly, the security of the workloads within a converged infrastructure is the responsibility of the organization, not the vendor of the converged infrastructure.