Illuminations

Are we done yet.....?

From the number of e-mails that I've received over the past couple of days it seems that everyone has enjoyed the little exchange of ideas between Alan and myself.  Alan says he's done, so I figured I should close things off as well. 

I'm glad to see that Alan responded to all the questions I had on his product, and in exactly the way I expected him to.  As he correctly pointed out, I lifted all those concerns from the recent NWW NAC review, and it seems from his responses that he doesn't feel any of them stick (except the one that he owns up to and says is covered on roadmap).  So, Alan, are you going to be surprised if I tell you that I don't think a lot of the concerns raised about our product in the year old NWW review that you quoted stick either?  We're a year further down the line and at the time that review was conducted our product had been on the market 4 weeks.  We actually came out with an equivalent score to our friends over at Consentry in that one and they had been shipping for over a year.

Now speaking of Consentry, it seems that Michelle has been hanging on the sidelines waiting for Alan and I to wind down before trying to steal our sweat equity.  Come on Michelle, next time jump in rather than waiting until the end, especially if your on my side :-)  First I should apologize to Michelle, she is correct that the doing vs. teaching analogy was hers, I just forgot where I heard it.  In my defence Consentry have borrowed big slices of our messaging and positioning over the years (the LAN is the DMZ, LAN security, Secure Switching, etc) so let's just call it a wash.  I don't think it's a surprise that Michelle lines up behind me on most of the arguments, as we both take the same inline approach to NAC, the main architectural differences are in Nevis's deterministic performance, pattern matching and broader deployment capabilities.  Anyway, let's address more of that nasty FUD that Michelle decided to fling:

I think it's fair to say that Consentry has more customers than us right now, but they have been in the market a year longer than us, mainly because we built our own ASIC rather than taking an old one in off the street.  We believe this gives us some long term architectural advantages, particularly when it comes to secure switching, as that is what we set out to build from the ground up.  As for the accusations of no customer announcements this year? 

How about June 18th?

http://www.nevisnetworks.com/press_release.php?id=44

or June 4th?  There were a few in that one

http://www.nevisnetworks.com/press_release.php?id=42

I'll go one better.  Do you want to hear what our customers have to say about us?  Here's a couple of examples:

http://brighttalk.com/comm/Nevisnetworks/edb684859b-4539  - Aptuit

http://brighttalk.com/comm/Nevisnetworks/7747e567c9-4423-983-4146 - SOCCCD

Anyway, Michelle, aside from those little FUD'ish distractions, I think we're mostly on the same page.  Maybe we can go a couple of rounds on the definition of a Secure Switch, why pattern matching has distinct customer value for security in a LAN Security solution and other advantages besides security.  We should also debate that thorny topic of performance at some point, and why it's important to customers.  Just let me get my breath back first :-)

//Dom

This isn't Deadwood and you're not the NAC Sheriff ...

Aside from being immensely amused at Alan's incredible self belief that someone appointed him the NAC Sheriff (he already ran those Forescout scoundrels out of town), and that we're all guilty of idiocy, incompetence and outright lying until we can prove we're innocent, I'm really struggling to understand where he is coming from in his latest rant and what point he is trying to make.  Come to think of it I'm still trying to find the point of the previous rant as well.  I see a bunch of wild aspersions cast about, and I see that he believes the onus is on me to prove to him that his amateur assessment of our technology is incorrect.  I actually think it's more fun to let him keep guessing as he seems to have enough time on his hands to spend worrying about what everyone else is doing.  I will, however, give you a couple of clues Alan:

1) The Firewall is not IPtables (can I say it any clearer?).  It provides application layer gateways and  application recognition and control (read L7, not just L3/L4) for every user and every port while still maintaining switching performance and latency.  Just because you don't know how to do it Alan, doesn't mean it isn't so.

2) The IPS functionality is not SNORT based (can I say it any clearer?).  It integrates signature matching along with protocol, traffic and behavior anomaly algorithms.  The signature set is developed in house by our security research team.

Now, I think we can all agree that Alan was plain wrong about those two items, so it's safe to assume that there is a high probability that his other accusations were wrong too.  N'est pas?  At the end of the day the market is going to decide truth from fiction, and I'm very willing to put my fate in the hands of that justice system rather than the StillSecure Kangaroo Court.

So Alan, here's a few questions for you:

