Have I got a NAC for you

So McLean (you can call me Alan and I will go back to Michelle :-) ), jumps on the NAC debate with Richard and Amrit this week.  While she agrees with Amrit and Rich, I didn't really think I was arguing the other side too hard on this one.  However, my problem is what she describes as the perfect solution is the ConSentry box.  Hey, she is entitled to be as biased as the rest of us, so more power to her, but lets look at what Michelle is really saying.

First of all Michelle talks again about what little value she sees in pre-connect NAC testing.  Hey if it was not a strong point of my NAC product, I would say the same thing.  My suspicion though is that deep down Michelle knows how important pre-connect testing really is.  It isn't the end of NAC, but it is the beginning.  A teacher once told me that if you can start off strong, you have a much better chance of finishing strong.  So taking that to NAC, if you don't have the goods to start with, it is hard to finish strong.  Fact is, it is still table stakes to play at this game and there are many deals we win just because of our strength in this.

What Michelle calls role based access control, I call identity based access control.  That is based upon who you are, your device and you are allowed only on certain parts of the LAN.  ConSentry is hardly alone in offering this capability.  HP ProCurve's Identity Driven Management has done it for a long time.  However, the fact is ConSentry does it through a non-scalable choke point.  Some of the other solutions available do it much more elegantly.  What ConSentry and their bump-in-the-wire brethren in the NAC space do, is use a firewall to set rules on access.  They suck down the information from a LDAP or AD and set the access rules on the on board firewall on the box.  The problem with this is the amount of rules you can place on the firewall on the box is limited and you are stuck being in line as a bump in the wire.  As you move up the network, the amount of users overwhelms a single box, so you are stuck deploying appliances all over your edge.  Unless of course you are going to replace your switches with the "secure switch".  This entails trading security for switch functionality and is just not a great option.  By moving out of band, NAC solutions can use the AD and Radius servers and those "old dogs" VLANS and ACL's in a much more scalable and less hardware intensive manner then the bump-in-the wire boxes.

Much else of the bump-in-the-wire appeal is by integrating IDS/IPS, usually Snort.  Hey you probably already have IDS/IPS in place, why do you need another one (not to mention who knows about licensing this in the future).  Some of the out-of-band NAC solutions, Safe Access included can now take alerts and information from a variety of sources including IDS/IPS sensors, etc. and give you the same functionality.  Again, much more scalable and less HW intensive. So while I agree that post-connect monitoring is a valuable piece of the NAC equation, why limit yourself to being stuck in line with your NAC, when your IDS/IPS is already in line.  How many points of failure do you want to put in place on the network?

Powered by ScribeFire.