En Garde!

NAC Fight - Five Rounds and Counting

A blog fight! A blog fight!

No surprise Alan Shimel’s involved, and this time he’s taken on Dominic Wilde at Nevis. It started with Dominic’s post responding to Mike Fratto’s blog on the limits of NAC. I took issue with some of Mike’s blog too and left a comment.

Then Alan took Dominic to task, Dominic responded , Alan replied, Dominic replied, and Alan replied again, promising it’s his last post on the topic.

So what’s to gain from jumping into the fray, with emotions running so high and allegations flying back and forth? I think both guys have gotten a bit lost in the weeds, whining at each other about various details, but the overall nature of the debate sits close to my heart. At the highest level, Dom is arguing that pre-connect or pre-admission checks are insufficient and Alan’s arguing, well, a bunch of stuff but essentially he gets mad whenever anyone says pre-admission isn’t enough.

So let me start by saying pre-admission, of whatever quality, isn’t enough – for a lot of customers. If it were all anybody wanted, we wouldn’t have well over 100 customers. (Now I have to tease my friends at Nevis and say “come on – not a SINGLE customer announcement all year? What’s up with that?”) Of course, pre-admission is enough for some, or Still Secure wouldn’t have any customers. (And actually, Alan, I couldn’t find any customer announcements for this year on the Still Secure site either.)

Clearly I agree with Dom’s overall premise that for many enterprises, pre-admission checks aren’t enough – they need post-admission control. And by post-admission, I don’t mean just running pre-admission checks over and over again, as a lot of people want to define it. I mean something very different – truly controlling what users can do after they’re admitted onto the LAN. This level of access control involves understanding who the user is and limiting the applications and resources that user can access based on role, location, time of day, and other aspects of who the user is.

This debate between Alan and Dom went down a few other paths I’d like to touch on as well. 

Dominic – next time you steal my line, at least give me my props! Probably all nine people reading this blog fight were at the New York event and heard me draw the analogy between doing vs. teaching to talk about being inline.

Both of you – you talk about architecture, debating inline vs. out of band, as if the customers are thinking that way from the start. They're not, and they shouldn't be. They're thinking about what business problems they’re trying to solve. When they lay out their requirements, and match it up against product features, only then will architecture trends start to emerge. It so happens that if they need to actually control what people can do on the LAN, they need an inline device. The customers who need identity-based control get it – they understand that to do that, the device actually has to first see and then be intelligent about doing enforcement on all the traffic going through it. But the discussion doesn’t start with architecture religion – it starts with the enterprise’s needs.

Alan – your questions on the quality of the switch miss the point. Switching’s commoditized, for one, and second, anyone looking at a secure switch cares first and foremost about the security capabilities. Cisco, for all its switch dominance, can’t hold a candle to us on security features in its switches. Certainly we have the enterprise-class features needed to sell or we wouldn't be successfully selling it, but a purchase driven by security does change the decision focus.

For the last two quarters in a row, we’ve sold more switches than appliances, and the way this quarter’s shaping up, it looks like that'll happen again. It’s never about rip and replace – we offer both appliances and switches so enterprises can choose the platform that suits them best. But let me tell you, it’s really nice when an enterprise can take advantage of an existing, and substantial, budget item already earmarked for a switch upgrade and use that money to also get security and identity-based control built right in. It's that kind of pragmatism that shows me this stuff ends up in the infrastructure.

Both of you – way overblown on the IPS thing. Maybe Nevis uses Snort, maybe not – but regardless, it’s not the point. Enterprises will still use separate IDS/IPS devices – no one should act like even best of NAC devices will change that. But I heartily believe that if you’re sitting inline anyway, seeing all the traffic coming from the user edge of the network, and you can build in some smarts to do anomaly detection and help pinpoint network problems, you’re providing good value. And keep in mind anomalies take a lot of forms. For one of our customers, the ConSentry algorithms tripped alerts on an application built in-house. It certainly wasn’t malware, but it showed them where a piece of the code was written badly and was sending people off to the Internet for data they had in house. Not IPS, clearly, but still useful.

Alan – your rant on ASICs seems off too. Of course we at Nevis and ConSentry would be proud of our custom silicon – it’s the secret sauce for doing what we do. Even if merchant silicon is improving, we’re still way ahead of what you can buy, and owning those goods is incredibly valuable. Line rate, 10 Gbps packet inspection, including full L7 so I can show you the filename a user just accessed over Windows or the URL they just clicked on – that’s truly where we get the customer “a-ha!” moments. And you just can’t get there with off-the-shelf silicon. Secret sauce is always worth crooning about, especially when it's actually why you win.

You’re right Alan – your blog is your domain, and you are master of that domain. But I have to admit – I’m pining a bit for the old days when you blogged on stuff beyond picking on your competitors and trumpeting about Still Secure products. And riding your coattails? Come on - he's engaging in a debate that you started.

