Illuminations

Attacking Anti Virus Software

Wow, it's been a while since I posted. How time flies.....

Sowhat from Nevis Labs gave a very well attended presentation at Black Hat Europe last week on "Attacking Anti-Virus Software". He has been running a research project for several months now focussed on  how attackers might be targeting the very software that more than 80% of Enterprises rely on to keep them safe. In just those few months he has discovered numerous vulnerabilities in widely used AV products. Nate McFeters at ZDNet gave a pretty concise summary of Sowhat's presentation that I encourage you to read, so I won't recount all the detail myself.

By demonstrating how vulnerable one of the key security tools in the Enterprise toolbag is, Sowhat has shown just how far we in the security industry have to go to put our own house in order.  A few years back Microsoft used to come in for daily bashings as yet more vulnerabilities and exploits were unearthed in the Windows OS.  At first it looked as if big company arrogance might prevail, and the press lambasted the folks in Redmond for not taking responsibility for creating security holes that you could drive a bus through.  But give credit where credit is due.  Microsoft stepped up and put a focus on security and cleaning up vulnerabilities that few other software companies have (Apple, for instance, have flown under the radar thus far, but it looks like their day in the limelight is coming).  Today, Microsoft have processes and procedures in place that make updates predictable and manageable, they have developed relationships within the security community that improve their visibility into future threats and most importantly they have invested some of their billions in making security an integral part of what they do and cleaning up their own act.  Pretty impressive for a company whose primary revenues do not come from security. Can we expect the same response from the titans of the security industry like Symantec and McAfee?  After all security is their business.  The irony is not lost on me that both these companies ship "NAC" solutions that are client based and are supposed to ensure that your AV is patched and running.  Good to know that the fox is out there guarding the chicken coop.

//Dom

 

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

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

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

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

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

Cisco TrustSec: What does it mean for the industry?

The Blogosphere has been surprisingly quiet about Cisco's TrustSec announcement, so I thought I'd weigh in and try and get some debate going. Mitchell Ashley did put out a couple of insightful posts on the subject and there have been a few articles reporting the news.

First thing I should say is that this announcement finally validates what we've known for sometime. The task of managing internal access to an Enterprise LAN is a problem that is too complex to use the traditional Cisco topology-based access control approach. You absolutely need to take an identity-based (or role based) approach otherwise the task of defining and managing policy becomes complex and unworkable. So the first piece of good news from this announcement is that we will be able to stop wasting energy on the religious wars over topology vs. identity because the big guy on the block finally admits that we were right all along.

As an aside, I do have to have a chuckle at Jayshree's quote on CNN where she claims "a new paradigm for security in role-based user access to applications and resources without compromising business velocity". Puhleeease, Nevis Networks, Consentry, Vernier (or should I say Autonomic Networks as they are to be known henceforth, more on that later) have been shipping solutions for years, and the paradigm was around long before that (can you say DEN). So history will be recast and re-written again, but that's ok, I'm quite flattered actually since Cisco has viewed our website over 2500 times in the past 6 months, I'm going to assume that their marketing team learned a lot from us.

So what about the Cisco TrustSec technology itself? What will this mean for customers and the market?

Cisco vs. Microsoft - Round 1,658  ding, ding

TrustSec is a Cisco response to Microsoft's Server Domain Isolation.  We saw an attempt by the two giants of the Enterprise to make nice over NAC/NAP with the promise of interoperability, but it strikes me that they are increasingly trying to solve the same problems at different network layers, so how long will that peace last and who ends up as the collateral damage in the ensuing battle?  You guessed it, Enterprise customers.  While Microsoft stuck to the desktop and Cisco stuck to switching and routing everything was fine, but Cisco has pushed further up the stack, and even set up shop in MS's backyard with an endpoint initiative in NAC.  Microsoft on the other hand just keep trying to abstract the network and diminish it's role to nothing more than a dumb transport.  All of this gets further complicated by the fact that they sell to different teams in IT organizations and that can lead to overlapping efforts or turf wars.

The Cost of Upgrades

For those Cisco customers interested, what will this mean in terms of cost?  Well, 802.11AE describes a new Ethernet frame format so that will mean software upgrades, and possibly hardware too, not just in the wiring closet but throughout the network and in the router infrastructure as well.  The big issue, as always, is that Cisco wiring closet switches have a very limited set of ACLs available and you need both ingress and egress ACLs.  So if you get too granular on your identity based policy you are definitely looking at hardware upgrades, possibly throughout the network.

It also relies on 802.1AF for key management, which is an extension of 802.1X.  So you're going to have to deploy that as well.  Bottom line here is that for Fortune 500's with big IT teams and money to spend, this might be possible, but for everyone else the cost of deployment and maintenance will probably be prohibitive. 

Secure Malware Channels

The thing that really struck me about TrustSec is the fact that it provides the ability to create point to point encrypted channels based on policy.  This is near and dear to my heart because Nevis introduced this ability using IPSec 2 years back.  The piece that Cisco seem to have overlooked is that if you don't implement IPS on each and every access switch port at wire speed like we do, you've just created secure channels to spread malware throughout the network.  Now, I'm sure they'll tell you that this is where NAC comes into play and that if you deploy NAC alongside TrustSec you have nothing to worry about.  Hmmm, except, as we all know, pre-connect NAC alone (particularly Cisco's flavor of it) is really bad at mitigating blended malware threats, particularly zero day threats. 

Heterogeneity

Another big stumbling block with TrustSec is that it depends on you having a 100% Cisco network.  Cisco has really been pushing hard against the best of breed approach lately and redoubling their efforts to lock customers into a single vendor approach.  Call me crazy, but I see this as a sign that there is a chink in their armor.  They've been losing switch market share slowly but surely to HP, and now you have other upstarts in the Secure Switch arena like Nevis Networks and Consentry starting to make in-roads in the wiring closet.  It's interesting to see Cisco starting to adopt "defend your turf" strategies that the other 7 dwarves in switching have had to live with for so long to defend against Cisco.  I think there is good opportunity for some of those other switching vendors to go on the offensive right now using security and wiring closet commodotization as the weapon of choice.

Standards (or are they?)

According to the Cisco releases and whitepaper, TrustSec is "based" on 802.1AE.  Interesting word "based".  Are we to conclude that Cisco have "interpreted" this new IEEE standard, which is just another way of saying "made it proprietary"?  Or have they developed proprietary extensions to lock in some additional Cisco goodness?  Or have they just built an architecture on top of the IEEE standard so that it would be interoperable with multi-vendor equipment?  I think the latter is highly unlikely.  I tend to agree with Mitchell Ashley's assessment, that this will be a closed Cisco architecture

If anyone else has any insight or opinion, I'm all ears

//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

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

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