a) You claim to be an out of band device, but it appears from the recent NWW test that you in fact sit in-line.  So, how does your box fare with triple play and quad play traffic?  Cause any bottlenecks?  Add any latency?  Bring the network down when the box fails?  I'm sure you'll say no to all of the above, but why should I believe you?  Remember, this is Sheriff Shimel's town and whatever you say must be a flat out lie.  Either that or you can't be smart enough to overcome the problems.  Oh, but hang on, Sheriff Shimel's rules only apply to the rest of us, so you'll get away with that.

b) So you can't do authorization based on user roles?  Man, that must make policy configuration a bit of a nightmare, even in a moderate sized organization.  I'm guessing you'll say no, but watch out for Sheriff Shimel, you know that won't fly with him.  What am I saying?  I keep forgetting it's only the rest of us who have to worry about that. 

c) These advanced endpoint checks that you've been crowing about.  Apparently you need a PhD in Python to make them usable.  So does anyone actually use those features?  Again, I'm sure your answer is yes, and Sheriff Shimel's special rules apply again.

d) So you don't have the ability to detect if an endpoint is already infected other than a few token things like Blaster?  I'm guessing the answer to this one is that you'll sell me your IPS to cover that.  But hang on a minute, how much will that cost me, and will it actually prevent rapidly propagating malware at the user edge of the network anyway?  I'm pretty sure Sheriff Shimel will turn a blind eye to this one

e) Apparently your reporting capabilities leave a lot to be desired, so how does anyone know if they're getting any value out of the solution?  Yep, you guessed it, Sheriff Shimel is going to give you a get out of jail free card on this one

As I mentioned earlier, the market will ultimately decide our fate.  There are many different ways to skin a cat, but we have a strong belief here at Nevis that integrating (not bolting on) NAC, identity-based application intelligent firewalling, and IPS, significantly increases the value proposition to the customer, enables new business initiatives and provides greater IT efficiency savings.

Finally, just so I can end this feeling like I might have contributed something of worth to the World (and for the sake of my own sanity), here's some background and thinking on why general purpose processors can't provide the level of performance required to do deep security processing in the LAN:

The LANsecure ASIC provides the enabling technology for the entire LANenforcer product line, having been designed from the ground up as the basis for a family of security platforms. The overarching design goals were to enable integrated deep packet inspection security with high throughput flow-based network processing in a way that scales in multiple dimensions.

Most security appliances today are designed around general-purpose processors. As these processors were not really designed for networking, most appliances add FPGA, NPU, or custom ASIC front-ends. These front-ends offload mechanical fast path processing to enhance performance. However, slow path classification and security policy processing, including looking deep into packets to detect and identify malware, still must be done in software on the CPU, or in look aside peripheral processors attached to the CPU.

The LANsecure ASIC overcomes this fundamental scalability limitation by integrating slow path security processing directly into the massively multi-threaded network processing engines. This not only enables integrated flow classification and stateful firewall policy processing, it modularizes the processing to support scaling, and provides the ability to react in real time to changes in policy or dynamic network threat status.

Since the LANsecure fast path is entirely in software, it can easily be extended to accommodate additional security or networking services in subsequent software releases. Furthermore, it uses the integrated security engines to accelerate in-line security processing on every packet, including threat signature matching, and checksum verification.

In summary, each LANsecure ASIC provides

Up to 10 Gbps integrated networking and security throughput

High performance interfaces, with hardware packet I/O and memory management, including hardware managed queues

Six clusters of four CPU engines, each supporting four-way hardware multi-threading, for a total of 96 threads. Each CPU can access any memory location, whether on-chip or off-chip.

Integrated security processing engines for signature matching, and TCP checksum processing

And thanks for the medal Alan, I will wear it proudly

//Dom

WonderNAC. I like it......

I appear to have touched a nerve with Alan Shimel and inspired him to get out his FUD gun. A trait that he apparently dislikes in others, but is ok when he is holding the double barrelled, fully automatic, laser guided version with the big bullets.

Let me first say, "Those that can, do, those that can't, teach". Alan has spent a good number of column inches devoted to pontificating about our second rate this and that, how we have mashed up a bunch of old technology, and ends by giving me a history lesson in NAC. Alan, I bow down to your superior historical knowledge, but I'm not interested in being a history teacher, I'm interested in shaping the future. So you keep teaching history to the young 'uns, but try to avoid teaching subjects like "Other People's Technology Innovation 101" when you are not in possession of the facts. Our technology is neither old nor second rate, but if it let's you sleep better at night believing that, so be it.

