A brief history of NAC

With a nod towards one of my heroes, Stephen Hawking, I give you my own brief history, except of NAC instead of time.  In order to decide if NAC has been successful to date or not, you need to know what it is and where it has come.

As you probably know NAC today generally means network access control.  However, when Cisco first introduced the term in late 2003/early 2004, it was network admission control.  Gartner was one of the first groups to start using NAC as a generic term referring to what today is pre-connect network access control. Prior to this there were several companies selling products that performed this pre-connect NAC type of function. Our own Safe Access was officially released in April of 2004. It had been in beta and alpha for many months before that, probably since the summer of 2003.  We called it an "endpoint policy compliance and enforcement" tool.  I know, it just rolls right off the tongue. Microsoft announced their NAP initiative for Longhorn in later 2004/early 2005. Certainly by mid 2005 there were many companies flying the NAC banner.  By RSA 2006 NAC was taking the security world by storm.  Some analysts were saying it was going to grow from a 100 million dollar market to multi-billions in just a few years. Why, is a good question to ask.

The biggest driver for NAC was the realization that after spending billions on the perimeter, we still were not any more secure.  The threat came more often than not from the inside.  Our own customer research was very clear.  People wanted to know who was accessing the network and was their machine up to snuff.  This is still even today core to NAC.  There are few if any NAC solutions that do not perform some type of pre-connect test.  With Cisco and then Microsoft beating the drums, it is no wonder that network access control received lots of attention.  However, the fact that it struck a chord with people should not be overlooked. It was an idea whose time has come.

A funny thing happened on the way to the market though.  Several vendors with products that did not fit into one bucket or another decided that in fact they were NAC all along, but no one knew what it was. I remember Toney Jennings, then CEO of Mirage Networks, telling me that Mirage was always a NAC, it was just that there was no NAC at the time they came to market. So instead they labeled themselves an internal threat/NABD.  Other companies such as Lockdown Networks said that "continuous vulnerability management" is part of NAC. Forescout added some pre-connect test to their IPS and abracadabra, NAC. Yet other companies from the wireless and SSL VPN markets said who you are and where you can go on the network is part of NAC. Other companies also "embraced and extended" the NAC name.  As a result, today NAC can mean a lot of different things to different people.  The common thread though is that each and every one of them still perform some type of pre-connect test.  Some like Michelle McLean over at ConSentry may say that the pre-connect test is not a "high value" feature of NAC. Maybe, maybe not, but it is the one common theme running through all of these disparate solutions.  My personal opinion is that Cisco and others have conditioned us to think of a pre-connect test as just being for anti-virus up to date and MS hotfixes. If that is all it is, I don't blame Michelle for saying what she says.  However, I think a pre-connect test should be much more than that though and is still why pre-connect tests and capability are an important piece of the NAC puzzle.

There are other variations in the NAC market that have evolved over time as well.  Layer 2 versus Layer 3 testing and enforcement are choices to ponder.  Is your NAC solution a bump in the wire and in line to all traffic passing through? Do you have an out-of-band solution that utilizes the network infrastructure or maybe an appliance that claims not to require any network changes?  Do you require to wire up your entire network with potentially insecure SNMP scripts to each switch or can you use the 802.1x infrastructure?  Still others as I have written about use what some call a hack, called ARP twiddling or ARP poisoning to enforce policy. Using DHCP to enforce NAC is far from perfect, but can be the right solution for some folks. Another religious argument is over agent versus client versus true agentless and clientless.

All of these variations and more have evolved in just over 2 short years in the NAC market.  Is it any wonder that people are confused.  It is also testament to how vibrant and full of potential this market is.  There is a major problem out there and lots of very smart people are proposing different methods to solve it.  Next we will discuss what the shakeout of all this evolution is. But make no mistake the NAC market is far from disappointing or a bust.  Customers need to know what they want and get through vendor BS, but the reasons for NAC are many and to important to wait.