Developing Security

Its All About Secuirty

Virtualization Security is never dull.

While much of the spotlight is on cloud, virtualization continues to invoke challenges and invite opportunity in the field of Information Security. Problems that once had few solutions now can be tackled with an ever-evolving toolbox. VMsafe may have been the first to highlight creative new ways to protect virtual machines, but certainly wont be the last.

It's hard to dissect concrete technical details from the Citrix/McAfee announcement, but I'm always intrigued by any new APIs. In Simon Crosby's blog post he says they are developing, "A hypervisor-native detection service that enables a quantum leap forward in secure virtualization, expressed via an open API to third party detection". I'm excited to see what they come up with, despite the Scott Bakula reference. Imagine my surprise when I read a quote from my humble blog at the end of his post, unfortunately I'm not insured for coffee-computer spit-takes.

I work for Trend Micro who, I'm happy to say, is leading the way in security for virtualization. I personally worked on our VMsafe-based Virtual appliance that we released in 2009 and I'm really excited about what we will soon have to offer. Without talking about things on the horizon, all I can say is this is going to be an interesting time in the history of virtualization security. (BTW: This horizon is largely what's responsible for my recent lack of post density.)

But this post isn't about responding to the announcement, the Trend Micro Cloud Security Blog (cloudsecurity.trendmicro.com) will have commentary on the Citrix announcement. The announcement reminded me of a perennial challenge with developing security software.

While all of this innovation is deeply satisfying to my inner-architect, our fight is actually on a different battlefield. We are still under siege, faced with an ever smarter enemy, and we can't be distracted by a highly disruptive home-front. Virtualization is disruptive innovation for sure, but it needn't disrupt our ability to outmaneuver our digital foe.

When developing security software we have to balance our priorities between:
- New or improved security features
- New contexts (VMsafe, Platforms, IaaS)
- Expanded ecosystems (vCenter, LDAP, SI/EM, Databases)
- Enhanced management (Configuration, Incident Response, Reporting, Metrics)
- System improvements (Performance, Scalability)

But this is a case where not all are created equal.

It's ultimately about the quality of protection being provided, not just how that protection is employed. There are many ways to solve the problem of scan storms in a VDI environment or filter packets before they enter a guest OS, but what really matters is stopping malicious activity. New contexts may be the shiny penny, but innovative security is the real jewel.

Hypervisor Security APIs according to Shakespeare

There is a feud raging over the role of the Hypervisor in providing security services to Virtual Machines. One family, VMware (The Montagues) believes that external VM introspection opens up a world of new opportunities for security. On the other side, Citrix (The Capulets), believes the Hypervisor should just get out of the way and leave security to the existing in-guest and network paradigm. Before you ask... no, Crosby and Hoff are not the star crossed lovers.

I'm going to wade into this debate, despite my admittedly biased view (I'm working with a team on a VMsafe Virtual Appliance). To do so I'm going to borrow a little help from The Bard.

"Nothing can come of nothing."

As King Lear required penance for inaction, so to does Citrix risk its opportunity to foster innovation through inaction. Security APIs like VMsafe do offer an innovative way to secure and monitor Virtual Machines through introspection of CPU, memory, network and disk. With the exception of network, the other inspection points are not currently available unless you put software in the guest. The moment you do, you are vulnerable to evasions, being crippled by malware, and the challenges of inspection across a diverse set of platforms. If you allow inspection externally (via Security APIs) you immediately have a level platform to inspect all logical processing and disk/network usage, opening up a world of opportunities.

The first wave of products will likely replicate existing security controls (AV, Network/Behavioral IDS/IPS, DLP, Offline patching, etc). Shortly though, we are likely to see a new wave of security controls that currently don't have a handy acronym, which will be enabled only by this new method. There are community XEN projects to introduce introspection, however if they are not embraced by Citrix a large opportunity will be missed.

"I go, and it is done; the bell invites me."

Simon Crosby's main argument against providing APIs in the Hypervisor is that it fattens the Hypervisor and makes it less secure. I see no earthly reason why these APIs cannot be implemented in a compact nature with the most stringent security. An API is by nature thin, since it's the responsibility of the consumer to instrument it. Why not, like Macbeth just get it over with and do it securely.

"Though this be madness, yet there is method in't."

While there are non-API methods for network introspection available or coming (see Hoff's posts about vShield Zones and Citrix Network Changes) VMsafe-NET provides a low impact way of tapping the network traffic as close to the virtual NIC as possible. There is no need to alter virtual networking or re-route traffic through appliances (virtual or otherwise).

The simplicity for users justifies the complexity for vendors who must retool to utilize the APIs.

"To be, or not to be, that is the question"; when it comes to Hypervisor Security APIs the benefits to existence outweigh the consequences.