And just for the record, I’m siding with Dom here, but I can assure you I’m not playing the Olivia Newton-John role. I'm afraid neither my figure nor my voice would cut it.

Michelle McLean
mmclean-at-ConSentry-dot-com

NAC's Role in Protecting VoIP

Tim Greene's column on the relationship between NAC and VoIP and Alan Shimel's blog response both took a fairly narrow view of how NAC can help protect VoIP systems. The perspective in both cases is limited to a more admission-focused definition of NAC.

Tim talks about how endpoint scans could catch an infected system and in turn prevent that system from infecting the VoIP systems. Alan responds saying NAC really can't do much to help VoIP at all and saying so just adds to the over-hyping of NAC.

I disagree with both, because they've overlooked a key way that NAC can extend protection to VoIP systems. If by NAC one means not just admission control but also network access control, and if that access control can include policies that limit which devices can communicate with which other devices, then NAC can help substantially in protecting VoIP systems.

Think about a system that first is able to identify VoIP components - either via MAC address whitelisting or via reverse DNS lookup and using device names. Then think about policies that say VoIP phones can communicate only with the call manager and vice versa. You take just that simple combination and you've already got fairly robust protection right out of the gate. A desktop spewing a worm won't infect a VoIP phone or the call manager, whether or not an endpoint scan catches that worm, because that endpoint is not a device that's authorized to communicate with either the VoIP phones or the call manager. Similarly, a desktop trying to launch a DoS attack on the call manager will fail, because again, that's not a device that's allowed to send traffic to the call manager. Emerging SPIT (spam over IP telephony) attacks would also fail, since direct communications from VoIP phone to VoIP phone would also be against policy and therefore blocked.

Then imagine extending those controls with specific protocol support - so the policy would say that only the SIP, H.323, or Cisco Skinny protocols should ever emanate from a device known to be a VoIP phone. Same with a call manager. Now any data-based attack, from any device, will not be able to take down the call manager or the VoIP phones.

So really, NAC can do much more than just accidentally help protect VoIP systems. It's all in how you define it - and defined as network access control, with strong post-admission capabilities, NAC can get you there.

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

Reflections on Gartner's Security Conference

I’m just back from attending the Gartner Security Summit in DC. I know several industry folks were there, but for those who weren’t, a few reflections on the conference.

John Pescatore kicked off the event with his “Security 3.0” talk. I didn’t react negatively to that title the way Rothman did. Pescatore was just using that scheme to call out a third era of security. He defined Security 1.0 as when everything was under lock down in the mainframe era, 2.0 was when we were perennially trying to catch security up with user activities, and 3.0 is about trying to get ahead of the game.

What I object to with that title is posing this concept as something new - I think most people thinking about security have been trying to "get ahead" vs. "just react" for a while now. That aside, though, I do believe that thinking about what you can do to get security built in vs. layered on later is a really helpful exercise. One, you get more security, period – you get it built into the network, the application, the PC, etc.

And two - and here's the really interesting angle - the more you get security “built in” to stuff, the more you can shift capital costs to hit budgets other than the security budget. I love this idea, in large part because we’re seeing it today here at ConSentry with our secure switch. We have customers who have a switch upgrade already on the books. They use that money to upgrade to secure switches instead of plain ol’ vanilla switches and presto – even with no separate NAC or other security line item, they get a massive new security layer built into the edge of the LAN. Another argument for why it’s got to be built right into the infrastructure.

In another session, Gartner analyst Rich Mogull hosted a panel on vulnerability research and ethical disclosure, with Thomas Ptacek, Chris Wysopal, and David Maynor. All three guys had interesting perspectives and experiences to share. I’m not sure the average conference attendee got too much out of it – what these researchers do is usually a bit removed from the average enterprise, even if it shouldn’t be. But having read those guys’ blogs for a while, it made for fun listening. And it was good to meet Ptacek in person – maybe he’ll find another way to call ConSentry “committed” to security now that we’ve met face to face!

The highlight, though, was the Lawrence Orans session on NAC. Parts of it demonstrated the “when you have a hammer, everything looks like a nail” phenomenon – lots of pre-admission focus, which is no surprise given Cisco’s dominance in general and especially within the Gartner client set. But in the entire hour’s talk, he shared just one customer case study – and it was a ConSentry customer! Very, very cool to see our application, and the customer’s need for role-based control, as his one example of an interesting deployment.

All in all, a good two days, especially meeting other bloggers, talking with several of the analysts one-on-one, seeing other industry folks like Richard Stiennon, and best of all chatting with enterprise users in between sessions.

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

It's All About Controlling Users