Come on Alan, get back on point. My "tirades" are arguments based on technology and architectural approaches to solving a problem. At no point have I ever said that "pre-connect posture checks and such are useless". What I have said is that it's not a hard technology problem to solve. Look around, there are a myriad of vendors out there all claiming to do it, you and me included. Hell, there are even some organizations building it themselves from Open Source in their spare time. I'm a great believer in posture checks, I just think that it's one element of the solution. So if there is an approach that can extend the scope of the NAC solution and offer deeper and broader security, while enabling other benefits such as increased IT cost savings, and new business initiatives, isn't it worth looking at? You were in New York in June Alan, and heard our customer from Upper Canada District School Board describe how he has saved significant IT resources and solved the problem of Cyberbullying in an entire school district with 40,000 students by deploying 5 of our appliances. I didn't hear a single other customer from that panel describe such an extensive deployment, articulate tangible IT cost savings or talk about the fact that they are now able to do things that they couldn't achieve before.

Now to deal with some of the FUD:

1) Yes, I disagree with Alan and Mike Fratto on a couple of issues. It's called debate and it's healthy
2) We have plenty of customers, thank you very much. In fact I just spent an entire analyst inquiry day with Gartner and shared a lot of information with them on this topic. You really lose credibility when you have to resort to mud slinging about someone's business, especially when you're wrong.
3) Yes we sit in-line, no that doesn't mean your network goes down if the appliance fails. Like any other in-line device we have high availability options, some of which are very innovative and won't cost you extra.
4) No our firewall is not based on IPtables, our IPS is not a bunch of 30 day old SNORT signatures and our switch is not a second rate Linksys or D-Link (we have customers who have selected us over Cisco so I think that speaks for itself). I'd love to understand where Alan gets his deep insight into the technology innovations that we have made. Again, you lose credibility when you pontificate about things without possession of the facts.
5) We have a team of 8 dedicated security research engineers in our Nevis Labs group who have been credited with finding 11 vulnerabilities in major OS's and applications in the past 6 months. So, we're not just enforcing patches to vulnerabilities in the pre-connect posture check, we're out there contributing to the security community as a whole by finding the vulnerabilities in the first place.
6) Don't even get me started on the FUD around performance. Let me simply state that the reason we spent 2 years building an ASIC is because we believe that performance is at the heart of the solution and how it relates to the real world problem. There are a host of patents filed and our innovation in this area is exceptional (even if I say so myself :-))
7) You know what? I'm tired of responding to FUD. If someone wants to have a debate about architectural approaches to solving customer problems, please let me know.

At the end of the day, our product is not perfect, nobody's is, but adding more features to a solid architectural foundation is easier than trying to change that foundation after the house is built.

//Dom

Fratto misses the mark on Access Control

While I agree with some of what Mike Fratto says in his Dark Reading article, "The Limits Of Access Control In NAC", I don't agree that Network Access Control can't add value to application access control, and that application security has to be entirely taken care of by the application logic. In fact one of the major issues in Enterprise security today is exactly that network and application access control are treated as mutually exclusive with separate islands of policy. The real issue is that you have to have the right kind of NAC solution to provide any real value. At the application layer, policy is easy, but control is hard. The opposite is true at the network layer. Control is easy, but policy is complex and hard. What is needed is a unifying technology that takes application layer policy and enforces it at the network layer.

To do that, you have to have a solution that sits in line (real time processing is critical), is able to recognize applications, do deep packet inspection and IPS, apply network and application policy and control decisions in real time, pull identity based policy from existing application layer policy stores (e.g. identity management systems), and not affect latency or throughput of the LAN. A very tall order, but that technology and solution exists and it's called the Nevis LANenforcer. A network layer policy enforcement device that provides application aware network access control and persistent threat detection. I agree you still need the application logic to do a job (security in depth), but now there is a way to tie the application and network layers together with a single policy model and robust enforcement strategy.

