Got you with that title, huh? :)
Every couple of weeks, I join a number of other folks in the security business on Edward “Texiwill” Haletky’s Virtualization Security Podcast. Today’s episode, Sept 6th 2012, was a bit of a round-up of VMworld 2012 with a pretty good discussion on Big Data and Software Defined X, where X could be Datacenter, Network or Security.
Near the end of the podcast we were talking about what would Software Defined Security actually be. I chimed in with my thoughts. No surprise if you follow this blog, but for me it started with infrastructure.
SDx
First, for the purposes of this blog post, let me share my definition of Software Defined X. SDx is where everything (and I mean EVERYTHING) is programmatically accessible. Basically, everything is available and manipulated via API’s.
At VMworld, VMware talked about “Software Defined Security as vShield/vCNS (vCloud Networking and Security). Allwyn Sequeira from VMware had a great presentation on this here. They are doing an excellent job around the network portion of what one could call Software Defined Security and I’m sure they’ll knock it out of the park moving forward. But, as usual, I want more. Let me explain.
Here’s what I’d like to see from VMware
Today, the objects in vCenter (VM’s, network, storage, etc) can be controlled using the RBAC capabilities of vCenter. But I think it’s time to start thinking about more. What I’d like is an enabling technology. One that can enable a new/better way of managing, security and reporting objects in vCenter. I’d like to see the ability to add digitally signed meta-data to an object such as a VM, network or storage. Because it is signed it provides verification that it hasn’t been tampered with. This should work in hand in hand with a root of trust that starts from the hardware on up.
Why digitally sign? Why not just put stuff in the .VMX file? Because, any admin with enough privileges can manipulate that data. Signing the meta data would mean that the meta data would be invalidated or changed if the VM was copied for example. All this has to happen at the Hypervisor and control plane (vCenter) level.
For VMware vSphere 5.1, VMware has added Tagging, which, while useful, isn’t signed so it can’t be fully trusted. It’s a handy thing for IT guys but not good enough for security.
So, if we could digitally sign information it means we can now start to do interesting things like apply and enforce policy, generate reports and orchestrate actions. Here’s an example of what I’m thinking of.
- Create new VM
- VM meta-data added. I create a digitally signed tag of “PCI” using a “PCI” key.
- VM is also digitally signed to only run in a specific cluster
- Upon creation, I choose to try and put the VM on a non-PCI network.
- The policy enforcement engine says only non-PCI VM’s are allowed on the non-PCI network and blocks that action.
- And sends a log to my SIEM and into my GRC solution!
- Ok, I change the network to be PCI and the VM is ready to be powered up.
- A disgruntled admin logs in but he doesn’t have PCI rights so he can’t change the VM. He also can’t copy the VM.
- And because I’ve created a policy that PCI VM’s can only be managed via a VMware Orchestrator workflow that’s been signed with the PCI key, even *I* can’t delete the VM without going thru an approved PCI workflow in Orchestrator
As you can see, this type of ability would go a long way to managing LOTS of VM’s that fall under different regulatory compliance umbrellas. Working in concert with logging solutions and GRC solutions, you can be assured that only the right people are touching the right things and that workflows can be enforced at the infrastructure layer, ensuring compliance. Also, because everything is programmatically addressable, it becomes VERY easy to measure and report on all those actions and workflows, sending that information into a Governance, Risk and Compliance solution.
So what’s the downside?
The big downside is that you really, really need to architect the security of the control plane. With it all being in software, you need to be even more paranoid…er…diligent about securing all the logins, network, etc that these API’s will be running over. For example, you may want to run all the control plane parts in a separate, non-routable network to minimize exposure to the bad guys.
I want to hear from you!
I’d love to hear your thoughts on this line of thinking. As you can tell from the podcast, I got a number of the other participants to agree. What I’d really like to see is someone picking this apart. It’s how we’ll all learn. This blog entry is by no means complete. More of a stream of consciousness like most of my blog posts.
Disclaimer
This blog was written with NO advanced information from VMware, purely from my brain. VMware, if you are doing something like this then I can’t wait to see it! :)
Thanks,
mike