StillSecure, After All These Years

Hybrid NAC, Piecemeal NAC and Complete NAC

Following up an article he wrote earlier about the pros and cons of the different types of NAC, Tim Greene's column this week talks about what he calls Hybrid NAC installs.  Tim is referring to organizations buying NAC for one reason or for one class of devices and users and than wanting to use it for another class.  Often times depending on what the second type of NAC testing is, they than have to buy a second NAC system.  I think this is incredibly silly.  I wrote as much about it last week.

I find a few things to comment on in this column.  First of all I think the situation Tim describes is most true when companies are "sold" a NAC system from their endpoint vendors.  The local Symantec or McAfee reseller tells them there is no need to buy a stand alone NAC system, because they can get NAC with the uber-suite they already own. The old adage of you get what you pay for applies.  They soon find out that the NAC they got bundled with suite is little more than a toy and doesn't give them what they need.  Now they have no choice but to buy another NAC system.  Or you could go put IPS boxes all over the place with the new McAfee NAC system.

More importantly perhaps is that most NAC solutions are really geared towards one kind of NAC deployment.  This leads to Hybrid NAC as Tim calls it or piecemeal NAC, which is what I have always called it.  If you are looking for a NAC system, it should be a complete NAC system that has a solution for wired or wireless devices, remote or local, managed or unmanaged, LAN or WAN, your NAC solution needs to cover the full spectrum.

By the way if you are looking for a system like that check out Safe Access.

Related articles by Zemanta

• Setting the record straight on NAC
• McAfee tries to NAC back to the stone age

Setting the record straight on NAC

Sometimes when you try to explain something you can't help but muddy the waters.  That is exactly what happened to Tim Greene in this article he wrote about endpoint based NAC in Network World. Hey I am not knocking Tim though. I get some of my best material from his column.  Anyway, in this weeks adventure Tim is seeking to compare the pros and cons of endpoint based NAC to other types of NAC technologies.  He has the same old regular guest stars featured, Rob Whitley of Forrester, Ofir Arkin and a couple of special guest star NAC customers.  I am not going to regurgitate Tim's entire article.  Instead lets go to the videotape to the facts.

Here is the background.  There are three types of NAC

1. Network or infrastructure based NAC - Like Cisco and Juniper and StillSecure, it uses the network switches and infrastructure to enforce and detect devices coming on the network
2. Endpoint based NAC - an agent on the endpoint does the heavy lifting and the testing and enforcing.
3. Appliance based NAC - sits on top of the network and usually uses some clever (or flaky) way of enforcing like ARP poisoning, TCP reset and the like.

Also, whether the NAC system is based on testing before or during a device logging on or just waiting until you see something bad is another way of separating the real deal from the pretenders in NAC.

So with that as a background here is what Tim wrote and what I say:

NAC products that enforce policies via Dynamic Host Configuration Protocol (DHCP) proxy servers do nothing to stop machines that obtain static IP addresses and don't use DHCP to make their network connections. That makes significant portions of corporate networks invisible to the NAC access control products, says Ofir Arkin . . .

Come on Tim that is so 2005.  I don't even think Ofir is pushing that crap anymore.  Yes spoofed and static IPs are a challenge, but not fatal.  There are many best practices to overcome this type of issue, not the least of which is an RDAC (remote device activity capture) or scan on connect module such as StillSecure Safe Access NAC has.  Also depending on your switch and DNS/DHCP vendor you can handle this problem that way as well.

Next:

The major downside to endpoint-enforced NAC is largely theoretical so far and one that customers seem willing to overlook. The problem is that rootkits can take over machines to make them lie about their health. This underlying endpoint problem can be mitigated by software that monitors behavior of machines to determine if they are acting badly. And lying endpoints haven't actually proven a problem for many customers.

