Illuminations

More NAC confusion and FUD in the press....

Tim Greene's recent article "NAC may find its niche as a supplement" announces that in-line devices will not be the main choice for enterprises moving forward because of:

1) the number of boxes that you need to proliferate throughout the network for an in-line solution

2) the adoption of 802.1X in network switches since NAC first came along

3) the introduction of Microsoft NAP

Let me address these points with some degree of fact, rather than opinion and speculation.

1) We are an inline vendor of Identity Driven LAN Security solutions that include NAC as an element of the feature set. We have successfully deployed our solution in large global deployments that include fortune 500 companies and span >40,000 active users.  We have done this very cost effectively with fewer appliances than specified by OOB vendors in the same competitive bids.  Contrary to popular belief you can in fact put a Nevis in-line appliance in above disti or in the core, or better still use your existing switch refresh $$ to buy Nevis secure switches in the wiring closet which means you've done away with the additional cost of OOB software, hardware, licenses, etc. 

So the first point to make here is that OOB does not mean you can add one box to the network for all users.  In most cases network topologies will dictate that you need many OOB appliances and then the limitations on user count per appliance further impacts the equation.  The reality is that OOB is often more expensive and cumbersome to deploy.

The other point to consider is that enterprises are very often looking for more than just the pre-connect Network Admission Control that most OOB solutions provide, particualrly when they want to scale the solution to include employees as well as business partners, contractors and guests.  To get this functionality from an OOB solution I have to have a bunch of other supported elements (switches, IDS/IPS, Firewalls, etc) that I then have to hang together with complex interoperability, deployment, maintenance and policy issues.  I've said it before and I'll say it again.  The hidden, dirty little secret of the OOB approach is that reliance on VLANs and port based ACLs in switches for post connect access control enforcement means that what used to be a simple network topology change now has a new NAC policy dimension to complicate things.  Things are probably ok if you stick to the Guest/Employee VLAN model, but start to get more granular than that, and start wanting to add a little more granularity on the ACLs that are enforced, and all of a sudden you've got a full grown oak tree to prune where you thought you had a bonzai tree.  Group based L2-L7 policies, enforced independently of the network switched and routed infrastructure remove this dependency and complexity. 

2) For the rebuttal on the tired old 802.1X assertion please start by reading the great article that our own Gary Kinghorn just had published in Enterprise Networks and Servers.  Gary did a lot of research within the analyst community and with customers when writing this article and found that while the technology is there in the switches as Tim points out, implementing it has so many costs and pitfalls associated with it that very few people are implementing it in the short to medium term.  If it is a requirement for a NAC solution then I would argue that the vast majority of Enterprises, particularly in the mid tier, won't be rolling out that NAC solution any time soon.  I'd also refer you to a Nevis white paper for further discussion on how 802.1X compares, contrasts with, and can also be a part of, a Nevis Identity Driven LAN Security solution.  802.1X will have it's day, but the fact that the OpenSEA Alliance was founded should give you some indication of the problems that still have to be overcome.

3) We have advocated interoperability with Microsoft's NAP from the very early days and have shown our strong commitment by actually putting in the effort to do development work while others just talk to it.  Our feeling has always been that NAP will become the dominant Network Admission Control technology, which is why we provide a solution today that can interoperate with it.  We can also add tremendous value to the NAP framework rather than providing the significant overlap that OOB solutions give.  What do you do about non-windows or legacy endpoints for instance?  How will you ease the transition to a full corporate roll out of NAP while getting the protection you need in the short term?  How will you secure against network born threats?  How will you cloak network resources from sophisticated attackers in the network?  How will you ensure that your network is intelligent enough to recognise, authorize, prioritize and control the applications that use it?

Anyway, I have pontificated enough.  The simple message here is that there is another side to the story that Tim Greene published and it's not "the Dark Side" that's been portrayed.  Besides everyone knows that marketing is the Dark Side and that Darth Vader was the VP Marketing for the Empire. Don't they??

//Dom

A Rose By Any Other Name Still Can’t Grow Market Share

