Ok, Alan Shimel???s thoughtful response to my blog Host assessment does not make a NAC begs a response. Access control is about controlling access first and foremost. Reporting on a host???s condition doesn???t tell you much about the potential threat of a host, it only seems to. You can???t discern intent based on the bits on a drive, which is what Alan argues for when he says that a dirty machine ???is still dirty and it is only a matter of time [until something bad happens]. I would not want it on my network or at least would want to know if it was on the network.???
That???s a reasonable position to take but the underlying assumption is that dirty machines will do bad things, clean machines won???t, and I don???t buy it. To be fair, I don???t think Alan does either, but he can speak for himself. LOL. Thing is, there are so many ways to hide the bits on a disk that a host???s condition, and therefore its intent, is unknowable except for the known bad bits. In other words, if a host agent reports it has the bot-du-jour running, then taking action against the host like quarantining makes perfect sense, but that access decision is predicated on something detecting the bot-du-jour in the first place. Chick -> egg, egg -> chicken. There are so many ways to hide malware that a whole subscription industry has risen up in the form of anti-malware.
There are many good reasons for host assessment: automating remediation when a host accesses the network, checking on hosts that are potentially dirty like mobile computers, ensuring desktop management is working, and reporting for software and hardware inventory. There are good business cases for each. The costs of performing manual updates, infections from mobile computers, botched desktop management, and data gathering for reporting are enormous. Any efficiencies that can be achieved will reduce operational expenses. While I am going through my NAC reviews, nearly all of the products host assessment features can aid in all these things. It's a good thing.
Now, if you look at network access control (NAC) as, um, well, access control, then as a matter of organizational and technical policy, you should limit the resources that a host can access based on what you know, like who the user is, whether the computer is managed or a guest, first. That limits the potential damage that a host can inflict regardless of it???s condition. The access controls can be enforced in a number of ways such as in-line NAC offered by vendors such as Consentry, Nevis, and Vernier. Or the access controls could be handled through 802.1X, RADIUS, VLAN assignment, DHCP management, and others, from vendors like, Cisco, Forescout, InfoExpress StillSecure, Symantec, and others. Or you can enforce access controls in firewalls and other network equipment. My point is first identify the user and/or computer, then grant limited access on a user or role basis.
I am probably arguing for stricter access control than most folks are used to thinking about and I recognize that strict access control is difficult to achieve. My forays into doing something I thought would be simple like limiting access to Active Directory computers for log-ons, which I discussed tangentially, demonstrates just how difficult controlling access to resources with complex networks and applications can be. But that is what network access control is about.