Tim, the "theoretical" problem of trusting an endpoint to report on itself is more real than that. Ask Richard Stiennon if you have any questions.  In fact this is a reason why some people choose not to go endpoint based NAC.  However, that is not the major downside to endpoint based NAC.  The major downside is there is no guest access solution.  What do you do if the endpoint does not have the agent installed and you can't make them install the agent.  Saying that you than need a second type of NAC is not elegant as Rob Whitley says.  In fact it is downright ugly. When you consider that guest or unmanaged access is the biggest driver in NAC, that pretty much sinks the endpoint based NAC approach.

And finally:

To deal with this problem, McAfee, for instance, is adding enforcement of NAC policies based on behavior via its IPS appliance and next year via a dedicated NAC appliance.

Guys, if the only defense you have is IPS, that is fine, but lets not say that is an effective NAC solution for guests.  You are bound by what the IPS can detect and it takes a lot of IPS boxes usually.  Not a scalable model at all.  Of course you could wait for McAfee to resurrect the Lockdown appliances.  It didn't work before and it probably won't work now.

Now wouldn't it be great if there was one NAC solution that covered all of these bases from one management console? You bet.  If you are looking for one that does that let me know or check out StillSecure Safe Access!

McAfee tries to take NAC back to the stone age

I have been reading about it in bits and pieces for about a week now, but reading Tim Greene's column this morning confirmed it for me. McAfee the company that usually buys whatever innovation it needs, tried to build their own NAC system and in doing so is trying to take us back to the stone age of NAC. I guess we should not be surprised that a dinosaur of a company would have us perform NAC with caveman tools.

Lets be clear, McAfee has offered NAC for a while now. It was called MNAC and was part of the uber-suite.  Everyone agreed it was pretty weak and not much of a NAC product.  It really had no provision for guest or unmanaged devices.  Other than the agent acting as a reverse firewall it depended entirely on either Cisco NAC framework or Microsoft NAP to perform network enforcement.  The need for guest or unmanaged device control and network based enforcement was painfully obvious. 

So taking a page from the GEICO caveman. McAfee is seeking to move NAC back to the stone age. They took their expensive Intruvert derived, "purpose built" IPS and re-purposed it for NAC.  So now McAfee has a network based NAC product.  Sure, you just have to buy a few or a dozen expensive "purpose built" IPS boxes that now have I guess, a "purpose built" NAC on there as well and place them all over your network. Now they can block unmanaged devices and provide network based NAC enforcement even if you are not one of the two people who use the Cisco NAC framework or you don't yet have Microsoft NAP.

This is a page out of Juniper UAC v1 back in 2005 or so.  It didn't scale then and it doesn't scale now.  At best this is a finger in the dike strategy until McAfee realizes that they have to do it the McAfee way. They just can't build innovation and they have to go out and buy a NAC company.  In the meantime, I don't expect anyone but the most diehard McAfee customers will find much merit in this retro approach to NAC!

Aha! Now I see said the blind man

I couldn't help but laugh reading Tim Greene's NAC newsletter today. Tim is taking about a NAC customer who uses NAC without the enforcement or "self-remediation" turned on and has done so for over a year.  Tim reports that the customer is still finding tremendous value in his NAC product by being able to understand who is logging on the network, what port they are plugged into and what their endpoints look like. 

Though the customer referenced in Tim's article is not a StillSecure customer, it really doesn't matter.  What Tim is describing is exactly what we have been preaching on NAC for 2 years now.  NAC is not all about the quarantine!  Too many people focus in on NACs ability to shut people off the network, but that is not end game people.  Here at StillSecure we have one large network that tests over 200k devices a day and quarantines almost no one!

Most people accessing the network have a legitimate right to be on the network.  Our job is to make sure they do so in compliance with our security policies so they do no harm and are not harmed.  We actually wrote a great white paper on this very subject called "A phased approach to NAC" that describes how to roll out NAC in phases and the value that can be derived from each phase.  You don't have to get all the way to the enforcement or quarantine phase.  Many customers are content with the value they derive without quarantine to more than justify the investment in a NAC system. 

I think part of the maturation of the NAC market is the realization of this value. I hope that Tim's newsletter will help spread the word that NAC is not just about the quarantine!

One caveat though is that some customers are just not happy unless they can eventually quarantine devices.  For those customers your NAC solution has to have the ability to do this irrespective of your network architecture.

