Illuminations

Why Blacklisting Doesn’t Work

After reading Mike Fratto’s post on “Why Blacklisting Works” I feel some comments are in order.

The default allow (or “blacklisting”) vs. default deny (“whitelisting”) debate seems to go on and on ad infinitum. Let me state up front that I am unabashedly in the default-deny camp, and here’s why.

Sure it sounds easier in principle to just deny the bad stuff, thus avoiding the trouble of figuring out just what the good stuff is (and maybe avoiding a few irate help desk calls in the process), but, as you actually point out, it’s really not good security. But we have to accommodate customers of either persuasion and, truthfully, your NAC product should let you do it whichever way you want.

We opted for default deny.

Why? Because it’s clearly the best security practice, based on many years of many people’s experience. We just couldn’t make a firewall default allow and still think of ourselves as security people.

Besides, when you put an ACL on a file, do you normally make it default allow and blacklist just those who shouldn’t be granted access? I think not.

But, honestly, it shouldn’t be that big a deal to append an allow-all rule if that’s what you really want to do. In fact, we ship our product with an allow-all sample policy configured on all secure interfaces, since we found that most of our evals and deployments want to start out by monitoring what’s happening on their network – since unfortunately, they don’t really know how bad of a problem they have. And this makes it easier to get the box up and running.

And we also ship with a “pre-login” sample policy that allows just enough access to things like Active Directory to let Windows boot and get GPOs, and let users get tickets to login and open browsers, and which of course has to be customized with the specific server addresses for the particular network. I don’t really understand why you couldn’t configure the ConSentry box to do the same thing and whether this was for endpoint compliance or for post-connect, but I suspect it is because they only allow you to set policies for UDP and TCP. So if you had a default deny but want to allow some other IP protocol, such as ICMP or GRE, you can’t do it.

But I digress. On your impossible-to-manage points, we think you can avoid a lot of the headaches inherent in a traditional monolithic perimeter firewall rule set by composing policies for users based on group memberships. This way, the access granted to particular user classes can be more readily managed.

Speaking of managing policies, I wish LAN security could be as simple as you want would like just by blacklisting, but as far as I am concerned it’s only an illusion. If you forget to deny your sales people access to one of those R&D servers, say, nobody might ever know until it is too late. So have you really solved your security problem, or just temporarily made it appear to go away?

I can get behind your thought processes, though. When we were developing the Nevis secure switches I have to confess that even I thought the same as you, at least for a while. I pondered, isn’t LAN security a different species than perimeter security? At the perimeter it’s like at the front door, you only want to let friends in and anyone who is not your friend is clearly SoTE, but on the LAN, it’s like you’re roaming among the cube farm: everyone can pretty much go anywhere they want to because everyone is your friend. Inside, you really only need to make a few places like the CEO’s office off limits and remember to lock up those few file cabinets with sensitive stuff in them when you step out. Most people are honest and adhere to company policies, right? And guests need an escort.

To put it differently, at the perimeter you typically want to deny most ingress but allow most egress, but on the LAN you are more concerned about what different classes of users can or maybe shouldn’t access. And until recently there have been limited options for providing an escort for your guests to keep them from running amok. So how to architect a LAN security firewall, should it default to deny or allow?

-- Joe

I'll See Your New Chips, and Raise You...

Eric Ogren has a nice blog over at ComputerWorld, but his post this week left me shaking my head. Eric anticipates that the new generation of Intel and AMD chips with built-in security processing is going to change the playing field for security appliance manufacturers. More importantly, he states, “it is becoming increasingly difficult to justify the large engineering investments in custom-built ASICs or hardware that is not built on a standard platform”. This assertion couldn’t be further from the truth, and doesn’t anticipate where the ultimate direction of all the emerging security services is going. Security has become increasingly complex due to the sophisticatation of blended malware attacks, among other reasons. The increase in mobile systems, as well as non-employees on corporate networks have reduced the effectiveness of the perimeter and requires security services within the network infrastructure. From Nevis’ perspective, the switch is the ideal security enforcement point because it can block threats in microseconds at the lowest common factor, the port. Existing departmental firewalls or out of band appliances cannot keep malware off the network because, by definition, the malware is already inside the corporate LAN before they even detect it. The future of LAN security is a fully secure access layer – both wireless and wired. Many of the people we speak to get this message. Secure switching at wirespeed is now a reality. Many of the traditional switch vendors understand this dynamic and are planning to build ‘stateful’, application aware switches that are secure.

The challenge thus far in the market has been with performance. Obviously switches are blazingly fast and designed with performance and scalability in mind. LAN technologies require high performance and low cost. Traditionally, security products have been low performance and high cost. As security merges into the network fabric, secure switches need to remain cost competitive AND fast. Something has to give.

If you are going to layer in deep packet inspection and analysis, and do it on every packet, you can’t sacrifice the performance that people expect. Access layer switches are now shipping with multiple 10 Gbps interfaces. Many of the fastest IPS devices in the market struggle to cope with this level of traffic. Eric might be surprised to learn that the fastest Intel and AMD silicon can scale to ‘maybe’ 1 Gbps of traffic when running L4-L7 services. How then can we secure tens of gigabits per second of traffic at the access layer, while keeping them cost competitive? The only answer is the development of customized ASICs or multicore processors that have hardware acceleration for the key L4-L7 services.

