I have spoken with a few companies lately that have made a nice security solution out of integrating NAC and VDI products.
Security officers have always liked most of the traditional NAC story – automatically assess the health of the endpoint, control access to applications at the port level, and have end-users bring their own devices into compliance. That has led to a resurgence of interest in NAC products from the likes of Cisco, ForeScout, Juniper and Microsoft.
However, the NAC problem has always been the concept of quarantining devices that fail health checks, are unmanaged because of device type (such as iPads or mobile devices), or are unmanaged because they are owned by business partners (and maybe do not run 802.1x). In many of these cases the devices cannot automatically be brought into a safe compliant state, but the user still needs to conduct business on the network. There are not many security officers that want to tell business executives that they have blocked access to the network – a better approach is to offer an alternative delivery of the application.
A solution for some is to host guest desktops in the datacenter and to use VDI from the likes of Citrix, Microsoft, Quest or VMware to allow the user to do their jobs. With VDI, the organization has far less concerns of valuable data residing on an infected endpoint since the data never leaves the datacenter in a persistent form, access to critical applications is still controlled by strong authentication, and security can recommend a safe, compliant means of using the network.
If you are running NAC for automated remediation and quarantining of non-compliant or unregistered endpoint, look into granting access to applications with VDI.
Subscribe to:
Post Comments (Atom)
Posts
I agree with your concept: it's a clever idea. I think it's a great way to allow commercial entities to use guilty-until-proven-innocent NAC while ensuring that productivity is minimally impacted when endpoints are quarantined.
ReplyDeleteOne thing to point out, however, is that VDI will not be a clone of your normal desktop in most cases. Likely your normal desktop will have some local apps or files not stored in VDI, and being forced into VDI by NAC will mean you will temporarily lose access to that data and capabilities.
The more cloud-leveraged environments will see far less impact, of course. I would expect some impact on productivity in any case, but still a far better option than losing network access entirely.
Good point - it is not perfect, but least the user can get work done.
ReplyDeleteI like Eric's commentary as it relates to NAC being a complementary control and a control enabler. NAC has real-time visibility to BYOD devices, that are unmanaged, and corporate managed devices, where host-based controls are often inactive, out-of-date, corrupt or non-existent. In both cases, the corporation is blind to the actual security and management posture of the device. NAC can not only assess and remediate the endpoint, but can initiate enrollment to application or a process based on applying policy against captured attributes. The assumption of better security with VDI systems and that there would be no affect on user experience for remediation is not the case with enterprises we have worked with. A policy violation triggering an action would be similar for VDI and non-VDI endpoints - and such actions are still pre and post network admission. There is also the presumption that all NAC enforcement needs to be disruptive - this too is not the case and NAC enforcement / quarantine options and flexibility varies by vendor. I agree with JBrown comments (yes we are both from NAC vendors). There is plenty of commentary on VDI security (read recent blog commentary by Andrew Wood and Mike More). "With VDI or any remote terminal you don't know what is wrapped around the remote access and what it can do and that needs also needs to be considered in the arguments on security." So if you have a rooted BYOD device and then initiate a VDI session... are you ok? Net Net... we are back to a layered model... control application by use case and consequence.
ReplyDelete