Related articles by Zemanta

• Infonetics proclaim NAC alive and kicking
• Vulnerability scanning NAC - Thats why it is the wrong tool at the wrong time

Vulnerability scanning NAC - Thats why it is the wrong tool at the wrong time

This weeks Tim Greene NAC newsletter (Tim actually writes the most consistent NAC column there is, thanks Tim!) deals with an age old problem with NAC.  That is the case of the wrong tool at the wrong time.  Tim highlights a recent release of a new version by one of the smaller NAC vendors. The vendor is seeking to make lemonade out of lemons.  Because they use traditional vulnerability testing in place of true NAC policy tests, the testing takes a long time to complete, by their own admission.  Therefore they are advocating letting people on the network and scanning them in the background.  If they fail they can then be dealt with.  Of course this still leaves you open to a user coming on the network and doing something bad before they are discovered.  In the case of this vendor, they say to only do it with "trusted" devices.  That would work if you could say for sure who and what a trusted device is. In today's world there are no trusted devices, same as there are no trusted networks.

The problem with vulnerability scanning is it is hard to do quickly before someone logs onto a network. That is the fundamental problem here and the same with other agent-less tests from other NAC vendors (think used car sales guys).  In certain verticals, such as the edu space they are comfortable with testing a device once a semester or so and not testing again for a few weeks or months. That is a question of what your risk tolerance is though.  Also don't be fooled by millisecond response times.  The clock doesn't start until the vulnerability or malicious behavior is actually detected.  By than it could be too late.

Purpose built NAC products that don't just re-use vulnerability scanners provide superior solutions to this problem and should be what you look for.

NAC management server running in a virtual machine - BFD!

Things must be slow for Tim Greene.  Either that or Greg Stock, CEO of MIrage snookered him pretty good.  Tim's article today talks about the virtues of Mirage's management console running in a virtual machine and the company is "contemplating" moving its policy software also to run in a virtual environment.

Come on guys, are you kidding me.  Being able to get your product to run in a virtual server is newsworthy?  We have been installing Safe Access like that for a long time already.  I guess when all you sell are appliances, the idea of just selling software is radical?

Tim next time you can't find something to write about NAC give me a call, we can talk.

Humans - the weakest chain in the link?

The old adage that you are only as strong as your weakest link is a fundamental truth in security.  According to Tim Greene, the weakest link in the chain of protection that NAC can provide is too often the human being behind the computer. Tim relays in his most recent NAC newsletter the experience of a college IT administrator who when they turned NAC on flooded his help desk with calls from students who could not remediate their own computers.  This is a real problem.  Tim points out that this is a good reason why you should not turn on enforcement right away.  This gives you a chance to profile the devices on your networks and work on getting them to look like what you want before you enforce.  This is right in line with a "phased approach to NAC", a white paper we have done at StillSecure. 

It also points out another issue I have written about before.  Too many NAC vendors have "self-remediation" as their solution for getting computers up to speed.  Fact is for non-IT personnel, self0remediation is just not a viable option.  Your NAC product needs to have other options around patching and remediating devices.

Also, I just don't understand colleges that are content to test a device once a semester.  Tim's article mentions this too.  Once you have gone through the trouble of setting NAC up, it doesn't cost you anything more to test these devices every time they come on the network. Defeats the whole purpose if you ask me.

Is there an 802.1x in your future?

Tim Greene's NAC column today goes back to the recent Gartner IT Security Conference. At Lawrence Oran's session on NAC, using the handheld voting machines he asked the audience if and when they planned on deploying an 892.1x capable network.  Of course answers are always dependant on how the question is framed.  But in this session about 50% of respondents said they were going to go .1x by 2011.  You know what they say, once you go .1x you don't go back.  That bodes well for NAC deployments.  802.1x remains the most secure and powerful way of implementing NAC.  However, .1x is also useful for other security and network functionality.  If you want to read more about .1x my friend JJ has a ton of good .1x stuff up on her blog.

