VMware Adds Distributed IPS/IDS to NSX

VMware has declared a minor victory (Ceasefire? Stalemate?) on the North-South interface and has decided to fight on the East-West front for a while.

Partly this is because most of VMware lives on the East-West front, so it makes sense to defend its own territory rather than risk its resources defending foreign lands. Let the people of Firewallistan provide for their own defense! Here in the People’s Democratic Republic of VMware, it is internal borders that we must concern ourselves with.

But I digress.

VMware has started adding security features to its networking efforts, following what feels like a well worn path by network vendors. First they move packets around, then they start stopping packets from going to certain places because some of them are evil. VMware has already added firewall capabilities into its NSX distributed networking approach, so now it’s started doing the next logical step: trying to detect if packets are evil or not so they can open the gate to some of the places that it blocked off with firewalls, and optionally close the gates automatically if evil packets are detected.

VMware has started adding intrusion detection/prevention to NSX so you can do IPS/DPS on east-west traffic in the same distributed fashion as you can with VMware’s NSX firewalling capabilities.

The functionality that’s available today seems to be quite well-featured, and it supports two of my favourite approaches: groups and tags.

Groups provide a way to collect like objects together, and help you to apply common rules to groups of similar things. Tags can be used in a similar way, but they’re more useful for decorating objects with arbitrary attributes that follow an information scheme that makes sense to you. They tend to be less formal than groups, and provide for better interoperation between systems that don’t share the same kind of grouping approach. The two approaches tend to be complementary, when supported by a reasonable information architecture and appropriate tooling.

And this is where there’s a bit of an operational gap in what VMware provides today. The tooling for interrogating and troubleshooting the NSX IDS/IPS rules is a bit lacking. Once you move from toy-examples in the lab to the much more complex and nuanced rulesets needed for running production networks, you need to figure out why things aren’t working quite the way you intended. Mistakes happen, and the subtle differences between what you believe should happen and what actually happens when the stupid computers to exactly what you tell them instead of what you mean.

This level of debugging and what if interrogation isn’t there yet, and the fear of getting things wrong (because we lack confidence the computer will do what we mean instead of what we say) tends to lead to leaving the automated actions off so we stay in detect mode instead of prevent mode. That’s really only doing half the job.

Happily, adding this tooling isn’t a big departure from where VMware is going. It’s just the natural next step. I’m pretty confident that as more admins start getting their hands on NSX IDS/IPS and doing real things with it, they’ll start noticing the debugging and prediction challenges and will pressure VMware to add the required operational tools.

Then we humans can get back to arguing about whether or not computers will ever be able to automatically determine if arbitrary packets are evil or not when we have so much trouble with it ourselves.