With apologies to the Bard of Avon…The news is finally going mainstream regarding Vernier Networks getting out of the NAC market and changing its name to Autonomic Networks. Industry observers are digging deep to read the tea leaves as to what this means to the industry as a whole, with specific speculation about Vernier’s one-time inline NAC rivals, Nevis and ConSentry. Matt Hines at InfoWorld quotes Paul Roberts at the 451 Group as saying, “ConSentry and Nevis Networks -- both direct rivals of Vernier -- could be among the other NAC providers looking to be sold, or under consideration for a buyout from the bigger fish”.

Before we offer some insights on the Vernier situation, it’s important to point out that this move by Vernier really has no bearing on us or what the industry perceives to be similar companies. The fact is that Vernier is a very different situation, with a substantially different product. For example, what Vernier was never able to figure out, or couldn't make work, was the importance of delivering inline access control as a secure switch, as well as an appliance. This critical detail is lost on many of the pundits covering the NAC market in general (because the concept of a secure switch is lost on the out of band appliance vendors), although ConSentry to its credit, as well as Nevis, is educating the market. Vernier was also at a different growth stage, and with a different set of investors, having raised over $100 million dollars with less to show for it than many of the other NAC vendors, not to mention its more direct inline competition. The telling point is that it appears that Vernier needed to ramp down its headcount into the 50 or so range, according to the Matt Hines article, and, well, that just requires a new plan and a new image to survive.

Nevis, which has had a different growth model, and quite frankly a different primary focus, is not in the same situation. We continue to ramp sales, and gather momentum and support from both the market and our investors. Now is not the time to be looking for the exits (it’s only Act II after all), although I don’t think any company would be completely closed-minded to a reasonable consolidation offer, NAC vendor or not. Having said that, it’s hard to deny that some consolidation in the NAC space isn’t warranted. The NAC market is still immature, and hasn’t grown according to early prognostications. But, here again, that may not have a great bearing on Nevis. We don’t consider ourselves a “NAC vendor”, in the way that the industry likes to clump vendors into simple sound-byte buckets. We have always taken a much broader view of the real problem customers are facing, and offer a solution of which NAC is only one of several primary components. We believe companies are better defined by the markets and problems they address than the features of their product anyway.

Back to Autonomic Networks (nee Vernier), it’s interesting that the industry view is that they are getting out of the NAC market and have remade themselves into a “role-based access control” solution based on existing intellectual property, while their “inline NAC technology may… be up for sale”. It has always been our contention that role-based access control, along with NAC (as well as intrusion detection and application use controls) are an integral part of a complete solution customers are looking for. It’s no secret that the inline vendors have always had a major advantage in this area, and that ultimately that’s what the market will demand. As Forrester stated early last year “NAC as we know it will fail”, and pure NAC vendors are seeing some effect of that. We are trying to change the “as we know it” part. We know the market needs more, and we believe customers (and finally the analysts and press) get it as well. It just doesn’t make sense to us that Vernier would throw the baby out with the bathwater, although we wish them luck in whatever they end up sorting out. It seems like I've seen this play before though...

In-line versus Out-of-Band Revisited

Tim Greene over at Network World had another post today in his NAC Alert column on the "NAC placement debate", whether it's better to be in-line or out of band. He took the opportunity to highlight a new Infonetics report that showed the market was about evenly divided and that the debate was roughly a draw. Revenue apparently is about equally split as well, with in-line devices getting only a couple percent more of the revenue pie.

In all fairness, we haven't drilled into the Infonetics report yet, but most of the conclusions Tim points out we would agree with: deployments are increasing in size, 2/3 of the market is still North America, etc. What gets me going is the simplified view of the merits of each. Tim summarizes as follows: "In general, in-line NAC appliances are better for smaller deployments because as the size of the installation grows, so does the number of devices. Out-of-band scales better."

Call me biased, but, folks, this just ain't true. Rather than get all huffy and technical here, I'd just like to point out our recent whitepaper on this very topic for a more in-depth analysis. In reality, when deploying out-of-band, just to provide the authentication functionality, an appliance is required in every switch domain, so the number of appliances required tends to be comparable. The bottom line is there are a lot of myths out there, so be careful. [One out-of-band vendor states that the two terms refer not to analyzing packets in or out of the flow of network traffic, but to whether or not the communication to enforcement points (a downstream switch, e.g.) was in or out of the flow of traffic. (Note that if you are in-line you can BE the enforcement point).]

I just hate to see these misconceptions and myths get propagated any further than they need to. I hope that clears things up.