Fortunately or unfortunately, I have another job at ConSentry aside from blogging, so I don't get to do it as frequently as I'd like. But the discussion that started, for the umpteenth time, a few days back on where the value is in NAC is just too important to leave with mis-information. So I'm responding to Alan's (is that better, Alan? ;)) comments here in more detail.

Let's be clear about one thing first - yes, ConSentry is really strong in post-admission. No, that's not why I think post-admission is the key to doing access control right. Let's think about typical business problems today:

The offshore development office where you've got no oversight over your "employees"
The contractors who have to be on your LAN but should only go to certain servers
The medical devices, robots, printers, and VoIP phones that need protection but can't host an agent
The stored data with no app-level control, like the research docs the DuPont guy stole
The credit card data that you have to not only restrict access to but document that control

None of these is solved with pre-admission control - not one. It's all about limiting what people can do AFTER they're on the LAN.

Admission control has limited value. And in case I haven't been clear in my opinion here, let me just say that I think admission control has limited value. It's not worthless - it just doesn't buy you much. And I believe that for reasons well beyond the fact that I work at ConSentry.

To be clear, ConSentry "gets it" that you need pre-admission control as a piece of the overall security solution. We just don't think that delivering our own installed endpoint agent is what customers want. Let's look at the strategy:

For unmanaged machines, no installed agent - you don't own the device, you're not installing software on it. Enter the ConSentry dissolvable agent. And yes, Alan, we OEM it from Check Point. Looks at OS, looks at AV, checks for adware/malware/spyware, looks at Registry settings, etc. Way more than "do you have AV software installed?" which is where a lot of dissolvable agents stop.

For managed machines, you need a permanent agent. We're smoking something if we believe you'll buy one from ConSentry. If Cisco's not winning at that game, why the heck would we think we could? Enterprises don't want to install yet another agent just to do NAC. They'll wait for MS NAP or they'll get the latest Sygate/McAfee/Trend version - something that's ALREADY on their desktop will do it. The managed PC is the desktop team's problem, and they're going to use software that's already on the desktop for NAC. That's where I think Amrit and Stiennon are really coming from - why would you go through all that trouble and expense of installing new software on the PC just for NAC? The endpoint software guys know they need to get there - hence the Symantec acquisitions of Sygate and Altiris.

So ConSentry's strategy - go figure - is why fight the customer. We'll work with NAP and Sygate and McAfee and Trend and any of the endpoint guys our customers ask us to. We're already working with regional endpoint guys in Europe and Japan, too - we call this Universal Endpoint Interoperability. We excel at post-admission control, but we know you need endpoint checking too, so we'll leverage whatever you've already got on the desktop to do it. And we'll give you a dissolvable agent to check the desktops you don't own.

As for advocating for out of band vs. inline, it's like the old saying - if you can do, do. If you can't, teach. Now that's actually heretical in my book since both my parents were teachers, but seriously, if you have the horsepower to be inline, and you're focused on security, you sit inline - full stop. It's always more secure to be inline. Those who advocate out of band simply CAN'T sit inline.

Alan's right - it's all about identity-based control. But out-of-band approaches cannot provide identity-based control. Taking feeds from an IDS does not equate to identity-based control. VLANs and ACLs do not equate to identity-based control. What do you do for the simple case, say the CIO? She's an exec and she's in IT - she needs overlapping sets of permissions. Are you going to build a VLAN of one for her, and then for every other person with a unique set of access rights? It just doesn't work. Plus, all this VLAN and ACL stuff is happening at L3 and L4, and what you really need is L7 - really understanding the app involved and applying access rights with that parameter as well.

Identity-based control is knowing all sorts of info about the user - name, addresses, location, role, group memberships - and mapping that to all sorts of info about what's happening at that moment - what server are you going to, what app are you running, what time of day is it - and applying policy to control access based on that entire universe of info.

I was an analyst and journalist for nine years, and as Rothman says, the instinct for skepticism simply doesn't get out of your blood. I didn't check my brain at the door in favor of a fresh batch of Kool-Aid when I joined ConSentry. I believe what I believe about the need for post-admission control not because it's all I have to hawk but because customers constantly affirm they need it. I'm fortunate to get a fair bit of time with customers, and many of them were trying to do this stuff with ACLs and VLANs, and it just wasn't working.

I'll readily admit to the "selective reality" problem, where given what your product's good at, you end up in front of customers with problems you can solve instead of those who can't use your technology. But that said, all you need to do is read the news today about what's getting companies into trouble and it's crystal clear it's all about controlling users after they're on the LAN. I believe that through and through, regardless of what ConSentry makes.

--Michelle McLean

mmclean-at-consentry-dot-com

In Good Company

