As part of our on-going coverage on network access control, InformationWeek's NAC Immersion Center was recently updated with new content from recent Las Vegas Interop keynotes and presentations.

802.1X is a relatively simple protocol once you understand how it works. It's all the moving parts like EAP, EAP Types, RADIUS, and RADIUS attributes, that get complicated. Sorting out how it all works and the shortcomings of 802.1X is well worth your time if you want to implement network access control.

802.1X sounds simple enough. Enable the switch ports, set up Radius and supplicants, and you're ready to go. But the reality is that common network scenarios are made vastly more difficult where 802.1x is deployed.

The Trusted Computing Group's Trusted Network Connect announced Metadata Access Point, IF-MAP, a specification to aggregate and propagate events from multiple sources. IF-MAP is the best thing since sliced bread.

Windows XP Service Pack 3 is coming on April 29, which means NAP will be coming to an OS near you. Already, Hewlett-Packard has announced it will integrate network access protection with its ProCurve identity driven management product, which provides identity-based management to network access. We can expect more vendors to follow suit.

Starting at 11 a.m. on April 22, InformationWeek's virtual trade show will open its doors. We have fielded a list of presenters that cover various topics surrounding NAC.

One of the themes coming from RSA and from vendors in the last few months is the notion that virtual servers, whether running on a hypervisor or not, are somehow more at risk that physical servers. I don't buy it entirely because servers and applications that are virtualized tend to be in tightly controlled data centers. If your data center is secure, so are your servers. Why treat virtualized servers special?

A little-mentioned press release passed through my mail last week. NetClarity was assigned a patent titled Proactive network security system to protect against hackers, patent No. 7,346,922. I read through the patent, and I have to say it aptly describes a NAC product and function that has been available before the filing of July 26, 2004. I wouldn't be surprised if NetClarity starts beating the pavement trying to drum up license fees.

NAC pioneer Lockdown Networks bit the dust, as pioneers often do. It shut its doors unceremoniously at 1 p.m. yesterday and put up a notice on its Web site that it would contact customers. My sources at Lockdown report all the internal servers are shut down so customers can't get software updates, patch definitions, etc.

Lockdown Networks has closed its doors and is looking for someone to buy it's IP. Is this just the beginning of the NAC market consolidation, or an isolated event?

Gord Boyce, president of ForeScout Technologies, has an interesting article about using network access control to change behavior up on Enterprise Networks & Servers, asking Are Your Users Smarter Than A Fifth Grader? I find the idea intriguing because using NAC to lock down a network is onerous.

This week, Steve Hanna sent the TCG/TNC specifications to the NEA working group for consideration as working group documents. These are basically submissions of existing TCG/TNC specifications along with an explanation of how the specifications meet requirements already agreed to by the NEA working group. Apparently, these are the only specifications submitted to the working group.

Steve Hultquist at InfoWorld recently posted a review of ConSentry Network's LANShield Switch. The review is largely positive, as was my review of ConSentry's LANShield Controller, its in-band NAC product which sports many similar features. I think ConSentry, along with Nevis Networks, which has a competing product line, are on to something.

Automation in Windows can be difficult to achieve. You can write batch files. Use Windows Scripting Host. Use WMI. But all of these methods have their drawbacks. While trying to figure out how to disable a NIC from the command line for my NAC test bed, I found AutoIT, freeware scripting utility.

So Shimel has beaten me to the punch on Tim Greene's article on Juniper's NAC product. There's nothing in Juniper's announcement concerning NAC and NAC enforcement. Tim brought up two other points, one about Cisco's TrustSec and the other about ConSentry and Nevis, that I wanted to comment on.

If I have ever tossed out the idea that 802.1X is simple, usable, and simple, then I misspoke. Setting up 802.1X for testing is pretty straightforward, but where the road to 802.1X gets bumpy is trying to integrate port-based authentication with other LAN processes.

Juniper's switch announcement is raising a lot of eyebrows. Many in the industry point to this announcement as the play Juniper needed to make to get into the enterprise. The switches -- at first blush -- look like any other switch supporting the common layer two and three protocols.

Alan Shimel's latest blog post takes vendors to task that have added NAC functionality to their existing product line and specifically goes after LANDesk's NAC, which, he states, is an afterthought. Shimel has often said that host assessment is critical to NAC. Is he changing his tune?

