Client Virtualization and NAC: The Fratto Strikes Back…
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
Outside of the impact virtualization will or will not have on the NAC/IPS space, your view that either of the two solutions don't fit the bill for host-side security, segmentation, or access control misses half the problem definition that NAC attempts to mitigate. If the solutions available today where labeled HAC (Host Access Control) you might have an arguement. Network Access Control's most prevalent gain is noted on controlling access to a trusted environment not by just the assets you do manage, but most importantly for the ones you do not.
To exacerbate your position even more – until network attached printers, faxes, phones, and cameras start to get virtualized – you'll notice that the node types on a network go far beyond a a workstation client and raise the exposure footprint far beyond anything aggregrated atop a hypervisor.
That being said – no security solution is absolute, most especially NAC. But considering a network's expanse and points of entry – adequate or good security at the point of access is arguably better than no security.
NAC will not become a primary control pattern for virtualized hosts, rather – virtualization vendors need to include the basis of NAC tenets into their products as they mature:
– Define authorized components within the environment
– Apply a pre-defined access or authorization model
– Validate the integrity of authorized components
It doesn't truly matter what security space/vendor does the activity (NAC or VM providers) as long as the roles of each are clear and you can apply what works well in your environment dependent on your needs.
@J:
See that's where I see the definition trailing off with NAC. It used to be that NAC was supposed to empower an organization to control and endpoint's access to the network, regardless of asset-type (client, printer, etc.)
However, the realistic messaging of NAC has become more about controlling the "inadvertent corporate polluter" (i.e. managed CLIENT machines) and that these solutions will ultimately not be able to stop a determined intruder (who might pose as a printer, phone, etc.)
Now, vendors will argue that TECHNICALLY they can enforce these policies with flexible quarantine and intelligent threat assessment technologies, but in talking to many customers, it never pans out that way.
The technology is certainly improving and NAC will become a useful and reasonable feature in the stack over time. However, there's so much churn in this space, it's really difficult to sometimes figure out what pain point/business problem is being solved.
I think that's because the customers looking for solutions from the "NAC" market are really bifurcated between deciding whether they want network ADMISSION control or network ACCESS control…or both.
I think we agree that the concept of the FUNCTIONALITY that NAC/NAC (both) provides is needed across all platforms, including servers IMHO for the reasons I alluded to in the post. It's not necessarily what "NAC" does today…
So, I probably could have titled the post less abrasively, but virtualized client and server environments will complicate an already complicated environment even more.
The roles are so far from being clear; this is why I sense a coming Storm (pun intended.)
/Hoff
I also agree with you that classic IPS pattern recognition architectures (signature, anomaly, deep packet inspection, etc) will not be able to deliver adequate protection in fluid, virtualized infrastructures. In the short term firewalls may do OK, but classic IPS will face shrinking habitats as enterprises standardize on racks/stacks/blade fabrics and contemplate custom hardware… and where to put it. Maybe some of them are already planning the 100G virtual IPS and hiring out management to a low labor cost country?
G
NAC in the virtual environment provides a few more important and valuable features.
1. The NAC feature can provide access control to servers and
applications. Network users, auditors, customers, partners, and
guest should have different access requirements to network
resources. Enterprise extended perimeter is open for different
groups of users to access critical application to increase
enterprise’s productivity and efficiency. That means partners have
more access to critical application inside the datacenter. Using
what we call Server Base NAC we can limit the access to
application based on the user credential without the need to have
a client on every workstation. We can also limit access to
critical resources based on user group’s credentials.
2. Another important feature is the Access Control for servers that
access the virtual network. For example if a server was a backup
image and hasn’t been running for 3 months and the user boot the
server up to a production network. The server should be
quarantined until the server is properly patched and 3 months of
security patches was applied to the server. The NAC will detect
that a new server was added to the virtual environment and
automatically quarantine the server until the patching is done and
the server will be moved back to the production environment. With
the server sprawl and server mobility of today’s virtual
environment, users need an automated NAC system that will verify
server’s access to the virtual environment.
Hezi:
That's exactly what I was getting at when I referred to how most NAC vendors are NOT paying attention to the applicability of their products in a virtualized environment.
Many of these companies spend a lot of energy lecturing people on what NAC *is*, trying to establish the business case, but only after changing the messaging along the way themselves.
NAC 2.0 (yech) or whatever you want to call it can solve some pretty interesting problems beyond merely keeping out inadvertent polluters. It just takes a change in perspective.
It's my belief that NAC can and should be extended to manage VM instances and their admission/access to the network. I can imagine pre and post-auth checks as well as behavioral access control down to (at least) the application level.
It's a shame that these companies don't see the opportunity for what this is, a way to differentiate from the competition. It also doesn't have to stomp on their existing server management toolsets…
Thanks for your comments, Hezi.
/Hoff
(In case you don't know, Hezi is the CTO/founder of Reflex Security)