Microsoft’s answer to VMSafe

The last couple of days the blogosphere has been a buzz about possible alternatives to VMSafe API. Chris Hoff started the discussion with this blog post, which a number of people picked up on and expanded including virtualization.info. I thought I would put in my two cents:

It will be interesting to see how the market reacts to VMSafe in late 2008- early 2009 when ESX 4 is being rolled out and VMSafe enabled VMs are available. That gives Microsoft and Xen about a year to come up with an answer.

Microsoft has two options, to become the single security player for Hyper-V, or follow VMWare and try and create a ISV ecosystem around a hypervisor security API.

I believe Microsoft purchased Komoku (advanced root-kit detection) to roll their technology into a Hyper-V Windows Defender product. This would allow Windows Defender to take advantage of the benefits of malware detection from outside the operating system, and at the same time offering a security option to secure multiple Hyper-V guests. This would be a feature of Windows Defender and not the Hyper-V framework.

It would be interesting if Microsoft worked with Citrix to make available the Virtual Machine Introspection (VMI) interface that Komoku developed to both Xen and Hyper-V. This would effectively create a second standard to VMSafe, “Hyper-VMI” which could be used across all Xen and MS environment.

Either way Xen and Microsoft need to have an answer to VMSafe as the discussion on securing virtual infrastructures will be heating up..

Single Malt PCI

Seems PCI DSS and scotch have something in common - they both are easier to take when watered down. Martin McKeay points to information supplements from the PCI council clarifying sections 11.3 (penetration testing) and 6.6 (application code review, web application firewall) of the v1.1 standard. The exact text of the standard follows:

6.6 Ensure that all web-facing applications are protected against known attacks by applying either of the following methods:

• Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security
• Installing an application layer firewall in front of web-facing applications.

Note: This method is considered a best practice until June 30, 2008, after which it becomes a requirement.

The second bullet has single-handedly driven the WAF space into overdrive (a good, but perhaps premature, thing IMO). The first bullet has always been a bit vague, but the recent clarification explicitly weakens it. From the supplement:

Properly implemented, one or more of these four alternatives could meet the intent of Option 1 and provide the minimum level of protection against common web application threats:

1. Manual review of application source code
2. Proper use of automated application source code analyzer (scanning) tools
3. Manual web application security vulnerability assessment
4. Proper use of automated web application security vulnerability assessment (scanning) tools

Since either method (code review or WAF) satisfies the requirement, compliance with 6.6 is now just a matter of a WatchFire or WebInspect scan. It's certainly less stringent then a manual source code review, which was how most had read it. The scanning cop-out also seems slightly redundant with section 11.2, which already mandates network scans.

Oh well, I suppose you can just go with these guys and be done with it. Back to your regularly scheduled virtualization-related program...

Where's Cisco?

As Kevin mentioned, the VMsafe APIs certainly allow for an entire security ecosystem to grow around ESX. VMware has a fair number of partnerships in place, but where is Cisco? One would think that a company with oodles of networking experience, an increasing large security footprint and, ummm... $150 million invested might have some interest in this. No doubt they do, and I'm guessing the neutron bomb that is Cisco will drop soon.