Chris Hoff points out a limitation with NAC appliances and virtualization in "How the Hypervisor is Death By a Thousand Cuts to the Network IPS/NAC Appliance Vendor." But the example he describes is somewhat silly when compared with how virtualization and NAC are deployed.

Vernier Networks video review segments. The videos illustrate the points we make in print and provide you visual context for the review.

ConSentry Networks video review segments. The videos illustrate the points we make in print and provide you visual context for the review. For more details, check out ConSentry Network's Rolling Review.

Adding to our ever-expanding coverage on network access control products, I am starting to post video reviews of the products we have in the lab that should complement our print and online reviews.

Sophos issued a press release announcing that Microsoft's recent update contained fixes for a critical vulnerability in the TCP/IP stack. Sophos then went on to recommend NAC to "reduce the risk of unauthorized, guest, noncompliant, or infected systems compromising the network, ensuring that only correctly secured computers gain network access."

Network access control can address some compliance and reporting requirements, but truthfully, there is only so much that it can audit effectively.

The Trusted Computing Group, a consortium of vendors that are driving standardized APIs and specifications for secure computing, is perhaps opening up a bit with its recently announced blog. The TCG has been a very opaque organization for those folks who aren't willing to pony up the $1,000-per-year minimum membership dues, and I think the opacity has hurt its efforts to educate the ultimate consumer of its technology, the enterprise. Hopefully, the new blog signals a change within the TCG to be more open.

There are many reasons to not consider open source NAC, the first of which is how much workload do you want to put into your NAC solution, above and beyond having to figure out what you want your NAC to do for you, laying out policies, ensuring that your network architecture will support NAC, deploying the product, managing endpoints, and a bunch of other little things that in totality add to your workload.

Alcatel-Lucent (ALU), probably better known outside the United States and in the telephony space, has partnered with InfoExpress to provide NAC to ALU's customers. The shrink-wrap deal will roll-out InfoExpress to ALU's top-tier channel.

TrustSec, Cisco's network-based access control feature set due in 2008, seems to be analogous to functions like identity-based and role-based access controls that, as Dominic Wilde from Nevis Networks aptly points out, other vendors have had for years. What is new is the use of 802.1AE as the mechanism. More on that later, though.

If I can speculate on the future, functions such as NAC, QoS, configuration, etc., are poised to be pushed deeper into the network as an automated service rather than a feature or product that needs to be baby-sat.

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.”

Alan Shimel, Chief Strategy Officer for StillSecure, makes the argument that "with out the pre-connect posture or health check, you don't have NAC." I’ll go out on a limb and say host assessment plays a small part.

Mimicking activity in the physical world, Cisco Guest Server lets employees sponsor guests onto your network rather than lumping all guests into one account or another. This is the first step toward placing access control decisions with the business user, where it ultimately belongs.

Reading over the Aberdeen Groups October report “Who’s got the NAC? Best practices in protecting network access”, I was struck by figure 4, Percentage of End-Users with ANC at the End-Point where 70% of best in class organizations, 80% of average organizations, and 69% of laggards planned to have NAC at the endpoint. What are they thinking?

As I work my way through testing in-line NAC devices from vendors like Consentry, Juniper, and Nevis, I learn not only about how the products work, but also about deployment options and stumbling blocks. Some of those lessons come purely through product testing; some lessons from talking to system engineers who are out deploying their products; and some lessons are a combination of both.

NAC deployments often require more integration than seen at first blush. Especially when the NAC products don't meet with expectations. Take user login/log-offs that were a problem I mentioned in my review of ConSentry's product. There are ways to mitigate problems or bolster your NAC deployments using features you already have.

I gave a presentation at the MIS Training Institute IT Security World 2007 conference in San Francisco, and I when finally got done (I went a bit long) and a few people were left, I asked if there were any final questions. One of the attendees asked, "Is NAC ready for deployment?" A simple enough question, and I hemmed and hawed trying to sort through all the special-use cases, exceptions, and whatever accounts for accumulated conventional wisdom.

In a previous installment of Alan Shimel's NAC-tacular podcast series, Michelle McLean of Consentry observed that the press is often covering technology one and a half to two years before enterprises are ready to deploy. So Shimel decided to get three press folks together, myself, Matt Hines from InfoWorld, and Joel Snyder, who in addition to consulting, writes for Network World and Information Security magazine, to discuss the NAC landscape, where products are, the features that are available and those that are missing which in a more relaxed venue than stuffy old print. Of course you could hold on to this for two years and be up to speed. :) You can get the podcast on iTunes (search for StillSecure) or grab the mp3 here.