I also agree that the type of solution that StillSecure and others of that ilk provide is woefully inadequate to do anything much more than be a crude gatekeeper at the network layer. They don't have any level of application layer intelligence or real-time logic to make accurate and meaningful application layer security decisions, and Alan Shimel would have you believe that using VLANs to provide granular differentiated access is the way to avoid draconian black and white quarantine decisions. I'm afraid I'll have to call BS on that one. Every user is different and has different needs, but most are not malicious intentionally, so should we limit access whenever someone's endpoint has a vulnerability or it is infected with malware? Wouldn't it be better to just ensure that vulnerability is not exploited or stop the malware affecting any other resource? In other words, drop the bad traffic and let the good stuff through, making the experience completely transparent to the end user. Once you start doing policy control enforcement with VLANs, AAA and switch ACLs, you've either massively increased complexity and cost (and therefore compromised security), or you've had to compromise on the granularity of that control to save costs (and therefore compromised security). Dynamic, identity-based firewall rules for each and every user, with application intelligence is the only way to get simple granular control, and pulling the policy from existing application layers policy stores prevents skyrocketing costs. Remember we're living in a world of increasing virtulization now, if your network policy enforcement device doesn't have application visibility and intelligence in real time, how are you ever going to make meaningful security decisions?

//Dom

Real time NAC

An interesting article and a timely blog post from Mike Rothman caught my eye yesterday...

In the internetnews.com article, it appears that Ofir Arkin is on his soap box at Blackhat spouting about the insecurity of NAC again.  I thought his presentation at last year's Blackhat was a little academic, but this year I find myself nodding along as I read his comments.  His comments on the NAP/TNC alliance certainly ring true - great idea, but multi vendor approach will inevitably add complexity and implementation problems (that's ok, there is plenty of time for this to evolve).  However, what really resonated with me is his suggestion that NAC has to evolve beyond a focus on the endpoint posture check (let's face it, that's not really hard and is of limited value) and become a more real time technology providing an accurate view of what's on the network and what it's doing at any moment in time.  I've always felt that the temporal nature of posture checking was a fundamental flaw in the NAC concept, and that has obviously been borne out as most vendors react to ever more educated customer demand, and rush to declare that they have some kind of post-connect threat monitoring capability to address the myriad of issues that couldn't be caught in the pre-connect phase.  Unfortunately for all these vendors, they are limited by their architectures and have to resort to taking inputs from other detection devices so that they can send control messages to yet other devices to do any enforcement.  The reason, we at Nevis, built our product from the ground up was to overcome the obvious architectural issues:

1) If you want granular visibility and control in real time you have to be in the data path

2) If you're in the data path performance and scalability are critical

Vendors have to be held accountable when it comes to enabling deep packet inspection and control in real time and at LAN speeds, and that means legitimate 10Gbps performance - not vacuous data sheet claims.

On a separate note, I have to commend Mike Rothman on his Daily Incite.  Being the straight shooter that he is, he has gone straight to the heart of the matter and recognized that the broad Network World NAC test that was published yesterday has really only tested one feature and "the least interesting part" at that.  It would be more meaningful to customers to start testing NAC appliances for performance, scalability and the ability to solve the real world problem.  Yes that's harder to do from a test bed standpoint, but that is what customers need to evaluate when making critical decisions to insert devices into critical areas of their networks and data paths.  I have to commend Joel Snyder and Mandy Andress for pointing out in the article that even though many of these products claim to be out of band and vendors claim there is no performance requirement becasue of this, they all at some point sit in line during the NAC process, even if it's just for authentication.  We're no doubt going to see all the usual crowing and posturing from those that topped the scoring (hell, I'd do it too), but at the end of the day it's a data sheet validation exercise.  Let's face it, the review is a snapshot in time in a limited and vanilla test bed.  Enterprise networks are way more complex, each with a myriad of unique nuances, and if there is one thing I know for sure from our customers, nothing beats trying it out in your own network.  I'd really like to see someone step up and do a review in the form of a real world business problem rather than feature comparisons.  Challenge vendors to solve the two critical problems that NAC is supposedly targeted at and measure them on their success in achieving the end goal in a practical, manageable and affordable way:

1) Ensure the services that the network offers continue to stay up in the presence of malware and threats

2) Ensure that users get appropriate access to resources and services and nothing else

I think we'd soon find out that it is either too complex and expensive to get all the moving pieces required by most solutions to work, and that taking anything but an identity based approach to access control incurs too much cost and complexity to be practical.  Oh, and I'd also like someone to stand up and be counted and recognize that while 802.1X is certainly a great ideal for network authentication (that's why we support it), it's not as simple as industry experts purport it to be and many who have tried it have given up because of cost, complexity, interoperability and just plain frustration.  There has to be some transition path to really make it practical while adding significant value after you get there and that's part of the value prop that Nevis offers it's customers. 

//Dom