Nevis was built on the vision of high performance and low cost stateful services. Key to our success has been the development of our SuperNova™ security ASIC – which has 24 cores and 96 threads, architected to drive security services and application recognition. It mght surprise Eric to learn that 10 of Intel’s fastest CPU’s cannot keep up with 1 SuperNova. Don’t believe me, listen to what one of our customers had to say.

10:1 price performance – now that’s impressive.

Welcome Parveen....

So, I see Consentry have a new President and CEO. No announcement, just quietly slipped onto their website Management page. Does this mean that the fanfare and fireworks over their new round of funding had a bittersweet side (where did Tom go?)? Interesting to see that Parveen comes most recently from a fundamental security player (McAfee) and was the founder and CEO of IntruVert, an IDP player. I think they've realised that to be a credible secure switching or LAN security solution you do have to put the fundamentals into the security piece of the equation. Nevis made the investment early on and have maintained that with a cadre of Security educated PhD's and researchers who contribute to the security community on a daily basis, alongside a strong team of networking engineers. To realize the vision of security ubiquity in the network fabric you have to be able to talk the talk and walk the walk.

Welcome to the LAN Security market space Parveen. I look forward to meeting you and hearing your perspective on the evolution of enterprise networking and security.

//Dom

It's NAC survey season...

Tim Wilson over at Dark Reading is reporting on a recent Applied Research West survey on NAC (it sounds like it was sponsored by Symantec, but I'm not sure):

300 security professionals interviewed
70% have already deployed NAC or plan it in the next 12 months
86% had no problem deploying
21% had difficulty integrating with security hardware and software
18% said NAC used too many resources
16% complained of lack of industry standards (Well this flies in the face of all the so called industry experts who keep telling us that no-one will adopt until standards are defined. We all want standards but they take time)
54% want an all in one product from a single vendor (not possible with an out of band vendor I'm afraid, there are too many moving parts)
61% say vendors should adopt standards (I wholeheartedly agree, which is why we continue our efforts with IETF, TCG and Microsoft.)

27% use NAC for guest access
80% use it to prevent unauthorized users accessing the network
66% use it to protect critical business assets and prevent data loss
(this is totally inline (no pun intended) with what we see from our customers)

30% say they have no plans to adopt NAC in next 12 months
35% of those say it's too costly
27% of those say it's not interoperable with their existing infrastructure
20% of those say it's too disruptive
(hmmm, they should take a look at our solution, it addresses all those points)

63 % prefer NAC enforement to take place in the network rather than at the endpoint
(the logical enforcement point since the endpoint can and usually is the place where exploits occur)

We have done our own survey, which was a little more focused, and the results will pubish over the next week or so. Look out for that, it's interesting for trends, but I'd be interested to hear from IT professionals if they think it's in-line (there's that pun again) with their thinking

Overall it sounds like the industry and customers are starting to settle on some fundamental architectural building blocks:

• The primary requirement for NAC is to police unauthorized access and protect critical assets
• Don't rely on enforcement on the endpoint, the network is the place to do it
• Provide a turnkey solution that's easy to drop in
• Build ubiquitous security into the network
• Minimize the resources required to manage NAC
• Plan for interoperability and standards
• Make NAC more affordable

Now I can honestly say, hand on heart (that's a big deal for a marketing guy because we don't have hearts, but if it helps I started life as an engineer), that we have satisfied each and everyone of those requirements. I'm very proud of what we have done to mature NAC beyond it's infancy to a holistic LAN Security solution that can stand up to both technical and fiscal scrutiny. We don't have all the answers (yet), but our architecture and approach will stand the test of time.

//Dom

UPDATE: Tim Greene at NWW has also picked up this story

A switch by any other name....

It was nice to see Consentry finally get a decent win for their NAC Switch.  We've had our fair share of wins with our Secure Switch in the past year, and it's great to see more customers recognise the fact that the switching infrastructure is the perfect place to deliver scalable, ubiquitous advanced services, like security, in the long term.  Many of our own customers, spanning verticals like High Tech, Pharma, Finance/Legal and Outsourcers, have embraced the Secure Switch, and continue to place regular, quarterly repeat orders as they migrate their wiring closet infrastructures.  But let's not detract from the fact that Consentry did some dragon slaying here in the US, and in FSU they found a customer willing to speak with their check book about their dissatisfaction with Cisco's NAC and the lack of identity based services available in switching overall.  This stuff is not easy to do while maintaining switching performance, which is why you have to make an investment in purpose built silicon, rather than using general purpose COTS (commercial off the shelf) chipsets that don't make the grade.

Now, you'll notice that I called the Consentry switch a "NAC Switch" at the start of this post.  This is deliberate despite the fact that they position it as a secure switch.  In the mind of most security and networking professionals we talk to, a secure switch needs to at least attempt to be secure, and it also has to be able to maintain switching performance while delivering that security and other application intelligent services.  Without any pattern matching capabilities, a very large proportion of threats are free to march right through the Consentry NAC switch.  To be fair, I have spoken at a couple of conferences in the recent past with Michelle from Consentry and she openly admits that threat detection and mitigation is not a focus for their company.  They've built in some anomaly detection capabilities for some level of value add, but their focus is clearly NAC and LAN segmentation (it says so right there on their website).  That's why I'm confused as to why they call it something it isn't.  We chose to take a more holistic approach to the problem, so we spent a bit more time on our ASIC and product line.  This enables us to provide threat signature matching to address a broad range of LAN threats, and hardware accelerated application intelligence, all at a full 10Gbps and switching latencies.  When you integrate this functionality and performance together with access control and NAC, and tie in identity at all stages, you get a secure switch worthy of the title.

//Dom

Is your NAC glass half empty or half full??

Mike Fratto wrote an interesting article debating whether NAC is ready for primetime or not, and, unsurprisingly, Mike Rothman congratulates MikeF for having the "stones" to take that position. Personally I don't think this is about stones, pebbles or grains of sand. MikeF makes some very valid points about the readiness of NAC products to address a broad set of use cases in diverse enterprise environments, but he also makes some great points about the readiness of IT teams to implement the technology. In fact in my reading of his article, I think MikeF raises more points about the readiness of Enterprise IT teams for NAC than the products themselves. This is an important point that I think MikeR has missed in this and several of his previous posts. The reality is that just as products have to mature, customers also have to come up to speed on what this new technology can do for them in their environment. The good news is that customers are coming up to speed and fast. Not only that, but they are recognising the potential of the technology and helping to redefine and extend NAC. What's really gratifying is that NAC has evolved more and more into the vision of LAN Security that we set out more than 2 years ago. So, let's get this straight, it's a good thing when our customers come to us and tell us what they need. Sometimes we see a trend that can be applied across many customers and we embrace it because it means we can add value that people will be willing to pay for. We also innovate and take ideas and features back to customers because we think we have seen a way to help that perhaps the customer didn't think technically possible. In this manner, products and markets evolve and the reason I have remained on the vendor side of the industry is because their is no bigger kick than seeing your product being used to solve a problem or create an initiative that wasn't possible before. We are lucky enough to be closely plugged into early adopters and are not only seeing our rate of customer acquisition increase at a very healthy rate, but also a huge increase quarter by quarter in the number of RFI/RFPs that we are being invited to respond to. While not everyone is ready to roll out corporate wide today, many are certainly biting off managable high priority projects and deploying pilots. Our customers range from specific projects with Fortune 100's to full global deployments with large enterprises and campus deployments with medium enterprises. This is perhaps "security incite" that the two Mike's are not a party to so they assume that things aren't moving along. So come on guys, less of the negativity, and start writing about the cool things customers are already doing with our technology rather than the nits about what can't be done. As one of our customers said, "Look at the problem you want to solve, find a vendor who's thinking the same way and that you can partner with and jump in with both feet". If we all sat around waiting for everything to be perfect we'd still be living in caves.

//Dom

Is Secret Sharing for Convenience Really Keeping a Secret?

I grew up with the maxim “security by obscurity bad, real security good” ringing in my head.

That’s why I find it so hard to be amused when I hear arguments that obscurity can provide security if it is more “convenient.” And then I see products that actually embrace security-by-obscurity-for-convenience out there in the market – and being shipped by companies claiming to be security vendors.

This has come up recently in the context of captive portal login certificate warnings. The beauty of captive portal is that it uses a standard Web browser as a nice GUI for someone logging in. Since it talks to a more or less standard Web server, the way to secure passwords sent over the link is to use TLS. But to use TLS, the server needs a public key certificate, and browsers want (or, should want) to verify the names in these certificates and who issued them, mostly for Web commerce but in this case to protect against password sniffing or classic spoofing attacks.

Many products provide a throw-away temporary certificate for evaluation purposes. This almost always is a self-signed certificate so that customer’s passwords are at least encrypted using a new private key for that deployment. But this gives a browser warning about the certificate not having been issued by a known CA.

So some products try to avoid this major inconvenience by using HTTP as the default. Since this is clearly insecure and most customers will want to turn on TLS, these vendors oblige by shipping a “free” certificate. This way customers don’t get the nasty warning and will see the padlock (if they care), and on newer browsers don’t see red backgrounds in their URLs. End of story, security restored.

Unfortunately, it isn’t. These products get rid of the warning by using a vendor public domain name and baking the same certificate into their software. That means everybody has the same private key, too. How many of these customers actually click on the browser padlock and view the name in the certificate? Do you do this when you go to your bank or order on Amazon? Unfortunately, too many people aren’t in the habit.

I was taught that a secret shared with everyone is not a secret at all. If you’re going to provide a security mechanism, do it right – make it clear that what’s shipped by default is strictly for evaluation and let people put in their own real certificate.

That is, if they care about security in the security product they are purchasing. Isn’t that the whole point?

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