A couple of interesting points though.  Gartner themselves as Tim points out estimates that .1x adoption will be closer to 70% by 2011.  The difference between the 50% in the survey and Gartner's estimates will be realized due to increasing ease of implementation of .1x networks. Perhaps, I know at StillSecure we are always looking for ways to make it easier to implement .1x and NAC.  However, lets be clear. Installing new supplicants because Cisco and Juniper say the Microsoft supplicant is not good enough is a red herring. Yes the Odyssey client is cool, but it is a nice to have in the .1x equation, not a must have.  The same goes for the Cisco/Meetinghouse supplicant. Also, not all .1x is created equal.  There are still enough differences between switch vendors in how and what they support in .1x to make it maddening.

Finally, like I have said before if you are going to do 802.1x just for NAC, don't bother.  But if you are going to go to 802.1x you should give NAC a good look.

Symantec takes a fling it on the wall approach to NAC

I was reading Tim Greene's column this morning about Symantec's new on demand web log in for guests as part of their SNAC appliance offering. I have to admit that even I who follows the NAC market and competition pretty closely, get pretty confused with all of the different offerings Symantec has come out with around NAC. Symantec seems to be following a fling stuff on the wall and see what sticks strategy when it comes to NAC.  The problem is separating the keepers from the rest of it when evaluating their offering.

This latest offering appears to sure up a hole that was called out in the recent CRN review of their product in a bake off against Sophos and StillSecure's Safe Access. In that review Symantec's drop off in functionality between agent and agentless was called out.  So within just a few days comes this announcement addressing the issue.  Very timely indeed.  This comes on the heels of Symantec's peer-to-peer approach to NAC, which came on the heels of their Endpoint Security product version 11 which had NAC included (and which I understand has already been patched/upgraded several times since its release). 

At this point you have Symantec NAC with their endpoint suite which is a throw in but has no guest access option on its own. Than you have the Symantec NAC appliance which can do enforcement of managed devices beyond what just endpoint suite gives you.  Now you also have on demand/dissolvable agents available with the Symantec NAC server (but I guess not with the endpoint suite). You also have the Symantec peer-to-peer stuff, which I think also requires the SNAC server.  Starting to get confusing? I guess this is what happens when your NAC offering is made up of an amalgamation of several different products lumped together.

Not to worry though, I am sure Big Yellow will still sell plenty of all flavors of their NAC offering. At the end of the day some of this stuff is bound to stick.

Companies getting the knack of NAC

For too long we have heard the NAC knockers bad mouthing the benefits of NAC and bemoaning its lack of adoption. I have always believed that much of this was marketing spin and that companies were finding NAC highly useful.  Typical hype cycle kind of stuff. At the end of the day though nothing speaks like real world references by customers stepping up and publicly saying they use the product.  Of course, those of us in the security industry know that this is probably one of the hardest things to do. No one wants to stand up and say what they use for security.  This could give information to the bad guys and attract attention that many companies would rather not do.  At StillSecure this has always been a double edged sword for us. With many DoD networks using the product, we have not really been able to talk a lot about the great job our NAC product does on some of the most sensitive, mission critical networks in the world.  By the same token, usually we don’t announce or publicize many of the infrastructure providers who we partner with and who sell a re-branded version of our NAC product.

Recently several NAC customers have been stepping up and talking about how they use NAC and why. Last week there was a good article on Estee Lauder using NAC first for guest access control and most recently an expansion of their NAC deployment to help with PCI compliance.  This week in an article with the usual left-handed compliments, Tim Greene in between quotes by the so called analyst experts, talks about several NAC companies rolling out NAC.  One is American Bancard, another StillSecure customer who uses NAC to help with PCI and keep their network secure. The article talks about several other companies using NAC solutions from other vendors as well, which is also very encouraging.  Of course the companies I have spoken about I know for a fact are using NAC.  With some of the competition, you cannot always be sure as I have written about in the past.

In any event, I think it is important that we are starting to see some real public references for NAC deployments.  Nothing proves the point of a products value than real live customers stepping up and talking about it!