Last week, Cisco had an announcement about an updated Supervisor 32 engine for its 6500 line of Catalyst switches. Understandably, this news fell under the radar of most security blogs and reports, but it's worth highlighting. The heart of this new Sup engine is the Programmable Intelligence Services Accelerator, promising L7 packet inspection and enforcement, and the focus is on getting this kind of intelligence in the wiring closet, as a blade in 6500s deployed at the LAN edge.

It's exciting to see Cisco drive this message around the need for security in the wiring closet, and for ConSentry, the timing couldn't be better. We rolled out our Secure Switching news today, and it's great to be in such good company as we drive that message. Of course, the Cisco module isn't out quite yet, and it'll max out at 2 Gbps, but we definitely get a boost from the Cisco messaging that this is the way IT should be building LANs. And it clearly broadens the message well beyond the well-worn Network Access Control path.

We also decided to have a little fun with our news and how we explain the impact on the wiring closet. If you get a second, check out our take on what this all means for enterprise networks.

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

The Problem with Commodity Switches

Richard Stiennon brought up a great issue in a comment on my "Security Goodness - Baked Right In" post. I was writing my reply into a comment back to him but decided to post as another entry to encourage more discussion with the broader audience.

Richard summed up the perspective of his panelists at RSA as "security must stay separate from the network because the switching market is driven by cost-per-port and security is too expensive." Richard wants to know our response.

It's a great question in several ways. First off, I totally agree that switching has hit commodity status and security, particularly LAN security, is far from it. There are exceptions on both sides, of course, but it's generally true. So what's the implication for a secure switch? Essentially, a secure switch is a security device first and a switch second. So it's anything but a commodity product. If a customer's switch purchasing decision is driven solely by price, a secure switch will not even be on his or her radar. Someone buying a secure switch needs something more - some form of network access control. This buyer is motivated by the security feature set, not by simple packet forwarding, and that changes the equation immediately.

Richard's question indirectly raises two other interesting issues.

One - the separation of security and control planes. A minority of shops will want to keep the security plane separate from the control plane in perpetuity. Those shops are rare, but we do see them, so the market for a controller-type approach, where the enforcement device stays separate from the LAN switching infrastructure, will continue. It'll be much smaller than the secure switch market, but it will persist.

Two - the innovation cycle for security vs. switching. This topic is even more interesting, because every shop has this problem. Basically, people want their infrastructure to last five to seven years but they know security changes at a much faster rate. So how can you have a switch that can "keep up" with those security changes?

To be fast, switches have been built on ASICs. But a secure switch has to be updated to stay relevant. So the commodity merchant silicon chips that everyone - including ConSentry - uses to build their switches aren't enough. To build a secure switch, you also need programmability, but to keep up with LAN speeds, you need really fast programmability. For ConSentry, the answer is our custom CPU (see the Multithreading post from Dan a couple weeks ago).

And now we've come full circle - that combination of high speeds and programmability is why a secure switch isn't a commodity. Richard's panelists are right - you can't get the security you need in today's "cost per port" designed switches. But that's doesn't mean security and switching can't come together effectively - they just can't come together in those switches. You need a new architecture. You need a secure switch.

--Michelle McLean

mmclean-at-consentry-dot-com

Security Goodness - Baked Right In

My buddy Mike Rothman comments today on a wireless LAN product adding more security and how that's representative of the broader trend of security getting built directly into the infrastructure. He leads off with this statement:

I've been saying for a while that security eventually becomes a feature of the infrastructure. That's right, baked right into the network fabric and data center.

Richard Stiennon calls this idea the "secure network fabric."

I couldn't agree more with both these guys. Most new network functions and services come into the network as an overlay first but work their way into the infrastructure. Firewalls got integrated into routers, network monitoring happened first in probes and then got built into switches, and even the now-ubiquitous Power over Ethernet went from separate add-on bricks to a feature of every wiring closet switch.

As an ardent pragmatist, Rothman I'm sure can appreciate the overlay appeal of LAN security and network access control. Forcing a switch upgrade throughout the entire enterprise to add in security doesn't fly - offering an appliance that can drop in, with no network changes, is the pragmatic approach.

But if security ultimately ends up in the switch, when does "ultimately" happen? For some of our customers, today. Some of those who've been using our controllers for more than a year are now approaching a network upgrade cycle. For them, getting a "two-fer" -- as in two for one in our secure switch -- has a lot of appeal. Rather than buy just a dumb switch and stick a controller behind it, they'd rather take the opportunity of the upgrade cycle to integrate security directly into their network infrastructure.

Why is this kind of integration appealing, and ultimately inevitable? Device consolidation, tighter control, pervasive coverage, operational simplicity.

Rothman alludes to the market resembling the musical chairs game, saying there's still time for the overlay model but the music will stop. I contend it will stop not all at once but customer by customer, as they go through the upgrade cycle. And whether you'll have a chair depends on whether you can offer the integrated, "baked right in" approach.

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

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