Attention NAC vendors who continue to barrage me via email/blog
postings claiming I don't understand NAC: You're missing the point of
this post which basically confirms my point; you're not paying
attention and are being myopic.I included NAC with IPS in (the original) post here to illustrate two things:
(1) Current NAC solutions aren't particularly relevant when you have centralized and virtualized client infrastructure and
(2) If you understand the issues with offline VM's in the server world
and what it means to compliance and admission control on spin-up or
when VMotioned, you could add a lot of value by adapting your products
(if you're software based) to do offline VM conformance/remediation and
help prevent VM sprawl and inadvertent non-compliant VM spin-up...
But you go ahead and continue with your strategy...you're doing swell so far convincing the market of your relevance.
Now back to our regular programming...
-- ORIGINAL POST --
I sense a disturbance in the force...
Mike Fratto's blog over at the NWC NAC Immersion Center doesn't provide a method of commenting, so I thought I'd respond to his post here regarding my latest rant on how virtualization will ultimately and profoundly impact the IPS and NAC appliance markets titled "How the hypervisor is death by a thousand cuts to the network IPS/NAC appliance vendors."
I think Mike took a bit of a left turn when analyzing my comments because he missed my point. Assuming I'm wrong, I'll respond the best I can.
A couple of things really stood out in Mike's comments and I'm going to address them in reverse order. I think most of Mike's comments strike an odd chord to me because my post was about what is going to happen to the IPS/NAC markets given virtualization's impact and not necessarily what these products look like today.
Even though the focus of my post was not client virtualization, let's take this one first:
Maybe I am missing something, but client virtualization just doesn???t
seem to be in the cards today. Even if I am wrong, and I very well
could be, I don???t think mixing client VM???s with server VM in the same
hypervisor would be a good idea if for no other reason than the fact
that a client VM could take down the hypervisor or suck up resources.
I don't say this to be disrespectful, but it doesn't
appear like Mike understands how virtualization technology works. I
can't understand what he means when he speaks of "...mixing client VM's
with server VM in the same hypervisor." VM's sit atop of the
hypervisor, not *in* it. Perhaps he's suggesting that despite isolation and the entire operating premise of virtualization that it's a bad idea to have a virtualized client instance colocated in the same physical host as a VM next to a VM running a server instance? Why?
Further, beyond theoretical hand wringing,
I'd very much like to see a demo today of how a "...client VM could take down the
hypervisor."
I won't argue that client virtualization is still not as popular
as server virtualization today, but according to folks like Gartner, it's on
the uptake, especially when it goes toward dealing with endpoint
management and the consumerization of IT. With entire product lines from folks like Citrix (Desktop Server, Presentation Server products, XenDesktop) and VMware (VDI) it's sort of a hard bite to swallow.
This is exactly the topic of
my post here (Thin Clients: Does this laptop make my assets look fat?), underscored with a quick example by Thomas Bittman from Gartner:
Virtualization on the PC has even more potential than server
virtualization to improve the management of IT infrastructure,
according to Mr Bittman.???Virtualization on the client is perhaps two years behind, but it is
going to be much bigger. On the PC, it is about isolation and creating
a managed environment that the user can???t touch. This will help change
the paradigm of desktop computer management in organizations. It will
make the trend towards employee-owned notebooks more manageable,
flexible and secure.???
Today, I totally get that NAC is about edge deployment (access layer,) keeping the inadvertent client polluter from bringing something nasty onto the network, making sure endpoints are compliant to network policy, and in some cases, controlling access to network resources:
NAC is, by definition, targeting hosts at the edge. The idea is to
keep control access of untrusted or untrustworthy hosts to the network
based on some number of conditions like authentication, host
configuration, software, patch level, activity, etc. NAC is client
facing regardless of whether you???re controlling access at the client
edge or the data center edge.
I understand that today's version of NAC isn't about servers,
but the distinction between clients and servers blurs heavily due to
virtualization and NAC -- much like IPS -- is going to have to change
to address this. In fact, some might argue it already has. Further, some of the functionality being discussed when using the TPM is very much NAC-like. Remember, given the dynamic nature of VMs (and technology like VMotion) the reality is that a VM could turn up anywhere on a network. In fact, I can run (I do today, actually) a Windows "server" in a VM on my laptop:
You could deploy NAC to access by servers to the network, but I
don???t think that is a particularly useful or effective strategy mainly
because I would hope that your servers are better maintained and better
managed than desktops. Certainly, you aren???t going to have arbitrary
users accessing the server desktop and installing software, launching
applications, etc. The main threat to server is if they come under the
control of an attacker so you really need to make sure your apps and
app servers are hardened.
Within a virtualized environment (client and server) you won't need a bunch of physical appliances or "NAC switches," as this functionality will be provided by a virtual appliance within a host or as a function of the trusted security subsystem embedded within the virtualization provider's platform.
I think it's a natural by-product of the productization of what we see as NAC platforms today, anyhow. Most of the NAC solutions today used to be IPS products yesterday. That's why I grouped them together in this example.
This next paragraph almost makes my point entirely:
Client virtualization is better served with products like Citrix
MetaFrame or Microsoft???s Terminal Services where the desktop
configuration is dictated and controlled by IT and thus doesn???t t
suffer from the same problems that physical desktop do. Namely, in a
centrally managed remote client situation, the administrator can more
easily and effectively control the actions of a user and their
interactions on the remote desktop. Drivers that are being pushed by
NAC vendors and analysts, as well as responses to our own reader polls,
relating the host condition like patch level, running applications,
configuration, etc are more easily managed and should lead to a more
controlled environment.
Exactly! Despite perhaps his choice of products, if the client environment is centralized and virtualized, why would I need NAC (as it exists today) in this environment!? I wouldn't. That was the point of the post!
Perhaps I did a crappy job of explaining my point, or maybe if I hadn't included NAC alongside IPS, Mike wouldn't have made that left turn, but I maintain that IPS and NAC both face major changes in having to deal with the impact virtualization will bring.
/Hoff
I put in my candidate Apache mod_rewrite patterns into the UI and feed it good and bad urls. I made sure that good urls matched in a reasonable amount of steps, but more importantly I tested how many steps a “bad” url took. Fake input like /en-US/some/wacky/page/should/fail/fast?foo=bar&baz=buz should stop within a dozen or less steps. Don’t just test for successful matches and call it a day. How does a small amount of non-matching input do? How about a large amount of non-matching input? If the engine takes thousands of steps before calling it quits, you know you’re gonna have issues – a slow web server… or worse.
