Opinion: NAC may be more effective in theory than in real-world practice.
Network access control schemes seem to be all the rage, with IT heavyweights and smaller players alike pushing them full force.
While theres no disputing that these NAC initiatives are aimed at worthwhile goals, what remains to be seen is whether and to what extent these initiatives are worth the time and money that enterprises must lay out to implement them.
In other words, is NAC all its cracked up to be? I have my doubts, specifically concerning the portion of NAC involving network endpoint assessmentthe proposition that by quizzing a client about its operating system, patch level and anti-virus signature currency, its possible to determine whether that client may be trusted.
My initial concern, as a user of desktop Linux and a proponent of keeping ones client platform options open, is that NAC could erect new barriers to running non-Windows operating systems. I see the technology landscape teeming with all sorts of new clients, and if using networked services is to require not only the capability to talk across the network but also to satisfy some necessarily narrow-minded health monitor, many of those potential networked clients could be kept out.
Of course, its the right and, certainly, the responsibility of administrators of a well-managed enterprise infrastructure to exert control over the users and clients that access their networked services. However, it seems to me that for a companys well-managed clients, NACs security posture checking is redundanta managed system wont be running unvetted software, and administrators of these machines will already have the authority to enforce vulnerability and anti-virus updates.
For systems that an IT organization does not manage tightly, such
as the personal systems of telecommuters or the laptops of partners employees, NAC cant be enough to offer acceptable health guarantees. Who knows what malware might lurk on your employees home machines, regardless of what the client reports about its own health?
Whats more, the managed clients of your partners wont necessarily be managed under the same policies youve chosen to mandate. For instance, what happens when your idea of system health equals a completely patched system, and one of your partners has held back a particular patch due to some incompatibility it introduces with one of their key applications?
The answer, in the cases both of the partner-policy conflict and the non-supported client scenarios, is that youd create exceptions. With the constant stream of OS patches and anti-virus signature updatesand the unforeseen conflicts among themNAC seems to me like an ongoing policy-writing nightmare. At the very least, it sounds like more work than already overworked IT departments are probably prepared to assume.
NAC vendors concede that the technology has a long way to go. Click here to read more.
Rather than pursue assurances of health that you cant completely trust from endpoints that you cant completely controlat the expense of implementing, deploying and managing NAC policies, software and hardware for an as-yet-unproven returncompanies would do better to focus on hardening their clients and servers to better withstand the malware that will inevitably worm its way into their networks.
On the server side, companies would do well to focus on the security functionality thats beginning to flow from niche trusted operating systems into mainstream platforms such as Linux and Solaris. On the client side, companies should tighten their management grip over the systems they own. Where thats not possible, companies should explore methods of carving out reasonably secure beachheads within otherwise unmanaged clients, such as through virtual machines or terminal services.
Yes, itd be nice if there were a way to sniff at a client and arrive, automagically, at a state of confidence in which that client could be trusted. Not even the most ardent supporter of NAC would suggest that the technology is currently capable of such a feat. Until such assurances can be reliably obtained, lets worry less about implementing trustability and prepare ourselves instead for suspicion.
Advanced Technologies Analyst Jason Brooks can be reached at firstname.lastname@example.org.Check out eWEEK.coms Security Center for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEKs Security Watch blog.
As Editor in Chief of eWEEK Labs, Jason Brooks manages the Labs team and is responsible for eWEEK's print edition. Brooks joined eWEEK in 1999, and has covered wireless networking, office productivity suites, mobile devices, Windows, virtualization, and desktops and notebooks. Jason's coverage is currently focused on Linux and Unix operating systems, open-source software and licensing, cloud computing and Software as a Service. Follow Jason on Twitter at jasonbrooks, or reach him by email at email@example.com.