The idea that a MAC address, the globally unique hardware address of a NIC, could be used in authentication is ridiculous. MAC addresses, both easily discovered and altered, don't provide any valid proof of identity other than it's intended use case—as a way for layer two devices to exchange frames between each other. Yet, we hear "MAC authentication" used to refer to white-listing hosts by MAC address. That bugs me.

I forget who told me that conventional wisdom is often neither, but I would do well to remember it. I have been heads down testing NAC products for the last few weeks and in between having vendor system engineers (the people how travel to site for installation and troubleshooting) in the lab helping with set-up, I have been picking their brains on what they see in deployments. When you land on a NAC vendor, be sure to add to your list of questions, if they don’t ask you, what switch models and software versions have you tested your product with.

There is so much hype in the IT media and vendor product pitches about policy compliance it makes my head swim. Survey results published by Network Instruments shows many organizations don’t think they have the data or the means to meet compliance regulations.

As I start to test product for the upcoming NAC reviews, in-line NAC being the first of many, one thing strikes me as truly annoying—the lack of decent logging and reporting within network devices. Without good logging, there is no way to troubleshoot problems and that hampers my productivity and more importantly, support desks productivity.

What happens when you get Michelle McLean from ConSentry Networks, Mike Rothman from Security Incite, Alan Shimel from StillSecure, Dominic Wilde from Nevis Networks together? The answer is a rather engaging give and take about network access control between four very outspoken people.

In a recent blog, I said that "NAC fails to reach into the application layer and frankly, it shouldn't" and I want to clarify that statement because in response to that blog both Michelle McLean from Consentry and Dominic Wilde from Nevis Networks are describing application level (as in the OSI model) control, not application access control. The difference is application level controls states that a user "may access this web server or that network service" while application access control states that a user "can modify this form/field in this application." The former is well suited for NAC controls, the latter is not.

Alan Shimel, in his July 30th blog Is quantine black and white or is there access control in NAC?, takes Kurt Roemer from Citrix to task for Roemer’s portrayal of NAC as black and white access control. I agree with Shimel that access control doesn't have to be black and white, but I do have to agree with Roemer that NAC is about network access control and shouldn’t be confused with application access control.

Andy Dornan and Andrew Braunberg of Current Analysis joins Alan Shimel and Mitchell Ashley from StillSecure, on a podcast discussing NAC. Much of the discussion is based on a user survey Network Computing and Current Analysis recently completed. There is a good discussion about the role of standards and where Cisco, Microsoft, the TCG are heading. Both Dornan and Braunberg discuss other results of the survey.

Listen to this Podcast Now

I received this email the other day:
"I went through your article regarding NAC, and would like to ask you one question more to the part of the topic, which was not mentioned. When we internally discussed the possibility of implementing VLANs, we found out that we cannot find suitable solution for 802.1X authentication."

Whenever a new technology hits the streets, the question of whether it can keep up with network traffic quickly follows and with good reason. If a product becomes a network bottle neck or fails to process everything it should be processing, the product has failed. That fear of failure, or perception of being slow, often drives vendors to make optimistic performance claims about their products and drives reviewers like myself put vendors products to the test.

Yesterday, I spent about four hours yesterday configuring a Cisco Aironet 1240AG access point, a Cisco 3750 switch, and an HP Procurve switch to authenticate hosts using 802.1X against a Windows 2003 Enterprise Server AD deployment. During the deployment I was reading the docs for the switches (yeah, yeah, shocking), and noted that the 802.1X configurations could be set with default actions like putting the port into a default VLAN, if an 802.1X authentication failed or there was no supplicant on the host (there are some other features I will dive into at a later date). So I have to wonder, if you can run 802.1X and you simply want to keep outsiders on a guest VLAN with limited resources, do you really need a NAC system?

Welcome to the NAC Immersion Center. The goal of this site is to cover the pertinent information about NAC technology, products, and practices. We will conduct product reviews, writing tutorials about the technology that drives NAC, and discuss trends to help you plan for the future. Think of this as your one stop shop for NAC information.

In setting up the test bed for a series of NAC reviews, I ran into some interesting issues some of which I want to lay out here and some I will explore more in depth later (at some point, I have to get some testing done). So in preparation for upcoming tests, I created my test bed.