What a great NAC solution needs, Part 2

Yesterday I started a series of articles on what makes a great NAC solution.  Of course, I think that our own Safe Access, is the best NAC solution available today, so you can take all of this with a grain of salt, but I am trying to remain objective.  After going through what I think are the must have features, I intend to discuss why certain approaches in my mind are just not the best way to do it. Picking up where we left off:   

3. Enforcement options - A key piece of functionality for any NAC solution is: how does it enforce defined access policies.  Generally, policies can be enforced by quarantining devices which do not meet policy.  Now, a key tenant of our philosophy at StillSecure, is guilty until proven innocent. By this I mean, a device should not have access to the network until it has been tested and either passed or failed its policy test.  If it fails, obviously it should remain in quarantine.  This means that the test has to be done quickly, with minimum impact to the enduser. Our studies clearly show, that if an enduser has to wait more than 20 seconds for a NAC test, they are going to think something is wrong and either start pressing buttons, rebooting or calling the help desk.  This presents a fundamental problem that makes many NAC solutions sub-par.  NAC solutions that cannot complete their complete range of tests in this time are faced with some tough choices.  They can let a device on a network after just a cursory, but less than full policy test, then fully test and if they are dirty, quarantine them (obviously the problem here is they may have already infected the network). Another option is don't test the devices every time they log on, if they are recognized and were tested before (you see this with many of the NAC solutions that specialize in selling to the education market), of course if a device became infected and you did not inspect it, you know what happens.  As we say in the NAC business, it only takes one bad apple. Another option is just to not test for too much beyond patch level and anti-virus. Generally this kind of choice is inherent to the basic design of the NAC solution.  If they are using a vulnerability scanning solution to do their testing, you can almost bet, this is the case.  This is why, I say that a purpose built NAC solution is key.  At StillSecure we could have easily used our VAM vulnerability scanning solution for Safe Access, but we saw that this was the wrong tool at the wrong place and wrong time.

In any event, you can utilize your network infrastructure to quarantine or you can just prevent the device from connecting to anything on the network via an agent or reverse firewall on the device itself.  The latter method, is more of a classic endpoint management feature and in my opinion is not a great NAC method, because by definition you need to have an agent on the machine to do it, therefore unmanaged devices are by definition not covered.  This method is very popular with the personal firewall crowd.  They are all agent based and endpoint solutions.  However, they are not necessarily NAC solutions.

The next big choice in techniques involves in line or out of band enforcement.  I think both in line and out of band have a place in a great NAC product. However, you can't have one and not the other.  A great NAC solution has to be flexible enough to offer both methods depending on your own network and who you are trying to perform NAC on.  Generally, if you can, in line is best for remote users, where you have a small amount of access points and an in line NAC device can sit at that choke point.  In larger more complex networks, putting NAC solutions in line at every branch of the network can become a huge management nightmare, not to mention the cost of all those devices.  This is why some of the solutions that are only in line and are almost "security switches" are doomed.  Unless you are going to throw out your existing switches and replace them with these devices (maybe that is the play, they want to replace your existing switch vendor), you cannot deploy the solution across a complex network.

So to be a great NAC solution you need to able to use the network for enforcement.  There are several means of doing this available today or in the near future.  I do not pretend to tell you which of these methods are best (I have my own personal opinion).  You use what you have available to you.  Lets review some of the most common:

• The frameworks - Cisco NAC, Microsoft NAP, Trusted Computing Group -  Of the three Cisco is probably furthest developed, but all three are really still being rolled out.  All three represent a means of using the network to enforce policy.  The problem with Cisco NAC is that you need a Cisco only network with NAC enabled gear (Safe Access is a Cisco NAC partner and will work in this environment).  For all of the expense to do this, currently you really don't get a lot of bang for the buck, just testing patch level and anti-virus, agent only testing.  In NAC 2 you can use a Qualys scanner for unmanaged devices, but this has all of the problems I outlined above of using the vulnerability scanner as a NAC tool.  MS NAP seems very promising, of course in a Microsoft only network, and then only for Vista and XP.  The jury is still out on NAP. The TCG certainly looks promising, but how widely used and adopted it will be remains to be seen.  Note: Safe Access is both a NAP and TCG partner/member and we are committed to supporting them both.  I think time will tell which of these frameworks will attract enough critical mass to remain relevant.
• DHCP or IP management - probably one of the more popular methods of performing NAC today. In this scenario, the NAC appliance can intercept the request for a DHCP IP address and perform admission tests before a valid IP is given.  Safe Access, will actually give a device a pre-configured quarantined IP address so these tests can be performed.  These quarantine networks can be pre-configured using ACLs (access control lists) or quarantine can be forced  by manipulation of the end points own access tables.  The biggest issue with DHCP enforcement, is what do you do about spoofing static IPs or static IPs in general.  Also, many DHCP solutions have to be in line.  If you have a large, complex network, you may have lots of DHCP servers, and therefore a lot of NAC appliances to manage.  Some NAC vendors who can only manage devices with an installed agent, will rely on a DHCP server to quarantine or deny access to devices that don't have the agent installed.  To me this is a bit of a kludge and not a very elegant solution.  What does the DHCP server then do with the quarantined device?
• 802.1x - My own personal favorite.  In this scenario, the NAC solution works with the 802.1x enabled switch and the Radius server to deliver port level control for NAC.  It should be noted, that many NAC solutions can ride 802.1x, but do not really support and integrate with it.  You should investigate this for your own purposes.  Also, many NAC solutions will use SNMP scripting in lieu of 802.1x.  Depending on what version of SNMP you use, I think that this method introduces a lot of potential security holes into the equation and makes an install very difficult.  This is why many NAC solutions that use SNMP instead of 802.1x to work with switches, will shy away from an evaluation on your network.  It is just to damn hard to set up.  Another plus about 802.1x is it makes it easy to integrate NAC with user and identity access.  This is a very powerful combination and in my mind represents the future of this technology.  The TCG standard is very closely tied to 802.1x and one can say that Cisco NAC version 2 is actually a proprietary version of 802.1x.  The downside of 802.1x is that not all networks are 802.1x capable.  Therefore, if your NAC solution requires 802.1x, you have to make sure you have invested in your network to support it.
• In line - the old stand by and probably best used for remote users, the in line method has the NAC appliance act as a layer 2 bridge.  Usually with an on board firewall, the NAC device acts as a choke point to allow or deny network access.  The downsides are that it is a single point of failure and that it is tough to scale in large networks

What is the best method for you to use?  All of them and none of them.  I have never seen any two networks that are alike and so in any given situation one or more of these methods may be best for that situation.  That is exactly why a great NAC solution must be flexible enough to support all of these technologies! 

4. Depth of testing - this is where we will pick up next time