So – today RSA, the security division of EMC announced a very cool capability – a simple VMware security dashboard that integrates with vCenter, ESX/ESXi, with vCenter, RSA Data Loss Prevention suite, VMware’s vShield family (more on that soon), VMware vCloud Director, VMware vCenter Configuration Manager, EMC Ionix portfolsio, and HyTrust appliancevShield family of products (along with other partners). It brings everything up to a high level dashboard which continuously assess state – and helps remediate (aka “fix”) problems. It’s a solution for Cloud Security and Compliance.
We also showed the next step of the evolution of “Project Roswell” – an ongoing effort between VMware/RSA/Intel to bring an unbelievable set of compliance capabilities to public clouds, enforced in a hardware root of trust.
There will also be an RSA Securebook on Cloud Security published in October that covers these topics for people who are in the security business…
Ok a bit of background…
So – I asked in the open “VirtualGeek 2010 Survey” (full results here) 2 basic questions. “Is security an issue for you”. Of the 121 respondents to that question – it turns out it is (to varying degress) to 71% of the people.
Then I asked people to be a bit more specific about degree of “security pain”.
If you look at the stack ranking (and the detail on how many people ranked those issues as high priority) – it’s clear:
1) People don’t know how to harden their virtualized environment; and 2) EVEN IF THEY DO, they don’t know how to prove it (and if you can’t prove it, it’s not much good).
While I asked the question knowing what we were going to be announcing this week, I had NO IDEA how people would respond (frankly I expected encryption and hypervisor attacks to rank higher).
I guess the RSA folks know what they’re talking about :-)
So – the RSA Solution for Cloud Security and Compliance is pretty darn cool. Rather than explaining any more – this demonstration says it all.
I don’t know about you but that little example used (one of 100+ checks) I do all the time. A given VM needs the vSwitch to be in promiscuous mode for some weird reason, so you just flip that switch (while there are legitimate reasons for promiscuous mode, often its a hack workaround for something – and a better thing would be if promiscuous mode was not needed by that given VM). Once it’s done, you never think about it again… hopefully. Imagine that kind of problem, but at scale, and with ALL the things that one “just changes” and then never thinks about it again. How could you possibly audit and fix that on an ongoing basis. Answer is that without something like this – you can’t.
This new capability from RSA is simple on a fundamental level a dashboard and remediation workflow for: 1) VMware security hardening; 2) PCI and HIPAA compliance; 3) that merges the physical and virtual worlds.
At the same time – we demonstrated the continuing development down the path of “Project Roswell” – which is focused on end-to-end compliance in clouds, both public and private – and using a hardware root of trust to reinforce that. Roswell leverages what each of the 3 partners are doing – Intel with TXT, VMware in vSphere and RSA.
So – what we demonstrated back in March at the RSA was instrumenting Intel TXT and vSphere 4.1 to not only do what we GAed today with the RSA Secure Cloud, but add the ability to ensure that the vSphere VMM wasn’t compromised, and be able to attest to that (being able to PROVE it is very important). You can read it up in an independent site here: http://www.chriswolf.com/?p=519.
What we showed is that we’ve made more progress – leveraging the Intel TXT capability with vSphere and RSA Archer to audit for FISMA (read up on that here) compliance. FISMA is the US legislation about information security, and one part of it has to do with information staying in geographies – specifically the US as an example. To be even handed, many national entities have analogous legislation for other places, such as Germany. “OK Poindexter…” you may be saying, “… what are you talking about and why does it matter to me?”.
So – as people look to move workloads into public clouds, the “where in the world is Carmen Sandiego” problem gets really hard.
If you think about it – where a compute workload is running as it is able to move anywhere gets harder and harder to identify, but more importantly, harder and harder to attest to on demand as an intrinsic part of a service. How would you do it? Find the ESX host the VM is running on and physically find it in the datacenter (when perhaps even that server itself has a transient persona?).
So – unless you can audit WHERE a VM is (without overly restricting it’s mobility), some workloads won’t move to clouds.
What did we show? The answer to how you could do that. Well, as I’m often a fan of saying – a demo is worth a thousand words :-)
You can download this demo in high resolution MP4 format.
We’ve demonstrated the ability to geo tag to the Intel TXT hardware itself, leverage the vApp wrapper to apply the geo-location rules, and integrated that with the RSA Archer Governance, Risk and Compliance toolset to audit against that state.
We’re not stopping here. There are incredibly bright minds at RSA and other places working on all sorts of ways to heuristically comply with all these standards (in the same way that RSA active authentication heuristically works at banks to keep your money safe).
The policy standards were written by bureaucrats, congress-people and lawyers with no understanding of technology – but for good reasons for national security. We think we can crack the nut to apply the governance rules, but do it in a way that doesn’t hamstring all the power, efficiency, dynamic nature that comes from Private and Public cloud models.
Now, that vSphere 4.1 advanced ESX setting we set in the demo isn’t officially supported in vSphere 4.1 (which is why we aren’t talking about this as GA yet), but shows where we are doing.
Pretty darn cool if you ask me – both the shipping capability and the direction. What do you think?