En Garde!

NAC - What's in a Name?

As I read the raging debate this week between Amrit (Williams at BigFix) and Alan (Shimel at StillSecure) about the value of NAC, it struck me how much we can get caught up on semantics. It also seemed that the old adage "the truth is somewhere in the middle" most certainly applies.

If you define NAC as primarily about seeing whether an endpoint is "safe" and deciding to allow someone onto the LAN, concluding that NAC doesn't provide nearly enough value for the work involved makes total sense. When I read the knocks on NAC (would those be "NAC knocks"?) by Rothman, Stiennon, and Williams, the issues seem rooted in that view - geez, overhaul all your gear or deploy a bunch of new hardware, and all you have is "this is joe, and his machine appears to be clean"? Yeah - I wouldn't do it either.

When NAC is done right, it's about much more than admission and endpoint posture. So rather than spelling it out as Network Admission Control, if NAC instead means Network ACCESS Control it's much more compelling. (Of course, now we're back arguing semantics.) The key is, after you know it's Joe, you've got to control what Joe can do.

Amrit rightly points out that knowing what Joe can do on the LAN is really, really hard. And it's not IT that decides this info - it's the line of business. And getting that info from them - and getting the right info - is also really hard. One of our customers just went through this lengthy and difficult business process step to do just this. They sent excel files to all managers, listing the company's 6000 employees, and asked the managers to check off which resources each user should get to access. Painful for sure. And they didn't even get it right. Not only did they have to send the excel file multiple times to managers to get a complete response, but the data didn't come back right.

How did they know? This customer took all the excel info, turned it into policies on our system, and then turned on logging to monitor the users for a while. And guess what - there were a lot of access violations. So IT had to go back to the managers with the violation logs and ask whether the resources in question were ones that the users should be allowed to reach. Whoops - indeed, the managers had forgotten several resources the users had legitimate grounds to access. It puts visibility in a whole new light. Instead of a "nice to have" extra, it was fundamental to the process - this company couldn't have successfully rolled out identity-based control without it.

So does NAC have value? Absolutely, provided you define it right. The key is to broaden what NAC means, and implementing it right is hard, definitely requires the business people, and is about WAY more than just making sure the endpoint's clean. For this customer, NAC was all about restricting access to sensitive resources, and it also got them compliant with PCI (Payment Card Industry - specs for how to handle credit card data) along the way.

As I've commented before, it really doesn't matter what we as vendors say NAC is - all that matters is how the enterprise defines its LAN security requirements. At the end of the day, enterprises must define their needs, map those needs to the solutions that can meet them, and then look at how easily those solutions can integrate into their existing infrastructure.

I think with this debate, semantics got in the way and kept these guys - both clearly smart - from seeing the elements of truth to both sides of the issue.

Michelle McLean

mmclean-at-consentry-dot-com

Multi-Threading: The Future of Networking and Security

Cavium Networks just filed their S-1, looking to raise a healthy $86M in their upcoming IPO. These guys were the first silicon company whose sole reason to exist was high-performance security processing in the network, and they built their success on the NITROX processors used for high-speed SSL processing and related functions. Their more recently introduced OCTEON processor family is optimized to deliver deep packet processing in the network at wire speed. You can bet the folks over at RMI, another commodity multicore vendor, will be watching intently.

It’s easy to get lost in the myriad of silicon technologies and what they give you, so here’s a quick primer. Forgive the generalities – we’re going for the basics here. ASICs are the fastest and cheapest chips, provided you produce them in large numbers. But ASICs are fixed – you need to know exactly what the chip should do, and when you want it to do something more, it’ll take another nine months to get it. Networking companies like Foundry and Extreme innovated here, and then Broadcom and Marvell got the religion and made switch ASICs available to masses. NetScreen also innovated with ASICs in their firewalls, but left room for some flexibility by adding FPGAs.

Think of FPGAs (Field Programmable Gate Arrays) as programmable ASICS – they can adapt, but they are expensive and extremely difficult to program. Some companies tried to build product lines around them – but they proved too expensive and not nimble enough to keep up with their commoditized Intel/AMD-based appliance brethren.

Then you have the humble CPU, which has been the life-blood of the network appliance industry because companies can spin out features at the speed-of-coding. Plus, if you want to have anything to do with application processing, such as security or acceleration, then you’re on a CPU. If you’ve got really smart coding, you *might* be able to get 1 Gbps of throughput.  But the world is moving on and 1 Gbps, especially in the LAN, isn’t enough anymore. Luckily, AMD and Intel have discovered that the path to speed isn’t frequency but multiple cores.

Which brings us to multi-core CPUs, which enable multi-threaded processing. The key to delivering wire-speed packet processing is a highly multi-threaded architecture. One look at the rated speed of most security appliances, though, tells you it’s difficult, if not impossible, to do deep packet processing and get multi-gigabit speeds off a standard CPU with one to four cores. The fastest appliances top out at 2 Gbps.

And herein lies the special sauce for ConSentry – we developed our own CPU with 128 multi-threaded cores, and it does deep packet inspection at 10 Gbps and powers our entire product family. In contrast, Intel CEO Paul Otellini just talked about their next-generation 80-core chip they hope to introduce in about 5 years *yawn*. And while Intel struggles to get 20% or 30% performance gains in each successive generation, highly multithreaded processors can get 4x the speed in a single generation.

But hardware is actually only part of the battle. Many networking companies have tried to move from commodity to highly multi-threaded CPUs, and they’ve discovered the real challenge is in the coding. Blindly slapping the code from your single CPU-based appliance onto a multicore CPU is a little like strapping a JATO on your Impala. First, you better check your OS version – if you’re on VxWorks, forget it, and if you’re on BSD or Linux, you’ll probably want to upgrade. In general, porting existing code usually delivers nowhere near the expected performance benefit, mostly because of memory access and locking. When one software process locks access to memory on a two-core system, it’s holding up just one core, and developers can usually optimize the design to minimize the system-level performance impact. But when you extend the problem to 128 threads, that same memory lock holds up as many as 127 threads. That’s why developing code optimized for multi-threaded processors from the ground up is so critical. So if your friendly appliance vendor transitions from a single CPU to one of these multicore systems, don’t believe the software version number if it’s anything higher than 1.0.

So how did ConSentry build this 128-core CPU when even four- or eight-core CPUs remain fairly rare? We’re very fortunate to have Mario Nemirovsky, a pioneer in multi-threaded, high-performance architectures, as our Chief Scientist leading the CPU development team. And because our chip was always destined to do LAN security, we’ve been able to avoid the complexity and delays inherent in writing code to run on more generalized network processors like those from Cavium. In a nutshell, coding for multi-threading is a very hard problem, and most companies underestimate the effort, but getting it right creates strong barriers to entry.

I expect we’ll see that played out in the market in the quarters ahead – it’s going to be a great but occasionally bumpy ride along the way!

Dan Leary

dleary-at-consenty-dot-com

Steps to Deploying NAC

Tim Greene's latest NAC newsletter about not rushing to deploy NAC draws from recommendations by panelists at RSA. I liked a lot of the ideas, but I found a few concepts missing. I posted a comment there, and I thought I'd include it here as well to broaden the dialogue around how best to do network access control and LAN security. Would love to hear any feedback.

Many of the steps in here are spot on. I was surprised, though, that the panelists skipped what should be the very first step: identify what you need NAC to do for you. Perhaps they consider this step should go without saying, but you can't start by looking at which NAC solutions fit in your network without first knowing which NAC solutions solve your actual problem. There's a lot of complaining about how many vendor definitions of NAC there are, but that really doesn't matter - a given enterprise's definition of NAC is all that matters. If you are concerned with just who can get onto the LAN, that will direct you toward one set of solutions. If you need to control where people can go once they're on the LAN, that points toward a different set of solutions. Another potential list of deployment steps?

1) Define your needs.
2) Determine which solutions meet those needs.
3) Compare how those solutions fit in your network design - are they self-contained, will they work in heterogeneous LANs, do they need endpoint/switch/VLAN/ACL changes?
4) Compare how those solutions impact user interaction with the LAN - will they change the user login?
5) Look at how the solution lets you define and test policies - you're going to solicit input from lines of business, and they're going to miss something, and you need a pain-free way to test those policies first.
6) Pilot the top two solutions to see where marketing leaves off and product reality begins, and don't let the vendor drive the whole time - take over and see that you can do it on your own.
7) Look at additional features the piloted systems can provide - does it answer just your current issues, or can it do more as you get further along with deploying LAN security.

