Follow up items to NAC / 802.1x post

I realized I left out some important clarifications on my post about NAC and 802.x, so here they are in no particular order. I've includes some other random thoughts too, just to keep life interesting.

1. I did not do a Cisco NAC Appliance + 802.1x (Cisco NAC Framework) deployment configuration - which would likely address some of the items in the fourth point. I would still argue that for trusted hosts that are able to run virtual machines you can still have issues with the overall security deployment and you need that HR/Security policy and procedures.

2. I did not address VMware's View (VDI) or ACE platforms or Microsoft's Remote Desktop or Citrix's XenApp or XenDesktop since they are all inherently remote access methods. I have not had a chance to look into View's authentication method supports but I imagine for the thin client machines simple MAC based security would suffice along with ACL's if a large thin client deployment is done.

For ACE I would recommend building out the internal network with 802.1x with a default guestnet configuration and let machines boot and get Internet access and then launch the ACE desktop to connect via VPN, just like if they are out on the public Internet. I would use this same method for people running View on a desktop or laptop since they have an underlying OS. With both of these solutions I see limited value in attempting to do single sign on or an 802.1x supplicant in the native OS. Basically you are building a public access network where View is the only service available or in the case of ACE where they have to VPN back for resources just like if they were on the public Internet.

3. I did not address the function of most of the agents used in NAC solutions and what benefit you might get from them. For instance, Cisco's Trust Agent (CTA) can allow the end host to pass posture information to Cisco ACS and can work with Cisco Security Agent (CSA) to build a more comprehensive solution. Basically, CTA was the first NAC client agent (2004?) and allows for end hosts to work with with a AAA server to do both authentication but also posture validation.

CSA is different, it works independently on the end host and watches the behavior of the native OS and basically denies any activity that looks outside the normal behavior of that machine. It doesn't care what an application or service is trying to do, if it isn't something that has been previously defined as ok it blocks it. It can run as a centrally managed or standalone configuration. So, if you glue the two together you can get health posture/remediation + validation of machine and end user + very secure end host with reduced exploitable footprint.

4. Some IT professionals argue it is easier and cheaper to run a VMware View setup (or a Pano Logic configuration) and just blow away potential desktops that don't meet company standards or appear to have issues (security or otherwise). They argue it is cheaper and more cost effective to simply deploy a new desktop than to determine what is wrong. They often also say you do not need to incur the cost of deploying either NAC or 802.1x solutions since everything is resident back on a VMware ESX host. I think the cost argument for not wasting time trying to determine what has gone wrong on a desktop OS makes sense. I would still argue that you want some sort of endpoint security to keep foreign systems from accessing your View configuration or ESX host. Also, you will still need to audit your systems for security issues and while patching the OS might have gotten easier and even automated the exposure from guest hosts isn't any different.

5. I think it is sort of obvious right now but I didn't mention it specifically, there is no unified framework or management method for deploying this as a solution right now. What does this mean for IT Professionals who are running and maintaining this? It is possible to break NAC or 802.1x by doing a simple upgrade of your AAA service or radius solution if there is a bug. It is possible to lock everyone out of the network by mis-applying the wrong policy configuration (always have a backup reserved port with no 802.1x or NAC authentication on it!) and you have to manage this on all the network devices connected to your network.

6. To the best of my knowledge there is no way to automate deployment of new switches on the network and have them self provision with 802.1x. You can avoid trusting a new switch connection by using Cisco TrustSec but I have not seen a lot of activity in that area myself.

7. I think there might be something to the argument that deploying an all wireless (no public access switchports) might be more secure in some cases. You can't address the DOS problems with wireless spectrum so that is a negative but it is only a single unified solution for wireless. Everything else is back in the datacenter on a trusted well known port.

8. I think there is also something to be said for shops that deploy everything in a data center and require everyone to VPN in to access content. Then they simply build out public access networks at their office locations and don't worry about port security. As bandwidth has gotten cheaper and cheaper this solution seems viable. With Cisco's AnyConnect client being able to auto reconnect it makes this a more tolerable solution to end users since they don't have to reconnect via VPN if they disconnect by losing network connectivity.

9. I believe Microsoft's DirectAccess solution is a great way to extend a corporate network with trusted client machines and still get the same sort of policy management. The solution allows IT professionals to run basic 802.1x. For machines that don't run a supplicant it still provide them basic corporate services in a dynamic VPN configuration no different then if they were on the public Internet by having them fall back to guestnet access. In addition, they can run the Microsoft's NAP solution with DirectAccess and have all the posture and remediation work happen regardless of location. The best part is that 802.1x can be run and maintained by the network team and NAP by the server team and neither solution gets in the way of the other for the most part.

Ok, that is it for now, I am sure I'll think of something else and I know I've forgotten a point or two so I will post again when they resurface in my head.
- Ed