--Michelle McLean
mmclean-at-consentry-dot-com

Thoughts on RSA

Even more than last year, I was struck by how much the RSA show floor looks like Interop's. I'm still new to the world of RSA, but I've been going to Interop since 1991 - back in the days of Moscone, engineers, and incredible lego designs from FTP Software showing IP stack interoperability (I'll skip the tempting analogies to explore between today's purveyors of agents and FTP Software - "sure, a stack will get built into the OS, but our stack's better, so people will keep paying for it separately"). From what I hear, RSA is getting softer and softer in the same way Interop has, and I'm left feeling bad for IT folks actually trying to find solutions to their real and serious problems as they wander the dizzying maze of booths. I think it can be done, but it takes a lot of focus and work to read the buzzwords and ask the potentially relevant vendors to explain, yet again, what it is they do.

From the vendor perspective, trade shows are a mixed bag - you do it somewhat for the customers, and somewhat for the industry. We had lots of vendors coming by to see our product in action, but we also had some great conversations with users. I think Rothman's point about the value of a show depending on expectations is right on. Since I think of trade shows as more about branding than leads, I was actually pleasantly surprised by the dialogues I had with end users. The bank with some apps so dated they don't support any kind of access control, the defense bogeyman who had to stay incredibly vague about what his apps did, the company with a PCI problem and only three months to get compliant.

One thing stands out - yeah, there's still confusion about what NAC is, but people are a lot smarter about it this year. The conversations this week, as well as our sales calls and the RFIs we're seeing, show people have thought about their problems, understand their needs, and now are sorting through how to go about solving them. That's a much better state of confusion than last year's!

With an 18-month old at home and very little time to see him, I scooted out of the City as early as I could most nights, but I did stay out on Wednesday to go the security bloggers event. Like others have mentioned in their postings, it was really cool to put a face to the text. I'm still a blogging newbie, but it was fun talking to folks about how blogging is helping to advance people's understandings of security issues. As a former journalist and analyst, I really appreciate having a forum to lay out some thoughts and engage in a dialogue, and given the tight focus of so many of us, compared to often fairly broad beats that journalists and analysts have to cover, we have the luxury to delve into issues much more deeply.

So thanks for organizing, Rich (we'll miss your writings), and I look forward to tipping a glass with the whole group again soon.

--Michelle McLean
mmclean-at-consentry-dot-com